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

FHIRcast Event-based Content Sharing

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

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

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](3-6-3-DiagnosticReport-update.html) 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.

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

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.

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.