Send Client Alert Workflow
Last updated
Last updated
The send alert workflow allows the infrastructure services to register alerts with an alert service. The alert service allows alert consumers to query for these alerts and send them out to clients (patients) in whatever format is appropriate (SMS, email, etc).
An alert is intended as a largely one way communication to a client of the system. Use cases for alerts include:
Crisis Response 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 clients within a particular health care network and to verify, to the extent possible, the receipt of the alert.
Care Reminders A subject of care may receive care from multiple providers across multiple health care networks, and coordination of care across providers and networks is difficult. If an Electronic Medical Record or Longitudinal/Shared Health Record is present, Care Reminder alerts can be triggered through the examination of clinical records about the subject of care. Care Reminder alerts are sent either to the subject of care.
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.
The IHE mACM standard on which this workflow expects that additional IHE profiles utilizing mACM would be developed to address broader alerting workflows.
Workflow Maturity | Maturing |
|
Standards* | 1. FHIR DSTU2 search on Location, Provider or Patient resources / FHIR DSTU2 bundle search response OR ITI-73 Find Matching Services CSD Request / ITI-73 Find Matching Services response 2. FHIR search on Patient resources (PDQm) request / FHIR DSTU2 bundle search response OR PIX/PDQ request / PIX/PDQ response | |
Assumptions and Prerequisites | None | |
Actors | Alert Reporter - The point-of-service system that captures patient identifiers, is responsible for sending the identifiers to the HIE. 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) In the workflow below, the Alert Report is presented as a generic actor. Examples include:
Alert Aggregator - A system responsible for distributing an alert to a client. The alert aggregator manage these alerts according to the required jurisdiction defined business context, for example dispatching them onto a communications platform for delivery to an intended recipient. The Alert Aggregator may optionally collect statistics related to the dissemination of the alert such as delivery status or the value of an SMS response or acknowledgment. |
# | Interaction | Data / Notes | Transaction Options |
1 | Notice an alert condition (Defined by business rules of Alert Reporter) | ||
2 | Search for patient identifier(s) | FHIR search on Patient resources (PDQm) request OR PIX/PDQ request | |
3 | Search for patient identifier(s) | ||
4/5 | Return identifiers | FHIR transactions are more aligned with the mACM ITI-84 transaction which has references to Organization, Location (e.g., facility) or Provider resources | FHIR DSTU2 bundle search response OR PIX/PDQ response |
6 | Report Alert | Identifiers of recipients passed either by reference to appropriate FHIR resource (requires FHIR server for those resources) OR Identifiers of recipients passed as embedded reference to appropriate FHIR resources (does not require FHIR server) | Mobile Report Alert ITI-84 (mACM) |
7 | Report Alert | Mobile Report Alert ITI-84 (mACM) | |
8 | Search for patient identifier(s) | FHIR search on Patient resources (PDQm) request OR PIX/PDQ request | |
9 | Return identifiers | 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 | FHIR DSTU2 bundle search response OR PIX/PDQ response |
10 | Disseminate Alert | Disseminate alert(s) via appropriate communication mechanisms available to the HIE (SMS, email, POC system, etc). Transactions depend on the communication channel. | |
11 | Response | ||
12 | 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. | |
13 | Request for Alert Status | Query for Alert Status ITI-85 (mACM) Request | |
14 | Request for Alert Status | Query for Alert Status ITI-85 (mACM) Request | |
15 | Request Alert Status | Query for Alert Status ITI-85 (mACM) Response | |
16 | Request Alert Status | Query for Alert Status ITI-85 (mACM) Response |