Orders-Based Imaging Workflow

1. Proposed Workitem: Orders-Based Imaging Workflow for Mobile (OBIWm)

• Proposal Editor: Chris Lindop
• Proposal Contributors: Jonathan Whitby
• Editors:
• Contributors: HL7/WG20/DICOM II
• Domain: Radiology

Summary

A new Orders-Based Imaging Workflow Profile would specify how to integrate web-enabled imaging devices with a FHIR-based/DICOMweb-based workflow.

The current IHE orders-based imaging workflow, SWF.b, profiles orders-based imaging workflow with HL7 v2.x and DICOM DIMSE. Developed, in the late 1990’s before the current web-based protocols were established. While the early standards are implemented extensively, they are limited and inefficient as compared to the current HL7 FHIR and DICOMweb protocols.

The industry is quickly adapting new web-based protocols for the electronic medical records, Utilizing FHIR and DICOMWeb. Without an implementation guide to profile resource utilization and FHIR to DICOM mapping, vendors are developing a mix of the older protocols with the new, utilizing different protocol mixes and adaptations or proprietary extensions.

2. The Problem

Web-enabled Orders-based Imaging is needed for support of lightweight handheld and mobile imaging devices as well for heavyweight imaging devices to improve the efficiencies of resource utilization, linkages to EMR data and communications protocol. The current orders-based imaging workflow, profiled in SWF.b profile is based 1990's HL7 v2.x and DICOM DIMSE.

• Mobile & hand-held imaging devices, such as the hand-held ultrasound, require a light-weight protocol for Orders-based workflow. SWF.b is cumbersome for lightweight mobile platforms to implement, utilizing valuable system resources that impede system performance.
• Procedure and patient demographics to the imaging device rely on transcoding transactional HL7 v2 messaging in SWF.b. Imaging devices today require clinical non-imaging data not found in these messages. This leaves the imaging devices to implement other approaches to access this data need.
• The medical industry, overall, is aligning forward product development, including tools, with the new web-based RESTful FHIR and DICOMweb protocols.

3. Key Use Case

• All Web-enabled Imaging Devices, including MR, CT, etc.
• Orders-based lightweight portable devices, such as handheld Ultrasound
• Intermediate weight Mobile Imaging devices, such as X-Ray

Orders-based Imaging Workflow-(Simple Case)

Comprehensive Imaging Scheduled Workflow

• Extracted/revised from FHIR ImagingStudy:https://www.hl7.org/fhir/imagingstudy.html#10.4.3.3.2

Joe Angina complains of shortness of breath and occasional chest pain to his primary care physician, Dr. Pat Down at Local MultiClinic, who orders a stress echocardiogram; the order is created as a FHIR Task resource to manage the workflow, with a link to a ServiceRequest resource with the details of the request. The order is scheduled and assigned to cardiologist Dr. Art Skann, also at Local MultiClinic. On the scheduled day of the exam, Joe arrives at the echo lab to meet with Dr. Skann and have the study done. Dr. Skann’s workstation shows the daily list of Task, and he follows the link to retrieve the ServiceRequest. (He may follow the links through the referenced Patient resource to access Joe’s electronic medical record, but that is not the concern of this storyboard.) The Task and ServiceRequest has been transcoded to a DICOM Unified Procedure Step (UPS-RS) task(including links to the Service Request and the Patient Resources). The echo lab the equipment downloads the Worklist item. The study is performed, and the acquired images and sonographer’s preliminary measurements are stored in the Local MultiClinic Picture Archiving and Communication System (PACS) using the DICOMweb STOW protocol. The PACS creates an ImagingStudy resource for each study it manages.

4. Standards and Systems

Potential Systems

• Image Acquisition Devices (both Lightweight and Heavy/Integrated)
• Image Archiving Devices
• Electronic Medical Record Systems
• Practice Management Systems
• Radiology Management System (office/departmental system that transcodes the ServiceRequest to an imaging acquisition task, potentially using DICOM UPS-RS or FHIR task)

Potential Standards

• Existing Profiles: WIC, SWF.b, EBIW
• DICOMweb STOW UPS-RS
• FHIR, Imaging Study,ServiceRequest, Task, Patient, Visit

Discussion

IHE is a good venue to solve this because many of the expertise with both DICOMweb and FHIR profiles. Many of the IHE members are also members of DICOM and HL7 SDOs which can recruit additional resources for assistance and review. This profile is intended to drive integrated, complete and consistent solutions with the application of RESTful web services. An IHE profile or solution could avoid the costs and incompatibilities implementing proprietary extensions to FHIR and DICOMweb.

Goal:

1. Profile the equivalent “Simple Use Case” using FHIR based and DICOMWeb resources from the Service Request to the ImageStudy.
2. Establish code mapping between FHIR and DICOMweb(see https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_White-Paper_Codes_Rev2.0_2014-03-07.pdf])

Future Work (out of scope):

1. As part of keeping the scope practical, the use case is limited to a one-to-one relationship of what was requested vs preformed. SWF.b identifies several other usecases which could be included, but may require excessive profiling effort for a single cycle.
2. Patient Administration workflow not part of this proposal.

Open Questions to be addressed

1. UPS-RS or FHIR Task Will imaging acquisition modalities prefer UPS-RS or FHIR Task?