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. |
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.
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).
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.
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:
fullUrl
attribute may never be used; however, it should be supported to cover all possibilities.