POCUS EBIW Extensions

1. Proposed Work Item: POCUS EBIW

• Proposal Editor: Steve Nichols
• Proposal Contributors: Rob Ferre MD, Kevin O’Donnell
• Profile Editor: Steve Nichols
• Profile Contributors: American College of Emergency Physicians (ACEP) POCUS workgroup
• Domain: Radiology

Summary

The integration of Point-of-Care Ultrasound (POCUS) into healthcare settings is hindered by inconsistent workflows, lack of standardization, and failure to support comprehensive reporting and billing, leading to inefficiencies and closed solutions​.

DICOM, HL7v2, and FHIR provide key integration features for Point-of-Care Ultrasound (POCUS) workflows, including mechanisms for patient demographics, image storage, and reporting, while IHE's Encounter-Based Imaging Workflow (EBIW) profiles transaction standards that can be leveraged to integrate POCUS workflows into both clinical and educational settings.

A POCUS integration profile could define standardized workflows for clinical and educational use cases, capturing patient and operator data, storing images, verifying POCUS privileges, generating reports, and supporting billing.

ACEP and SCCM (Society of Critical Care Medicine) have published guidelines encouraging the use of POCUS in clinical practice, and the ACEP POCUS workgroup, consisting of 30 members including EMR and modality vendors, has expressed interest in contributing to profile development​.

IHE is well-suited to solve the problem by providing a structured environment for developing standardized workflows, ensuring consistent implementations, and fostering collaboration between healthcare professionals, vendors, and organizations like ACEP to address integration challenges in POCUS​.

2. The Problem

POCUS lacks consistent workflows and standardization across healthcare settings, with current systems often failing to integrate patient and operator data, image storage, and reporting into electronic medical records (EMRs). Additionally, inconsistent verification of POCUS privileges leads to inefficiencies in billing, reporting, and compliance.

The underlying cost of the POCUS integration problem includes missed opportunities for accurate clinical documentation. POCUS images and reports often fail to be integrated into patient records, resulting in incomplete medical histories and potentially impacting patient care. This gap can lead to medical errors, delayed diagnoses, and lost revenue due to missed billing opportunities. Additionally, the lack of integration disrupts workflows, increases administrative burdens, and exposes healthcare providers to compliance risks, as reporting and credentialing remain inconsistent. Solving this would ensure that POCUS data is properly captured in medical records, improving care quality and reimbursement accuracy.

3. Key Use Case

Current Workflow (Problem):

1. A healthcare provider (HCP) conducts a POCUS scan on a registered patient in the emergency department.
2. The images are captured on the ultrasound device, but there is no standardized process to transfer them directly to the hospital's Vendor Neutral Archive (VNA).
3. The HCP creates a report, manually entering patient and operator data, often leading to errors or incomplete documentation.
4. Reports and images may not be automatically linked or accessible in the patient's EMR, resulting in incomplete clinical records, which affects the care continuum.
5. Due to a lack of integration, billing for the procedure may be delayed or missed entirely.

Ideal Workflow (Solution):

1. A healthcare provider (HCP) conducts a POCUS scan on a registered patient in the emergency department.
2. The ultrasound device requests a MWL that automatically retrieves patient demographics from the EMR, ensuring accurate data entry.
3. Once the scan is complete, images are automatically transferred to the POCUS manager, and a worksheet is generated to standardize the reporting process.
4. The POCUS manager verifies the HCP's credentials and privileges to finalize the report.
5. The signed report and images are automatically integrated into the patient's EMR, and a notification is sent to the VNA.
6. The procedure is properly documented, ensuring accurate billing and compliance with local policies.

4. Standards & Systems

DICOM (Digital Imaging and Communications in Medicine):

• Version: Current version is DICOM 2023c.
• Support: Widely supported by ultrasound device manufacturers and PACS vendors for image storage and retrieval. The SR (Structured Reporting) format is used for standardized reporting.

HL7v2 (Health Level 7, Version 2):

• Version: HL7v2.9 is the latest release, 2.5.1 is widely adopted
• Support: Used by EMR systems to transmit patient demographic, encounter, and results data. POCUS integration can leverage HL7v2 ORU^R01 messages for transmitting reports.

IHE Encounter-Based Imaging Workflow (EBIW):

• Version: May 13, 2019
• Support: Partially supported by system vendors focusing on encounter-based imaging, particularly in critical and emergency care.

Systems involved:

• Ultrasound Modality: These may be cart-based or handheld devices used for performing POCUS studies.
• POCUS Manager: Manages POCUS workflows, including credentialing, report generation, and integration with EMRs and VNAs.
• EMR: Supports POCUS report and image lining into patient encounter records. In cases without a POCUS Manager, the EMR may also handle credentialing and report generation.
• VNA: Manages the storage and access to POCUS images.

5. Technical Approach

The proposed solution for POCUS integration involves defining a standardized workflow for capturing and integrating POCUS images, operator data, and reports into EMRs and VNAs. Most of the transactions will leverage existing DICOM and HL7v2 transactions from the EBIW and SWF profiles. The key tasks include the standardization of data capture, report generation, credential verification, and communication between systems.

Actors

• (NEW) Report Creator/Credential Manager
• Encounter Manager
• Modality
• Image Manager
• Image Display
• Results Aggregator

Transactions

• (NEW) Store Report [RAD-tbd]. An HL7v2 ORU^R01 modeled after RAD-28
• Get Encounter Imaging Context [RAD-130]:
  • ADT mapping of HL7 Visit Number (PV1-19) to Admission ID (0038,0010) for Encounter linking as a concept.
  • R+ Physician of Record (Attending) in Visit Admission Module (DICOM cp2451)
• Store Encounter Images [RAD-131]:
  • R+ Physician of Record (Attending)
• Notify of Imaging Results [RAD-132]: no change
• Query Images [RAD-14]: no change
• Retrieve Images [RAD-16]: no change

Profile

Use Cases and Concepts have been developed (here) and will be incorporated into a new profile.

Creating a new profile, rather than modifying the EBIW profile, is preferred (see below).

Decisions/Topics/Uncertainties

• Packaging: EBIW extension vs separate Profile
  • • A separate profile is preferred for the following reasons:
      • Reduced Burden for POCUS Managers: POCUS managers typically use DICOM MWL, and the UPS-RS requirements in EBIW could impose unnecessary burdens, making a separate profile more suitable.
      • Re-use of Transactions: Existing EBIW transactions can still be utilized.
      • Focused Scope: A separate profile will concentrate on the specific concepts relevant to clinical POCUS, without including lightweight devices (e.g., digital cameras) that are part of EBIW.
      • Editorial: A new profile is less confusing than merging POCUS into the existing EBIW, as it avoids mixing different types of imaging devices and workflows.
      • Simplified RFQs: A distinct POCUS profile will make it easier for users to specify requirements in RFQs, rather than having to specify EBIW options.
• Finalize Actors: Define responsibilities for all actors in the POCUS workflow.
  • The market has largely adopted a centralized POCUS Manager. This profile should consider alternative approaches to offer greater flexibility in system design, especially in cases where the EMR handles reporting and credential verification (see Rong, Katie, et al and Dhamija, Akhil, et al).
• Managing Transactions for Exception Handling:
  • Training Workflow:
    • Determine how to identify educational studies, possibly handled through the ORU message.
    • Determine how to segregate training studies without a POCUS Manager that can provide long-term storage.
  • Study Merge and Split:
    • Address the complexity of use cases that involve merging or splitting studies during POCUS workflows.
  • Reflexive Order:
    • Is mentioned in the happy path. Should it be profiled? If so, which Actor initiates it? Should it be sent before or after the report?
• Quality Assurance:
  • Currently out of scope, but future considerations may need to address QA processes for clinical and training studies

Credibility points:

• Managing credential verification and report finalization processes.
• Addressing the unique requirements of both clinical and educational POCUS studies.
• Concepts for handling unstructured and incomplete studies that may lack proper metadata or imaging.
• Balancing the need for flexible workflows with standardization to ensure interoperability.
• Adapting existing EBIW transactions for POCUS-specific requirements.
• Addressing study merge and split use cases for complex workflows.
• Potential to improve billing accuracy through standardized report generation and integration.

6. Support & Resources

Support

• American College of Emergency Physicians (ACEP)
• Society for Clinical Ultrasound Fellowships (SCUF)

Prototyping Interest

• GE HealthCare
• ...

7. Risks

Real-world risks

• Slow vendor adoption
• Decreasing vendor participation in ACEP POCUS workgroup reduces the robustness of transactions

Political / Regulatory

• The ONC HTI-2 (Cures Act) proposes a certification requirement for Imaging Links. However, the ONC has not yet established specific standards requirements to support this.

8. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx% for MUE
• yy% for MUE + optional

Editor:

TBA