Realtime Bidirectional Communication

1. Proposed Workitem: Realtime Bidirectional Communication

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

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

1. 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. Traditionally this context switching is done using vendor specific proprietary methods. 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.

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.