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

Introduction

Official URL: http://hl7.org/fhir/uv/fhircast/ImplementationGuide/hl7.fhir.uv.fhircast				Version: 3.0.0-ballot
Draft as of 2024-04-10				Computable Name: FHIRcast

Overview

FHIRcast synchronizes healthcare applications in real time to ensure the user acts on the same clinical information across these applications. For example, a radiologist often works in three disparate applications at the same time (a radiology information system, a PACS and a dictation system), in this case, each of these three systems needs to display the same study or patient at the same time.

FHIRcast isn’t limited to radiology use-cases. Modeled after the common event notification design pattern and specifically WebSub, FHIRcast naturally extends the SMART on FHIR launch protocol to achieve tight integration between disparate, full-featured applications.

FHIRcast builds on the CCOW abstract model to specify an http-based and simple context synchronization specification that doesn’t require a separate context manager. FHIRcast is intended to be both less sophisticated, and more implementer-friendly than CCOW and therefore is not a one-to-one replacement of CCOW, although it solves many of the same problems.

Adopting the WebSub terminology, FHIRcast describes an application as a Subscriber synchronizing with a Hub (which may be an EHR or other system). Any user-facing application can synchronize with FHIRcast. While less common, bidirectional communication between multiple applications is also possible.

Why?

The large number of vendor-specific or proprietary context synchronization methods in production limit the industry’s ability to enhance the very large number of integrations currently in production. In practice, these integrations are decentralized and simple.

How it works and an example scenario

A radiologist working in the reporting system clicks a button to open the dictation system. The dictation app is authorized and subscribes to the radiologist’s session. Each time the radiologist opens a patient’s chart in the reporting system, the dictation app will be notified of the current patient and therefore presents the corresponding patient information on its own UI. The reporting system and dictation app share the same session’s context.

By convention a driving application is the application which opens a context. The driving application could be an EHR, a PACS, a worklist, or any other clinical workflow system. A driving application may or may not launch other applications; to launch other applications the driving application may use the SMART App Launch mechanism. As part of a SMART App Launch, an application requests appropriate FHIRcast OAuth 2.0 scopes and receives the location of the Hub and a unique hub.topic session identifier.

An application subscribes to specific workflow events for the topic during its subscription request. The Hub verifies the subscription then notifies the subscribed application when the requested workflow events occur; for example, by the clinician opening a patient’s chart a Patient-open event would be sent. An application unsubscribes from a topic when it no longer wants to receive notifications. Note that subscribed applications other than the driving application could send a close event for an open context; however, such a scenario may not desirable in many workflows.

Note that:

• Event notifications are thin json wrappers around FHIR resources.
• An application can request context changes by sending an event notification to the Hub’s hub.topic session identifier. The HTTP response status indicates success or failure.
• The Event Catalog documents the workflow events that can be communicated in FHIRcast. Each event will always carry the same type of FHIR resources.

Reading the Specification

Much of this implementation guide is descriptive in how Subscribers and the FHIRcast Hub interact in various scenarios. The normative portion of this implementation guide is contained in Sections 2: Specification, 3: Event Library, and 8: Artifacts. Other portions of the specification are informative and are labeled as such.

Relation to FHIR Subscriptions

FHIRcast is focused on providing notifications when key elements in the context change (i.e., when the current Patient, Encounter, ImagingStudy, etc. is changed). Notable differences in the scenarios addressed by FHIRcast and FHIR Subscriptions:

• FHIRcast is designed to be used by multiple applications perhaps with the same user and typically on the same device - Subscriptions are designed to be used by multiple distinct systems, often outside of a user workflow
• FHIRcast sends only single-event notifications - Subscriptions allow servers to batch multiple notifications in high-frequency scenarios
• FHIRcast is designed around short-lived sessions - Subscriptions are intended to be long-lived resources

Get involved

• Check out our awesome community contributions on github
• Log issues, submit a PR!
• Converse at chat.fhir.org