I started connecting medical devices to electronic records in 2001 at Massachusetts General Hospital when we installed an anesthesia information management system. I left the operating room in 2008 to lead a Medical Device Integration and Informatics (MDII) team working on the implementation of an in-patient electronic medical record (EMR) for 1,700 beds at the two Partners Healthcare academic medical centers, Brigham and Women's Hospital and Massachusetts General Hospital. A key function of the system was to integrate data from our medical devices to the EMR.

The project touches virtually every aspect of in-patient care at both hospitals. Since we're introducing many changes and significant new workflows at both hospitals, we quickly realized the value of using formal and structured quality assurance practices. We developed clinical scenarios based on “a day in the life” of a patient's visit for each of the care areas involved in our acceptance testing from admission to discharge. We developed other clinical scenarios after a gap analysis to make sure we didn't miss any expected patient care conditions.

Clinical scenarios break down to quite a number of use cases, which easily create hundreds or thousands of test cases. Working in multidisciplinary teams, we created thorough documentation tracking expected normal user workflow, variant user workflow, and system dependencies, such as the admit-discharge-transfer (ADT) system, bed management systems, and network communications under both normal and fault conditions. With detailed descriptions—from people who operate the equipment every day—of how the medical devices are used, we analyzed the flow of medical device data through these diverse clinical scenarios with the goal of understanding our assumptions and potential system outcomes.

Testing software and systems is a complex affair that is beyond the scope of this article. At a high level, there are numerous types of tests (e.g., defect, functional, regression, verification and validation, performance, and acceptance) and a number of testing levels or phases (e.g., unit, integrated, system). For unit testing, which involves verifying the core functions of our component work properly, we developed the “Five Fundamental Medical Device Data Characteristics” (see sidebar page 66) that had to be right.

This detailed testing approach uncovered a number of defects, many of which were addressed. However, a few left residual risks that we needed to mitigate. Unfortunately, we found that for some defects, our only mitigation strategy in the near-term was to shut down some of the functionality that we were trying to implement. For example, we could not ensure that buffered medical device data (data generated by today's patient transport monitors or during fault conditions like network interruptions) loaded correctly into every test patient record all the time.

Loading medical device data to the correct patient record is a vital function with significant patient safety implications. We found that it is important to understand exactly how that function works. Most of today's EMRs receive medical device data through a Health Level Seven (HL7) interface (and/or terminal servers) and associate medical device data to the patient by a location, not the HL7 patient identifier (PID). That approach works reliably under normal conditions. It doesn't work as well when there are communication delays and buffered data is processed at a later time, after a patient has changed locations.

After finding this buffered data problem, we contacted colleagues across the country and confirmed that other organizations have experienced the same thing. We also confirmed that most EMR systems work in much the same way. For example:

  • Patient A is admitted to bed 1 in an EMR and connected to a physiological monitor.

  • There's an interruption in monitor data transmission (e.g., transport monitor, network disconnect).

  • Data is buffered in the monitor or gateway.

  • Patient A moves to a new location.

  • Patient B is admitted to bed 1.

  • The service interruption is resolved and buffered data is transmitted to bed 1.

  • Our testing (other systems may behave differently) found data from Patient A is incorrectly loaded into Patient B's record.

We had difficulty resolving this problem because there are at least three parties involved, and each holds a part of the solution:

  1. The healthcare delivery organization that installed the EMR

  2. The EMR manufacturer

  3. The manufacturer of the medical device or connectivity solution

To reduce the possibility of error and confusion, a good practice when implementing any system is to decide the location of the “single source of truth” (SSOT), particularly anything that involves a patient's location. (Setting aside all the safety implications, no family member wants to go visit their loved one in a hospital and be sent to the wrong room.) The healthcare delivery organization must weigh many factors like accessibility, connectivity, and flexibility in the SSOT decision. We decided that the SSOT had to be a computer system, not a patient monitor and not a medical device connectivity solution. Among other reasons, the SSOT had to be accessible to large numbers of hospital employees. Patient monitors and/or medical device connectivity solutions didn't meet that requirement.

The problem of buffered data is only one of the challenges facing healthcare providers as they integrate medical devices with information systems.

The problem of buffered data is only one of the challenges facing healthcare providers as they integrate medical devices with information systems.

Close modal

Most EMR manufacturers load data into a patient's record when three criteria are met:

  1. Medical device data are detected from a particular location.

  2. A patient has an active EMR record during the corresponding timeframe.

  3. The patient is associated with a particular bed.

When all three of those conditions are met, data from that location are loaded into that patient's record.

Loading medical device data to the correct patient record is a vital function with significant patient safety implications. We found that it is important to understand exactly how that function works.

Medical device and/or connectivity solution manufacturers rely heavily on user workflow, hospital processes and admit discharge transfer (ADT) computer systems to assemble the correct patient identification (PID). They then forward the PID and other information as part of the HL7 outbound results message to the EMR. If there are ADT delays or last-minute bed assignment changes, they may not get and transmit the correct PID unless it's a fault-tolerant system.

After many months of work trying to resolve this problem, we realized that each manufacturer is following the HL7 standard, but that the system still does not work as expected or desired. To mitigate the problem we had to disable a capability we wanted in the system. Healthcare providers who do not have the technical resources to perform exhaustive testing like this may not even be aware of the problem.

Five Fundamental Medical Device Data Characteristics

My colleagues and I at Partners have developed this list of “rights” for patient data that must be in place to ensure patient safety:

  • Right Measure—ECG heart rate must be ECG heart rate, not SpO2 HR or NIBP.

  • Right Value—62 on the medical device must be 62 in the EMR, not 60 and not 63.

  • Right Units—mmHg is mmHg not kilo Pascal or cm H2O.

  • Right Time—Since many medical devices are not networked (nor were they built to use an NTP reference), ensuring medical devices all have the correct time is essential.

  • Right Patient—Medical device data MUST be associated to the correct patient. Patient A's medical device data cannot be loaded into Patient B's record.

As an organization, we decided it was an unacceptable risk to knowingly allow the potential for medical device data to load into the wrong patient's record. To mitigate the risk, we had to shut down the capability to process buffered data altogether. Therefore, no transport monitor data whatsoever can feed into the EMR, and we cannot upload recovered data from certain network communications problems. That was an uncomfortable constraint to have to implement. Transport monitor data in the EMR is potentially important in the patient's care and our clinicians specifically stated they want the functionality.

For now, we're mitigating the risk of wrongly associated data by turning off the capability to upload buffered data. We're also archiving only user-validated data in the permanent record. Unvalidated device data are purged shortly after the patient is discharged.

As an organization, we decided it was an unacceptable risk to knowingly allow the potential for medical device data to load into the wrong patient's record. To mitigate the risk, we had to shut down the capability to process buffered data altogether.

We're using Network Time Protocol (NTP) to synchronize the clocks of our patient monitor networks. With NTP enabled, we configured our EMR so that medical device data is written into the database at the timestamp they were generated. For installations that don't have an NTP reference to their patient monitors, many EMRs can be configured to load device data at the time they were received.

Other key steps healthcare facilities should consider:

  • Prepare for production by ensuring you have enough redundancy.

  • Put policies and procedures in place to deal with down time.

  • Develop a support plan.

  • Periodically re-evaluate the market to see what new solutions and capabilities are available.

  • Focus on drafting requirements for systems you would like to purchase in the future.

Collaboration is needed from all parties involved to solve these problems. We all need to move outside of our comfort zone. We also need an arbitrator for situations where everyone is working to a published standard, but still the components don't work together as expected. Our hope for the long term is that as a customer, we'll be able to help guide industry to better meet provider needs.

At Partners, we chose to do without certain functionalities that we believe cannot be implemented safely within a reasonable time at a reasonable cost. We're allowing time for the industry to mature. By the time we are ready to install new connectivity solutions, we're optimistic that many of these challenges will have been solved.

Medical device connectivity solutions hold tremendous promise to solve many of these problems for healthcare facilities. These solutions may allow us to get more parameters out of medical devices, and may also solve problems like tracking software versions. We hope ongoing standards efforts bring us resolution to today's challenges and that a process for certification emerges. There's clearly a role for arbitrators of complex systems problems.

Thinking about the future, the buffered data problem is just one challenge healthcare providers face as we integrate medical devices with information systems. Our converging industries are beginning to identify some of the edifices that are being constructed with medical device interoperability. We're now building EMRs across the country. At national conferences people are describing what clinical decision support tools could do to advance care. Others are asking what it will take to enable closed-loop control of infusion pumps with physiological monitors. As the potential medical device interoperability edifices become clearer, we need to start describing the foundation we're building upon. We see data as the foundation for all these edifices, and medical device data is our building block.

Many of today's EMRs are built to capture one-minute alphanumeric data. That may not be enough data to enable the kind of functionality people envision. Even though we identified five characteristics that must be right, there are more to identify and work through. The foundations of these systems, their rudimentary characteristics, are the things that we must get right. Otherwise the systems we build on top of the data could exhibit unanticipated behavior or have constrained capabilities.

A starter list describing medical device data and their foundational attributes might be:

  • Proper patient data association for any and all expected user workflow

  • Network time protocol and/or time synchronization

  • Naming of parameters and a common ontology. We need consistent nomenclature and definitions.

  • Settings versus measurements

  • What data is available? Many medical devices, and some connectivity solutions, pare down what's available from the device to the user and/or communication port. Users often want access to more parameters, not less.

  • Time lag in data availability

  • Possible data types: waveforms, alphanumeric, alarms, images, video, sound

  • Alphanumeric data, instantaneous, averaged, mean, frequency, etc.

  • Device software revision, serial numbers, last service or calibration, FDA Unique Device Identification (UDI)

  • Signal quality (signal to noise ratio, averaging time, other pertinent device conditions)

There are still a number of fundamental challenges before us. It's often surprising to our information systems colleagues that biomedical engineering cannot centrally identify which devices may have incompatible software revisions with our EMR interfaces. They're beginning to understand we don't have the ability to view software revision levels over the network (even when the device is connected to an EMR) and that we currently have to touch every device to determine if it has the proper software version.

As we move into more advanced uses of patient data, including infusion pump integration, alarm system integration, transmitting waveforms, and clinical decision support software, these foundational challenges must be more clearly understood and resolved.

Many of today's EMRs are built to capture oneminute alphanumeric data. That may not be enough data to enable the kind of functionality people envision.

About the Author

Luis Melendez is an associate director with Partners Healthcare, specializing in biomedical engineering, medical device integration and informatics. E-mail: lmelendez@partners.org