Mitigating Failure in Medical Devices

Mitigating Failure in Medical Devices

Products fail. We’ve seen it time and again, from smokeless cigarettes to Ford’s failed Edsel automobile and the $680 million submarine that could not float. The reasons are many and the impacts are far-reaching. They affect a company’s reputation, and stock price, and can be the genesis for lawsuits. What makes medical device failures even more concerning is that they often affect the health of consumers, and in the worst-case scenario, may lead to death. Despite rigorous certification and compliance requirements from the US Federal Drug Administration (FDA) as well as the European Medicines Agency (EMA), many medical devices fail every year. Most medical device failures fall into the following categories:

  • Poor documentation – poorly written, incomplete, or incorrect documentation may result in poor performance and outright failure to perform.
  • Product malfunctions – the product simply didn’t perform as specified and certified.
  • Software issues – false readings, inadequate performance, or unexpected behavior lead to products malfunctioning.
  • Manufacturing issues – the product was not manufactured as designed, which causes errors in use.

This blog highlights a few real-world examples for each of the above categories, presents viable reasons for failure, and lays out possible remedies through better governance, collaboration, and data gathering throughout the product lifecycle. These remedies will help to avoid future breakdowns through the application of Product Lifecycle Management (PLM) technologies and solutions in the ideation, design, and manufacturing phases of a product’s lifecycle.

Poor Documentation 

Consider the following product failures due to poor documentation:

  • A scalpel used for emergency umbilical vein catheter placement posed a safety risk due to poor usage documentation of usage
  • A heart assist pump was recalled because its instructions required updating 
  • A surgical procedure pack mislabeled its Lidocaine dose (labeled as 1% as opposed to the proper 0.5%)

Proper documentation, assembly, and user instructions are crucial for the proper usage of medical devices. Unfortunately, the groups who document a product or create user instructions are not the same people who conceived or designed the product. Their role often comes later in the lifecycle, so documentation may be hurried to rush the product to market, may be improperly translated, or may be developed last minute, almost as an afterthought. The authors of such documentation are not involved with creating stakeholder requirements, do not have access to data created during the design phase, and are usually asked to create the documentation after the product design is complete.

Document authors should not be disconnected from the product lifecycle; rather, they should be fully integrated into the product lifecycle ecosystem. This enables users from various disciplines to author, visualize, share, and publish information all within a central, controlled, and collaborative environment. When they have access to and can participate in the systems architecture and requirements definitions for the product, they can better articulate product information to end-users. Parameters detailed in requirements can be definitively expressed in documentation, and geometric views captured in the design process can better illustrate difficult concepts. When design details change, as they will, they can be automatically updated in the documentation, avoiding costly misinformation being given to end-users. Final documents can contain information from graphics in the PLM library, other technical documents, data queried from individual items, and the author’s text. The system should identify stale or versioned content. Content created within the Aras Innovator architecture and processes is semantically rich in governed structures, with consistent content layout versus an individualistic author-defined document. Consistent, up-to-date documents greatly reduce errors and misuse by end-users.

Product Malfunctions 

Consider the impacts of these product malfunctions: 

  • An internal pump used as a bridge for heart transplant candidates may malfunction and lead to worsening conditions
  • A heating element in a lavage kit may release high levels of aluminum, exposing patients to toxic conditions or even death
  • SARS-CoV-2 assayer may give false readings

Despite the best efforts of product manufacturers, products still fail. Components break, products don’t perform as specified or may have unforeseen consequences. Aras Innovator offers applications to design, build, and operate complex products effective in reducing some product failures by fostering better collaboration between stakeholder domains, refining processes between the domains, and capturing design intent and changes accurately and completely. This results in more innovation, faster time to market, better compliance, and more stable products.

Another technology integrated within the governance umbrella of Aras Innovator is simulation. For far too long, simulation existed as a separate domain with highly specialized participants. Simulation can now be made available throughout the lifecycle, including the regulatory process, bringing insight, documented test results, and collaborative insight to the design.

Software Issues 

Consider the impacts that may result from software issues in medical devices: 

  • Software issues in a nitric-oxide delivery system for newborns may cause delivery complications
  • Ventilator software issues may result in lower oxygen flow than required
  • Mismatched medications may result from a software defect in an infusion pump

More and more medical devices are computers performing medical purposes in conjunction with mechanical devices, probes, and monitors. Historically, the practice of software engineering is separate from the mechanical and systems engineering domains. As software continues to play an even more important role in devices, the two practices are slowly merging. This is proving difficult, as they use different tools in their engineering practices. Mechanical engineers have been using PLM for many years, but software engineers have been largely excluded and developed their own tools to document and publish designs.

As the two practices become more closely integrated, better products will result. Software engineers need to be fully involved during the architectural and requirements definition phases to understand the entire scope of the envisioned product. They need to be part of the change management process to incorporate changes into their own procedures. Finally, the two domains need to be closely integrated to properly document the development of the product.

Manufacturing Issues 

Consider how manufacturing defects may impact the use of a product: 

  • A catheter insertion guide may not be sterile
  • Incorrect market gradations on an insulin syringe can lead to incorrect dosage
  • An applicator for a pre-surgery cleansing kit may be contaminated with a specific fungus (Aspergillus penicillioides)

If the best-designed and certified product is not manufactured correctly, it can fail and cause harm to the public. Poor quality control can lead to an inordinate number of failures. The substitution of unauthorized materials that are cheap and low-quality contributes to reliability issues and longevity.

The successful transformation of design data into manufacturing data is critical for reducing errors and increasing the speed of delivery of new products. During design, an Engineering Bill of Materials (EBOM), a structure that reflects the engineering definition of a product including functional groups, assemblies, and parts, is created and results in connected data, or a digital thread, from ideation through design. Fundamentally different than the EBOM, a Manufacturing Bill of Material” (MBOM) is created to define how the product is to be manufactured and assembled, continuing the digital thread further into the lifecycle. Ideally, the MBOM is created automatically, and if it exists within the same platform as the EBOM it can be updated as changes occur. Capturing these changes, or failing to do so, is a critical step. If managed correctly, many of the errors in manufacturing can be avoided, limiting product failures in the field. 

Products fail. There may be no way to avoid all product failures, but there are ways to mitigate them if appropriate and effective technologies are employed to connect data, people, and processes into a single ecosystem within the foundation Aras Innovator. Errors are reduced. Time to market is decreased. Innovation flourishes. End-users have a better experience, and lives can be saved.

For more information, visit our medical device solutions page