Carequality Subscription Implementation Guide for Push Notifications
0.1.1 - CI Build
Carequality Subscription Implementation Guide for Push Notifications, published by Carequality. This guide is not an authorized publication; it is the continuous build for version 0.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/Carequality/CEQSubscription/ and changes regularly. See the Directory of published versions
The Carequality Push Notification IG defines specific Actors and Transactions. All transactions require following the security and authentication policies and requirements of the Carequality FHIR Implementation Guide, available at: carequality.org
The Push Notification IG defines 4 Actors:
These Actors have 3 possible transactions:
RegisterSubscription – Push a subscription to the receiver.
1a. UpdateSubscription – As per RegisterSubscription, Push a subscription with changed events to the receiver.
1b. TerminateSubscription – As per RegisterSubscription, Push a subscription with a "delete" event to the receiver.
The Actors work with the Transactions as follows:
Actor | Transactions | Optionality |
---|---|---|
Notification Recipient | RegisterSubscription RetrieveResource NotifyEvent |
R O1 R |
Notification Generator | NotifyEvent RegisterSubscription |
R R |
RecipientSMS | RegisterSubscription RetrieveResource |
R O1 |
GeneratorSMS | NotifyEvent | R |
1 The Notification Recipient and RecipientSMS may or may not fetch the notification's listed Resource depending on business requirements.
The Notification Recipient or RecipientSMS creates the Subscription resource. The Subscription resource contains the canonical URL that represents the events that the Notification Recipient wishes to subscribe to and the Patient identifier or Patient ResourceID in addition to other business information.
The Subscription.criteria element is formatted as a simple Patient search string using either Patient?id=<identifier>
or Patient?identifer=<MRN>
. This is to allow for compliance with current FHIR R4 requirements.
The Notification Generator creates the Event and either requests the GeneratorSMS to notify the receiver or sends the notification to the receiver directly, depending on business requirements.
A notification consists of a history bundle sent to the endpoint listed in the Subscription. This notification can activate the RetrieveResource transaction depending on the policy and procedures of the receiving organization.
The Notification bundle contains a minimum of two entries, the Subscription Status profile and one or more resources that contain the information about the clinical event. The Subscription Status profile also includes a count of notifications to date, allowing for missed notification tracking.
This Bundle is sent to the endpoint specified in the Subscription resource that was POSTed to the Notification Generator e.g.,
http://www.example.org/fhir/subscription/sub123
Once notified via the NotifyEvent transaction the Notification Recipient/RecipientSMS can retrieve additional Resources and internalize them as dictated by business processes.