2022-05 FHIRcast

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.

• Must request subscription to topic and events on hub url.
• Must accept event notification.
• May request context changes.
• Should support websockets as described in the spec. 

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.

Integrated imaging for context sync

The connectathon scenarios below align with Scenario 4.6 in the specification.  It requires a RIS/EHR/Worklist app, an image reading application and a reporting (dictation) application within a single user's session.  Our key checkpoint is successful test of multiple synchronizing apps with a single driving app, the RIS/EHR/Worklist, providing the hub.  Clients may be less mature with the goal of multiple vendor participants simultaneously exchanging content and handling sync errors across a single hub.  

Handle Patient Open Event

:Action: The driving app user in EHR/RIS/Worklist selects an Patient to open.
:Precondition: Image reader app, EHR/RIS/Worklist and reporting (dictation) apps are each successfully connected to the RIS-provided hub and viewing synchronized context.  
:Success Criteria:  The Image reader app and reporting (dictation) apps are each successfully notified of the patient open event.

Handle user logout event

:Action: The user logs out of the EHR/RIS/Worklist application.
:Precondition: Image reader app, EHR/RIS/Worklist and reporting (dictation) apps are each successfully connected to the RIS-provided hub and viewing synchronized context.  
:Success Criteria:  The Image reader app and reporting (dictation) Apps are each successfully notified of user logout.

Handle unsubscribe

:Action: The user normally exits the image reader app.
:Precondition: Image reader app, EHR/RIS/Worklist and reporting (dictation) Apps are each successfully connected to the RIS-provided hub and viewing synchronized context.  
:Success Criteria:  The Image reader app closes.  Hub is notified of unsubscribe.  Future events do not trigger sync errors.

Raise sync error

:Action:  User chooses to close the study or patient in the EHR/RIS/Worklist.  
:Precondition: Image reader app, EHR/RIS/Worklist and reporting (dictation) apps are each successfully connected to the RIS-provided hub and viewing synchronized context.  The user abnormally exits the image reader app.  Since heartbeat does not trigger sync error nothing happens immediately.
:Success Criteria:  Driving app EHR/RIS/Worklist and subscribed reporting (dictation) app each notify the user that the image reader was disconnected 

Common Study Context Established

:Action: The driving app user in EHR/RIS/Worklist selects an ImagingStudy resource to be added to the context. 
:Precondition: Image reader app, EHR/RIS/Worklist and reporting (dictation) Apps are each successfully connected to the RIS-provided hub and viewing synchronized context.  
:Success Criteria:  The DICOM identifiers for this study are conveyed to the image reader and reporting (dictation) apps

Diagnostic Report Update

:Action: Image reader adds a measurement as an observation to a diagnosticReport
:Precondition: Image reader and reporting (dictation) application are both in session with the same version of the same DiagnosticReport resource
:Success Criteria: The RIS/EHR app ignores the updated diagnosticReport event.  The measurement is conveyed to the reporting (dictation) application as a new observation

Diagnostic Report Update Stale Version

:Action: Image reader adds a measurement as an observation to a diagnosticReport
:Precondition: Image reader and reporting (dictation) application are both in session with the different versions of the same DiagnosticReport resource such that the image reading application has an older version than the hub at the time the measurement was captured.   
:Success Criteria: The RIS/Worklist rejects the initial diagnosticReport event.  
:Bonus point: The Image Reader uses getContext to refresh its context to match the hub.  Since this is a new measurement the image reader can resolve the conflict automatically, adding the measurement to the refreshed version of the diagnosticReport.  The measurement is conveyed to the reporting (dictation) application as a new observation