For decades, pharmaceutical and medical device companies have operated under the assumption that they must document and validate each and every software used in their processes. The concern was that if they didn’t, they would be at higher risk for potential audit observations and 483 warning letters. The purpose of this article is to provide new details on the transition from Computer System Validation (CSV) to Computer System Assurance (CSA).
What The Future Holds – The Transition From CSV to CSA
This approach to computer systems validation (CSV) aims to ensure compliance with 21 CFR Part 820.75, which relates to process validation. Unfortunately, the unintended result has been a slow adoption of technology software solutions that improve efficiency, product quality, and patient outcomes.
Computer systems can be used as tools to achieve many goals–such as improving efficiency and productivity or reducing costs–but they also pose certain risks:
- The information they contain could be inaccurate or incomplete; this could lead to incorrect decisions being made by people using them (e.g., doctors prescribing medicines based on wrong dosage information).
- Accessing sensitive data without authorization can put individuals at risk (e.g., hackers stealing people’s personal information).
Documentation to capture this hasn’t always been consistent or agreed upon across the industry. The GAMP forum, along with the International Society for Pharmaceutical Engineering (ISPE) introduced the first edition of Good Automated Manufacturing Practices (GAMP) in 1994 to address this.
Good Automated Manufacturing Practices
GAMP defined a clear set of industry best practices to ensure regulatory compliance and utilizes the V-Model Software Development Life Cycle (SDLC). The V-Model gives us a clear path to validation, that includes verification activities for each level of specification.
How do we know which deliverables are required? Before beginning a new project an assessment of risk for the system must be completed and the system must be given a GAMP category classification.
In the most recent version of GAMP, we are given the following classifications:
By identifying the risk and the GAMP category, we can implement our own internal processes/procedures that indicate the level of validation and deliverables required for the project. CSV is required by regulatory agencies to ensure:
- Data Integrity
- Product Quality
- Patient Safety
If the validation process isn’t documented appropriately then an organization risks findings during an audit that can have an impact across the organization. Ensuring your systems are validated appropriately can mitigate many of these issues and ensure your systems/products are reliable and safe.
Which regulatory agencies require Computer System Validation?
Computer System Validation (CSV) is required by regulatory agencies, including the FDA, EPA, and NRC, to ensure that the computer systems used in regulated industries, such as medical devices and drugs, pesticides and chemicals, or nuclear power plants, are safe, secure, and reliable. A crucial aspect of the regulatory requirements involves the Transition From CSV to CSA, emphasizing the need for a smooth shift in validating computer systems.
Which systems do (and don’t) need to be validated – including off-the-Shelf
As with most things in life, it’s important to know what you’re getting into before you go down that road. When it comes to validation, there are three main types: off-the-shelf (OTS) software, SaaS applications and cloud services (software as a service).
Spreadsheets also fall into this category–but they’re not exactly like OTS or SaaS. Spreadsheets are typically used by non-programmers who have no formal training in computer science or engineering; they’re often used by people who don’t even have a college degree!
SaaS, cloud-based and spreadsheets? In our next upcoming articles, I explain how these systems work and how they can be used to validate your system. The first article will describe the off-the-shelf, SaaS, cloud-based and spreadsheets. The second article explains what is needed in the validation plan.
What are the consequences of not validating systems?
Not validating systems, including the transition from CSV to CSA, can have a range of consequences. You may be unable to meet regulatory requirements and face penalties, such as fines or being forced to shut down. Your business could also suffer from reputation damage, especially if you are a regulated organization that is publicly visible.
What are the steps you need to take to implement a computer system validation program? You can begin to develop your computer system validation program by establishing a process to validate systems and developing a checklist that will help you conduct the validation.
Conducting gap analysis will help identify where your systems are lacking, so you can create plans to address those gaps in the future. Implementing these new processes and monitoring results is important as well.
What the future holds – Transition from CSV to CSA
The FDA’s new approach to CSV, Computer Software Assurance (CSA), represents a step-change in computer system validation, placing critical thinking at the center of the CSV process, as opposed to a traditional almost one-size-fits-all approach.
The transition to Computer System Assurance methodology supports product quality and patient safety by emphasizing the use of critical thinking and digital technologies over burdensome testing and documentation. By streamlining the validation process, CSA can help you achieve faster deployment and ROI.
Following the launch of their ‘Case for Quality‘ initiative in 2011, the FDA was uncertain why so few companies were investing in automated solutions and why so many continued to run long-outdated versions of software.
The initiative, which set out to study quality best practices in medical device manufacturing, found that the burden of Computer Systems Validation (CSV) deterred technology investments and, as a result, inhibited quality best practices, emphasizing the need for a seamless transition from CSV to CSA.
On learning that the burden of CSV was holding companies back from realizing their investment in technology, the FDA decided to partner with the industry to strike a balance between promoting automation and value-added CSV activities.
The FDA aimed to improve quality, remove non-value add activities, and focus testing on high-risk areas, therefore reducing validation cost and time by focusing on the software’s impact to patient safety, impact to product quality and impact to quality system integrity (Direct or Indirect system).
This transition in approach to computer system assurance aims to realign effort to planning and preparation first, then defining the testing to be performed, and finally test execution and documentation.
