The attached diagram shows some ideas about alerting. The idea is that there is an Alert Manager in the IL. The Alert Manager (which is somewhat modelled on the OpenMRS messaging module) can be polled from edge apps or can be configured to send alerts by multiple devices/protocols. Each of these devices/protocols is represented by an Alert Sender which is instantiated and configured by the Alert Manager. Alerts are registered with the Alert Manager and assigned (based on facility, provider, patient) to Alert Senders when push is desired. A single alert should be able to have multiple destinations and formats (e.g. e-mail to facility with lab result, SMS to provider saying check for new lab results for patient x). The configuration of the Alert Manager and its message queue/history would be persisted.
Another class of object resides inside the HIE, the Alert Generator. Driven either by timer or registry events, the Alert Generator uses data in the registries to identify alerts. It can also persist workflow states within those registries. When an alert condition is satisfied, an alert is generated and sent to the Alert Manager. Note that there is a similarity between indicators and alert conditions which should be exploited if the HMIS group specifies an indicator registry. Note that alerts also fit the use cases of case-based surveillance and notifiable disease reporting (including international health regulations).
At the moment, my feeling is that the most attainable Alert Generator would be based on the OpenMRS reporting module. (This would have the beneficial side effect of providing an alerting mechanism for OpenMRS.) Note that there can be multiple instances of Alert Generators, so each instance could manage a single program or query types in a distinct manner while still using the report generator as the query engine. However, I think that ICPs specified in business process models as described by Derek can have a place, particularly if they can be represented as program workflow states in OpenMRS and used as selectors by the report generator. Eventually we are going to run into competition between transactional and reporting uses of the registries, and hopefully by that time the HMIS community will have the process of loading a data warehouse with registry data for indicator generation down pat.
···
Hi Derek,
Thanks for this. I’m finally starting to see how the ICP workflows fit into the big picture (it took me longer than it should have
).
I agree with what you have laid out here, however, I don’t think that the IL (or the HIE infrastructure in general) should do the actual sending of an alert or even know of what form the alert should be sent in (ie. SMS, email, carrier pigeon). The HIE should just provide a mechanism to store these alerts and their metadata and allow alert handling POC systems (such as RapidSMS) to query for the alerts it is interested in and the POC should decide how these get delivered to the recipient.
Cheers,
Ryan
On Tue, May 13, 2014 at 3:56 PM, Derek Ritz derek.ritz@gmail.com wrote:
Hi all.
Attached is a PPT which proposes a generic “alerting” capability which could potentially be used on both the RHEA project and within OpenHIE.
Comments are welcome.
Warmest regards,
Derek.
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
-----Original Message-----
From: Ryan Crichton
Sent: May 15, 2014 3:55 AM
To: Derek Ritz
Cc: “ohie-architecture@googlegroups.com”
Subject: Re: generic “alerts” capability–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.