The past few years I’ve worked for a Medical device manufacturer, Quidel Corporation. They create 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 has been in high demand.
Those rapid tests run on Sofia 2 (left in bellow photo), Sofia and their Solana (not pictured) 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 overall process of creating hardware and software needs to be carefully documented and every step approved along the way.
And by the way I lead the creation and maintenance of the myquidel.com service allowing Quidel customers to download and self-install software updates to those instruments. For a long time that service was considered an accessory to a medical device which meant it too fell under FDA design control scrutiny.
Getting back on point – In particular, the requirements need to be what we call “Verified” and “Validated” (or V&V-ed) as part of that design control process. And again, the whole 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 (intended use is what you put on the product label as to how you intend the product to be used). 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, the question is should you also validate the tools and processes used to develop your end product?
I’ve worked with a few folks in software V&V (Verification and Validation).
Some will tell you:
You need to validate everything! – all the tools you are using!
and then you go: huh? 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 as it turns out 🙂
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
And that above quote is the key.
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.
For example, you write up requirements and test cases in Microsoft Word. So, Word is your tool. And then print those out to share and get signatures from other folks in the company. In this case, Verification means you manually review and then wet sign the documents. Meaning we can reliable inspect the result of the output from Word.
So, in that case you don’t need to validate the process or tool which generated the document. You don’t validate Microsoft Word, Excel or even Windows. 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 (or process) 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 code commit for everyone who uses the tool – and also ensure the bits you committed is exactly what someone would be able to later clone out of the repo.
It just isn’t practical.
So in that case (and assuming you are under design control scrutiny) you need to validate the tool is working reliably in that particular use case and you show you can count on that automation to work every time.
And that’s when and why you’d need to validate.