...
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
TBDScenarios.
- 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]
...
Participants can also implement the server side, or extend their existing FHIR server implementations,
to 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