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

• POCUS Manager (new)
• Modality (from EBIW)
• Results Aggregator (from EBIW)
• Image Archive (from EBIW)

Transactions

• 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
• (NEW) Store Report [RAD-tbd]. An HL7v2 ORU^R01 modeled after RAD-128
• (NEW) Get credentials: potentially reuse HPD [ITI-52] (ou=HPDCredential), mCSD [ITI-90], or SANER
• (NEW) QA: reuse IID
• (NEW) Mapping from ADT --> MWL --> Images (CP-RAD-480)

Profile

46 pages of Use Cases, concepts, open and closed items (here) have been reviewed and vetted by clinicians and vendors in the ACEP POCUS workgroup.

Decisions/Topics/Uncertainties

• Packaging: EBIW extension vs separate Profile
  • Objectives
    • Consolidate clinical concepts relevant to the POCUS workflow without confusing with lightweight devices.
    • Introduce modest requirements for existing POCUS Managers: The market has shown a preference for utilizing DICOM MWL, the UPS-RS requirements in EBIW may impose unnecessary burdens that do not align with clinical POCUS.
    • Re-use EBIW Transactions.
    • Make it easier for users to specify Profile requirements in RFQs.
• 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).
  • The POCUS Manager functions include:
    • Provide encounter information: Dynamically manage and update the list of patient encounters, ensuring that relevant patient and encounter metadata are readily available for the modality in a MWL.
    • Manage images: Ensure images align with reports through coercion, study split, or study merge. It segregates training studies from clinical studies, and forwards clinical studies to the Image Archive.
    • Display images: View POCUS images, allowing healthcare providers to assess and interpret studies.
    • Report creation: Identify relevant worksheets based on the imaging study performed and assists in creating reports, including the identification of training studies. It verifies user credentials to ensure that only authorized users can complete and sign reports, it facilitates auto-population of data, and it submits finalized reports to the EMR.
    • Manage credentials: Verify healthcare provider credentials, ensuring that only authorized users can perform, interpret, and sign off on POCUS studies, in accordance with institutional privileging policies.
    • Quality Assurance: reviewing POCUS studies for technical quality, completeness, and adherence to established protocols based on a sampling plan. Ensure accuracy and identify areas for improvement in both clinical and training settings.
• Alternative workflows:
  • Training Workflow:
    • Determine how to identify and segregate training studies.
  • Study Merge and Split:
    • Address the complexity of use cases that involve merging or splitting studies during POCUS workflows.
  • Reflexive Order:
    • May be required for billing in some facilities.
• Transactions:
  • POCUS Manager: The more the POCUS Manager is deconstructed, the more transactions are required, complicating alternate workflows, credentialing, and QA processes.
  • Manage credentials: Currently, there is no Actor designated for credentialing within the existing profile, and the introduction of such an Actor could create additional market demands that might be difficult for vendors and healthcare providers to meet. Although several credentialing products are available in the marketplace (e.g., from ASM, QGenda, Verge Health, symplr), the interfaces they provide for exposing credential data are not well-documented or standardized. As a result, creating a new transaction to handle credentialing data without a clear understanding of existing interfaces and integration capabilities would be speculative and could lead to inconsistencies or non-compliance with real-world implementations. The Technical Committee should not make assumptions about the structure or requirements of such a transaction without detailed insights into the capabilities and interoperability of the credentialing products currently in use.

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
• Mindray
• Other participants in the ACEP work group (prototyping interest to be confirmed):
  • FujiFilm SonoSite
  • Cerner
  • Clarius
  • Echonous
  • Terason
  • Philips
  • Vave Healthcare
  • Epic
  • Telexy Healthcare
  • Butterfly Network

7. Risks

Real-world risks

• Slow vendor adoption.
• Decreasing vendor participation in ACEP POCUS workgroup reduces the robustness of transactions.
• The pursuit of an idealized profile may result in overly complex requirements that are burdensome for the market to implement.

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