210901 FHIR Subscriptions

FHIR Subscriptions

All Registration and tracking will be done in the connectathon managment app: http://conman.fhir.org/connectathon.html?event=sanant2019

Dedicated Zulip chat stream for this track.

• Track orientation slides: (TODO)

Previous Subscriptions Connectathons

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

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

R4

Expected participants

Cerner, Jenni Syed & Max Philips

• https://github.com/MaxPhilips/wgm_notes/blob/jan_2019/subscriptions/test_server_faq.md

Roles

FHIR Server

The FHIR Server supports the Subscription resource and notifying subscribed clients of changes.

• Must expose a Subscriptions resource supporting read, create and update.
• Must also act as a 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 specifying a criteria and a channel.type of rest-hook. 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 notifies client

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

Precondition: Create FHIR Subscription scenario

Success Criteria: FHIR server POSTs when the criteria in the Subscription is met within the FHIR server.

Create FHIR Subscription with Authentication (Bonus)

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

Precondition: n/a

Success Criteria: Subscribing client POSTs new subscription resource to FHIR server specifying a criteria and a channel.type of rest-hook. 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.

Server authenticates and notifies client (Bonus)

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

Precondition: Create FHIR Subscription scenario

Success Criteria: FHIR server POSTs when the criteria in the Subscription is met within the FHIR server.

Argonaut Patient Scheduling prefetch

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. Subscription.channel.type is rest-hook and Subscription.channel.payload is application/fhir+json. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.

Notify client of Slot change

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

Precondition: FHIR Subscription created.

Success Criteria: FHIR server POSTs a FHIR Schedule for the modified Slot, to the subscribing client when the criteria is met in the FHIR server.

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

Outcomes

Summary

The activity this Connectathon was heavily weighted towards servers. We had 1 client application built (found here: http://ec2-18-222-237-133.us-east-2.compute.amazonaws.com/subscription/home ). However, we had several people concentrating on learning FHIR for the first time, and wanting to set up Subscriptions. There were 4 groups that were either working on uplifting their previous server to R4, or implementing subscriptions for the first time in their own system so they could learn about it. Many were at their first connectathon as well, and were learning about the community (like Zulip).

Several of the groups involved mentioned that they may continue trying out the activities after the connectathon using the public reference servers.

The general feedback was that the greatest takeaway/benefit was from discussion and questions that happened live at the event, both about Subscriptions and FHIR in general.

Trackers and discussion

• Logged https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=19976 to clarify spec around why having the server alert for changes that fall out of the data set is so complex and may not always be able to be done (eg: security changes/privacy restrictions)
• Discussed a bit about the concerns around "batching up" updates on server or client side. This discussion should continue on zulip for those that have raised this: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Client.20and.20Server.20delays
• Looked to determine if a server should error if the criteria requested aren't acceptable. Looking at the spec, it looks like this would be a 4xx (422?) with an OperationOutcome: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Errors.20with.20criteria