Newsletter Summer 2019 - Bill Hoover, Issues with Product Development Traceability

Issues with Product Development Traceability  

Bill Hoover 

Medical Device and Quality Consultant  

What is traceability? 

A key element of product development is the concept of “traceability.” Traceability is part of FDA’s guidance for the Quality System Regulations and Design Controls.The FDA has described it as “Traceability among requirements, specifications, identified hazards and mitigations, and verification and validation testing.The Agency’s guidance documents also describe traceability information to be in the form of a matrix or a table. This very general guidance can be interpreted in many different ways by individual companies. 

Although traceability appears to be a straightforward concept to implement, it can become a developmental roadblockfor companies that do not use this valuable tool properly and with care. Here are some examples ofissues that have been encountered: 

1.Viewingtraceability as a “checklist” item for submission 

Company X viewed traceability as a standalone process to create a document for its 510(k) submission. The company did not start the traceability process until the submission wasbeing assembled by the regulatory group. The entire product development team needed tobe devoted to reverse engineer and document the traceability. As a result, the FDA submission was delayed by several months. 

Traceability should be a parallel, interactive part of the development process. The value of traceability is greatly diminished if it is performed after development.In order to avoid this pitfall, the type and timing of traceability need to be clearly defined in a company’s product development process. 

2.Traceability touser orcustomer requirements 

In another scenario, a product development team spent many weeks tracing customer requirements to system and subsystem requirements. Unfortunately, this involved creating imaginary customer requirements for itemssuch as electrical safety requirements required by regulatory agencies or for a proprietary reagent manufacturing process. These imaginary customer requirements were frequently repetitive with the system and subsystem requirements or did not have a logical source. 

There is a common misunderstanding in industry that all requirements must trace back to a user or customer requirement or need. In reality, requirements originate from where they are introduced in the development process. These may be business requirements, regulatory requirements, risk mitigation requirements(developed as part of the product’s risk management process), or requirementsthat meet a manufacturing need. These requirements do not necessarily trace back to customer or user requirements.  

The level or document used for introducing a requirement needs to be logical and appropriate. Additionally, the source and reasoning for the requirement need to be documented. The control and processing of these requirements need to be defined in a company’s requirements-management process. 

3. Very large traceability tables 

In a third scenario, a product development team spent countless hours creating a single traceability table in Microsoft Excel that related approximately 30 documents as columns and the traced items from each document as rows. As a result, the table contained over 20 thousand rows! Because the table was so large, only item numbers could be listed in each cell; normally, the full text of the items being related is used in traceability tables for ease of understanding. In this case, however, a copy of each of the 30 documents was needed to determine what was being linked in the table.The item number in each document had to be looked up to read the associated text. This extra effort counteracted the usefulness of the traceability document and could have inhibited efficient FDA review.  

Unfortunately,this is a commonoccurrence,largely due to how FDA guidance documents describe traceability. FDA’s statement of Traceability among requirements, specifications, identified hazards and mitigations, and verification and validation testing” can be interpreted as the submission of a single document. Furthermore, FDA’sprovided examples donot accurately reflect the actual number of documents produced in product development processes. 

Traceability is an extremely valuable tool, but it needs to be defined so that it adds to the process, not create massive documentation obstacles. All traceability does not need to be accomplished in a single table; traceability may be documented in a manner that provides the most value at the time. Some examples could be as follows: 

  • Traceability between requirements and between the lowest-level input requirements to the design documentation are key needs. 

  • The project’s risk management process should require traceability between the identified risks, the risk mitigation requirements, and the validation of the effectiveness of the mitigations.  

  • Tracing the lowest-level input requirements to their respective verification is another key need. 

A company’s product development stndard operating procedures (SOPs) need to define when and how such traceability tables will be documented and how they are used to provide the appropriate feedback to the development team. These procedures should include how software-based traceability tools are used in the development process. 

These tables are also submitted as required to regulatory agencies – the benefit is that the regulatory agencies will have an easier time following the documentation, helping to shorten the approval timeframe. 


When creating or re-engineering processes and SOPs, it is not enough to be in compliance. The process also needs to be as efficient as possible to save time, minimize required resources, produce outstanding products, and more. The experts at Kinexum can support your efforts with their depth of knowledge and experiences with multiple development projects, helping you achievecompliance and effectiveness together.