3 FDA Guidance Documents That Shaped Today's Computer System Validation

By Richie Siconolfi, Richard M. Siconolfi, LLC

Regulated industries, such as pharmaceuticals, medical devices, and biotech, have been validating their computerized systems to meet government regulations efficiently and effectively since the early 1980s. In support, the FDA and global regulatory agencies have promulgated regulations, directives, and guidance documents. Relative to the U.S., there are three FDA guidance documents that allow the regulated industry to take risks in validating computerized systems. Understanding the history of such guidance can help industry contextualize today’s approach to computer system validation (CSV).

Guidance Documents That Framed Current Validation Practices

FDA’s General Principles of Software Validation, Final Guidance for Industry and FDA Staff¹

This 47-page guidance document laid out the basic principles — specifically, citing a risk-based approach — that should be used in validating a computerized system. While the FDA intended this guidance document for the medical device industry, its principles and advice are still a good guide for developing and following good validation practices. Key to this guidance document are the many references to computer system complexity, reflecting the era in which it was published. The FDA published this guidance document in 2002, just as industry was coming out of the dot.com collapse, Microsoft had just released Windows XP, and IBM was introducing a lower-priced entry-class mainframe that changed the economics of mainframe computing. Medical device companies have been developing a process to assess a computerized system’s risk; the rest of the regulated industries are now just entering into this risk area.

Therefore, the guidance importantly states, “Validation coverage should be based on the software’s complexity and safety risk – not on firm size or resource constraints.”

Defining a software’s complexity and safety risk may take a team composed of the business owner, information technology (IT) professionals, subject matter experts (SMEs), and quality assurance professionals (QAPs). A common achievable goal can unite these experts. For example, a goal could be as simple as documenting requirements, developing test cases, and moving the computerized system into production.

The FDA, later in the guidance, provided more direction and substance by outlining major areas to control validation, stating, “The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use.”

The validation activities, tasks, and work items (e.g., validation deliverables) could be part of a standard operating procedure, with explanations of the validation deliverables required during a validation event.

Section 4.8 Validation Coverage, as quoted above, continued to state that if the risk has been determined to be low, only baseline validation may be conducted, which means reducing the testing and the documentation to prove the computerized system is operating as intended.

Although this guidance successfully introduced the concept of a risk-based approach to validate computerized systems, the regulated industry beyond the medical device industry was slow to recognize and adopt this recommendation.

Part 11, Electronic Records; Electronic Signatures – Scope and Application

The FDA release of Part 11, Electronic Records; Electronic Signatures – Scope and Application² guidance document in 2003 reminded the regulated industry to take a documented risk-based approach to validation. It reintroduced the concept of a documented risk-based approach to business owners, IT owners, SMEs, and QAPs assigned to develop an approach that verifies the intent of the computerized system and allowed the regulated industry to “test” to its assigned risk level.

Because traditional methods of risk assessment did not easily apply to computerized systems, business owners, IT owners, SMEs, and QAPs had to think critically. Risk can be broken down into probability and severity. ICH Q9, Quality Risk Management³ defines risk as the combination of the probability of occurrence of harm and the severity of that harm.

FDA Draft Guidance Document on Computer Software Assurance for Production and Quality System Software

It took another 19 years before the FDA issued its third guidance document on a risk-based approach to validated computerized systems. The FDA released this latest document, FDA Draft Guidance Document on Computer Software Assurance for Production and Quality System Software⁴, on September 13, 2022. While regulated industry waits for the final release of this guidance document, many SMEs and QAPs are already implementing these guiding principles, as well as presenting webinars, delivering presentations at professional meetings, and authoring articles on their use.

Past And Present CSV Deliverables

The number of suitable validation deliverables has changed over time. Regulations and guidance documents necessitated some changes, while others were due to changes in technology or the introduction of new concepts, such as software as a service (SaaS) and cloud service providers (CSPs).

Preceding the above FDA guidance was a meeting in October 1987 at which the FDA assembled 66 professionals at the Red Apple Conference Center in Heber Springs, Arkansas, to author a book on CSV called Computerized Data Systems for Nonclinical Safety Assessment (commonly known as “Red Apple”)⁵. This five-chapter book, written by government, industry, and academia professionals, established a new approach to regulated CSV. The book includes topics on validation and verification principles that are still used today, including these validation deliverables:

• initiation
• requirements analysis
• design specifications
• programming and testing
• system integration and testing
• system validation testing
• system release
• operation and maintenance.

Over time, these validation deliverables have changed, some in name, others in function, and some in both name and function. The point is validation deliverables can be combined or simplified, or both. The three FDA guidance documents described above have allowed the regulated industry to add or subtract validation deliverables during the course of establishing or revising a risk-based approach to validation. In some cases, validation deliverables have been combined into one document. An example of the latter was the combination of the requirements analysis deliverable with the traceability matrix deliverable. This combination proved to be effective and efficient, allowing the tracing of requirements to specific test scripts in a single document.

The case for adding a validation deliverable based on these guidance documents proved to be a timesaver, too. FDA’s Part 11, Electronic Records and Electronic Scope and Application² guidance document recommended to industry to develop a “Part 11 Gap Assessment” process to prove that a regulated computerized system complied with 21 CFR Part 11⁶. This allowed industry to take documented risks.

Since then, two more validation deliverables have been added to benefit the industry. The first was the vendor assessment process, in which the business, IT, SMEs, and QAPs assess a vendor’s software development life cycle, knowledge of applicable regulations, and the ability to include the Part 11 regulation’s technical requirements in a software system. The benefit of this assessment was twofold: (1) it confirms whether the vendor has a documented software development life cycle; and (2) it allows industry to reference the vendor’s validation deliverables and possibly reduce the number of validation deliverables and testing by focusing on how the client uses the system. This was a win-win for the vendor, the industry client, and the government agencies. It guaranteed that the vendor and client established a partnership and relied on each other for compliance. This vendor assessment report is essentially a validation deliverable that should be reviewed and updated based on the system’s risk level assigned by the client and the frequency of software releases, i.e., change controls.

Another validation deliverable is an assessment of the CSPs conducted by either the vendor or the client. If it is conducted by the vendor, the client simply needs to review the summary of the assessment report and document in one of their validation deliverables, such as the validation master plan, validation event protocol, or the Part 11 Risk Assessment document. If the vendor did not conduct the CSP assessment, then the vendor and client can discuss the best way to fulfill this expectation.

Summary

Today’s risk-based management approach to computer software validation has foundations in three guidance documents, one risk management guideline, and a book written by government, academia, and industry professionals on the current concepts of validation over several decades. Today, the evolution of CSV continues. As such, it should address how the addition or removal of validation deliverables will benefit the validation process. It should also recommend how some validation deliverables could be combined into one document. The evolution of validation will continue to challenge with the introduction of regulated AI algorithms and future changes in technology and hardware.

To learn how to build a risk-based approach for CSV, follow up with “Developing A Risk-Based Model For Computer System Validation.”

References:

1. FDA’s General Principles of Software Validation; Final Guidance for Industry and FDA Staff, 2002
2. FDA’s Part 11, Electronic Records; Electronic Signatures – Scope and Application, 2003
3. ICH Q9 Quality Risk Management, finalized by FDA May 2023
4. FDA Draft Guidance Document on Computer Software Assurance for Production and Quality System Software, 2022
5. Computerized Data Systems for Nonclinical Safety Assessment (commonly known as Red Apple), 1988.
6. FDA 21 CFR Part 11, Electronic Record; Electronic Signature Rule, 1997.

About The Author:

Richie Siconolfi earned a BS in biology (Bethany College, Bethany, WV) and MS degree in toxicology (University of Cincinnati College of Medicine, Cincinnati). He has worked for The Standard Oil Co., Gulf Oil Co., Sherex Chemical Co., and the Procter & Gamble Co. Currently, Richie is a consultant in computer system validation, Part 11 compliance, data integrity, and software vendor audits (“The Validation Specialist”, Richard M. Siconolfi, LLC). Richie is a cofounder of the Society of Quality Assurance and was elected president in 1990. He is a member of the Beyond Compliance Specialty Section, Computer Validation IT Compliance Specialty Section, and Program Committee. Richie also is a member of Research Quality Assurance’s IT Committee and Drug Information Association’s GCP/QA community. The Research Quality Assurance professional society appointed Richie to fellow in 2014.