The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of medical devices, has published a guidance document dedicated to the general principles of software validation. The document is intended to provide medical device manufacturers (software developers) with additional clarifications regarding the current legislation and recommendations to be followed in order to achieve and sustain compliance with the applicable regulatory requirements.
Table of Contents
As with other guidance documents issued by the FDA, the present guidance does not introduce new rules or requirements itself, and the provisions thereof are non-binding. An alternative approach could be applied, provided such an approach complies with the applicable regulatory requirements and has been approved by the authority in advance.
The present guidance describes the aspects retailed to:
- the context for software validation, including the main definitions,
- the role of software development in the general system design,
- the main differences in approach to be applied to software and hardware,
- outlines the benefits of software validation, and
- provides additional details regarding the design review.
The guidance is intended to assist medical device manufacturers (software developers) in complying with the Quality System regulation related to software validation. The approach described herein is quite common in the software industry in general. The FDA describes how it should be applied in the case of healthcare-related products and also highlights the most important aspects to be considered in this regard. The Agency additionally emphasizes that the approach described herein should not be construed as a comprehensive and exhaustive guide of software validation but rather a set of general principles to be followed. The particular way they should be applied should be determined in each situation on a case-by-case basis.
Requirements and Specifications
First, the FDA provides the definitions of the most important terms and concepts used in the context of software validation. In this regard, the authority refers to the FDA Glossary of Computerized System and Software Development Terminology and also to the Quality System regulation (21 CFR 802.3). The Agency also mentions that some definitions found in the medical device Quality System regulation can be confusing when compared to commonly used terminology in the software industry. Examples are requirements, specification, verification, and validation.
With regard to the first two terms, the authority states they could sometimes be confused, as there are no clarifications provided in the applicable legislation. According to the document, the requirements are defined as the expectations the device should meet, usually based on the actual needs of customers. The requirements could be different in their nature. In the case of software, the requirements are usually based on the expected functionality the future product should provide. Software requirements should be duly determined at the first stage of the design development process in order to ensure the final product meets its intended purpose and complies with the applicable safety and performance requirements. At the same time, a specification refers to “a document that states requirements” and constitutes a physical (visual) representation of requirements. Specifications describing the requirements could contain drawings, patterns, or other documents.
According to the guidance, the types of specifications include:
- System requirements specification,
- Software requirements specification,
- Software design specification,
- Software test specification,
- Software integration specification, and other types.
These documents are considered design outputs further used in the course of the verification process.
Verification and Validation
The authority further explains that verification and validation have different meanings as well, even if they are often used interchangeably. Sometimes they are even combined with testing. The FDA states these terms should be used separately and have the following meanings:
- Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase. Usually verification is performed by the means of software testing intended to verify whether the final product meets the requirements set forth in specifications. At the same time, the concept of verification also covers different types of analysis and inspections.
- Software validation stands for confirmation by examination and provisions of objective evidence that software specifications conform to user needs and intended users, and that the particular requirements implemented through software can be consistently fulfilled. The authority also mentions that software validation could take place at any stage of the software development process, including after its completion. In the course of the software valuation, its performance could be assessed in the context of the overall performance of a medical device. This process includes various types of testing to be carried out in order to assess whether the software and the device, in general, achieve their intended purpose.
The Agency acknowledges the difficulty of determining the sufficiency of verification and validation. Testing could be performed for a long period of time, and the more it lasts, the more details are available. Hence, the results become more accurate and reliable. However, it is important to decide on a reasonable extent for testing which will provide sufficient information to build “a level of confidence” with regard to the actual performance of a medical device, its compliance with the applicable requirements, and its ability to meet the needs of customers. The aforementioned level of confidence could be based on defects identified, the scope of testing, and other aspects to be considered when determining whether the software could be placed on the market and made available for actual use for its intended purpose or whether it requires additional testing and evaluation. As described in the present FDA guidance on software validation, the extent to which a new software product should undergo testing, validation, and verification should be based on the risks associated with the product – should the device expose users or patients to higher risks, more rigorous testing would be required. In this regard, the document refers to the Guidance for the Content of Pre-market Submissions for Software Contained in Medical Devices, and also to the applicable international standards ISO/IEC 14971-1 and IEC 60601-1-4.
Installation Qualification / Operational Qualification / Performance Qualification
Other important terms used in the context of the software include the following:
- Installation Qualification (IQ),
- Operational Qualification (OQ), and
- Performance Qualification (PQ).
However, in order to avoid confusion, the FDA abstains from using these terms in the present guidance on software validation as they could be misinterpreted by software professionals. The regulating authority finds it sufficient to mention that these terms could sometimes be used in the context of the matter.
In summary, the present FDA guidance on software validation provides additional clarifications regarding the most important terms and the way they should be used. The document provides the definitions of such terms as validation, verification, requirements, and specifications, and also outlines the main differences between similar ones.
Sources:
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
