Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed

1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting

• Proposal Editor: Kinson Ho, David Vining, Peter O'Toole
• Editor: Kinson Ho
• Domain: Radiology

Summary

In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.

FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.

With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.

HIMSS/SIIM has published a whitepaper regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.

IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.

2. The Problem

As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.

3. Key Use Case

1. Use Case 1: Interactive Multimedia Reporting

A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static evidence for long-term reference instead of real-time communication or composition. Most PACS will create these DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence objects are good resources for subsequent retrieval when viewing an IMR, but not good payload candidates for real-time communication during a reporting session. As the image-centric specialist generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the permanent record.

4. Standards and Systems

Systems:

• PACS (Image Manager and Image Display)
• Reporting System (Report Creator)
• AI Manager (Evidence Creator)

Standards:

• FHIRcast
• HL7 Smart Web Messaging
• Smart on FHIR for authentication and authorization
• FHIR Observation for message payload

5. Technical Approach

Actors

New Actors:

• Data Publisher
• Data Subscriber
• Data Hub

These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.

Existing actors:

• For the IMR use case
  • Report Creator is the Data Subscriber
  • Image Display is the Data Publihser

• For the EMR with embedded viewer use case
  • Image Display Invoker is the Data Publisher
  • Image Display is the Data Subscriber

Transactions

New transactions:

• [RAD-X1] Subscribe Event - FHIRcast
• [RAD-X2] Publish Event - FHIRcast
• [RAD-X3] Notify Event - FHIRcast
• [RAD-X4] Unsubscribe Event - FHIRcast
• [RAD-X5] Launch Application - OAuth2 / SMART on FHIR

Content Modules:

• IMR Measurements - FHIR Observation
• Study Open/Close - FHIRcast
• Patient Open/Close - FHIRCast

Profile

There can be two approaches to the implementation:

• Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors
• Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors

Decisions/Topics/Uncertainties

• IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text

• IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.

• FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).

• FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.

• Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.

• FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.

Task Breakdowns

• Decide on which approach for the profile development
• Extend the existing IMR and IID use cases to accommodate RTBC steps
• Define the new transactions
• Define the message content (e.g. using FHIR Observation) for IMR use case
• Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case

Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.

6. Support & Resources

HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.

7. Risks

• HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.

• Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.

8. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx% for MUE
• yy% for MUE + optional

Editor:

Kinson Ho

SME/Champion:

• David Vining (MD Anderson / VisionSR)
• Peter O'Toole (mIntuition)