<img alt="" src="https://secure.shoo5woop.com/166337.png" style="display:none;">

The Datacor Blog

FDA Software Validation: Guide, Methods, Tools and Template

April 28, 2020 by Caitlin O'Donnell

Do you have strict requirements for quality and safety, with equally strict procedures required for meeting them? Is your industry regulated by the U.S. Food and Drug Administration (FDA)? FDA software validation is one way to ensure the tools you use when creating or distributing products are up to the task. 

But software validation isn’t only for companies who need to maintain compliance. It’s also a good business decision for any organization that wants to improve quality standards and prove critical software is operating the way it should. 

However, FDA software validation can be a complex process. The FDA requires that it be done, but it doesn’t tell organizations specifically how to do it. Their published recommendations are long and complex, and not all of the guidelines apply to every business — so how do you know where to start?

This article will walk you through the steps and documentation most organizations can use to validate their software, stay compliant and improve business processes. We’ll cover:

What is software validation?

Software validation is the process of establishing documented evidence that confirms a computer system has been installed correctly, will meet users’ needs and functions according to its intended use. 

What is FDA software validation?

FDA software validation is when an FDA-regulated company demonstrates and documents that their software can accurately and consistently produce results that meet predetermined guidelines for compliance and quality management. 

While the FDA offers recommendations, they don’t tell companies specifically how to validate their software, nor do they define what the results should look like. Instead, it’s up to each company to explain how they intend to validate their software, and to provide evidence for having done so in the way they intended. 

Even though software is typically purchased from a third-party vendor, it’s the company, not the vendor, that is responsible for validation. 

Who needs to validate software?

All companies in industries that have to comply with FDA regulations are legally required to validate any software that could impact product quality, safety or effectiveness. This includes manufacturers of food and beverages; pharmaceuticals; botanicals; medical devices; surgical instruments; dental equipment and supplies; ophthalmic supplies; orthopedics; diagnostic substances; and the parts or ingredients used to produce any of these goods.

However, validation is a good idea for any company that wants to improve quality, even if they’re not in a regulated industry. With FDA software validation, organizations can establish good practice (GxP) or good manufacturing practice (GMP) procedures: a set of regulations that help manufacturers minimize risk and ensure their products are being produced and distributed according to high quality standards.

How do you validate software?

datacor_services_FDA_validation_toolkit

Validating software involves recording evidence that proves a software system meets the proper specifications and quality attributes; that it’s been installed correctly; and that it will fulfill its intended use. 

During this process, you must validate the way you plan to use your software to produce regulated goods and/or perform related business processes. The goal is not only to prove the software will do what you want, but also to identify and mitigate problems that could negatively impact the production of regulated goods or their ingredients. 

FDA software validation requirements

The only hard-and-fast rules for FDA software validation are: 

  • The products you make and the processes you follow must meet the FDA’s standards for production and inventory management. 
  • Every step of the validation process must be documented. 

Since the FDA doesn’t know how your company intends to use its software, your validation plan must show them. That includes determining the specifications and quality guidelines that define success, as well as testing out common scenarios in which the software will be used to produce or distribute regulated products. 

The FDA has compiled comprehensive guidance for validation projects, but not all of the recommendations apply to all companies. Validation is based on the degree of risk involved with the product being produced: The greater the risk, the more of the FDA’s guidelines will apply to your validation process, and the more complex that process will be. 

For example, a company producing a pharmaceutical drug that will go directly to consumers assumes more risk than does a manufacturer producing an ingredient in that drug that is also used in lower-risk products. 

Software validation methods

The FDA’s guidance and requirements can seem overwhelming — but the task of following them can be simplified to not only stay compliant, but to help your business, as well. 

Most validation projects follow the same basic format, known as the “4Q Lifecycle Model.” It involves four stages of conducting tests and documenting the results: 

4Q Lifecycle Model

  • Design Qualification (DQ): This is typically supplied by the software vendor; it documents design specifications, software requirements, functional specifications, operational specifications and vendor attributes.
  • Installation Qualification (IQ): At this stage, your tests and documentation will confirm that the software has been installed correctly — according to your company’s specifications and user requirements, the vendor’s recommendations and the FDA’s guidance. This goes for all hardware, software, equipment and systems.
  • Operational Qualification (OQ): These tests establish confidence that the software will consistently perform the way it’s supposed to when operating within expected ranges. These tests and results can be supplied by the vendor, since they involve standard features and security capabilities.
  • Performance Qualification (PQ): This stage confirms that the software, as it was installed, will perform the way your company needs it to. Based on the processes and specifications outlined in the previous stages, your tests and documentation validate that the product being produced will meet FDA requirements for functionality and safety.

Steps to software validation

So, how do you put these methods into practice? Here are the common steps to software validation:

  • Step 1: Make a validation plan. Your validation plan is the “who,” “what” and “where” of your validation project. It documents and describes the software system; the environment it’s installed in; assumptions and limitations of the project; the testing and acceptance criteria you’ll use; the procedures you’ll follow; and who’s on the validation team and what their responsibilities are.
  • Step 2: Determine your system requirements (SRS). Outline the conditions that need to be in place for the software to perform the way you expect it to. These include infrastructure requirements — the necessary staff, facility and equipment — and functional requirements, including performance and security requirements, system and user interfaces and the operating environment. It may also include a risk analysis to identify any gaps in your functional requirements.
  • Step 3: Create a validation protocol and test specifications. Now you must outline what you expect the software to do and how you’re going to prove that it works. This involves creating a test plan and test cases. Your test plan documents why and how you’re going to test and verify the software. Your test cases will re-create common scenarios that prove the software can produce your regulated product or conduct a key business process. They are designed to uncover as many potential errors as possible and to demonstrate whether key features are performing properly.
  • Step 4: Conduct and document tests. Based on your test plan and test cases, this is where you actually conduct the tests and document the results, including successes, errors and failures. 
  • Step 5: Establish procedures and write your final report. After you’ve completed testing, you must establish and revise procedures for using the software. Writing, reviewing and approving your final validation report is the last step before releasing the system for use within the company. This should also include information on support, training, security backup and recovery.  

Software validation best practices

While the process you follow will depend on your industry and business processes, there are some best practices that apply to most organizations. These include:

  • Tie validation to change management. FDA software validation should be automatically triggered every time there is a change; for example, when a regulated system is installed, upgraded or updated. This helps you stay compliant, meet GxP or GMP standards and ensure any changes will still fit your company’s needs. 
  • Only test the features you’ll actually use. The validation process is complex enough; save yourself time and effort by only testing the functionality you need as part of your production, inventory or quality control system. Try to disable any unused features so users don’t accidentally stumble across them.
  • Validate the output of the software, not the software itself. This is a fine, yet important, distinction: You need to validate how your company will be using the features, not the tools themselves. Your tests should be designed to measure whether the software’s functionality can be used to produce a final product that meets your needs and FDA requirements — not to simply test whether a certain feature works. For example, if you’re using Excel, you would validate the completed spreadsheets.
  • Use vendor-provided documentation. Another great way to ease your burden is to use the validation documentation provided by most major software vendors. These resources offer a roadmap through the validation process and supply standard information. The vendor can validate functional specifications and the products of basic features — the OQ stage — but they can’t confirm the way your company plans to use the software (the PQ tests and results).

In the next section, we’ll outline what some of this vendor-supplied documentation looks like.

FDA software validation template

Documentation is the most important part of the software validation process. Many software vendors, such as Datacor, offer tools to assist with this. Datacor provides an FDA Software Validation Toolkit that guides you through your validation and implementation journey using an easy-to-follow format.

Here is a sample FDA software validation template:

  • Master Validation Plan: Outlines the scope of the validation project and the strategy for validating the software’s installation and use. Includes an overview of each process, the validation approach and the rationale for following it.
  • Design Qualification (DQ): Identifies key functionality, design specifications and software requirements.
  • Risk Assessment and Management: Documents the risk factors and mitigations associated with using the software to produce regulated goods.
  • Vendor Qualification (VQ)
  • Quality Control Protocol: Defines the quality control department’s roles and responsibilities in the validation process, including maintaining consistency with GxP or GMP and managing any relevant Standards of Practice (SOPs).
  • Hardware Specifications: Lists all hardware and software requirements.
  • Installation Qualification (IQ) for Install: Confirms that all hardware, software and networks have been installed and configured properly. 
  • Installation Qualification (IQ) for Upgrades: Confirms that all hardware, software and networks will be installed properly after upgrades are performed.
  • Operational Qualification (OQ): Verifies that the software is functional; key features will perform as expected; all necessary modules can be accessed; and that data can be viewed, uploaded and exported.
  • Performance Qualification (PQ): Lists the tests and results that confirm the software will perform as needed to produce the desired goods in compliance with FDA guidelines.
  • Support and Maintenance: Specifies who will be responsible for ongoing maintenance and support, as well as what their responsibilities are.
  • SOP and Change Control: Lists procedures for making changes that could potentially impact the finished product and includes any related SOPs.

Software validation for the chemical, manufacturing and cannabis industries

Manufacturers who directly produce goods for human or animal consumption, or for use in a health care setting, are subject to the most stringent FDA regulations. The chemical industry and process manufacturing industry, and the cannabis market in particular, have additional considerations that must be factored in when validating software.  

Again, the degree of validation required depends on the level of risk involved. Manufacturers producing finished products for consumption or for medical use — for example, a pharmaceutical drug — have to comply with a greater amount of FDA recommendations. 

Meanwhile, manufacturers who produce components of these finished products — e.g., one ingredient that is used in that same drug, but is also used in non-pharmaceutical products — have less associated risk. The scope of your validation project will depend on where your company falls on this risk-assessment scale. 

Ingested products involve some of the greatest risk; it’s crucial these goods be safe, especially in this age of heightened health awareness. As a result, the FDA is constantly expanding its requirements to encompass more consumable products as new ones come on the market and become popular. 

Special considerations for the cannabis market

The cannabis industry is one of the newest entrants to the consumable-goods market, along with vape and nutraceutical products. Given this, not all cannabis companies may be currently required to comply with FDA regulations — but it’s only a matter of time. 

There are many levels of testing and analysis required in the cannabis industry to ensure safety and quality, especially for medical-use products. Currently, there are no national or global regulation standards in this emerging market, given that sale and distribution is not yet legal at the federal level in many countries or within many U.S. states. 

However, there are an ever-growing number of states and countries legalizing or decriminalizing use. As a result, companies and consultancies are beginning to implement GMP to ensure safe use, replicable quality and compliance in the cannabis industry. 

If you’re a cannabis producer, software validation is a great way to create, test and refine standards and practices and raise the bar for your products. Not only will it keep you compliant down the line, saving you headaches and potential fines — it will also ensure that you’re following best practices, your software is working correctly and you’re producing the safest, most effective and highest-quality goods for your customers. 

Cannabis growers and producers should validate any software system that might affect the quality of their product according to GMP standards. This includes manufacturing, production, inventory management, packaging and labeling and maintenance processes and functionality.

Key functionality for chemical and process manufacturers

For chemical and process manufacturers, tracking lot data from cradle to grave is the most crucial set of data that needs to be validated. When there is a recall, you need to be able to track the lot where the problem originated, as well as to retrieve records of everywhere that lot was consumed and every purchased product it went into. 

The FDA requires that you validate your ability to perform a recall and get the word out to buyers, which means testing your software’s inventory management functionality. Your PQ documentation should focus on the ability to record and retrieve purchasing and manufacturing transactions; to record and provide an audit trail for every inventory transaction; and to control access to inventory changes.

If you produce or distribute goods in Europe, there are additional rules to comply with: The Registration, Evaluation, Authorization and Restriction (REACH) regulation requires chemical producers and distributors to provide safe handling information on chemical properties and register it in a central database. Make sure to validate processes for compliance with these standards, as well.

As governments around the world place greater responsibility on companies to raise product quality, data accuracy and product and practice standards, software validation provides a path to prove you’re on the right track. By following the tips provided and using vendor-supplied documentation, such as Datacor’s Software Validation Toolkit, you’ll have a framework to prove that your data and processes are accurate; workers are following the proper practices; and you’re being a good steward of the industry — all while creating the best quality products. 

Of course, you also have to start with a comprehensive software system that will meet all of your company’s needs. Datacor ERP is a robust, integrated enterprise resource planning (ERP) system that helps businesses in any industry centralize and streamline processes, but is designed with chemical and process manufacturers in mind. Get the Toolkit here, or learn more about what Datacor ERP has to offer.

Topics: software validation, FDA, Software, Datacor ERP


Caitlin O'Donnell

Written by Caitlin O'Donnell

Schedule a Free Consultation

Datacor offers products and services designed specifically for process manufacturers and chemical distributors. Contact us to learn more about our products and services. Call us now at (973) 822-1551 or fill out the form to the right.