I have a few thoughts on the discussion, and will try to share how this is approached in proven, robust architectures that industry uses including LMICs
First of all we are mixing the concerns across services. I’ll try to articulate what are the concerns we are discussing and how they are effectively separated:
REQUEST There are services that identify an alert needs to be sent. That is their concern and it could be within services or in some cases the IL would generate that request. Sometimes the request may come with pre-determined information. For example, if a referral to a clinic is needed, and you need to remind the receiver of the alert about the address, then in some cases all you can get is a Facility ID. Sometimes, however, you may already get the Address resolved by an IL. This may or may not be ‘better’ depending on the scenario, as you’ll see below. Ideally, this is managed or informed by an ICP service that knows the care pathways that knows the juxtaposition of patient states and sends the right alert - pregnant woman with HIV may not necessarily be referred to the same clinic than her pregnant neighbor wout HIV. But this is just about optimizing the separation of concerns of requesting alerts, not executing them
GENERATE Then there is a service that receives that synthesizes the form and destination of such an alert into the right user experience.
In other words, it may get something like an input “referral?patient =2345&clinic=789” (in URL format is the “lingua franca” of alerting tools; inventing or adding SOAP interfaces to this would mean not be looking at what protocols are used.
Such services may be responsible for, for example, translating a clinic ID into an address that is actually a recorded audio; or making sure to look up the address written in the right script / dialect. For that reason some information you may want to resolve in services of #1, but others you don’t because it starts being “user interface” concerns not interoperability/orchestration.
Sometimes the fields are not for a specific alert but an alert schedule - ie. the user interface for the alert is actually 3 messages sent 3 days before, 1 day before, and on the day of the appointment.
The output of this service is a series of scheduled messages (for SMS) or call plans (for voice)
- DISPATCH Finally, there is a service that is connected to some level of gateway that pushes the messages out and/or executes the call plans. An appropriate service for this can expose a uniform API at scales ranging from a puny android phone / modem to a telco-connected gateway; and be conformant to be hosted inside operators as needed.
#2 and #3 exist as well proven architectures and products and are there are a couple (at most!) robust examples in the ehealth world for LMIC; this is the topology that for example eHealth Systems with Joaquin Blaya follows (using hosted OpenMRS as a #1) or MOTECH follows (using a mixture of Motech and instedd technologies for #2, and InSTEDD for #3)
As a matter of fact, if the OHIE sandbox can send out appropriate requests for alerts I can hook up production country-scale alerting systems just by adding some config. Would love to demo how this is done.
I would not recommend the OpenMRS messaging module; it is built for a different purpose and assumes a different topology and does not necessarily support the scaling, routing, telco interoperability, routing policy etc that more robust products do. We should do a requirements based analysis if people fancy the excercise but I’m not sure it’s what we’re scoped to do,
We have published millions of patient alerts, confirmations, lab results, etc to patients and health workers over the last 8 years; as part of standalone apps or working with OpenMRS and more complex systems, over voice and SMS in dozens of countries and validated from central africa republic to china… I hope that by not being able to be on this discussion board myself over the next days we don’t throw away all the painful & valuable lessons learned in that process.
Will send an update soon with a diagram to illustrate it better-
On May 21, 2014, at 9:37 AM, firstname.lastname@example.org email@example.com wrote:
Apparently the listserv does not do attachments, see below
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.
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.