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.
- Newborn patient, a fresh Patient resource is created. The record is populated with Bilirubin Observations as they are taken
xx A stream of relevant new Observations - Later on, more Observation are created, some of which are not Bilirubin types.
Or
Some of which are Bilirubins, but do not match the exact criteria (e.g. transcutaneous vs ...)
xx A stream of relevant new Observations interleaved with non-relevant ones
Optionally:
- A nurse detects an error in one of the reports, so one of the Observations needs to be corrected (updated).
The correction may or may not make the Observation relevant
xx The Subscription mechanism will be demonstrated with updates too
Dev Environment:
- At least one Subscription capable FHIR endpoint will be provided
- TBD : FHIR endpoint
- 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]
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