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 and 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 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 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="http://localhost:8080/bilirubin/onEvent" (note, this URL is relative to the sandbox)
- Subscription Newborn having criteria "Patient" and channel.endpoint="http://localhost:8080/newborn/onEvent" (note, this URL is relative to the sandbox)
- The server will expose Observation Resources of the following types:
- Transcutaneous Bilirubin Loinc Code 58941-6
- The StructureDefinition corresponding to the Observation types will be available here
- [Code : Profile URL TBD] (Travis: We aren't using a profile for this demo)
- 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
Developer's guide
- Participants are encouraged to create new client Applications, e.g. using the HSPC 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