This article defines software verification and validation for medical devices and provides an overview of CE Marking and 510k requirements. We also provide a link to our free download of a webinar on 510k software documentation.
Software Verification and validation is an essential tool for ensuring medical device software is safe. Software is not a piece of metal that can be put into a strain gauge to see if the code is strong enough not to break. That’s because software is intangible. You can’t see if it is in the process of failing until it fails. The FDA is concerned about software safety since many medical devices now include software. Software failure can result in serious injury or even death to a patient. This places significant liability on the device manufacturer to ensure their software is safe. One way to ensure software safety is to perform software verification and validation (V&V).
What is software verification and validation (V&V)?
Definitions of software verification and validation confuse most people. Which tasks are software verification? And which tasks are software validation? Sometimes the terms are used interchangeably. Even the FDA does not clearly define the meaning of these two terms for software. For example, in the FDA’s design control guidance document the following definitions are used:
“Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.”
“Validation means confirmation by examination and provision of objective evidence that the particular requirements for specific intended use can be consistently fulfilled.”
Specific intended use requirement…specified requirements…what is the difference? To understand the difference between the two terms, the key is understanding “Intended Use.” It is asking the question: “What is the software’s intended use?”
“Intended Use” is not just about a bunch of engineers sitting around a table coming up with really fresh ideas. “Intended Use” refers specifically to the patient/customer of the software and how it fulfills their needs (i.e., “User Needs”). Systematic identification of user needs is required, and the software must address the user needs. Identification of user needs is done through customer focus groups, rigorous usability studies, and consultation with subject matter experts such as doctors and clinicians providing expert insight.
“Intended Use” also ensures the safety of the process through the process of “Hazard Analysis,” whereby any hazard that could potentially cause harm to the patient/customer is identified. For each identified hazard, software requirements, software design, and other risk controls are used to make sure the hazard does not result in harm, or if it does, the severity of the harm is reduced as far as possible.
So if “Validation” ensures user needs are met, what is “Verification” and how does it apply to the software development process. “Verification” ensures that the software is built correctly based on the software requirements (i.e., design inputs), with regard to each task the software must perform (i.e., unit testing), during communication between software modules (i.e., integration testing) and within the overall system architecture (i.e., system-level testing). This is accomplished by rigorous and thorough software testing using prospectively approved software verification protocols.
CE Marking requirements for software verification and validation (V&V)
European CE Marking applications include the submission of a technical file that summarizes the technical documentation for the medical device. To be approved for CE Marking by a Notified Body, the device must meet the essential requirements defined in the applicable EU directive. The technical file must also include performance testing of the medical device in accordance with the “State of the Art.” For software, IEC/EN 62304:2006, medical device software – software life cycle processes, is considered “State of the Art” for the development and maintenance of software for medical devices. This standard applies to stand-alone software and embedded software alike. The standard also identifies specific areas of concern, such as software of unknown pedigree (SOUP). As with most medical device standards, the standard provides a risk-based approach for the evaluation of SOUP acceptability and defines testing requirements for SOUP.
FDA requirements for software verification and validation (V&V)
For 510k submissions to the US FDA, section 16 of the 510k submission describes the software verification and validation (V&V) activities that have been conducted to ensure the software is safe and effective. There are 11 documents that are typically included in this section of the submission for software with a moderate level of concern:
- Level of Concern
- Software Description
- Device Hazard Analysis
- Software Requirement Specification (SRS)
- Architecture Design Chart
- Software Design Specification (SDS)
- Traceability Analysis
- Software Development Environment Description
- Verification and Validation Documentation
- Revision Level History
- Unresolved Anomalies (Bugs or Defects)
The FDA does not require compliance with IEC 62304 as the European Regulations do, but IEC 62304 is a recognized standard, and manufacturers must comply with all applicable parts of IEC 62304 if they claim to follow IEC 62304. The FDA also provides a guidance document for the general principles of software validation. The above requirements for software verification and validation documentation also apply to software as a medical device (SaMD).
Additional Resources
If you are interested in learning more about the documentation requirements for a 510k submission of a software medical device, please click here to download a free recording of our 510k software documentation webinar.
Medical Device Academy also has a new live webinar scheduled for Tuesday, January 5, 2016, @ Noon (EST). The topic is “Planning Your 2016 Annual Audit Schedule“. We are also offering this live webinar as a bundle with our auditor toolkit.
About the Author
Nancy Knettell is the newest member of the Medical Device Academy’s consulting team, and this is her first blog contribution to our website. Nancy is an IEC 62304 subject matter expert. To learn more about Nancy, please click here. If you have suggestions for future blogs or webinars on the topic of medical device software, please submit your requests to our updated suggestion box.
The traceability matrix is like user needs -> system requirements -> software requirements
where is the system requirement specification in your diagram?
what is the difference between system validation and software validation?
Some companies combine their system requirements specification with the software requirements specification, because the software is a stand-alone device. Some companies separate them, because they have hardware included with the device as well. Unfortunately, both have the same acronym (i.e. “SRS”). If you have an embedded system with system requirements, I document these system requirements in my design inputs for the combined design/risk management plan. The software requirements specifications are separately documented in the software development plan. There is no separate “system requirement specification” in the V-diagram, because the V-diagram is specific to your software development process and it was created with only the software development process in mind. The V-diagram is from IEC 62304. It is intended to be an incremental process where you add requirements each time through the process until all of the system requirements have been satisfied. Often these additional requirements will be evolutionary as a product evolves from a minimum viable product (MVP) to the final commercial version of the product. Other people describe this process as a progression from alpha to beta to launch. This 3-step evolution is practical for a hardware device, while software can have hundreds of iterations.
Section 5.1.1(c) in IEC 62304 states that you should have traceability in your software development plan between SYSTEM requirements, software requirements, SOFTWARE SYSTEM test, and RISK CONTROL measures implemented in software. But the V-diagram is process model provided in Annex C (Figure C2).
Regarding your other question: software validation is poorly defined, because it doesn’t differentiate between verification activities and validation activities. True software validation is exactly the same as system validation. During true software validation, you are performing simulated use testing to validate that all of the software functions are executed correctly on the intended hardware platform in the intended use environment by the intended users. However, most people do not differentiate between true validation activities and verification activities. Instead of carefully defining what is a verification activity and what is a validation activity, most people refer to all software verification activities as software validation too. I make this mistake when I speak and write too. The FDA refers to all of this documentation as software validation documentation too. This is not really any different from using the term “sterilization validation documentation” when we are referring to verification of sterility or sterilization process validation–not design validation.
Software verification includes unit testing, integration testing, and system testing. However, verification does not include simulated use. Depending upon the functions of the software, there may be absolutely no difference between system testing and simulated use for simple software architecture.