Should you Validate Tools and Processes when Developing Medical Device Software?

The past few years I’ve worked for a Medical device manufacturer, Quidel Corporation. The overall company creates diagnostic tests for things like Flu, RSV and other infectious diseases including COVID-19.

It’s an exciting place to be in terms of the war on Coronavirus. Quidel was the first to develop and receive FDA approval for a rapid SARS Coronavirus (COVID-19) Antigen test. And by the looks of it the test is in high demand.

Those rapid tests run on Sofia 2 and Sofia devices. Which require software to run the tests.

The hardware and software on those medical devices are required by the FDA to have design controls - meaning the requirements driving the hardware and software need to be what we call “Verified” and “Validated” (or V&V-ed). And the process needs to be documented.

The thinking is when requirements are verified and validated (and you show you documented your work) there is a higher assurance the end product delivers the consistent, intended results and won’t result in patient harm.

Verification means showing your requirements have been met. In other words, you built it “right”.

Validation means showing your requirements meet intended use. In other words, you’ve build the “right” thing meeting user needs and you have high assurance what you’ve built provides reliable, intended results.

V&V can be a time intensive process to complete and the documentation alone is significant work.

So, being in the Medical Device industry should you also validate the tools and processes used to develop your end product?

I’ve worked with a few folks in software Verification and Validation.

Some will tell you:

You need to validate everything!

and then you go: huh? Wait, what? I have to validate Microsoft Windows? Word? Excel too? What about my SDLC tool (Azure DevOps, Jira, etc.) I use for managing and printing my requirements and test cases - I need to validate that too?

No. You don’t.

You validate a process or tool when the output can’t be verified. That’s what our friends at the FDA say.

Where the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated

Let me say it differently.

You need to validate your end-product meets requirements and meets intended use. But when using tools and processes to build your end-product you only need to validate those if you can’t reliably verify (e.g. inspect or test) their results.

Verification can mean you manually review a printed document generated by some process or tool and wet sign with a pen (maybe you printed requirement test cases using Word or Excel on Microsoft Windows).

So, in that case you don’t need to validate the process or tool which generated the document. You don’t validate Windows, Word or Excel. Or any tool used to generated the result (the document). You’ve been able to “inspect” or “test” the document as your verification. And you’re done :)

You would however need to validate a tool for certain use cases where you can’t verify the output.

Example is when you plan to use a cloud repository like Git Hub or Azure DevOps for storing the code your software/device is built from. You wouldn’t be able to reliably inspect the bits on each commit or clone activity and for everyone who uses the tool. And that’s why you’d need to validate.