At the beginning of last year (2014), I posed the above question “Should Requirements Traceability Matrices (RTMs) be formally controlled documents?” on LinkedIn because I wanted to get thoughts from people working in the pharmaceutical industry regarding how they went about it. I thank all those that have taken the time to respond. In essence, while these responses have been varied, they pretty much all agreed on one thing i.e. Requirements Traceability should be carried out.

What is an RTM?

Requirements Traceability Matrix (or more commonly referred to as RTM) is a method used to establish the relationship between documents. Its purpose is to ensure that requirements have not only been traced to the appropriate design elements but also that requirements have been met through test or other means of verification.

What do the regulations say?

FDA (Code of Federal Regulations Title 21) and TGA (PE 009-8 – 15 January 2009) currently do not have any specific regulation around requirements traceability. However, the European Commission (Volume 4 Annex 11 Clause 4.4 (part)) and PIC/S Guide to Good Manufacturing Practice for Medical Products (PE 009-11 1 March 2014 Annex 11 Clause 4.4) do state “User requirements should be traceable throughout the life-cycle.”.

What is industry’s current thinking?

Based on my experience and also from the LinkedIn responses, everyone has their own interpretation of how it should be done. See table below for examples:

None of the approaches are necessarily wrong or right but whichever strategy you choose, it needs to be done in a way that will make it easily manageable and maintained in an up-to-date format by anyone. Otherwise, the time, money and resources invested to get it right at the start is all but wasted if it is left with those who have not necessarily agreed, understood or been taught how to keep it up-to-date especially, when they haven’t been involved during its infancy.What do I think?

What lessons have I learnt?

I’ve been involved with different kinds of RTMs on many varied projects, so here are some of the lessons that I’ve learnt along the way:

By having RTM prepared early, the following benefits will be realized:
- Time saving because if any requirement needs to be updated, it can quickly be determined what test documents need to be updated.
- Minimize unnecessarily testing any requirement more than once.
RTM needs to start as soon as possible, preferably as soon as the URS is approved. Otherwise, the following issues may arise:
- It may get too complicated and challenging to start later on
- If you find that something hasn’t been designed or tested, it will take more time and effort to include them later on.
Either an approved SOP or a plan should be written right at the start to explain how RTM will be documented. Otherwise, there is little chance that one will even be done at all.
If it is complicated to get the first RTM prepared, then it is likely to never be maintained. At the same time, it cannot be so lean and vague that it needs time for someone to analyze whether the requirements have been met. Finding this balance should be based on risk, complexity and novelty of the product.
Without an RTM or even having an RTM that is not technically reviewed, user requirements will most definitely not be met! Thus it’s important to get one prepared and independently technically reviewed.
RTM does not necessarily need to be in the form of a stand-alone document. If the project is small enough and there are only a handful of documents requiring traceability, it is acceptable to have requirements traceability within the documents themselves. For example, a Functional/Design/Configuration Specification can have sections or columns which state which specific user requirement is being met. The test documents can also be divided into sections that state at the start which requirements are being verified.
Responsibility for maintaining the RTM should lie with the Subject Matter Expert (SME) who not only has an in-depth technical knowledge of all documents listed in the RTM but is also informed when the traceable documents have been updated so as to ensure that the RTM is updated where necessary.
The RTM should be aligned with the URS and other associated documentation.

What guidance documents are out there?

For specific guidance on requirements traceability, the following documents provide a good starting point:

Is QA formal approval required?

As for obtaining QA approval via a formal QA signature on the RTM, you need to ask yourself what the intent of such signature is and how you are treating this document. If it’s a document that is going to be managed internally by SMEs (and not provided in a regulatory inspection) and anyone can use it as a guide to confirm traceability to a requirement, then I would say no. If the RTM will become part of the site’s Quality Management System (QMS), and elements of the RTM have a potential impact on GMP processes and systems, obtaining QA approval should be considered. Note that the European Commission Code of GMP mentioned above only says that user requirements should be traceable so how that is done is up to the regulated companies.

My Final Words on RTM?

In conclusion, I believe as long as you have an SOP or documented plan that states how you do it and you follow it, regulatory inspectors are unlikely to have any issues with that approach. In the end, regulators want confidence that you are in control of your process and if you can easily and quickly show where any requirements have been designed in and tested (in other words, traceability), what more can they ask? In the end, it’s a tool used to assist regulated companies in making sure they get what they ask for.