Integrated Reporting Applications
0.1.1 - ci-build International flag

Integrated Reporting Applications, published by IHE Radiology Technical Committee. This is not an authorized publication; it is the continuous build for version 0.1.1). This version is based on the current content of https://github.com/IHE/RAD.RTC-IMR/ and changes regularly. See the Directory of published versions

1:XX. IRA Volume 1

The Integrated Reporting Applications (IRA) profile helps applications that are used together during reporting (e.g. image display, report creator, clinical applications, AI tools, etc) to share information using a standard called FHIRcast. Each application can share what it is doing and the data it is creating, referred to as Context and Content, respectively. Other applications are notified so they can then intelligently synchronize their behavior or use the new data.

For example, the report creator could share that the user is starting a new report, and the other applications could synchronize by opening the corresponding study. An AI tool could generate a tumor measurement and the report creator could get that data and add an entry in the report, either automatically or triggered by a command from the radiologist.

1:XX.1 Realtime Bidirectional Communication for Interactive Multimedia Reporting

This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at https://profiles.ihe.net/GeneralIntro/.

Figure 1:XX.1-1 shows the actors directly involved in the IRA Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a required grouping are shown in conjoined boxes (see Section 1:XX.3).


Figure 1:XX.1-1: IRA Actor Diagram

Table 1:XX.1-1 lists the transactions for each actor directly involved in the IMR Profile. To claim compliance with this profile, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”).

Table 1:XX.1-1: IRA Profile - Actors and Transactions

Actors Transactions Initiator or Responder Optionality Reference
Image Display Subscribe to Reporting Session [RAD-X1] Initiator R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Initiator R RAD TF-2: 4.X2
Open Report Context [RAD-X3] Initiator R RAD TF-2: 4.X3
Close Report Context [RAD-X4] Initiator R RAD TF-2: 4.X4
Unsubscribe Session [RAD-X7] Initiator R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Initiator R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Responder R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Responder R RAD TF-2: 4.X10
Notify Error [RAD-X11] Initiator R RAD TF-2: 4.X11
Report Creator Subscribe to Reporting Session [RAD-X1] Initiator R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Initiator R RAD TF-2: 4.X2
Open Report Context [RAD-X3] Initiator R RAD TF-2: 4.X3
Close Report Context [RAD-X4] Initiator R RAD TF-2: 4.X4
Unsubscribe Session [RAD-X7] Initiator R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Initiator R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Responder R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Responder R RAD TF-2: 4.X10
Notify Error [RAD-X11] Initiator R RAD TF-2: 4.X11
Worklist Client Subscribe to Reporting Session [RAD-X1] Initiator R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Initiator R RAD TF-2: 4.X2
Open Report Context [RAD-X3] Initiator R RAD TF-2: 4.X3
Close Report Context [RAD-X4] Initiator R RAD TF-2: 4.X4
Unsubscribe Session [RAD-X7] Initiator R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Initiator R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Responder R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Responder R RAD TF-2: 4.X10
Notify Error [RAD-X11] Initiator R RAD TF-2: 4.X11
Evidence Creator Subscribe to Reporting Session [RAD-X1] Initiator R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Initiator R RAD TF-2: 4.X2
Unsubscribe Session [RAD-X7] Initiator R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Initiator R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Responder R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Responder R RAD TF-2: 4.X10
Notify Error [RAD-X11] Initiator R RAD TF-2: 4.X11
Content Creator Update Report Content [RAD-X5] Initiator O (Note 1) RAD TF-2: 4.X5
Select Report Content [RAD-X6] Initiator O (Note 1) RAD TF-2: 4.X6
Watcher Subscribe to Reporting Session [RAD-X1] Initiator R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Initiator R RAD TF-2: 4.X2
Unsubscribe Session [RAD-X7] Initiator R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Initiator R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Responder R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Responder R RAD TF-2: 4.X10
Notify Error [RAD-X11] Initiator R RAD TF-2: 4.X11
Hub Subscribe to Reporting Session [RAD-X1] Responder R RAD TF-2: 4.X1
Connect to Notification Channel [RAD-X2] Responder R RAD TF-2: 4.X2
Open Report Context [RAD-X3] Responder R RAD TF-2: 4.X3
Close Report Context [RAD-X4] Responder R RAD TF-2: 4.X4
Update Report Content [RAD-X5] Responder R RAD TF-2: 4.X5
Select Report Content [RAD-X6] Responder R RAD TF-2: 4.X6
Unsubscribe from Session [RAD-X7] Responder R RAD TF-2: 4.X7
Get Current Context [RAD-X8] Responder R RAD TF-2: 4.X8
Distribute Context Event [RAD-X9] Initiator R RAD TF-2: 4.X9
Generate SyncError Event [RAD-X10] Initiator R RAD TF-2: 4.X10
Notify Error [RAD-X11] Responder R RAD TF-2: 4.X11

Note 1: A Content Creator shall support at least one of the update or select transactions.

1:XX.1.1 Actors Description and Actor Profile Requirements

Most requirements are documented in RAD TF-2 Transactions. This section documents any additional requirements on this profile’s actors.

1:XX.1.1.1 Image Display

The Image Display actor is responsible for presenting patients’ studies and relevant information to the user so that the user can make diagnostic decisions on the studies.

The Image Display provides tools for the user to navigate images in a study. It may include a worklist component that let the user select studies to read. It may also include tools to create evidence data such as annotations, key images, etc.

The Image Display shall be capable of being launched by another application. When launched, it shall use the provided hub.url and hub.topic to join a reporting session.

The Image Display shall be able to launch other applications and synchronize them to the same report context through the Hub. It shall have the following capabilities:

  • Start a new reporting session by generating a unique session ID and subscribing to the Hub on its own
  • Launch one or more actors and provide them the URL of the Hub actor as hub.url and the reporting session ID as hub.topic
  • Open or close (or both) report context based on some business logic

Note that the actual application launch method is out of scope of this profile See Application Launch Scenarios and Session Discovery for more details.

1:XX.1.1.1.1 Event Handling Requirements

In Table 1:XX.1.1.1.1-1, for each Received Event, Context Key specifies the contexts in the received event and Resources specifies the FHIR resources used in the given context. The Image Display shall support all Behaviors shown as “R” in Optionality. The Image Display may support suggested behaviors (“O” in Optionality).

Table 1:XX.1.1.1.1-1: Event Handling Requirements

Received Event Context Key Resources Optionality Behavior
DiagnosticReport-open report DiagnosticReport R Maintain association of report context to associated patient and study
patient
study		 Patient
ImagingStudy		 R Display the study images and patient metadata
DiagnosticReport-update report DiagnosticReport R Reflect updated status (DiagnosticReport.status) in worklist
updates ImagingStudy O Display the comparison study
updates ImagingSelection O Display annotations to selected images
updates Observation O Display measurements and annotations
DiagnosticReport-select select ImagingStudy O Bring the comparison study to focus
select ImagingSelection O Bring selected images and annotations to focus
DiagnosticReport-close report DiagnosticReport R Stop display the study images associated to the report context
SyncError operationoutcome OperationOutcome O Notify the user regarding the synchronization error, including the details of the error reported and the Subscriber that reported the error
1:XX.1.1.1.2 Event Producing Requirements

If the Image Display accepted an event initially (i.e. returning 202 Accepted) and later decided to refuse the context or failed to process the event, then it shall send a syncerror event back to the Hub using Notify Error RAD-X11.

If the Image Display is grouped with a Content Creator to publish additional content events to a reporting session, then it shall publish events using at least one FHIR resource. The Image Display is highly recommended to publish events using one or more of the following FHIR resources that are expected to be useful in reporting:

  • Patient: patient in the anchor context
  • ImagingStudy: imaging study in either the anchor context (i.e. the study subject to be reported) or as additional studies (e.g. a comparison study)
  • ImagingSelection: image / series references and simple annotations
  • Observation: measurements and annotations

1:XX.1.1.2 Report Creator

The Report Creator actor is responsible for producing a diagnostic report for patients’ studies.

In order to complete a study dictation, the Report Creator:

  • May launch other applications and synchronize them to the same report context through the Hub
  • May be launched by another application, consume reporting events from the Hub and synchronize itself to the same report context

The Report Creator provides tools for the user to insert report content such as findings and impressions. The Report Creator may use the report content shared by other applications through the Hub (e.g. image references shared by Image Display, or measurements shared by Evidence Creator) to directly update the report (e.g. insert measurements) or generate derived report content (e.g. inject hyperlinks from image references)

The Report Creator shall be capable of being launched by another application. When launched, it shall use the provided hub.url and hub.topic to join a reporting session.

The Report Creator shall be able to launch other applications and synchronize them to the same report context through the Hub. It shall have the following capabilities:

  • Start a new reporting session by generating a unique session ID and subscribing to the Hub on its own
  • Launch one or more actors and provide them the URL of the Hub actor as hub.url and the reporting session ID as hub.topic
  • Open or close (or both) report context based on some business logic

Note that the actual application launch method is out of scope of this profile See Application Launch Scenarios and Session Discovery for more details.

1:XX.1.1.2.1 Event Handling Requirements

In Table 1:XX.1.1.2.1-1, for each Received Event, Context Key specifies the contexts in the received event and Resources specifies the FHIR resources used in the given context. The Report Creator shall support all Behaviors shown as “R” in Optionality. The Report Creator may support suggested behaviors (“O” in Optionality).

Table 1:XX.1.1.2.1-1: Event Handling Requirements

Event Context Key Resources Optionality Behavior
DiagnosticReport-open report DiagnosticReport R Maintain association of report context to associated patient and study
patient
study		 Patient
ImagingStudy		 R Be ready for reporting for the study. If re-open a previously opened report context, resume to the previous state of the report context when it was interrupted.
DiagnosticReport-update updates ImagingStudy O Add comparison study to report
updates ImagingSelection O Add annotations of selected images to data collection for further processing
updates Observation O Add measurements and annotations to data collection for further processing
DiagnosticReport-select select ImagingStudy O Select comparison study and able to apply user commands (See Note 1)
select ImagingSelection O Select images and annotations and able to apply user commands (See Note 1)
DiagnosticReport-close report DiagnosticReport R Stop display the study report
SyncError operationoutcome OperationOutcome O Notify the user regarding the synchronization error, including the details of the error reported and the Subscriber that reported the error

Note 1: The Report Creator may provide application logic that can make use of the selected resources. For example, a nodule (as ImagingSelection) and corresponding measurements (as Observation) are selected. Then the radiologist issues a voice command “insert hyperlink”. In this case, the Report Creator applies the command with the selected resources and insert a hyperlink reference to the nodule with measurement.

1:XX.1.1.2.2 Event Producing Requirements

If the Report Creator accepted an event initially (i.e. returning 202 Accepted) and later decided to refuse the context or failed to process the event, then it shall send a syncerror event back to the Hub using Notify Error RAD-X11.

The Report Creator shall be grouped with a Content Creator to publish report status update using the report anchor context DiagnosticReport resource. It may support other content sharing resources.

1:XX.1.1.3 Worklist Client

The Worklist Client actor is responsible for providing a reporting worklist to the user.

When a user selects studies from the worklist, the Worklist Client launches other applications (e.g. Image Display, Report Creator, etc.) if necessary. It opens a new report context to synchronize other applications through the Hub to enable dictation on the studies.

When a study dictation is complete, the Worklist Client consumes the report anchor context update event so that it can mark the study as dictated and remove it from the worklist.

The Worklist Client shall be capable of being launched by another application. When launched, it shall use the provided hub.url and hub.topic to join a reporting session.

The Worklist Client shall be able to launch other applications and synchronize them to the same report context through the Hub. It shall have the following capabilities:

  • Start a new reporting session by generating a unique session ID and subscribing to the Hub on its own
  • Launch one or more actors and provide them the URL of the Hub actor as hub.url and the reporting session ID as hub.topic
  • Open or close (or both) report context based on some business logic

Note that the actual application launch method is out of scope of this profile See Application Launch Scenarios and Session Discovery for more details.

1:XX.1.1.3.1 Event Handling Requirements

In Table 1:XX.1.1.3.1-1, for each Received Event, Context Key specifies the contexts in the received event and Resources specifies the FHIR resources used in the given context. The Worklist Client shall support all Behaviors shown as “R” in Optionality. The Worklist Client may support suggested behaviors (“O” in Optionality).

Table 1:XX.1.1.3.1-1: Event Handling Requirements

Event Context Key Resources Optionality Behavior
DiagnosticReport-open report DiagnosticReport R Maintain association of report context to associated patient and study.
patient
study		 Patient
ImagingStudy		 R Display the patient and study metadata
DiagnosticReport-update report DiagnosticReport R Reflect updated status DiagnosticReport.status in worklist
DiagnosticReport-select select ImagingStudy O Select the study in worklist
DiagnosticReport-close report DiagnosticReport R Stop processing the study associated to the report context
SyncError operationoutcome OperationOutcome O Notify the user regarding the synchronization error, including the details of the error reported and the Subscriber that reported the error
1:XX.1.1.3.2 Event Producing Requirements

If the Worklist Client accepted an event initially (i.e. returning 202 Accepted) and later decided to refuse the context or failed to process the event, then it shall send a syncerror event back to the Hub using Notify Error RAD-X11.

1:XX.1.1.4 Evidence Creator

The Evidence Creator actor is responsible for consuming events in the reporting session and producing evidence data such as annotations, measurements, key image references, etc. for the patients’ studies. For example, it may detect lung nodules and produce measurements and bounding boxes of the nodules detected.

The Evidence Creator may capture the evidence data in format such as DICOM SR and shared with other systems using methods outside of this profile (e.g. as Evidence Creator in IHE AIR profile). In this case, other synchronizing applications in the same reporting session may not be aware of the evidence data created by the Evidence Creator.

Alternatively the Evidence Creator may capture the evidence data (e.g. lung nodule measurements as FHIR Observation resource, image references and bounding box as FHIR ImagingSelection resource) and share them by publishing content sharing events back to the reporting session through the Hub.

The Evidence Creator may be a standalone application such as an Specialty AI application, or it may be grouped with another actor such as Image Display.

The Evidence Creator shall be capable of being launched by another application. When launched, it shall use the provided hub.url and hub.topic to join a reporting session.

1:XX.1.1.4.1 Event Handling Requirements

In Table 1:XX.1.1.4.1-1, for each Received Event, Context Key specifies the contexts in the received event and Resources specifies the FHIR resources used in the given context. The Evidence Creator shall support all Behaviors shown as “R” in Optionality. The Evidence Creator may support suggested behaviors (“O” in Optionality).

Table 1:XX.1.1.4.1-1: Event Handling Requirements

Event Context Key Resources Optionality Behavior
DiagnosticReport-open report DiagnosticReport R Maintain association of report context to associated patient and study
patient
study		 Patient
ImagingStudy		 R Process the study data
DiagnosticReport-update Any Any O Update the report, patient or study record, or add/modify/delete received contents, if applicable.
DiagnosticReport-select Any Any O Process the applicable selected resources
DiagnosticReport-close report DiagnosticReport R Stop processing the study data associated to the report context
SyncError operationoutcome OperationOutcome O Notify the user regarding the synchronization error, including the details of the error reported and the Subscriber that reported the error
1:XX.1.1.4.2 Event Producing Requirements

If the Evidence Creator accepted an event initially (i.e. returning 202 Accepted) and later decided to refuse the context or failed to process the event, then it shall send a syncerror event back to the Hub using Notify Error RAD-X11.

If the Evidence Creator is grouped with a Content Creator to publish content events to a reporting session, then it shall publish events using at least one FHIR resource. The Evidence Creator is highly recommended to publish events using one or more of the following FHIR resources that are expected to be useful in reporting:

  • ImagingSelection: image / series references and simple annotations such as bounding boxes
  • Observation: measurements and annotations
  • DocumentReference: results from IHE AI Results Profile using the JSON Representation of DICOM SR, or other documents

1:XX.1.1.5 Content Creator

The Content Creator is responsible for the creation and selection of the contents of the reporting session which are the basis of synchronization and collaboration between the subscribing actors.

Note: This actor represents content creation / selection capabilities that may be present in implementation of other actors. As such, the Content Creator is required to be grouped with another actor. This actor cannot be claimed as a standalone actor.

For example, when an Image Display user clicks on the bounding box of a detected nodule, the grouped Content Creator publishes a selection event referencing the affected images and bounding boxes as an ImagingSelection resource, and referencing the corresponding measurements as an Observation resource. Upon receiving the event, a Report Creator might show those details in a side panel to the user. Finally the user issues a voice command to the Report Creator to inject a hyperlink, which is adding to the finding section.

The Content Creator actor may publish context and/or content changes as events to a reporting session. The Content Creator may select one or more contents and publish the selection events.

The specific context or content changes captured by the Content Creator depends on the grouped actor and the specific deployment scenario. For example:

Grouped Actor Potential Use Relevant Resource
Report Creator Communicate report status update DiagnosticReport
Evidence Creator Image references
Bounding Boxes		 ImagingSelection
Observation
Image Display Comparison study used during reporting ImagingStudy

1:XX.1.1.6. Watcher

The Watcher actor is responsible for listening to events in a session and perform actions according to it business logic. The specific actions are out of scope of this profile.

For example, the Watcher consumes the initiation and termination of report contexts and calculates the turnaround time for different types of studies in different departments. Another example is that the Watcher monitors how often an Evidence Creator publishes content sharing events and correlates how effective an AI application is with respect to the turnaround time by comparison and time before and after the Evidence Creator is deployed.

The Watcher shall be capable of being launched by another application. When launched, it shall use the provided hub.url and hub.topic to join a reporting session.

1:XX.1.1.6.1 Event Handling Requirements

In Table 1:XX.1.1.6.1-1, for each Received Event, Context Key specifies the contexts in the received event and Resources specifies the FHIR resources used in the given context. The Watcher shall support all Behaviors shown as “R” in Optionality. The Watcher may support suggested behaviors (“O” in Optionality).

Table 1:XX.1.1.6.1-1: Event Handling Requirements

Event Context Key Resources Optionality Behavior
DiagnosticReport-open report DiagnosticReport R Maintain association of report context to aassociated patient and study
patient
study		 Patient
ImagingStudy		 R Process according to business logic
DiagnosticReport-update Any Any O Update the report, patient or study record, or add/modify/delete received contents, if applicable.
DiagnosticReport-select Any Any O Process the applicable selected resources
DiagnosticReport-close report DiagnosticReport R Stop processing the report context
SyncError operationoutcome OperationOutcome O Process the synchronization error, including the details of the error reported and the Subscriber that reported the error
1:XX.1.1.6.2 Event Producing Requirements

If the Watcher accepted an event initially (i.e. returning 202 Accepted) and later decided to refuse the context or failed to process the event, then it shall send a syncerror event back to the Hub using Notify Error RAD-X11.

1:XX.1.1.7 Hub

The Hub actor is responsible for managing event flows between Subscribers in reporting sessions and maintaining the current context and transaction of content sharing in each session.

The Hub is responsible for authorizing the following:

  • which Subscriber has permission to invoke what requests
  • which context and content a Subscriber is eligible to access and in what type (e.g. read only, write only or ready and write)

Note: This profile does not mandate a specific authorization mechanism.

The Hub shall support content sharing.

The Hub shall monitor the established websocket connections. If it detects a websocket connection issue with a Subscriber, then the Hub shall

  • Unsubscribe the Subscriber and drop the websocket connection
  • Send a SyncError notification to other Subscribers using RAD-X10
1:XX.1.1.7.1 Event Handling Requirements

The Hub shall be able to process all valid events conforming to the FHIRcast Event Format received using FHIRcast Request Context Change requests.

Note: This implies that the Hub cannot only process events defined in this profile. The Hub is required to support other valid events regardless of whether they are defined in the FHIRcast Event Catalog. For example, Subscribers in a reporting session are permitted to send Request Context Change requests with events (e.g. HeartBeat, ImagingStudy-*, etc.) beyond those explicitly defined in this profile.

For all received events, the Hub shall support the following core behaviors:

  • It shall receive and distribute the event to all Subscribers subscribed to that event type (See Event Notification)
  • It shall manage the current context in the session for all context-change events (i.e. *-open and *-close events) (See Request Context Change)
  • It shall serve as a transaction coordinator to avoid lost updates and other out of sync conditions when processing content sharing events (i.e. *-update and *-select events) (See Content Sharing)

Additional profile requirements for specific events are defined in the corresponding transactions.

1:XX.1.1.7.2 Event Producing Requirements

When a Hub has successfully processed a Close Report Context [RAD-X4] request, the Hub will establish a new current context. The Hub will select one of the existing open contexts in the session to be the new current context, typically the most recently opened context (i.e. resume a previous open context). If no open context exist, then current context will be empty.

When the Hub establishes a new current context, the Hub shall be capable of distributing a corresponding DiagnosticReport-open context event as if it had received Open Report Context [RAD-X3] requests.

If the current context has associated contents, the Hub shall be capable of distributing corresponding DiagnosticReport-update and/or DiagnosticReport-select context events as if it had received Update Report Content [RAD-X5] and/or Select Report Content [RAD-X6] requests.

Note: These requirements are limited to processing reporting events in reporting sessions as defined in this profile. These requirements are not required for other events that the Hub received and processed.

1:XX.2 IRA Actor Options

Options that may be selected for each actor in this implementation guide, are listed in Table 1:XX.2-1 below. Dependencies between options, when applicable, are specified in notes.

Table 1:XX.2-1: IRA - Actors and Options

Actor Option Name Reference
Image Display No options defined -
Report Creator No options defined -
Worklist Client No options defined -
Evidence Creator No options defined -
Content Creator No options defined –
Watcher No options defined -
Hub No options defined –

1:XX.3 IRA Required Actor Groupings

An actor from this profile (Column 1) shall implement all of the required transactions and/or content modules in this profile in addition to all of the requirements for the grouped actor (Column 3).

In some cases, required groupings are defined as at least one of an enumerated set of possible actors; this is designated by merging column one into a single cell spanning multiple potential grouped actors. Notes are used to highlight this situation.

Section 1:XX.5 describes some optional groupings that may be of interest for security considerations and Section 1:52.6 describes some optional groupings in other related profiles.

Table 1:XX.3-1: IRA Required Actor Groupings

IMR Actor Grouping Condition Actor(s) to be grouped with Reference
Image Display – None –
Report Creator – None –
Worklist Client – None –
Evidence Creator – None –
Content Creator Enable producing content sharing events IRA / Any actor IRA TF-1: 1.1
Watcher – None –
Hub – None –

1:XX.4 IRA Overview

1:XX.4.1 Concepts

1:XX.4.1.1 Publish and Subscribe Model

At its heart, this profile synchronizes a group of applications using a Publish and Subscribe model as implemented by FHIRcast which in turn is an implementation of WebSub.

The following are some key concepts:

  • Participating applications are Subscribers that register with and communicate with a Hub
  • Subscribers do not communicate with other Subscribers directly.
  • Typically the Hub only communicates with authenticated Subscribers
  • When Subscribers generate data that needs to be made available to other applications, or perform actions that the other applications should be notified of, they publish it by sending an event with the relevant details to the Hub
  • The Hub forwards events received from Driving Applications to the other Synchronizing Applications
  • Subscribers can configure their subscription to limit what types of events the Hub sends to them.
  • Subscribers react to events from the Hub based on their internal business logic
  • Subscribers do not need to be explicitly aware of what other subscribers (if any) are receiving their events or how they react to them
  • The Hub also maintains the collection of data it has received, organized them according to the context
  • Subscribers can request the current context and associated contents from the Hub
  • The Hub can simultaneously manage multiple groups of Subscribers and their associated data in different sessions
  • Each session is identified by a unique “topic ID”
  • The Subscriber that opens and closes context is referred to as the Driving Application. A Driving Application usually also launches other applications, providing them with the address of the Hub and the topic ID so they can join the same session.

1:XX.4.1.2 Terminology and Model

The terminology used in FHIRcast and adopted in this profile can be found in the Glossary page.

The following is a representation of the data model.

Figure 1:XX.4,1.2-1: FHIRcast Concept Data Model


The following is a representation of the interaction model.

Note: The term Driving Application and Synchronizing Application in the diagram are convenient terms instead of actual defined terms. They are used here to highlight the additional capabilities a driving application can do, in particular:

  • Start a new reporting session
  • Launch another application
  • Open or close a report context

Figure 1:XX.4,1.2-1: FHIRcast Concept Interaction Model


1:XX.4.1.3 Long Session and Short Context

A Session is an abstract concept representing a shared workspace, such as a user’s login session across multiple applications or a shared view of one application distributed to multiple users. A session results from a user logging into an application and can encompass one or more workflows.

For instance, a reporting session is a shared workspace across multiple applications to communicate activities of a user, such as initiating a new report context when opening a study for reporting. These applications as Subscribers share events using the Hub. As long as there are Subscribers associated to a Session, the Session stays open. Therefore a Session has a long duration.

A Context is a FHIR resource associated with a Session which indicates a subject on which applications should synchronize as appropriate to their functionality. As soon as the subject is complete, the corresponding Context can be closed. Therefore a Context has a limited duration within a Session.

1:XX.4.1.4 Events vs Commands

Communication patterns between two systems fall in two general categories: Commands and Events.

Events represent facts that have happened. For example, DiagnosticReport-open represents an event that an application opens a study for reporting. Note that an event has an initiator but no target recipient(s). It is the responsibility of any applications that are interested in such events to subscribe them. Any applications subscribed to the event will receive the event and the application can determine how to process the event. The application that is producing the event is not aware of the actions being performed by the consuming applications, unless these consuming applications in turn publishes additional events.

On the other hand, Commands represent intention. In addition to an initiator, Commands have specific target recipient(s). For example, Send-Study represents an intention to send a study. The application that sends the commands often has direct knowledge of which applications should execute the commands, or delegate to a proxy service that has the knowledge.

In this profile, the messages that a Subscriber sends to the Hub represents an Event. Each event captures what has happened, and there is no explicit recipient(s) specified.

Note: Some implementations may define commands using Extensions or custom events with explicit recipient(s). These are out of scope of this profile.

1:XX.4.1.5 Timing of Sending an Event

A driving application is a subscriber that initiates a context change request. From the driving application perspective, it is desirable for all subscribers to be synchronized as soon as possible. On the other hand, FHIRcast is a network protocol which incurs a non-trivial cost to send each event. Therefore any implementation should take into account when an action is considered to be complete or stable, and hence ready to be captured and communicated as events.

For example, when a user is actively making measurements or annotations, instead of capturing every change a user made (e.g. incremental changes in size or location of a shape) as an event which can result in many intermittent and partial events, an application may use specific triggers (e.g. when a user saves the changes) or an idle time threshold to detect when the user completed making the changes. The application then creates the corresponding event(s) to capture the result.

On the other hand, this profile is designed to communicate in-progress data as soon as possible. Therefore it is not desirable for the driving application to wait too long. For example, if the driving application supports exporting measurements and annotations as DICOM SR or other DICOM objects, it is not necessary to wait until the DICOM objects are created before sending the corresponding event.

This profile does not mandate any specific implementation design regarding when an application should capture the result of an action as an event. The intention is that the driving application will send an event as soon as feasible so that all subscribers in a reporting session can be synchronized and provide a good user experience.

1:XX.4.1.6 Event Awareness vs Event Consumption

Event Awareness means an application, upon receiving an event from the Hub, has the knowledge of an event has happened.

Event Consumption means an application, upon receiving an event from the Hub, reacts to the event and performed some actions according to its business logic.

This means from the content sharing application perspective, in order to synchronize the context with other applications, it may be desirable to publish frequent events so that other subscribers can be aware of the same context as in the content sharing application.

On the other hand, from the subscribing application perspective, it is up to its business logic to determine how to react to the received event. This business logic may be automatic or requires additional user input.

For example, when the user goes through the study images in Image Display (a content sharing application), for each nodule that the user identified (e.g. 1, 2, …, 9, 10), the Image Display publishes a corresponding event. In the Report Creator (a subscribing application), for each event received, it keeps track of the nodule in its nodule tracking bookmark. Once the user finished reviewing the full study, the user uses the nodule tracking bookmark in the Report Creator and selects the top 3 (e.g. 2, 5, 9) to include in the final report. Note that since the Report Creator is aware of all the nodules observed by synchronizing the context with the Image Display, selecting a subset of the nodules to be included in the final report (i.e. event consumption) is an operation internal to the Report Creator.

1:XX.4.1.7 Transient Resource vs Persistent Resource

FHIRcast uses FHIR resources to capture the context and content in an event. These FHIR resources may be transient, meaning that they do not necessarily exist in any system, nor are they expected to be persisted by any system. Furthermore, even an application decides to persist the FHIR resource(s), it is not required to use the same resource ID in the event as the ID of the persisted resource. The application can generate new IDs instead.

Since the FHIR resources specified in the event may or may not be persisted in any FHIR server, to differentiate between the two cases, this profile defines that transient resources are identified by relative references (e.g. Patient/12345) and persisted resources that already exist are identified by full URL (e.g. http://myserver.com/Patient/12345).

1:XX.4.1.8 Local Tracking of Context

The DiagnosticReport-open event includes both the report anchor context and associated contexts patient and study. Subsequent event(s) for this anchor context will only provide the report context. Therefore, it is up to the Subscriber to record internally the patient and study contexts associated with the report anchor context if that information is relevant to its business logic.

1:XX.4.1.9 Interruption and Resume

Occasionally a Context may be interrupted because of suspension, meaning that before the Context is closed, another Context is opened. In this case, the information of the previous Context is still maintained by the Hub since it is not closed, but it is suspended (i.e. not the Current Context).

For example, a radiologist needs to suspend the current report on a study in order to review another urgent study. When switching to the urgent study, the report context of the previously opened study is not closed. Instead a new report context is opened for the urgent study. In this case, the Current Context is switched to the urgent study being opened. As soon as the user finished reviewing the urgent study and hence has closed the Context of the urgent study, the suspended Context will resume to be the Current Context since it is the last opened Context.

See Use Case #3 for more details.

1:XX.4.1.10 Deployment Considerations

The Hub can be a standalone application or embedded within another application (e.g. the Image Manager, Report Creator and Worklist Client are grouped with the Hub independently). As a result, which Hub to use for the reporting session needs to be configurable during deployment.

The Hub can be deployed on premises or in the cloud. The other actors may or may not be deployed in the same location as the Hub. Since this profile is aimed at providing streamline user experience for all integrated applications, the effectiveness of this profile depends on timely communications with the Hub, whether it is the context change request, or the subsequent event distribution. Therefore it is important to have a reliable low latency network connection between applications and the Hub, taking into account all the network appliances in between (e.g. firewall, reverse proxy, load balancer, etc.).

1:XX.4.1.11 FHIRcast Beyond Reporting

FHIRcast is a generic event distribution mechanism. Most transactions in this profile are generally applicable to any events. Any applications are permitted to use FHIRcast and the Hub for use cases beyond reporting. In this case, the application may consider using different sessions and events for different purposes. For example, an Image Manager may setup a separate advanced visualization session with an Evidence Creator and uses ImagingStudy-* events for communication.

Furthermore, the Hub used in these cases may be different from the Hub used for the reporting session. Therefore an application needs to be prepared to support different sessions with different Hubs, and know which session to use for what purpose.

1:XX.4.2 Use Cases

1:XX.4.2.1 Use Case #1: Basic Reporting

In a basic reporting session, a user uses two systems, the Image Display and the Report Creator, to complete reporting on a study.

1:XX.4.2.1.1 Basic Reporting Use Case Description

The Basic Reporting Use Case is intended to capture the common reporting activities happened during a reporting session. The Image Display handles all user needs for displaying the study and the Report Creator handles all user needs for report creation.

Note: Figure 1:XX.4.2.2-1 shows a high level workflow and highlights the user interaction with the two actors involved. This use case is broken down into multiple steps. The steps shown in the diagram are not actual transactions. The interactions between the Image Display and Report Creator during a reporting session are omitted to highlight the user interactions more clearly. The hyperlinks provided in the diagram link to the subsections that describe the corresponding steps with actual transactions in details. Furthermore, the Examples tab contains sample events following this use case.

In this use case,

  • Before reporting starts, the Image Display launches the Report Creator to join a reporting session
  • The Image Display, with the built-in worklist function, has a set of studies waiting for reporting
  • Radiologist uses the worklist to select studies to report
  • Radiologist opens a study in Image Display to view the study images and patient metadata
  • Radiologist reports on the study using the Report Creator
  • While reporting on the study, Radiologist performs measurements and adds annotations on the images using tools provided by the Image Display
  • Radiologist selects some of the measurements made and uses voice commands to auto-populate the report with the selected measurements
  • Radiologist completes and signs off the report and moves on to the next study in the worklist
  • Eventually, Radiologist finishes all studies in the reporting worklist and closes the applications

Note: In more complex scenarios, separate Worklist Client can be used to drive the Image Display and Report Creator, while the Image Display can launch separate Evidence Creator on demand to perform advanced visualization and measurements. See Use Case 2 for an example.

1:XX.4.2.1.2 Basic Reporting Process Flow
RadiologistImage DisplayReport CreatorOpen reporting sessionStep 1Launch applicationloopSelect Patient and StudyOpen Study and show Chest X-RayStep 2Measure area of PneumothoraxStep 3Dictate ReportSelect measurements as seen in imagesStep 4Auto-populate report with selected measurementsSign-off ReportStep 5Close reporting sessionStep 6


Figure 1:XX.4.2.2-1: Basic Reporting Flow in IRA Profile

1:XX.4.2.1.2.1 Step 1: Open Reporting Session

When a radiologist starts reporting, the Image Display, as a Driving Application, starts a reporting session.

Note that there is no explicit creation of a session. If the Hub receives a session (i.e. topic ID) that does not already exist, then the Hub will automatically create the session and add the subscriber (i.e. Image Display) to the session.

The Image Display subscribes to events so that it can:

  • Receive events published by other Subscribers
  • Receive the version ID of any events necessary for content sharing (See Responsiblities of a FHIRcast Hub and a Subcriber for more information)
  • Receive synchronization error events from the Hub or from other Subscribers.

Once the Image Display completed its subscription, it launches the Report Creator. The Report Creator, as a Synchronizing Application, can follow the context and content events automatically.

Note that launching the Report Creator (or any Synchronizing Application) by the Image Display (or any Driving Application) may be implemented in different ways. For example, the Synchronizing Application can be started and terminated, or it can be put in focus and minimize when not needed but keep running in the background for efficiency, or a combination.

When launched, the first thing that the Report Creator does as a Synchronizing Application is to subscribe to the reporting session. The information about the Hub and the session is provided by the Image Display during launch.

Furthermore, the Report Creator queries the Hub to get the current context to ensure it has the latest context and content. Since the reporting session has just begun, and the Image Display has not yet opened any report context, the result of the query will be empty.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorStep 1: Open Reporting SessionOpen reporting sessionReady to start reporting(Generate new session ID)Subscribe to reporting session [RAD-X1](session 12345)Create a new sessionif session ID does not existAdd Image Display to sessionAcceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionLaunch ApplicationSubscribe to reporting session [RAD-X1](session 12345)Add Report Creator to sessionAcceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionGet Current Context [RAD-X6](catch up with current context and content)Return empty context


Figure 1:XX.4.2.1.2.1-1: Open Reporting Session Flow in IRA Profile

1:XX.4.2.1.2.2 Step 2: Open Study in Context

When the radiologist selects a study in the worklist in the Image Display, as a Driving Application, opens a new report context. Once the Hub accepted the event, it broadcasts the event to all Subscribers.

The Report Creator, as a Synchronizing Application, receives the event and opens the corresponding procedure for the study.

Furthermore, the event has a version ID. For the Image Display as a Driving Application, including the version ID when submitting the next event allows the Hub to ensure proper event sequence. For the Report Creator as a Synchronizing Application, keeping track of the version ID enables it to check if it missed any prior events. Event sequencing is important for content sharing because all updates and selects are expected to be applied in the same sequence as they are emitted by the Content Creator.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorStep 2: Open Study in ContextSelect Patient and StudyOpen Study and show Chest X-RayOpen Report Context [RAD-X3](event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Create DiagnosticReport Context in session 12345ExampleAcceptDistribute Context Event [RAD-X9](event: id = 1000, ...)Open new reportbased on the received contextSuccess (id = 1000, status = 200)Distribute Context Event [RAD-X9](event: id = 1000, ...)Success (id = 1000, status = 200)Start dictation


Figure 1:XX.4.2.1.2.1-2: Open Study in Context Flow in IRA Profile

1:XX.4.2.1.2.3 Step 3: Add Content (Optional)

Sometimes the radiologist may annotate the images with markups and measurements. When this happened, the Image Display, grouped with the Content Creator, updates the report context at the Hub with new content using Update Report Content [RAD-X5]. The Hub broadcasts the event to all Synchronizing Applications.

When the Report Creator receives and accepts the event, it can apply the updates according to its business logic. For example, it may automatically create a hyperlink in the report, or keeps track of the content in a panel for the user to perform other activities later.

RadiologistRadiologistImage Display /Content CreatorImage Display /Content CreatorHubHubReport CreatorReport CreatorStep 3: Add Contents (Optional)Measure area of PneumothoraxCreate content(new FHIR Observation resource)Update Report Content [RAD-X5]include Observation in content bundleEnsure request version matchescurrent context versionSuccessUpdate content in report contextExampleDistribute Context Event [RAD-X9]same content as receivedInsert pneumothorax area in the reportSuccess (status = 200)Distribute Context Event [RAD-X9]same content as receivedSuccess (status = 200)Fill general report text


Figure 1:XX.4.2.1.2.1-3: Add Content Flow in IRA Profile

1:XX.4.2.1.2.4 Step 4: Select Content (Optional)

Occasionally it is desirable to trigger activities on subscribers based on user navigation. With FHIRcast, this can be achieved using the content selection events.

Content selection can be used in various way:

  • as input for a follow up action (e.g. images or measurements selected by a user in the Image Display as input for hyperlink in the Report Creator)
  • bring something to focus (e.g. user clicks on the measurement in a report in the Report Creator triggers the Image Display to bring the corresponding images to focus)

Sometimes the radiologist selected certain elements (e.g. images, annotation, specific measurements, etc.) in the Image Display. When this happened, the Image Display, grouped with the Content Creator, sends a event to the Hub using Select Report Content [RAD-X6] indicating what contents have been selected. The Hub broadcasts the event to all Subscribers.

When the Report Creator receives the event, it can apply the selection according to its business logic. For example, it can highlight to the user what are selected so that the user can perform some actions. In this example, the radiologist uses a voice command to insert a hyperlink in the report. The Report Creator uses the selected content to generate the hyperlink.

Generally, selecting a content means putting the content in ‘focus’. Note that this profile is agnostic about the user interface implementation of ‘focus’, e.g., it may result in the selected contents being highlighted in the user interface, or it may result in the selected contents being flagged in the backend service. Specific behavior depends on the implementation.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorStep 4: Select Contents (Optional)Select measurements as seen in imagesas current focusSelect Report Content [RAD-X6]Mark selected contentsExampleSuccessDistribute Context Event [RAD-X9]Select referenced report contentSelection can be visible to the user orinvisible in the background tracked by theapplication.Success (status = 200)Distribute Context Event [RAD-X9]Success (status = 200)Auto-populate report with selected measurementse.g. Insert Hyperlink via a voice commandInsert hyperlink in reportwith current focused content


Figure 1:XX.4.2.1.2.1-4: Select Content Flow in IRA Profile

1:XX.4.2.1.2.5 Step 5: Sign-off Report

The radiologist completes dictation and signs off the report on the Report Creator. The Report Creator sends an update event notifying about the report status change (e.g. complete normally, draft complete, sent to transcriptionist, etc.) The Image Display updates the status of the study in its worklist.

In this diagram, the Report Creator closes the report context after it sent the report status update event. Recall that this report context was opened by the Image Display.

Note: Alternatively, the Image Display can close the report context upon successfully processing the report status update event. Both scenarios are valid and which method is used is determined by site configuration of the Image Display and Report Creator.

The Hub sends the update event and the termination event to all Subscribers. Once the Hub successfully processed the termination event, it disallows any further interaction of that closed report context.

Upon receiving the termination event, the Image Display removes the study from its worklist.

Note: The Image Display may have different behavior when processing the termination event depending on the report status of the study. For example, it the status is draft completed, then the Image Display may set the study in a separate Draft worklist for later follow up.

The Report Creator may have some internal mechanism to keep the report for a grace period after signed off and before sending it out to other recipients. The Report Creator persists the report according to its business logic.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorComplete dictate reportPersist reportStep 5: Sign-off ReportSign off reportSet report status to FINALUpdate Report Content [RAD-X5](event: id = 1500,context = DiagnosticReport xxx, update status FINAL)Update DiagnosticReport context in session 12345(event: id = 1500,context = DiagnosticReport xxx, status FINAL)ExampleDistribute Context Event [RAD-X9](event: id = 1500 ...)Update study statusSuccess (id = 1500, status = 200)Distribute Context Event [RAD-X9](event: id = 1500 ...)Success (id = 1500, status = 200)Close Report Context [RAD-X4](event: id = 2000,context = DiagnosticReport xxx)Update DiagnosticReport context in session 12345(event: id = 2000,context = DiagnosticReport xxx)Distribute Context Event [RAD-X9](event: id = 2000,context = DiagnosticReport xxx)Drop study from worklistSuccess (id = 2000, status = 200)Distribute Context Event [RAD-X9](event: id = 2000,context = DiagnosticReport xxx)Success (id = 2000, status = 200)Delete DiagnosticReport context in session 12345(context = DiagnosticReport xxx)ExampleWait for the grace periodSend final reportProceed to next studyRepeat Step 2.Open Report Context [RAD-X3]


Figure 1:XX.4.2.1.2.1-5: Sign-off Report Flow in IRA Profile

The flow above shows the simple case with a sequential switching of report context. In this case, a report context is opened and then closed before the next report context is opened.

In practice, the radiologist is likely to continue with the next study in the worklist without any awareness of the events happening behind the scene. If the initiating Driving Application and terminating Driving Application are different as in this example, then it is possible that the radiologist moves to the next study and hence the Image Display opens a new report context before the Image Display receives the Close Report Context [RAD-X5] event of the reported study.

Such rapid context switching is supported by this profile. The Hub and each Subscriber maintain multiple open context simultaneously. As long as the context is not closed, it still exists. Each event is associated to a particular anchor context. Therefore a Subscriber can reliably match an event to its internal state according to the context ID of the anchor context in the event.

The following diagram shows what can happen in case of rapid switching of the report context.

Rapid Context Switch WorkflowRadiologistRadiologistImage Display(as Driving Appand Content Sharing App)Image Display(as Driving Appand Content Sharing App)HubHubReport Creator(as Synchronizing Appand Driving App)Report Creator(as Synchronizing Appand Driving App)Step 5: Sign-Off Report and Continue with next StudyComplete reporting and sign off reportClose Report Context [RAD-X4]on Study 1(event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Click "Next study"Open Report Context [RAD-X2]on Study 2(event: id = 1111,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)Note that switching study happened before theClose Context event of the previously signed-offstudy is received.Create DiagnosticReport Context in session 12345(event: id = 1111,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)The existing context DiagnosticReport xxx remainsin the Hub but it is not the active context.Distribute Context Event [RAD-X9]of previous study(event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)It is NOT an error if the *-close eventdoes not match the most recent *-open event.Update study statusand drop the study from worklistThis may be done in the background. The studyto be dropped from the worklist does not haveto be the study currently in focus in PACS.SuccessDistribute Context Event [RAD-X3]of previous study(event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)no action requiredSuccessDelete DiagnosticReport context in session 12345(context = DiagnosticReport xxx)


Figure 1:XX.4.2.1.2.1-5b: Rapid Context Switching Flow in IRA Profile

1:XX.4.2.1.2.6 Step 6: Close Reporting Session

Eventually, the radiologist completed all the studies in the worklist and closes the Report Creator. The Report Creator unsubscribes to the reporting session so that it will no longer receives any future events.

The Hub closes the connection to the Report Creator. Note that if there are other Subscribers on the same session, those applications are not affected and will continue to receive notification on the session.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorStep 6: Close Reporting SessionClose applicationUnsubscribe Session [RAD-X7](session 12345)AcceptClose channel to Reporting System


Figure 1:XX.4.2.1.2.1-6: Close Reporting Session Flow in IRA Profile

1:XX.4.2.2 Use Case #2: Complex Reporting

This reporting workflow is more complex because there are 5 systems collaborating closely:

  • Worklist Client: Manages a set of studies waiting for reporting
  • Image Display: Displays the selected study and patient metadata
  • Report Creator: Captures dictation from Radiologist and creates report
  • Evidence Creator: Processes study, provides advanced visualization and produces clinical results
  • Hub: Manages the different application subscriptions, maintains report context and distributes events

In this diagram, a single Evidence Creator performs multiple functions. Alternatively, there can be multiple Evidence Creators, each performing a specific function.

In this use case,

  • The Worklist Client has a set of studies waiting for reporting
  • Radiologist uses the worklist to select studies to report
  • Before reporting starts, the Worklist Client starts the reporting session and launches the Image Display and Report Creator to join the session
  • When Radiologist opens a study in Worklist Client,
    • Image Display automatically synchronizes and views the corresponding study images and patient metadata
    • Report Creator automatically synchronizes and opens a new report for the corresponding study
  • While viewing the study in Image Display, Radiologist clicks the advanced processing button in Image Display to execute the integrated Evidence Creator
  • After launched, Evidence Creator automatically synchronizes and processes the study
  • After finished processing, Evidence Creator shares the outputs back with other applications in the reporting session
  • Image Display automatically shows the outputs from Evidence Creator
  • Radiologist accepts the results in Image Display, which in turn shares the Radiologist decisions as observation with other applications in the reporting session
  • Report Creator automatically updates the report with the Radiologist decisions according to the observation
  • Radiologist completes and signs off the report and moves on to the next study in the worklist
  • Eventually, Radiologist finishes all studies in the reporting worklist and closes the applications
Multiple Applications WorkflowRadiologistRadiologistWorklist ClientWorklist ClientHubHubImage DisplayImage DisplayReport CreatorReport CreatorEvidence CreatorEvidence CreatorStep 1: Prepare Reporting SessionSubscribe to Reporting Session [RAD-X1](session 12345:events = DiagnosticReport-*, syncerror)Create Reporting Session with ID 12345Acceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionStep 2: Launch Applications in Reporting Sessionpar[Launching Image Display and Report Creator simultaneously]Launch Application (Image Display)in session 12345Subscribe to Reporting Session [RAD-X1](session 12345:events = DiagnosticReport-*, syncerror)Acceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionGet Current Context [RAD-X8](catch up with current context and content)Return empty contextLaunch Application (Report Creator)in session 12345Subscribe to Reporting Session [RAD-X1](session 12345:events = DiagnosticReport-*, syncerror)Acceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionGet Current Context [RAD-X8](catch up with current context and content)Return empty contextStep 3: Open Report ContextOpen studyOpen Report Context [RAD-X3](session 12345, event: id = 1000,anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Create DiagnosticReport Context in session 12345(anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)AcceptDistribute Context Event [RAD-X9](session 12345, event: id = 1000,anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Success (id = 1000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 1000,anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Display study zzzSuccess (id = 1000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 1000,anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Open new report for study zzzSuccess (id = 1000, status = 200)Step 4: Launch Additional Application On DemandNeed additional information from Evidence Creator on the current studyLaunch Application (Evidence Creator)in session 12345PACS, not the original requester of the session,launches additional application to join thesession on demand.Subscribe to Reporting Session [RAD-X1](session 12345:events = DiagnosticReport-open, DiagnosticReport-close, syncerror)Only subscribe to DiagnosticReport-open andDiagnosticReport-close events as well as syncerrorAcceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connectionGet Current Context [RAD-X8]on session 12345(catch up with current context and content)Return report context(session 12345:anchor context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Process study zzz(Create bounding boxes on potential nodules)Update Report Content [RAD-X5](session 12345, event: id = 2000,anchor context = DiagnosticReport xxx, add ImagingSelection qqq)AcceptDistribute Context Event [RAD-X9](session 12345, event: id = 2000,anchor context = DiagnosticReport xxx, add ImagingSelection qqq)Success (id = 2000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 2000,anchor context = DiagnosticReport xxx, add ImagingSelection qqq)Display bounding box (from ImagingSelection qqq)on study zzzSuccess (id = 2000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 2000,anchor context = DiagnosticReport xxx, add ImagingSelection qqq)Success (id = 2000, status = 200)Persist results (e.g. DICOM SR)for patient recordStep 5: Create Report ContentVerify and accept results from Evidence CreatorUpdate Report Content [RAD-X5](session 12345, event: id = 3000,anchor context = DiagnosticReport xxx, add Observation abc)Distribute Context Event [RAD-X9](session 12345, event: id = 3000,anchor context = DiagnosticReport xxx, add Observation abc)Update report with contentsfrom Observation abcSuccess (id = 3000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 3000,anchor context = DiagnosticReport xxx, add Observation abc)Success (id = 3000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 3000,anchor context = DiagnosticReport xxx, add Observation abc)Success (id = 3000, status = 200)Step 6: Close Report ContextSign off reportSet report status to FINALSend final reportUpdate Report Content [RAD-X5](event: id = 4000,anchor context = DiagnosticReport xxx, update status FINAL)Update DiagnosticReport context in session 12345anchor context = DiagnosticReport xxx, status FINAL)Distribute Context Event [RAD-X9](event: id = 4000 ...)Update study statusSuccess (id = 4000, status = 200)Distribute Context Event [RAD-X9](event: id = 4000 ...)Success (id = 4000, status = 200)Distribute Context Event [RAD-X9](event: id = 4000 ...)Update study statusSuccess (id = 4000, status = 200)Close Report Context [RAD-X4](session 12345, event: id = 5000,anchor context = DiagnosticReport xxx)Update DiagnosticReport context in session 12345(event: id = 5000,anchor context = DiagnosticReport xxx)Distribute Context Event [RAD-X9](session 12345, event: id = 5000,anchor context = DiagnosticReport xxx)Drop study zzz from worklistSuccess (id = 5000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 5000,anchor context = DiagnosticReport xxx)Close study zzzSuccess (id = 5000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 5000,anchor context = DiagnosticReport xxx)Success (id = 5000, status = 200)Distribute Context Event [RAD-X9](session 12345, event: id = 5000,anchor context = DiagnosticReport xxx)Minimize applicationSuccess (id = 5000, status = 200)Delete DiagnosticReport context in session 12345anchor context = DiagnosticReport xxx)Step 7: Switch Report Context in Reporting SessionThe workflow repeats. Since all the necessary applicationshave already been started, there is no need to relaunchthe applications and establish the subscription.Initial Report Context [RAD-X3](session 12345, event: id = 6000,anchor context = DiagnosticReport kkk)Distribute Context Event [RAD-X9]Distribute Context Event [RAD-X9]Distribute Context Event [RAD-X9]Distribute Context Event [RAD-X9]Step 8: Close ApplicationsClose applicationUnsubscribe Session [RAD-X7](session 12345)AcceptClose channel to Worklist ClientTime elapsed and the other subscriptions lease time expiredClose channel to Image Display, Report Creator and Evidence Creator


Figure 1:XX.4.2.2-1: Complex Reporting in IRA Profile

1:XX.4.2.3 Use Case #3: Interruption and Resume Flow

Occasionally a radiologist is interrupted while reporting on a study. She needs to open a different study (e.g. for consultation purpose) before the study that is currently in progress is ready for sign-off.

This profile permits a new report context to be opened before the previous report context is closed. The Hub can maintain multiple anchor contexts simultaneously within a reporting session. The current context is the most recent anchor context that has been opened but not yet closed. This current context enables all Synchronizing Applications to be synchronized and working on the same context all the time.

Once the interrupting study is complete, the Image Display closes the report context of the interrupting study. The Hub removes the context of the interrupting study and set the current context back to the previously opened study. Note that all associated context and contents remain in the Hub.

By default, the Hub will implicitly generate and distribute new DiagnosticReport-open event for the resumed report context to all subscribers (See Hub Event Producing Requirements for more details.). As a result, all subscribers will resume to the same report context. If an application has business logic to resume something else rather than the previous report context, that application should send a new Open Report Context [RAD-X3] event to set the new report context accordingly.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorStep 2: Open Study in ContextLaunch ApplicationSubscribe to reporting session [RAD-X1]Acceptwith hub.channel.endpointConnect to Notification Channel [RAD-X2]Confirm connetionGet Current Context [RAD-X6](catch up with current context and content)Return empty contextSelect Patient and StudyOpen Study and show Chest X-RayOpen Report Context [RAD-X3](event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Create DiagnosticReport Context in session 12345(event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)ExampleAcceptDistribute Context Event [RAD-X9](event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Open new reportbased on the received contextSuccess (id = 1000, status = 200)Distribute Context Event [RAD-X9](event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)No action requiredSuccess (id = 1000, status = 200)Step 2b: Interruption OccurredReceived an interruption to consult on another studySelectAnotherPatient and StudyOpen Study and show Chest CTOpen Report Context [RAD-X3](event: id = 2000,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)Create DiagnosticReport Context in session 12345(event: id = 2000,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)ExampleAt this moment, the current context is DiagnosticReport aaabecause it is the last context that has been opened and notyet closed.However, the anchor context DiagnosticReport xxx remains inthe Hub's tracking since it has not yet been closed.AcceptDistribute Context Event [RAD-X9](event: id = 2000,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)Open new reportbased on the received contextSuccess (id = 2000, status = 200)Distribute Context Event [RAD-X9](event: id = 2000,context = DiagnosticReport aaarelated context = Patient bbb, ImagingStudy ccc)No action requiredSuccess (id = 2000, status = 200)Start reviewing the new study for consultationStep 2c: Interruption CompleteComplete review for consultation and close studyClose Report Context [RAD-X4](event: id = 3000,context = DiagnosticReport aaa)Close DiagnosticReport aaaDistribute Context Event [RAD-X9](event: id = 3000,context = DiagnositcReport aaa)Close study in consultationSuccessDistribute Context Event [RAD-X9](event: id = 3000,context = DiagnosticReport aaa)Close study in consultationSuccessStep 2d: Resume Previous Report ContextDetect DiagnosticReport xxx remains openGenerate new event to resume(event: id = 4000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Distribute Content Event [RAD-X9](event: id = 4000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Resume report xxxSuccess (id=4000, status = 200)Distribute Content Event [RAD-X9](event: id = 4000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Resume study zzzSuccess (id=4000, status = 200)Resume reporting on study zzz as Step 3


Figure 1:XX.4.2.3-1: Interruption and Resume Flow in IRA Profile

1:XX.4.2.4 Use Case #4: Error Handling Flow

Error handling is driven by two factors:

  • Synchronous vs Asynchronous
  • Subscriber initiated vs Hub initiated
Error Handling Workflow(Initiating)Subscriber(Initiating)SubscriberHubHubSubscribersSubscribersSynchronous Event Processing Error from HubAny context / content change eventse.g. RAD-X3, RAD-X4, RAD-X5, RAD-X6Failed requestReturn errorwith HTTP 4xx or 5xx error codesAsynchronous Event Processing Error from HubAny context / content change eventse.g. RAD-X3, RAD-X4, RAD-X5, RAD-X6Return HTTP 202 AcceptedFailed processingGenerate syncerror eventDistribute SyncError Event [RAD-X10]Synchronous Event Processing Error from SubscriberDistribute Context Event [RAD-X9]Return HTTP 4xx or 5xx error codesGenerate syncerror eventDistribute SyncError Event [RAD-X10]Distribute SyncError Event [RAD-X10]Asynchronous Event Processing Error from SubscriberDistribute Context Event [RAD-X9]Return HTTP 202 AcceptedFailed processingNotify Error [RAD-X11]Return HTTP 200 OKDistribute Context Event [RAD-X9]Distribute Context Event [RAD-X9]Subscriber Network ErrorFailed websocket heartbeat checkRemove Receiver from subscriptionGenerate syncerror eventDistribute SyncError Event [RAD-X10]


Figure 1:XX.4.2.4-1: Error Handling Flow in IRA Profile

Figure 1:XX.4.2.4-2 shows two sample use cases how error handling can be used in reporting.

RadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorWatcherWatcherCase 1: Hub detected errorSelect Patient and Studyto start dictationOpen Report Context [RAD-X3](Study context missing)Detect missing study contextReturn 400 Bad RequestCase 2: Subscriber detected errorSelect Patient and Studyto start dictationOpen Report Context [RAD-X3](Study context present)Return 200 OKOpen report contextDistribute Context Event [RAD-X9](Report context opened)Return 200 OKDistribute Context Event [RAD-X9](Report context opened)Return 200 OKDistribute Context Event [RAD-X9](Report context opened)Return 202 AcceptedDetect that the identifiedpatient context does notmatch the patient referencedin the identified study contextNotify Error [RAD-X11](with SyncError)Return 200 OKDistribute Context Event [RAD-X9](SyncError received)Return 200 OKUpdate dashboard with errorDistribute Context Event [RAD-X9](SyncError received)Return 200 OKDisplay error to userDistribute Context Event [RAD-X9](SyncError received)Return 200 OK


Figure 1:XX.4.2.4-2: Error Handling Example Flows in IRA Profile

1:XX.4.2.5 Use Case #5: Overread Draft Report

A radiologist wants to review a draft report created by a residence. She opens the draft report in the Report Creator. The Report Creator opens a new report context for the draft report, including the corresponding patient and study context. The Image Display receives the event distributed by the Hub and opens the study in context. The radiologist reviews the study associated to the report using the Image Display.

Later a radiologist selects a nodule measurement on the report. The Report Creator sends a content selection event for the observation. The Image Display receives the event and display the observation on the study.

In case a reporting session has not been started when the radiologist reviews the draft report, the Report Creator can start a new reporting session and launch the Image Display to join it.

Overread Draft ReportRadiologistRadiologistImage DisplayImage DisplayHubHubReport CreatorReport CreatorOpen draft report created by residence radiologistopt[Start a new reporting session if not exist]Subscribe to reporting session [RAD-Sub](session 12345)Create a new sessionif session ID does not existLaunch ApplicationSubscribe to reporting session [RAD-Sub](session 12345)Hub adds Image Display to the reporting session.Get Current Context [RAD-X6](catch up with current context and content)Return empty contextOpen Report Context [RAD-X3](event: id = 1000,context = DiagnosticReport xxxrelated context = Patient yyy, ImagingStudy zzz)Create DiagnosticReport Context in session 12345ExampleAcceptDistribute Context Event [RAD-X9](event: id = 1000, ...)Open study zzzSuccess (id = 1000, status = 200)Distribute Context Event [RAD-X9](event: id = 1000, ...)Success (id = 1000, status = 200)View study associated to the draft reportSelect nodule measurement in reoprtSelect Report Content [RAD-X6](event: id = 2000,context = DiagnosticReport xxxcontent = Observation abc)Success (id = 2000, status = 200)Distribute Context Event [RAD-X9](event: id = 2000, ...)Display measurement in Observation abcon study zzzSuccess (id = 2000, status = 200)Distribute Context Event [RAD-X9](event: id = 2000, ...)Success (id = 2000, status = 200)


1:XX.5 IRA Security Considerations

This profile strongly recommends all actors to consider the FHIRcast Security Considerations.

This profile strongly recommends all actors group with an ITI ATNA Secure Application or Secure Node Actor using the Radiology Audit Trail Option.

The ATNA Profile requires actors to implement:

  • Record Audit Event [ITI-20] transaction which would record when and where analysis results are distributed and displayed.
  • Authenticate Node [ITI-19] transaction to further ensure the integrity of transactions using node authentication and communication encryption.

Furthermore, for the HTTP-based transactions, this profile strongly recommends the use of ITI Internet User Authorization (IUA) Profile to ensure that communications are only allowed for authenticated and authorized users and/or systems.

Additionally, although this profile does not specify any particular method for an application to launch other synchronizing applications, this profile strongly recommends the use of SMART App Launch for application launching. In addition to the use of OAuth2 as specified in the ITI IUA profile, FHIRcast extends SMART App Launch with FHIRcast specific OAuth2 scopes that can be used by the Hub to validate if the Subscriber is authorized to invoke the transaction. Furthermore, the authorization server returns the FHIRcast SMART launch parameters which can be used by the synchronizing applications to join the session. See Section 4.1.1 SMART on FHIR for more details.

Note that with FHIRcast, the authentication and authorization is controlled at the time of subscription and per context change request. Once the websocket connections are established, there is no further authorization for event distribution.

The events as defined in this profile contain personal demographic information and clinical information. It is appropriate for products implementing the this profile to include appropriate PHI controls. Specifying such mechanisms and features is outside the scope of this profile.

1:XX.6 IRA Cross-Profile Considerations

Table 1:XX.6-1 describes various actors in various other profiles that might be useful to group with IRA Profile actors.

Table 1:XX.6-1: IRA - Optional Actor Groupings

IMR Actor Might group with Potential Purpose
Report Creator IMR Report Creator To produce multi-media interactive report using the context and content received.
IUA Authorization Client To provide authorization claims when invoking a request with another actor.
IMR Report Creator To receive image references and measurements input from Image Display for the interactive hyperlinks.
Image Display SWF.b Image Display To display patients' studies and share context and content with other synchronized applications
IUA Authorization Client To provide authorization claims when invoking a request with another actor.
IMR Image Display To enhance the interactivity with the Report Creator after the Image Display is launched.
Worklist Client IUA Authorization Client To provide authorization claims when invoking a request with another actor.
Evidence Creator SWF.b Evidence Creator To provide measurements and other evidence data and share the content with other synchronized applications.
IUA Authorization Client To provide authorization claims when invoking a request with another actor.
AIW-I Task Performer To provide an additional method to share the output with other synchronizing applications in a reporting session.
AIR Evidence Creator To support creating the various AI results.
Watcher IUA Authorization Client To provide authorization claims when invoking a request with another actor.
AIW-I Watcher To watch an additional infrastructure for events.
Hub IUA Resource Server To enforce only authorized access to the resources stored in the repository.