201809 FHIR Subscriptions

FHIR Subscriptions

Dedicated Zulip chat stream for this track.

Previous Subscriptions Connectathons

• 201709 FHIR Subscriptions, September 2017, San Diego, CA
• 201801 FHIR Subscriptions, January 2018

Submitting WG/Project/Implementer Group

FHIR-I

Justification

This track is an important step in advancing the maturity of the interactions and resources associated with FHIR Subscriptions.

The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Jenni Syed

FHIR version

STU3

Expected participants

Cerner, <your name here!>

Roles

FHIR Server

The FHIR Server supports the Subscription resource and pushing relevant FHIR resources to client.

• Must expose a Subscriptions resource supporting read, create and update.
• Must also act as a FHIR client to send notifications.

Subscribing client

Subscribes to FHIR server and gets updates.

• Must create a Subscriptions instance on external FHIR server.
• Must expose an endpoint to accept notifications.

Scenarios

Create FHIR Subscription

Action: Subscribing client creates a Subscription instance on FHIR Server.

Precondition: n/a

Success Criteria: Subscribing client POSTs new subscription resource to FHIR server. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.

Bonus point: Subscribing client updates Subscription instance's status element to _off_ once the subscription is no longer needed. FHIR server respects this setting.

REST Hook with payload of "payload": "application/fhir+json"

Action: FHIR Server notifies Subscribing client by pushing a FHIR resource to the endpoint identified in the subscription resource instance.

Precondition: Create FHIR Subscription scenario

Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server..

Subscribe to Schedule using Argonaut extension

Action: Client subscribes to Schedule per Argonaut Patient Scheduling IG.

Precondition: n/a

Success Criteria: Subscribing client POSTs new subscription resource (including Schedule identifier in _\_criteria_) to FHIR server. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.

Notify client of Slot change

Action: FHIR Server notifies subscribers by pushing a FHIR Schedule resource to the endpoint identified in the subscription, according to Argonaut Patient Scheduling.

Precondition: FHIR Subscription created

Success Criteria: FHIR server pushes FHIR payload of relevant resource using REST Hook when the subscribed event occurs in the FHIR server.

Bonus point: Subscriber subsequently fetches Slots associated with Schedule from notification.

Notes

Please discuss/explore this tracker issue: [1]