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

« Previous Version 2 Next »

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

TBD


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.

  • No labels