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

Multi-anchor Considerations

Apples & oranges: considerations for synchronizing applications that talk past one another

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.

Applications understand each other

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.

Applications don’t understand each other

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.

Implied 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).

Hub derives open events

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:

• Hubs can reject subscriptions according to their own internal business logic.
• Hubs are required to derive and send open events.

Hub may or may not derive close events

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.