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

From IHE Wiki
Jump to navigation Jump to search
 
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
  
 +
==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.
  
''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.''
+
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.
  
''<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.>''
+
==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.
 +
 
 +
 
 +
<center>[[Image: IMR_Key_Use_Case_Pic.png|700px]]</center>
 +
 
 +
==4. Standards and Systems==
 +
 
 +
 
 +
{| class="wikitable"
 +
|+ 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 
 +
|}
  
  
==1. Proposed Workitem: Interactive Multimedia Reporting (IMR)==
+
{| class="wikitable"
 +
|+ Standards:
 +
|-
 +
! PACS and Report Creator Communications  !! IMR Output and Communications   
 +
|-
 +
| * FHIRcast  || * FHIR (DiagnosticReport, ImagingStudy and Observation )
 +
|-
 +
| * DICOMweb WADO-RS ||
 +
|-
 +
|}
  
* Proposal Editor: David Kwan, Elliot Silver, Kinson Ho, Christopher Roth, Les Folio, Andrei Leontiev, Seth Berkowitz
+
==5. Technical Approach==
* Editor: Kinson Ho
 
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
* Domain: Radiology
 
<nowiki> remove this tag
 
[[Category:DomainAbbreviation]]
 
</nowiki> remove this tag too
 
  
==2. The Problem==
+
<center>[[Image: IMR Technical Approach Picture.jpg|700px]]</center>
  
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==
+
'''New actors:'''
 +
* Data Hub
 +
* Data Publisher
 +
* Data Subscriber
  
The following use case illustrates current typical workflow, and places where a profile could enhance the workflow.
+
'''Existing actors:'''
 +
*Image Manager / Image Archive
 +
* Image Display
 +
* Report Creator
 +
* Report Repository
 +
* Report Reader
 +
* Image Display Invoker
  
 +
'''New transactions (standards used):'''
  
<center>[[Image: IMR Workflow Revised.png]]</center>
+
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
  
Lung Cancer Follow-up CT Report Use Case:
+
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.
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.''
+
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).
  
*  2. Initiates a report creator/reporting application session using a reporting template, “LDCT reporting template” triggered by LDCT procedure code for Lung Cancer Screening.
+
[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]
  
* 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.
+
Communication of multimedia report between Report Creator and Report Reader:
 +
* [Rad-Y1] Store Multimedia Report
 +
* [Rad-Y2] Display Report
  
* 4. Radiologist reviews images and begins a reporting session with an active reporting template in the report creator/reporting application.
+
Resulting report is encoded and communicated using FHIR DiagnosticReport as a ‘container’:
* 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.
+
* 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
  
*  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.
+
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.
  
*  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.
+
'''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.
  
*  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.
+
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.
  
*  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.
+
IMR Report Reader / Image Display can use WIA WADO-RS to retrieve the referenced images in the DiagnosticReport.imagingStudy.
  
* 10. The reporting tool creates a graph of lung nodule size over time.  The graph is saved into the report.
+
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.
  
* 11. Radiologist inserts a reference link for ACR Lung Reporting and Data Systems (ACR LungRads) into 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.
  
* 12. Radiologist completes and signs off the report; the report and images are sent to EMR and VNA.
+
==6. Support & Resources==
  
* 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.
+
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.
  
* 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.
+
* '''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).
  
{| style="width:95%" border="1" cellpadding="1"
+
Healthcare and industry participants bring their implementation experiences and clinical understanding to progress the IMR from theory to practice.
<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. Standards and Systems==
+
==7. Open Issues==
  
''<List existing systems that are/could be involved in the problem/solution.>''
+
* 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?
  
''<If known, list standards which might be relevant to the solution>''
+
==Risks==
  
==5. Discussion==
+
* 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.  
  
''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
+
==8. Tech Cmte Evaluation==
:''<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?>''
 
  
 +
Effort Evaluation (as a % of Tech Cmte Bandwidth):
  
''<This is the brief proposal.  Try to keep it to 1 or at most 2 pages>''
+
xx% for MUE
 +
yy% for MUE + optional
 +
Editor:
  
 +
Editor: Kinson Ho
  
''<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>'' [[Category:Templates]]
+
SME/Champion: Dr. Chris Roth

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