Tag: risk management

Contamination Control, Risk Management and Change Control

Microbiologists won’t be sequestered in the laboratory, running samples and conducting environmental testing, once the revisions proposed for Annex 1 of the EU and Pharmaceutical Inspection Cooperation Scheme (PIC/S) GMP guides take effect, Annex 1 rapporteur Andrew Hopkins said Oct. 15.

They will have a broader role that includes conducting risk assessments to ensure that sterile products are made as contamination-free as possible, said Hopkins, who is an inspector for the UK Medicines and Healthcare products Regulatory Agency.

Pink Sheet “EU GMP Annex 1 Would Give Microbiologists A Greater Role In Sterility Assurance, Rapporteur Says“

Contamination Control is a fairly wide term used to mean “getting microbiologists out of the lab” and involved in risk management and compliance. Our organization splits that function off from the QC Microbiology organization but there are many models for making it work.

Risk Management is a major part of the new Annex 1, and what they are driving at are good risk assessments with good risk mitigation that involve the microbiologists.

living risk assessments

This is really what is meant by a contamination control strategy which considers the product and process knowledge and skills in pharmaceutical product manufacturing and GMP/ cGMP compliance under the auspices of a Pharmaceutical Quality System (Q10) together with initiatives of Quality by Design (Q8) and Quality Risk Management (Q9).

From this strategy comes:

  • Targeted/ risk based measures of contamination avoidance
  • Key performance indicators to assess status of contamination control
  • A defined strategy for deviation management (investigations) and CAPA

environmental monitoring

When it comes to change management, one of the easiest places to go wrong is to forget to bring the microbiologist in to changes. Based on your strategy you can determine change changes require their assessment and include it in the tool utilized to determine SMEs, for example:

Department Required if the change meets any of the following criteria:
Contamination Control The change impacts environment integrity, conditions or monitoring, including:

  • Changes to a controlled room or area that impact integrity
  • Changes in sampling methodology
  • Construction activities
  • Changes in personnel or material flow
  • The change will result in or modify exposure of product to the environment.

The change can impact microbiological control within a process stream, raw material or process equipment

The changes are to water systems

Effective Change Management

Both Curious Cat and A Lean Journey tell me that the ASQ Influential Voices blogs are covering change management. I do love a good blog carnival, and change management is sort of my thing, so I am going to jump in.

It’s often said that people don’t resist “change” so much as they resist “being changed.” So, the job of change management is clear: In a nutshell, you must explain why the affected people should want to change, and thereby cultivate readiness instead of resistance.

 What are some recommended strategies or tactics to help achieve successful change management?

My first piece, of advice, abandon the idea that change management only involves people. Just as all systems are made of people, organization, process and technology; all changes impact all four and need to be viewed holistically.

Second, get rid of the artificial barriers between change management and change control. Change management is the how of change – assess, handle and release. Change control is the what, the execution steps. Remember that all changes are really just projects, and vice versa. The level of change determines the level of activity.

Level of Change Change Management Change Control
Transactional Minor Few

Closely clustered
Operational Major Several

Across several areas
Transformational Fundamental Many

Iterative

Often in waves

Simplify your variety of change controls and strive for scalability within one change management (and control) system. Utilize the levers, which include: regulatory (compliance), product release and risk.

Knowledge Management

Change Management and Knowledge Management are closely entwined. An effective change management system includes active knowledge management, in which information from multiple sources is integrated to identify stimuli for changes needed to improve product and/or process robustness.

There are key interactions with document management and training.

Risk Management

Risk management enables changes and helps assess:

  • The proposed change
  • The effectiveness of the change once implemented

Change Is

Propose the Change

curent and future

Make it SMART:

  • Specific – The proposal needs to be accurate and leave no doubt as to what the change will achieve.
  • Measurable – How will the system owner (sponsor) know when the project is complete.
  • Achievable – Make the change as small as possible after all it is easier to eat an elephant one bite at a time. It is far easier to manage a few smaller change than one big one. This is why operational and transformational changes are many changes and often iterative.
  • Realistic – Make the change easy to deliver, if it is over complicated then it is likely to hit problems and run over budget, be delivered late or of poor quality.
  • Timely – Does the change have to be complete by a certain date? If so put it in the scope that the project has to be complete by that date. Are there dependencies and independencies?

Evaluate

The change Project team leverages SMEs to harness the collective intelligence (synergy) for the benefit of the site.

  • Relevancy – The information gathered is of value
  • Reliability – The process by which the information is collected should be consistent
  • Accuracy – The data should be expressed in a manner that most accurately reflects its information content
  • Efficiency – The design and implementation of the tasks should minimize the burden

Evaluates all four areas (process, technology, people and organization). Includes communication of the change and training.

Vision Importance
What is the vision for this change Why is this change important to our organization
Success Measurements Process Measurements
How will we measure success How will we show progress towards our vision?
Who and what is affected?
What people, departments and processes need to change in order to realize our vision?
How will we support people?
What actions will we do to support people through the change?
What is our plan?
Detailed action plan

Build in effectiveness reviews to your plan.

Implement

Execute the change plan, provide evidence of completion. Escalate significant risks or delays.

Close

Ensure change plan was executed and benefits realized.

Hold a lessons learned.

lessons learned

Conclusion

Change management is a system. It should have its own cycles of improvement and grow as you execute changes. Change is a fundamental pillar of a quality system and spending the time to build a robust system will reap dividends and prove itself a good idea again and again.

 

 

FDA issues new guidance on Post Approval Changes

This past week the FDA issued a draft guidance “Post Approval Changes to Drug Substances” from the Center for Drug Evaluation and Research on post-approval changes for drug substances to provide clarity to holders of drug master files and holders of new and generic drug applications on which reporting category manufacturing changes fall into as well as the information required to support these changes.

Like any guidance this is supposed to “describe the Agency’s current thinking on a topic” and in this case this is a pretty important guidance as it is the first on the subject of change management published after the draft of Q12. It also clearly builds on the concepts of Q11 and is the first time the agency has published a guidance on drug substance post approval changes.

The guidance covers changes to facility; scale and equipment changes; specification changes to starting materials; synthetic manufacturing process changes; and, changes to the container closure systems for the drug substance.

It uses the traditional breakdown of major changes (prior approval supplement category), Moderate changes (changes-being-effected-30 (CBE-30) category) and Minor changes (annual report).

The guidance provides some solid requirements for risk assessments, and requires the risk assessment be included with the filing of change. This will require some companies to improve their risk management process, and may cause some to question decision making about their internal formulas for level of effort and the formality of risk management.

The deadline for public comment on the draft is Nov. 13. Submit comments to the docket at: https://www.regulations.gov/docket?D=FDA-2018-D-3152.

Computer verification and validation – or what do I actually find myself worrying about every day

voting_software
xkcd “Voting Software” https://xkcd.com/2030/

This xkcd comic basically sums up my recent life. WFI system? Never seems to be a problem. Bioreactors? Work like clockwork. Cell growth? We go that covered. The list goes on. And then we get to pure software systems, and I spend all my time and effort on them. I wish it was just my company, but lets be frank, this stuff is harder than it should be and don’t trust a single software company or consultant who wants to tell you otherwise.

I am both terrified and ecstatic as everything moves to the cloud. Terrified because these are the same people who can’t get stuff like time clocks right, ecstatic because maybe when we all have the exact same problem we will see some changes (misery loves company, this is why we all go to software conferences).

So, confessional moment done, let us turn to a few elements of a competent computer systems validation program (csv).

Remember your system is more than software and hardware

Any system is made up of Process, Technology, People and Organization. All four need to be evaluated, planned for, and tested every step of the way. Too many computer systems fall flat because they focus on technology and maybe a little process.

Utilize a risk based approach regarding the impact of a computer system impact on product quality, patient and consumer safety, or related data integrity.

Risk assessments allow for a detailed, analytical review of potential risks posed by a process or system. Not every computer system has the same expectations on its data. Health authorities recognize that, and accept a risk based approach. This is reflected across the various guidances and regulations, best practices (GAMP 5, for instance) and the ISOs (14971 is a great example).

Some of the benefits of taking this risk based approach include:

  • Help to focus verification and validation efforts, which will allow you to better focus of resources on the higher-risk items
  • Determine which aspects of the system and/or business process around the system, require risk mitigation controls to reduce risk related to patient safety, product quality, data integrity, or business risk
  • Build a better understanding of  systems and processes from a quality and risk-based perspective

Don’t short the user requirements

A good user requirement process is critical. User requirements should include, among other things:

  • Technical Requirements: Should include things like capacity, performance, and hardware requirements.
  • System Functions: Should include things like calculations, logical security, audit trails, use of electronic signature.
  • Data: Should describe the data handling, definition of electronic records, required fields.
  • Environment: Should describe the physical conditions that the system will be required to operate in.
  • Interface: What and how will this system interface with other systems
  • Constraints: discuss compatibility, maximum allowable periods for downtime, user skill levels.
  • Lifecycle Requirements: Include mandatory design methods or special testing requirements.

Evaluate each of people, process, technology and organization.

This user requirement will be critical for performing a proper risk assessment. Said risk assessment is often iterative.

Build and test your system to mitigate risk

  • Eliminating risk through process or system redesign
  • Reduce risk by reducing the probability of a failure occurring (redundant design, more reliable solution)
  • Reduce risk by increasing the in-process detectability of a failure
  • Reduce risk by establishing downstream checks or error traps (e.g., fail-safe, or controlled fail state)
  • Increased rigor of verification testing may reduce the likelihood by providing new information to allow for a better assessment

After performing verification and validation activities, return to your risk assessment.

Apply a lifecycle approach once live

  • Apply proper change management
  • Perform periodic reviews of the system. This should include: current range of functionality, access and training, process robustness (do the current operating procedures provide the desired outcome), incident and deviation review, change history (including upgrades), performance, reliability, security and a general review of the current verified/validated state.
  • Ensure the risk assessment is returned to. On a periodic basis return to it and refresh based on new knowledge gained from the periodic review and other activities.

Do not separate any of this from your project management and development methodology

Too many times I’ve seen the hot new development lifecycle consider all this as an after thought to be done when the software is complete. That approach is expense, and oh so frustrating

 

International Council of Harmonization Q7-Q14

The Pharmaceutical GMP Professional certification from the ASQ body of knowledge has, as its first area, Regulatory Agency governance, as it should, as a solid understanding of not only what the regulations and guidances say is important, it is pretty important to understand the why, and how they work together.

The subsection Regulations and Guidances states: “Interpret frequently used regulations and guidelines/guidances, including those published or administered by the Pharmaceutical Inspection Convention and Pharmaceutical Inspection Cooperation Scheme (PIC/S), Health Canada, the World Health Organization (WHO), the International Conference on Harmonization (ICH), the European Medicines Agency (EMA), the Food & Drug Administration (FDA), the USDA 9CFR, the International Pharmaceutical Excipients Council (IPEC), and Controlled Substance Act (CSA) 21 CFR 1300. (Understand)”

The ICH is on my mind this week as I’ve had a few different conversations with folks as part of development conversations and other places about understanding regulations, and this post is my jotting down a few thoughts for future development and thought.

I am focusing on Q7 to Q14 (Q7-Q11 are published, Q12 in draft, Q13 and Q14 just recently announced). There are other Qs and there are certainly other aspects of the ICH, those just are not what I am interested in here.

Q7-Q14, in many ways, involves the development of a philosophy between the ICH member nations and the various observers. Like any harmonization and guidance process, it has a few difficulties, but the developing philosophy has been developed to establish a more proactive and risk-based approach to the industry. As such, being well versed in the principles is good for a pharmaceutical quality practitioner.

Quality trio ICH

Q7

ICHQ7 “Good Manufacturing Practice Guide for Active Pharmaceutical” was a fairly late product of the ICH. Founded in 1990 it was not until 1998 that it was determined that a GMP document was needed. It took another 2 years to complete and then another year or two for adoption by the member nations of the time. Which for the ICH is rocket speed.

Q7 is basically a solid list of what makes a functioning pharmaceutical quality system. Its the great big giant check-box of stuff to make sure you have. Personnel Qualification! Check! Production Controls? Check! Cleaning Validation? Check (well….)

Q7 covers API and has a great table on page 3 that covers applicability for types of API and the increasing GMPs. That said, Q7 is pretty much a great stopping place for anyone evaluating their quality system in a GMP environment. Most of the principles are universal, for example stating about master production records “These records should be numbered with a unique batch or identification number, dated and signed when issued. In continuous production, the product code together with the date and time can serve as the unique identifier until the final number is allocated.”

The Q&A released for Q7 in 2015 is telling. It is either all narrow specifies (including a definition of terms) or it is “Can I use risk management with X”, such as “To what extent can quality risk management be used in establishing appropriate containment measures to prevent cross-contamination?” To which the answer is basically “That is why we wrote Q9”

A good document to have around when setting standards.

Q8

ICHQ8 “Pharmaceutical Development” is the place where quality by design really starts coming into its own a solid concept. Finalized in 2005, it started being adopted in 2009/2010 (with Canada adopting it in 2016).

Q8 is all about setting forth a systematic, knowledge-driven, proactive, science and risk-based approach to pharmaceutical development. And at its heart, this is the philosophy that these ICH guidances rest on.

Q9

ICHQ9 “Quality Risk Management” was finalized in 2005 and quickly adopted in 2006 (except in Canada). This guidance pretty much recognizes that nothing the ICH was going to do would work without a risk-based approach, and it is arguable that the pharma industry might not have been all on the ball yet about risk. Risk management is without a doubt the glue that holds together the whole endeavor.

Q10

Q10

ICHQ10 “Pharmaceutical Quality System” was finalized in 2008 and adopted from 2008-2010 (except Canada). Q10 lays out a quality system approach that, based on a science and risk-based approach, establishes 4 pillars: Process Performance and Product Quality Monitoring; CAPA; Change Control; and, Management Review. Your welcome pharmaceutical industry, the ICH has now told you how to do your job and after Q10 we are getting serious about figuring out how to get ready for new technologies and be nimble and stuff.

The Pharmaceutical lifecycle is set out in 4 phases: Pharmaceutical Development, Technology Transfer, Commercial Manufacturing and  Product Discontinuation; with the requirements of each pillar being explained at a high level for each phase.

Knowledge management gets poked at as a key enabler.

Q9 and Q10 together basically set out to demonstrate just how to do the things that are a requirement in order to have quality by design (Q8) but also show how to move from Q7 to a proactive, risk-based approach to running your pharmaceutical lifecycle. We are moving from a set of discrete compliance requirements (which Q7 is sort of a bow-tie around) to a comprehensive quality systems approach over the lifetime of the product to establish and maintain a state of control and facilitate continual improvement. Breaking down silos this approach united product development with manufacturing, with distribution. I feel almost like I am having a mystic experience when I contemplate what this path we are on can do. Because frankly, we are still on the path.

Q11

ICHQ11 “Development and Manufacture of Drug Substances” was finalized in 2012 and adopted in the next 4 years. This is a bow guidance as it shows how to implement Q8, with the support of Q9 and Q10. This is based on six principles that stem from the three previous guidances: Drug-substance quality linked to drug product; Process-development tools; Approaches to development; Drug-substance CQAs; Linking material attributes and process parameters to drug substance CQAs; and, Design space.

Q11 is our blueprint, drug substance manufacturers. Others can learn a lot of how to implement Q8-10 through reading, understanding and internalizing this document.

Q12

In November of 2017 the long-anticipated draft of ICHQ12 “Technical and Quality Considerations for Pharmaceutical Product Lifecycle management” was published. Q12 provides a framework to manage CMC changes across the lifecycle of the product. In short, it utilizes Q8, Q9, and Q10 and says if you do those things then here are how post-marketing changes will work and the expected regulatory benefits. Which means getting changes to market faster. Knowledge management is expanded upon as a concept.

Q12 enshrines established conditions, which is a term that wraps a few QbD concepts and provides a regulatory framework. Still, in draft, there is a fair share of controversy (for example, the EMA can’t adopt it as is it appears) and I am certainly curious to see what the final result is.

At this point we have: Q7 – summary of GMPs; Q8 – QbD; Q9- risk management; Q10 – quality systems; Q11 – a roadmap for drug substances; and in draft, Q12 – lifecycle management.

The ICH primary exists as a way for regulatory bodies to align and work out the thorny issues facing the industry. The process is not perfect, but it’s much better to be involved then to ignore.

Q13 and Q14

This last June the ICH met and, amongst other things, announced the roadmap for what is next:

  • Analytical Procedure Development and Revision of Q2(R1) AnalyticalValidation (Q2(R2)/Q14)
  • Continuous manufacturing (Q13)

Q2 is desperately in need of revision. It was finalized back in 1996 and does not take advantage of all the thought process expressed in Q8-Q11. Apply QbD, risk management, and quality systems will hopefully improve this guidance greatly.

Q13 appears to be another in the line of how to apply the Q8-Q10 concepts, this time to everyone’s favorite topics – continuous manufacturing. Both the FDA and EMA have been taking stabs at this concept, and I look forward to seeing the alignment and development through this process.

I look forward to seeing formal concept papers on both.