FHIRcast logo

FHIRcast
3.0.0-ballot - ci-build 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

FHIRcast Event-based Content Sharing

This page contains guidance to implementers and is not part of the normative-track.

Example of Content Sharing in an Anchor Context

The content that is interacted with during a FHIRcast content-sharing session can be considered a shared, non-persisted "cache" of FHIR data. This "cache" begins the session empty, except for the anchor context. Content is then added using FHIRcast *-update events from the session's subscribers. Upon a *-close event, FHIRcast doesn't place any requirements on persisting the content.

From a workflow perspective, each subscriber is responsible for determining if FHIRcast session-created content should persist. Subscribers should provide previously existing content to a FHIRcast session anchored by a relevant context.

An example of content sharing is provided for a use case where a DiagnosticReport is the anchor context (see anchor context). However, the pattern of the example holds when other FHIR resource types are the anchor context.

Diagnostic Report Content Sharing Basics

When reporting applications integrate with PACS and/or RIS applications, a radiologist's (or other clinician's) workflow is centered on the final deliverable, a diagnostic report. In radiology, the imaging study (exam) is an integral resource with the report referencing one or more imaging studies. Structured data, many times represented by a FHIR Observation resource, may also be captured as part of a report. In addition to basic context synchronization, a diagnostic report centered workflow builds upon the basic FHIRcast operations to support near real-time exchange of structured information between applications participating in a diagnostic report context. Also, the DiagnosticReport resource contains certain attributes (such as report status), that are useful to PACS/RIS applications. Participating applications may include clients such as reporting applications, PACS, EHRs, workflow orchestrators, and interactive AI applications.

Exchanged content need not have an independent existence. For example, a radiologist may use the PACS viewer to create a measurement. The PACS application sends this measurement as an Observation to other Subscribers (through interactions with a FHIRcast Hub) for consideration. If the radiologist determines the measurement is useful in another application (and accurate), it may then become an Observation to be included in the diagnostic report.

Structured information may be added, changed, or removed quite frequently during the lifetime of a context. Exchanged information is transitory and it is not required that the information exchanged during the collaboration is persisted. However, as required by their use cases, each participating application may choose to persist information in their own structures which may or may not be expressed as a FHIR resource. Even if stored in the form of a FHIR resource, the resource may or may not be stored in a system which provides access to the information through a FHIR server and associated FHIR operations (i.e., it may be persisted only in storage specific to a given application).

ClinicianApp1(Subscriber)HubApp2(Subscriber)Open ReportFHIRcast: Open ReportDiagnosticReport-openStore Context and Generate versionId202 AcceptedDiagnosticReport-openwith versionIdDiagnosticReport-openwith versionIdMake ObservationFHIRcast: Make ObservationDiagnosticReport-updatewith versionId and ObservationUpdate Content and Generate New versionId202 AcceptedDiagnosticReport-updatewith Observation, versionId,and priorVersionIdDiagnosticReport-updatewith Observation, versionId,and priorVersionIdClose reportFHIRcast: Close ReportDiagnosticReport-close202 AcceptedDiagnosticReport-closeDiagnosticReport-closePersist contentPurge Context including Content
Figure: Basics of content sharing

Example Use Case

A frequent scenario which illustrates a diagnostic report centered workflow involves an EHR, an image reading application, a reporting application, and an advanced quantification application. The EHR, image reading application, and reporting application are authenticated, authorized, and subscribed to the same topic using a FHIRcast Hub with the EHR establishing a patient context, see messages 1 through 7 in the below sequence diagram.

In an EHR a clinical users opens a patient with the EHR sending a Patient-open request to the Hub (messages 1 and 2). The Hub notes the context and if it supports content sharing assigns a version to the context then distributes the Patient-open events (messages 3 and 4a, 4b, and 4c). The reporting application reacts to the patient context in some manner such as displaying available reports and imaging studies associated with the patient while storing the version of the patient context in case content is shared in this anchor context (message 5). The imaging application is not interested in patient contexts so it ignores the event entirely (message 6) while the EHR identifies the Patient-open event as one it triggered and stores the version of the context provided by the Hub in case it would like to contribute content in this context (message 7).

Next the clinical user decides to create diagnostic report using the reporting application, see messages 8 through 14 in the below sequence diagram.

Using a reporting application, a clinical user creates a report by choosing an imaging study as the primary subject of the report (message 8). The reporting application creates a report and then opens a diagnostic report context by posting a DiagnosticReport-open request to the Hub (message 9). The Hub notes the context, assigns a version to the context and then distributes a DiagnosticReport-open event with the generated context.versionId to subscribed applications (messages 10, 11a, 11b, and 11c). On receiving the DiagnosticReport-open event from the Hub, an EHR decides not to react to this event noticing that the patient context has not changed (message 14). The image reading application responds to the event by opening the imaging study referenced in the diagnostic report anchor context (message 13) while the reporting application identifies the DiagnosticReport-open event as one it triggered and stores the version of the context provided by the Hub (message 12).

ClinicianEHR App(Subscriber)ReportingApplication(Subscriber)HubImage ReadingApplication(Subscriber)1: Open a PatientSummaryFHIRcast: Open Patient2: Patient-open3: Store Context and GenerateversionId4a: Patient-openwith versionId5: React and storeversionId4b: Patient-openwith versionId6: ignore4c: Patient-openwith versionId7: Store versionId8: create reportFHIRcast: Open Report9: DiagnosticReport-open10: Store Context and generateversionId11a: DiagnosticReport-openwith versionId12: store versionID11b: DiagnosticReport-openwith versionId13: react andstore versionID11c: DiagnosticReport-openwith versionId14: ignore
Figure: Opening a DiagnosticReport Context

After opening a report, the clinical user takes a measurement using the imaging reading application (message 1 in the below sequence diagram) which then shares this measurement by making a DiagnosticReport-update request to the hub (message 2). The Hub validates that the context.versionId provided in the request is correct, updates its content, generates a new context.versionId (message 3). If the context.versionId provided in the request is not correct the Hub rejects the request (response to message 2). The Hub then distributes DiagnosticReport-update events which contain the newly generated context.versionId and the priorVersionId to all subscribed applications (messages 4a, 4b, and 4c). The reporting application receives the measurement through a DiagnosticReport-update event from the Hub and adds this information to the report if the context.versionId it currently holds matches the context.priorVersionId provided in the event (message 7). If the context.priorVersionId does not match the context.versionId of the content known to the reporting application, it may resynchronize its content by requesting the current context from the Hub (message 8).

As the clinical user continues the reporting process they select a measurement or other structured information in the reporting application, the reporting application may note this selection by posting a DiagnosticReport-select request to the Hub. Upon receiving the DiagnosticReport-select event the image reading application may navigate to the image on which this measurement was acquired.

ClinicianEHR App(Subscriber)ReportingApplication(Subscriber)HubImage ReadingApplication(Subscriber)1: make measurement2: DiagnosticReport-updatewith versionIdFHIRcast: Add MeasurementValidate Update Request[versionId incorrect]2: Reject DiagnosticReport-update[VersionId correct]3: Update Contentand Generate New versionId4a: DiagnosticReport-updatewith versionId and priorVersionId5: Ignore4b: DiagnosticReport-updatewith versionId and priorVersionId6: Store versionId4c:DiagnosticReport-updatewith versionId and priorVersionIdValidate Current Version[priorVersion Correct]7: Update Content andStore versionId[priorVersion Incorrect]8a: Get Current Context8b: Update Content andStore versionId9: Select a MeasurementFHIRcast: Select Measurement10: DiagnosticReport-select11a: DiagnosticReport-select12: Ignore11b: DiagnosticReport-selectAdjust UI11c: DiagnosticReport-select
Figure: Create a Measurement

At some point the image reading application (automatically or through user interaction) may determine that an advanced quantification application should be used and launches this application including the appropriate FHIRcast topic (messages 1 and 2 in the below sequence diagram). The advanced quantification application then subscribes to the topic and requests the current context including any already exchanged structured information by making a GET Context request to the Hub which returns the current context including existing content in the response (messages 3 and 4). The user interacts with the advanced quantification application which then adds content to the anchor context (messages 6 through 13).

ClinicianEHR App(Subscriber)ReportingApplication(Subscriber)HubImage ReadingApplication(Subscriber)AdvancedQuantificationApplication(Subscriber)1: Open Advanced Quantification ApplicationAdd New Subscriber to Existing Content Sharing Session2: Open with FHIRcast Topic3: Subscribe to Topic4: Get Current Context (includes existing content if any)5: Adjust to Contextand Store versionId6: Generate FindingNew Subscriber Adds Finding7: DiagnosticReport-updatewith versionId8: Update Content and Generate New versionId9a DiagnosticReport-updatewith versionId and priorVersionId10: Ignore9b DiagnosticReport-updatewith versionId and priorVersionId11: Update Contentand Store versionId9c DiagnosticReport-updatewith versionIdand priorVersionId11: Update Contentand Store versionId9d DiagnosticReport-updatewith versionId and priorVersionId13 Store versionId
Figure: Newly Subscribed Application Contributes Content

Finally, the clinical user closes the report in the reporting application. The reporting application makes a DiagnosticReport-close request. Upon receipt of the DiagnosticReport-close event both the imaging reading application and advanced quantification application close all relevant image studies.

ClinicianEHR App(Subscriber)ReportingApplication(Subscriber)HubImage ReadingApplication(Subscriber)AdvancedQuantificationApplication(Subscriber)Close report1Close report2DiagnosticReport-close3DiagnosticReport-close4DiagnosticReport-close5close imaging study6DiagnosticReport-close7close imaging study8persist content9Purge Context including content
Figure: Report is stored and context is closed

The Hub purges the context including content and the reporting application persists all relevant content.

Discussion on Reopening Anchor Context Scenario

Often a context in which content has been shared may be reopened (meaning an anchor context has been reopened). An example of this scenario is when a DiagnosticReport was opened and used as an anchor context, the corresponding report was then closed without reaching a final signoff state, and subsequently the report was reopened.

To appropriately handle the scenario of reopening a specific context (e.g., a report), it is necessary that all Subscribers be able to identify specific content from the original sharing session with that same content in the new content sharing session. The consistent use in each FHIR resource of its Resource.id and the fullUrl attribute of the resource's entry in the update bundle (if populated) enables Subscribers to consistently identify content across multiple sharing sessions.

In order to illustrate this consistent handling, consider two Observation resources added to a DiagnosticReport anchor context by two different Subscribers (a reporting application "Reporting" and an imaging reading application "Imaging").

Reporting opens a DiagnosticReport as an anchor context (using a DiagnosticReport-open Event) when a report is being initially created. Imaging opens an ImagingStudy which Reporting has included in the DiagnosticReport-open Event.

Imaging adds Observation A to the content sharing session (using a DiagnosticReport-update Event) without storing this information in a persistent FHIR server. Imaging is responsible to generate a globally unique (e.g., a UUID) Resource.id and providing this as the Resource.id in Observation A's entry in the FHIRcast update bundle with the entry's request.method attribute having a value of PUT. Both the FHIRcast Hub and Reporting add this Observation to their working memory including the Resource.id value provided by Imaging.

Reporting adds Observation B to the content sharing session (using a DiagnosticReport-update Event) after it stores the Observation resource in a FHIR server. The FHIR server assigns a Resource.id to Observation B and the full URL for retrieving the Observation is known. Reporting provides the fullUrl attribute and the Resource.id in Observation B's entry in the FHIRcast update bundle with the entry's request.method attribute having a value of PUT. Both the FHIRcast Hub and Imaging add this Observation to their working memory including the Resource.id and fullUrl values provided by Reporting.

To complete this initial content sharing portion of the reopen scenario, the DiagnosticReport anchor context is closed (by a DiagnosticReport-close Event). At least one of the Subscribers likely persists the structured information exchanged in the content sharing session (in the above example this is Observations A and B). Regardless of the persistence mechanisms used (e.g., persistence in a FHIR server or storage in a SQL or non-SQL database), each actor should ensure the Resource.id and fullUrl (if populated) used in the initial content sharing session is stored with the persisted structured information. For example, an application persisting Observations A and B in a FHIR server could use an identifier value with a known system to retain the Resource.id of Observation A as provided by Imaging.

If the same DiagnosticReport anchor context is reopened (by a DiagnosticReport-open Event), content from the initial content sharing session may be added to the reestablished content sharing session by one or more Subscribers. For example, it is possible that only Reporting populates the reopened DiagnosticReport anchor context (using a DiagnosticReport-update Event) or both Reporting and Imaging could populate the session. In any circumstance, if all Subscribers use the Resource.id and fullUrl (if populated) from the initial content sharing session all Subscribers are able to identify specific content from the original sharing session with that same content in the new content sharing session without any logic specific to the population of structured information in the reopened anchor context. Note that the FHIRcast Hub is not expected to provide a persistence mechanism, hence it plays no role in populating the reopened content sharing session.

A few additional notes are relevant to the reopen scenario:

  1. Any modifications to structured information performed outside of a content sharing session that includes all Subscribers who persisted structured information from the initial content sharing session could lead to inconsistencies requiring resolution by an end user. For example, if Observation A was deleted by a user in Imaging with the deletion occurring outside of a content sharing session which includes Reporting; when a joint session is reestablished, Observation A may be added to the new content sharing session by Reporting and hence require the user to again delete Observation A. Ideally, no modification of structured information that was acquired during a content sharing session is permitted in the absence of a reopened content sharing session with as many of the originally participating Subscribers as possible.
  2. There is no requirement that all Subscribers persist structured information that is exchanged during a content sharing session. For such applications the need to retain Resource.id values is not relevant.
  3. Applications may decide to use attributes in a FHIR resource to hold private information. If a resource holding private information is added to a reopened content sharing session by another subscriber, this private information may no longer be present. For example, if Imaging uses an extension in Observation A, Reporting may persist Observation A in a database structure that has no provision for the extension. Upon reopening the content sharing session, if Reporting is the Subscriber which adds Observation A to the content sharing session then information in the extension will not be present. Imaging must have some provision to retain the information in the extension as appropriate.
  4. It is likely that during content exchange most resources will not be persisted in a FHIR server at least until after the initial close. Hence, the fullUrl attribute may never be used; however, it should be supported to cover all possibilities.