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
Dev Environment:
- At least one Subscription capable FHIR endpoint will be provided
- The server will expose Observation Resources of the following types:
- Loinc Code 58941-6
- 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]
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