Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

TBD


Dev Environment:

At least one Subscription capable FHIR endpoint will be provided
-- [FHIR EP TBD]
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 will be updated randomly
-- [Test Patient 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.

  • No labels