The importance of traceability from the perspective of designing a medical device software

When designing a new product for the regulated environment, each manufacturer meets the challenge to provide compliance with multiple standards and regulations to achieve the certification required to release a product on the market. Therefore, he needs to ensure notified body that the device is safe and works as intended. Experience suggests that well-prepared documentation during the design process is a key factor in achieving this goal.

In the process of designing the product, some documentation path that leads from input parameters to specific design decisions at each sub-stage should be created. This kind of process is nothing more like the basis for maintaining product traceability.

When learning about any design process, you may hear about traceability and its importance in Quality Management System (QMS). This article describes the use of this term in one of the most regulated environments – medical device software design.

Traceability in general

There are plenty of definitions of traceability in literature. The one that accurately captures its meaning is:

Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction (i.e., from its origins through its development and specification to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases) [1]

In other words, in the term ‘Traceability’ two simple words are hidden – “trace” and “ability”. This combination may mean the product’s ability to trace the history of the requirements specified for that product.

Traceability in the medical device domain

The main standard that specifically addresses the requirements for the traceability of medical devices is ISO 13485. In the product realization chapter, the following can be found:

The organization shall document procedures for traceability. These procedures shall define the extent of traceability in accordance with applicable regulatory requirements and the records to be maintained [2]

Traceability shall accompany the main stages of medical device realization, especially including the product implementation plan or design and development plan. However, it is worth mentioning that ISO 13485 does not describe the specific methods or technologies to be used, but defines general requirements for traceability. The way a medical device is tracked may vary depending on many factors, like the type of device, intended use, or regulatory jurisdiction.

Standards, guidelines, and regulations

In addition to ISO 13485, other standards, guidelines, and regulations, for example:

• ISO 14971,
• U.S. Food and Drug Administration’s (FDA) guidance “General Principles of Software Validation
• European Medical Device Regulation (MDR),

also address traceability within broader medical device requirements. It would be difficult to include them all in one article.

Generally speaking, to comply with traceability requirements and recommendations, the manufacturer has to address applicable standards and regulations specific to the region and type of device produced.

The IEC 62304 standard, which has already been blogged about, defines the medical device software life cycle process. Traceability in the context of this standard is the heart of our case. The IEC 62304 sets out the requirements for the development and maintenance of medical device software. The development part consists of some stages, further described in Fig. 1 (the software is named “SW”). In conjunction with other standards, in particular ISO 13485 and ISO 14971, it addresses the issues of safety and effectiveness.

The role of traceability

The role of traceability in this standard is explained as a:

degree to which a relationship can be established between two or more products of the development PROCESS,

and begins in chapter 5 of this standard called Software Development Process. Its steps 5.1 to 5.8 are shown in the diagram below:

Table 1 presents areas where Traceability is pointed out as required (“shall” narration) or recommended (“can“narration). Traceability Context Description specifies what path is to be traced in the prism of Traceability for the specific step of the process.

V-model

The role of traceability in the software life-cycle process can be described using the V-model illustrated in Fig. 2. Traceability always accompanies the verification of requirements defined at individual stages of the process. The green area of the figure represents IEC 62304 scope.

Where does V-model come from and what does it show? IEC 60601-1 standard is the source. It describes Programmable Electrical Medical System (PEMS) development and is related to the software life-cycle process.

Within the green area in Fig. 2, the IEC 62304 requirements apply to IEC 60601-1 at the PEMS component level. From the point of specifying software requirements to software integration, the software system is being established. Going forward, the software system belongs to the programmable electrical subsystem (PESS) that is a part of PEMS.

A little bit of practice

How to move forward from being aware of tracking every step of the design inputs and outputs that define the product to creating a traceability analysis for a medical equipment software system? It is worth starting by collecting traceability deliverables.

These can be:

• Stakeholder Requirements – they describe what the system will do for the specific environment from the stakeholder’s (patients, physicians, service, employers, business owners etc.) point of view and refer to the origin of the requirements, e.g., overview of similar products, service feedback, intended use or actual input from users (user needs/marketing input).
• System Requirements – define the system’s features, attributes, functional and performance requirements in a measurable way to satisfy stakeholder requirements, regulatory requirements, and risk analysis (RCMs), its input may also come from e.g., already established requirements from similar products or usability studies.
• Subsystem Requirements – if the system is divided into subsystems, they refer to system requirements, system architecture, risk analysis, and other sources, e.g., usability studies; can be called system requirements for a specific subsystem.

Based on these inputs, a path of requirements from stakeholders to the component level is formed via traceability.

The next step is to decide how many levels we want to maintain in one traceability analysis. That is, whether we prefer to represent a full range of this path in one document or divide it into several records. There are no specific requirements or restrictions on how much we should include in one document. The penultimate aspect is – in what form we want to present traceability. The most common is a traceability matrix. Putting this into exemplary practice, a sample matrix pattern for subsystem-level requirements is presented below:

Finally, it must be confirmed that the outputs meet specified requirements through V&V activities (Verification and Validation). All requirements must be covered by verification and/or validation, the results of which are fed into the traceability matrix.

Example below (SRS – Software Requirement Specification, SR – System Requirement, STP – System Test Protocol, STR – System Test Report, Ver – Verification, Val – Validation):

The solution above should be considered only as an example. Its structure and content may vary depending on the type and individual needs of the project. e.g., it could be reasonable to omit the validation step altogether.

What makes it so important?

Tracking the list of requirements in a compiled form can show us yet undiscovered missing or incomplete requirements. Moreover, it can highlight whether all requirements have been sufficiently verified.

Traceability can also be helpful in making decisions during product development. You could assess the impact of requirements on the product’s design. And in case of any change of requirements, you will be able to analyze its influence on the entire development process.

Traceability proves valuable in project management as it provides a clear measure of progress. By associating requirements with tests, it helps to control the scope and realistically approach the fulfillment of these requirements, taking into account the available time frames.

Finally, all of the above comes down to ensuring high quality and safety.

Practically most of the activities and tasks within the software development process are aimed at:

• reducing the risk that the use of the software may potentially lead to,
• improving and maintaining the quality of the software.

It should be noted that in IEC 62304, risk and quality management are constant companions throughout the whole lifecycle model (Fig. 1 and Fig. 2).

In all, traceability appears as a tool that:

• can control that risk, by tracing RCMs to the software requirements, software requirements to the software system, completing this chain in unit and integration tests,
• is the guardian of quality control in the face of product growth, ensuring that the quality requirements of the system are met via the V&V phase, documenting proper implementation and the extent to which test cases test these requirements.

Summary

Demonstrating a product’s safety and effectiveness is the bottom line to achieving conformance to specific regulations or standards. Handing well traced documents to notification’s body, product certification is almost at your fingertips.

Just as there is no clear development path for each medical device, it is difficult to find a single solution for determining its traceability. Readers who have similar thoughts and feel lost in the fog are welcome to contact us. A team of experienced Sii engineers supports not only the creation of this type of documentation but also testing, certification, and more.

***

[1] O.C.Z. Gotel, C.W. Finkelstein, An analysis of the requirements traceability problem, in: Requirements Engineering, 1994., Proceedings of the First International Conference on Requirements Engineering, 1994, pp. 94-101

[2] ISO 13485:2016 – Medical devices — Quality management systems — Requirements for regulatory purposes