1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

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

Published by Chris McHale
on March 21, 2022

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).

      Company Issue Date Warning in relation to Example used
      USHIO Europe B.V. 12/03/2019 Failure to validate computer software for its intended use according to an established protocol, as required by 21 CFR 820.70(i). Firm’s software used to operate the Isolde-HPA pumping, filling, and pinching machines with machine numbers 2281 and 2282 has not been validated for its intended use. Your firm stated that the pinching, pumping, filling, and sealing processes can affect the UV output of the finished lamps.
      American Contract Systems, Inc. 11/09/2019 Failure to adequately validate computer software used as part of production for its intended use according to an established protocol, as required by 21 CFR 820.70(i). Observed firm’s (b)(4) software system has not been fully validated per the Process Validation Procedure (PV-01). There was no protocol specific method used to document acceptance criteria and how the validation will be completed in the Software and Systems Validation Protocol (b)(4)
      • Observed (b)(4) software design changes were implemented from 08/1/11 to 4/5/19, with changes affecting critical process parameters such as (b)(4). There is no documented evidence the design changes were verified and/or validated prior to implementation. Also, there is no evidence that (b)(4) testing was done after the implementation of each software code changes.
      • Firm’s (b)(4) software does not display error codes to the operators when process parameters are not met. Software changes (CR-04, CR-06, and CR-08) were requested to show visible error codes when the (b)(4) process parameters were not within specification.
      • There is no documented evidence that software (b)(4) testing and/or (b)(4) testing have been conducted for the firm’s (b)(4) Sterilization units ((b)(4)).

      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.

       

      Latest White Papers

      Infrastructure as Code: Top 10 Do’s and Don’ts

      Infrastructure as Code: Top 10 Do’s and Don’ts

      The ability to scale a business is no longer solely defined by manpower, money, and on-premises infrastructure. Infrastructure as Code (IaC), in fact, has revolutionized the ability to scale and grow businesses globally. But what is IAC? How can migrating to it enable...

      Related Resources

      Protecting Device Storage Using Windows UWF

      Protecting Device Storage Using Windows UWF

      The Unified Write Filter (UWF) is a Windows native feature that ensures a system’s data remains as an unmodified, secure baseline.  Data can be changed by a Windows UWF system user. However, the changes do not persist after a restart. In fact, changes are discarded...

      Single Pane of Glass Dashboards: What are they?

      Single Pane of Glass Dashboards: What are they?

      There’s simply too much information.  We all know this.  So how can the “single pane of glass” (SPOG) dashboard simplify quantitative data? And why is data driven analytics of interest to companies? Every day, more data arrives in our inbox – text messages, reports,...

      DevOps and CloudBees Accelerate Banking Innovation Part 2

      DevOps and CloudBees Accelerate Banking Innovation Part 2

      In Part 1 of this article, we talked about the banking innovation industry threats and market conditions. We discussed how DevOps and CI/CD tools can help to mitigate threats. We also discussed why tools like Jenkins, CloudBees CD/RO and CloudBeesSoftware Delivery...