Computer Systems Validation: How To Avoid FDA Warning Letters C.F.R. 820.70(i)

Computer systems validation (CSV) is a standard regulatory exercise Med Device companies are required to complete. This is not new news. In fact, the content in this article may not be “new news” for you either, but as with other regulatory requirements, it’s useful to revisit the basic information and  ensure you are taking the correct steps for compliance. This article will help you avoid 483 observations and FDA warning letters related to CSV’s.

Why do companies have to complete a CSV?

Computer System Validations are the mandatory and indestructible audit trail that the Food and Drug Administration (FDA) considers to be applicable to:

1. the validation of medical device software or,
2. the validation of software (systems) used to design, develop, or manufacture medical devices.

Whilst completing CSV’s can be time consuming, failure to comply will result in formal warning letters from FDA investigators who often cite issues with respect to “intended use” and other aspects of Title 21 C.F.R. 820.70(i).

The regulatory requirements under Title 21 C.F.R. 820.70(i).

The guidance describes how certain provisions of the medical device Quality System regulation apply to computer systems and the agency’s current approach to evaluating a software validation system.

The guidance recommends an integration of software life cycle management and risk management activities. Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. 

While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.

The FDA Code of Federal Regulations, Title 21 under Quality Systems, subsection 70(i) sites the following:

“When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.”

The FDA also provides additional supportive information via Section 6 of “Validation of Automated Process Equipment and Quality System Software” in the Principles of Software Validation; Final Guidance for Industry and FDA Staff, January 11, 2002.

Identifying What Computer System Validation Is Applicable For You.

The FDA recommends utilizing a risk-based assessment process to determine whether validation is necessary. You should consider a system’s impact on product quality, safety and records integrity. So firstly, you’ll need to create a company-wide inventory of tools and assess whether they perform quality or business critical functions. 

Once you have a comprehensive, you’ll need to invest time developing meaningful user requirements in line with what needs to be captured under Section 6.2:

• the “intended use” of the software or automated equipment; and
• the extent to which the device manufacturer is dependent upon that software or equipment for production of a quality medical device.

The device manufacturer (user) needs to define the expected operating environment including any required hardware and software configurations, software versions, utilities, etc. The user also needs to:

• document requirements for system performance, quality, error handling, startup, shutdown, security, etc.;
• identify any safety related functions or features, such as sensors, alarms, interlocks, logical processing steps, or command sequences; and
• define objective criteria for determining acceptable performance.

How To Create A Validation Strategy

Once the user requirements have been identified they can be translated into functional/design specifications. From this, an overarching validation strategy can be created which includes:

• The roles of the people participating in the validation, 
• The scope of the validation, 
• The methodology,
• Segmentation to distinct protocols (IQ – Installation Qualification, OQ – Operational Qualification, and PQ – Performance Qualification).
• Protocol mapping of requirements to test cases – An auditor may deem a system “has not been validated” if a requirement is discovered without a test case. 

A Traceability Matrix is a useful project management tool, to quickly determine completeness and coverage of a validation.

How to complete test cases in line with FDA CSVs.

To effectively complete a CSV, you need to have the right depth of understanding the intended use of the application, the SOPs surrounding it and the technical workings of the application.

To pass a test case audit, the following components are required:

• Test description and goal
• Steps for execution
• Expected results
• Actual results (Verbiage and screen shots suffice).
• Test pass/fail determination
• Tester signature and date
• Artifacts of the validation must be documented
• A configuration-management plan should be in place for all software.

The Consequences Of Not Completing FDA CSV Requirements

Failure to conform with the FDA CSV requirement can lead to regulatory action. Within the past year the following five companies were implicated and received warning letters due to non compliance with 820.70(i).

Obviously, no company wants to be named with a failure to adequately complete CSV. Med Device companies need to both uphold their reputations and continue to provide a well-conformed business etiquette to protect their products being released to market, and ultimately the end user.

At SPK, we have the right level of expertise to assist CSV compliance for our Med Device clients and ensure they avoid the 21 C.F.R. 820.70(i) based 483 observations and warning letters.