This page is part of the FHIRcast (v3.0.0-ballot: STU3 (v3.0.0) Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions

FHIRcast Specification

This chapter consists of the following sections:

2.1 Session Discovery

2.2 FHIRcast Scopes

2.3 Event Format

2.4 Subscribing to Events

2.5 Event Notification

2.6 Request Context Change

2.7 Conformance

2.8 Extensions

2.9 Get Current Context

2.10 Content Sharing

The FHIRcast specification describes the APIs used by disparate healthcare applications to synchronize user interfaces (UI) in real time; allowing them to show the same clinical context and content to a user.

Once an application knows about the session (Hub topic), the application subscribes to specific workflow-related events for the given session. The application is then notified when those workflow-related events occur; for example, when the clinician opens a patient’s chart in another application subscribed to the same session. A Subscriber may also initiate context changes by accessing APIs defined in this specification; for example, closing the patient’s chart. A Subscriber unsubscribes from the session to no longer receive session events. The notification events describing the workflow event are defined as a simple JSON wrapper around one or more FHIR resources.

FHIRcast recommends the HL7 SMART on FHIR launch protocol for both session discovery and API authentication. FHIRcast enables a Subscriber to receive notifications over a WebSocket connection. This protocol is modeled on the W3C WebSub RFC, such as its use of GET vs POST interactions and a Hub for managing subscriptions. The Hub exposes APIs for subscribing and unsubscribing, requesting context changes, sharing content, and distributing event notifications. The flow diagram presented below illustrates the series of interactions specified by FHIRcast, their origination, and their outcome.

All data exchanged through the HTTP APIs SHALL be formatted, sent, and received as JSON structures (unless otherwise specified), and SHALL be transmitted over channels secured using the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS), also known as HTTPS which is defined in RFC2818.

All data exchanged through WebSockets SHALL be formatted, sent, and received as JSON structures, and SHALL be transmitted over Secure Web Sockets (WSS) as defined in RFC6455.