The official version of the OHIE workflows can be found in the OpenHIE Architecture Specification.

Overview

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 clients (patients) in whatever format is appropriate (sms, email, etc).

Sponsors: Eduardo JezierskiDykki Settle and Carl Leitner 

Status:  under development

Last Modified: 3 March 2016

Definitions

An alert is intended as a largely one way communication to a client of the system.  Use cases for alerts include:

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

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

Actors


Non-Exhaustive Examples of Alert Reporters

In the workflow below, the Alert Report is presented as a generic actor.   Examples include:

Workflow



title Send alert
participant Alert Reporter as AR
participant Interoperability Layer as IL
Participant Client Registry as CR
participant Alert Aggregator as AA
participant Client as Human
AR->AR: [1] Notice an alert condition\n    OR    \nHuman Initiated Alert
opt
 AR->+IL: [6] Search for patient identifier(s) 
 IL->CR: [7] Search for patient identifier(s)
 CR->IL: [8] Return patient identifier(s)
 IL->-AR: [9] Return patient, provider, organization\n and/or facility identifier(s)
end
AR->IL: [10] Report Alert
IL->AA: [11] Report Alert

  AA->CR: [11.1] Lookup patient (s)
  CR->AA:  [11.2] Return FHIR resources
 
AA-->Human: [12] Disseminate alert(s)
opt
  Human-->AA: [13] Free-text/unstructured response 
  AA->AA : [13.1] Update dissemination status
end
opt
    AR->IL: [14] Request for Alert Status
    IL->AA: [15] Request for Alert Status
    AA->IL: [16] Return Alert Status
    IL->AR: [17] Return Alert Status
end




RefInteractionTransaction SpecificationNotes
1Notice an alert condition
None: Defined by business rules of Alert Reporter
2Search for provider, organization and/or facility identifier(s)

FHIR DSTU2 search on Location, Provider or Patient resources
      OR

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.
3Search for provider, organization and/or facility identifier(s)

FHIR DSTU2 search on Location, Provider or Patient resources

      OR
ITI-73 Find Matching Services CSD Request


4Return identifiersFHIR 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
7Search for patient identifier(s)

FHIR search on Patient resources (PDQm) request

    OR

PIX/PDQ request


8Return identifiersFHIR 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
9Return identifiersFHIR DSTU2 bundle search response

     OR

PIX/PDQ response

10Report AlertMobile Report Alert ITI-84 (mACM)

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)

11Report AlertMobile Report Alert ITI-84 (mACM)
12Disseminate Alert

Disseminate alert(s) via appropriate communication mechanisms available to the HIE (SMS, email, POC system, etc).  Transactions depend on the communication channel.

13Update 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
16Return Alert StatusQuery for Alert Status ITI-85 (mACM) Response
17Return Alert StatusQuery for Alert Status ITI-85 (mACM) Response