Software Validation for Medical Devices

by | May 22, 2019 | FDA, Medical Devices, Quality Systems, Regulatory, Software, Validation

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

 

Nikita Angane

Nikita Angane

Solutions Delivery Specialist - Ms. Angane is a Bioengineering graduate with experience in medical device commercialization, product development, quality system compliance and regulatory affairs. Her portfolio includes working on medical devices, combination products, and pharmaceuticals. As a Solutions Delivery Specialist at EMMA International, she offers her expertise to help our clients achieve an effective and sustainable quality system, and develop regulatory strategies for market access and compliance of new products in the US and international markets. Ms. Angane earned a Bachelor of Engineering in Biomedical Engineering from the University of Mumbai, India and an M.S. in Bioengineering from University of Illinois at Chicago.

More Resources

FDA Adverse Event Reporting 

FDA Adverse Event Reporting 

When reporting an Adverse Event to the Food and Drug Administration (FDA) the best method is to utilize the FDA Adverse Event Reporting System (FAERS). FAERS is a database that contains adverse event reports, product quality complaints that led to an adverse event, and medication error reports1. All FAERS reports are easily accessible to the public. 
De Novo Classification

De Novo Classification

A device can be registered for the De Novo pathway if there is evidence of the safety and effectiveness of the device and there is not a previously legally marketed predicate device1. When determining if your device can go through the De Novo process there are two pathways available to determine the device classification.
Abbreviated 510k submission

Abbreviated 510k submission

There are three types of 510K, Premarket Notifications, which can be submitted to the Food and Drug Administration (FDA) traditional, abbreviated, and special. Abbreviated and Special 510K submissions can be utilized when the submissions meet the certain factors presented by the FDA. When submitting an abbreviated 510K the submission must include the elements that are identified in 21CFR 807.87 for the information required in a premarket notification submission.

Ready to learn more about working with us?

Pin It on Pinterest

Share This