Realtime Bidirectional Communication

1. Proposed Workitem: Realtime Communication

• Proposal Editor: Kinson Ho
• Editor: Kinson Ho
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

2. The Problem

As a health system becomes more sophisticated including many different systems (EMR, PACS, dictation system, etc.) with more advanced integrated use cases in which a user uses multiple systems simultaneously and need information to flow between these systems in realtime to keep them in sync and in context, there is a growing need to support more sophisticated realtime bidirectional communication between systems. Without this realtime communication method, often time the user can experience noticeable delays, leading to a suboptimal user experience; or worse, the information becomes out of context without notice and eventually causing wrong diagnosis.

3. Key Use Case

1. Use Case 1: Interactive Multimedia Reporting

A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI, etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture evidence for long-term reference instead of real-time communication or composition. Most PACS will create these evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good candidates as the payload for real-time communication during a reporting session. As the image-centric specialist captures measurements, regions of interest, and other data points, the PACS should provide those data points to the reporting system in real-time without introducing any unnecessary 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 the 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 new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.

4. Standards and Systems

Systems:

• PACS (Image Manager and Image Display)
• EMR
• Dictation System (Report Creator)

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 a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.

• FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.

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