FDA is issuing this draft guidance to provide recommendations on computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system. 


FDA envisions a future state where the medical device ecosystem is inherently focused on device features and manufacturing practices that promote product quality and patient safety. 


FDA has sought to identify and promote successful manufacturing practices and help device manufacturers raise their manufacturing quality level. 


In doing so, one goal is to help manufacturers produce high-quality medical devices that align with the laws and regulations implemented by FDA. 


Compliance with the Quality System regulation, Part 820, is required for manufacturers of finished medical devices to the extent they engage in operations to which Part 820 applies.


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 (21 CFR 820.70, Production and Process Controls), including requirements for manufacturers to validate computer software used as part of production or the quality system for its intended use (see 21 CFR 820.70(i)). Recommending best practices should promote product quality and patient safety, and correlate to higher-quality outcomes. 


In recent years, advances in manufacturing technologies, including the adoption of automation, robotics, simulation, and other digital capabilities, have allowed manufacturers to reduce sources of error, optimize resources, and reduce patient risk. 


FDA recognizes the potential for these technologies to provide significant benefits for enhancing the quality, availability, and safety of medical devices, and has undertaken several efforts to help foster the adoption and use of such technologies.


When final, this guidance is intended to provide recommendations regarding computer software assurance for computers or automated data processing systems used as part of production or the quality system.


This guidance is not intended to provide a complete description of all software validation principles. 


FDA has previously outlined principles for software validation, including managing changes as part of the software lifecycle, in FDA’s Software Validation guidance. 


This guidance applies the risk based approach to software validation discussed in the Software Validation guidance to production or quality system software.


This guidance additionally discusses specific risk considerations, acceptable testing methods, and efficient generation of objective evidence for production or quality system software.


The following approach is intended to help manufacturers establish a risk-based framework for computer software assurance throughout the software’s lifecycle.

  • Identifying the Intended Use
  • Determining the Risk­ Based Approach
  • Determining the Appropriate Assurance Activities
  • Establishing the Appropriate Record

By stressing critical thinking in the validation process, the FDA is emphasizing a risk based approach to streamline validation based on the GAMP5 model. 

This means that while all aspects of the system used in manufacturing must be tested, only components essential to the quality of the product and safety of the patient need to be subjected to full validation rigor. 

The CSA process can be described in four broad steps:

1. Identify the software’s intended use
The CSA approach starts with identifying intended use of the software or software feature.

If the system directly impacts patient safety, device quality, or quality system integrity, then it would be considered a direct system 

2. Prioritize risk and determine your approach
For validation purposes, it will be important to delineate where the system in question could introduce risk, versus what is a process risk, and use critical thinking to calculate the risk impact of the system or system feature on patient safety and product quality. 

3. Leverage vendor documentation where possible
Audit your software vendors. If they have quality documentation and validation in place, it can be used for medium and low risk features. 

4. Conduct testing activities based on determined risk level

Computer System Assurance can be divided into two risk based testing categories: 

Unscripted testing: Used for testing low risk systems or features that do not directly impact product quality or safety. 
The testing is carried out without the use of detailed scripts and testing procedures with the objective of a Pass/Fail rating outcome of the testing.

Scripted testing: Used for testing high risk systems or features that may have a significant impact on product quality or safety. The testing is based upon well-defined test scripts and procedures with an outcome of expected results and a Pass/ Fail rating. 


Resource Person: Barbara Pirola