OpenHIE Community Wiki
Documents
Communities
Projects
Resources
Description: The send alert workflow allows the infrastructure services to register alerts with an alert service. The alert service allows alert consumer to query for these alerts and send them out to health workers in whatever format is appropriate (sms, email, etc).
Sponsors: Eduardo Jezierski, Dykki Settle and Carl Leitner
Status: under development
Last Modified: 3 March 2016
An alert is intended as a largely one way communication to a health worker. Use cases for alerts include:
In response to a crisis or emergency situation, such as the 2014 and 2015 outbreaks of Ebola in western Africa, it is critical to communicate to health workers within a particular health care network and to verify, to the extent possible, the receipt of such alert.
Though the infrastructure of the alerting workflow indicated below would permit communication of many types of additional messages, alerts, or notifications, it is not intended that these messages exceed the above use cases. In particular these do not include "Critical Findings" or other types of alerts which require immediate action by a health worker.
The IHE mACM standard on which this workflow expects that additional IHE profiles utilizing mACM would be developed to address broader alerting workflows.
An Alert Reporter shall originate or relay alerts (an alarm, either physiological or technical, or an advisory) to the Alert Aggregator.
This actor can optionally query an Alert Aggregator Actor for statistics related to the dissemination of this alert to the intended recipient(s)
The Alert Aggregator may optionally collect statistics related to the dissemination of the alert such as delivery status or the value of a SMS response or acknowledgment.
In the workflow below, the Alert Report is presented as a generic actor. Examples include:
Ref | Interaction | Transaction Specification | Notes |
---|---|---|---|
1 | Notice an alert condition | None: Defined by business rules of Alert Reporter | |
2 | Search for provider, organization and/or facility identifier(s) | FHIR DSTU2 search on Location, Provider or Patient resources ITI-73 Find Matching Services CSD Request | Alert Report constructs query according to business rule under which alert was initiated FHIR transactions are more aligned with the mACM ITI-84 transaction which has references to Organization, Location (e.g. facility), or Provider resources. |
3 | Search for provider, organization and/or facility identifier(s) | FHIR DSTU2 search on Location, Provider or Patient resources OR | |
4 | Return identifiers | FHIR DSTU2 bundle search response OR ITI-73 Find Matching Services response | Current reference implementation of ILR (OpenInfoMan) supports both of these transactions. FHIR transactions are more aligned with the mACM ITI-84 transaction which has references to Organization, Location (e.g. facility) or Provider resources |
7 | Search for patient identifier(s) | FHIR search on Patient resources (PDQm) request OR PIX/PDQ request | |
8 | Return identifiers | FHIR DSTU2 bundle search response OR PIX/PDQ response | FHIR transactions are more aligned with the mACM ITI-84 transaction which has references to Patient resources |
9 | Return identifiers | FHIR DSTU2 bundle search response OR PIX/PDQ response | |
10 | Report Alert | Mobile Report Alert ITI-84 (mACM) | Identifiers of recipients passed either by reference to appropriate FHIR resource (requires FHIR server for those resources) Identifiers of recipients passed as embedded reference to appropriate FHIR resources (does not require FHIR server) |
11 | Report Alert | Mobile Report Alert ITI-84 (mACM) | |
12 | Disseminate Alert | Disseminate alert(s) via appropriate communication mechanisms available to the HIE (SMS, email, POC system, etc). Transactions depend on the communication channel. | |
13 | Update dissemination status | Transactions are not specified (currently) by mACM standard. Note: RapidPro uses custom FHIR compliant endpoint "Communication/$response" and "Communication/$sent" for this. We can submit a Change Proposal to standardize this | |
14 | Request for Alert Status | Query for Alert Status ITI-85 (mACM) Request | |
15 | Request for Alert Status | Query for Alert Status ITI-85 (mACM) Request | |
16 | Return Alert Status | Query for Alert Status ITI-85 (mACM) Response | |
17 | Return Alert Status | Query for Alert Status ITI-85 (mACM) Response |
2 Comments
Roger Friedman
In the architecture call today, Ed J. raised the idea of changing step 7 from a push to a pull to allow for intermittent connectivity of SMS senders. I think this is one good option. However, I also think that it requires a registered POS system and some mechanism to restrict the scope of records available to that system. Also I'd like to see some sort of an ACK to know that the alert has been delivered. Perhaps there could be a combination of pull and push – a pull request would be a request to subscribe with a last-record-received parameter. The IL will reply with all messages newer than the last-record-received, including newly created messages as they are created, sent one at a time with an ACK. NAK or failure to ACK unsubscribes.
Derek Ritz
Hi all.
I'm very sorry to have missed the architecture call yesterday, especially since there was a discussion of one of my favourite topics: alerts.
As is sometimes the case, I think I'm going to be a bit of a contrarian on this topic. At a quite basic level, I really do not believe it should be the role of the SHR to "raise alerts". The SHR is a repository and that is, in my view, the only job it has. Even if we think of SHR as denoting a "virtual database" of health observations, prescriptions and dispenses, lab orders and results, DI orders and images – it doesn't change the fact that it is a repository, not a logic engine. Alerts rely on a logic engine. As another side comment, I can't see why the Interoperability Layer will have to resolve all the IDs. Content that is stored in our registries and repositories is already resolved to our cardinal code sets / terminologies and is indexed by the ECID, EPID, ELID, etc. Inside the datacentre, we should not have to do message massage.
What I believe we will need is a "service" that is dedicated to being the logic engine for OpenHIE. This is the ICP (integrated care pathways) service that I have been advocating for, lo these many months – and which we are now starting to draw into our workflow discussions. As Roger correctly noted (on the Google Group thread, I think) – we seem, in the present example, to be raising an alert on something that didn't happen. That is a key role of the ICP service – to understand what are the guideline-based care pathways so that, when something that should have happened has NOT happened, we can raise an alert. Another key role is to be able to raise an alert when something that did happen should NOT have happened (e.g. prescribing Derek penicillin when he is allergic to it).
Arising out of the RHEA status call last week, I was invited to prepare a discussion document describing an alert logic that we could use on the implementation in Rwanda as well as for our OpenHIE work. The approach that I proposed was based on the following: