Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed

1. Proposed Workitem: Realtime Bidirectional Communication

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. Another use case is for EMR to send a command to switch patient and/or study context to an embedded Image Display or to close it rather than requiring the user to manually switch patient/study or close the viewer.

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.

Embedding an enterprise viewer in EMR is common practice to show imaging studies along with the patient records in an EMR. IHE Invoked Image Display profile facilitates that by defining a standard URL to launch a viewer. IID is close to final text, with the exception that there is an outstanding CP to support automatic switching context or closing the viewer.

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

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.

Use Case 2: Context Sharing between EMR and Universal Viewer

When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study automatically without human intervention. Traditionally this context switching is done using vendor specific proprietary methods that requiers custom integration.

In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context. This may be done automatically using a proprietary method today, or has to be done manually. This can potentially cause patient safety issue if the viewer is not reliably closed while the user switches context to another patient / study in the EMR. The user may be mistakenly viewing a wrong study for the wrong patient and hence and result in incorrect diagnosis.

4. Standards and Systems

Systems:

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

Standards:

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

5. Discussion

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.

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.

5. Technical Approach

<If any context or "big picture" is needed to understand the transaction, actor and profile discussion below, that can be put here>

<READ PROPOSER HOMEWORK IN Proposal Effort Evaluation FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >

Actors

(NEW) <List possible new actors>
<List existing actors that may be given requirements in the Profile.>

Transactions

(NEW) <List possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>
<List existing transactions that may be used and which might need modification/extension.>

Profile

<Describe the main new profile chunks that will need to be written.>
<List existing profiles that may need to be modified.>

Decisions/Topics/Uncertainties

<List key decisions that will need to be made, open issues, design problems, topics to discuss, and other potential areas of uncertainty>
<Credibility point: A proposal for a profile with any degree of novelty should have items listed here. If there is nothing here, it is usually a sign that the proposal analysis and discussion has been incomplete.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List real-world practical or political risks that could impede successfully fielding the profile.>

<Technical risks should be noted above under Uncertainties.>

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)