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

Actors and Transactions

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

Actors

The Push Notification IG defines 4 Actors:

  1. Notification Recipient – the actor who requests the subscription.
  2. Notification Generator – the actor who responds to the subscription requests based on events.
  3. RecipientSMS (Subscription Management Service) the actor who is an aggregator that may have a Record Locator Service and may act as a Recipient on behalf of the Notification Recipient and forward the notifications to the Notification Recipient.
  4. GeneratorSMS (Data Source Subscription Management Service) the actor who may act as an aggregator for one or more Notification Generators and send the notifications to the Notification Recipient.

Transactions

These Actors have 3 possible transactions:

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

  2. NotifyEvent – Push a notification bundle.
  3. RetrieveResource – Retrieve Resource included in the bundle – outside of scope for the this IG and subject to the Carequality FHIR Implementation Guide, available at carequality.org. Included for completeness.

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.

RegisterSubscription

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.

NotifyEvent

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

RetrieveResource

Once notified via the NotifyEvent transaction the Notification Recipient/RecipientSMS can retrieve additional Resources and internalize them as dictated by business processes.