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

Latest revision as of 13:32, 23 October 2008

1. Proposed Workitem: Waveform Communication Management [WCM]

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

2. The Problem

Waveform data is an important component of information coming from medical patient care devices. This information can be an important complement to assessing the current status of a patient or the status of a patient during a clinical event. As such waveform information can be provided in a number of forms:

waveform snapshots
- specific forms of snapshots such as 12-lead ECG associated with a diagnostic encounter
- general snapshots of waveforms captured during a clinical event or due to a request by a clinician
continuous waveforms
- a continuous "real-time" stream of waveform data that would be used for a remote "real-time" waveform display

Independent of the form of waveform, the following information must be accommodated:

waveform type (e.g. ECG, Arterial Blood Pressure, CO2, etc.)
sampling rate
start time
event time
scaling (e.g. #bits/mmHg in the case of blood pressure)
annotations (e.g. pacer, beat-label, QRS, respiration, out-of-range, etc.)
status (e.g. lead-off, out-of-range, test mode, etc.)
filter status (e.g. low-pass, high-pass, etc.)
number of waveform samples
suggested waveform display color
units of measure
patient identification
clinician notes

A waveform snapshot may also include encapsulated vitals signs and event related information. The real-time waveform probably has this information as part of DEC or ACM data stream.

3. Key Use Case

A patient enters the Emergency Room complaining of pressure on the chest wall. A 12-lead ECG is obtained and transmitted via WCM to the Cardiology Management System. The data is reviewed and annotated and sent via WCM to the hospital Clinical Information System as part of the patient's clinical record.
A patient, post Heart Attack, is walking in his room while being monitored using a patient telemetry system. The system detects a run of ventricular beats and generates an alarm at the central nurse station. In parallel the alarm information, including the waveform, parameter data and alarm information is acquired by a separate alarm communication system which then sends the appropriate information snapshot to a caregiver's portable device.
A physician would like to review the current status of a patient including his parameter information, waveforms, device settings, etc. He brings up an application on his PDA or personal computer and can view the current information delayed by a maximum of 10 seconds.
A physician starting his rounds would like to review the waveforms and associated data for a patient under his/her care. He/she accesses an archive which has stored the continuous waveforms and related vital signs and other parameter data over the past 24 (or more) hours.

4. 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.
ISO/IEEE 11073-10201
The 'Unified Code for Units of Measure' (UCUM)
Health Level 7, version 2.5 (which supports large observation messages) (IHE PCD Waveforms using HL7 V2 OBX)

5. Discussion

Use Case 1 - there are already DICOM based IHE profiles to support the transmission of 12 Lead ECG Data. During the Oct. 2008 F2F it was decided that 12 Lead Rest ECG reports would be out of scope for this profile.

Use Case 2 - a basic decision needs to be made whether these types of applications require 'raw data' or images such as jpeg files. This scenario is closely related to work being done on the ACM Profile. During the Oct. 2008 F2F it was decided that 'raw data' would be the best way of transferring this type of data. This is the best way of supporting very widely varying display sizes, form factors, pixel areas, etc.

Use Case 3 - this is a good example of the possible use of the WCM profile.

Use Case 4 - this Use Case is related to the Query for Bulk Data (QBD) Profile and will be handled as such.

@@ Line 2: / Line 2: @@
 * Proposal Editor: '''Ken Fuchs'''
-* Editor: '''TBD'''
+* Editor: '''Ken Fuchs'''
 * Date:    N/A (Wiki keeps history)
 * Version: N/A (Wiki keeps history)
@@ Line 9: / Line 9: @@
 ==2. The Problem==
-The majority of PCD devices use vendor-specific or proprietary nomenclatures and terminologies.  As a result, even though information may be exchanged using standards-based transactions such as [[Device_Enterprise_Communication | Device Enterprise Communication]], semantic interoperability is not achieved until the content is mapped to a standard nomenclature.  This mapping is often inconsistent and subject to loss of information (e.g. mapping from a specific term to a more generic term).  Also given the lack of tooling, utilizing standardized medical device terminology in production systems is difficult and often cost prohibitive.
+Waveform data is an important component of information coming from medical patient care devices.  This information can be an important complement to assessing the current status of a patient or the status of a patient during a clinical event.  As such waveform information can be provided in a number of forms:
+* waveform snapshots
+** specific forms of snapshots such as 12-lead ECG associated with a diagnostic encounter
+** general snapshots of waveforms captured during a clinical event or due to a request by a clinician
+* continuous waveforms
+** a continuous "real-time" stream of waveform data that would be used for a remote "real-time" waveform display
-This profile will focus on identifying a core set of semantics that are shared between multiple devices within the same modality (e.g., physiological monitors, ventilators, infusion pumps, etc.) and then mapping them to a standard terminology.  The RTM mapping effort will initially include numeric parameters and their associated units of measurement and enumerated values.
+Independent of the form of waveform, the following information must be accommodated:
+* waveform type (e.g. ECG, Arterial Blood Pressure, CO2, etc.)
+* sampling rate
+* start time
+* event time
+* scaling (e.g. #bits/mmHg in the case of blood pressure)
+* annotations (e.g. pacer, beat-label, QRS, respiration, out-of-range, etc.)
+* status (e.g. lead-off, out-of-range, test mode, etc.)
+* filter status (e.g. low-pass, high-pass, etc.)
+* number of waveform samples
+* suggested waveform display color
+* units of measure
+* patient identification
+* clinician notes
-The RTM information should be represented in a uniform manner, such as by one or more XML files.  This will facilitate use by production systems, but more importantly, facilitate comparison between vendors that have (or plan to) implement the nomenclature standard in their systems, with the following goals:
+A waveform snapshot may also include encapsulated vitals signs and event related information.  The real-time waveform probably has this information as part of DEC or ACM data stream.
-* identify terms that are missing from the standard nomenclature
-* ensure correct and consistent use if multiple representations are possible
-* ensure correct and consistent use of units-of-measure
-* ensure correct and consistent use of enumerated values
-During the development of the RTM, gaps in the standardized medical device terminology will be identified.  In these cases, proposals will be made for adding the semantics to the appropriate terminologies.  Although the immediate focus of the RTM profile will be to standardize the content in transaction profiles such as [[Device_Enterprise_Communication | DEC]], which are typically between a device data gateway and enterprise level applications, the standardized terms should also support direct device communication, enabling semantic interoperability literally from the sensor to the EHR.
-The availability of the RTM information will also facilitate development of tools that can more rigorously validate messages, such as enforcing the use of the correct units-of-measure and correct enumerated values associated with specific numeric values.  For example, ST segment deviation will be expressed in "uV" or "mV", rather than the traditional "mm".  This will promote greater interoperability, clarity and correctness which will in turn benefit patient safety.
-The consistent and correct use of a standard nomenclatures such as ISO/IEEE 11073-10101 and UCUM for medical device and system data exchange will facilitate further development of real-time clinical decision support, smart alarms, safety interlocks, clinical algorithms, data mining and other clinical research.  This work can be also be expanded at a future date to support events and alarms, waveforms, device settings and other critical monitoring information.
 ==3. Key Use Case==
-A patient is monitored at home.  A potentially life-threatening cardiac event is detected and reported to a remote monitoring service that confirms and forwards the event to his caregiver.  The patient is subsequently admitted to the ER complaining about chest pain.  A diagnostic 12-lead is taken followed by continuous vital signs monitoring or telemetry for further observation.  Following a series of premonitory episodes of ST segment deviation, the patient exhibits short runs of ventricular ectopy that rapidly devolve into ventricular tachycardia and then fibrillation.  The patient is cardioverted in the ER and scheduled for CABG surgery.  During surgery, the patient is connected to well over a dozen medical devices (e.g. multiparameter patient monitor, anesthesia machine, multiple infusion pumps, bypass machine, etc.) and the data from these devices and systems is displayed in a unified and comprehensible manner and automatically charted.  After successful surgery, the patient is monitored in the ICU.  The patient is discharged a week later to continue his recovery at home, where, among other things, he uses a spirometer with a low-cost wireless interface to facilitate recovery.  He also exercises while walking around in and outside the house attached to a wireless sensor that records and transmits his ECG via his cell phone to a remote monitoring service.  The patient also has follow-up visits to cardiac rehab, where his ECG and glucose measurements are taken before and after exercise, with all the data also electronically recorded.  This information is ultimately stored in the patient's personal health record and made available for a follow-up study regarding the cardiac medications he was taking.
+# A patient enters the Emergency Room complaining of pressure on the chest wall.  A 12-lead ECG is obtained and transmitted via WCM to the Cardiology Management System.  The data is reviewed and annotated and sent via WCM to the hospital Clinical Information System as part of the patient's clinical record.
+# A patient, post Heart Attack, is walking in his room while being monitored using a patient telemetry system.  The system detects a run of ventricular beats and generates an alarm at the central nurse station.  In parallel the alarm information, including the waveform, parameter data and alarm information is acquired by a separate alarm communication system which then sends the appropriate information snapshot to a caregiver's portable device.
-The key point of this overly broad but realistic use case is that the patient's data is "touched" by well over three dozen medical devices and systems designed and manufactured by nearly an equal number of different vendors.  An essential first step towards achieving interoperability across all these devices and systems is that they use a shared semantic foundation.
+# A physician would like to review the current status of a patient including his parameter information, waveforms, device settings, etc.  He brings up an application on his PDA or personal computer and can view the current information delayed by a maximum of 10 seconds.
+# A physician starting his rounds would like to review the waveforms and associated data for a patient under his/her care.  He/she accesses an archive which has stored the continuous waveforms and related vital signs and other parameter data over the past 24 (or more) hours.
 ==4. Standards & Systems==
-ISO/IEEE 11073-10101  Health informatics — Point-of-care medical device communication —
+* ISO/IEEE 11073-10101  Health informatics — Point-of-care medical device communication — Part 10101:  Nomenclature, First edition, 2004-12-15.  ISO and IEEE, 2004.
-Part 10101:  Nomenclature, First edition, 2004-12-15.  ISO and IEEE, 2004.
+* ISO/IEEE 11073-10201
+* The [http://aurora.regenstrief.org/UCUM 'Unified Code for Units of Measure' (UCUM)]
-The ‘Unified Code for Units of Measure’ (UCUM), [http://aurora.regenstrief.org/UCUM].
+* Health Level 7, version 2.5 (which supports large observation messages) ([ftp://ftp.ihe.net/Patient_Care_Devices/Profiles/ACM/pcdWave1a.doc IHE PCD Waveforms using HL7 V2 OBX])
 ==5. Discussion==
+: Use Case 1 - there are already DICOM based IHE profiles to support the transmission of 12 Lead ECG Data.  During the Oct. 2008 F2F it was decided that 12 Lead Rest ECG reports would be out of scope for this profile.
-# Detailed mapping content should not be included in the RTM profile document, but in separate files that could be more easily updated and manipulated.
+: Use Case 2 - a basic decision needs to be made whether these types of applications require 'raw data' or images such as jpeg files.  This scenario is closely related to work being done on the ACM Profile.  During the Oct. 2008 F2F it was decided that 'raw data' would be the best way of transferring this type of data.  This is the best way of supporting very widely varying display sizes, form factors, pixel areas, etc.
-# Issue:  Addressing gaps and having them quickly addressed by the appropriate standards organization
+: Use Case 3 - this is a good example of the possible use of the WCM profile.
-# ...
+: Use Case 4 - this Use Case is related to the Query for Bulk Data (QBD) Profile and will be handled as such.
 [[Category:PCD]]