201809 FHIR Subscriptions

FHIR Subscriptions

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

Dedicated Zulip chat stream for this track.

• Track orientation slides: https://docs.google.com/presentation/d/1Qh8ZxVJ6aIelYhklz1y-agPXpzohc9MNiOVOIU_w4Sc/edit?usp=sharing

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

R4 (September 2018 Ballot): http://hl7.org/fhir/2018Sep/subscription.html

Expected participants

Cerner, Jenni Syed & Max Philips

• https://github.com/MaxPhilips/wgm_sept_2018_notes/blob/subscription/subscription/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.

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.

Notes

Please discuss/explore this tracker issue: [1]

Outcomes

Participants

• David Barnet (NHS Digital)
• Naresh Jaganathan (Aegis)
• Max Philips (Cerner)
• Brian Reinhold (Lamprey)
• Jenni Syed (Cerner)
• Ben Winters (Mayo Clinic)

Observers

• Richard Ettema
• Roland Hartich
• Aleksandr Ivanov
• Christiaan Knaap
• Christopher Kundra
• Sagy Mintz
• John Moehrke
• Michele Mottini
• John Rhoads
• Cooper Thompson
• Isaac Vetter
• Abigail Watson

Achievements

The biggest outcome came from discussion and learning. For example, we discussed benefits of using compartments to enable population monitoring, and the backing FHIR concepts that exist to support this (eg: _list). General discussion of security and challenges around this as well which covered both permissions and data access (right provider, right data) as well as web security challenges that the subscription model may present. There were use cases brought up that we hadn't discussed before including EpisodeOfCare monitoring (and all the resources relating to them) and how servers need to handle Subscriptions that include references to sets that may change (_list, code:in type queries). Finally, the discussion around what a server should do when it can't immediately process a subscription to indicate this to scenario to a subscriber.

We had participants that were able to test against a FHIR server, set up a mock environment based around MSMQ that helped visualize what challenges a real system would face, and a server that was receiving updates from devices to trigger subscription notifications.

Issues

We discussed several issues or challenges during this connectathon:

• Detecting data that no longer qualifies for a subscription
• Validation of subscription: realtime vs. delayed
• GForge 14646 discussed a bit
• Logged GForge 18990 to suggest removing Subscription.tag and suggest use of CommunicationRequest/Communication (or other) for this type of need.
• Logged GForge 18991 to clarify payload value set (make a value set instead of a string) and possibly add an invariant around email/SMS.
• Logged GForge 18992 that is somewhat related to above, but allowing SMS and EMail subscribers to provide some default text to be sent with the notification.
• Logged GForge 18993 to address subscriber-side security concerns and impacts that could have to the FHIR server they're subscribed to.
• Logged GForge 18994 to suggest adding more detail and concerns to the security section of the Subscription resource.

Now What

The 3 ongoing zulip discussions need to be tracked and have trackers logged with conclusions (or have trackers updated for the case of 14646). Need to watch and discuss other trackers as necessary. We also recommend indicating that the SMS, Email, and (perhaps) Messaging sections have had less feedback than the Hook and WebSocket sections. We didn't have anyone at the table that did SMS and Email, and only one that was tangentially thinking about the messaging aspect.