Release of the FDA Draft Guidance “Computer Software Assurance for Production and Quality System Software”: Key Notes

INTRODUCTION

Recently, the Compliance and Quality team at the CDRH of the FDA issued the long-awaited draft guidance: “Computer Software Assurance for Production and Quality System Software. draft. At this stage, this draft guidance is released for comments to the FDA staff and the industry. This article shares my take-away key notes that summarize the content of the draft guidance.

Key Notes

1. Applicability and Intended Use

FDA’s draft guidance clearly identifies the type of industry that this document is primarily intended for. The guidance also specifies what computer systems thar are in scope.

• Since the first implementation of the Product Quality Pilot in 2018, FDA has targeted Medical Devices manufacturers, covered by Quality System regulation part 820, to apply the Computer Software Assurance framework and approach: “The Quality System regulation includes requirements for medical device manufacturers to develop, conduct, control, and monitor production processes to ensure that a device conforms to its specifications […].
• In scope of this draft guidance are computer and automated data processing systems:
  • Used directly as part of production or the quality system, and software that supports production or the quality system. The draft also clearly defines the term “directly”.
  • To be used to support production or the quality system. For those supporting systems, effort of validation may be reduced as they often carry lower risk to patient safety.
• Out of Scope of this guidance are software systems generally not considered to be used as part of production or the quality system and that are not covered by part 820.

2. Risk Framework and Risk-Based Approach

FDA recognizes that computer systems are often comprised of rather complex features, functions and operations, and accordingly may have one or more intended uses (e.g., ERP systems). Consequently, FDA recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy. Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations.

Although not specified in the draft guidance, this decision-making process that FDA recommends is part of the “Critical Thinking” approach, a term that we are more familiar with.

FDA concern is primarily with the review and assurance for those software features, functions, and operations that are high process risk because a failure could potentially cause a medical device risk, where:

• A process risk refers to the potential to compromise production or the quality system
• A medical device risk refers to the potential for a device to harm the patient or user

In other words, this outlines the patient safety and product quality criteria to use in the risk assessment streamlined process.

Additionally, and for the process risk, this guidance clearly makes the distinction between a software feature, function, or operation that poses a “high process risk” and one that is “not high process risk.” A high process risk is one in which a failure to perform as intended may result in a quality problem that foreseeably compromises safety, resulting in an increased medical device risk.

As a result, the outcome of the risk analysis will drive the rigor of testing, as outlined below.

3. Testing

FDA recommends that manufacturers apply principles of risk-based testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based the levels of analyzed risk to determine the appropriate activities.

This guidance presents in detail the different types of unscripted testing versus scripted testing, and proposes the following recommendations to document testing:

• For high-risk software features, functions, and operations, manufacturers may choose to consider more rigor such as the use of scripted testing or limited scripted testing, as appropriate, when determining their assurance activities.
• For software features, functions, and operations that are not high-risk, manufacturers may consider using unscripted testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk of the intended use.

However, FDA stipulates that the manufacturers are solely responsible for determining the appropriate assurance activities that are most appropriate for risk associated with the intended use.

For testing, FDA encourages:

• The use of computer system validation tools, such as a bug tracker, automated testing tools, for software assurance.
• The use of testing done in iterative cycles (e.g., Agile methodology) and performed continuously throughout the lifecycle of the software.

4. Reporting

When establishing the record, FDA recommends that the manufacturer capture the following in a simplified document report without the need to include more evidence than necessary:

• 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;
  • 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)

5. Summary

FDA continuously advocating for the use of the CSA approach, as the discretion of the manufacturers. With the release of this draft guidance for CSA, FDA achieved an important milestone on their journey to modernize approach to validation of production and quality system software used in the medical devices industry.

However, there are still several QA organizations at manufacturers who are reluctant to shift the validation paradigm from CSV to CSA. Hopefully, the release of this draft guidance will bring them confidence to start making the move to CSA.

Manufacturers who have already embraced CSA for the validation activities of their production or quality system software, have reported significant benefits using this approach over CSV validation activities, for which timeline, resource, and financial burdens are typically associated with.

Ultimately, CSA will drive better patient outcomes and faster time to market.

About the Author:

Laurent Saugrin, Associate Director, Computer Software Assurance

Sr. professional with 20 years of experience within the pharmaceutical biotech and Medical Devices industries, managing CSV and CA projects and programs. Extensive experience leading projects for validation of enterprise systems and quality management systems. Focus on Compliance for Cloud Computing.