Software verification is confirmation through objective evidence that specified requirements have been met. It confirms that design outputs have met the design input requirements. It is typically conducted at particular phases. Software verification and validation planning is essential in the early stages of software development.
While not required. It is very beneficial to use a third-party software validation service. This provides independence of review of the validation reports, and the ability to perhaps detect anomalies.
Software validation by the FDA is defined as testing and subsequent objective evidence that specifications conformed to the user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled. Validation is not covered by IEC 62304. It only covers software release in section 5.8. Manufacturers should validate the installation operation and performance of their medical device software.
The IVDR’s general safety and performance requirements 6.4 reads “the documentation shall contain evidence of the validation of the software, as it is used in the finished device. Such information shall typically include the summary results of all verification, validation, and testing performed in-house and applicable in an actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the labeling”.
The FDA advises that software validation should be increased in rigor as compared to hardware:
“Because of its complexity, the development process for software should be even more tightly controlled than for hardware, in order to prevent problems that cannot easily be detected later in the development process”.
User site testing, for example, also known as installation qualification, is essential for your medical device software.
The software validation process cannot be completed of course, without an established SRS (software requirements specification) and you can find some definitions and other requirements for software validation in 21 CFR 820 cited here. Your testing can be differentiated into 7 separate units. We have the unit level, the integration level, and then we move on to the system level. The system level validation should address functional concerns, including performance issues, response to stress conditions, operation of security features, effectiveness of recovery procedures, usability, compatibility with other software products, behavior in each of the defined hardware configurations, and accuracy of documentation.
Let’s move on to some technical file documentation requirements as they relate to medical device software. So here’s a list of key software technical file requirements.
- Interoperability – discussing that in your technical file, especially for those softwares in a medical device
- Describe your security controls
- Describer your architecture
- The Performance Evaluation, which is applicable to the IVDR
- The Clinical Evaluation, which is applicable to the MDR
- Software validation documentation
- You want to provide an overview of design, including the design stages
- Your usability and human factors testing
- If applicable, your GSPR analysis
- Risk management
Annex two in the IVDR paragraph 6.4 – which reads that the documentation shall contain evidence of the validation of the software, as it is used in the finished device. It includes the summary results of all verification, validation, and testing performed in-house and in an actual user environment prior to release. Address, if applicable hardware configurations and operating systems identified in the labelling.
Note: IVDR essential requirements are now termed as GSPR 16.2 also cites the requirement for software validation and verification.
Performance evaluation is defined by the IVDR as “an assessment and analysis of data to establish or verify the scientific validity, the analytical and, where applicable, the clinical performance of a device.”
Clinical performance is defined by the IVDR as “the ability of a device to yield results that are correlated with a particular clinical condition or a physiological or pathological process or state in accordance with the target population and intended user.”
Clinical evidence is defined by the IVDR as “clinical data and performance evaluation results, pertaining to a device of a sufficient amount and quality to allow a qualified assessment of whether the device is safe and achieves the intended clinical benefit(s), when used as intended by the manufacturer.”
Performance evaluation report or PER is a critical element of the technical file. It is the outcome of the performance evaluation plan. All devices require a PER. The IVDR states – The performance evaluation shall follow a design and methodologically sound procedure. Particular contents can be justified as not applicable, only as appropriate. IVDR also reads the clinical evidence shall support the intended use of the device.
Refer to article 56 of the IVDR for more information on your performance evaluation, and then refer to part A of Annex 13 for all of the requirements of PERs.
Performance evaluation, of course, is not just pre- or post-CE, it is continuous.