Validation requirements apply to software used as components in medical devices, to software that is itself a medical device, and to software used in the production of the device or in implementation of the device manufacturer’s quality system. Any medical device software developed after June 1, 1997, regardless of its class, unless exempted in a classification regulation is subject to design controls. Specific requirements for software validation are in 21CFR 820.30 (g).1
Software is usually part of a bigger hardware system, software validation typically includes evidence that all software requirements have been met, and hence the same design control requirements apply to the software components of the device. Because software has the capability to learn, adapt and improve with time, that could fix defects proactively (surveys, interviews) and reactively (complaints, post-market surveillance), etc. These changes may introduce new risks to the software. Hence, software validation should be conducted for all software development projects including the changes/revisions made to the existing medical device software.1
FDA defines software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled.” According to the FDA, software validation is a matter of developing a ‘level of confidence’ that the device meets all requirements and expectations of the user from the software.1
All software subject to verification and validation requires a software verification and validation plan. This plan will outline what will be accomplished as part of the validation effort. A Software verification and validation procedure is also required that will govern the validation activities more specifically the sequence of actions that must be carried out to complete the validation successfully.1
Validation of software changes:
Since a small change in the software may create a big impact on the system as a whole, the validation status of the software needs to be re-established once a change is made. Appropriate regression testing must be carried out to demonstrate that the vulnerable portions of the software have not been adversely affected.1
Validation of off the shelf (OTS) software:
Validation of OTS software systems can be difficult because of the many unknown parameters to the sponsor. However, the device manufacturer or the specification developer has the sole responsibility of complying with the FDA software validation requirements. Vendor verification and validation documents may be used in place of, or to support, the necessary deliverables. Again, the responsibility to have all the documents in compliance with FDA regulations lies with the device manufacturer or the specification developer. The vendor’s design and development methodologies should be audited as part of the supplier quality program of your organization to avoid any regulatory issues in the future.1
Struggling with the quality requirements for your software? Give us a call at 248-987-4497 or email us at info@emmainternational.com.
1FDA (Jan 2002) General Principles of Software Validation; Final Guidance for Industry and FDA Staff retrieved on 05/10/2019 from https://www.fda.gov/media/73141/download
