Traceability Matrix format for tracing user needs - Requirements, specifications, etc

[DaveDavis]

Hi all,

I was wondering is anyone had a good traceability matrix format for tracing user needs - requirements - specifications - testing - risks. This is for a hardware/software medical device. I am going to speak with some of my co-workers in Japan next week and I know they are very weak on this topic so I thought a good example would help. Thanks in advance.

Dave

[Marc]

Are you essentially looking for something to track customer requirements?

[Al Rosen]

Originally Posted by DaveDavis

Hi all,

I was wondering is anyone had a good traceability matrix format for tracing user needs - requirements - specifications - testing - risks. This is for a hardware/software medical device. I am going to speak with some of my co-workers in Japan next week and I know they are very weak on this topic so I thought a good example would help. Thanks in advance.

Dave

I haven't heard of a "traceability matrix". What requirement is this for?

[DaveDavis]

[[I haven't heard of a "traceability matrix". What requirement is this for?]]

Well, the FDA describes the traceability matrix as, "A Traceability Analysis links together your product design requirements, design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations...", "...The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations."

It is required by 21CFR Part 820, subpart C -- Design Controls. It is required for manufacturers in the medical device industry. The trace matrix is part of your design controls process and is used in a product submission to FDA.

I was looking for some examples of how people in industry (device or pharmy) have imlpemented such a matrix. I know that I created one that I believe satisfies the requirements and *should be* typical.. but needed to bounce that off some of the experts in this forum

What I have looks something like this...

[Al Rosen]

Originally Posted by DaveDavis

[[I haven't heard of a "traceability matrix". What requirement is this for?]]

Well, the FDA describes the traceability matrix as, "A Traceability Analysis links together your product design requirements, design specifications, and testing requirements. It also provides a means of tying together identified hazards with the implementation and testing of the mitigations...", "...The Traceability Analysis commonly consists of a matrix with line items for requirements, specifications and tests, and pointers to hazard mitigations."

It is required by 21CFR Part 820, subpart C -- Design Controls. It is required for manufacturers in the medical device industry. The trace matrix is part of your design controls process and is used in a product submission to FDA.

I was looking for some examples of how people in industry (device or pharmy) have imlpemented such a matrix. I know that I created one that I believe satisfies the requirements and *should be* typical.. but needed to bounce that off some of the experts in this forum

What I have looks something like this...

I found the reference to the traceability matrix in the FDA Design Control Guidance For Medical Device Manufacturers

DOCUMENTATION OF VERIFICATION ACTIVITIES. Some verification methods result in a document by their nature. For example, a failure modes and effects analysis produces a table listing each system component, its postulated failure modes, and the effect of such failures on system operation.

Another self-documenting verification method is the traceability matrix. This method is particularly useful when the design input and output are both documents; it also has great utility in software development. In the most common form of the traceability matrix, the input requirements are enumerated in a table, and references are provided to each section in the output documents (or software modules) which address or satisfy each input requirement. The matrix can also be constructed "backwards," listing each feature in the design output and tracing which input requirement bears on that feature. This reverse approach is especially useful for detecting hidden assumptions. Hidden assumptions are dangerous because they often lead to overdesign, adding unnecessary cost and complexity to the design. In other cases, hidden assumptions turn out to be undocumented design input requirements which, once exposed, can be properly tracked and verified.

However, many verification activities are simply some sort of structured assessment of the design output relative to the design input. When this is the case, manufacturers may document completion of verification activities by linking these activities with the signoff procedures for documents. This may be accomplished by establishing a procedure whereby each design output document must be verified and signed by designated persons. The presence of the reviewers' signatures on the document signifies that the design output has been verified in accordance with the signoff procedure.

I am familiar with the second method described, review of the output document and signoff. Although design verification is a requirement, the method is left to the device manufacturer. Perhaps there are others here who wish to comment?

[Brae164]

I worked for Boston Scientific for many years. We used an Input/Output matrix. It was similar to the one you have uploaded. However we did have additional columns that you do not have.

Source of Input
Summary of the Results
Ongoing Controls (ie, inspection procedures, drawings)
Output

[BradM]

Originally Posted by Brae164

I worked for Boston Scientific for many years. We used an Input/Output matrix. It was similar to the one you have uploaded. However we did have additional columns that you do not have.

Source of Input
Summary of the Results
Ongoing Controls (ie, inspection procedures, drawings)
Output

Hello there! Welcome the Cove!

Thank you for your input, and we look forward to seeing more posts from you.

[Mark W]

Thank you for reminding me of the FDA link to the reference for the traceability matrix and what it is actually used for.

Here's the twist: I have a client that designed and has sold a registered device since before the FDA guidance waS published and it's performance has been demonstrated for over 20 years by the thousands of devices that have been sold.

My question: How can one RETROSPECTIVELY generate a traceability matrix for such a device?

And a related question: How can one RETROSPECTIVELY validate such a device?

Many thanks in advance for your help.

Mark