System validation, including validation of software for its intended use, is essential to GMP compliance for both drug and biologics manufacturers because computer systems are used in all phases of manufacture and analysis. Current enforcement actions identify how firms fail to meet existing drug GMPs (i.e., predicate rules) when using electronic systems and electronic records.

The question is asked, “why doesn’t FDA commonly cite ‘lack of software validation’ as a deficiency” to drug manufacturers? They did cite failures in, or lack of computer system validation, in warning letters in 1999 and 2000 (yes, the topic extends that far back) but FDA’s thinking about the issue has matured over the intervening years, and they have refined their approach.

Predicate Rules

In 2010 FDA stated they would focus on electronic record compliance to predicate rules. This approach is more nuanced, and cites failures in components and features of computer system validation rather than simply saying that the entire system isn’t validated.

In addition, FDA cites lack of procedural controls in the generation, processing, review and archival of data. Procedural controls are key components of ensuring that a computer system is used in a way that is compliant with regulations, consistent with its intended purpose.

For example, systems may be configured with audit trails enabled and access limited by roles and responsibilities. However, if audit trails are not reviewed and data are not backed up then the system is not implemented consistent with its intended purpose. Thus, completing the technical aspects of system validation is necessary but not sufficient to compliant operation.

Many of the deficiencies cited address failure to establish and implement adequate configuration specifications, many of which contribute to control of the system.

Following are examples of problems that result from failures in computer system validation.

Regulation 211.194

Requirement

Laboratory records shall include complete data derived from all tests necessary to assure compliance with established specifications and standards.

Examples

“Our investigator documented multiple examples of falsifying laboratory records. Your quality control laboratory employee stated that he fabricated laboratory data for untested finished drug products by manipulating electronic laboratory records. For example, he changed the file names for test results of previously tested drugs so that the file names appeared to reflect the results of other lots of product.” (WL issued 22/2018)

“We found three electronic data files in the electronic recycle bin of the standalone HPLC system you used to test finished drug product (b)(4) spray. Because this instrument lacks back-up and audit trail capabilities, we could not determine how frequently test data obtained prior to “official” batch testing was discarded. You were unable to explain why these electronic files were deleted.” (WL issued 2/23/2018)

“During our inspection, when we sought to reconcile assay results reported in the quality control data package for a released batch with the underlying electronic data, you responded that you could not provide the electronic data from laboratory analyses on this equipment for the above period of several years. You explained that the electronic data in question had been deleted by accident and was no longer available…. electronic data had been downloaded to a “mobile hard disk for backup” and that you would be able to recover the data after you have upgraded your HPLC software. However, you did not include evidence to support recovery of deleted electronic data or demonstrate how you will prevent such deletions from recurring in the future.” (WL issued 4/19/2018)

Regulation 211.68

Requirement

Appropriate controls shall be exercised over computer or related systems to assure that changes are instituted only by authorized personnel.

Examples

“Laboratory equipment used to generate analytical data for release purposes lacked restricted access. For example, analysts shared usernames and passwords, and all users had administrator rights that permitted them to delete or modify files in high-performance liquid chromatography and gas chromatography equipment. You had no mechanism to facilitate traceability of the individuals who changed, adjusted, or modified data generated by computerized systems” (WL issued 2/2/2018)

“Laboratory equipment used to generate analytical data for batch release purposes by your quality unit lacked restricted access.” (WL issued 4/9/2018)

“…audit trails in your standalone instruments ((b)(4) high performance liquid chromatography systems, (b)(4) gas chromatography systems, and (b)(4) infrared radiation system) were not enabled. You also did not have other mechanisms for recording and monitoring any changes to data generated on these instruments. Your firm backed up electronic data from these instruments to a portable drive (b)(4). However, the drive was not password-protected, and it was stored in an unlocked drawer in an unlocked office…. operators had full system permissions, including the ability to modify and delete files. For example, our investigator found files related to system suitability tests for (b)(4) in the recycle bin folder on the computer connected to high performance liquid chromatography system.” (WL issued 5/14/2018)

Reviewing the Examples

In the above cases, we could reach the conclusion that the computer system is not validated for its intended use which would require controlled access, enabled audit trails, inability to routinely delete data and privileges within the system limited by job description and role. Simple ‘lack of validation’ is an easy observation to make during an inspection but not very helpful to the auditee, nor is it consistent with FDA’s stated approach. It’s much more valuable to the auditee, or inspected site, to identify the deficiency with appropriate granularity and detail citing the predicate rules that are not followed, along with the consequences of the deficiencies.

All of these aspects should be established as part of configuration specifications and tested during system validation. Configuration specifications in these cases were inadequate and thus we can conclude that the system was not validated for its intended use.

Conclusion

Software is used extensively in both the drug and device industry for computerized systems in manufacture and testing activities along with being used for building management control and equipment management control. It is external to the drug itself (except for some interesting possibilities that are under development), unlike some software that is an integral component of programmable devices.

GMP/GCP compliance failures in the drug product segment are no longer identified as the ‘software not being validated for its intended use,’ but rather the deficiencies are now linked to the predicate GMP requirements based on FDA’s stated focus in 2010. Much of the inspection focus is on whether systems are configured and operated in a way that prevents undetected deletion or modification of data, ensures that all data are available for review and that access to such systems is limited to those with proper authorization.

While FDA could simply cite that systems are not validated for their intended use, this provides no granularity or detail that can be acted upon by the industry they regulate nor does it provide linkage to the most relevant predicate rules.