Do I HAVE To Validate This System?

A little cheese with that oft-heard whine?

If you’ve been in QA any length of time, you’ve been asked this question. If you weren’t sure yourself, you may have called a systems auditor for help. When you finish reading this newsletter, you’ll have insight into why the question gets asked. Best of all, you’ll have 4 simple questions you can ask to get agreement on the answer to “Do I HAVE to validate this system?”

Why Do People Ask?

As we approach the 20th anniversary of 21 CFR Part 11, people are not still asking this question because they want to put another nail in your QA coffin. In my experience, both the question and the answer are related to people and process. 

People

People generally ask why because they don’t understand. So be patient. If they’re internal to your company, they may be a new hire or have transferred from a group that doesn’t work with the GLPs or GCPs. If they work for a Software As A Service (SaaS) company, starting to service our industry, no one at their company may understand the regulatory expectations.

Sometimes people ask because of pressure from their management not to do the work validation requires. They may “know” the system should be validated, but they don’t feel confident explaining “why” to their management. 

Process

People are less likely to ask “why” if there is an effective process in place for making and documenting the decision. The process for making the decision needs to be scoped correctly and well-designed to be effective.

Process scope

The process for deciding may not be scoped properly. The process is often owned by IT and kicks in when the business comes to IT with a request. What happens at your company when the business does not go to IT for help? Can they bypass IT by contracting directly with another company? Can they bypass IT by developing the system on their own, using tools provided by IT? (SharePoint leaps to mind.)

Process design

The process for making the decision may be so poorly designed that people can’t make a decision or don’t trust the decision. We’ve all seen those Part 11 Applicability Forms that make you select what the system does from a list. If you check anything on the list, the system must be validated. Those tools don’t help users or their management understand “why.” And then there’s the groaning and moaning and gnashing of teeth when nothing in the list fits.

I can’t help you with the politics of scope and IT governance, but I can help you ask the right questions to effectively answer “Do I HAVE to validate this system?”

Decision Process

In the US, there are no regulatory requirements specific to clinical trials that require computer systems to be validated. If you can demonstrate that Part 11 applies, then the system should be validated. Let’s take a hypothetical example, ask the questions, and see what the decision is. 

Hypothetical example

Your safety department wants to improve the timeliness and reliability of reporting Serious Adverse Events (SAEs) seen in clinical trials. All your clinical trials use software from EDC-R-US to collect eCRF data, and your company uses software from AESnow to collect and report SAEs. Your safety department has requested your company’s IT department to build an interface called PIPE between the two systems to automate reporting from one database into the other. Management in the safety department has told IT management there’s no need to validate the system, because it’s just a “pass-through” system. The IT Project Manager and Safety representative bring this to the table when IT, safety, clinical data management, and QA meet to complete the 21 CFR Part 11 assessment.

1. Intended use

Answering the 1st question sets up you to successfully answer the next 3.

Question: What is the intended use of the system? Include who will use the system and what they will use it for.

Answer: When a user saves an SAE eCRF in the EDC-R-US system, PIPE will reformat the data and transmit a copy to AESnow, where Safety Case Managers can process the case.

2. Records

Question: What records does the system 

1. Create?
2. Modify?
3. Maintain?
4. Archive?
5. Retrieve?
6. Transmit?

Answer: 

1. Create – PIPE creates a modified version of the SAE record from EDC-R-US for export into SAESnow. In addition, PIPE creates the records identified in “3. Maintain.”
2. Modify – PIPE modifies the SAE record retrieved from EDC-R-US, fomatting it for export into AESnow.
3. Maintain – PIPE does not maintain a copy of the imported SAE record or the modified record for transmission to AESnow. PIPE does maintain records of
   • when it imported SAE records from EDC-R-US
   • which SAE record was imported
   • when it modified the imported SAE record
   • when the transformed record was transmitted to AESnow
   • success or failure of the transmission, including the date and time
4. Archive – Not applicable. PIPE does not archive any records.
5. Retrieve – PIPE retrieves a copy of SAE records from the EDC-R-US system
6. Transmit – PIPE transmits modified SAE records from EDC-R-US to AESnow

3. Predicate Rules

If there are predicate rules for the records, the system should be validated.

Question: Which FDA regulatory requirements apply to these records?

Answer:

• 21 CFR Part 312.64(b) requires investigators to “promptly report to the sponsor any adverse effect that may reasonably be regarded as caused by, or probably caused by, the drug.” In addition, when “the adverse event is alarming,” the investigator is required to “report the adverse effect immediately.”
• 21 CFR Part 312.56(c) requires the sponsor to “review and evaluate the evidence relating to the safety and effectiveness of the drug as it is obtained from the investigator.”
• 21 CFR Part 312.32(c) describes the sponsor’s responsibilities for notifying “FDA and all participating investigators” of adverse events.

4. Submitted or not?

If the records will be submitted, the system should be validated.

Question: Will the records identified be submitted to the FDA?

Answer: No. While PDF renditions of the SAE form in EDC-R-US and safety records from AESnow will be submitted to the FDA, records created and transmitted by PIPE will not be submitted to the FDA. 

Decision

In our hypothetical example, because the system creates, modifies, retrieves and transmits records covered by predicate rules, then 21 CFR Part 11 applies, and the system should be validated. Because you’ve all worked together to identify how the system will be used, what the records are, and where the requirements for those records are documented in regulation, having that difficult conversation with IT and Safety management just got easier.

4 Simple Questions

Now you have 4 simple questions to help you reach agreement on the question

Do I HAVE to validate this system?

1. What is the intended use of the system?
2. What records does the system create, modify, maintain, archive, retrieve, or transmit?
3. What predicate rules apply to the records?
4. Will the records be submitted?

How does the conversation go for you? Leave a comment below.

Linkedin

Facebook

0

Twitter

email