I would be happy to help coordinate a call to discuss the send alert workflow for over the next week or two. Would you like to see a Doodle poll going out to a certain group of
people or one of the mailing lists?
···
Thank you,
Jamie Thomas
From: Derek Ritz (ecGroup) [mailto:derek.ritz@ecgroupinc.com]
Sent: Friday, September 12, 2014 11:20 AM
To: ‘Carl Leitner’; Thomas, Jamie
Cc: ‘Bob Jolliffe’; ‘Justin Fyfe’; openhie-interoperability-layer@googlegroups.com; ‘Carl Leitner’; ohie-architecture@googlegroups.com; ‘Sean Blaschke’; ‘Jie Xiong’; ‘Steven Uggowitzer’; ‘will ross’
Subject: RE: Alerting within OpenHIE
Are we allowed to ask for help from Jamie as “architecture board” support? Jamie – is this something you can coordinate
for us? This is such a pan-community undertaking… I’m feeling a bit like we’re best served by having this under the ARB umbrella.
**Derek Ritz,**P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other
delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message
and any attachments.
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur
ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient,
par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.
From: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Friday, September 12, 2014 11:14 AM
To: Derek Ritz (ecGroup)
Cc: Bob Jolliffe; Justin Fyfe;
openhie-interoperability-layer@googlegroups.com; Carl Leitner;
ohie-architecture@googlegroups.com; Sean Blaschke; Jie Xiong; Steven Uggowitzer; will ross
Subject: Re: Alerting within OpenHIE
On the OpenHIE architecture call today we discussed having a conference call to help bring us to consensus on this. Unless I missed it, I don’t think we discussed scheduling the call. How do people feel about a doodle
poll? Any volunteers to coordinate?
Cheers,
-carl
On Sep 11, 2014, at 2:27 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
This is a really terrific discussion. I lament a bit that it is happening so urgently because we have a “drop dead” date tomorrow for v1 – but
I suppose that this drop dead date is also the thing that is usefully motivating us all to sort some of these issues out.
I think we should take to heart that “alerts” and “alerting” are overloaded terms. Some are easy to get our heads around (email; SMS messages)
and some are not (“broadcasts”; standing orders). It seems to me that we should, as best we’re able to, leverage architectural elements to allow us to “keep our powder dry” regarding the many use cases we have today and, especially, those we don’t yet have
on our radar. The architectural element that I’m seeing in Ryan and Justin’s work so far is the generic QUEUE. To be sure, an IMAP directory can also be treated as a queue – so I’m going to assume that Carl and Bob are “on side” with this idea. The problem
is – I don’t think IMAP can be thought of as a QUEUE completely separate from the delivery system.
So… as a pattern… we want ALERT SOURCES (whatever they may be) to be able to put alerts into a QUEUE (whatever that may be; also referred to as
an ALERT MANAGER and as an ALERT REPOSITORY on some of the wiki pages out there). An ALERT CONSUMER can then access the QUEUE to process the alert. As described, RapidPRO or RapidSMS or Zimbra or Dovecot or MoTECH or any number of “things that can send messages”
could play the role of the ALERT CONSUMER. The role of the ALERT CONSUMER is to move the alert along to wherever it is supposed to go, be that an individual (a health worker or a patient, for example) or a group (all health workers in a district… all patients…
all OpenHIE users). The ALERT CONSUMER can then “de-activate” the alert from the QUEUE to show that it’s been managed/consumed. (This is an extra step, but supports much more flexibility – including support for multiple consumers of an alert, for example).
Presently, the thread seems to be reading as an either/or discussion about what should be the QUEUE rather than a both/and discussion. I think
we could and should try to frame this as a both/and discussion. De-coupling of the architectural elements will, I think, help us do this.
We need a QUEUE. Personally, I think some of the shortcomings of the FHIR alert resource can be quite readily overcome and, for lots of reasons,
I think there are reasons to favour moving in that direction (toward the “glow of the FHIR”) if it is practical to do so. But to be clear – the FHIR resource doesn’t “do” alerting or messaging or any of the things we need to accomplish in order to satisfy
our user stories. For that, we’ll need an ALERT CONSUMER.
I think we should consider leveraging Zimbra and RapidPRO as our first ALERT CONSUMER actors. My reasons for this are pure expediency. At present,
an alert that is a message needs to have a destination – and for messages that are intended to go to health workers, their “destination” is in the HWR. Today, both Zimbra and RapidPRO are able to connect to our reference HWR, using CSD interfaces, and resolve
health worker IDs to email addresses or phone numbers. As has been pointed out – managing “group broadcasts” is also something which is very doable using both of these tools (although, to be sure, the concept of a “distribution list” isn’t explicitly supported
in the CSD information model at present).
So… our Rwanda user story may be characterised as: “I need to send an SMS to a community health worker when one of her clients is a no-show at
the district hospital”. I think we should add in Carl’s Ebola stories, because they are so pressing and because – as health system management examples – they are really good ones that we should expect will be common (as Carl and Bob have pointed out). So,
an Ebola-related user story could be: “I need to send an SMS to all the nurses at facility X”. To round out our user stories, I’d recommend we add: “I need to send an email to all the facility managers in district X”. This last one just draws in the idea of
an email use case… we can drop it if it’s not worth the extra effort.
What issues are we leaving unresolved if we go this route? Architecturally, this pattern will look like the diagrams found here:
https://wiki.ohie.org/pages/viewpage.action?pageId=19923164 .
This is only a bit different from the diagram here: https://wiki.ohie.org/display/documents/Send+alert+workflow .
The key difference I see is that there is an explicit “deactivate” step in the former which I think we should keep. Another point (not shown in the first diagram) is that an alert may be enriched by the IL. I’m not certain this is needed unless we’re allowing
ALERT SOURCE actors to communicate to the QUEUE (the ALERT MANAGER) from “the wild”. For now, I think we just restrict our ALERT SOURCE actors to those that are above the HIM and we’re fine.
Does this description of actors and communication patterns get us to a point where we believe we can get a working system together between now
and November 30th?
Warmest regards,
Derek.
**Derek Ritz,**P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other
delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message
and any attachments.
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur
ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient,
par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.
From:
openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com]
On Behalf Of Bob Jolliffe
Sent: Thursday, September 11, 2014 1:24 PM
To: Justin Fyfe
Cc: Carl Leitner;
openhie-interoperability-layer@googlegroups.com; Carl Leitner;
ohie-architecture@googlegroups.com; Sean Blaschke; Jie Xiong; Steven Uggowitzer
Subject: Re: Alerting within OpenHIE
Chiming in …
I suspect IMAP would support untargeted and on-demand querying of alerts quite well.
Personally I see the alert repository as being well catered for by solid backend like dovecot (or even zimbra). With very well understood interfaces and standards related to transport, routing and message storage. There
is no necessary suggestion of a chain of MTAs (though of course this could be possible). Personally I think I would favour dovecot - even though I think zimbra is great, it does a whole lot of other things which make it a bigger fish to manage. Chances are
that a well batoned down dovecot is going to be at least as, most likely more, secure than your average web app.
FWIW both zimbra and dovecot also support quite extensive rest interfaces. Dovecot has quite recently announced a gmail compatible REST API (http://www.dovecot.fi/dovecot-launches-a-gmail-api-compatible-rest-api-to-enable-third-party-developers-to-join-its-global-email-ecosystem/ )
which looks interesting - not exactly an ISO standard but tapping in to a lot of traction.
Then the IL could, and probably should, fulfil its historic mission of providing translation, mediation etc between components rather than venture into the realm of alert storage, queuing etc.
FiHR is interesting for lots of things, and getting more interesting by the day, though the alert interface as it currently stands, seems to be too narrowly construed to meet all our use cases, many of which, as Carl
points out, are not necessarily patient centric.
Cheers
Bob
On 11 September 2014 17:03, Justin Fyfe justin.fyfe@ecgroupinc.com wrote:
Hi Carl,
I think that distribution lists can be used to support some use cases of untargeted alerts (IMO those
are still targeted, only at a DL), however SMTP/IMAP still doesn’t support the “on-demand” querying of alerts (which is useful for transient patients or where the recipient doesn’t need to act immediately on the alert), and the use of distribution lists can
be heavy in terms of administration.
I am ok with SMTP/IMAP as a transport (can even use it for shipping FHIR resources as attachments),
however we need to be very careful about the privacy and security architecture, especially if alerts contain PHI or identifying information. Not all mail relays support node authentication, and senders/receivers should use S/MIME. IMO I think a repository
being accessed via HTTP is easier to secure and maintain than a series of MTAs.
RE: FHIR Alerts, it would be up to a consumer of a repository to determine which alerts it is interested
in (standard HTTP access control mechanisms of course). I think that generic system level alerts (“HIE will be under maintenance” for example) wouldn’t use the Alert resource as it specified. I’ll add it to my list of things to ask at the FHIR hackathon.
Cheers
-Justin
From: Carl Leitner [mailto:litlfred@gmail.com]
Sent: Thursday, September 11, 2014 10:53 AM
To: Justin Fyfe
Cc:
openhie-interoperability-layer@googlegroups.com;
bobjolliffe@gmail.com; Carl Leitner;
ohie-architecture@googlegroups.com;
sblaschke@unicef.org;
jxiong@thoughtworks.com;
whotopia@gmail.com
Subject: Re: Alerting within OpenHIE
@Justin,
Just a few quick notes on untargeted:
-
a untargeted alert by geographic area is supported in the EDXL-DE (Distribution Element)
-
the mHero workflow also support this via things like “send a message to all nurses in facility X” or “send a message to everyone in county Y”
-
use of SMTP/IMAP does not preclude untargeted alerts. There are a variety of things we could do here, e.g. mailing/distribution lists.
As an aside, at the California Connects demo (search for CSD), we setup a Zimbra
server and quite trivially created an email account for everyone in the HWR. Point is, we have the existing setup to prototype some of these workflows through an email perspective.
I am not sure how the FHIR alert would limit the audience of an alert within the HIE.
@Ryan,
Thanks for pulling out the two issues. Now that you say it like this, I think there are three issues:
-
What are the workflows being supported — I think maybe we are still in the “cataloging” phase of possible workflows. Maybe we need to crowd-source this on a google doc/ether pad?
-
What standards are needed to support issuing and receiving of alerts
-
How will messages be routed and stored
If we wanted to expose a FHIR alert resource, I think it would be pretty trivial for a mediator in the IL to hook into an IMAP/SMTP/LMTP server.
Another big thing with the FHIR alert resource is that it
requires a “subject of care.” This is certainly not going to be the case for a lot of the non-clinical workflows.
Cheers,
-carl
On Sep 11, 2014, at 10:19 AM, Justin Fyfe justin.fyfe@ecgroupinc.com wrote:
Hi,
Just thought I’d chime in. When I first thought about alerting I had the same reaction as Carl/Bob, using SMTP/IMAP to route alerts however I think there is an additional use case
for which this pattern is not ideal.
When I was reading the FHIR Alert documentation I realized that the reason a recipient isn’t included in the resource is that it supports un-targeted alerts about the Patient. So they
can be used for the purpose of alerting a clinician to double check something (i.e. “Patient may have intolerance to X”) or some note that might help a care worker (i.e. “Patient currently has no running water in home”).
IMO, these types of untargeted alerts are useful, and will be helpful when we get into ICPs which run on a schedule. For example, I imagine there could be a need for an ICP to post
a “Somebody please check this on Mosa’s next scheduled visit” alert.
I think that an alert repository/manager doesn’t prevent SMTP/SMS alerts (as Ryan mentioned they can poll for targeted alerts and deliver them anyway they see fit), it does provide
some additional functionality which I think is useful.
Cheers
-Justin
On Thursday, September 11, 2014 7:33:14 AM UTC-4, Ryan Crichton wrote:
Hi Carl,
Thanks for the input. The original idea for this workflow was sending alerts from the SHR. However, I have consciously removed the naming of specific components from the workflow
for exactly the reasons that you state. So the intention is that many different systems can supply alerts for a variety of different reasons.
I think we need to split this discussion into two parts:
- Does the workflow (agnostic of what standard/implementation we use) make sense? Does this cover out needs for OpenHIE and the needs Carl has stated? To me it seems it does.
- Secondly, what is the most appropriate standard/implementation to use.
Please let me know what you think about the first part. I think this is the most important part to get right for now.
For the second part, FHIR seemed to make sense as it is fairly simple and an emerging standard. It doesn’t completely fit our needs but we can extend it to do so. I agree with you
they do seems tom be very clinically focussed at the moment and this may not suit us. However it seems to me that pulling from a simple REST API would make it much simpler for applications like RapidSMS or RapidPro to interact with it. Having them interact
with a mail server seems like it could be more work to setup, even if the tools do exist.
Also, for the mail server idea do you anticipate that the IL would be able to send emails directly to health workers or would there always be an intermediary (such as RapidPro or
RapidSMS or some other message sending service) that receives the messages? I’d rather the IL just provide the service for an Alert Repository and have other systems responsible for sending message to actual end users.
Let me know what you think.
Cheers,
Ryan
On Wed, Sep 10, 2014 at 6:07 PM, Bob Jolliffe bobjo...@gmail.com wrote:
+1 to all of Carl’s message. Particularly the email message bus.
On 10 September 2014 15:59, Carl Leitner clei...@capacityplus.org wrote:
Hi Ryan,
First, my apologies that I couldn’t join the call yesterday.
As I understand, this workflow is related to sending alerts based on trigger conditions in the SHR. There are several other use cases in which an alert/messaging system is needed
across the HIE. I think it would be best to consider these as well as we design our alerting/messaging system. Here are a few workflows related to the recent outbreak of Ebola in Liberia:
- Sending of Lab Results via SMS from central lab to the health worker
http://bit.ly/1qhUlEN
- “mHero” the synchronization of contacts in an Inter-Linked Registry with RapidPRO. Note that this uses FHIR as well for contact synchronization, but the communication is internal to RapidPRO. Should there be an expectation here that messages sent out through
RapidPRO be auditable from the HIE repository? http://bit.ly/1p77daE
These workflows are all a part of a crisis/emergency response — more about that below.
I had also proposed a while back that we look at using a MTA as our "communications bus.” We then automatically have well understood mechanism to route and store messages/alerts
and lots of existing software to implement this. There are also, as I understand, a number of IHE profiles in which email based communication is assumed.
In general, I am think it is good to expose FHIR endpoints (for example, we now have a mapping from the CSD data model to the related FHIR resources for the OpenInfoMan
https://github.com/openhie/openinfoman-fhir ). But I think it would be better that this is “optional” — FHIR seems to be undergoing some rather rapid changes at the moment and is primarily
focused on supporting clinical workflows. For many of the countries we are operating in, the HMIS/health system/public health workflows appear to be the entry point for OpenHIE technologies.
If we chose an email based message bus, it should be pretty easy to have a mediator in the IL to expose a FHIR alert resource.
Getting back to the crisis/emergency response, I think we should treat the Ebola situation in Liberia as the “norm” rather than the “exception.” We should be building in to the
OpenHIE messaging/alert architecture the ability to respond to a variety emergency situations which require alert and coordination of HWs: — disease outbreak, tsunamis, volcano eruptions and mudslides, bombings, etc. There are a couple of relevant standards
that I would really like discuss supporting in the “version 1.1” that directly support this. Here are a few relevant links:
Again, I think this would be relatively easy to support with an IL mediator and an email communication bus.
Cheers,
-carl
On Sep 10, 2014, at 5:16 AM, Ryan Crichton ry...@jembi.org wrote:
Hi all,
The SHR community had a good discussion around alerting within OpenHIE on our call yesterday. I wanted to share the outcomes of our discussion. I have updated the “Send alerts”
workflow to represent this: https://wiki.ohie.org/display/documents/Send+alert+workflow
Basically we are proposing an alert repository that the IL can host. Other registries or services can submit alerts to the alert repository. Alert consumer systems such as RapidSMS
could query this repository to see if their are any alerts that they are interested in (alerts with recipients that they are responsible for). Then they could fetch the alert and deliver it is the way they see fit (sms, email, etc).
We have been thinking about using the FHIR alert resource for this: http://www.hl7.org/implement/standards/fhir/alert.html
The one major glaring omission in the alert resource is that recipient is missing. We would have to extend the standard to add this and perhaps speak to Graeme to get this included
into FHIR proper.
I don’t think this is too out of wack with what we have been discussing previously. I’d like to hear other thoughts about this and the appropriateness of the solution.
Cheers,
Ryan
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org
–
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.
–
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
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile:
+27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org
–
You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.