One of the most important areas of connectivity, and one that frequently does not receive the attention it deserves, is establishing and maintaining patient context. Historically, connected devices identified data by location – tagging data with a bed or even port number – rather than the actual patient name or ID. Because patients are frequently moved during an episode of care – not to mention ambulatory – data that is only tagged with a location presents risks of misidentification. In an effort to improve positive patient identification, data is increasingly tagged with a patient identifier.

Besides patient safety, patient context also greatly impacts medical device workflow. (Medical device connectivity is workflow automation through the integration of medical devices and information systems.) How a vendor implements patient context can have a big impact on usability and customer acceptance.

Patient context requirements can vary, based on the type of medical device in question. What is not variable is the requirement to reliably establish and maintain context. Mobile applications (like smart pumps or patient monitoring) where the device may go in and out of network coverage while constantly in use present special challenges. This compares to a fixed or portable medical device, like a dialysis machine or diagnostic ultrasound, with an episodic use case during which neither the device or patient is moved. Another variable is whether the application is life-critical. Continuous patient monitoring and many alarms (e.g., smart pumps and ventilators) are life-critical applications with a higher threshold of requirements. This contrasts with connectivity for documentation like with point of care testing or spot vital signs capture. In all cases though, patient context must be safe and reliable. The above issues just help define how many hoops you have to jump through to be safe and reliable.

In the past few years, medical device vendors have seemingly chosen barcoding as the consensus method for implementing patient context. This approach has two advantages for vendors, it has been implemented by other vendors and represents a no-brainer default solution, and is relatively quick and easy to design (especially compared to alternatives). The problem is that users don’t like most barcoding solutions.

Barcoding solutions can have the following problems:

  1. The resulting workflow is really bad and customers don’t want to use it,
  2. Customers don’t want to buy more than one barcode system, and
  3. Barcode technology is finicky – you have to have the right barcode, printers, ink and labels for a certain application if you want a reasonably reliable read rate.

To be fair, the workflow around barcoding is not inherently bad. Besides challenges reading barcodes, there is the question of how barcodes are generated, an issue that gets too little attention. System-generated barcodes from a database are a great way to generate barcodes for automated data capture. Barcodes generated from data keyed in by a user is subject to typos, transpositions, and “right data, wrong entry” errors than render the resulting barcode little better than any other manually entered data. Of course, accurately reading bad data doesn’t improve patient safety.

A relatively recent connectivity and patient context application is smart pumps. These systems can illustrate some of the problems, both inherent to barcodes and design short comings, around patient context and workflow.

The word “smart” in the term smart pump is relative; as the market matures, expectations for intelligence increase. Infusion pumps with site specific formularies and software that returns an alert when the user possibly mis-configures the pump is really barely sentient. A pump that also captures patient and user context resulting in a much more meaningful CQI (continuous quality improvement) database is more intelligent. But the summa cum laude of smart pumps is one that integrates with an EMAR (electronic meds administration record) and pharmacy departmental system to provide closed-loop meds administration for the highest risk drug category in the hospital – those that are infused.

This state of connectivity bliss is a ways off for the vast majority of hospitals (who just aren’t ready yet) and many pump vendors (who are still struggling with lower forms of smartness), but smart pump installations continue to grow. According to Pharmacy Purchasing & Products, 43% of facilities in the U.S. have adopted smart pumps. Smart pumps linked to bar coded meds administration systems represent a mere 11.5% of installed IV pumps. Of the smart pumps installed, only 26.9% include wireless connectivity.

Not surprisingly, user satisfaction with systems that are not wireless (I’m assuming no network connectivity at all) is low – only 14.3% rate data collection as excellent or good, 26.2% rate it as satisfactory, and a dismal 59.5% of users rate data collection as less than satisfactory or poor. In contrast wireless data collection is rated excellent to good by 75% of users, and satisfactory was chosen by another 18.8% leaving 6.2% of users dissatisfied. But wireless connectivity is only half the story.

A key challenge with workflow and barcoding is that there are many factors that impact usability. Assuming you get barcodes that are reliably scanned the first time, you need a device that’s easy to use and can be positioned properly. If a barcode reader is mounted to the infusion pump or a cart, the entire assembly must be easily moved into position for scanning.Refer to the latest Spyglass Consulting report on Point of Care Computing for Nursing for examples of barcoding gone wrong – tape on the floor showing where to stand, wrist labels cut off patients and taped to folders at the nursing unit, duplicate drug barcodes printed and taped to folders at the nursing unit, and others. Besides poor wireless network converage, the accessibility of barcodes on patients and drugs is a very common problem. Obviously, poor system configuration and implementation can torpedo even an excellent barcode workflow.

In the fall of 2006, Cardinal Health acquired CareFusion to use as their own meds administration and barcoding system. I recall Cardinal’s CareFusion demo at the HIMSS in New Orleans where the poor demo person had to scan each barcode repeatedly while a group of us watched her struggle. This is not an example of a poor implementation of barcode technology, but an example of how finicky barcodes can be and how it can impact usability. Nurses aren’t marketing people, they won’t put up with it.

The bottom line in all this is that the percentage of smart pumps installed in the U.S. that establish patient context for CQI databases or EMR documentation is surprisingly small. One reason is the prevalence of wireless LANs that don’t cover all patient care areas or cover them unreliably. I suspect though, that the real reason is that pump vendors have yet to come up with a quick, convenient and reliable way for users to establish patient context.

Vendors, when designing a system with patient context think about alternatives to barcoding. Regardless of your technical solution, carefully model and evaluate the resulting workflows so users have to go through the same or few steps when using the device. I was looking at the 2008 HIMSS Leadership Survey today and noted under technology adoption (next 2 years) that barcode technology fell from 74% last year, to 35% for 2008. That percentage did not fall because almost everyone’s doing point of care barcoding. While most hospitals fiddle with barcodes somewhere, those using them at the point of care are still in the minority. Don’t assume that buyers are willing to implement your barcoding stuff – especially if it’s not open standards and compatible with all the other point of care barcoding they want to do.

Providers, when you’re looking at medical device connectivity look closely at the workflow – all of it, not just for patient context. Make sure the automated workflow is, you know, better than your existing manual workflow. Be sure to look for similarities and differences between product demos, how site visits may have implemented the system, and how you plan to implement it.