Products fail. We’ve seen it time and again, from disposable underwear and smokeless cigarettes, to Ford’s failed Edsel automobile and several football leagues set up to challenge the NFL behemoth. The reasons are many and the impacts far-reaching. They affect a company’s reputation, stock price, and are 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, lead to death. Despite rigorous certification and compliance requirements from the FDA, 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 led to products malfunctioning.
- Manufacturing issues: The product was not manufactured as designed, which causes errors in use.
This article 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’s lifecycle, to avoid future failures through the application of product lifecycle management (PLM) technologies and solutions in the ideation, design and manufacturing phases of a product’s lifecycle.
Consider these failures resulting from poor documentation:
- A scalpel used for emergency umbilical vein catheter placement posed a safety risk due to poor 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 disjointed 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, as well as the authors text manually created. The system should identify stale or versioned content. Content created within the PLM 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.
Consider the impacts of these product malfunctions:
- An internal pump used as a bridge for heart transplant candidates may malfunction, which may 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. A PLM platform that offers applications to design, build, and operate complex products can be 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 that should be integrated within the governance umbrella of a PLM solution is simulation. For far too long, simulation existed as a separate domain with highly specialized participants. Now, simulation can now be made available through the lifecycle, including the regulatory process, bringing insight, documented test results, and collaborative insight to the design.
Consider the impacts that may result from software issues in medical devices:
- Software issue in a nitric-oxide delivery system for newborns may cause inadequate delivery.
- Ventilator software issue 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 together. 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 incorporated changes into their own processes. And finally, the two domains need to be closely integrated to properly document the development.
Consider how manufacturing defects may impact the use of a product:
- 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 contribute to reliability issues and longevity.
The successful transformation of design data into manufacturing data is critical for reducing errors and increasing 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 PLM 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 of an integrated PLM platform. Errors are reduced. Time to market is decreased. Innovation flourishes. End users have a better experience, and lives can be saved.