PCD Detailed Profile Proposal 2009 QBD

From IHE Wiki
Jump to: navigation, search


Proposed Work Item: Query for Bulk Data [QBD]

  • Proposal Editor: Ken Fuchs / Jack Harrington
  • Editor: TBA
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Patient Care Device


Summary

This profile provides support for access to stored time-structured data sets, typically of parameter data but could be extended to waveform data, events or other data in the future.

The Problem

In multiple HIMSS surveys the respondents identified Cross Enterprise Sharing of Patient Care Device Data as their highest priority. Goals include increased shortening decision time, increasing productivity, minimizing transcription errors, and obtaining increased contextual information regarding the data.

Within the PCD various profiles address access to “real-time” streams of patient data such as parameters, settings, alarms and waveforms. This data can also be stored in various types of “simple” data archives such as trend data archives, data logs, full-disclosure logs which can be located in simple patient-specific archives or more complex central-server multi-patient archives.

The scope of this proposal is a consistent mechanism for querying and retrieving bulk data from archives of structured time-based data typically acquired from “real-time” streams. The archives themselves can be built using other PCD profiles based on DEC and/or DPI and/or proprietary vendor protocols. The retrieval approach is proposed to be limited to patient-specific, “simple” queries which will allow the querier to discover for what data period data is available, what data types are available and ask for a bulk data transfer of specific data types over a specified time period.

This is not intended to be used as a general querying mechanism of EMR, EHR, CIS or other complex databases but could be used by these kinds of systems to populate their own archives.

Examples of patient care device data included in this profile include, but are not limited to, discrete vital signs parameters, infusion rates and constituents, ventilation rates and settings, and snapshots of waveforms.

Key Use Case(s)

  1. Review Device Trend Data - A physician wants to remotely review the trends of heart rate and blood pressure for a specific patient over the last 12 hours. (Periodic data from the patient care device is stored within the device.)
  2. Review Patient Care Device Manager Trend Data - A physician wants to remotely review the trends of heart rate, blood pressure, infusion rate and volume for infused drugs and ventilator mode and settings for a specific patient over the last 12 hours. (Periodic data from the medical devices at the point of care are collected and stored within the Patient Care device Manager. The primary intent is communication of structured data however provisions are made for inclusion of unstructured data. The patient associated with the data may be identified by the device from which it is gathered and the data is time stamped with a consistent time across the respective patient care devices. Interested devices or systems are able to retrieve data using a query and retrieval mechanism which is independent of the local storage implementation.)
  3. Review Full Disclosure Data - Upon returning to the ICU after the weekend, the physician would like to review the ECG and Ventilar Flow of all assigned patients over the past 48 hours. If he/she finds something of interest they would like to drill down into a specific patient's data and review any related waveforms, parameters, clinical events, etc. that occured in the 10 minutes before and after the period of interest. [Periodic data from all of the patient care devices (or patient care device managers) associated with a number of specified patients or beds. Both discrete and continuous waveform data are collected by the Full-Disclosure System. The primary intent is communication of structured periodic data however provisions are made for inclusion of unstructured and aperiodic data. Interested devices or systems are able to retrieve data using a query and retrieval mechanism which is independent of the local storage implementation.]
  4. Post-Sentinel Event Review - A patient on the ICU dies unexpectantly. The hospital wants to collect all information possible which would allow them to understand the condition of the patient and related systems leading up to this point. They would like to remotely acquire all of this data and store it on a DVD. The application they use uses the QBD protocol to transfer data from their Full-Disclosure system as well as the archival Logs (Flight Recorders) and create and complete real-time oriented record. (Periodic and Aperiodic event data from all devices associated with a patient are stored in a archival Log. This log may include clinical alarm events, settings changes, configuration changes, technical error messages, etc. which can be used to track the equipment interactions. This would be similar to an airplane Black Box / Flight Recorder which can be used to assist in discovery after a critical event. Interested devices or systems are able to retrieve data using a query and retrieval mechanism which is independent of the local storage implementation.)
  5. Patient Data Transfer - A patient is transported from the OR to the ICU after surgery. He/she has a number of attached infusion devices, a patient monitor and a ventilator. Once transferred to the new bed, the data collected during the transport (parameter, waveform, alarm, etc.) is used to backfill the Clinical Information System or EMR.
  6. EMR / CIS Data Retrieval - clinician is updating the patient documentation and decides that additional data from 1 hour ago is desired. The system can query medical devices using QBD in order to acquire the unvalidated data, which can then be validated by the clinician.

Standards & Systems

  • ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Part 10101: Nomenclature, First edition, 2004-12-15. ISO and IEEE, 2004.
  • DICOM
  • CLSI-POCT
  • The ‘Unified Code for Units of Measure (UCUM).
  • Health Level 7, version 2.5 (which supports large observation messages)
  • IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor)

Technical Approach

We anticipate that a phased approach will be used, with the initial focus on vital signs data followed by Event data or Waveform data This decision will be made based on the interests of the participants.


Existing actors

The QBD profile will not use any existing actors.

New actors

Some new actors may include:

  • Bulk Data Archiver (BDA)
    • Data Types to be stored include:
      • Parameter value series (including labels,UOM, etc.)
      • Waveform values series(including labels, UOM, scale, etc.)
      • Clinical Alarm Events (Time-stamped)
      • Annotations (Time-stamped)
      • Technical Device Alerts (Time-stamped)
      • User notes (Time-stamped)
  • Bulk Data Querier (BDQ)
    • Query types may include:
      • List of data types available
      • Time range of data available
      • Selection of specific data types to be reported
      • Selection of time intervals for data to be reported
      • Selection of time/date range for data to be reported

Existing transactions

There is a possibility that some PCC transactions may be applicable either directly or as templates.

New transactions (standards used)

New transactions will be based on HL7 transactions. The Technical WG will need to assess whether to use HL7 2.x or 3.x transactions.

Impact on existing integration profiles

This capability can become a companion to the ACM profile (where Alarm data can be stored), the MEM profile for access to Error Logs and the DPI profile for access to stored vital signs, waveforms, etc.

New integration profiles needed

The QBD profile?

Support & Resources

The QBD Brief Profile Proposal received support from:

  • Capsule
  • Draeger Medical
  • GE Healthcare
  • Philips Healthcare

Risks

Technical risks include:

  • Size of resulting HL7 messages
  • Complexity of
  • Lack of participation
  • ???

Political risks include:

  • ???

Open Issues

  • This capability is required by DPI as well as DEC, ACM and MEM environments. Do we create a single approach for all environments or are there multiple approaches?
  • The technical team will need to also evaluate the PCC QED profile (Query for Existing Data) to assess whether it meets the requirements of PCD Domain users.

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):

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA