You're absolutely right that the diagram does not indicate where the alert comes from; unlike an event that can be recognized by looking at data as it is stored, in this case we are looking for an event that doesn't happen. Some app is undoubtedly generating it, but what app is another question. That app, or a messaging gateway for a number of alerting apps, can be responsible for maintaining the store of alerts. As far as the app which polls the alert store in Ed J's diagram, that is one way to move away from "fixed apps." One thing that gets freed up is the idea that the alerts should go only to the (potentially non-existent) CHW; it could go to the manager of the service at the facility which the patient was supposed to attend; it could go to the patient; it could go to all the above.
Alerts, like indicators, imply some logic applied to the SHR to identify a cohort. I'm pretty sure there will be more than one app which is capable of doing so. There are three or four scripting languages that are in use for such things, and there will be different optimizations for different purposes.
By this process of creating messages, we are discovering pieces of the IL. CSD InfoMan is one part; the query encounters workflow is another part. At this point, it's not clear to me that the IL is even an app, it may be just a bowl of lollipops (endpoints) built elsewhere (like your idea of a HWR sidecar alerting app). Maybe this is me just grasping the full potential of SOA.
Saludos, Roger
···
Sorry I was not able to join the call today, as I am traveling.
I am a bit unsure of all of the context of this workflow. A few questions/comments:
In this architecture diagram, the SMS application is RapidSMS, but I am assuming we want to move away from such “fixed” applications.
when [1] "Missed referral noticed” is initiated by the SHR, how does the SHR know which SMS application to send the message to?
it seems like we could think better about how to leverage the HWR, for example in deciding what cell number we can send an alert to.
It seems like the FR and TS are not used in this workflow — can we cut them form the diagram? Or is there some interaction that’s missing?
I like Ed’s DOP, but it’s not clear where these message would be held. Do we really want them in the IL=OpenHIM itself? Perhaps the message queue could be something that gets tacked on to the HWR as an app? There are clear extension points in CSD that would support this and the API is already established. The IL could then translate your "Query for enriched alert parameters” which is presumably a GET request into the correct CSD findMatchingServices request
Cheers,
-carl
On May 12, 2014, at 3:27 PM, Eduardo Jezierski edjez@instedd.org wrote:
I’ll speak from the perspective of a team who has fulfilled the role filled by the concrete ‘rapidsms’ example in the workflow in a zillion contexts
Here are my recommendations:
Most importantly, change “send enriched alert message” to “send message parameters” (or message arguments, to be precise)
Transforming those into a message to a user is a POS / user interface responsibility / concern:
The POS system does things like
deciding whether a SMS, voice call is appropriate depending on context, disease, etc
looking up phone numbers / validating that it is sent to the right SIM card in some cases where CHWs have 2;
getting the right message to generate in the right language/dialect,
adding some metadata about the referral so the CHW can say something like ‘to take a new test for TB’ or ‘to make sure your baby is healthy’ and answer questions like will I get blood drawn, remind the patient to take insurance/vouched/id cards and so on.
schedule it within the right schedule (eg not at 3am)
Let’s sure that call is the cleanest http post URL we can; as long as it is adequately authenticated and secured, something simple like
[http://URL of POS system]/[endpoint]?param1=arg1¶m2=arg2 etc. This will allow the maximum amount of apps to play; these patterns we have gravitated to over time look something like the following:
Finally, a suggestion to have REST-style event feeds (Distributed Observer Pattern)which puts the responsibilities of the POS system in its box instead of making the HIM complicated with idiosyncratic & ad-hoc downtime/unable to reach/error condition loops. It is also widely implemented in a lot of mobile messaging apps; and is the pattern that allowed “frantic interoperability” between 5 parties in the wake of the Haiti disaster where getting and sending SMS to the population for health stuff was key
The alternate flow would look more or less like this (source pasted at bottom of emails, i need to get better at the syntax)
<PastedGraphic-2.png>’
Original:
<PastedGraphic-1.png>
title Send missed referral alert
participant CHW
participant RapidSMS
participant OpenHIM
participant CR
participant PR
participant FR
participant TS
participant SHR
SHR->SHR: [1] Missed referral noticed
SHR->+OpenHIM: [2] Send alert details
OpenHIM->+PR: [3] Resolve provider identifier
PR->-OpenHIM: [4] Return provider NID
OpenHIM->+CR: [5] Resolve patient indentifier
CR->-OpenHIM: [6] Return patient NID
RapidSMS->+OpenHIM: [7.1] Query for enriched alert parameters
-----Original Message-----
From: Carl Leitner
Sent: May 12, 2014 2:10 PM
To: Eduardo Jezierski , ohie-architecture@googlegroups.com
Subject: Re: Sending “event” alerts to POS systems for mobile alerts
@Ed, I like your proposed changes, feel free to make those changes in the wiki page as this discussion goes on. I believe you and Derek are the Sponsors in this case.
Some general comments:
I think that the place where the alert message can be ‘held’ could either be the in an IL alerts mediator or as Carl says the HWR could do this.
As Roger eludes to, I don’t think that it is just the SHR that will produce these alerts, but rather that many applications within the HIE may want do so. Perhaps the SHR actor should rather become a generic ‘alert producing’ actor or something similar.
I don’t think the ‘alert producing’ systems need to know which POC system they are sending the alert to, rather they should just register the alert with appropriate metadata about the type of the alert and it should be up to the POC to request alerts that they are interested in. This could be by message type, patient cohort or geographic location.
Cheers,
You're absolutely right that the diagram does not indicate where the alert comes from; unlike an event that can be recognized by looking at data as it is stored, in this case we are looking for an event that doesn't happen. Some app is undoubtedly generating it, but what app is another question. That app, or a messaging gateway for a number of alerting apps, can be responsible for maintaining the store of alerts. As far as the app which polls the alert store in Ed J's diagram, that is one way to move away from "fixed apps." One thing that gets freed up is the idea that the alerts should go only to the (potentially non-existent) CHW; it could go to the manager of the service at the facility which the patient was supposed to attend; it could go to the patient; it could go to all the above.
Alerts, like indicators, imply some logic applied to the SHR to identify a cohort. I'm pretty sure there will be more than one app which is capable of doing so. There are three or four scripting languages that are in use for such things, and there will be different optimizations for different purposes.
By this process of creating messages, we are discovering pieces of the IL. CSD InfoMan is one part; the query encounters workflow is another part. At this point, it's not clear to me that the IL is even an app, it may be just a bowl of lollipops (endpoints) built elsewhere (like your idea of a HWR sidecar alerting app). Maybe this is me just grasping the full potential of SOA.
Subject: Re: Sending “event” alerts to POS systems for mobile alerts
Hi,
Sorry I was not able to join the call today, as I am traveling.
I am a bit unsure of all of the context of this workflow. A few questions/comments:
In this architecture diagram, the SMS application is RapidSMS, but I am assuming we want to move away from such “fixed” applications.
when [1] "Missed referral noticed” is initiated by the SHR, how does the SHR know which SMS application to send the message to?
it seems like we could think better about how to leverage the HWR, for example in deciding what cell number we can send an alert to.
It seems like the FR and TS are not used in this workflow — can we cut them form the diagram? Or is there some interaction that’s missing?
I like Ed’s DOP, but it’s not clear where these message would be held. Do we really want them in the IL=OpenHIM itself? Perhaps the message queue could be something that gets tacked on to the HWR as an app? There are clear extension points in CSD that would support this and the API is already established. The IL could then translate your "Query for enriched alert parameters” which is presumably a GET request into the correct CSD findMatchingServices request
Cheers,
-carl
On May 12, 2014, at 3:27 PM, Eduardo Jezierski edjez@instedd.org wrote:
I’ll speak from the perspective of a team who has fulfilled the role filled by the concrete ‘rapidsms’ example in the workflow in a zillion contexts
Here are my recommendations:
Most importantly, change “send enriched alert message” to “send message parameters” (or message arguments, to be precise)
Transforming those into a message to a user is a POS / user interface responsibility / concern:
The POS system does things like
deciding whether a SMS, voice call is appropriate depending on context, disease, etc
looking up phone numbers / validating that it is sent to the right SIM card in some cases where CHWs have 2;
getting the right message to generate in the right language/dialect,
adding some metadata about the referral so the CHW can say something like ‘to take a new test for TB’ or ‘to make sure your baby is healthy’ and answer questions like will I get blood drawn, remind the patient to take insurance/vouched/id cards and so on.
schedule it within the right schedule (eg not at 3am)
Let’s sure that call is the cleanest http post URL we can; as long as it is adequately authenticated and secured, something simple like
http://[URL of POS system]/[endpoint]?param1=arg1¶m2=arg2 etc. This will allow the maximum amount of apps to play; these patterns we have gravitated to over time look something like the following:
Finally, a suggestion to have REST-style event feeds (Distributed Observer Pattern)which puts the responsibilities of the POS system in its box instead of making the HIM complicated with idiosyncratic & ad-hoc downtime/unable to reach/error condition loops. It is also widely implemented in a lot of mobile messaging apps; and is the pattern that allowed “frantic interoperability” between 5 parties in the wake of the Haiti disaster where getting and sending SMS to the population for health stuff was key
The alternate flow would look more or less like this (source pasted at bottom of emails, i need to get better at the syntax)
<PastedGraphic-2.png>’
Original:
<PastedGraphic-1.png>
title Send missed referral alert
participant CHW
participant RapidSMS
participant OpenHIM
participant CR
participant PR
participant FR
participant TS
participant SHR
SHR->SHR: [1] Missed referral noticed
SHR->+OpenHIM: [2] Send alert details
OpenHIM->+PR: [3] Resolve provider identifier
PR->-OpenHIM: [4] Return provider NID
OpenHIM->+CR: [5] Resolve patient indentifier
CR->-OpenHIM: [6] Return patient NID
RapidSMS->+OpenHIM: [7.1] Query for enriched alert parameters
RapidSMS–>-CHW: [8] Send missed referral SMS to CHW
–
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.
–
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.