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

By Sara E. Dyson, Esq.
February 12, 2018


• Categories: 04-Product Design & Development, 05-Quality/Regulatory, RC - Medtech Regulatory Resource Center

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.

When Devices Connect but Shouldn’t

Whether mechanical or electronic, devices that are interoperable can also create “accidental systems,” which occur when two things connect that should not be connected, giving rise to a hazard. In 2010, the FDA cautioned the manufacturers of enteral feeding tubes of this very risk. Again, luer-lock technology was at issue. The letter advised, “FDA is aware that standard luer-lock connectors are found on a variety of tubing sets, solution bags and other medical products. The ease of connection between these luer-lock connectors ha[s] led to misconnections that have inadvertently linked unrelated systems, and at times, have resulted in serious adverse events.” Some of the worst examples of accidental systems involved enteral feeding tubes. Enteral feeding tubes would become mixed up with IV tubes and send “food” into the patient’s blood stream, resulting in permanent injury or death. During a 10-year period, more than 1,200 accidental connections were reported.

Read Part I: Medical Device Software & Products Liability: An OverviewFollowing patient injuries, manufacturers of this technology grappled with potentially messy products liability lawsuits. Under products liability law, if two devices interact to cause harm, a plaintiff will be able to sue the manufacturers of both devices. Each manufacturer-defendant then has to prove that its product was not defective and did not cause the plaintiff’s injury. Lawsuits that arose from tubing-connection errors could become bogged down in apportioning blame between healthcare providers and the manufacturers of the connectable products involved.
Managing the Risk. In a quest to facilitate interoperability, luer-lock manufacturers inadvertently created an environment in which products became “too connectable.” Either connections were invited but were not effective (as in Hansen), or connections were made when they weren’t intended (as in the case of tubing mix-ups). Luer locks are a cautionary tale for manufacturers that are developing products that will be interoperable via software. Eventually, luer locks became safer, and some of the lessons learned by the manufacturers that use luer-lock technology may be applicable to software interoperability.

Be Wary of the “Too-Interoperable” Trap

As the luer-lock misconnection threat emerged, there were calls from patient-safety organizations, including from the Joint Commission, a nonprofit that accredits hospitals, to address the hazard, particularly as respects the connections with enteral tubes. The industry experienced a period of confusion as it sorted out who—manufacturers, regulators, and healthcare providers—would lead the effort. In the meantime, some manufacturers developed alternatives to traditional luer-lock technology, but these products never gained a toehold in the marketplace, and other attempts at fixes proved ineffective. Finally, almost two decades later, a collaboration between FDA, the International Organization for Standardization (ISO), and other standard-making organizations resulted in the AAMI/ANSI/ISO 80369 standard, which was first published on December 15, 2010, and has since undergone revision. The standard applies to “small bore connectors,” which are used to deliver fluids and gases to patients. In 2012, FDA issued a related, draft guidance document (that was finalized in 2015) that instructs industry on properly mitigating misconnections in tubing used with this type of luer connection, primarily through product design and labeling.⁵ FDA is currently studying the impact that the standards have had on patient safety.⁶ However, there is a sense among industry—manufacturers, in particular—that these efforts have resulted in safer products.

As manufacturers work to make medical device software communicate, various industry groups have called for standards for interoperability. However, unlike with luer locks, those calling for interoperability standards are motivated primarily by the prospect of making interoperability easier across an array of products. That is, their intent is to standardize software communication to create a “plug-and-play” environment in which a variety of devices can be connected. In contrast, standards for luer locks grew out of a need to fix a patient-safety problem that arose precisely because products became too connectable. With the rush to interoperability, there is a risk that industry may be overlooking hazards that can arise from too-easy connections.

For now, just as what occurred with luer locks, industry is grappling with identifying who will take the lead in developing interoperability standards. Several organizations have emerged as leading the charge, though it does not appear that industry is close to agreeing on the path to standardization. In the meantime, on September 6, 2017, FDA addressed interoperability in a guidance document titled, Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices. Similar to its response to the luer-lock hazard, FDA addresses a variety of concerns related to interoperability, including the risk of improper connections, by recommending design and labeling fixes.

Historically, when hazards have emerged, industry has turned to standards to address patient safety. Ironically, as a result of industry’s zeal to make interoperability easy, standards may exacerbate a hazard in this case. It is particularly important, therefore, for manufacturers to remember that compliance with standards will not protect a manufacturer from products liability. (Indeed, even compliance with FDA regulations is not a protection from liability for the manufacturers of Class I and II devices.) In other words, just because a particular device complies with a standard does not mean that the device will be considered free from defect in the products liability setting.

In products liability, a product is judged based on how reasonably well a manufacturer protects persons who come into contact with the product from foreseeable risks that arise from both the intended use and misuse of the product. While compliance with standards is often a way for a manufacturer to demonstrate “reasonableness,” standards are not a panacea. A plaintiff who can demonstrate that a manufacturer should have done something more than merely comply with a standard in order to protect patients may prevail in a products liability action. Accordingly, to avoid liability that could arise from too-easy connections, it is imperative for manufacturers to use design and labeling features to manage the risk and not simply fall back on standards to guide the product-development process.

Prevent the Risk of Unintended Connections through Design and Warnings

Industry groups fought the tide of luer-lock interoperability by calling for product features that would prevent connections. An article that appeared in The Joint Commission Journal on Quality and Patient Safety urged, “In simple terms, any system that carries a high risk of injury if connected unintentionally to another system should have design features that prevent the possibility of inadvertent connection.”⁸ Later, the standards for luer locks and the related FDA guidance document addressed the need to prevent connections through design and labeling.

In an increasingly interoperable world, the manufacturer that figures out not only how to make its software connectable but also how to prevent inappropriate connections will create the superior product. Just as with luer locks, a product’s design and labeling will be important to addressing the problem. A manufacturer that fails to prevent hazardous connections through design features could face liability should the device injure a patient, particularly when a competitor product includes such safety features or when a design solution that would make the product safer is feasible but nevertheless omitted. In the context of products liability, “designing out” a problem is always preferable to minimizing risk through warnings. For this reason, warning about potential connection problems should be a manufacturer’s “Plan B.” In its guidance related to interoperability, FDA advises, “If the device is meant to interact with only a few specific devices, the labeling should explicitly state that the medical device is meant to connect with the specific devices listed (including the version) and that it should not be used with other medical devices or nonmedical device technologies.”⁹ In products liability, an effective warning will describe the hazard—in this case, the consequences that arise from inappropriate connections—and how to avoid it, such as by identifying the devices likely to be found nearby that are vulnerable to unintended connections and the steps a user must take to prevent them.

Make Your Risk Management Strategy “Interoperable”

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. For example, there are products like luer locks, electrosurgical equipment and dental instruments that are designed to be interchangeable, or combined with products created by several other manufacturers. In other instances, companies set out to create interoperable products in collaboration with partner-manufacturers. For example, consider the relationship between Stryker Corp. and Neurologica, a subsidiary of Samsung Electronics America, Inc. In 2012, the two companies announced a plan to integrate their products—a neuro navigation platform and CT scanner, respectively—to offer a “turnkey surgical solution” for customers wishing to acquire this technology as a connected system. The combination of the products promises to “enhance the surgeon experience and simplify the purchasing process for hospitals,” according to a Stryker press release.

Manufacturers that work with partner companies to create “monogamously” interoperable products have an important opportunity to manage risk that manufacturers creating “openly” interoperable products do not. Partnership creates the opportunity to work collaboratively to address possible safety hazards that are created by combining products. Making two existing technologies interoperable means that manufacturers are integrating more than software. They are also integrating other types of product features, such as human-factors signals, those design aspects that are intended to guide users to interact with the product safely and effectively. Whereas each product may have individually undergone human factors analysis, combining the products creates a need to ensure that safety signals are compatible between devices. The same is true for warnings and instructions. Between the products, are the hazards described consistently? Do the instructions for use (IFUs) share a vocabulary, and are critical terms defined consistently? Examining existing product features in the new context of interoperability can be important to improving safety and managing risk.

Because interoperability failures make co-defendants out of companies that otherwise share symbiotic relationships, it is important to anticipate at the time of partnership formation that interoperability problems could lead to litigation and address this possibility contractually. In particular, manufacturers should anticipate products liability entanglements. Among other terms, the contract should address how parties will notify each other of lawsuits and require them to cooperate in the investigation of claims. Indemnification will be critical, and so will be the contract terms that describe how the manufacturer-partners intend to insure risk, including the types and amounts of coverage required to address it adequately. During contract formation, manufacturers should seek assistance from attorneys and insurance professionals with expertise specific to the life sciences industry to ensure that their agreements address the needs unique to medical device manufacturers.

References

1. Proctor, L. (January 1, 2008). Getting Connected for Patient Safety. How Medical Device “Plug-and-Play” Interoperability Can Make a Difference, Patient Safety & Quality Healthcare.
2. Oshita, J. (August 16, 2016). Japan Developing the Smart, Networked Operating Room of the Future, Nikkei Asian Review.
3. Brown, J. (March 1, 2009). Unraveling Misconnections in Medical Tubing, Medical Device and Diagnostic Industry.
4. Hansen v. Baxter Healthcare Corp., 723 N.E. 2d 302 (Ill. App. 1 Dist. 1999).
5. Safety Considerations to Mitigate the Risks of Misconnections with Small-bore Connectors Intended for Enteral Applications, Guidance for Industry and Food and Drug Administration Staff, Food & Drug Administration, February 11, 2015.
6. Brown, J. (May 1, 2015). ISO 80369 Standards for Small Bore Connectors Move Closer to Implementation, Medical Design Briefs.
7. Class III devices are protected from products liability, except when it arises from manufacturing defects, as a result of a US Supreme Court decision, Riegel v. Medtronic, Inc., 552 U.S. 312, 128 S. Ct. 999 (2008).
8. Simmons, D., et al. Error-Avoidance Recommendations for Tubing Misconnections When Using Luer-Tip Connectors: A Statement by the USP Safe Medication Use Expert Committee, The Joint Commission Journal on Quality and Patient Safety, Volume 34 Number 5, May 2008.
9. Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices, Guidance for Industry and Food and Drug Administration Staff. (September 6, 2017). Food & Drug Administration. p.17.