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

Connectathon Agenda

Please refer to the HL7 Whova Event App for agenda.

Submitting WG/Project/Implementer Group: Infrastructure & Messaging, Imaging Integration

Justification and Objectives

FHIRcast provides modern, simple, application context synchronization. We're working within the RIS/PACS community and beyond to standardize FHIRcast as the common, lightweight standard. We are finishing ballot resolution for our STU2 ballot. This connectathon is important to support basic connectivity and testing of the STU2 spec and to explore how to enable exchange of discrete, draft, image measurements.

This track will prototype this workflow synchronization with FHIR as the underlying content data model according to the specification: https://fhircast.org

This track will use any version of FHIR.

Related tracks

Subscriptions (for websockets?)

Proposed Track Lead

Isaac Vetter - isaac@epic.com

Expected participants

Expecting around 6 or so participants. 

Track Orientation

A webinar will be hosted on Tuesday, August 25h at 9am Central to share further participation information about this track.

Meeting number (access code): 133 542 5903

Meeting password: qJmpJ7qUY33 


Tap to join from a mobile device (attendees only) 
+1-404-397-1525,,1335425903## US Toll 
+1-877-309-8689,,1335425903## US Toll Free 

Join by phone 
+1-404-397-1525 US Toll 
+1-877-309-8689 US Toll Free 
Global call-in numbers  |  Toll-free calling restrictions  
 
Join from a video system or application
Dial 1335425903@epic.webex.com 
You can also dial 173.243.2.68 and enter your meeting number.  

Questions, help and chat on zulip!

https://chat.fhir.org/#narrow/stream/179271-FHIRcast/topic/Sept.202020.20FHIRcast.20virtual.20connectathon


System Roles

Checkout our reference implementation and other opensource FHIRcast projects at: https://github.com/fhircast .

Hub

The Hub manages users' sessions, accepts subscriptions, is responsible for notifications and is closely aligned with the SMART server and FHIR server.

  • Must accept new subscriptions.
  • Must verify subscribed callback urls.
  • Must accept context change requests from subscribers.
  • Should support websockets as described in the spec. 
  • May POST notifications to subscribed callback urls.

Subscriber

Subscribes to a user's session topic on the hub, receives and processes event notifications.

Basic Scenarios

Subscriber creates new subscription; hub respond with 202

:Action: Subscriber POSTs WebSub subscription request to hub for a specific hub.topic and hub.events.
:Precondition: Subscriber must know hub base url, hub.topic (session identifier) and supported events. Use ''Patient.open'', ''Patient.close'' for events for Connectathon.
:Success Criteria: Hub persists subscription.
:Bonus point: Subscribe via websocket.

Subscriber is notified of user session change per subscription

:Action: Hub/Publisher POSTs notification to subscriber for a subscribed event and topic/session.
:Precondition: Subscriber subscribes correctly, see previous scenario.
:Success Criteria: Subscriber responds with 2xx code.
:Bonus point: Notify client  via established websocket connection.

Subscriber requests user session change 

:Action: Subscriber POSTs context change request to Hub's topic url.
:Precondition: Subscriber subscribes correctly, see initial scenario.
:Success Criteria: Hub responds with 2xx code.
:Bonus point: Hub accepts context change and broadcasts corresponding notification.
:Bonus point: Hub rejects context change and subscriber handles synchronization failure.

Subscriber is notified of topic/session id, hub url during SMART app EHR launch from Hub

:Action: Subscribing client launches from Hub, according to SMART EHR launch.
:Precondition: n/a
:Success Criteria: Subscriber requests fhircast scope and receives hub base url and hub.topic in SMART launch and performs scenario #1.

Subscriber is notified of topic/session id, hub url during SMART app standalone launch

:Action: Subscribing client initiates SMART standalone launch using Hub's OAuth2 server, according to SMART EHR launch.
:Precondition: n/a
:Success Criteria: Subscriber requests fhircast scope and receives hub base url and hub.topic in SMART launch and performs scenario #1.
:Bonus point: Subscriber evaluates multiple returned sessions and chooses between them.

DiagnosticReport Context with Information Sharing Scenarios

Subscriber requests diagnostic report open 

:Action: Subscriber POSTs DiagnosticReport-open request to Hub's topic url.
:Precondition: Subscriber subscribes correctly, see initial Basic Scenario including subscription to DiagnosticReport-open events
:Success Criteria: Hub responds with 2xx code.
:Bonus point: Hub accepts DiagnosticReport-open request with any necessary context change and broadcasts corresponding notification.
:Bonus point: Hub rejects context change and subscriber handles synchronization failure.
See DiagnosticReport-open Request

Subscriber is notified of diagnostic report open per subscription

:Action: Hub pushes a notification to subscriber for a subscribed event and topic/session.
:Precondition: Subscriber subscribes correctly, see initial Basic Scenario including subscription to DiagnosticReport-open events
:Success Criteria: Subscriber responds with 2xx code.
:Bonus point: Notify client via established WebSocket connection
See DiagnosticReport-open Event

Subscriber communicates a new discrete, draft measurement via FHIRcast

:Action: Subscriber POSTs ''DiagnosticReport-update'' change request to Hub's topic url
:Precondition: Subscriber subscribes correctly, see initial Basic Scenario including subscription to DiagnosticReport-update events to a topic in which a context of a diagnostic report has already been established
:Success Criteria: Hub responds with 2xx code.
:Bonus point: Hub accepts context change and broadcasts corresponding notification.
See DiagnosticReport-update Request #1
See DiagnosticReport-update Request #2

Subscriber is notified of a new discrete, draft measurement via FHIRcast

:Action: Hub pushes a notification to subscriber for a subscribed event and topic/session.
:Precondition: Subscriber subscribes correctly, see initial Basic Scenario including subscription to DiagnosticReport-update events
:Success Criteria: Subscriber responds with 2xx code.
:Bonus point: Notify client via established WebSocket connection
See DiagnosticReport-update Event #1
See DiagnosticReport-update Event #2

Subscriber requests to close the diagnostic report context and the Hub distributes the close event

:Action: Hub pushes a notification to subscriber for a subscribed event and topic/session.
:Precondition: Subscriber subscribes correctly, see initial Basic Scenario including subscription to DiagnosticReport-update and DiagnosticReport-close events
:Success Criteria: Subscriber responds with 2xx code.
:Bonus point: Notify client via established WebSocket connection
See DiagnosticReport-close Request/Event


Track Report Out

Summary

As FHIRcast's STU2 ballot reconciliation wraps up, our goals for this connectathon were to implement and test this newer version of the specification, with an emphasis on websockets, but also to work towards defining possible future enhancements. 

Participants:

  • Bas van den Heuval - Phillips Research
  • Catie Ladd - Nuance
  • Endre Berki - Siemens Healthineers
  • George Kustas - Nuance
  • Isaac Vetter - Epic
  • Juan Arzac - University of Michigan, College of Pharmacy
  • Niklas Svenzen - Sectra
  • Stanislav Melnikov - Smart Reporting GMBH
  • Will Maethner - Epic

Implementers & Notable Achievements

Across six different organizations, we tested three distinct hubs and five distinct FHIRcast clients. The number and depth of implementations and our strikingly intelligent and good-looking group of implementers are our notable achievement. Most implementers brought their existing implementations and focused on the basic context synchronization scenarios.

Specifically:

  • Bas' Phillips Research Hub was successfully integrated with: Juan's University of Michigan FHIRcast client, Stanislav's Smart Reporting Gmbh client, Niklas' Sectra client, Endre's Siemens Healthineer's client, and Bas' Phillips Research client. 
  • George and Catie's Nuance FHIRcast Hub was successfully integrated with: Bas' Phillips Research client, Juan's University of Michigan FHIRcast client, Stanislav's Smart Reporting Gmbh client, Endre's Siemens Healthineer's client and George and Catie's Nuance client.
  • Endre's Siemens Healthineers' FHIR cast was successfully integrated with: Juan's University of Michigan FHIRcast client, Stanislav's Smart Reporting Gmbh client, and Endre's Siemens Healthineer's client.

Nuance was able to rapidly add intent verification into their websocket subscription flow. 


Issues & Problems discovered

  • Connectathon timezones: FHIRcast is a truly international specification with strong, consistent participation from multiple northern european counties as well as the United States. This track observed the Eastern US timezone, with some concessions to Central European Time. This 6+ hour time difference negatively impacted European participants by either forcing them to work late into the night or limiting their participation. 
  • How to communicate websocket endpoints?  Upon creating a subscription of type websocket, the Hub replies to an HTTP request with a wss url to which the client subsequently connects to receive event notifications. Previously, the FHIRcast Hub returned this wss url in the Content-Location HTTP header. We figured out that .Net's stock HttpClient class tries to follow this "redirect" insted of treating it as data. We moved the location of this wss endpoint from the HTTP header into a small json object in the HTTP body to better enable implementers to use off the shelf libraries. For background, see github PR's #303 and #333.
  • STU2 not yet published: STU2 ballot comment reconciliation is continuing. This means that implementers don't have an entirely stable target. 
  • Not yet consensus on "content synchronization": One of the potential goals for this track was to test an advanced proposal and implementation share by Nuance. George shared a functional demonstration of this proposal, and Bas presented a sketch of an alternate design (see slides, below). Continued work is necessary to standardize broad, interoperable support for the exchange of advanced context/content in a FHIRcast integration.

Now what?

The FHIRcast project is on the cusp of production adoption of the almost finalized STU2 specification.  The project is healthy and moving forward, albeit slowly. Before the end of the year, we must finalize ballot comment reconciliation and begin the HL7 publishing process for STU2. Longer term, we need to determine if and how "content synchronization" fits into FHIRcast. Content synchronization, and specifically, draft image measurement exchange within the imaging integration space, is important with maturing, but not entirely standards-based implementations. 

George's DiagnosticReport-update specification

https://chat.fhir.org/user_uploads/10155/tq_WA9t2YMsIOqMnsiooXEhU/DiagnosticReport-Update.pdf

Bas' content sharing design sketch. 


  • No labels