Interactive Multimedia Reporting (IMR)

This template is for one or two page IHE workitem proposals for initial review. To create a new proposal, first log in to the Wiki (or create an account if you don't already have one). Then create an appropriately named new Wiki page (see the editing instructions linked to "Help" at left. Then come back to this page, click "edit" above, select and copy the contents of this page and paste the contents into your newly created page.

<Delete everything in italics and angle brackets and replace with real text. This means delete the angle bracket character and the two quote marks too.>

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

remove this tag [[Category:DomainAbbreviation]] remove this tag too

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.

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. Standards and Systems

<List existing systems that are/could be involved in the problem/solution.>

<If known, list standards which might be relevant to the solution>

5. Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>

<This is the brief proposal. Try to keep it to 1 or at most 2 pages>

<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>