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  
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 CaseTBD

Scenarios

• It is recommended that the level of Bilirubin should be checked in newborn babies.
  A monitoring agent is set up to ensure that newborns receive at least one reading within 12 hours from their birth.
  
  
• Abnormal bilirubin values may lead to severe complications, so an alerting agent will be responsible to deliver notifications
  to the appropriate actors.
  
  

Proof of concept specification

• A manager application (not implemented) embodies an institution's policies. It configures Subscription resources to monitor for
  • 1) new 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 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 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 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 providedTBD : FHIR endpointFHIR endpoint
  • https://hspc.isalusconsulting.com/dstu2/open-hsp-reference-api/data/Subscription
  • Subscription resources
    • Subscription Bilirubin having criteria "Observation?code=58941-6" and channel.endpoint="https://hspc.isalusconsulting.com/hsp-bilirubin-monitor/bilirubin/onEvent"
    • Subscription Newborn having criteria "Patient" and channel.endpoint="https://hspc.isalusconsulting.com/hsp-bilirubin-monitor/newborn/onEvent"
      • 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:
  • [Obs Type Codes TBD]
  • The StructureDefinition corresponding to the Observation types will be available here
    • [Code : Profile URL TBD]
• 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
  • -- [Test Patient ID TBD]
• 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  to support Subscription resources.

To be valuable, the server should contain - and allow to create/update - instances of the observations relevant to the proposed scenarios