gavel

Medical Device Software & Products Liability: Interoperability (Part III)

By Sara E. Dyson, Esq.
2 Comments
gavel

How software is changing the legal landscape for medical device manufacturers.

This article is the third in a series of four 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.1 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.2 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.3 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.4 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.

About The Author

Sara Dyson, Medmarc

Comments

  1. Horst

    Thank you for this article. Being an active member of the PCHAlliance/Continua and a manager at Roche Diabetes Care your article gave me quite a bit to think about. Let me pick one key statement. Quote: “There are two routes to interoperability. A company can create a device that is designed to be used with products created by any other manufacturer, or a company can create a device that is designed to be used with products created by a specific manufacturer”. Does the use of interoperability standards and the mention of the use in the labeling automatically imply that the device is designed for use for any manufacturer? Is there any liability for the standards development organization that can be derived from e.g. a mission statement that “claims” universal interoperability?

    1. Sara Dyson

      Horst, thank you for your questions.

      With respect to the first one, a company that creates a product that is interoperable, presumably by use of a standard, and touts its “connectability” in product information could be described as having – even inviting – open connections. To relate this concept to a non-software-related product, consider the manufacturer of electrosurgical equipment. The product is composed of a console with connectable instruments (such as surgical knives). Imagine that this manufacturer creates a port through which the user can connect instruments, universally, whether created by our manufacturer or another manufacturer of similar equipment. Our manufacturer includes in its product literature information about the universal port (and, indeed, touts this feature as a product benefit). Based on these facts, I believe that you could find that the manufacturer has implied that the device is designed to be used universally. On the other hand, if a manufacturer wishes to avoid this implication, it should do two things: (1) create design features (software-related or mechanical) to prevent connection with products to which it should not be connected and (2) include in product information (IFUs, package inserts, labels, training, etc.) warnings about any potentially hazardous connections as well as clarification about what products are safe to use with it.

      In regards to your second question, I believe whether a standards organization has liability in a particular case will depend on the facts that arise – namely who is injured, the product involved, and the nature of the injuries. For example, a standards organization that sells a standard (and perhaps related services) could find itself liable under a breach of contract theory should it not deliver the promised benefit to the manufacturer. I suspect, however, that your inquiry is about whether a standards organization could be liable for an injury caused to a patient when a manufacturer relies on the standard to effectuate interoperability and the patient is injured in some way based on the interoperability features of the product. Tracing the causation of the injury back to the standards organization seems remote – unless there is something evidently harmful about the standard. Rather, if a manufacturer has wrongly applied the standard – such as if the standard is inappropriate for the product or incorporated negligently into the design – then liability will likely be limited to the manufacturer. Again, the outcome will be dependent on the facts that give rise to the injury.

      I hope this information is useful. Please let me know if you have any additional questions.

Leave a Reply

Your email address will not be published. Required fields are marked *