Method Qualification and Validation

The terms “method qualification” and “method validation” are often used in the context of analytical procedures in the pharmaceutical and biotechnology industries. While related, they serve different purposes and are applied at different stages of method development. Here is a detailed comparison of the two:

Method Qualification

Definition

Method qualification demonstrates that an analytical method is suitable for its intended use during the early stages of development. It involves preliminary testing to ensure the method can produce reliable and reproducible results for the specific application.

Purpose

Early Development: This is typically performed during the early phases of drug development (e.g., preclinical and Phase I clinical trials) to assess the method’s feasibility.
Optimization: Helps in optimizing the method to ensure it meets the necessary performance criteria before full validation.
Feasibility Studies: Often referred to as feasibility or pre-validation studies, method qualification helps understand the method’s performance characteristics and establish preliminary acceptance criteria.

Characteristics

Flexibility: The method can still be modified and optimized based on the results obtained during qualification.
Parameters: This evaluation method evaluates fewer parameters than validation, focusing on key performance indicators like specificity, linearity, accuracy, and precision.
Voluntary: This is not always required by regulatory authorities, but it is a good practice to ensure the method is on the right track for future validation.

Example

A company developing a new drug might perform method qualification to ensure that their analytical method can accurately measure the drug’s concentration in biological samples before moving on to more rigorous validation studies.

Method Validation

Definition

Method validation proves that an analytical method is suitable for its intended purpose and can consistently produce reliable and reproducible results under specified conditions. It is a regulatory requirement for methods used to test drug substances and products.

Purpose

Regulatory Compliance: Required by regulatory authorities (e.g., FDA, EMA) for methods used in quality control and release testing of pharmaceutical products.
Late Development: This is typically performed during the later stages of drug development (e.g., Phase III clinical trials, and commercial production) when the method is fully developed and optimized.
Consistency: Ensures that the method produces consistent results over time and across different laboratories.

Characteristics

Rigidity: The method must be fully developed and optimized before validation. Any changes to the method after validation would require re-validation.
Comprehensive: Involves a thorough evaluation of multiple parameters as defined by guidelines such as ICH Q2(R1), including accuracy, precision, specificity, linearity, range, limit of detection (LOD), limit of quantification (LOQ), robustness, and ruggedness.
Mandatory: Required by regulatory authorities to ensure the quality, reliability, and consistency of analytical results.

Example

Before a pharmaceutical company can market a new drug, it must validate its analytical methods to demonstrate that they can reliably measure the drug’s potency, purity, and stability according to regulatory standards.

Key Differences

Aspect	Method Qualification	Method Validation
Stage of Development	Early stages (pre-clinical, Phase I)	Later stages (Phase III, commercial production)
Purpose	Feasibility and optimization	Regulatory compliance and consistency
Flexibility	Method can be modified	Method must be fully developed and optimized
Parameters Evaluated	Fewer, key performance indicators	Comprehensive, as per regulatory guidelines
Regulatory Requirement	Voluntary, good practice	Mandatory

In summary, method qualification is an early-stage activity aimed at ensuring that an analytical method is on the right path to becoming reliable and reproducible, while method validation is a more rigorous, comprehensive process required to demonstrate that the method meets all regulatory requirements for its intended use.

Cleaning Validation Checklist

I’m reviewing the status of cleaning validation. Here is the list I’m currently going through, just in case it helps others.

Develop a comprehensive cleaning validation master plan that outlines your overall approach, policies, and procedures for cleaning validation at your facility. This should cover all aspects of the cleaning validation lifecycle.
Ensure you have written standard operating procedures (SOPs) for equipment cleaning processes that address different scenarios (e.g., cleaning between batches, between product changes, etc.).
Have written cleaning validation protocols for each piece of equipment that cover common issues like sampling procedures and analytical methods.
Maintain thorough documentation of your cleaning validation studies, including the protocols, results, and final reports stating whether the cleaning process for each piece of equipment is valid.
Implement a continuous verification program for routine residue monitoring after initial cleaning validation.
Be prepared to demonstrate that your cleaning procedures can consistently clean equipment to predetermined standards using scientifically sound sampling and analytical test methods.
Have data available to support your rationale for residue limits, which should be logical, practical, achievable, and verifiable.
Be ready to explain your approach for different types of equipment (dedicated vs. multi-use) and how you handle potent compounds or other high-risk materials.
Review your cleaning agent selection process and be able to justify the cleaning methods and agents used.
Ensure you have a system in place for equipment maintenance and cleaning records.
Be prepared to discuss how you handle manual vs. automated cleaning processes and any associated validation differences.
Review past audits or inspections and ensure any previous findings related to cleaning validation have been addressed.

Let me know if I’ve missed anything.

The GAMP5 System Owner and Process Owner and Beyond

Defining the accountable individuals in a process is critical. In GAMP5, the technical System Owner role is distinct from the business Process Owner role, which focuses more on the system’s business process and compliance aspects.

The System Owner

The System Owner is responsible for the computerized system’s availability, support, and maintenance throughout its lifecycle. The System owner is the technical side of the equation and is often an IT director/manager or application support manager. Key responsibilities include:

Defining, reviewing, approving, and implementing risk mitigation plans
Ensuring technical requirements are documented
Managing change control for the system
Conducting evaluations for change requests impacting security, maintainability, data integrity, and architecture
Performing system administration tasks like user and privilege maintenance
Handling system patching, documentation of issues, and facilitating vendor support

Frankly, I think too many organizations make the system owner too low level. These lower-level individuals may perform system admin tasks and handle systems patching, but the more significant risk questions require extensive experience.

The System Owner focuses on the technical aspects of validation and ensures adequate procedural controls are in place after validation to maintain the validated state and protect data integrity.

The system owner requires learning and understanding new products and complex system architectures. They are the architect and need to be in charge of the big picture.

The Process Owner

In the context of GAMP5, a Process Owner plays a crucial role in the lifecycle management of computerized systems used in regulated industries such as pharmaceuticals and biotechnology. The Process Owner is ultimately accountable for the system’s implementation, validation, and ongoing compliant use.

I’ve written a lot about Process Owners. This use of process owner is 100% aligned with previous thinking.

Key Responsibilities of a Process Owner

System Implementation and Validation: The Process Owner ensures the system is implemented and validated according to regulatory requirements and company policies. This includes overseeing the creation and maintenance of validation documentation and ensuring the system meets its intended use.
Ongoing Compliance and Maintenance: The Process Owner must ensure the system remains validated throughout its lifecycle. This involves regular reviews, updates, and maintenance activities to ensure continued compliance with regulatory standards.
Data Integrity and Quality: As the data owner maintains the system, the Process Owner is responsible for its integrity, administration, operation, maintenance, and decommissioning. They must ensure that data integrity and quality requirements are met and maintained.
Decision-Making Authority: The Process Owner should be at a level within the organization that allows them to make business and process decisions regarding the system. This often includes roles such as operations director/manager, lab manager, or production manager.
Collaboration with Other Teams: The Process Owner must collaborate with various teams, including Quality (QA), IT, Computer System Validation (CSV), training, HR, system vendors, and system development teams, to ensure that all necessary compliance activities are performed and documented promptly.

Skills and Knowledge Required

Detailed Understanding of the System: The Process Owner should have a comprehensive understanding of the system, its purpose, functions, and use within the organization.
Regulatory Knowledge: A good grasp of regulatory requirements is crucial for ensuring the system complies with all relevant guidelines and standards.
Validation Practices: The Process Owner will sign off on validation documents and ensure that the system is fit for its intended use.

Comparison with the Molecule Steward

While the Molecule Steward, the ASTM E2500 SME role, is not directly equivalent to the GAMP 5 roles, it shares some similarities with both the system owner and process owner, particularly in terms of specialized knowledge and involvement in critical aspects of the system. It’s best to think of the Molecule Steward as the third part of this triad, ensuring the robustness of the scientific approach.

	System Owner	Process Owner	Molecule Steward
Primary Focus	Technical aspects and maintenance of the system	Business process and compliance aspects	Specialized knowledge of critical aspects
Typical Role	IT director/manager or application support manager	Head of functional unit or department using the system	Subject matter expert in specific field
Key Responsibilities	– System availability, support, and maintenance – Data security – Risk mitigation plans – Technical requirements documentation – Change control management – Evaluating change requests	– Overall system integrity and compliance – Data ownership – User requirements definition – SOP development and maintenance – Ensuring GxP compliance – Approving key documentation – User training	– Defining system needs – Identifying critical aspects – Leading quality risk management – Developing verification strategies – Reviewing system designs – Executing verification tests
Expertise	Strong technical background	Business process knowledge	Specialized technical knowledge
Accountability	System performance and security	Business use and regulatory compliance	Critical aspects impacting product quality and patient safety
Involvement in Validation	Focuses on technical validation aspects	Ensures validation meets business needs	Leads verification activities

Comparison of SO, PO and ASTM E2500 SME

Scale of the System

People make the system too small here. This isn’t equipment A or computer system X. It’s the entire system that produces result Y. For example, it is the manufacturing process for DS (or upstream DS), not the individual bioreactors. Lower-level assistants can help with wrangling, but there should be overall accountability. The system, process, and ASTM E2500 SME must have the power in the organization to be truly accountable.

The Role of Quality

The Quality Unit is responsible for ensuring the right process and procedure are in place, that regulatory requirements are met, and that the system is fit for use and fit for purpose. The Quality Unit in GAMP5 is crucial for ensuring the safety, efficacy, and regulatory compliance of pharmaceutical products and computerized systems.

Ensuring Compliance and Product Quality: Quality is vital in ensuring that computerized systems used in pharmaceutical manufacturing meet regulatory requirements and consistently produce high-quality products. The Quality Unit helps organizations maintain high-quality standards in the various processes.
Risk Management: The Quality Unit champions a science-based risk management approach to system validation and qualification. Quality ensures the identification and assessment of potential risks.
Lifecycle Approach: The Quality Unit ensures that validation activities are conducted throughout the system’s lifecycle, from concept to retirement.
Documentation and Traceability: The Quality Unit oversees comprehensive documentation and traceability throughout the system’s lifecycle. Detailed records enable transparency, facilitate audits, and demonstrate compliance with regulatory requirements.
Change Management: The Quality Unit evaluates and controls system changes to ensure that modifications do not compromise product quality or patient safety.
Data Integrity: Quality is crucial in maintaining data integrity and ensuring records’ accuracy, reliability, and completeness.
Supplier and Internal Audits: Quality regularly audits suppliers and internal processes to ensure compliance and quality. These audits help identify gaps and areas for improvement in system development, implementation, and maintenance.

Beyond GAMP5

I consider this the best practice for handling an ASTM E2500 approach.

A Collaborative Learning Event I Might Run

To complete a thought on community of practices I did this weekend with “A CoP is Collaborative Learning, not Lecture” and “How I would Organize a Meeting of a CoP” I’m now going to build, from the group up, a collaborative learning event I would love to organize.

A little caveat: I really burnt out on professional obligations last year and have just started to peak my head out. So, it may be a little harder to turn this mad scientist dream into a reality. However, I think it is worth putting out as a thought experiment.

Theme and Scope

I’ve written a bit about the challenges to quality, and these challenges provide a framework for much of what I think and write about.

More specifically drawing from the “Challenges in Validation” focusing on the challenges of navigating a complex validation landscape characterized by rapid technological advancements, evolving regulatory standards, and the development of novel therapies.

This event would ask, “How do we rise to the challenges of validation in the next decade, leveraging technology and a risk management approach and drawing from the best practices of ASTM E2500, GAMP5, and others to meet and exceed changing regulatory requirements.”

Intended Audience

I go to events, and there are a lot of quality people, OR risk management people, OR computer systems (IT and Q) people, OR engineers, OR analytical method folks, OR process development people. Rarely do I see an event that looks at the whole picture. And rarely do I get to attend an event where we are sharing and blurring the lines between the various silos. So let us break down the silos and invite quality, IT, engineers, and process development individuals involved in the full spectrum of pharmaceutical (and possibly medtech) validation.

This holistic event is meant to blend boundaries, share best practices, challenge ourselves, and look across the entire validation lifecycle.

Structure

Opening/Networking (1 hour)

As people arrive, they go right into a poster event. These posters are each for a specific methodology/approach of ASTM E2500, ISPE Baseline Guides, FDA’s Guidance for Process Validation: General Principles and Practices, ICH’s QbD approach, and GAMP5. Maybe some other things.

These posters would each:

Provide an overview of what it is and why it is important
Overview of methodology
What challenges it overcomes
Lessons that can be applied
Challenges/problems inherent in the approach

These posters would be fun to develop and take a good squad of experts.

After an hour of mingling, sharing, and baselining, we could move to the next step.

Fish Bowl Debate (45 minutes)

Having earlier selected a specific topic and a panel of experts, hold a fish bowl debate. This would be excellent as a mock-inspection, maybe of a really challenging topic. Great place to bring those inspectors in.

During a fish bowl, everyone not in the center is taking notes. I love a worksheet to help with this by providing things to look for to get the critical thinking going.

Future Workshop (1.5 hour)

Introduce the activity (10 min)
Ask participants to reflect on their present-day situation, write down all their negative experiences on sticky notes, and place them on the wall. (15 min)
Invite participants to list uncertainties they face by asking, “In your/our operating environment, what factors are impossible to predict or control their direction?” (5 min).
Prioritize the most critical factors by asking, “Which factors threaten your/our ability to operate successfully?” (10 min)
Based on the group’s history and experience, select the two most critical and most uncertain (X and Y). (5 min)
Create a grid with two axes—X & Y—with a “more of <— —> less of” continuum to represent the factor on each axis. For example, suppose new modalities are a critically uncertain factor for the X-axis. In that case, one end of the X-axis is many new modalities, and the other is no new modalities. Repeat for the Y factor and axis. For instance, if patent protection is a critical factor, one end of the Y axis is strong patent protection, and the other has no patent protection. Four quadrants are created. (5 min)
Break into four groups, and each group creatively names and writes a thumbnail scenario for one of the quadrants. (10 min)
The four groups share their scenarios briefly. 2 min. each
Participants fantasize about the desired future situation. How would the ideal situation be for them? At this stage, there are no limitations; everything is possible. Write on stick notes and apply them to the most likely quadrant. (10 minutes)
Do a n/3 activity to find the top ideas (enough for groups of 4-5 each) (3 min)
Explain the next activity (2 min)

Lunch (1 hour)

Open Space Solution (1 hour)

For each top idea, the participants vote with their feet and go to develop the concept. Each group is looking to come up with the challenge solved, a tool/methodology, and an example.

Review the Results of the Open Space Solutions (1 hour)

Each team presents for 5-8 minutes.

1-2-4-All (20 minutes)

Silent self-reflection by individuals on the shared challenge, framed as a question “What opportunities do YOU see for making progress on this challenge? How would you handle this situation? What ideas or actions do you recommend?” (1 min)
Generate ideas in pairs, building on ideas from self-reflection. (2 min)
Share and develop ideas from your pair in foursomes (notice similarities and differences).( 4 min)
Ask, “What is one idea that stood out in your conversation?” Each group shares one important idea with all (15 min)

Closing Commitment (5 min)

Where will this live? What comes next? Make a commitment to follow up electronically.

Networking

Spend an hour or so with drinks and food and discuss everything. Never enough socialization.

Color and Risk Evaluation

These experiments show some preliminary evidence that the color assignment in risk matrices might influence people’s perception of risk gravity, and therefore their decisionmaking with regards to risk mitigation. We found that individuals might be tempted to cross color boundaries when reducing risks even if this option is not advantageous (i.e., the boundary crossing effect). However, this effect was not consistently found when we included exploratory analyses of
risk mitigations at different impact levels.

Pending future research replicating these results, the cautious recommendation is that the potential biasing effects of color should be considered alongside the goal of communication. If the purpose of communication is informing individuals in an unbiased way, these findings suggest it might be worth eliminating colors from risk matrices in order to reduce the risk of the boundary-crossing effect. On the other hand, if the goal of communication is to persuade individuals to implement certain risk mitigation actions, it might be that assigning colors so as to elicit the boundary-crossing effect would facilitate this. This could be the case, for example, when designing risk matrices that communicate action standards (i.e., severity level at which risk mitigation should be implemented) (Keller et al., 2009). This advice might be particularly relevant in the case of semiqualitative risk matrices, where color assignment might be arbitrary due to the absence of clear numeric cut-off points separating risk severity categories, and to situations where the users of the risk matrix are expected to be of higher numeracy and not have prior training in the design and use of risk matrices.
Proto, R., Recchia, G., Dryhurst, S., & Freeman, A. L. J. (2023). Do colored cells in risk matrices affect decision-making and risk perception? Insights from randomized controlled studies. Risk Analysis, 43, 2114–2128. https://doi.org/10.1111/risa.14091

Well, that is thought-provoking. I guess I need to start evaluating the removal of a lot of color from SOPs, work instructions, and templates.