Interactive Multimedia Reporting (IMR)

From IHE Wiki
Jump to: navigation, search


1. Proposed Workitem: Interactive Multimedia Reporting (IMR)

  • Proposal Editor: David Kwan, Elliot Silver, Kinson Ho, Seth Berkowitz, Karen Thullner, Christopher Roth, MD
  • Editor: Kinson Ho
  • Domain: Radiology

2. The Problem

IMR provides imaging findings and results in a contextual, educational/informative, and graphic manner that are easily accessible by providers and patients from anywhere. Interactive Multimedia Reporting (IMR) has been defined (by the HIMSS-SIIM Enterprise Imaging Workgroup) as “interactive medical documentation that combines clinical images, videos, sound, imaging metadata, and/or image annotations with text, tables, graphs, anatomic maps, and/or educational resources to optimize communication between medical professionals and their patients.” Interactive Multimedia Reporting improves communications and workflow; by providing clear, concise and contextual information for stakeholder users of clinical reports. Current IMR implementations that utilize proprietary technologies and techniques to create and distribute reports with rich content face challenges with wide scale sharing of such reports.

IMR Benefits:

  • Linked and/or embedded images and annotated images saves surgeon and oncologist look-up time during patient treatment planning, and ensure correct patient look-up
  • Improved radiologist workflow for comparison imaging, and patient study follow-up
  • Time savings for radiologists, especially for repetitive data entry and follow-up queries during radiologist reporting sessions
  • Improved accuracy (reduced data entry errors) and precision, through auto- insertion of images, measurements, links and annotations.
  • Improved consumption of rad reporting:
    • Improved Report Clarity and Consistency
    • Improved patient satisfaction ratings, i.e., HCAHPS (Hospital Consumer Assessment of Healthcare Providers and Systems) survey scores
  • Higher quality data source for artificial intelligence and machine-learning

Despite these potential benefits, IMR has not been widely adopted, partially due to interoperability limitations. Creators and diagnosticians reviewing the images do not include alphanumeric embedded annotations to identify and classify findings due to lack of integration of tables, graphs, diagrams, or anatomic maps with the textual report elements within the systems employed. Where IMR has been practiced, users external to these organizations find the links, tables, graphs, and anatomic maps in these reports inaccessible. An IHE profile for IMR would define standardized formats and exchange mechanisms usable by report creators and consumers at both the institution at which the report is created and at external institutions. Hyperlinks to images would be functional, and able to display referenced images by both internal and external authorized report consumers.

3. Key Use Case

The following use case illustrates current typical workflow, and an IMR implementation state where a profile could enhance the workflow.

Current State Use Case:

  • 1. Radiologist choses patient study from the worklist. Images are launched in the PACS system. The reporting session begins.
  • 2. Initiates a report creator/reporting application session using a reporting template.
  • 3. Radiologist reviews images and begins a reporting session with an active reporting template in the report creator/reporting application.
  • 4. Radiologists perform measurements on significant images and findings.
  • 5. Radiologist dictates observations and findings including measurements, image number and series of noted observations into the active reporting template.
  • 6. Radiologist completes and signs off the report; the report and images are sent to EMR and VNA.
  • 7. Oncologist retrieves and reviews the report in the EMR client, including using manual navigation of image study to find image and findings noted in patient imaging report.

IMR Implementation Use Case:

  • 1. Radiologist choses patient study from worklist; images are launched in PACS system; begins reporting session.
  • 2. Initiates a report creator/reporting application session using a reporting template.
  • 3. Radiologist reviews images and begins a reporting session with an active reporting template (based on procedure code) in the report creator/reporting application
  • 4. Radiologist opens the IMR from a prior study (from 6 months ago) on PACS workstation. When image hyperlinks on the prior report are clicked, a viewport in the PACS workstation displays the appropriate image instance UID in the context of the parent DICOM series.
  • 5. Radiologists continue to review current images while comparing them to prior images. Begins reporting on the active reporting template.
  • 6. The radiologist measures a lung nodule on an axial image. The measurement and source image instance UID are transmitted in real time to the reporting application. Measurements and instance UID of source images are stored in the report as coded metadata and text in the narrative.
  • 7. Radiologist completes and signs off the report. The report and images are sent to EMR and VNA.
  • 8. The oncologist retrieves and reviews the report in the EMR client. The report contains hyperlinks to specific findings. The hyperlinks launch the enterprise viewer to display the appropriate image instance UID in the context of the parent DICOM series.


IMR Key Use Case Pic.png

4. Standards and Systems

Systems:
Primary Systems Secondary Systems
* PACS * Imaging Modality
* Report Creator * A.I. App + Others
* RIS/EMR/HIS * Image Displays
* Report/Image Display * HIE, Patient portal


Standards:
PACS and Report Creator Communications IMR Output and Communications
* FHIRcast * FHIR (DiagnosticReport, ImagingStudy and Observation )
* DICOMweb WADO-RS

5. Technical Approach

IMR Technical Approach Picture.jpg


New actors:

  • Data Hub
  • Data Publisher
  • Data Subscriber

Existing actors:

  • Image Manager / Image Archive
  • Image Display
  • Report Creator
  • Report Repository
  • Report Reader
  • Image Display Invoker

New transactions (standards used):

There are two main components of IMR:

  • Real time communication between Image Display and Report Creator about data points
  • Communicate multimedia report from Report Creator to Report Reader

Real time communication between Image Display and Report Creator:

  • [Rad-X1] Subscribe Event
  • [Rad-X2] Publish Event
  • [Rad-X3] Notify Event
  • [Rad-X4] Unsubscribe Event

Rad-X1 to Rad-X4 are based on FHIRcast. FHIRcast supports websocket by default and webhook (i.e. URL callback) as optional. Rad-X1 to Rad-X4 are infrastructure focus and content agnostic. Several payload contents will be defined in IMR:

  • From Image Display to Report Creator
    • SOP Instance UID (for key images) via FHIR ImagingStudy
    • Measurements via FHIR Observation
    • Optional: Current Field ID
  • From Report Creator to Image Display
    • Current Field ID

Note that the introduction of new actors Data Hub, Data Publisher and Data Subscriber is intended to provide a common context-sharing infrastructure that can be useful in multiple applications and scenarios. IMR is the first use case.

FHIRcast, the hub.url, needs to be communicated by the driving application (i.e. Image Display/Data Publisher) to the App (i.e. Report Creator). FHIRcast recommends using ‘SMART on FHIR’ (EMR launch or standalone launch) for authentication, authorization, and communicating the hub.url as part of the scope along with other parameters in the granted OAuth access token. Based on current deployments, launching a Report Creator from Image Display is often proprietary based on some context sharing. Therefore, IMR will not mandate ‘SMART on FHIR’ as a mechanism to communicate the hub.url, but as a prerequisite for IMR. In the future, ‘SMART on FHIR’ can be a separate profile (may be done in ITI, along with IUA).

[Side Note: Once FHIRcast is defined, we can add to IID support for the Patient-open|close event as well as the ImagingStudy-open|close events. These are missing and identified in CP-RAD-xxx that is currently blocking IID from final text]

Communication of multimedia report between Report Creator and Report Reader:

  • [Rad-Y1] Store Multimedia Report
  • [Rad-Y2] Display Report

Resulting report is encoded and communicated using FHIR DiagnosticReport as a ‘container’:

  • References FHIR Observation as details.
    • E.g. The FHIR Observation can be used to capture measurements (Not MUE)
  • References FHIR ImagingStudy as context
    • E.g. SOP Instances with WADO-RS endpoints
  • The full text report is defined in DiagnosticReport.conclusion. The text report may include embedded markup using FHIRPath syntax to refer to a particular referenced Observation or referenced ImagingStudy content

IMR will focus on a push model for report communication using FHIR PUT. The push model is based on the fact and this is by far the most common model used based on HL7 ORU within an enterprise. No query/retrieve transaction is necessary as a result of this model. In the future, cross enterprise report communication can be added as well as query/retrieve report support.

Impact on existing integration profiles It is an extension to SWF to handle reporting. IMR is an alternative to the existing Report Workflow (RWF), which has low adoption in the real world.

SINR can work together with IMR in the sense that SINR provides the detailed measurement information from US Modality to Image Manager using DICOM SR. Image Display retrieves the measurement and publishes the measurement as FHIR Observation to the Report Creator.

IMR Report Reader / Image Display can use WIA WADO-RS to retrieve the referenced images in the DiagnosticReport.imagingStudy.

An IID Image Display may support IMR to display multimedia content. Rad-106 Invoke Image Display extends the study launch API to launch a specific series. This enables the Report Reader to launch the parent series of a given image or observation in the report.

Breakdown of tasks that need to be accomplished

  • Specify Rad-X1 to Rad-X4 using FHIRcast
    • Specifically, define the event payload using FHIR Observation and FHIR ImagingStudy
      • Discuss what data points besides measurements should be defined in IMR using FHIR Observation
      • Define the IMR payload for communicating current field ID
    • Discuss if webhook should be mandatory for Data Hub or not
    • Discuss if other Data Publisher should be included besides Image Display in IMR
  • Specify Rad-Y1 using FHIR DiagnosticReport and using HTTP PUT
    • DiagnosticReport.result is using FHIR Observation
      • derivedFrom attribute includes the ImagingStudy reference with endpoint specifying the parent series
    • DiagnosticReport.imageStudy is using FHIR ImagingStudy
    • DiagnosticReport.conclusion is the text report with optional embedded FHIRPath markup to reference particular observation or imagingStudy
    • Optionally, DiagnosticReport.presentedForm can contain the actual image in base64 encoded
  • Specify Rad-Y2
    • Specifically, require the Report Reader to interpret the referenced ImagingStudy to find the referenced images and then use the endpoint attribute to retrieve the objects (using WADO-RS)
    • Require the Report Reader to present the measurements specified in the Observation in the report in a meaningful way.
    • Require the Report Reader to present each referenced image and observation as a clickable / hyperlink content.
      • When clicked, the Report Reader will display the image instance in the context of the parent series (using either Observation.derivedFrom.endpoint or derived from the WADO-RS link specified in ImagingStudy.endpoint)
      • The Report Reader can either retrieve the parent series using WADO-RS or launch a viewer using IID
  • [Rad-106] Extend the transaction to support launching a specific series in addition to launching a specific study.

6. Support & Resources

The HIMSS SIIM Enterprise Imaging Community Workgroup for Interactive Multimedia Reporting has already coalesced a number of collaborators. Many of these collaborators have contributed to the proposal and are interested in working on the profile.

  • Healthcare: Chris Roth (Duke), Les Folio (NIH), Cree Gaskin (UVA), Seth Berkowitz (Beth Israel/Harvard), , Alex Aisen (Independent), Shawn Clark (University of Miami), David Vining (MD Anderson).
  • Vendors: Elliot Silver (Argentix Informatics), Kinson Ho (Change), Peter O’Toole (mTuitive), James Raynor (Epic), Nathan Gurgel (Fujifilm), Karen Thullner/Kurt Allen (PenRad Technologies), Adam Coal (Smile CDR), Alexander Goel (CAP/ACR/PuraJuniper).

Healthcare and industry participants bring their implementation experiences and clinical understanding to progress the IMR from theory to practice.

7. Open Issues

  • To what degree will legacy systems be able to be actors in this profile?
  • Will a push model between Report Creator and Report Repository be sufficient? Is a full FHIR server required?
  • IMR will not specify the trigger when the Image Displays the real time user action (e.g. measurements) to the Data Hub. IMR will only define the real time communication using FHIRcast and the payload. Is this sufficient?
  • Since there are many existing proprietary integrations between Image Display and Report Creator, IMR will not mandate the use of SMART on FHIR and define how the hub.topic and hub.url is communicated. However, these are prerequisites and will be communicated using existing integration between Image Display and Report Creator. Is this acceptable?
  • Given the complexity of multimedia reports, the report structure and transport will be based on FHIR DiagnosticReport and using FHIR for transport. This will be totally separate from existing common HL7 ORU for radiology reports. Many reporting systems can actually produce different report output already.
  • Should the FHIRcast portion be specified as an independent profile since it is by itself useable in other context?

Risks

  • Market demand for IMR (including changes to reimbursements).
  • The inclusion of technology making use of HL7 FHIR may mitigate the risk of developing an outdated profile.
  • Lack of an IMR profile would lead to the numerous use-case driven solutions and technologies and lack interoperability between systems.

8. Tech Cmte Evaluation

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

xx% for MUE yy% for MUE + optional Editor:

Editor: Kinson Ho

SME/Champion: Dr. Chris Roth