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

Are you essentially looking for something to track customer requirements?

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.

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

[[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 :tg:

What I have looks something like this...

[[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 :tg:

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 (http://www.fda.gov/cdrh/comp/designgd.html)
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?

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

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!:bigwave:

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

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

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.

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

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

consider this;

1. organizing & evaluating the "existing data-points/references" is certainly key step in retrospective validations but essentially not the end of it. One aspect still remains, i.e to establish the existing controls/procedures to be adequate[ not just interms of QC but interms of design-controls/QA as well];

2. now to do that, traceability matrix would help us map the requirements against the existing data/references and the design-controls; and as well as identifying the gaps if any!

3. give the facts and as you have indicated, the product must be in market without any problems; and the above exercise may not throw up any additional surprises, yet its worthwhile to have comprehensive approach, cause this will form the foundation/basis for the future life cycle of the product/process.!

:nope:i hope i did not state the obvious.:bonk:

Reply to Al Rosen,

My apologies if I didn't answer your question in a more timely manner.

The client recently had a vendor audit that essentially was a retrospective audit for the auditor's client. Interestingly, the audit should have happened last year before my client got the project.

As it turned out, the issue of actually doing the retrospective validation was only a small facet of the audit, which as it turned out involved other issues related to an end user-related qualification of certain aspects of the firmware and software for the device.

So, to answer your question, the need wasn't for a retrospective validation, although that could still be needed. The need related to processes and procedures for certain aspects of validation as well as operational and installation qualification of firmware and software.

Reply to v9991,

Thank you for your input. In the validation report, this kind of information is valuable.

Regards to all.

Mark W