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.
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
Hi Ryan.
Thank you for catching this; you are completely correct, of course, regarding the need for a more generic pattern for message forwarding. I “named” RapidSMS in this deck because I was explicitly targeting the solution at the RHEA project. In the described scenario, RapidSMS is playing the role of a queue actor and playing the role of the POS system responsible for actually doing message transmission to a message client. I apologize if this created confusion. This is a “generic” solution only in that it would support message transmission for more than just the “maternal danger signs” use case that the RHEA project is trying to address right now.
Another deck, which is not specific to the RHEA project, has also been posted to this forum. The other one more precisely articulates these actors and the roles they would play in a more general OpenHIE architecture.
Warmest regards,
Derek.
···
On Thursday, May 15, 2014 3:55:22 AM UTC-4, Ryan Crichton wrote:
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...@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-architect...@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: ry...@jembi.org