1. Introduction
Alerts within the OpenHIE interoperability layer can be published and retrieved from a "Alert Repository" hosted by the IL. This service exposes a virtual "bucket" of alerts. Services "above the IL" and "below the IL" (that is infrastructure, and point of care) may use the Alert Repository to:
- Post (publish) alerts
- Query (poll) for alerts
- Deactivate alerts which have been acknowledged
This wiki article describes the "alert repository" as a series of interface requirements, and does not describe the mechanism used to store those alerts within implementations.
Use cases of this profile are:
- An ICP which periodically checks patient profiles, in the course of its application logic, discovers that a clinical protocol is not being followed publishes a reminder alert to the attending clinician.
- An administrative service that requires the .
- TODO: Add more use cases here.
Mis-use cases of this profile:
- Any alert which requires "real time" stoppage/modification of a clinical workflow. For example: In the course of prescribing a drug a decision support system discovers the patient has an allergy/intolerance to the prescribed drug.
2. Actors / Transactions
2.1. Use Case Roles
| Actor | Role / Responsibility |
|---|---|
| Alert Publisher | Any actor (ex: a mediator, administrative system, an ICP, etc.) which requires an Alert to be broadcast or targeted within the HIE |
| Alert Consumer | Retrieves alerts for a particular system/provider/patient and is responsible for deactivating (or marking the alert as read). |
| Alert Repository | Responsible for the persistence and maintenance of alerts. |
2.2. Referenced Standards
HL7 Fast Healthcare Interoperability Resource (FHIR) DSTU 0.80
RFC4287 The Atom Syndication Format
RFC2616 IETF Hypertext Transfer Protocol - HTTP/1.1
RFC3986 IETF Uniform Resource Identifier (URI): Generic Syntax
2.3. Interaction Diagram
2.3.1. Alert Repository in the Context of the IL
This profile is intended to express the mechanism of alerting from the perspective of the Alert Publisher, Consumer and Repository. The IL is expected to expose the interface to the Alert Repository and perform any resolution of provider/patient/location identifiers contained within the received alerts prior to conveying them to the Alert Repository.
TODO: Add a sequence diagram showing alerts within the context of the IL
In the context of the IL and OpenHIE, the Alert Repository actor can be equated to the "IL" as the IL would be exposing the interface to its backing repository.
The Alert Consumer in the context of OpenHIE would most likely be an edge system responsible for interpreting the structured alert from the Alert Repository and formatting it appropriately. For example, a clinical EMR system could format the message as an inbox item whereas an SMS package would represent the structured data as a text-message.
2.4. Publish Alert Message
This message represents an HTTP POST from the Alert Publisher actor to the Alert Repository actor containing a profiled FHIR Alert resource.
2.4.1. Trigger Events
When the Alert Publisher actor wishes to make known to Alert Consumer actors, via the Alert Repository, some statement of clinical fact, administrative, or other message.
2.4.2. Message Semantics
The Publish Alert Message is conducted by the Alert Publisher by executing an HTTP POST against the Alert Repository's Alert Resource URL. The URL is formatted as:
http[s]://<authority>/<path>/Alert
This URL is configurable by the Alert Repository and is subject to the following constraints:
- The <authority> shall be represented as a host (either DNS name or IP address) followed optionally by a port.
- The Alert Repository may use the <path> to segregate its implementation of the actor from other REST-based services.
- The <path>, if present, represents the path from which all resources related to a Alert Repository are located (Conformance, Profile, and Alert) and shall not contain a '?'.
2.4.2.1. Content-Type HTTP Header
The Publish Alert Message shall contain a content-type HTTP header, the value of which shall be drawn from Table 2.4.2.1-1 and shall accurately represent the format of the message.
Table 2.4.2.1-1 - Content-Type
| Content-Type | Resource Encoding |
|---|---|
| application/json+fhir | HL7 FHIR JSON representation (see http://hl7.org/implement/standards/fhir/json.html) |
| application/xml+fhir | HL7 FHIR XML representation (see http://hl7.org/implement/standards/fhir/xml.html) |
2.4.2.2. HTTP Payload
The payload of the HTTP request shall be an HL7 FHIR Alert resource (see http://hl7.org/implement/standards/fhir/alert.html) profiled as described in figure 2.3.2.2-1 and table 2.3.2.2-2.
| Resource Definition | Description |
|---|---|
| Alert | The primary alert resource element representing a particular alert (note) about a patient. |
| identifier [1..*] identifier | One or more identifiers which can be used to reference the alert. Note: This has a different cardinality than FHIR |
category [1..1] | Identifies the category of the alert (example: administrative, clinical, etc.). Note: This has a different cardinality and value set binding than FHIR. See XXXX for value set members. |
| status [1..1] code {http://hl7.org/fhir/alert-status} | Identifies the status of the alert. This element is bound to the http://hl7.org/fhir/alert-status value set defined at http://hl7.org/implement/standards/fhir/alert-status.html and shall carry a value of active, inactive or "entered in error". |
subject [1..1] | Identifies the subject (patient) for which the alert applies. |
author [1..1] | Identifies the clinician, patient, or device which was responsible for the authoring of the alert. |
| note [1..1] string | The textual content of the note. |
The Alert Publisher shall include all resources referenced in the subject and author attributes as contained resources (see http://www.hl7.org/implement/standards/fhir/references.html#contained)
2.4.2.2.1 Examples
An example alert published instructing any provider to double check the patient's weight and blood pressure on their next care visit in FHIR JSON:
{
"resourceType": "Alert",
"contained": [
{
"resourceType": "Patient",
"id": "Patient1",
"identifier": [
{
"use": "usual",
"system": "urn:oid:LOCAL IDENTIFIERS OID",
"value": "LOCAL IDENTIFIER"
}
]
},
{
"resourceType": "Device",
"id": "Device1",
"identifier": [
{
"use": "usual",
"system": "urn:oid:OPENHIE DEVICES OID",
"value": "OPENHIE DEVICE ID"
}
],
"type": {
"coding": [
{
"system": "local",
"code": "icp",
"display": "Integrated Care Pathways Workflow Host"
}
],
"text": "ICP Host"
},
"manufacturer" : "OpenHIM",
"model" : "v1.0"
}
],
"text": {
"status": "generated",
"div": "<div><b>From ICP-WHO-304:</b> Patient underweight for this stage of pregnancy, please double check weight next visit"
},
"category": {
"coding": [
{
"system": "local",
"code": "clinical",
"display": "Clinical Alert"
}],
"text": "Clinical Alert"
},
"status": "active",
"subject": {
"reference": "#Patient1",
"display": "Mosa Mengasube"
},
"author": {
"reference": "#Device1",
"display": "OpenHIM ICP"
},
"note": "Patient underweight for this stage of pregnancy, please double check weight next visit"
}
2.4.2.3. Targeting Alerts
The basic FHIR Alert resource may be a generic Alert about the patient (example: "Someone please verify the Patient's address") or, in the context of OpenHIE, may need to be a targeted alert (example: "CHW X, please see patient Y because they haven't had an antenatal care visit in over 6 months"). In order to facilitate the latter use case, OpenHIE's the Alert Publisher may convey an intended recipient of the alert in the extension "Intended Recipient".