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

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:

• 2-4-Subscribing.html#current-context-notification-upon-successful-subscription
• 2-5-EventNotification.html#hub-generated-syncerror-events
• 2-9-GetCurrentContext.html#get-current-context
• 3-2-2-Heartbeat.html#heartbeat-event
• 4-1-launch-scenarios.html#dynamic-registration-for-native-apps-following-smart-launch-parent-application-registers-dynamic-application-which-participates-in-fhircast-session
• 4-5-multi-anchor-considerations.html#hub-derives-open-events
• 4-5-multi-anchor-considerations.html#hub-may-or-may-not-derive-close-events

FHIR Publication Details

Intellectual Property Statements

This publication includes IP covered under the following statements.

• Copyright 2014 – The Radiological Society of North America (RSNA), all rights reserved. Licensed under RadLex License Version 2.0. You may obtain a copy of the license at: http://www.rsna.org/radlexdownloads/This work is distributed under the above noted license on an “AS IS” basis, WITHOUT WARRANTIES OF ANY KIND, either express or implied. Please see the license for complete terms and conditions.Subject to the terms and conditions of this Agreement, Licensor hereby grants to You a worldwide, non-exclusive, no-charge, royalty-free copyright license to reproduce, prepare Adaptations of, publicly display, publicly perform, sublicense, and distribute the Work and such Adaptations in any medium.RadLex is licensed freely for commercial and non-commercial users. Review and download the license: http://www.rsna.org/uploadedFiles/RSNA/Content/Informatics/RadLex_License_Agreement_and_Terms_of_Use_V2_Final.pdf
  Show Usage
  • RadLex radiology lexicon: Bundle/8i7tbu6fby5fuuey7133eh and Bundle/FHIRcastContentUpdateBundle-Example
• Copyright HL7. Licensed under creative commons public domain
  Show Usage
  • identifierType: Bundle/FHIRcastContentUpdateBundle-Example, DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327... Show 4 more, ImagingStudy/e25c1d31-20a2-41f8-8d85-fe2fdeac74fd, ImagingStudy/e25c1d31-20a2-41f8-8d85-fe2fdeac74fd-close, Patient/503824b8-fe8c-4227-b061-7181ba6c3926 and Patient/503824b8-fe8c-4227-b061-7181ba6c3926-close
• This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  • LOINC: DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327, DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327-close, DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327-select, DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327-update and Observation/435098234
• This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
  Show Usage
  • SNOMED Clinical Terms® (SNOMED CT®): DiagnosticReport/2402d3bd-e988-414b-b7f2-4322e86c9327-close

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