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
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.
SyncError
OperationOutcome (namely communication of the error'd event's id and event name).Content-Location
HTTP header.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.
The Get Current Context API was added to the 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.
webhook
channelIn 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.
open
eventsSignificant 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
eventsSTU3 introduces the (experimental) concept of selection.
Scattered throughout the FHIRcast specification are the questions to implementers, the following hyperlink directly to them:
This publication includes IP covered under the following statements.
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.
IG | Package | FHIR | Comment |
---|---|---|---|
FHIRcast | hl7.fhir.uv.fhircast#3.0.0-ballot | R4 | |
HL7 Terminology (THO) | hl7.terminology.r4#6.1.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.1.0 | R4 | Automatically added as a dependency - all IGs depend on the HL7 Extension Pack |
International Patient Access | hl7.fhir.uv.ipa#1.0.0 | R4 | |
HL7 Terminology (THO) | hl7.terminology.r4#5.0.0 | R4 | |
SMART App Launch | hl7.fhir.uv.smart-app-launch#2.0.0 | R4 |
Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10: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) |
There are no Global profiles defined