John R Zaleski, PhD, CPHIMS

In this article I wish to provide some comments and highlight the functional requirements associated with high-acuity medical device communication in relation to the American Health Information Community (AHIC) priorities on common device connectivity (CDC) to electronic health records (EHRs).

The US Department of Health and Human Services Office of the National Coordinator for Health Information Technology has chartered the development of a series of documents to represent American Health Information Community (AHIC) priorities for national health information activities. The 2009 Common Device Connectivity (CDC) Extension/Gap document, as requested by AHIC, was commissioned to address information transfer from “high-acuity and inpatient diagnostic/therapeutic medical devices…into electronic health records.”

As stated in the scope of the CDC AHIC Extension/Gap, section 2.2, Common device connectivity is

“…the means by which high-acuity and inpatient clinical device information such as settings, measurements, and monitoring values are communicate to and from [the electronic health record] and other specialized clinical information systems.”

Examples cited include vital signs monitors, mechanical ventilators, anesthesia, and infusion pumps. Radiological devices are explicitly excluded from consideration. As such, single- and multi-parameter data from such devices are assumed the primary sources of data for communication to EHRs and clinical information systems (CISs).

It is noted, as stated within section 1.2 of the CDC AHIC Extension/Gap document, that as of the publication date of this CDC document, available at

http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10731_848117_0_0_18/ComDevFinalExtGap.pdf, the national health agenda

“…has not formally addressed the interoperability considerations for connectivity between medical devices and EHRs.”

Progress has been made through the spring and summer of this year via the Tiger Team efforts initiated earlier this year, with focus on the Remote Monitoring Use Case. The 2008 Remote Monitoring (RMON) Use Case highlights communication from ambulatory settings to EHR and PHR. The functional requirements associated with CDC related to communication and exchange of information between medical devices and the electronic health record are highlighted in section 3.0 of the subject document. As is pointed out in the preamble to section 3.0, it is implicit in these functional needs that what are described are key capabilities and not detailed, explicit functional requirements, representative of those expected in a mission, software, and interface requirements specification. Rather, the focus is on the high-level functional needs.

My approach is to list each of the explicit functional needs (as quoted directly from the document—in italics) and then provide my feedback on the potential implications of each.

3.0 Functional Needs

A. The ability to configure and register a device to communicate with an EHR or other system.

i. When a device is set up within an organization to communicate measurement information, the device is configured and registered within the organization’s electronic health record to uniquely identify the device and enable connectivity between the device and system.

Zaleski:

This is usually a manual process today. The ability to associate a device with a patient is normally managed through the clinical software. One method is through the manual assignment via the clinical information system, such as through the critical care flow sheet. A pick list may be shown in which a clinician assigns the available devices to patients. Other approaches to associating medical devices with patients are being evaluated by various interoperability vendors, including the automated association via barcode or radio frequency identification token through a common device token, similar to a serial number.

B. The ability to associate patient identification and device information with an EHR.

i. Patient registration, location, and identification information available within the EHR is uniquely associated with the patient’s monitoring device using standardized mechanisms for admission, transfer, and discharge from beds, units, wards, and entities within the facility.

Zaleski:

Many vital signs monitoring systems provide methods for associating monitors in individual patient rooms with patients within a flow sheet, in the format of a bed board. Patients are assigned by nursing upon admission to the unit. The key identifying information can include a medical record number and visit identifier. Upon discharge, patients are disassociated using the bed board mechanism again. This process, while manual, addresses the point identified above.

ii. In the event patient identification information is associated with a device in error, the device can be disassociated with the current patient within the EHR and associated with the correct patient.

Zaleski:

Some clinical information systems (CISs) today provide the capability to disassociate the medical device from the patient through a flow sheet user interface. Those CISs that provide the equivalent of “bed boards” whereby patients are manually assigned to monitors (in rooms) via this user interface is one mechanism by which this can be accomplished.

iii. A patient may be placed on a monitoring device prior to the completion of patient registration or the availability of patient identification information within the EHR, especially in emergent or critical situations. The measurement information is available in the EHR upon initiation of the monitoring function or medical device initiation, and can be reconciled with patient registration or patient identification information within the EHR when available. Data collected prior to patient registration should be buffered and retained for a reasonable period of time sufficient to complete the registration process.

Zaleski:

Again, certain CIS flow sheets support this, with association or linkage to patient done after admission to the unit. The HL7 admission, discharge and transfer (ADT) messages arriving from an existing master registration system to the unit can then be used to link the patient-specific identifying information to the vitals data measured from the bedside equipment. Once linked, the observations and measurements can be sent back to electronic health records.

iv. Organizational policies and procedures may require medical device measurement values within a patient’s record to be validated by a licensed clinician prior to being stored within a patient’s record. This function may prevent the charting of erroneous values within a patient’s permanent medical record.

Zaleski:

The validation step is key to ensure that the data are indeed a true and accurate representation of the measurements from the patient. Furthermore, context added to the measurements (for example, clinical notes or text) that establish conditions at the bedside that may impact or influence the measured observations are also critical and necessary to communicate to the electronic health record.

C. The ability to associate patient identification and device information with an EHR.

i. Measurement and device information generated by the medical device is communicated to the EHR. Measurement information such as device settings, parameters, values, and units may be utilized by the EHR and/or clinical decision support (CDS) systems to support patient management.

ii. The devices should communicate state, error conditions, and user selections to support the analysis of adverse events.

Zaleski:

This causes me to think about the work I conducted when I was at PENN in the early 90s, and why I became involved in the field of medical devices and clinical decision making in healthcare. Having a complete and accurate record of the settings, parameter values, error conditions, etc. is certainly important for documentation purposes. But, moreover, it is essential to the “art” of making clinical decisions in an advisory role to the bedside clinician. What also speaks to me here is the necessity to begin thinking in terms of real-time management and monitoring of data—through the electronic health record! Again, it is certainly necessary to have a complete and accurate record of information from the documentation perspective. However, we should bear in mind that manual recording of this information has been done for decades. Presumably, benefits in terms of reduced errors, improved quality, and interventional guidance can be offered to the clinician by monitoring and recording this information in a timely manner. It would seem to follow that as much of this information is available in real- or near real-time, it would be beneficial to the patient to record information in as high a frequency as possible and practicable. Furthermore, status and error information that are logged could be made available to biomedical and IT departments for servicing and quality control purposes.

D. The ability to support point-of-care integration to uniquely identify a device and related components, communicate device setting and detailed device information, associated with each measurement value, to the EHR.

i. When a patient device is replaced by another device of the same type, measurement information may seamlessly populate the EHR. The devices may be from different manufacturers, but communicate the same information to the EHR. The EHR recognizes the measurement parameters and is able to represent the measurement values consistently within the EHR. Device information, settings, and metadata specific to each device is associated with each measurement value and is accessible within the EHR. This is accomplished via a standards-based first communication link interface between the point-of-care device and the EHR, device intermediary, or device gateway.

ii. A patient placed on multiple monitoring and patient care devices that need to be associated with the patient within the EHR. When multiple devices are capturing the same measurement or monitoring parameter, the information available within the EHR enables clinicians to distinguish between the measurements and determine the measurements that are captured from each device.

iii. Device data should be uniquely associated with the device, the patient, and the date and time the data was acquired, sent, and received.

Zaleski:

Standards-based communication from instrument or device gateways is typically accomplished using an HL7 result transaction. While the specific segment syntax can vary depending on the peculiarities of the device and the manufacturers’ objectives, this is more often than not the case. When device gateways do not exist, then the form of communication can be rather proprietary. Those in the device community are engaged in a continuing dialog on how to address this situation. Yet, from a clinical perspective, if two devices are interchanged (measuring the same parameter), then it may be in the interest to note the change in device as variations in device sensitivity, behavior, and manufacturing may result in some slight variation or difference in reported output. Yet, such variation should be well within the range of clinical significance so as not to raise a question as to the veracity of the result. Furthermore, one poor practice I have seen is representing two of the same values as two separate entries in flow sheets. For example, oxygen saturation from two different SpO2 cuffs. If these represent the same value (and not, for example, SpO2 and SaO2), then the values shown multiple times or presented in parallel with one another can cause confusion. While certain measurements can vary depending upon where measured (left arm versus right arm blood pressure measurement), and the differential is indeed necessary for clinical decision making, diagnosis and treatment, care must be taken so as not to present redundant measurements before the eyes of the clinician that may in fact be the same in every respect except for name. This simply will serve to confuse.

E. The ability to communicate measurement intervals and device setting information within the EHR.

i. When a patient is placed on a medical device, the clinician’s order details may specify measurement intervals for patient information to be communicated to the EHR.

ii. Depending upon patient acuity and monitoring needs, measurement intervals may need to be modified during the course of care. A clinician may modify the measurement parameters and intervals via the EHR or by modifying the device directly. Measurement interval information is communicated from the device to the EHR so the clinician may access this information.

iii. Inbound device settings and controls from the EHR may be subject to clinical oversight, validation and verification at the point of care prior to execution on the instrument itself.

iv. Measurement intervals are reconciled against the system time available from the EHR to ensure consistent and accurate identification of time intervals in absolute time.

v. The communication of multiple interval types should be supported (e.g. episodic, regular, quasi-continuous, sampled waveform, continuous waveform).

Zaleski:

An example that is used in clinical practice is the ordering of initial support on mechanical ventilation upon admission to an intensive care unit (ICU) of a post-operative coronary bypass graft patient. For instance, upon admission, initial ventilator settings of intermittent mandatory ventilation (IMV) at 12 breaths per minute, with a forced inspired oxygen of 100% and a positive end expiratory pressure (PEEP) of 5 cmH2O might be ordered. Then, as the patient is weaned down, the order is changed over time.

F. The ability to query the device or device intermediary [Zaleski adds: I interpret this as the device gateway] for additional information captured by the device that may not have been communicated to the EHR.

i. A clinician may request certain intervals for viewing device measurements or information within the EHR. If a patient event occurs that requires further investigation, the clinician may utilize the EHR to query for additional retrospective device information or measurement details that were not initially communicated to the EHR based upon the data intervals set for the patient.

Zaleski:

Clinical information systems that support automated collection at the bedside typically display automated vital signs information in discrete intervals. These intervals can vary. Typical ranges are one set of parameters every several minutes to once an hour, with typical values being in the quarter-hour range (i.e., once every 15 minutes, or q15). Flow sheets and their supporting medical device interoperability software need to allow for more or less frequent collection of information. The challenge remains that unless medical devices at the point of care provide for local storage of their data (possibly through their intermediaries), there may be no possibility to recall retrospective data on a patient.

G. The ability to communicate device and measurement information to the EHR when there is a lapse in EHR connectivity.

i. If a break in network connectivity occurs, or other factors prevent device communication to the EHR, device and measurement information is communicated to the EHR when connectivity is restored. Upon establishing or re-establishing this connectivity, there is no loss of measurement information in the EHR. In addition, details associated with measurement or device settings are communicated with the appropriate timestamp and patient parameters (e.g., identification, device settings) present at the time of information capture at the device.

ii. A notification may be sent to the EHR notifying of the event in which data transmission or communications are lost between the EHR and medical device. This notification consists of a standard health and status message that confirms device connectivity and general operation.

Zaleski:

A necessary requirement and cannot be overemphasized. Quality of Service undergirds this. Assured delivery of medical device data must occur if we are to use such data for intervention. As manufacturers of medical devices evolve more towards a plug and play paradigm, perhaps analogous to USB 2.0, this will assist in achieving this requirement. What we are talking about here is intelligent connectivity: devices “know” to whom they were attached; their data are not lost in the event of inadvertent loss of connectivity; the data can be picked up from where it was lost upon reconnection. Some monitoring systems provide what is typically called a “full disclosure database” which, in many instances, can store up to 72 hours of moment-by-moment data on any given patient until that patient is discharged. However, this is done at a much higher frequency than is normally stored within electronic health records.

H. The ability to communicate standardized alarm types and alarm violation types to the EHR in near real-time.

i. If a medical device generates an alarm, the alarm information and details are communicated to the EHR in time to support clinician life support efforts and critical care activities. Both text-based and audible alarm information should be communicated. For example, when a clinician or patient modifies device settings such as patient-controlled analgesics that are out of range and generates an alarm, the alarm and associated device details are communicated to the EHR.

Zaleski:

If we expect episodic, regular, quasi-continuous, sampled waveforms, continuous waveforms to somehow be supported, then near real-time implies real-time to me. This presents an interesting quandary: if we are to communicate interventional information to the EHR, is it not implied that this information will, somehow, be used for interventional guidance? To me, this further implies a medical device, possibly requiring pre-market notification and substantial equivalent to existing monitoring systems and full-disclosure databases (Class-II regulatory implication).

I. The ability to set and communicate limits and safeguards for device settings from the EHR to a device.

i. Evidence-based guidelines or clinician preferences for device parameters or alarms may be communicated from the EHR or other systems to the device. For example, this would enable an infusion pump to be interrupted or paused based upon EHR information. Interrupts and pauses are not intended to be or imply closed loop control.

Zaleski:

Presumably, we’re talking about communicating notifications to clinicians who would then intervene and stop or adjust the device, since we’re not talking about closed loop control.

J. The ability to wirelessly communicate point of care device information from the device to a device intermediary or EHR.

i. Wireless communication of high-acuity and inpatient medical device information may require specifications for wireless networking that supports the critical nature of this information and can co-exist with other medical devices and wireless applications.

Zaleski:

Clearly key: high quality of service, secure, available, reliable wireless infrastructure. This is the subject of an entirely new discussion, and one that I will be bringing up in the future. From iPhones™ to BlackBerrys™, clinicians of the future will be relying on mobile device technology and will expect them to support their clinical workflow in ways we have not yet even considered.