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
This page contains guidance to implementers and is not part of the normative-track. |
Some healthcare applications know about apples, some oranges. When the orange application doesn't understand what the apple application is saying: the Hub should help translate.
For many context synchronization scenarios, all participating applications are subscribed to and understand all of the events used in the session. For example all of the applications in a session understand Patient-open
and Patient-close
events and those are the only events used in the session.
However, it may make sense to synchronize applications that don't subscribe to and understand the same FHIRcast events. For example, some specialized healthcare applications deal exclusively with billing charges or imaging studies and don't have the concept of a patient outside of a charge or study. A PACS may not send or even understand a Patient-open
, only ImagingStudy-open
. Similarly, a generalized healthcare application may understand Patient-open
events, but not more specialized events, such as DiagnosticReport-open
events.
FHIRcast event definitions specify the related FHIR resources that are contextully relevent to the event. An *-open event implies additional open events, one for each of the resource types referenced in the context.
For example, an Encounter-open
implies a Patient-open
, because the Encounter-open
's context includes not just an encounter resource, but also a patient resource. Similarly, DiagnosticReport-open
implies Patient-open
and possibly an ImagingStudy-open
(if an ImagingStudy is supplied in the DiagnosticReport-open
event).
Implementer input is solicited. Is the absence of guidance from the specification problematic? If so, why? and how would you recommend we solve this? |
The Hub is responsible for identifying and sending these implied *-open events. When distributing a received event, the Hub is responsible for generating and communicating open events for the resource types referenced by the received event. It is important that Hubs do not generate and send duplicative events.
See details in the specification about:
Implementer input is solicited. Is the absence of guidance from the specification problematic? If so, why? and how would you recommend we solve this? |
A close event may or may not imply the closure of referenced resource types (see multi-tab considerations). FHIRcast does not currently prescribe this behavior.