Clinical users have been managing patient context in various ways with medical devices for many years. With some classes of medical devices, this is nothing new.  So you might ask -- what is the big deal here with patient context and what has changed that makes this topic relevant today?

As I stated in a previous post, managing patient context is all about the clinical workflow.  My working definition of patient context for medical devices is the linking of any information produced by a medical device (including data parameters, alarms, control settings, waveforms, etc.) with a specific patient identifier.

From a patient safety perspective, the best way to establish patient context is to tag data leaving a medical device with a unique patient identifier. And ideally this should be performed at the patient's bedside where devices can come and go. There is clinician workflow associated with managing patient context - and this is perhaps the most important aspect.

We live in a dynamic world where technologies, products, and user requirements are constantly evolving. Take wireless medical devices for example. Wireless has evolved over the past few years and adoption will increase for the foreseeable future. When connectivity is wireless, patient context becomes even more challenging.  Another example is with the evolving requirements for automatically integrating device data in to an EMR. The EMR market is moving beyond relatively simple patient monitoring vital signs interfaces and is now looking to integrate all bedside device data including smart pumps.

If you look at what is quickly evolving at the point of care today, patient context is becoming more of a challenge for vendors that manufacture the medical devices and as a result, end users (clinicians) are being asked to perform the task of establishing patient context at the point of care. So let’s look at how patient context is currently managed (if at all) and the impact on workflow.The main approaches used in the past have been to manage patient context on a vendor by vendor and product by product basis. Unfortunately, only some classes of devices can accept a patient ID or patient admit function. Legacy devices (those with serial ports, but no built in connectivity) have no capability to manage patient context at the device. This brings up real connectivity challenges because patient context is still important and has to be managed somewhere.

If patient context cannot be established in the medical device itself, then the alternative is to somehow manage it in an external system. This is usually done in a device interface system or in the EMR application.

For a medical device system that supports patient context, the vendor must implement specific features for their device (or system of devices) to have visibility to who the patient is. And therefore, someone (i.e. the clinician, nursing unit assistant, etc.) will have to perform a series of tasks or workflow to input and manage the correct patient ID for each device.

Some vendors provide a means for inputting patient ID and/or name directly into the bedside device. Other vendors leverage their device system, a patient monitoring system for example, and provide a capability to manage patient context at a central station. And in some cases, it is more than just patient ID that is required.  Many times, some or all of the ADT patient demographics are interfaced into the medical device or device system -- with HL7 almost always the preferred interface method. Here is a related article that also mentions ADT as it relates to patient context for medical devices.

Below are a couple of examples of how patient context is typically managed today and the resulting workflows. When reviewing these examples, take particular note for how patient context is established, who performs the task, where it is performed (bedside or central area), how many times it needs to be discretely managed (i.e. in each system or device), and the steps required to complete the task.

Patient Monitoring Systems

A basic "high-end" monitoring system includes bedside patient monitors, telemetry devices, one or more central monitoring stations, and a centralized gateway for data aggregation and HL7 interfacing. Patient context is performed either at the bedside via manual entry or a pick list on the monitor or at the central station. Patient monitoring vendors refer to this as the patient admit function.

At the central station, the user workflow is either manual entry of an MRN (medical record number) or patient name, or partially automated by selecting from a pick list of available patients. The pick list is populated via an ADT interface. With some vendors and products, if an ADT interface to the monitoring system has been implemented, then the user can semi-automate the bedside admit function by manually entering the patient ID and having the central send the patient demographics. Most monitoring systems need visibility to patient demographics in order to automate monitoring functions. For example, the monitoring system may need the patient's age and other fields from the ADT.

An interesting evolution of device connectivity was in the area of devices interfaced via the patient monitor. For example, when a ventilator is connected via the monitor, the monitoring system becomes responsible for establishing patient context. In this example, the ID of the patient admitted to the monitor becomes the data identifier if the vent data is sent externally from the monitoring system. If the monitoring system does not implement patient context then the data is by default tagged with a bed label or room identifier.

At the "low-end" of the monitoring market are devices like spot check vital signs monitors which are often found on med/surg floors or in the ED.  Because the devices are very transient, moving from patient to patient, it makes no sense to manage patient context in the monitoring device. The time required to input the patient name and ID would often exceed the time it takes for the nurse to record the vital signs for the patient. As a result, most of these devices fall into the "other" category - see below.

Point of Care Testing Devices

POC testing devices include a wide range of device including glucometers, coagulation analyzers, and cardiac marker analyzers.  A system typically includes a connectivity method which is often a docking station used to upload test results to a lab or HIS system. Depending on the device, patient context is either entered manually or captured via a barcode. Some POC testing vendors have started thinking about providing wireless connectivity. The usual problems are clearly outlined here.

IV Pumps and Infusion Management Systems

The typical system may include IV pump devices, vital signs measurement devices, and a centralized gateway for data aggregation, and management of IV pump devices (i.e., for managing the updating of drug formularies and CQI data reporting), and HL7 interfacing.  The only current methods in use today for managing patient context are either manual entry of patient ID into the individual IV pump or barcode scanning.

The problems with manual entry are similar to patient monitors except that some patients receiving therapy from multiple IV pump devices. So this only further complicates any manual process. From my experience, most hospitals have (rightfully) made the decision not to go with any manual process for patient context mainly because it is too cumbersome for the nurse. But also because of corner cases -- such as what happens when the nurse enters the wrong ID or even a nonexistent patient ID into the pump? The answer is nothing happens per-se. Which may lead to further problems - such as the data and alarms from that device cannot be easily integrated with external systems.

Barcoding is the only other available method today for capturing and entering the patient ID. Here the user typically must use a barcode scanner provided by the medical device vendor. This may work fine for the IV pump and for drugs delivered via that IV pump, but what about general medication administration? Usually another barcode scanning device must be used. I will save the discussion about "less than optimal workflows" and challenges around barcoding for another posting.

Other Bedside Devices - Ventilators, Pulse Oximeters, Beds, etc.

With devices that fall into this class, there essentially is no technical capability for the device itself to accept a patient ID. From my previous post, for connectivity to work you need to manage the patient context somewhere. In this case, some other system must manage the context linking. The most logical place for this to be managed is in a bedside device interface system.

So what should hospitals and clinicians do to deal with these issues? When evaluating connectivity projects, work with all of your vendors to understand their capabilities for establishing patient context. Pay particular attention to the resulting impact on workflow and end-user training that may be required, particularly interactions between workflows for different devices. Assess the issues from the perspective of each class of bedside device as well as from the application side. Ask the key question - what does the resulting workflow look like for the clinician taking into account all the devices at the bedside and the EMR?