Traceability Matrix
In 2019, we wrote a blog post about the different aspects of traceability and why it's important to invest time in building proper traceability throughout your documentation.
In this post we'll zoom in a bit more on traceability in the design phase of a medical device. As you may have experienced, the design phase presents unique challenges to maintaining traceability.
Looking at the well-known V-model, it seems pretty simple: User needs are translated into design input, which is then converted into a design output which is tested. You trace all user needs via design input to your design output and matching tests. How hard can it be?
Well... Hard enough, I would say!
For example in software development, agile principles are often applied. They don't follow the classical V-model, but go through many shorter sprints. How do you manage traceability in that setup? Is it even possible?
Moving fast through development cycles creates specific challenges when it comes to maintaining traceability and documentation. Sometimes, the added value of a trace matrix is questioned in teams applying agile development principles.
However, In the medical device field, providing proof of your traceability fits into the general requirement of controlling your processes, including your design process. It's mandatory to show that you are in control of your whole design process, from start to end. A traceability matrix is a way to demonstrate the overall view of how everything is interconnected. It also allows the ones reviewing your medical device file to evaluate (or at least have an idea about) whether you have connected all dots.
We've found that proof of traceability is most easily maintained if you keep 4 things in mind:
Clear identification
Version control and change control
Centralized information
Simplicity in tools
Clear Identification
Every single item in your design should have a unique identification, regardless of whether it is a requirement, a test, an executed test. For one thing, it helps communication and collaboration within the team. By speaking in a uniform language of clearly defined terms, the team will make more efficient progress. Contradictions in your design can hide when terms are fuzzy and still open to interpretation. Worse, these contradictions will propagate out through your matrix of interconnections if any one definition is unclear.
Also, remember that an external person will look at your documentation and needs to find his/her way in it. Clear identification within the design documentation is key for that as well.
Version Control and Change Control
Tracking changes in a clear and transparent way keeps your trace matrix always up to date. Which test was executed on which version? What changed after our risk analysis and how does that reflect into other parts of the design? Version control allows the answers to those questions to be encoded in queries rather than laboriously recorded by hand.
If you don't know the status of all items in your design, it's difficult to keep track of changes and making sure your trace matrix is up-to-date becomes .... well, impossible.
Centralised Information
We all might have our own way of documenting our design. But one thing that helps is to have the information centralised. If information is spread over zillions of different documents or several different tools, the chance of making a mistake or missing information increase rapidly.
Remember that when information is spread over many different documents or tools, you've got to maintain traceability between the different ways and locations you store that information. It's very easy for a sub-team to adopt a tool or method of information storage which becomes "invisible" to the trace matrix. Check regularly to make sure any new information sources are incorporated into the matrix.
Simplicity in Tools
It is true that limiting the amount of tools used in the documentation of your design might benefit the overall efficiency. Either "one tool to rule them all" or a profound integration between different tools is a good approach. This also fits into a risk-based approach in the sense that it reduces the risk of forgetting or missing information.
If all design related information is centralised into one database, it becomes much easier to extract the proper documentation, including trace matrices, from it.
In conclusion, the ultimate goal of a trace matrix is to build trust and transparency within your design. It's a tool that shows you control the process. This is beneficial for the team that is working on that design, but also for the reviewers that need to evaluate your compliance based on your documentation.
And what happens if the team doesn't trust the trace matrix, the tools used or the definitions of terms? They may begin to "work around" whatever tools are there. While their decisions in the moment may be correct regarding one of the many problems they face, the traceability of the decision has been lost, and that can be a showstopper in the endgame.
In case you want to discover how we can help you build traceability within your design, don't hesitate to contact us!