Page History

...

...

2.3. Interaction Diagram 

NB: Alert Repository should read "Alert Manager"

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 RepositoryManager. The IL is expected to expose the interface to the Alert Repository Manager and perform any resolution of provider/patient/location identifiers contained within the received alerts prior to conveying them to the Alert RepositoryManager.

TODO: Add a sequence diagram showing alerts within the context of the IL

In the context of the IL and OpenHIE, the Alert Repository Manager actor can be equated to the "IL" as the IL would be exposing the interface to its backing repositorymanager implementation.

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

...

When the Alert Publisher actor wishes to make known to Alert Consumer actors, via the Alert RepositoryManager, some statement of clinical fact, administrative, or other message.

...

The Publish Alert Message is conducted by the Alert Publisher by executing an HTTP POST against the Alert RepositoryManager's Alert Resource URL. The URL is formatted as:

...

This URL is configurable by the Alert Repository Manager 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 Manager 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 Manager are located (Conformance, Profile, and Alert) and shall not contain a '?'.

...

The basic FHIR Alert resource may be a generic Alert about the patient (example: "Someone please verify the Patient's weight") or, for certain alert types, 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".

...

shall convey any intended recipients of the alert in the extension "intendedRecipient" having extension "url" property of http[s]://<authority>/<path>/Profile/ohie-alert#intendedRecipient. The URL shall point to a valid profile definition hosted by the Alert Manager.

The intendedRecipient extension shall contain a value of type Resource and shall point to a Practitioner, Organization or Patient resource indicating the intended recipient of the alert is a provider of care, an entire organization, or patient respectively. The Alert Publisher shall include the referenced resource as a contained resource.

An example of the intendedRecipient extension is defined below:

{
    "resourceType": "Alert",
    "extension": [
        {
            "url": "http[s]://alert-manager/Profile/ohie-alert#intendedRecipient",
            "valueResource": {
                "reference": "#Recipient1",
                "display": "Christy CHW"
            }
        }
    ],
    "contained": [
        {
            "resourceType" : "Practitioner",
            "id" : "Recipient1",
            "identifier" : [
               {
                "use" : "usual",
                "system" : "urn:oid:LOCAL IDENTIFIERS OID",
                "value" : "LOCAL IDENTIFIER"
               }
            ],
            "telecom" : [ 
               {
                 "system" : "phone",
                 "value" : "+1-203-403-2095",
                 "use" : "work"
               }
            ]
        },
        ...
}

Additionally, the Alert Manager actor shall indicate support for the intendedRecipient extension within a Profile resource as illustrated below:

    "extensionDefn": [
        {
            "code": "intendedRecipient",
            "contextType": "resource",
            "context": ["Alert"],
            "definition": {
                "short" : "Intended recipient of the Alert",
                "formal" : "The practitioner, organization, or patient to whom the alert is specifically addressed",
                "min" : 0,
                "max" : "unbounded",
                "type" : [
                    {
                        "code" : "ResourceReference",
                        "profile" : "http://hl7.org/fhir/profiles/Patient"
                    },
                    {
                        "code": "ResourceReference",
                        "profile": "http://hl7.org/fhir/profiles/Practitioner"
                    },
                    {
                        "code": "ResourceReference",
                        "profile": "http://hl7.org/fhir/profiles/Organization"
                    }
                ]
            }
        }
    ]

2.4.3. Expected Behavior

Upon receiving a Publish Alert Message, the Alert Manager shall persist and/or forward the Alert in some manner appropriate to the particular implementation (for example, storing the resource to a MongoDB or forwarding to another alert service).

The Alert Manager may, if it deems necessary, enrich any details of the contained resource, and may store the resources for access via a fully qualified resource URL (as defined in the FHIR standard).

If the Alert Manager receives a Publish Alert Message formatted in a manner which it does not support (for example, submitting XML to a JSON only service) it shall respond with an HTTP 415 error code. Once the alert has been stored, and/or forwarded the Alert Manager shall respond with an HTTP 200 (OK) message.

The Alert Manager shall respond with an appropriate HTTP level 500 error code (server errors) if it was not able to persist or forward the message (for example, due to invalid message parameters). The error message shall be an HL7 FHIR OperationOutcome resource (see: http://www.hl7.org/implement/standards/fhir/operationoutcome.html) indicating the reason for the fault.

The Alert Manager shall only indicate a successful response if the Alert Manager can guarantee delivery of the received alert (i.e. the Alert Manager shall finish committing data to a persistent store prior to responding with OK).

2.5. Publish Alert Response Message

This message is used to acknowledge a Publish Alert Message and is sent from the Alert Manager to the Alert Publisher actor.

2.5.1. Trigger Events 

The Alert Publisher actor has completed the processing and, in the case of a valid message, persistence of an alert and wishes to convey an acknowledgement.

2.5.2. Message Semantics

The Publish Alert Response Message is an HTTP message containing:

• An HTTP status code (drawn from table 2.5.2-1 )
• A location header indicating the fully qualified URL where the Alert can be retrieved.
• An optional OperationOutcome resource indicating details of the processing
• An appropriate Content-type header indicating the format of the OperationOutcome resource (see Table 2.4.2.1-1)

The behaviors for which the following status codes are generated are listed in section 2.4.3.

Table 2.5.2-1 : Publish Alert Response Message HTTP Status Codes