Tag: risk management

Risk Management leads to Change Management, Change Management contains Risk Management

We did an FMEA for the design of the room. Why do we need a risk assessment for the change control to implement the design features?

We have an environmental risk management plan, including a HAACP. Why does this change control require a new risk assessment?

If I received a nickel……

I want to expand on my earlier thoughts on risk management enabling change.

Risk Management is a key enabler of any quality by design, whether of product, facility or equipment. We do living risk assessments to understand the scope of our ongoing risk. Inevitably we either want to implement that new or improved design or we want to mitigate the ongoing risks in our operation. So we turn to change management. And as part of that change management we do a risk assessment. Our change management then informs ongoing risk review.

Risk Management Leads to Change Management

Design Implementation

Through your iterative design lifecycle there is a final design ready for introduction. Perhaps this is a totally new thing, perhaps it is a new set of equipment or processes, or just a modification.

All along through the iterative design lifecycle risk management has been applied to establish measurable, testable, unambiguous and traceable performance requirements. Now your process engages with change management to introduce the change.

And a new risk assessment is conducted.

This risk assessment is asking a different question. During the interative design lifecycle the risk question is some form of “What are the risks from this design on the patient/process.” As part of risk management, the question is “What are the risks to SISPQ/GMP from introducing the change.”

This risk assessment is narrower, in that it looks at the process of implementing. Broader that it looks at the entirety of your operations: facility, supply chain, quality system, etc.

The design risk assessment and risk management activities informs the change management risk assessment, but it cannot replace them. They also can serve to lower the rigor of the change management risk assessment, allowing the use of a less formal tool.

Living Risk Reviews

risk leads to change

In the third phase of risk management – risk review – we confirm that the risks identified and mitigated as planned and are functioning as intended. We also evaluate to see if any additional, previously unpredicted risks have appeared. Risk review is the living part of the lifecycle as we return to it on a periodic basis.

From this will come new mitigations, targeted to address the identified risks. These mitigations inevitably lead to change management.

We again do a new risk assessment focusing on the risk of implementing the change. Informed by the living risk assessment, we can often utilize a less formal tool to look at the full ramifications of introducing the mitigation (a change).

Change Controls contains Risk Management

risk and change management connections

Effective change management is enabled by risk management.

Each and every change requires a risk assessment to capture the risks of the change. This ICHQ10 requirement is the best way to determine if the change is acceptable.

This risk assessment evaluates the impact on the change on the facility, equipment, materials, supply chain, processes. testing, quality systems and everything else. It is one of the critical reasons it is crucial to involve the right experts.

From this risk assessment comes the appropriate actions before implementing the change, as well as appropriate follow-up activities and it can help define the effectiveness review.

What about grouped change controls?

Depends. Sometimes the risk management looks at the individual implementations. Othertimes you need to do separate ones. Many times the risk assessment lead you to breaking up one change control into many. Evaluate as follows:

  • Are the risks from the separate implementations appropriately captured
  • Are the risks from pauses between implementations appropriately captured
  • As the ripples appropriately understood

Change Management Leads back to Risk Management

Sometimes a change control requires a specific risk assessment to be updated, or requires specific risk management to happen.

What about HAACP?

Hazard Analysis Critical Control Point (HACCP) are great tools for risk assessments. They are often the catalyst for doing a change, they are often the artifact of a change. They should never be utilized for determining the impact of a change.

A hazard is any biological, chemical, or physical property that impacts human safety. The HAACP identifies and establishes critical limits. But a HAACP is not the tool to use to determine if a change should move forward and what actions to do. It is to static.

In Closing

Risk Management is an enabler for change, a tenet enshrined in the ICH guidances. We are engaging in risk management activities throughout our organizations. It is critical to understand how the various risk management activities fit together and how they should be separated.

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.

Likelihood of occurrence in risk estimation

People use imprecise words to describe the chance of events all the time — “It’s likely to rain,” or “There’s a real possibility they’ll launch before us,” or “It’s doubtful the nurses will strike.” Not only are such probabilistic terms subjective, but they also can have widely different interpretations. One person’s “pretty likely” is another’s “far from certain.” Our research shows just how broad these gaps in understanding can be and the types of problems that can flow from these differences in interpretation.

“If You Say Something Is “Likely,” How Likely Do People Think It Is?” by by Andrew Mauboussin and Michael J. Mauboussin

Risk estimation is based on two components:

  • The probability of the occurrence of harm
  • The consequences of that harm

With a third element of detectability of the harm being used in many tools.

Often-times we simplify probability of the occurrence into likelihood. The quoted article above is a good simple primer on why we should be careful of that. It offers three recommendations that I want to talk about. Go read the article and then come back.

I.                Use probabilities instead of words to avoid misinterpretation

Avoid the simplified quality probability levels, such as “likely to happen”, “frequent”, “can happen, but not frequently”, “rare”, “remote”, and “unlikely to happen.” Instead determine probability levels. even if you are heavily using expert opinion to drive probabilities, given ranges of numbers such as “<10% of the time”, “20-60% of the time” and “greater than 60% of the time.”

It helps to have several sets of scales.

The article has an awesome graph that really is telling for why we should avoid words.

W180614_MAUBOUSSIN_HOWPEOPLE

II.             Use structured approaches to set probabilities

Ideally pressure test these using a Delphi approach, or something similar like paired comparisons or absolute probability judgments. Using the historic data, and expert opinion, spend the time to make sure your probabilities actually capture the realities.

Be aware that when using historical data that if there is a very low frequent of occurrence historically, then any estimate of probability will be uncertain. In these cases its important to use predicative techniques and simulations. Monte Carlo anyone?

III.           Seek feedback to improve your forecasting

Risk management is a lifecycle approach, and you need to be applying good knowledge management to that lifecycle. Have a mechanism to learn from the risk assessments you conduct, and feed that back into your scales. These scales should never be a once and done.

In Conclusion

Risk Management is not new. It’s been around long enough that many companies have the elements in place. What we need to be doing to driving to consistency. Drive out the vague and build best practices that will give the best results. When it comes to likelihood there is a wide body of research on the subject and we should be drawing from it as we work to improve our risk management.

Move beyond setting your scales at the beginning of a risk assessment. Scales should exist as a library (living) that are drawn upon for specific risk evaluations. This will help to ensure that all participants in the risk assessment have a working vocabulary of the criteria, and will keep us honest and prevent any intentional or unintentional manipulation of the criteria based on an expected outcome.

.