Difference between revisions of "PCD Detailed Profile Proposal 2009 QBD"
Jump to navigation
Jump to search
Stevemerritt (talk | contribs) |
|||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | {{TOCright}} | |
| − | == | + | |
| + | ==Proposed Work Item: ''Query for Bulk Data [QBD]''== | ||
* Proposal Editor: '''Ken Fuchs / Jack Harrington''' | * Proposal Editor: '''Ken Fuchs / Jack Harrington''' | ||
| Line 8: | Line 9: | ||
* Version: N/A (Wiki keeps history) | * Version: N/A (Wiki keeps history) | ||
* Domain: '''Patient Care Device''' | * Domain: '''Patient Care Device''' | ||
| + | |||
===Summary=== | ===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. | 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. | ||
| Line 23: | Line 26: | ||
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. | 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 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 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.] | # 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 | + | # 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.) |
# 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. | # 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. | # 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 — | + | *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. | ||
| − | DICOM | + | *DICOM |
| − | CLSI-POCT | + | *CLSI-POCT |
| − | The ‘Unified Code for Units of | + | *The ‘Unified Code for Units of Measure [http://aurora.regenstrief.org/UCUM (UCUM)]. |
| − | Health Level 7, version 2.5 (which supports large observation messages) | + | *Health Level 7, version 2.5 (which supports large observation messages) |
| − | IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor) | + | *IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor) |
| − | PhysioNet [http://www.physionet.org The research source for complex physiological signals] | + | *PhysioNet [http://www.physionet.org The research source for complex physiological signals] |
| + | *IHE PCC QED [http://wiki.ihe.net/index.php?title=Query_for_Existing_Data_Profile (Query for Existing Data)] | ||
| + | ==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=== | ===Existing actors=== | ||
| − | The | + | The QBD profile will not use any existing actors. |
===New actors=== | ===New actors=== | ||
Some new actors may include: | Some new actors may include: | ||
| − | *Waveform | + | *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=== | ===Existing transactions=== | ||
| − | + | There is a possibility that some PCC transactions may be applicable either directly or as templates. | |
===New transactions (standards used)=== | ===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=== | ===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=== | ===New integration profiles needed=== | ||
| − | The | + | The QBD profile? |
| − | == | + | ==Support & Resources== |
| − | The | + | The QBD Brief Profile Proposal received support from: |
*Capsule | *Capsule | ||
*Draeger Medical | *Draeger Medical | ||
| Line 100: | Line 99: | ||
*Philips Healthcare | *Philips Healthcare | ||
| − | == | + | ==Risks== |
Technical risks include: | Technical risks include: | ||
*Size of resulting HL7 messages | *Size of resulting HL7 messages | ||
| + | *Complexity of | ||
*Lack of participation | *Lack of participation | ||
*??? | *??? | ||
| Line 109: | Line 109: | ||
*??? | *??? | ||
| − | == | + | ==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 [http://wiki.ihe.net/index.php?title=Query_for_Existing_Data_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.>'' | ''<The technical committee will use this area to record details of the effort estimation, etc.>'' | ||
Latest revision as of 14:36, 18 October 2010
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)
- 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 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.)
- 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).
- Health Level 7, version 2.5 (which supports large observation messages)
- IHE PCD SPD (Subscribe to Patient Data) Profile (DOF Actor)
- IHE PCC QED (Query for Existing Data)
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)
- Data Types to be stored include:
- 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
- Query types may include:
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