This article is the third in a series that will address the products liability risks associated with medical devices and software failures. While software can transform medical device capabilities, its use also creates new products liability risks or changes the nature of existing risks. This series provides descriptions of some of the software-related trends I have observed as well as some prognostications about where software is taking us.

The first article discussed products liability law and its application to software-driven medical devices. The second article looked at the use of software in medical devices in non-clinical settings—particularly, the home environment. This article discusses “interoperability,” or the ability to link multiple medical devices together via a shared software language. The purpose of making devices interoperable is to synchronize their functionality and thereby make the delivery of care smarter and more efficient than when devices operate independently from one another. While interoperability creates opportunities to enhance patient safety, it also creates some new risks (and new products liability exposures) that should not be overlooked. This article discusses those risks and offers some suggestions for managing them.

“Interoperability” is an important software buzzword. It refers to the ability of two or more software programs—and thus the devices to which they are attached—to “talk” to one another. FDA defines medical device interoperability as “the ability to safely, securely, and effectively exchange and use information among one or more devices, products, technologies, or systems.” Advocates of interoperability tout the advancements in medicine and patient safety that it promises and, indeed, has already delivered. For example, consider the safety benefits derived from enabling a portable x-ray unit to “speak” directly to an ICU ventilator.¹ With the devices working independently of one another, a healthcare provider would have to turn off the ventilator at end-inspiration in order to capture the x-ray image properly. (Taking an x-ray during respiration can produce a blurry image.) However, enabling the devices to communicate directly would make it possible for the x-ray to be synced with the ventilator and trigger automatically at end-inspiration. Communication between the devices eliminates the need to turn off the ventilator and avoids the risk of depriving the patient of oxygen.

Read Part II of the series, which looks at the use of software in non-clinical settings: The Homefront

Given the potential of interoperability, we can imagine the impact that it will have on device-rich environments such as operating rooms. In June 2016, a prototype of an interconnected operating room was unveiled at Tokyo Women’s Medical University.² The Japan Agency for Medical Research and Development in collaboration with Tokyo Women’s Medical University and Hiroshima University have created what can be described as “the operating room of the future.” It is composed of a networked system of at least 20 devices (made by various manufacturers) that integrates data from each at a central control panel, where surgeons can perform procedures with the help of two robotic arms. The plan is to finish testing the system by March 2019 and make it available publicly later that year. Fully-integrated operating rooms are not yet a reality in most healthcare environments, but limited versions of this technology are available today. Stryker Corp., for example, currently offers the iSuite, which is “a combination of equipment and software that transforms the traditional operating room into a modern, state-of-the-art surgical environment” when used to connect Stryker’s own line of integrated equipment.

Learning from Mechanical Interoperability. Although interoperability—as a software concept—appears to be something new, it has long existed in healthcare, but without the buzzy label. There are numerous examples of medical devices that were designed to interact with other medical devices, each with its own functionality, created by different manufacturers but intended to contribute collectively to deliver a particular treatment. Historically, the connectivity of these devices was enabled by mechanical parts, rather than software. Manufacturers of interoperable software programs should look to examples of mechanical interoperability failures as precursors of what’s to come.

A Case Study: Connection Problems

Consider medical tubing sets and their use with a variety of devices across medical applications, including intravenous (IV) catheters, bladder (foley) catheters, nasogastric (NG) tubes, enteral feeding tubes, etc. The tubing sets and the various devices to which they are designed to connect are often manufactured by various companies, yet intended to work together “interoperably.” For the most part, the systems that these connected devices create function well; however, there are hazards associated with them. These products demonstrate what can happen when the desire to make devices interoperable weighs too heavily in the design process, facilitating easy yet problematic connections between products.

Many devices that make use of medical tubing connect via a locking system. Historically, there have been two types of locks, the “luer lock” and the “friction fit” (also known as a “luer slip”). The luer lock was created originally to standardize the fit between hypodermic needles and syringes, allowing manufacturers to make widely compatible products and broaden the market for both types of devices.³ The luer lock has an important advantage over the friction fit lock, though, and its use eventually became popular with a broad array of devices and tubing sets. The luer lock can prevent unintentional separation of the tubing from the device better than the friction-fit lock. The friction-fit lock, which is older technology than the luer lock, is still used commonly, however. To facilitate interoperability across a wide variety of products, many manufacturers of medical devices added flanges to their products so the fittings could accommodate both luer and friction-fit locks. What transpired as a result is an interesting case study about interoperability.

When Devices Should Connect But Don’t

The underlying facts that gave rise to a lawsuit called, Hansen v. Baxter Healthcare Corporation, provide us with one “real-life” example of a patient injury caused by devices that did not connect properly.⁴ The plaintiff in that case underwent stomach ulcer surgery. In preparation for surgery, the healthcare provider inserted a catheter into her jugular vein (a central venous catheter) in order to transfuse blood or other fluids. The catheter (manufactured by a company that settled with the plaintiff and exited the lawsuit early) was connected to an IV tubing set manufactured by Baxter. In 1991, at the time of the plaintiff’s injury, Baxter offered its IV tubing sets with both types of locks (friction fit and luer lock). In this instance, the hospital where the plaintiff was being treated used the friction-fit technology.

Following a successful surgery, while in recovery, the IV tubing became disconnected from the catheter. As a result of the disconnection, the plaintiff suffered an air embolism in her brain, causing brain damage and paralysis. She died on June 4, 1995. In the products liability litigation that ensued, Baxter was found liable for a design defect on the basis that it had reason to know that its friction-fit product was used commonly with central venous catheters, though these catheters required use of IV tubing sets with luer locks in order to prevent disconnection. Hansen represents the unfulfilled promise of interoperability, when the maker of a device intends for its product to work interoperably with another manufacturer’s device, but a defect (likely related to design) prevents successful connection.

Continue to page 2 below.