September 2015 Connectathon Plans

Owned by Davide Sottara
Last updated: Mar 04, 2020 by Dimitar Dimitrov (Deactivated)
3 min read

Technical Background:

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

  • 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:

  • Subscription FHIR 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 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 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.

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