201801 FHIR Subscriptions

FHIR Subscriptions

Dedicated Zulip chat stream for this track.

• FHIR Subscriptions Track Orientation Slides

Previous Care Plan Connectathons

• 201709 FHIR Subscriptions, September 2017, San Diego, CA

Submitting WG/Project/Implementer Group

Imaging Integration, FHIR-I, CDS

Justification

The Imaging Integration is sponsoring a project to create a new context synchronization profile using FHIR Subscriptions called FHIRcast (FHIR-I and CDS are co-sponsors).

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

The subscription pub/sub pattern enables FHIR clients to retrieve data from a server without performing a more expensive periodic polling queries. This model also enables workflow event-based notifications that could keep two applications data in sync, but also synchronize their context. We're working within the RIS/PACS community to identify a common, lightweight application synchronization standard.

This track will attempt to prototype this event-based concept on top of the existing FHIR Subscription REST hook and criteria element and prototype this workflow synchronization using FHIR Subscriptions according to the draft FHIRcast specification.

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

Isaac Vetter

FHIR version

STU3

Expected participants

Agfa, Applicadia, Epic, Sectra

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 using the topic extension, as illustrated, below.

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..

Bonus point: n/a

FHIRcast

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

Precondition: Previous two scenarios; FHIR Server publishes workflow-type EventDefinition named "patient-chart-open" as described by FHIRcast.

Success Criteria: FHIR server pushes UserSession using REST Hook when the subscribed event occurs in the FHIR server. Subscribing client changes its UI to match the patient-chart-open event.

Bonus point: FHIR Server detects error scenario and reacts according to its own configuration.