Coping with Scoping a CSV Audit

You know you need a computer systems audit but that’s literally the extent of what you know.

Has this ever been you?

Yes, you use computers on a daily basis, and you may even use the system that needs to be audited. But you don’t spend your day thinking about where all the system components are located, how services and software are combined, and what 21 CFR Part 11 requirements apply. Terms like “cloud computing” make you feel slightly queasy. You’d rather get a root canal than discuss “distributed processing.” Your expertise is in manufacturing. Or clinical research. Or non-clinical lab operations. And somehow it’s your job to make sure an effective and properly-sized system audit is conducted. Great.

Yet your quality assurance colleagues -- whether they’re from your internal QA department or an external compliance company -- need your input. They need to understand what software is being purchased, what services are being contracted, how and where components of the system are being implemented, and how the system will be used.

The good news is that the QA auditors can help you. They know that FDA favors a risk-based approach to validation and 21 CFR Part 11 implementation, and they even know what that means. They love to talk about configuration management and change procedures. They love gathering evidence that demonstrates your system works correctly and is in a state of control, and they know what rocks they should look under to find and fix vulnerabilities.

What follows are examples of the types of information you need to convey to QA – and that they should be asking you about – to properly size and scope an audit.

How Do You Plan to Use the Quality System?

Suppose you need to audit the supplier of a new document management system. The first thing an auditor would need to understand is how you plan to use the system. How mission critical are the documents you’re looking to store? Are they covered under regulatory scope? Maybe you plan to use the system as a collaboration environment for developing new SOPs. That would require a relatively low level of scrutiny, especially if you only plan to print out the finalized documents for wet ink signature. (As a point of comparison, if you plan to use the system to finalize SOP approval, the auditor would need to check that Part 11 requirements for electronic signatures are properly implemented.) What if the document management system will be housing critical GxP documents, such as trial master files, master schedule sheets, or master batch records? In these cases, the validation would have to be far more thorough, and Part 11 electronic record features, such as audit trails and archiving functionality, would have to be

Here’s another “use” example. Similar to the term “document management system,” the term “analytics system” does not tell the whole story. From a business perspective, study start up (SSU) metrics may be vital for sponsors and CROs to collect and analyze. But since they have no regulatory impact, the FDA would not require an SSU analytics system to be validated. (That doesn’t necessarily mean you might not want to, though.) On the other hand, a system that performs statistical analysis on study data for regulatory submission is about as critical as it gets, and would require thorough validation and Part 11 implementation. Other analytics systems, such as dashboards that pull data from critical systems, might fall somewhere between these two extremes.

What is the Vendor Providing? How? Where?

If you need to audit a complex system, the questions QA will ask you will go beyond system use. The auditors will need to understand the combination of software and services the vendor is providing, and where the software and data reside.

• Does the software and data reside internally at your company or does the vendor provide a hosting service? If the vendor is hosting, the auditor needs to tour the facilities and review SOPs and records to evaluate physical security, staff training, environmental controls, backup procedures, disaster recovery plans, data retention, computer infrastructure, and change control.
• Does the hosting vendor own its own servers or does it, in turn, outsource that function to a third party hosting company, (possibly even in the cloud)? If the hosting is outsourced, ideally an auditor would be able to visit the hosting site. Failing that, the auditor would ask questions about the vendor’s qualification processes and review SOPs that govern vendor selection/management procedures. If the vendor outsources other services beyond hosting, those services might need to be considered, as well.
• Is the vendor providing any other services? Many EDC vendors will provide study-specific services such as screen development and data entry validation edits. Auditors would need to review SOPs for providing these services and understand how the vendor tests and manages modifications to these components as the study proceeds.

Sometimes computer systems vendors provide ancillary services, such as help desk functions and user account management. That would mean additional SOPs and training records for the auditor to look through.

Other Considerations

There are many. For example, where are you in the product life cycle? You ask different questions about a new system than you would about one that has been operating for a few years. Is the product commercial off-the-shelf (COTS) or highly customized? COTS systems vendors often have their own validation package which auditors would review, and then ensure proper operation in the sponsor/CRO’s specific environment. A highly customized or custom-built system would require a more extensive validation process.

The Take Away

21 CFR Part 11 audits will never be standardized, cookie cutter type activities; there are simply too many factors -- in too many combinations -- to consider. You want your QA efforts to be worth the money you spend and to be able to answer the questions FDA says you need to be asking. If you’re unsure how to do that, that’s ok. Other people know, as long as you can help them understand how you plan to use the system, what software and services are being supplied, and how components of the system are being implemented.

Many thanks to Lisa Olson for sharing her insights with me.