FHIRcast logo

FHIRcast
3.0.0-ballot - STU 3 Ballot International flag

FHIRcast, published by HL7 International / Infrastructure And Messaging. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhircast-docs/ and changes regularly. See the Directory of published versions

Specification Information

Revision History

All changes to the FHIRcast specification are tracked in the specification’s HL7 github repository. Further, issues may be submitted and are tracked in jira or (historically as) github issues. For the reader’s convenience, the below table additionally lists significant changes to the specification.

20200715 Significant changes as part of the STU2 publication included:

  • Introduction of WebSockets as the preferred communication mechanism over webhooks.
  • Creation of a FHIR CapabilityStatement extension to support Hub capability discovery.
  • Additional, required information on SyncError OperationOutcome (namely communication of the error’d event’s id and event name).
  • Websocket WSS URL communicated in HTTP body, instead of Content-Location HTTP header.
  • Subscribers should differentiate between immediately applied context changes and mere successfully received notifications with HTTP code responses of 200 and 202, respectively.

20240401 Change Log STU2 to STU3

Spec format moved to FHIR Implementation Guide

FHIRcast STU2 was the last version of FHIRcast published with our bespoke mkdocs publication pipeline. STU3 and beyond will be published as proper FHIR IGs, including the use of FHIR profiles.

New events added to event library

  • home-open
  • heartbeat
  • encounter-open
  • encounter-close
  • imagingstudy-open
  • imagingstudy-close
  • diagnosticreport-open
  • diagnosticreport-close
  • diagnosticreport-update
  • diagnosticreport-select

Get Current Context RESTful API is added as optional

The Get Current Context API was added to the specification.

FHIRcast starts to become a “base specification”

With the addition of update and select events, the scope of the FHIRcast specification significantly increases beyond context synchronization. In part this has lead to this FHIRcast publication specifying capabilities which require additional specification to be applied to specific interoperability use-cases.

Changes to Context Synchronization

Remove webhook channel

In STU1 and STU2, FHIRcast supported a webhook channel (URL callbacks). As part of FHIRcast STU3, support for webhooks was removed in favor of websockets as the single communication method. The field hub.channel.type was used to indicate the channel type to use for event notification. This field has been retained in order to support backward compatibility as well as facilitate potentially adding new channels in the future. Similarly, the conformance statement related to WebSocketsupport was retained.

New context synchronization events

  • home-open
  • encounter-open
  • encounter-close
  • heartbeat

Hub Generated open events

Significant complexity is created if/when subscribers support subsets of the FHIRcast context synchronization events used during a context synchronization session. If a hub permits subscribers to subscribe to subsets of one another’s events, the hub is required to “generate” or “derive open events. This is required in the specification of Event Notifications and discussed in Multi-anchor considerations

update events (aka Content Sharing)

STU3 introduces the concept of content sharing.

select events

STU3 introduces the (experimental) concept of selection.

Questions to implementers

Scattered througout the FHIRcast specification are the questions to implementers, the following hyperlink directly to them:

FHIR Publication Details

Intellectual Property Statements

This publication includes IP covered under the following statements.

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.uv.fhircast.r4) and R4B (hl7.fhir.uv.fhircast.r4b) are available.

Package Dependencies

Package hl7.fhir.uv.extensions.r4#1.0.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.ipa#1.0.0

This IG describes how an application acting on behalf of a patient can access information about the patient from an clinical records system using a FHIR based API. The clinical records system may be supporting a clinical care provider (e.g. a hospital, or a general practitioner), or a health data exchange, including a national health record system. (built Sun, Mar 26, 2023 20:50+0000+00:00)

Global Profile Definitions

There are no Global profiles defined