6 Software Validation Best Practices for Regulated Industries

Software validation, also called “computer system validation”, is a process that confirms a piece of software is designed for and satisfies its intended purpose. It involves reviews during software development or selection, and systematic installation procedures and testing during deployment. Validation is a basic part of software quality control, along with software verification. In software verification, the software is checked against a set of predetermined specifications. 

For software used in heavily regulated industries — for manufacturing automation, process control, or environmental monitoring, for example — validation should follow an IQ/OQ/PQ quality assurance framework (installation, operational, and performance qualification). This provides a step-by-step approach to ensure no critical aspects of validation are missed. We’ll get into the specifics of how software validation is related to IQ/OQ/PQ later in this article. 

Software validation presents unique challenges relative to quality management in other areas. For one, the scope of a software validation project can be unclear and difficult to manage, because of the wide range of potential users, diversity of potential features, and the unpredictability of the environment the software will be used in. Furthermore, software updates and changes must be accounted for as part of continuous validation. In this article, we’ll talk about the best practices for addressing these challenges, with a focus on highly regulated industries, like pharmaceutical manufacturing and distribution, medical devices, and aerospace. 

How Software Is Regulated

In the US, software used in the pharmaceutical and medical device industries is regulated by the FDA, through rules listed in CFR Title 21. Generally, software used for electronic record-keeping and electronic signatures, which applies to quality management systems, is covered by 21 CFR 11. This states explicitly that validation is required “to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records”. 

The regulations for validation of software related to medical devices are more detailed. Specifically, 21 CFR 820.30(g) covers design validation of software used in medical devices,  which “shall include software validation and risk analysis, where appropriate.” 21 CFR 820.70 further regulates software systems used in manufacturing and quality control. Software validation is also part of the global medical device quality standard ISO 13485, which is similar to 21 CFR 820 and is also used by the FDA. Software validation is also discussed in detail for operations involving human cells, tissues, and cell- and tissue-based products, in 21 CFR 1271. 

In the EU, the analogous regulations are covered in Annex 11 of the EudraLex Vol. 4, with inspections coordinated by the European Medicines Agency (EMA).

Software used in production and quality management in the aerospace industry, which is covered by AS9100, and other general manufacturing environments, such as those using the more general ISO 9001 standard, should also be validated through an IQ/OQ/PQ and risk analysis process. Note that software used in mission-critical aerospace applications is covered by a separate standard, DO-178C. 

In general, the laws and standards listed here are fairly non-specific, and exactly what activities should be carried out in the process of software validation is left to the regulated entities. To fill some of these gaps, additional guidance can be used. 

One example of this is the “ISPE GAMP 5 Guide: A Risk-Based Approach to Compliant GxP Computerized Systems”, published by the International Society for Pharmaceutical Engineering. This guide, and the ancillary good practice guides, also published by ISPE, provide a more detailed approach for software validation in GxP. A second example is the ISO/TR 80002-2:2017 document, which covers validation of software used in the quality systems related to medical devices. There are several other comprehensive guides in this area, for example the Software Engineering Body of Knowledge (SWEBOK), however this guidance is more general to all software development and testing. 

Since it is a fairly common situation, these regulatory bodies offer specific guidance for the use of commercial off-the-shelf (COTS) software from third party suppliers. We’ll discuss that in more detail later in the article. 

It is important to note that the landscape for software validation in FDA-regulated industries is likely to change in the next several years. The FDA is expected to announce revised guidelines for software validation in 2020, which will focus more on an approach termed “computer software assurance”. The updated regulations should allow for a more streamlined process, place less emphasis on exhaustive documentation and strict validation practices, and better reflect modern software and automation.   

Why Software Validation Is Important

The process of software validation is highly detail-oriented and can be labor intensive, but there are a number of reasons why it is important and beneficial to an organization:

• • It provides a tested, step-by-step process to ensure that software is correctly selected and deployed, so that there are fewer issues that require correction later  
  • It encourages alignment between the designers or purchasers of software and the end users
  • Extensive records are generated as part of the process, which makes diagnosing and troubleshooting issues later on more straightforward
  • Following validation procedures is required for regulatory compliance in some industries. In the following section, we’ll cover them in more detail
  • Validation provides a system to make sure the implementation of software upgrades and patches do not impact product quality

Industries Where Software Validation Is Necessary

Software validation is frequently needed in the following industries:

• Medical devices. FDA regulations divide the software used in medical devices into two groups: software used in the device itself (or as the device), and software used in manufacturing or quality control. In both cases, validation is required by law, because of the possibility that software quality issues can propagate to issues that would endanger the effectiveness of the device or patient safety. 
  
  Specifically, 21 CFR 820 covers the methods, facilities, and controls used for “design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use”. An example of a software system that requires validation in this context is the system used for statistical process control of a manufacturing line.
  
  This is an area where issues are frequently encountered during FDA audits. From 2015-2019, over 150 citations were issued by FDA inspectors related to software validation issues arising from noncompliance with 21 CFR 820 regulations. 
  
  
• Pharmaceutical manufacturing, storage, and distribution. Similar to medical devices, software validation is needed to ensure product quality and safety. In this area, the focus is on software used in manufacturing and quality control of the product and intermediate materials. An example of the type of software that would need validation in this area is the computer system used to monitor and control environmental conditions in an area where temperature- or humidity-sensitive drugs were being stored. 
  
  
• Laboratories involved in the research, development, or testing of medical devices and pharmaceuticals. Here, software systems should be validated to ensure records are accurate and complete, for example records pertaining to drug trials. Validation is required here since these records will be used by regulators for determining the safety and effectiveness of the materials under trial or production. 
  
  
• Aerospace manufacturing, repair, and distribution. This area is covered by the AS9100, AS9110, and AS9120 standards, where the overall goal is reliability and safety of aircraft and related systems. As with the other regulated industries, software validation here should be guided by a risk-based analysis.  
  
  
• General manufacturing environments. Even in industries not required by law to do so, software validation may be beneficial, depending on the level of risk involved. Validation of in-house software used for calculations and process control, for example, is part of the ISO 9001 standard. 
  
  

Software Validation Best Practices

The details of the software validation process are dependent on the environment in which the software will be used and the risks involved. However, there are a number of practices that can help a validation project go as smoothly as possible. 

1. Use a risk-based approach when making a plan for software validation. In other words, place more emphasis and more stringent requirements on software that, if it does not perform correctly, poses the most risk to the product. This favors a focus on the most critical aspects and features of the software. 
   
   
2. Take the time to develop a comprehensive set of requirements for the software, ensuring that they cover the full range of possible situations and users/stakeholders. Using this set of requirements as a basis for software development, selection, and testing will simplify the qualification process. This is sometimes referred to as the “design qualification” or DQ stage, and the requirements are known as the user requirements specification or URS. 
   
   Depending on the situation, it may also be useful to develop several test cases to use during the operational qualification stage. This is a point at which consultation with a vendor with experience in software testing or validation can be helpful. 
   
   
3. The software should be deployed using an IQ/OQ/PQ framework typical of validation in GxP
   
   
   • IQ (installation qualification). The hardware system is checked to confirm it meets the minimum requirements, and the software is installed and configured using the procedure given by the software supplier or internal design team. Another important component to this stage is recording any information about the software system, including associated hardware, such as the serial number, version, or release date. User manuals should also be collected and filed. 
     
     
   • OQ (operational qualification). The functionality of the software is tested against the Functional Specifications (FS). This can take the form of several different types of tests, like functional testing of each individual module, or testing of the integrated software system. The testing plan should be adapted to the specific software system, which is why it is important to plan and document it carefully prior to deployment.   
     
     
   • PQ (performance qualification). PQ testing is tested against the requirements listed in the URS.  Operation of the full software system in the actual use environment. This involves use of the software by the end users, under a representative range of conditions and also tests unique business processes built within configurable software. 
     
     
   • The theme running through all three stages is documentation. All validation activities should be completely documented using ALCOA guidelines (Attributable, Legible, Contemporaneously recorded, Original or a true copy, and Accurate)
     
     
4. Have a plan in place to trigger software re-validation or continuous validation as part of your overall quality management system. An example of triggering events would be the release of a new software version or patch, or the addition of new functionality. The criteria for a triggering event should be selected using a risk-based analysis. 
   
   
5. Stay up to date with the evolving regulations and guidance around software validation. As discussed earlier in the article, changes to the FDA approach in this area are expected in the coming year. 
   
   
6. To manage the scope and cost of these activities, consider working with an experienced vendor to implement COTS software. This has two potential benefits: 

• 1. The vendor will have performed much of the work by designing the software and a test plan with validation in mind
  2. An experienced vendor will be able to assist in risk assessment, auditing, and other validation activities

On that last point, the FDA has anticipated cases where regulated companies will be using software provided by third parties, for example, the DicksonOne cloud-based environmental monitoring system. In this situation, the ultimate responsibility for validating software still rests with the regulated company. However, the validation process can be streamlined significantly by:

• • Validating only the specific parts of the third party software that you will be using
    
    
  • Relying on the vendor-supplied documentation as a starting point for validation. For example, by comparing the specifications and capabilities of the software to your individual requirements. This might also include an audit of the software supplier
    
    
  • Clearly agreeing on responsibilities of each party

These recommendations are discussed in the FDA document General Principles of Software Validation, section 6.3, and in Annex 11 of EudraLex vol. 4. In cases where the vendor cannot provide full life cycle documentation, or when auditing is not possible, additional functionality tested is needed. This can be performed by the regulated company or by an independent testing lab. 

Conclusion

Software validation is an important part of the implementation of computerized system control in manufacturing, environmental monitoring, or any other system that can impact product quality in highly regulated industries, or industries where product quality is a critical customer requirement. It is a detail-oriented process, but when done right, it has benefits for regulatory compliance, customer satisfaction, and operational efficiency. 

Software validation follows the IQ/OQ/PQ framework that is well known to those familiar with GxP. However, it is expected to evolve in the coming years in response to the changing use of software in manufacturing and quality systems. In many cases, it is beneficial to work with an experienced vendor to provide software and validation assistance. 

About the author: Before coming to Dickson, Director of Services Antoine Nguyen spent more than 18 years in quality and validation roles in the pharmaceutical and medical device industries.