4 Key Takeaways From the FDA’s Software Validation Guidance

Christmas came early this year . After several years of delay, the U.S. Food and Drug Administration (FDA) issued its computer software assurance (CSA) guidance. It’s been on the agency’s priority list for a while, but a slew of other concerns kept bumping this back. Squeezing it in at the end of fiscal year 2022, the software validation guidance was released mid-September and is open for comments until November 14.

Computer software validation has traditionally been a burden, so “Computer Software Assurance for Production and Quality Systems Software” comes as a relief. Now that it’s out, here are some things from the guidance to keep in mind the next time a validation project comes up.

1. Computer Software Assurance Is Risk Based

We’ve written about taking a risk-based approach to validation before. Deciding how to validate based on risk is the key to reducing validation burden, ensuring “the burden of validation is no more than necessary to address the risk.”

Keep in mind, the FDA is primarily concerned about a software feature, function, or operation failing and resulting in a quality problem that might compromise safety. If a failure would affect quality, but not pose a safety issue, the FDA doesn’t consider it high risk. Life sciences companies have other concerns, but for regulatory compliance purposes, this is primarily what needs to be top of mind when performing computer software validation.

For years, we’ve been promoting the use of vendor documentation and testing as a way to reduce computer software validation burden. The FDA agrees: “The manufacturer could incorporate the practices, validation work, and electronic information already performed by developers of the software as the starting point and determine what additional activities may be needed. For some lower-risk software features, functions, and operations, this may be all the assurance that is needed.”

2. Not All Testing Needs to Be Formal

There’s a big difference between what the FDA categorizes as unscripted and scripted testing. Unscripted testing includes ad-hoc testing, error-guessing, and exploratory testing. These are less formal and don’t rely on written instructions in a test case. Depending on the level of risk, these might be sufficient quality assurance activities.

Scripted testing includes the more work-intensive robust and limited scripted testing . High-risk software features will probably require these more rigorous approaches normally associated with computer software validation.

3. What Needs to Be Recorded for Computer Software Validation

Computer software assurance, according to this guidance, should produce less paperwork than expected. The FDA outlines exactly what needs to be recorded:

• The intended use of the software feature, function, or operation.
• The determination of risk of the software feature, function, or operation.
• Documentation of the assurance activities conducted, including:
  • Description of the testing conducted based on the assurance activity.
  • Issues found (e.g., deviations, failures) and the disposition.
  • Conclusion statement declaring acceptability of the results
  • The date of testing/assessment and the name of the person who conducted the testing/assessment
  • Established review and approval when appropriate (e.g., when necessary, a signature and date of an individual with signatory authority).

To show what this would look like in practice, the software validation guidance gives an example. It’s less than a page long, strongly implying that stacks of documents are unnecessary to prove compliance.

4. Digitization Eases Computer Software Validation

The FDA would really like it if you digitized . They didn’t exactly say that in the guidance document. But what they did say was, “As a least burdensome method, FDA recommends the use of electronic records, such as system logs, audit trails, and other data generated by the software, as opposed to paper documentation and screenshots.”

Granted, this is a recommendation, not a requirement. However, using electronic records doesn’t just simplify the computer software assurance process — it simplifies every compliance activity. Document control, training, quality event management, etc. can all be interconnected and automated when an electronic quality management system is used.

Conclusion

The software validation guidance isn’t terribly long — it’s 25 pages including appendices. However, we still couldn’t cover it all in a single blog post. You can read the entire guidance for yourself here. The document has very specific examples that will help quality personnel better understand what the agency expects.

Still have validation questions? Our validation expert Vice President of Product Management Erin Wright answers some common validation questions here.