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