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]

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]

[[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 (broken link removed)

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]

Re: Traceability Matrix format for tracing user needs - Requirements, specifications,

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]

Re: Traceability Matrix format for tracing user needs - Requirements, specifications,

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]

Re: Traceability Matrix format for tracing user needs - Requirements, specifications,

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

 

[Al Rosen]

Re: Traceability Matrix format for tracing user needs - Requirements, specifications,

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

What's the purpose for this to be done for a device that's been on the market for 20 years?

 

[Mark W]

Re: Traceability Matrix format for tracing user needs - Requirements, specifications,

A vendor is retrospectively auditing the validation of software and maybe firmware that is essential for operating the device. It is important to note that the devices were already used by this vendor in a clinical study about 2 years ago.

But, thousands of the devices have been sold and successfully used by lots of other people and organizations.

The client is putting together the available validations/tests for this audit.

Thanks,

Mark W