POCUS EBIW Extensions

From IHE Wiki
Jump to navigation Jump to search


1. Proposed Work Item: POCUS EBIW Extensions

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.

<READ PROPOSER HOMEWORK IN Proposal Effort Evaluation FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >

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

  • <Describe the main new profile chunks that will need to be written.>
  • <List existing profiles that may need to be modified.>

Decisions/Topics/Uncertainties

  • <List key decisions that will need to be made, open issues, design problems, topics to discuss, and other potential areas of uncertainty>
  • <Credibility point: A proposal for a profile with any degree of novelty should have items listed here. If there is nothing here, it is usually a sign that the proposal analysis and discussion has been incomplete.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

<Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List real-world practical or political risks that could impede successfully fielding the profile.>

<Technical risks should be noted above under Uncertainties.>

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


<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>

Retrieved from "http://wiki.ihe.net/index.php?title=POCUS_EBIW_Extensions&oldid=133215"