traceability

Traceability in Medical Device Development

Traces are the glue.

Traces are the links that tie the development documentations together. They provide basis for verifying completeness and consistency.

Traceability, the discipline of setting and managing traces, is a core activity in the medical device development process. Norms and directives such as ISO 13485, ISO 14971, IEC 62304, IEC 62366 and FDA CFR 21 QSR 820 explicitly prescribe it.

Traces in a medical device project

In essence, establishing traces between artefacts is a deceptively straigh-forward task. You just declare the trace and that's it. So why is traceability perceived as such as annoying piece of work?

The main reason is change.

As mentioned above, a trace establishes a relation between dependent artefacts (e.g. a requirement and a specification). When change occurs to one party in this relationship (the requirement), the state of the traced artefact (the specification) may become invalid.

Word documents and Excel sheets are notoriously inept at handling this kind of problem, since the artefacts are not aware of eachother.

Traces in an Excel sheet are just dead text.

On the other hand, this is why traceability software tools such as Aligned Elements are so popular. Traceability softwares tools not only allow traces to be declared, but are also able to track changes made to the traced artefacts.

A change in an artefact automatically highlights the affected traces and signalizes that they might have become invalid due to the change. In Aligned Elements, we call such a possibly invalidated relationship a "suspect trace".

The user now has possibility to inspect the implicated artefacts and update them if needed. Or simply confirm that the the change did not have any impact on traced artefacts. In Aligned Elements, an impact analysis entry is made in the audit trail as the user complets this action, in order to ensure accountability throughout the development process.

However, these gains are quickly lost if different artefact types (e.g. tests and risks) are kept in seperate systems. Managing traces across system boundraies is often only possible by resorting to manual measures. Such as Excel. And then we are back to where we started.

Keeping all traced artefacts in a single system further helps disentageling a range of more mundane problems, such as finding out:

  • If some artefacts have not been traced
  • If some artefacts trace to artefacts of the wrong type
  • If some traces simply don't make sense

Trace consistency

In Aligned Elements, we have implemented traceability support following a few simple guidelines:

  • Usability. It shall be easy to set or remove a trace, regardless of the working context. Therefore we have five different mechanisms for setting traces.
  • Accountability. All trace-related operations shall be recorded chronologically in the audit trail.
  • Transparency. Missing, illegal and suspect traces must be immediatly and automatically highlighted.
  • Completeness. End-to-end traceability must be facilitated without having to cross system boundaries.
  • Reportability. Trace reports shall be customizable and configurable to match the quality requirements and look-and-feel criteria of each customer.

Again, traces are the glue.

Managed correctly with the right ALM support, they are (besides being regulatory necessities) a real asset to your design history file management. The traces help you ensure that completeness and consistency has been achieved throughout your development documentation. We are doing our best to make sure this becomes a smooth journey.

What is lurking in the Design History File? - a manufacturer's perspective

Generating the medical device development documentation making up the products' Design History File, stands for up to 30% of the total development effort. Putting in these substantial resources ought to provide top-notch quality and very few errors in documentation.

Still, Documentation not available, or Documentation not adequate are frequently cited deviations in FDA Warning Letters. The reason for this flood of FDA 483 warning letters, addressing seemingly obvious and simple errors, is not that the medical device manufacturers are ignorant or incompetent.

The documentation requirements are many and detailed, the development projects often spans over a long time-period, involves a large number of alternating team members, all contributing to the large set of deliverables that make up the Design History File / Technical File. The deliverables are highly interdependent and a small change can cause unexpected ripple-effects over large parts of the documentation.

haystack

This combination of large volume, frequent changes and a high level of document interdependencies makes it impossible for any single employee to get a comprehensive view of the current documentation consistency at a particular point in time.

This is where automatic checks by a dedicated computer system really helps out. To illustrate this point, let us share some insights from a medical device manufacturer that ported existing Design Control documentation into our Medical Device ALM Aligned Elements and analyzed it using the automatic consistency checks.

Seeing is believing

"We found inconsistencies in the areas of design control structure, missing and inadequate traces as well as formal aspects of the risk management." says the responsible engineer. "We knew about the problem with the risk management and did not have too much confidence about the traces, but the other inconsistencies were new to us".

Applying the sort of systematic, automated analysis and support a tool can offer, not only unveils gaps in the documentation. It also makes deviations from formal documentation requirements explicit. "In the past, we did not work with a tool and then you have more freedom to find solutions, which in themselves are not wrong per se, but at the same time may be a bit outside of the ideal structure." he continues. "As time goes by, these design control documents are modified and deviates further and further away from the ideal structure."

This is a typical way in which inconsistencies undetectably find their way into the documentation. No up-front errors are committed, but over time, the collected aggregation of minor, grey-zone adaptations undermines the overall documentation coherence. In the end, the consistency of the documentation is unknown and the confidence in the work deteriorates.

"We might have underestimated the benefit of adhering to a clear documentation structure. At the moment, we know that we have structural points to fix. When this is done we can focus on the content. I am confident that, in the end it will be easier to defend the documentation, when the formal aspects are not in question.", concludes the customer.