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?
Thanks Brian. As you may or may not know, I have been in the AutoID space since 1999 and was in the instrumental phases of all the initial BMCA with the VA, year 2001. The original intent was to validate the POC for the five rights has certainly evolved. While the generic term “bar coding”, is what is used in the healthcare sense, it should be as stated AutoID. Early stage 1D, laser scanners in healthcare at the POC model had issues. The laser must be able to “scan” or hit the front head and back of the bar code to confirm/(decode) the data. This tended to be difficult if the actual 1D truncated bar code was on a curved surface, (wristband), thus not allowing an easy decode, (since the laser could not be 3D) Clinical personal tended to become frustrated with this early on. Retail vendors overcame this issue by have an ominidirectional scan engine embedded in a surface flat bed scanner. This all changed as laser scan engines were left behind by CCD imagers that did not “scan” but actually were able to take a picture of either 1D, 2D, PD417, Composite, RSS, and then use software to decode the information (in the case of PDF417 a ton of information). The next evolution was and is to use an imager with a wireless/detached handheld imager. While this is not perfect, it gets around dealing with a corded/attached scannne/imager. The CCD imager using RSS/Composite obiviates the need for 1D over via the complex issues of laser scanning on a curved surface. Thus, for the first time we are able to improve the POC work flow model. I witnessed this as my wife came out of surgery and I worked with the clinical personnel and saw first hand their embracement of technology that can truly help them in caring for patients, but also reducing their anxiety in terms of dealing with potential but not perhaps on their radar screen issues our concerns with the patient care experience.
Great Article Brian!
I am an RN in a Clinical Analyst role at a hospital looking at the possibilities of wireless medical devices (Smart Pumps, portable vitals, etc) Patient context is difficult enough to manage on wired devices, even more so with wireless. It has been very frustrating to know what is needed and not see the vendors respond to the need.