This blog post is intended as a high level review of the issues surrounding the creation and management of patient context for data acquired from medical devices. This post is not a definitive explanation of all factors associated with patient context, nor does it provide “the answer” to any particular patient context need.
This blog post is intended as a high level review of the issues surrounding the creation and management of patient context for data acquired from medical devices. This post is not a definitive explanation of all factors associated with patient context, nor does it provide “the answer” to any particular patient context need. The intent of this post is to describe different requirements, technologies and workflows that impact the requirements and design of optimal patient context management. The goal here is to flesh out a framework to think about and discuss patient context and how it can impact patient safety and user acceptance.
Connectivity enabled medical devices send patient data right out of the medical device to a network, be it a body area network, cellular broadband network, home or enterprise network. The network then conveys this medical device data to databases and applications that store, display and manipulate the data. When a medical device is directly attached to a patient, there is no question as to which patient the device data belongs. As soon as the data leaves the actual medical device via the serial port or a network connection, the association of that data with a particular patient is no longer obvious.
Much of the data used in establishing and maintaining patient association or patient context comes from, or is stored in, the patient management database. Patient management workflow is an important enabling component in the overall connectivity solution and key to patient context management.
More Read
It is critical to reliably know that the data from a medical device belongs to a particular patient. If the data is not associated with any patient it’s worthless; should the data be associated with the wrong patient it could be deadly. When patient data from patient A is misidentified as belonging to patient B, patient A can miss out on a life saving clinical intervention that is mistakenly applied to patient B. In this example, patient A may die due to a lack of care, and patient B may be injured or die as a consequence of receiving some clinical intervention that is not needed and could be contraindicated. Consequently, safe and reliable patient association or patient context management is a foundational capability for virtually any medical device connectivity or interoperability solution.
Many patients are connected to a medical device over time. Besides accurately identifying the patient currently attached to the medical device the design of patient context management features must reliably known when the patient that’s been attached is now detached and that subsequent physiological data is from a new patient rather that the previously attached patient. Now this may seem like a no-brainer, and in many cases it is self evident. But, this is not always the case. When reviewing data retrospectively, the user has no way to know if gaps in data represent changes in patients. In actual operation, the device and patient may be out of view of clinicians and caregivers. Staff often circulates and changes as shifts change, so that in certain situations patient context is no longer self evident and how patient context management is designed becomes critical to ensuring patient safety.
Besides the obvious patient safety issues, patient context faces another difficult challenge: usability and workflow. Identifying the patient to the medical device, i.e., establishing patient context, is not something that is done when there is no connectivity feature. Consequently, any patient context workflow becomes “extra work” or workflow steps that were not required prior to connectivity. Connectivity is supposed to provide workflow automation, which implies less work rather than extra work. Users of connectivity solutions base their product evaluations on whether the new solution is easy to use and has fewer, the same, or more steps required to use the device when compared to the previous iteration of the device. Poor usability and/or extra workflow steps can spell poor user acceptance or outright rejection.
There are many ways to enable patient context, and can methods vary dramatically based on the use model of the medical device. The following are some key factors to consider when contemplating requirements for patient context:
Spot or Continuous Data
Spot vital signs monitors are pushed from patient to patient, reading vital signs that then go into the patient’s record. Patient context is created for the time required to gather these vital signs readings (often just a minute or two) after which patient context is removed or torn down. In some systems, the act of creating the next patient’s context serves to remove the previous patient’s context.
This contrasts with continuous data. These use models include many medical devices that are attached to the patient for an extended period of time, from hours to days in length. The data produced by the medical device could be continuous (often waveforms) from a patient monitor or ventilator, or periodic data that represents an episode of care over an extended period, such as alarms or device specific therapy related data from an infusion pump or dialysis machine. In this “continuous data” group of use models, patient association is established for a relatively long period of time and must be maintained over changes that occur naturally over longer periods. Potential changes can include changes in patient location, changes or reconfiguration of the medical device attached to the patient, staff changes, and changes in the patient’s condition.
Diagnostic or Patient Care
Many diagnostic patient context workflows are similar to spot vital signs. Patients are queued up and attached to the diagnostic device one at a time in a serial fashion. The patient’s location with diagnostic devices usually fits into one of two models, one where patients are brought to the device (like an endoscopy lab or cath lab) and one where a specimen from the patient is brought to the diagnostic device (like in the clinical lab).
This contrasts with patient care devices such as patient monitors, infusion pumps, ventilators – devices that tend to be attached to patients for expended periods (and longer periods than diagnostic devices). Unlike diagnostic systems which tend to be centered on individual labs or diagnostic devices, patient care devices include multiple devices that operate in the same system. For example, a cath lab control room connects to one hemodynamic recorder and visualization system, while the central station for a patient monitoring system typically displays waveforms from each patient in the unit connected to a patient monitor. These different use models impact the risk analysis, and consequently the requirements, for patient context design.
Stationary, Portable or Mobile
These are major factors in determining requirements for patient context. Stationary devices are tied to a particular physical location and are often networked via Ethernet – a network with a physical wire. Patients are brought to the stationary medical device, be it a CT or MRI bolted to the floor, or a wall mounted patient monitor in an Emergency Department trauma bay. With stationary devices it is tempting to use location as a key determinant for patient context – in this case, the data from device X is associated with the patient that is also at the same location. There is a risk that the patient we think is in this location is in fact in another location, and patient context is established for the wrong patient.
Portable devices are one’s that are used in a variety of locations within the hospital, within a unit, within a surgical suite, within a patient room or within various areas of a patient’s home. Typically their use model is one where the device is stationary, and only moved between uses. Here one may be tempted to use Ethernet for connectivity, but because of the portable nature of these devices, this will often result in usability and reliability problems caused when the device is moved before unplugging the network cable, or forgetting to bring the network cable to the new use location of the medical device. Moving portable devices prior to removing the network cable results in broken cables and connectors, pulled out wall plates, and sometimes broken medical devices. In almost all cases, wireless connectivity is industry best practice for portable devices.
Mobile devices are devices that are in use while in motion. This could be any patient attached medical device used during transport – inside or outside the hospital – or used when the patient ambulates. Wireless connectivity is the obvious choice for mobile medical devices. Just to be clear, many portable medical devices are only occasionally used in a mobile fashion. But if they are to be effective when mobile, product requirements must actually support mobility. For obvious reasons, industry best practice for devices that go mobile is wireless connectivity.
Wireless connectivity complicates requirements for safe and effective patient context management. Wireless connectivity is not perfect, and especially when mobile, wireless connections can fail for a period of time as wireless devices go in and out of coverage. A key issue here is that it is not always clear if the current set of acquired medical device data is from a new patient or the patient previously (or still) attached to the medical device. To ensure patient safety, the system must be confident that the same patient is attached to the medical device after the device loses its network connection and when it is restored. Assuming the data from the reconnected medical device is a new patient and forcing the user to reenter or re-associate with the same patient mitigates the mistaken identity risk, but at the cost of user acceptance. Most systems implement some sort of algorithm to determine when it is safe to assume the patient has remained the same, when a patient’s ID must be confirmed by a user to maintain an association, and when it is best (for both patient safety and workflow reasons) to assume the patient attached to the medical device is a new patient.
Wireless Sensors
Wireless sensors add additional challenges to the wireless connectivity for patient context management. A key challenge here is the scarcity of user interface on a wireless sensor or gateway device that could be used to implement patient context workflows. Most wireless patient monitors will present a list of patients on the unit from which the user selects the patient that’s being attached to that patient monitor. Yes, it’s an extra step, but it is relatively quick and everything is self contained on the patient monitor. This is not possible with a wireless sensor. The typical user interface on a wireless sensor is one or more LEDs and perhaps an accelerometer or low voltage piezoelectric buzzer or speaker.
Wireless sensor patient context workflows can be further complicated by the fact that users will likely be carrying additional sensors and/or gateways in their pockets. Consequently, a scheme to positively associate sensors with a gateway and with the patient wearing the sensors cannot be designed that assumes that the sensor and gateway will be the only ones within range of each other.
Retrofit or Built-in Connectivity
Virtually every medical device made in the last 20+ years meets a basic connectivity requirement in that they output data in a machine readable format. This is done via the serial port on the medical device that uses a communications protocol that is proprietary to that device’s manufacturer (and may be specific to that model of device and even that version of that model). That serial data stream must be parsed to extract meaningful clinical data. And the serial connection must be converted to some sort of network so that the data can be efficiently moved around to the appropriate servers and client applications. The systems that acquire this serial data, parse it and convert it to a network connection are called Medical Device Data Systems.
Most hospitals implementing the clinical documentation workflow are using these MDDS to acquire data from the various medical devices that produce data that ends up on patient flow sheets in medical records.
These MDDS have traditionally been wired systems. In the early days, especially when most medical device being connected were stationary or minimally portable, these systems used stationary terminal servers to convert the serial data to Ethernet. Each terminal server had numbered ports that were associated with the stationary location of the terminal server. The industry best practice at that time was to associate a patient with location, which was then associated with a port number and patient location. This association was done in either the MDDS or EMR away from the patient. This approach worked pretty well but has certain risk management implications.
Theoretically, transactions such as establishing patient context are most accurate and reliable when they occur at the point of care in the physical presence of the medical device and patient. Abstracting the association of medical device and patient by using a terminal server port and bed location to determine patient context is theoretically less accurate and reliable. In the real world, using any medical device systems exposes to the patient to inherent risks that , once identified in a risk analysis, are mitigated by a variety of methods.
Auto ID and Patient Context
There are a number of methods can used to establish patient context. Typically, the best workflow solution is when the user first applies the medical device to the patient and the user indicates the patient being attached to the device. This process of indicating the patient can be implemented in many different ways. The user can select the correct patient from a list presented on the medical device or some sort of client device, or the system can “read” the patient’s identity via a barcode or RFID. Worst case, the user is forced to enter the patient’s name and/or ID into the medical device. Manual data entry is not only time consuming, but also prone to error.
A brief aside about barcode technology: Many medical systems use barcodes to capture data, and they do reduce the potential for transcription and typographical errors when compared to manual entry. While it is often called an “auto ID” technology, there is little that’s automatic about picking up a barcode scanner and scanning a barcode – sometimes repeatedly – until it’s read. This contrasts with technologies that are truly auto ID, like passive or active RFID tags where the system automatically senses the tag and reads the data with no human action required. (There is of course, a manual verification step required by both barcodes and auto ID systems.)
In some situations, the preferred way to establish patient context may be unavailable or inoperable and an alternative method may be required. For example, if patient data is received through an interface to the hospital’s ADT system, and that system is either down or the transactions for a particular patient is lagging, there must be an alternative method to get patient data into the connectivity solution. Or perhaps the barcode reader is broken or can’t read the patient’s barcode; again, there must be an alternative method to enter that patient data. Oh, and don’t forget emergent situations, where you don’t have time to tell the system who the patient is, and situations where you have a patient with an unknown identity. The connectivity solution must account for these variations in workflow.
This concludes the overview of patient context workflow. By necessity, much has been left out of this discussion. Feel free to suggest additional topics and issues that relate to patient context in the comments below.
(medical data / shutterstock)
