Medical Device Software Validation Terminology
To read the first blog of this series, Cloud Computing and Software Validation, please click here.
I was recently speaking with a colleague about the significant software validation burden on life science companies. I found it interesting how difficult it was to sort out our terminology. It turns out that the regulatory agencies – and the Food and Drug Administration (FDA) in particular – have not been consistent in the application of language and definitions.
This confusion adds to the growing complexities that organizations with required FDA oversight might find challenging. I thought it might be valuable to spend some time discussing the various terms to better provide a common reference point.
The first order of business is to discuss the different types of software validation.
Design V&V – Verification and Validation performed on software that is either in itself a medical device, or resides on a medical device. This software is unique in that it is required to be compliant with ISO 62304. The others are not. (Read how Polarion helps customers achieve fast IEC 62304 compliance.)
Regulatory agencies often interchange the verification and validation terms. One of the common mistakes is to use Validation when either Verification and Validation – or just Verification – is intended. The definition of each as set forth in FDA regulation is the following:
Design Validation – means establishing by objective evidence that device specifications conform with user needs and intended use(s) (note the difference between design and process validation definitions).
Source – CFR 21 Part §820.3(z)
Design Verification – means confirmation by examination and provision of objective evidence that specified design requirements have been fulfilled.
Source – CFR 21 Part §820.3(aa)
System Software Validation (Automated Processes) – This software validation is required for platform software used support the manufacture of product or in the product quality management system (QMS). This task is often the responsibility of the IT department in large medical device companies. In fact, it’s not just validation, but also verification, and is similar in form to Design V&V, but conformance to ISO 62304 is not required. In this case we are validating a system for its intended use.
Process Validation with Software – means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications.
Source – CFR 21 Part §820.3(z)(1)
Notice that the Process Validation definition moves from design input language (User Needs and requirements) used in Design Validation to design output language (specifications).
The intent of the process validation is inherently different than the Design Validation. Process Validation doesn’t consider User Needs directly.
Our concern here is whether the production process produces a product that consistently meets specification or not. Often companies will use the IQ/OQ/PQ (Installation Qualification, Operational Qualification, Performance Qualification) framework to accomplish this task.
It’s sometimes possible to validate the machine software as part of the process validation in the context of the production run. An example of this is an adhesive dispensing machine I once validated. There was software on the machine, but we simply added software challenges to the process validation – one example of this was an alarm check added to the IQ – to assure the software was operating as intended in the context of dispensing the adhesive.
In any case Polarion serves very well to provide the design control definition, traceability, and document management necessary to provide compliance with CFR, MDD, and ISO 62304. We welcome you to schedule a live demo of of medical devices by Polarion.
I hope this serves to clarify the medical device validation terminology, and provide a clearer picture of what is required for validation of the different types of medical device software.
