The US FDA released on September 13, 2022 new draft guidance on Computer Software Assurance (CSA) for Production and Quality System Software. As the medical device industry utilizes more and more software to support and automate quality assurance, regulatory, and production processes, there has been a great demand for input and direction on this topic. The FDA recognizes medical device manufacturers’ desire for more clarity regarding FDA’s expectations for software assurance and validation.
The new guidance does not address the complete software validation process but rather focuses on determining the risk of production or quality system software, considerations for risk mitigation, and acceptable objective documented evidence for assurance activities to comply with regulatory software validation requirements such as defined in 21 CFR part 820 QSR.
The new guidance should be used in conjunction with the 2002 FDA Software Validation Guidance (General Principles of Software Validation) as this new guidance only supersedes section 6 of the 2002 guidance: validation of automated process equipment and quality system software.
Summary
The new guidance describes the following approach intended to establish a risk-based framework for computer software assurance activities.
Determine Intended Use
This guidance does not apply to all software applications. This guidance is specific to computer software or automated data processing systems that are used in medical device manufacturing and quality system management. As there are many potential uses for these types of software, it is key to identify the intended use. Initially, this can be done by determining if the software is used directly or indirectly as part of the production or quality system. This step may also need to be performed on individual features, functions, or operations within the software if the software fulfills multiple purposes and has differing risk levels for each of these purposes.
Determine Risk Level
Like most risk assessments, the recommended risk process outlined within the guidance can be summarized as (1) identifying reasonably foreseeable failures and the risks resulting from each such failure, (2) identifying the level of risk (not high risk, high risk), and (3) determining risk-mitigating activities. However, this risk assessment should be performed from the perspective of reasonably foreseeable risks that would affect the normal functioning or performance of the software, and what effects those failures would have on downstream processes (process risks) and products (medical device risks). Because the standard model of occurrence estimation is not applicable, a new risk scale is necessary rather than using one created for a product risk assessment.
The FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises product and patient safety (i.e. a medical device risk).
The guidance includes several examples of not high and high risk software operations, for example:
Determine Assurance Activities
Continuing with the risk-based concept, the guidance expects that assurance activities will be based on the risk level associated with the feature, function, operation, or software. Computer software assurance is “a risk-based approach for establishing and maintaining confidence that software is fit for its intended use”. These assurance activities can include scripted testing, unscripted testing, or other testing methods appropriate to the risk level.
For high-risk level software features, functions, and operations, more rigor in assurance is expected, such as the use of scripted testing. For software features, functions, and operations that are not considered high risk, manufacturers may use unscripted testing methods that are suitable for the risk of the intended use.
When deciding on the appropriate assurance activities, manufacturers should consider whether there are any additional controls established that decrease the impact of medical device risk. Some examples of quality system controls include data integrity processes (e.g., manual verification of software output), purchasing and supplier management controls, process monitoring, and computer system validation controls.
Establish Documentation
As with any quality system process, documented objective evidence of performed activities is a regulatory requirement. For software assurance activities this includes as a minimum:
- The intended use of the software application (software feature, function, or operation;
- Determination of the risk level of each software application feature, function, or operation;
- Documentation of the assurance activities conducted (e.g., test description, test results, and acceptability). Documentation does not need to include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk level identified.
The guidance gives several examples of what the documented objective evidence should include for different software applications of different risk levels. With the scope of the guidance in mind, these examples are very concise when compared to full software validation protocols or reports. It is these examples that truly reveal the purpose of the guidance and its intention to simplify the process and reduce the effort for production and quality system software validation.
Conclusion
The 2022 FDA draft guidance on Computer Software Assurance for Production and Quality System Software is a welcome addition to the FDA guidance on software assurance and validation. For a long time now the medical device industry has struggled to determine the appropriate level of validation for supporting (non-product) software and endured the burden of defending its decisions.
The guidance begins the process of shedding light on that subject with the application of critical thinking and a true risk-based approach, enabling manufacturers to tailor assurance rigor with the medical device risk, and therefore patient safety, on top of mind. Although it brings no change to the current validation regulatory requirements, the new computer software assurance (CSA) approach tends to move away from the traditional computer system validation approach (CSV) and ensures that validation activities are focused on testing the critical aspects of software efficiently. This fits within the least burdensome approach as promulgated by the FDA.
If you have further questions on production or quality system software validation, software risk assessments, or computer software assurance, Qserve is happy to answer any questions you may have and assist with your quality and regulatory compliance.