Difference between revisions of "PCD Brief Profile Proposal 2008 QBD"

Latest revision as of 19:51, 5 February 2009

Proposed Work Item: Query for Bulk Data [QBD]

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

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)

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.)
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.)
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.]
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 Forensic 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 Forensic 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.)
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.
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), [1].

Health Level 7, version 2.5 (which supports large observation messages)

IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor)

PhysioNet The research source for complex physiological signals

Discussion

This capability is required by DPI as well as DEC environments. Do we create a single approach for both environments or are there 2 approaches?

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)

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

@@ Line 1: / Line 1: @@
-==1. Proposed Workitem: ''Real-Time Archival (& Retrieval) Management [RAM]''==
+== Proposed Work Item: ''Query for Bulk Data [QBD]''==
-* Proposal Editor: '''Jack Harrington'''
+* Proposal Editor: '''Ken Fuchs / Jack Harrington'''
-* Editor: '''TBD'''
+* Editor: '''Ken Fuchs'''
 * Date:    N/A (Wiki keeps history)
 * Version: N/A (Wiki keeps history)
 * Domain: '''Patient Care Device'''
-==2. The Problem==
+== 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.
-In a recent HIMSS survey 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.
-Discussions of Cross Enterprise Sharing of Patient Care Device Data can be grouped into three categories – Asynchronous (non-real time), Isochronous (near time), and Synchronous (hard real time). For purposes of this proposal, real-time can be defined as “something can be said to be working in real-time when the time constants of the measurement and control loop are insignificant compared to the time constant of the process. ” Since we are discussing patient care device systems associated with measurement and control of physiologic processes “real-time” will be associated with the underlying chemical, electrical, and mechanical properties of the physiologic processes being measured or controlled.
-The scope of this proposal is limited to asynchronous patient care device data storage and retrieval. Examples include storage and retrieval of physiologic data by and from a CDSS Application, CDR, EMR, or EHR and may include static snapshots of waveform data.
-A key requirement is that the semantics of the data which is stored and retrieved is not a function of the storage and retrieval mechanism.
 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.
-==3. Key Use Case(s)==
+== Key Use Case(s)==
-# Storage and retrieval from a Patient Care Device Manager. - Periodic data from all of the patient care devices associated with a particular patient are communicated to a Patient Care Device Manager. Examples include data from a bedside monitor, point of care lab devices, ventilators, and infusion pumps. Both discrete and continuous (waveform snapshot) data are communicated to 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. Devices local to the Patient Care Device Manager are able to retrieve data using a query mechanism which supports a query and retrieval mechanism which is independent of the local implementation of the storage and retrieval implementation.
+# 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.)
-# Storage and retrieval of patient identified periodic data by and from an EMR/EHR – Periodic data which includes an enterprise unique identifier is stored by the EMR/EHR for inclusion in the patient record. Applications are able to retrieve data using a query mechanism which supports a query and retrieval mechanism which is independent of the local implementation of the storage and retrieval implementation. This may include user validation and device identification data associated with the PCD data and queries may be for specific patients, populations of patients, or more general as defined by the appropriate use cases.
+# 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.)
+# 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.]
+# 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 Forensic 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 Forensic 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.)
+# 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.
+# 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==
-==4. Standards & Systems==
 ISO/IEEE 11073-10101  Health informatics — Point-of-care medical device communication —
@@ Line 34: / Line 41: @@
 Health Level 7, version 2.5 (which supports large observation messages)
-==5. Discussion==
+IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor)
-Cross enterprise sharing of patient care device data has been identified as the top priority in a HIMSS survey. This proposal complements the Cross Enterprise Sharing of Patient Care Device Data-Asynchronous proposal by considering the storage and subsequent retrieval of the PCD data. There are a number of standards which can be used for this purpose and there is a need to select the appropriate profiles among those standards to meet use cases of sufficient breadth to be of interests to both the clinical user and patient care device vendor communities. The proposed profile addresses a broad range of uses of patient care data which do not require “real-time” storage and retrieval.
+PhysioNet [http://www.physionet.org The research source for complex physiological signals]
+== Discussion==
+This capability is required by DPI as well as DEC environments.  Do we create a single approach for both environments or are there 2 approaches?
+=== 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)
+=== 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