PCD Pulse Oximetry Integration with Clinical Applications

1. Proposed Profile: Pulse Oximetry Integration with Clinical Applications

Proposal Editor: Greg Staudenmaier
Profile Editor: Ioana Singureanu
Domain: Patient Care Devices (PCD)

Project Wiki: PCD Pulse Oximetry Integration Project

Summary

Pulse oximetry is usually monitored via stand‐alone units or is integrated into a monitoring system. The problem we are addressing is when the clinician outside the Intensive Care Unit will read a value or set of values and manually record these into the Electronic Health Record (EHR).

In the VA, pulse oximetry values are recorded in the Computerized Patient Record System (CPRS) vitals package. Some Veterans Health Administration (VHA) facilities are using FDA Class III software which transfers this data element directly into the vitals package which is available in CPRS. ICUs that have a Clinical Information System (CIS) may have the ability to automatically record these readings; the values stored in the commercial-off‐ the‐shelf (COTS) software; and are downloaded into a pdf file which is available in CPRS. Further, some areas may still record values on paper or in progress notes. There may be inconsistencies as well as inaccuracies in the manual recordings in relationship to values and time stamps, resulting in a large amount of patient data being lost. There needs to be a way to automatically capture these values as well as record interventions with these readings. Ideally, there should be real‐time feedback to the staff to be alerted to values outside the acceptable ranges for intervention. Also, there should be some way to validate the readings and annotate issues affecting the reading for final placement in the EHR. Pulse oximetry data elements should utilize standardized terminology.

Pulse oximetry devices should ideally be compatible with the EHR so that the values can be exported and displayed seamlessly, allowing clinicians to save time and have accurate and timely pulse oximetry recordings. Making disparate systems interoperable will improve patient safety by allowing clinicians to see all of the patient's pulse oximetry readings. This will allow clinicians to make better informed decisions about the patient's treatment plan. Additionally, a comprehensive list of values can provide researchers a wide variety of data which can lead to best practices.

IHE PCD is the best possible organization to partner with to solve this problem, because of their past work in this area. The VHA would like to partner with PCD for possible modification to the PCD Technical Framework and involvement with the calendar year 2013 Connectathon testing and HIMSS Interoperability Showcase demonstration.

2. The Problem

Currently, pulse oximeter are not capable of sending their results using standard-based messaging and terminology. They require proprietary adapters and solutions enable the exchange of device results the enterprise information system that are responsible for compiling the patient's EHR.

The ability of exchanging pulse oximetry with enterprise information systems using the standards and terminology that are native to those system would constitute a great advantage to the provider who use those devices and accelerate the integration with enterprise systems where the documentation for medical services is completed.

3. Key Use Case

Maria Registered Nurse (RN), is working the evening shift and is caring for John, a 60 year old male, postoperative day 1 open cholecystectomy. He is obese with a history of Chronic Obstructive Pulmonary Disease (COPD) and may have sleep apnea but is awaiting a sleep study. During her initial physical assessment she notes that he is afebrile, abdomen slightly tender, + bowel sounds, and without cyanosis. He is on 2L of oxygen. The pulse oximetry is connected to his right index finger with a good waveform reading 97%. The alarms are turned on. He is sleeping but easily arousable. He states his pain is still a 5 on a 1‐10 scale. Maria previously double‐checked the Patient Controlled Analgesic (PCA) settings with another nurse and confirmed he is receiving Morphine at 1 mg/hr continuously with 2 mg q 10 min on demand (30 mg 4 hr lockout). Maria notices he is not using the demand often. She reviews proper PCA use with the patient and his wife who is at the bedside.

Two hours later, a Nursing Assistant (NA) was taking vital signs. She called Maria to the room to report that his respiratory rate is 8. Maria sees he is taking shallow breaths and is having apneic spells. He is arousable only with deep stimulation. She finds his pulse oximetry probe on the floor. She connects it to John and it displays 89% with a good waveform. Maria told the NA to call for a rapid response team. The patient is treated and recovers from this incident.

While speaking with his wife after the event she tells Maria that she kept hearing her husband moan in his sleep so she would push the PCA button for him. The alarm to the pulse oximeter was turned off. She said she saw how to silence and turn off the alarm and did not think it was a problem to turn it off, since the alarm kept waking him up every time it fell off his finger. Maria took the opportunity to speak to his wife about why it is not safe to push the PCA button or turn off the alarm on the pulse oximeter machine. His wife verbalized understanding.

This scenario demonstrates how it is important for the nurse to have the tools needed to intervene appropriately to ensure patient safety. In this scenario, receiving alerts about abnormal pulse oximetery values would improve patient care.

4. Standards & Systems

HL7 Version 2.5.1 standards
SNOMED‐CT®, LOINC
Pulse Oximetry – ISO/IEEE 11073 -10404 Pulse Oximeter
ISO/IEEE 11073- 20601 Personal Health Device Information Model
IHE PCD Device Enterprise Communication (DEC) profile
X 73 nomenclature
COTS Products, (ICU/Analytics, DSS Inc. Real time vitals, VA Information Systems Technology Architecture (VISTA) vitals signs, Barcode Medical Administration (BCMA), CPRS local templates)

5. Technical Approach

The transmission of pulse oximetry results is triggered not only when a new measurement is available but it can be configured or triggered by clinicians based specific business triggers. In order for the results to be accepted by enterprise systems. The business requirements for this content profile specifies three type of triggers for information flowing from the device or device manager to the information system:The business use implies several technical use cases:

ICU: The pulse oximetry results are sent from the device through a clinical flowsheet application

to the EHR System (EHRS). The information is validated by the clinician in the flowsheet before it is forwarded to the EHRS. The user may select specific results to be added to the chart and forwarded to the EHR.

Operating Room (OR): The pulse oximetry results are sent from the device through an OR

application to the EHRS. All the results captured during a procedure are sent to the EHRS and committed to the anesthesia records of the patient.

Inpatient: Continuous pulse oximetry may be reported to the EHRS differently:
- All the results are sent to the EHRS as they are observed at the point of care. The clinician enables this mode of operation and “validates” the automatic reporting of data based on their assessment that the device is used correctly.
- Even though the patient is continuously monitored, the point‐of‐care system allows the clinician to select specific times measurements and send them to the EHRS.

This proposal will create additional implementation guidance regarding triggers and the need to support enterprise terminology.

In technical terms a PCD-01 transaction there are additional triggers of this transaction as follows:

Continuous or periodic information exchange – based on the frequency allowed by the device or configured on the device manager. This type of exchange is typical in the Operating Room for anesthesia record keeping and in Intensive Care Units for clinical flowsheets. The pulse oximetry values are automatically added to the patient’s chart/medical record. The information is validated in the information system that receives the medical device information.
- Device initiated:
User-specified information exchange- the device information is sent to the information system based on explicit user actions/request. The use may specify a set or range of measurements as relevant to the condition or treatment of the patient. These results are sent to the information site. Our analysis will determine whether the data is validated at the point of care or after the information is sent to the information system.
- User initiated: Content profile may be have additional guidance to the specify how the data is to be used.

Fig. 1: Devices exchanging information with Nursing application using a Device Manager

Note: The focus of this proposal are the last two interactions. 
      The rest of the interaction represent example pre-conditions

Existing actors

This proposal refers to the operation of the DEC profile, DOR and DOC actors - PCD-01. - see Figure 2 and Patient Care Devices (PCD) Technical Framework Published on the IHE.NET site."

Fig 2: Overview of Pulse Oximetry interactions highlighting the focus of this proposal

New actors

None, this proposal does not call for additional actors.

Existing transactions

The requirements in this proposal will result in constrains to PCD-01 – (OBR and OBX segments, specifically).

New transactions (standards used)

None

Impact on existing integration profiles

This proposal will produce normative mappings of pulse oximetry terms to SNOMED-CT and LOINC.

New integration profiles needed

None, additional content profile may be required.

Breakdown of tasks that need to be accomplished

Based on the initial analysis of the use cases, our team has identified two possible deliverables:

A content profile constrained for pulse oximetry and integration with clinical applications. This will include a content profile to constraint OBR and OBX segments. AA content profile is constraint of a transaction payload. In this case, we will constrain the message structure associated with PCD-01 transaction itn the PCD transaction package”.
Normative mapping of medical device parameter terms to enterprise terms form LOINC and SNOMED-CT. We expect that the number of concepts mapped will be relatively low (between four and seven). We expect that the number of concepts mapped will be relatively low (between three and seven). These maps will be added to the Rosetta Terminology Mapping.
- X 73 nomenclature will be included
- Coded elements may be coded using alternative coding systems (“bilingual codes”)

6. Support & Resources

VHA subject matter experts.

7. Risks

<List technical or political risks that could impede successfully fielding the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

9. 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:

Ioana Singureanu

PCD Home