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

By Sara E. Dyson, Esq.

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

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.5 FDA is currently studying the impact that the standards have had on patient safety.6 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.”8 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.”9 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.

The next article in this series looks at software designed to assist healthcare providers with making clinical decisions and how the makers of these products could be impacted in products liability actions targeting them.


  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.

About The Author

Sara Dyson, Medmarc


  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 *