The FDA has released a draft guidance document entitled Computer Software Assurance for Production and Quality System Software. The FDA believes that the recommendations provided within the guidance will help foster innovation without compromising quality or compliance.
The draft guidance was prepared by the Center for Devices and Radiological Health (CDRH) and the Center for Biologics Evaluation and Research (CBER) in consultation with other offices. It is scoped for computers and automated data processing systems used as part of medical device production or the quality system. Nonetheless, it is anticipated that this draft guidance will propel all segments of the health and life sciences industry to boost their quality mindset and revisit how they perform computerized system validation.
Here is what we'll be taking a look at:
- The proposed Computer Software Assurance framework
- Benefits of Computer Software Assurance
- What do you think?
Let's get started!
The proposed Computer Software Assurance framework
From the get-go, this draft guidance puts forth a new buzzword for the industry: Computer Software Assurance, or CSA. It describes a flexible and risk-based approach for evaluating software and establishing confidence (assurance) in the computers and automation used for production or quality systems associated with medical devices.
The draft guidance also outlines a framework for how software can be validated and how CSA can help maintain the validated state throughout the software lifecycle. Eventually (once it becomes effective), the guidance will replace Section 6 of the “General Principles of Software Validation” final guidance (issued in 2002).
Reinforced with practical examples, the draft guidance describes a four-step approach underpinned by risk-based techniques and testing activities.
Step A: Identify the intended use
Based on your understanding of how the software will be used, decide if the software even needs to be validated at all. Conduct an assessment of the intended use (and document your decision-making process) to decide whether a software is used Directly as part of, or to Support, production or the quality system. Such software will need to be validated (go to Step B). If a software does not support or is not used as part of production or the quality system, it does not need to be validated. As a software might have more than one intended use, it may be sensible to examine the individual features, functions, and operations to facilitate decision making.
Step B: Determine the risk-based approach
For software that supports or is part of the production or quality system, conduct an assessment (and document your analysis) to identify factors that may impact or prevent the software from performing as intended. These may be interpreted as process risks (could impact the production or quality system) or medical device risks (could cause the medical device to cause injury). The assessment should focus on identifying those risks that may result in a quality problem that foreseeably leads to or manifests itself in compromised safety. As the FDA is primarily concerned with the software features, functions, and operations that present the greatest risk, it is recommended to classify the perceived risks in a binary manner – “high risk” vs. “not high risk”. It is then possible to select appropriate Computer Software Assurance activities which are commensurate with the recognized risks (go to Step C).
Step C: Determine the appropriate assurance activities
The rigor of CSA activities, including testing, should be proportionate to the perceived risk. Greater risks generally mean greater rigor (more collection of objective evidence). Conversely, lower risks generally mean less rigor (less collection of objective evidence).
The draft guidance puts a significant focus on testing. Different testing techniques (Unscripted vs. Scripted testing) can be practiced, and each will yield a different level of objective evidence (go to Step D). Suitable type(s) and/or combinations of testing methods should be selected based on the analyzed risk of failure of the software features and functions being tested.
Assurance activities need not be limited to testing, as testing alone is often insufficient to demonstrate fitness for intended use. When figuring out which assurance activities are appropriate, consider whether additional mechanisms are in place to reduce the risk of quality problems (e.g. process controls, use of monitoring tools, procedures, vendor testing activities). These mechanisms can be leveraged to reduce the overall effort invested.
Step D: Establish the appropriate record
Practicing Computer Software Assurance does not absolve you of the obligation to produce objective (documented) evidence, but it does mean you can adjust the amount of documentation produced to just the right amount (not more, not less) to establish assurance of intended use. Different formats (other than traditional documents) are acceptable, as long as the approach satisfies the content and legal documentation requirements. The documentation needs to show that the software has been assessed, and the objective evidence should be sufficient to demonstrate that the software (as a whole or broken down by specific feature, function, or operation) performs as intended. The record of CSA activities should therefore focus on capturing information related to assurance and should include: intended use, risk prioritization, summary of testing (description of testing, issues found, statement of acceptability of results, traceability to who conducted/reviewed the assessment and when).
Benefits of Computer Software Assurance
To those familiar with principles of validation for GxP computerized systems, it’s evident that Computer Software Assurance applies a risk-based framework that is reminiscent of GAMP 5. At Montrium, our system development lifecycle is designed to follow GAMP 5 principles and is consistent with the CSA draft guidelines. Organizations who use Quality Connect can be assured the software was developed and is delivered following best practices.
Being risk-based means that the rigor of activities can be scaled accordingly such that effort does not exceed what is necessary to address the risk. In turn, this results in more efficient and cost-effective use of resources that implicitly yields higher-quality outcomes.
What do you think?
The draft guidance is currently available for comment purposes only (not for implementation). If you have any comments or suggestions for the FDA, you can submit them online. The FDA will consider comments submitted by November 14, 2022 before issuing the final version of the guidance.
Want to stay in the loop about regulatory developments, GxP computerized systems, and much, much more? Subscribe to updates from Montrium and we'll deliver expert analyses right to your inbox 👇
