Sending "event" alerts to POS systems for mobile alerts

Legacy ohie-architecture
1

Context: The general flow we were discussing was here:
https://wiki.ohie.org/display/documents/Send+alert+workflow

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:

  1. 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)
  1. 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&param2=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:

**http://www.somemhealthapp.org/whatever/rwandaMhealthstuff/MissedReferral? PatientID= 12345 & ReferralReason= TB_Diagnosis & CHW_ID= 98765 ****& **NotAfter= 20140622

  1. 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

OpenHIM–>-RapidSMS: [7.2]Return enriched alert parameters

RapidSMS–>-CHW: [8] Send missed referral SMS to CHW

2

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:

Context: The general flow we were discussing was here:
https://wiki.ohie.org/display/documents/Send+alert+workflow

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:

  1. 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)
  1. 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&param2=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:

**http://www.somemhealthapp.org/whatever/rwandaMhealthstuff/MissedReferral? PatientID= 12345 & ReferralReason= TB_Diagnosis & CHW_ID= 98765 ****& **NotAfter= 20140622

  1. 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

OpenHIM–>-RapidSMS: [7.2]Return 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.

For more options, visit https://groups.google.com/d/optout.

3

Carl,

Thanks for connecting.

The topic (from my perspective) on the architecture call was aimed at exploring the advantages and disadvantages of “push” versus “pull” alerting. Of course there are many dimensions to such a conversation, but that’s the upshot.

Ed can correct me if I’m wrong.

Best,

Shaun

···

Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Mon, May 12, 2014 at 2:10 PM, Carl Leitner litlfred@gmail.com wrote:

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:

Context: The general flow we were discussing was here:
https://wiki.ohie.org/display/documents/Send+alert+workflow

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:

  1. 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)
  1. 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&param2=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:

**http://www.somemhealthapp.org/whatever/rwandaMhealthstuff/MissedReferral? PatientID= 12345 & ReferralReason= TB_Diagnosis & CHW_ID= 98765 ****& **NotAfter= 20140622

  1. 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

OpenHIM–>-RapidSMS: [7.2]Return 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.

For more options, visit https://groups.google.com/d/optout.

–

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.