On the New FDA Guidance on Software Assurance

On September 13 2022, the FDA issued a new draft guidance on “Computer Software Assurance for Production and Quality System Software”.

This new guidance is intended to supplement the current approach described in the 2002 “General Principles of Software Validation” guidance. This guidance additionally discusses specific risk considerations, acceptable testing methods, and efficient generation of objective evidence for production or quality system software.

There is no major change in the validation approach for software tools, but the FDA is now classifying them as either “software that is used directly as part of production or the quality system”, and “software that supports production or the quality system”. Also, the outputs of the risk analysis for the tool are used to classify it as either “high process risk” or “not high process risk”.

We put together a visual flowchart to summarize the approach the guidance describes.

1. Unscripted testing – Dynamic testing in which the tester’s actions are not prescribed by written instructions in a test case.
   1. Ad-hoc testing
   2. Error-guessing
   3. Exploratory testing
2. Scripted testing – Dynamic testing in which the tester’s actions are prescribed by written instructions in a test case. Scripted testing includes both robust and limited scripted testing.
   1. Robust scripted testing
   2. Limited scripted testing

Although not explicitly called out in the document, certain parts of the guidance that a company can leverage activities that are relevant to SaaS tools, e.g.:

1. “Activities, people, and established processes that provide control in production.”
2. “Purchasing control processes for selecting and monitoring software developers. For example, 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.”
3. “Additional process controls that have been incorporated throughout production.”
4. “The data and information periodically or continuously collected by the software for the purposes of monitoring or detecting issues and anomalies in the software after implementation of the software. “
5. “The use of Computer System Validation tools (e.g., bug tracker, automated testing) for the assurance of software used in production or as part of the quality system whenever possible.”
6. “The use of testing done in iterative cycles and continuously throughout the lifecycle of the software used in production or as part of the quality system.”

Examples

The Examples that the FDA lists in the guidance can be found below:

Example	Resulting Risk
An Enterprise Resource Planning (ERP) Management system contains a feature that automates manufacturing material restocking	High process risk
Same as above, but a qualified person checks the materials before their use in production	NOT high process risk
An ERP management system contains a feature to automate product delivery	High process risk
An automated graphical user interface (GUI) function in the production software is used for developing test scripts based on user interactions and to automate future testing of modifications to the user interface of a system used in production	NOT high process risk
Nonconformance Management System including: 1. Nonconformance (NC) Initiation Operation 2. Electronic Signature Function 3. Automated Product Containment Function	1. NOT high process risk 2. NOT high process risk 3. High process risk
Learning Management system	NOT high process risk
Business Intelligence Applications including 1. Connectivity Functions 2. Usability Feature 3. Reporting Functions	1. High process risk 2. NOT high process risk 3. NOT high process risk

Summary

At a high level, the steps required to assess and validate your software tool and functions are:

1. Define the intended use;
2. Identify what functions are used as part of production or the QMS;
3. If possible, separate low risk functions from high risk functions;
4. Determine which functions are high process risk and which ones are not;
5. Assess if there are additional assurance activities in the process that mitigate the risk related to software (function) failure;
   • If appropriate they can be added;
6. Based on the final risk assessment, build an appropriate plan to validate the software function(s).