Page tree
Skip to end of metadata
Go to start of metadata

Track overview

Short Description

The FHIR Subscription model has changed a lot since R4 - this track is intended to continue providing feedback and solidify the approach for R5. We'll discuss changes that are needed and any challenges, as well as the approach proposed for "patch back" to R4 with the newer model.

Long Description

This track is an important step in advancing the maturity of the interactions and resources associated with FHIR Subscriptions. Specifically, proposed changes to the Subscription model are coming in to R5 via previous work on this track. Argonaut is also building patch back proposal for these changes, and we would like to prove out the newer model to determine what gaps still exist. This track will focus on RestHooks and WebSockets (or Server Sent Events - some discussion may occur on this topic). 

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

This track will use the draft R5 in the latest CI Build of FHIR: http://build.fhir.org/subscription.html, and http://build.fhir.org/subscriptiontopic.html

Conman: http://conman.clinfhir.com/connectathon.html?event=con25

Type

  • Test the design of a Resource/set of Resources

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

FHIR-I

Argonaut

Proposed Track Lead

Jenni Syed (https://chat.fhir.org/#narrow/pm-with/191356-jenni.syed)  

Related tracks

NA

FHIR Version

  • Current build
  • FHIR R4 (patch back)

Specification(s) this track uses

This track will use the draft R5 in the latest CI Build of FHIR: http://build.fhir.org/subscription.html, and http://build.fhir.org/subscriptiontopic.html

A Subscriptions Framework page has been started at http://build.fhir.org/subscriptions.html to cover high-level concepts.  WIP, but feedback encouraged.

Patch back proposal (R4): http://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/

Artifacts of focus

R5: Subscription, SubscriptionTopic, SubscriptionStatus, and the subscription notification bundle

R4: Backport profiles on Subscription, Parameters, and Basic.

Clinical input requested (if any)

NA

Patient input requested (if any)

NA

Expected participants

Cerner

Microsoft

Epic

... (TODO)

Zulip stream

https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Sept.202020.20Virtual.20Connectathon

Track Orientation

A webinar will be hosted on Tuesday, Sept 1st from 13:00 - 14:00 America/Chicago to share further participation information about this track.

An ics file can be downloaded and saved to your calendar here

Join Microsoft Teams Meeting

+1 816-384-1534   United States, Kansas City (Toll)

Conference ID: 815 427 304#

Local numbers 

Join with a video conferencing device

442901854@t.plcm.vc VTC Conference ID: 1178102898

Alternate VTC dialing instructions

Slides: https://docs.google.com/presentation/d/16TEFhdHldtgC6yp5QhoVZtT41EtzoFd3x1-BAL8R2CM/edit?usp=sharing

Recording: Orientation recording 420p MP4

Track details

System Roles

FHIR Server

The FHIR Server supports the Subscription and SubscriptionTopic resources, as well as notifying subscribed clients of changes.

  • Must expose a Subscription resource supporting read, create and update.
  • Must expose a SubscriptionTopic resource supporting read and search.
  • May expose a SubscriptionTopic create/update.
  • Must also act as a client to send notifications using the new subscription notification bundle.
  • May expose capabilities to use web sockets on the subscription.
  • May be capable of supporting the R4 backport profile.

Subscribing client

Subscribes to FHIR server and gets updates.

  • Should search or read the SubscriptionTopics
  • May support creating its own SubscriptionTopics on a FHIR Server.
  • Must create a Subscriptions instance on external FHIR server.
  • Must expose an endpoint to accept notifications using the new subscription notification bundle.
  • May be capable of using web sockets to receive updates.
  • May be capable of supporting the R4 backport profile.

Scenarios

Create Subscription

Action: A subscribing client creates a Subscription for a SubscriptionTopic on a FHIR server.

Precondition: A SubscriptionTopic must be read from the FHIR server.

Success Criteria: The subscription exists and is in an active status.

Bonus point: If the FHIR server supports it, the client may create its own SubscriptionTopic. The subscribing client may also update the Subscription status to off when it no longer needs the subscription (and server should honor)

Backport: Precondition is a known "shared" SubscriptionTopic URI instead of the SubscriptionTopic resource. R4 Subscription will contain extensions for backport.

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.

Backport: Notification is sent using the R4 Backport Basic approach

Create Subscription with Auth (Bonus)

Action: A subscribing client creates a subscription for a SubscriptionTopic on a FHIR server.

Precondition: A SubscriptionTopic must be read from the FHIR server.

Success Criteria: Subscribing client POSTs new subscription resource to FHIR server specifying a topic, an Authorization header, and a channel.type of rest-hook. FHIR Server persists active subscription resource. Subscribing client can read newly created Subscription.

Bonus point: If the FHIR server supports it, the client may create its own SubscriptionTopic. The subscribing client may also update the Subscription status to off when it no longer needs the subscription (and server should honor)

Backport: Precondition is a known "shared" SubscriptionTopic URI instead of the SubscriptionTopic resource. R4 Subscription will contain extensions for backport.

Rest Hook Notifies Client with Auth (Bonus)

Action: FHIR Server notifies Subscribing client by POSTing to the endpoint identified in the subscription resource instance, including the requested authorization header.

Precondition: Create FHIR Subscription with auth scenario

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

Backport: Notification is sent using the R4 Backport Basic approach

TestScript(s)

NA

Reference Implementation Info

Information Page: https://microsoft-healthcare-madison.github.io/argonaut-subscription-info/

Hosted: http://subscriptions.argo.run

Security and Privacy Considerations

Some scenarios may require an Authentication header to be stored with the subscription and sent with the notification.


Report Out

Summary

While the initial expectation was to continue working on R5, many participants expressed more interest in trial of the Backport IG. Regardless, the goal was to identify any issues or gaps in the existing R5 Subscriptions or R4 Backport IG.

Participants

  • Yazan Al-Alul - Microsoft
  • Avery Allen - Cerner
  • Cary Anderson - Apple
  • Gino Canessa - Microsoft
  • David DeRoode - Lantana Group
  • Grahame Grieve
  • Silas Johnson - Leidos
  • Spencer LaGesse - Epic
  • Ted Peck - InterSystems

Achievements and Scenarios

Most participants focused on the RestHooks aspect of the R5 or R4 backport. No WebSockets or other types of notifications/workflows were covered for this track event.

Yazan Al-Alul (Microsoft - Server)

  • Tested their server using the Argonaut tool.
  • Began upgrade from original R4 to R5 Subscription, took longer than expected
  • Discussing accuracy of the count of notifications since start of subscription and how this fits with architecture

Avery Allen (Cerner - Server)

  • Came in with R5 version and part of the backport to R4
  • Spent a lot of time helping others connect to Cerner server, or fixing bugs
  • Hope to continue backport updates after other issues are resolved
  • Fixed issues in bundle notifications, fixed URLs in entries. Bundle.entry (full), request URL is relative.
  • Started on adding auth

Cary Anderson (Apple - Client)

  • Built an iOS application to work with the backport specification
  • Currently it is able to create subscriptions, continuing work

Gino Canessa (Microsoft - Argonaut and Backport spec)

  • Participating in discussions on Zulip regarding changes and clarifications needed in different versions of spec (or IG)
  • Fixed canonical naming of filed in the Argonaut subscription app/server
  • Other corrections reported throughout the event

David DeRoode (Lantana - Client)

  • Was able to request an R5 subscription on the Cerner server
  • Was able to request an R5 subscription and create a topic on the HAPI server
  • Started work on the backport IG 

Grahame Grieve (fhir.org - Server)

  • Worked on updating test.fhir.org to support the R4 backport
  • Raised questions/issues on Zulip

Silas Johnson (Leidos)

  • Were looking a lot at the QualityMeasures track. Interest in subscriptions for CDC/public health workflows.
    • Implemented the Messaging protocols
  • Raised questions on zulip.

Spencer LaGesse (Epic - Client)

  • Was able to create an R4 backport Subscription on Cerner and Argonaut, and received notification
  • Will continue working on managing the lifecycle of the subscription

Ted Peck (InterSystems - Client)

  • Was able to create a subscription on Cerner server and Argonaut server
  • Received a notification from Cerner and Argonaut. 
  • Delete subscription didn't work on Cerner server (it's not implemented), did work on Argonaut server
  • Update worked on Cerner, didn't work on Argonaut (it's not implemented)
    • Cerner requires if-match header for updates: versions didn't seem to behave great. Note that the server itself updates the status which would affect the version. Not sure about "backwards" issue but the database behind the scenes could have some issues since this is a hackathon version. FHIR states version ordering can't be assumed by clients, just if it's changed, it's different.
  • Initial issues with receiving notifications was due to handshake not working. Resolved.

Issues/Discussions

Now What?

The R4 backport should continue with feedback gained today. In general, there weren't any major issues raised that weren't already raised in R5 as well. We should continue getting implementer feedback on new changes as well to make sure the maturity of core Subscriptions continues to improve for the next release.








  • No labels