Difference between revisions of "Orders-Based Imaging Workflow"

From IHE Wiki
Jump to navigation Jump to search
Line 1: Line 1:
{TOCright}}
+
{{TOCright}}
 
==1. Proposed Workitem: Orders-Based Imaging Workflow for Mobile (OBIWm)==
 
==1. Proposed Workitem: Orders-Based Imaging Workflow for Mobile (OBIWm)==
  

Revision as of 21:20, 13 August 2020

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, vendors are developing a mix of the older prococols with the new, utilizing different protocol mixes and adaptations or proprietary extensions.

IHE is a good venue to solve this because many of the expertise with both DICOMweb and FHIR profiles. This profile will drive integrated, complete, consistent solutions. An IHE solution could avoid the costs and incompatibilities implementing proprietary extensions to FHIR.

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. Both of these protocols have complexities and inefficiencies where are addressed in the current FHIR and DICOMweb RESTful web protocols.

  • Mobile & hand-held imaging devices, such as the hand-held ultrasound, require a light-weight protocol for Orders-based workflow. SWF.b is cumbersome 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.

3. Key Use Case

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

Use Case: Orders-based Imaging Workflow-(SWF Simple Case0

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. The procedure step task includes references/links to the Patient and Service Request. 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.

Goal:

  • Profile the equivalent “Simple Use Case” using FHIR based and DICOMWeb resources from the Service Request to the ImageStudy. Exclude patient administration and reconciliation.

“”Future Work (out of scope)”” 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.

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
  • FHIR, Imaging Study,ServiceRequest, Task, Patient