There are many inputs to consider when designing a new medical device product: user needs, regulatory requirements, and internal and external customer requirements, to name a few. Finding harmony and documenting everything is not a simple paperwork exercise. This can be overwhelming to even the most seasoned medical device professional.
How do you make sure the user needs are linked to actionable requirements, and ensure that all requirements have been addressed?
Traditional methods are tedious and labor-intensive with ample room for human error. Using a software solution during the product development process keeps the user needs and product requirements tightly integrated and ensures not only a successful development process, but also a quality and profitable product in the market.
Best practices go beyond any software system and include critical thinking and robust design practices. To deliver a product that truly meets the user’s needs involves meticulously considering the relationships between requirements, tests, and risks, and considering the regulations to make a compliant and useful device.
As per 21 CFR 820.30 (c) - Medical device manufacturers shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.
The Importance of Proper Definition
Properly defining your design inputs including user needs, requirements, component specifications, and test methodologies prepare your product development process for success. If user needs are lost amongst the design requirements and regulatory paperwork, there is a chance of the product reaching the market that fails to sufficiently solve the user’s problems. While design inputs can come from multiple sources, including clinicians, engineering, marketing, manufacturing, etc., every input needs to relate back to the patient. Additionally, user needs should always be verified with potential users, not just internal teams.
Identifying user needs and requirements is not enough. Justification of why a requirement exists is critical to a robust output. The reasoning for the acceptance criteria should be backed up with source documentation such as previous studies, ergonomic data, similar products, and test methods supported by clinical-based information or model analysis, et al.
Requirements must be measurable and not ambiguous. An actionable requirement should be defined similarly to SMART goals, ensuring that they are specific, measurable, attainable, realistic, and timely. When your inputs are unclear or too specific, it can cause limitations within the design:
-
If they are too specific, the design choices may be too narrow and limit the options for designing a more robust solution.
-
If they are too vague, they will not translate well to others (except for the original author), to test methods, or to risks.
The example below demonstrates some of the concepts discussed in this blog. It is intended to be an illustrative example and is therefore not comprehensive.
When a requirement is too weak, there is room for misinterpretation and inadequate testing. One example could be protective sterile packaging. This example steps through the user needs and a few requirements. A strong requirement also leads to strong specifications, strong component output definition, strong risk assessment, strong test methods, strong process measures, etc.
Example:
Poor Definition
User Need: Sterile packaging
Requirement: Design good packaging
Testing Method: Ship across the country and see what happens
Better Definition
Packaging related user needs:
-
Product must be delivered sterile to the operating environment
-
Packaging must protect product through shipping and storage until use
“Product must be delivered sterile to the operating environment” generates numerous different requirements, many of which are interlinked. For example, integrity is evaluated not only at a pre-sterile baseline but also after distribution & handling and aging studies. Requirements can be linked at different levels to the same test methods. Better definition of user needs helps generate stronger product requirements and test definition.
Possible Requirements:
-
Packaging must comply with ISO 11607
-
Ship Test: Packaging must pass distribution and handling testing per ASTM D4169 or D7368
-
Sterile Barrier Seal Integrity: Packaging must pass integrity of seals tested via visual inspection, per ASTM F1886/F1886M
-
Sterile Barrier Packaging Integrity: Packaging must pass integrity of packaging tested via detecting gross leaks by internal pressurization (Bubble test), per ASTM F2096
-
Pouch Seal Strength: Packaging must have a seal strength of the flexible barrier greater than 1 lbf, when tested per ASTM F88/F88M
If we take one of the user needs, Packaging Must Be Supplied Sterile, we can illustrate how this leads to the Requirements or Design Inputs and how those link through to Design Outputs.
From here we can visualize how the strong requirements lead to clearly defined acceptance criteria for testing. Enabling the test method to be well-defined, clinically relevant, validated, and robust.
Remember The Voice of The Customer
As part of best practices for good design, whether defining user needs, design inputs, or requirements, it is vital to ensure they originate from the voice of the customer and lead to a defined design output.
There are many different voices or viewpoints to consider. Using our example of packaging, there are several perspectives to consider in defining your user needs; it is critical to consider all these viewpoints to create a robust design. Continuing with our example above, we need our product delivered safely and intact. Various stakeholders may prioritize differently:
-
Manufacturer: inexpensive, supply chain, high quality, consistent material
-
Distribution channels: robust packaging, easy to store in larger shipping boxes and pallets
-
Hospital Materials Management/storage locations: easy to stack and store on shelves, easy identification
-
Circulating operating room people: easy to open, easy to present, easy to identify if something is wrong, easy to identify
-
Inside sterile field/scrub/physician: easy to remove from packaging, confidence in sterility, product delivered without damage
-
Patient: sterile, no resulting infection, undamaged product, the correct product used
-
And others
These viewpoints could result in competing or complementary inputs and it is the job of the design engineer to create a product that best meets these inputs. A robust definition of requirements from these numerous inputs helps make a more efficient and focused design process, while allowing flexibility for multiple solutions.
How a Traditional Manual System Falls Short
The design control process is not inherently difficult to implement. The challenge lies in accurate record keeping of the design process, which is particularly difficult with a manual system. When a medical device manufacturer manages their design controls via a manual system, every change in user needs or design requirements must be found, verified,and updated individually throughout the documentation.
In a manual system, a large complex trace table must be painstakingly created and maintained, linking each element and document. However, if one item is updated or deleted, it is easy to quickly have inconsistencies or mistakes due to human error. Relying on tables also leads to viewing design controls as a linear process where one item relates to one other item; however, requirements are interrelated, and the process should be considered multi-dimensional rather than linear.
Better Linkage with an Object-Based Database
When a medical device manufacturer chooses to manage its design controls process within software that uses an object-based database, they achieve better linkages throughout the entire process. In an object-based database, each element (user need, design requirement, etc.) is assigned its own unique identifier that can be used to link it with any other elements within the database. When an element is updated, the unique identifier is utilized to update that element throughout the whole database instantaneously. Additionally, an object-oriented database gives you full visibility into the connections, including any influencing or conflicting elements. This ensures the ability to identify early any conflicts or incomplete requirements.
The Compass® Advantage
Compass supports sharing, linking, and reuse of elements within the project. This capability is one of the core functions in Compass, and customers can create unlimited connections between elements in a project. Linking can be one to many, many to one, or many to many among inputs, outputs, risks, etc. This linkage helps identify incomplete or conflicting requirements that may be missed using a traditional manual system. Trace matrix views help quickly identify missing elements or areas of impact when there are changes to any element. Furthermore, Compass manages unique IDs for all elements at all times. IDs are never lost or altered when items are shared/linked/reused. Alignment and updates are not dependent on a manual process to ensure completeness. Documents can be quickly generated for inclusion in the Design History File in SOP aligned formats. Without a manual process, Compass is able to utilize the database structure to generate complex trace matrices, enabling reviewers to see intricate relationships quickly and easily.
Using our example above, design inputs are defined and organized in Compass and then Compass orders and connects from inputs through output.
Defining Design Inputs in Compass
Connecting Inputs to Outputs in a Simple Trace Matrix
Compass delivers an organized accounting of inputs through outputs, assuring a high quality, compliant product, that end users trust.
