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

From IHE Wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
==1. Proposed Workitem: Interactive Multimedia Reporting (IMR)==
 
==1. Proposed Workitem: Interactive Multimedia Reporting (IMR)==
  
−
* Proposal Editor: David Kwan, Elliot Silver, Kinson Ho, Christopher Roth, Les Folio, Andrei Leontiev, Seth Berkowitz
+
* Proposal Editor: David Kwan, Elliot Silver, Kinson Ho, Seth Berkowitz, Karen Thullner, Christopher Roth, MD
 
* Editor: Kinson Ho
 
* Editor: Kinson Ho
−
* Date:    N/A (Wiki keeps history)
 
−
* Version: N/A (Wiki keeps history)
 
 
* Domain: Radiology
 
* Domain: Radiology
  
 
==2. The Problem==
 
==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.
+
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.
  
−
==3. Key Use Case==
+
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
  
−
The following use case illustrates current typical workflow, and places where a profile could enhance the workflow.
+
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==
  
−
<center>[[Image: IMR Workflow Revised.png|1000px]]</center>
+
The following use case illustrates current typical workflow, and an IMR implementation state 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.
+
'''Current State Use Case:'''
  
−
* 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.
+
* 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.
  
−
*  4. Radiologist reviews images and begins a reporting session with an active reporting template in the report creator/reporting application.
+
'''IMR Implementation Use Case:'''
−
*  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.
+
* 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.  
  
−
*  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.
+
<center>[[Image: IMR_Key_Use_Case_Pic.png|700px]]</center>
−
 
 
−
*  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.
 
−
 
 
−
 
 
−
{| style="width:95%" border="1" cellpadding="1"
 
−
<center>'''Summary of Tasks'''</center>          
 
−
|-
 
−
|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==
 
==4. Standards and Systems==
Line 108: Line 74:
 
! PACS and Report Creator Communications  !! IMR Output and Communications     
 
! PACS and Report Creator Communications  !! IMR Output and Communications     
 
|-
 
|-
−
| * FHIRcast  || * Imaging Modality 
+
| * FHIRcast  || * FHIR (DiagnosticReport, ImagingStudy and Observation )
 
|-
 
|-
−
| * DICOM SR  || * PDF 
+
| * DICOMweb WADO-RS ||  
 
|-
 
|-
−
| * Restful services/Web services  || * RTF
 
 
|}
 
|}
  
−
==5. Discussion==
+
==5. Technical Approach==
 +
 
 +
<center>[[Image: IMR Technical Approach Picture.jpg|700px]]</center>
 +
 
 +
 
 +
'''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
  
−
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.)
+
SME/Champion: Dr. Chris Roth
−
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.
 

Latest revision as of 09:38, 12 October 2021


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

Retrieved from "http://wiki.ihe.net/index.php?title=Interactive_Multimedia_Reporting_(IMR)&oldid=126370"