Page History

...

NB: Alert Repository should read "Alert Manager"

2.3.1. Alert

...

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

...

This message represents an HTTP POST from the Alert Publisher actor to the Alert Repository Manager actor containing a profiled FHIR Alert resource.

...

{
    "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 MengasubeM."
    },
    "author": {
        "reference": "#Device1",
        "display": "OpenHIM ICP"
    },
    "note": "Patient underweight for this stage of pregnancy, please double check weight next visit"
}

...

 2.6. Query Alerts Message

This message represents an HTTP GET from the Alert Consumer actor to the Alert Manager actor for the purpose of querying for applicable Alerts.

2.6.1. Trigger Events 

When the Alert Consumer actor wishes to query for all known patient Alerts, it queries the Alert Manager.

2.6.2. Message Semantics

The Query Alert Message is conducted by the Alert Consumer by executing an HTTP GET against the Alert Manager's Alert Resource URL. The URL is formatted as:

http[s]://<authority>/<path>/Alert?<query>&format=<formatId>

This URL is configurable by the Alert 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 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 Manager are located (Conformance, Profile, and Alert) and shall not contain a '?'.
• The <query> represents a series of encoded name-value pairs representing the filter for the query specified in 2.6.2.1 as well as control parameters to modify the behavior of the Alert Manager such as response format.

2.6.2.1. Query Parameters

The Alert Consumer may supply and the Alert Manager shall be capable of processing all query parameters listed below. All query parameters should be appropriately encoded using RFC3986 percent encoding rules. Alert Managers may expose additional query parameters which fulfill site specific requirements, however these are out of scope for this resource profile.

_id Query Parameter

The _id query parameter can be used to query for an Alert having a specific resource identifier matching the specified value. This identifier is the local identifier assigned by the Alert Manager.

creationTime Parameter

The creationTime parameter filters results based on the time that the Alert was created in the Alert Manager. The Alert Manager shall, at minimum, support exact and interval matches (defined by FHIR date query parameters at http://hl7.org/implement/standards/fhir/search.html#date) and may support other types of date matching.

identifier Query Parameter

The identifier query parameter filters results based on one or more of the identifiers supplied in the Alert resource and may be used to find a specific instance of an Alert by identifier.

subject.identifier Query Parameter

The subject.identifier parameter filters results based on the identifier of the subject (or patient) for which the alert pertains. This can be used to find all alerts which belong to a particular patient and is of type token. For example, to find all Alerts related to a patient having a US social security identifier of 123456789 the query parameter would be represented as:

?subject.identifier=urn:oid:2.16.840.1.113883.4.1|123456789

author.identifier Query Parameter

The author.identifier parameter filters results based on the identifier of the author (device, patient or practitioner) which created the Alert. This can be used to find all alerts created by a particular actor and is represented as a token query parameter.

intendedRecipient.identifier Query Parameter

The intendedRecipient.identifier parameter filters results based on the identifier of the recipient to which the alert is addressed.

2.6.2.2. Populating Desired Response Format

The FHIR standard provides encodings for responses in either XML or JSON. Actors are expected to support either format, and the Alert Consumer actor shall indicate a desired response encoding vial the _format query parameter.

Table 2.6.2.2-1 - Desired Response Encoding

2.6.3. Expected Behavior

The Alert Manager shall return all alerts matching the query parameters supplied by the Alert Consumer. The Alert Manager shall respond to the query synchronously (i.e. on the same connection as was used to initiate the request). The Alert Manager shall bundle the matching Alerts within a FHIR Resource Bundle (see: http://www.hl7.org/implement/standards/fhir/extras.html#bundle) and shall return these results to the Alert Consumer actor.

If no Alerts were found matching the specified criteria, then the Alert Manager shall return a FHIR Resource Bundle with no matches.

If the Alert Manager was incapable of processing one of the query parameters supplied to it, it shall return an HTTP 400 (bad request) error and convey the parameter in error via an OperationOutcome Resource.