ISO 13485: Software Tool Validation

In a previous blog, we had a look at challenges and pitfalls relating to ISO 13485. One of the challenges manufacturers of medical devices encounter in their daily work, and a favourite topic for auditors, is the software tool validation as required by ISO 13485 in the chapters 4.1.6, 7.5.6 and 7.6. This blog takes a closer look at software tool validation and describes possible solutions to prove the suitability of software tools.

It’s all about the risk

ISO 13485 requires adjusting the rigor of the software tool validation to the risks associated with the software tool. Therefore, it is legitimate to have different validation approaches for different types of software, depending on their intended purpose. The validation of COTS (commercial of the shelf) software may require less effort than validation of MOTS (modifiable of the shelf) software or a self-written software.

The software validation activities should start with an overview list of all used software tools and a short description of the intended purpose. Risks that, in the event of a software tool failure, could lead to a product failure should also be included or referenced in this overview. These risks are the basis for the decision whether or not validation is required.

Based on criteria for validation defined in a SOP (standard operating procedure) or validation policy, the decision if a validation of the software tool is necessary, is documented in this overview list.

Establish criteria for validation and re-validation

Validation is only required if a malfunction of the tool can contribute to a risk for patients, users and third parties when using the manufactured medical device. To enable tool owners to make a decision about validation, criteria must be defined in the quality management system.

ISO 13485 itself provides the first indication of which criteria are eligible. The standard requires validation of software tools that influence product quality (e.g., version management systems, tools for continuous integration), that measure and monitor the manufacture of medical devices (e.g., unit test tools, static code analysis tools) and that are used within the quality management system (e.g., ticket system for error management, software used for document and record control). Further criteria can be found in the ISO TR 80002-2, but these criteria basically do not go beyond the requirements of ISO 13485.

When establishing the criteria for validation, also the criteria for re-validation should be documented. Revalidation is necessary if the intended use changes or additional requirements for application are added. An update that only fixes existing bugs or improves performance does not require re-validation. In any case, the responsibilities for revalidation must be defined to ensure that re- validation is done when necessary.

Define requirements

To be able to carry out a validation, requirements for the software tool are needed. In the best case, these requirements are defined before the tool is purchased. In practice, the requirements are often only created after the purchase and adapted to the tool. The requirements should have the same properties as any other product requirement and should be specific, measurable, attainable, realistic, and traceable.

The requirements for the software tool should focus not only on functionality, but also on meta data of the software tools, such as the time of availability of the tool, the user base and community or the frequency of updates and patches. The position of the manufacturer in the market (reliability) and the availability of support should also be considered.

Requirements management is an integral part of most of our training courses. If you want to learn more about the requirements, visit our training course website.