V&V deep dive Part 2: Traceability
Two words: "Prove it"
In Part 1 of this series we established the meaning of the concepts of verification and validation. In Part 2, we’ll explore a related concept that is central to medical device design controls: traceability.
Background in standards and regulations
Although traceability is seen in the industry as one of the most important elements of an effective design control system, medical device standards and regulations say surprisingly little about it. ISO 13485 only mentions it once, in Clause 7.3.2:
During design and development planning, the organization shall document the methods to ensure traceability of design and development outputs to design and development inputs.
The rest of the standard’s references to traceability, such as in Clause 7.5.9, are related to a different kind of traceability, the traceability of particular devices and their components through the supply chain. This is unrelated to the concept of traceability of design inputs to design outputs mentioned in Clause 7.3.2.
Likewise, US FDA quality system regulation 21 CFR 820 does not mention design controls traceability at all, only containing requirements related to traceability of product in the supply chain in subpart 820.65. Design controls traceability is only mentioned in a guidance document, Design Control Guidance for Medical Device Manufacturers, where a traceability matrix is briefly mentioned as a method of documenting verification activities. Similarly, EU MDR 2017/745 only mentions traceability in the context of the supply chain or calibration.
ISO 14971 addresses traceability in the context of risk management in Clause 4.5:
In addition to the requirements of other clauses of this document, the risk management file shall provide traceability for each identified hazard to the implementation and verification of the risk control measures.
Finally, for software products, IEC 62304 mentions it in Clause 5.1.1:
The (software development) plan shall address the following: TRACEABILITY between SYSTEM requirements, software requirements, SOFTWARE SYSTEM test, and RISK CONTROL measures implemented in software.
Defining design controls traceability
As you can see, the standards offer us only very small glimpses into design controls traceability. ISO 13485 requires us to trace design inputs to design outputs. ISO 14971 requires us to trace hazards to risk control measures. IEC 62304 is the most comprehensive, requiring tracing between requirements, tests, and risk control measures. Due to the brevity and vagueness of the clauses, I’ll offer the following practical definition of traceability that also takes into account industry practices and auditor expectations that I have observed:
Design controls traceability is the documentation of the link between each high-level design input (including risk control measures), technical requirement, design output, verification test, and validation test.
The concept behind this definition is that medical device design controls have a flow to them, and it is the job of traceability to document that flow. Before design begins, high-level design inputs are identified. During initial concept creation, these inputs can be translated into more detailed technical requirements that reflect the technology proposed for use. After the initial designs are completed, design outputs can be linked to each requirement to show where it was fulfilled. Then verification and validation tests can be written and executed for each requirement.
We can delve further into the concept of design controls traceability by looking at methods for documenting it.
Traceability methods
There are many methods available to demonstrate traceability. If you have each of the design control elements in separate documents, you can assign a unique tag to each, and place that tag next to the associated elements in other documents. However, I’ve found this method to be cumbersome and mistake-prone. To reduce documentation, centralize information, and make demonstration of traceability clearer during audits, I would recommend using the traceability matrix method:
There are many ways to organize a traceability matrix, but I’ve included a simple version above continuing with the made-up example of a syringe from Part 1 of this series. There are a few things to note in the example above:
I’ve included a variety of types of design inputs in the example. The first two rows have requirements related to the intended use of the device. Notice that these two have validation methods specified, but the other design inputs do not have validation methods.
Row 3 shows a design input from the product’s safety risk analysis. Presumably a risk was identified where the healthcare provider assumes the wrong unit of measurement when reading the syringe scale, which could lead to the delivery of an incorrect volume of medication and patient harm. ISO 14971 requires this risk to be mitigated “as-far-as-possible”, so all design-related risks should prompt the inclusion of design requirements as a risk control, if possible. In this case, the new design requirement to mitigate the risk is to print the unit of measurement on the scale. Notice that the “Design input source” column references the specific ID for the risk, so that traceability is maintained between the risk in the FMEA and the risk control in this requirement specification.
Rows 4 and 5 show examples of other kinds of design inputs, one a marketing requirement and one a regulatory labelling requirement.
In the example above, there is a 1:1 link between each high-level design input and its corresponding technical requirement. However, in practice, one high-level design input could be fulfilled via multiple technical requirements, or one technical requirement could be fulfilling multiple high-level design inputs. This all depends on the organization and level of detail of your requirements, so don’t be afraid to design the traceability in the way that makes the most sense to you. If using Excel, merging cells is a good way to show a 1:2 relationship. Otherwise, there are “requirements management” software products out there that might handle this situation in a more graceful way. Personally I prefer to keep it lightweight and cheap, so I generally use Excel.
In this example I included the test methods directly in the cells in the verification and validation method columns. Many products are complex and require large and complex test protocols. In this case you can simply reference the name and revision of the separate test protocol in these columns instead of writing the steps directly into the cells.
Notice the test results column. You want to trace to the test results, not just the methods. Auditors will want to see whether each test passed and the related documentation showing evidence.
Again, the above is just a simplified example. There are many different ways of organizing and naming the columns, so make it work for your product and don’t get too stuck on doing it a certain way. As long as all the elements are traced, auditors will generally be open-minded about the exact method and format chosen.
The purpose of traceability
Since the standards don’t really get into it, I think it’s important to address what the intent is behind design controls traceability and what value it brings to product quality.
Documented traceability shows evidence for regulatory bodies that you have followed the design control requirements for each phase of development. In covering design controls, auditors cannot just evaluate each element in isolation; they need to see that you are threading the needle all the way through. If you can demonstrate that each design input was translated into a technical specification, implemented in an output, and tested in the appropriate manner, you have covered 90% of design control requirements from the standards.
More importantly, traceability is an essential quality tool internally. Tracing the design inputs creates an important historical record of why the product was designed in a certain way, and safeguards essential requirements from accidental changes. For example, let’s say the design requirement to print the unit of measurement on the syringe scale was never traced to its source in the safety risk analysis. Let’s also say that a newer product manager wants to make a change to the syringe that would require the removal of the milliliter unit mark, and there’s no one around from the original project team to object. Without the traceability to the specific hazard in the safety risk analysis, the product manager might feel comfortable removing the milliliter unit mark from the syringe body, unaware that it is mitigating a safety risk. With the traceability, the historical reasoning behind the requirement is available and a potentially dangerous change can be avoided.
The traceability matrix has further utility for root cause analyses. If there is a product quality issue related to the design, the matrix provides an centralized location to see exactly when and how the relevant requirements were tested, and links to the test results and evidence.
In summation, don’t think of design controls traceability as purely an artifact of regulatory requirements. If done effectively, traceability documentation can be a really useful tool for those in charge of a product’s design and quality.
See the other parts of this V&V series:
