Page Comparison

...

The Subscription Resource is used by a Client App to manifest interest in a particular (sub)class of Resources.

When a Subscription is POSTed and processed by an enabled FHIR server, it allows to define selection criteria and a callback endpoint. 
Whenever a Resource matching the criteria is created or updated, a callback is pushed.
The callback may be a simple notification, or contain a (filtered) copy of the Resource that triggered the notification.

Clinical Use Case

Scenarios

...

• A manager application (not implemented) embodies an institution's policies. It configures Subscription resources to monitor for
  • 1) new
  Patients and
  • Patients 
  • 2) new Bilirubin observations. 
  As a new Patient is detected, the active monitor is notified. The monitor watches for Bilirubin observations for that patient and,
   in case none is detected within a 12 hour period, it sends an email notification to a relevant actor.

• The same manager application (not implemented) tries to enforce enforces a business rule, stating that abnormal Bilirubin readings should
  result into a notification being sent. The manager prepares a subscription criteria and embeds it into a Subscription resource, posted
  at posted at the appropriate endpoint.
  When an abnormal reading (e.g. > 12) is detected, a notification is sent to an alerting agent application. This application is responsible
  for responsible for managing the interaction with the healthcare provider, ensuring that the potential anomaly is appropriately cared for. 

Dev Environment:

• At least one Subscription capable FHIR endpoint will be provided
  • https://hspc.isalusconsulting.com/dstu2/open-hsp-reference-api/data/Subscription
  • Subscription resources
    • Subscription Bilirubin having criteria "Observation?code=58941-6" and channel.endpoint="httphttps:///localhost:8080hspc.isalusconsulting.com/hsp-bilirubin-monitor/bilirubin/onEvent" (note, this URL is relative to the sandbox)
    • Subscription Newborn having criteria "Patient" and channel.endpoint="httphttps://localhost:8080hspc.isalusconsulting.com/hsp-bilirubin-monitor/newborn/onEvent" (note, this URL is relative to the sandbox)
      • Note that these channel endpoints are external to the FHIR resource server and use the SMART on FHIR Backend Service architecture style
• The server will expose Observation Resources of the following types:
  • Transcutaneous Bilirubin Loinc Code 58941-6
• New resources of the given types will be generated randomly for a test patient. Likewise, existing resources in the patient's record will be updated randomly
  • Patient resource having a birth date/time of 11 hours 58 minutes in the past
  • Bilirubin Observation resources
    • Observation 1 having value = 11.0
    • Observation 2 having value = 10.7
    • Observation 3 having value = 14
    • Observation 4 having value = 10.7
• endpoints for Patient and Observation resources:
  • https://hspc.isalusconsulting.com/dstu2/open-hsp-reference-api/data/Patient/{id}
  • https://hspc.isalusconsulting.com/dstu2/open-hsp-reference-api/data/Observation/{id}
• The server will send an alert notification for newborn patients that have not had a Bilirubin observation within the first 12 hours of life
  • Note that "age < 12 hours" is not a supported FHIR criteria.
• The server will send an alert notification for an observation those value exceeds the threshold (12.0 for demo purposes)

Developer's guide

• Participants are encouraged to create new client Applications, e.g. using the HSPC the Logica Java Client, or to extend the provided reference application skeleton, based on a stripped version of the  "Bilirubin chart" application.
  -- [TBD Provide test application]
• The application will instantiate Subscription Resources and POST them to the FHIR server. The server will understand Subscription criteria based on Resource type and name.  
  A Subscription to Observations using one or more of the codes above will eventually result in callbacks being issued.
• The server will support e-mail and FHIR endpoint callbacks. Applications are encouraged to implement the FHIR endpoint, so to receive a copy of the new Resource(s) using a push-like mechanism
• Developers should compare such "reactive" applications with more traditional applications that rely on a pull mechanism.
• On a callback, applications are encouraged to validate the newly delivered resource(s) using the StructureDefinitions
  More information on how to validate a resource can be found here 
  -- [TBD link to the wiki]

...

Server Developer's Guide

Participants can also implement the server side, or extend their existing FHIR server implementations, to support Subscription resources.

...