Difference between revisions of "Interactive Multimedia Reporting (IMR)"

From IHE Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
 
  
 
==1. Proposed Workitem: Interactive Multimedia Reporting (IMR)==
 
==1. Proposed Workitem: Interactive Multimedia Reporting (IMR)==

Revision as of 16:38, 10 August 2021


1. Proposed Workitem: Interactive Multimedia Reporting (IMR)

  • Proposal Editor: David Kwan, Elliot Silver, Kinson Ho, Christopher Roth, Les Folio, Andrei Leontiev, Seth Berkowitz
  • Editor: Kinson Ho
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

2. The Problem

IMR provides imaging findings and results in a contextual, educational/informative, and graphic manner that meets the modern accessibility expectations of providers and patients. 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.

3. Key Use Case

The following use case illustrates current typical workflow, and places where a profile could enhance the workflow.


IMR Workflow Revised.png



Lung Cancer Follow-up CT Report Use Case: Patient is a 65-year-old male with 3-year history of lung cancer screening, previously a LungRADS 1 patient, last Low Dose CT (LDCT) had been diagnosed with LungRADS 3. Patient recommended to have a 6-month follow-up LDCT. Radiologist presented with a patient study for 6-month follow-up LDCT for Lung Cancer Screening.

  • 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, “LDCT reporting template” triggered by LDCT procedure code for Lung Cancer Screening.
  • 3. LDCT reporting template is auto-populated patient information and history (from EMR), and study information from (RIS/PACS), image acquisition information/data and technologist notes from image modality to the active reporting template.
  • 4. Radiologist reviews images and begins a reporting session with an active reporting template in the report creator/reporting application.
  • 5. Scan parameters and dose information are transmitted from the modality via DICOM SR Evidence Document and imported into the active reporting template. Data imported into the active reporting template is retained in the IMR as coded metadata.
  • 6. AI Results Evidence Document from an automated lung nodule detection software tool is imported into the reporting tool. The radiologist selects appropriate measurements for inclusion in the final report. Measurements and instance UID of source images are stored in the report as coded metadata and text in the narrative.
  • 7. Radiologist opens the IMR from the prior study 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.
  • 8. 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.
  • 9. The reporting application queries the PACS DICOMweb interface to retrieve a thumbnail image of the lung nodule which is inserted as an embedded image into the report. The image is embedded as a hyperlink to the instance UID of the source image.
  • 10. The reporting tool creates a graph of lung nodule size over time. The graph is saved into the report.
  • 11. Radiologist inserts a reference link for ACR Lung Reporting and Data Systems (ACR LungRads) into the report.
  • 12. Radiologist completes and signs off the report; the report and images are sent to EMR and VNA.
  • 13. IMR file contains structured, machine-readable content that can drive downstream workflows i.e., plain language letter sent to a patient specific to the ACR LungRads code.
  • 14. Oncologist retrieves and reviews the report in the EMR client. The report contains hyperlinks to specific findings. When clicked, the hyperlinks launch the enterprise viewer to display the appropriate image instance UID in the context of the parent DICOM series.


Summary of Tasks
1 Defining the ability for IMR consumers to launch images from image hyperlinks on a report, a viewport in the PACS workstation displays the appropriate image instance UID in the context of the parent DICOM series.
2 Define the ability for the report creator to query and retrieve a thumbnail image of source image, which is inserted as an embedded image into the final report. The image is embedded as a hyperlink to the instance UID of the source image.
3 Define the ability of an Oncologist to retrieve and review an Interactive Multimedia Report in an EMR client. The report contains hyperlinks to specific findings. When clicked, the hyperlinks launch the enterprise viewer to display the appropriate image instance UUID in the context of the parent DICOM series.
4 Define the ability for insertion of modality scan parameters and dose information into an active reporting template as coded metadata, for insertion into a final report
5 Define the interoperability for the ability to include measurements in the final report. The measurement and source image instance UID are transmitted in real time to the report creator application. Measurements and instance UID of source images are stored in the report as coded metadata and text.
6 Define the ability for importation of AI Results into the report creator for insertion into a final report.
7 Define the ability for the insertion of reference links into the final report, e.g., reference page of ACR Lung Reporting and Data Systems (ACR LungRads).
8 Define the ability for insertion of diagrams, graphs and key images into a final report,
9 Define the ability for sharing IMR structured and machine-readable content with downstream workflows, extraction ACR LungRads codes to trigger the generation of a Plain language letter sent to a patient for follow-up.

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 * Imaging Modality
* DICOM SR * PDF
* Restful services/Web services * RTF

5. Discussion

Provider and patient interest in IMR are growing. In support of this evolving practice and technology, The HIMSS-SIIM Enterprise Imaging Workgroup (HSEIWG) has published this article in the Journal of Digital Imaging in June 2021 , “Multispecialty Enterprise Imaging Workgroup Consensus on Interactive Multimedia Reporting Current State and Road to the Future: HIMSS‑SIIM Collaborative White Paper", Journal of Digital Imaging, ttps://doi.org/10.1007/s10278-021-00450-5 . This discussion in a major journal is a summary of the current state of IMR. Along with other complementary activities, such as the HIMSS-SIIM Body part labelling (nomenclature) initiative, is also an indication of community interest in IMR. The HSEIWG is developing a follow-up whitepaper on IMR Technical Developments Requirements and Considerations. We can expect a strong user-community interest and voice in this work (similar to the HSEIWG engagement in EBIW.) To date, the few institutions that have successfully deployed IMR have predominantly used single-vendor RIS and PACS, and tailored dictation systems. Interoperability between multiple vendors is needed to enable wider use of IMR: needs to be passed between the viewer and the reporting application; some form of rich text needs to pass from the reporting application to the EMR; etc. IHE has a strong history of profiling solutions such as this that require consensus between multiple vendors or systems. An IHE profile will define the ability to implement IMR, and how it is conveyed in an agnostic or vendor neutral technical profile; defining the ability to launch a viewer in the image context presented from the IMR link.