Software in Medical Devices, by MD101 Consulting

Why validating?

First point of view, quality-oriented: the purpose of workflow and data management tools for software development is close to document management tools. Both are designed to record information, which is evidence of application of QMS provisions:

• Document management tools for all document and records,
• Software development workflow tools for artifacts produced during software lifecycle activities.

Another point of view, more technical: workflow and data management tools for software development are connected to software configuration management (SCM) tools:

• SCM tools need to be validated, if your SCM tool doesn't work, you could generate a wrong version, and put patients at risk,
• Workflow tools need to be validated, if it doesn't work, you could miss a design review, place a version not validated on the market, and and put patients at risk.

When validating

The probability of such risks is in most cases very low, thus the effort of validation should be proportionate to these risks.
Depending on your context, you could even conclude that the validation is not mandatory. For example:

• If design reviews are managed outside the tool,
• If the software documentation is extracted from the tool in PDF files, which are formally reviewed,
• If the tool is only used to manage developers daily tasks, without formal link to software documentation.

Anyway, the rationale to validate or not, and the effort of validation shall be recorded in a document (see below risk assessment).

How validating

Software workflow management tools are off-the-shelf tools but highly configurable.
The validation can be managed in four steps:

• The definition of your requirements,
• The risk assessment on your software development process,
• The qualification of the tool vendor,
• The qualification of the tool itself configured for your needs.

Requirements

First and for all, the user requirements shall guide the validation process.
The best way to do it is to write a statement of work or a software requirement specification document containing the user needs. Such document should be written by software team in collaboration with quality team. It should also be based on your software development process.

Risk assessment

Once you've described the requirements, you can do a risk analysis on the software tool and its environment. For example:

• Risk of software failure of the tool,
• Risk of insufficient training of users,
• Risk of failure of the vendor.

If all identified risks are deemed acceptable you could stop here the validation process. Otherwise you continue the process.

Qualification of the vendor

Applying a purchase procedure is probably the most straightforward solution. However the general procedure could lack specific selection and evaluation criteria for that kind of supplier. You can define criteria on:

• Software tools functions, based on the software requirements,
• Tool vendor capabilities to ensure support on the tool when installing, configuring and maintaining the tool.

Your purchase department will add criteria on vendor pricing policy :-) If there is only one tool matching your needs (Jira is Jira, you know what I mean) then it's not necessary to spend too much time on the vendor selection.

IQ/OQ/PQ

When you have selected the tool and its vendor, it is time to qualify the tool itself.
A very classical IQ/OQ/PQ process is the best way to organize the qualification process. This is not the way it is presented in AAMI TIR 36 (see previous article) but auditors or inspectors are used to see such qualification steps.
For software, all these steps can be gathered in a single software test plan, with:

• Installation Qualification: tests by inspection that the tool is correctly installed and personnel is trained,
• Operational Qualification: tests cases on tools functions, with traceability between test cases and the statement of work,
• Performance Qualification: a kind of beta test phase, when software is used during one/two months/years (choose your period).

When revalidating

The characteristic of such software is its perpetual enhancement to match new user needs. The tool is subject to changes of configuration, minor or major, to adapt the workflow to the real software development process.
You will need to assess the impact of every change of configuration of the workflows implemented in the tool. It may be wise to wait a bit to have a minimum set of changes to implement. Validation of changes can be expensive, with a possible update to all records of validation.

Conclusion

Validating tools for the management of software development workflow is not rocket science. It's based on a risk assessment on the process where this tool is used, a good set of requirements, including non-software requirements, and a test plan to verify these requirements in the deployed software version.



If you don't want to start from a white page, see the QMS software validation templates in the Template Repository for software: Software Validation Plan, Software Validation Protocol and Software Validation Report.