Communication of Changes between sites

Yesterday, the FDA finalized the ICH Q7 Q&A Guidance on GMPs following its endorsement by the regulatory agencies participating in the ICH in June 2015.

Two-and-a-half-years. And I sometimes wonder why the ICHs aren’t more broadly adopted or why some of my colleagues are a little pessimistic about their impact on this industry

However, re-reading these questions and answers gave me a good topic.

QA on Q7 change management

With complex and virtual supply chains, with world wide distribution, it is important to understand who needs to be communicated about what changes.

This communication should be evaluated for it’s directionality. It helps to break down your types of changes and determine what are:

  • Consult – those changes where the other site needs to provide an assessment. For example, if a change impacts testing that is conducted at another site, or it impacts the way the next site will receive the material (don’t forget ERP changes). These communications are always push.
  • Inform – the other site needs to be aware but will not need to take any action. A great example of this notifying the QP.

Include your suppliers in this process as well, and ensure your suppliers are also appropriately communicating. Include this in your quality/technical agreements or contract terms.

Risk Management enables Change

Every change has a degree of risk. We cannot understand that unless we utilize risk management as a key enabler. Change management utilizes risk management to appropriately evaluate knowledge management.

risk and change management connections

Not everything we do in a change is a risk. There are also impacts.

Impacts are the things that will be impacted by the change. if I revise my HVAC system, my air monitoring program will be impacted. Subject matter experts can easily identify these, they can be checklisted, they are easy to standardized. If I can X, Y needs to happen. All of these impacts end up on the action plan.

Risk management instead looks at what could happen as a result of the change. In change control it is important to evaluate both the future state and the process of implementing the future state.

In the diagram above the four major aspects of change are linked to the risk management activities we do.

When we propose a change we often are using an already existing risk assessment to drive the decision making. We can also conduct risk assessments as part of our option analysis, and design activities.

In change plan development (evaluation), we also add in the risk of implementing the change. Depending on the risk management activities that happened in propose the formality of this risk assessment will change. Our risk assessment drives an action plan, which manages the mitigations, the risk control.

In Implement, we do the work to mitigate the identified risks. By accepting the change we accept the mitigated risks. How we break the change into pre-implementation, implementation and post-implementation activities will be driven heavily by risk mitigation.

And in closure, we come back to ensure risks are appropriately mitigated.  If formal risk assessments (such as an FMEA) drove the change, we return and rescore the risks against their new, mitigated, state.

Effectiveness reviews can be tied back to risk review activities.

Change Management and Document Control

“If it isn’t documented, it didn’t happen” is an often-repeated and heavily loaded phrase. One that I want to unpack in a lot of ways on this blog.

Here I want to focus on the interaction between change management and document control, as I think the two are closely intertwined, and that close relationship can confuse you.

Change Management is all about how we assess, control and release our changes. Document control is how we create, review, modify, issue, distribute & access documents. Document control is part of knowledge management (an enabler of the enabler), it is a tool for change control, and is often a deliverable, but it is important to understand that change management is broader than document control, and the principles of change management should enwrap and permeate a document control system.

Let’s start with a SIPOC.

SIPOC for document control

Change Management here is all about the how of the change:

  • Assess – What is the impact of our changes
  • Handle – Implementing our changes
  • Release- Using the change

All three of these are a risk-based approach, the amount of effort and rigor depends on how risky the change is. There are a few principles to keep in mind when developing that risk-based approach:

  1. Changes come in different sizes
  2. Keep your type of change control mechanisms to a manageable minimum.
  3. Have a consistent way of performing that assessment and moving between your change control mechanisms.

When I review 483s and other inspection trends one of the consistent areas is changes not going through a rigorous enough change management. They faltered on assessment, handling and/or release. It is pretty easy to put everything in the document control system and then miss a lot. (For example, those specification changes that don’t end up being filed in all appropriate markets).

So what do I recommend?

Ensure change management sits around and through document control. Build a set of standardized decision-making principles that allow a document revision to end up in the right size change control process (which can just be a document change) and then ensure there is a way to document and review those decisions. This allows us to drive continuous process improvements in this decision making.

Risk Management and Quality Intelligence

Kris Kelly on the Advantu blog brought to my attention a February post he wrote titled “Medical Device Recalls – Do You See the Pattern…?

While specific in intent to medical devices, the content is very relevant to my last post. Risk Management is a major enabler of quality system, and a big part of risk assessments is moving beyond the expected to find the unexpected.

The other part of the article that stood out to me was how this was a great example of regulatory intelligence as a part of knowledge management. Kris took a trend of medical device recalls and evaluated the need for action. And you should too. Regulatory intelligence should be informing your quality system, it needs to be an input to decision making from design through change management activities and every step of the way. Regulatory intelligence should be an input to your organization. This idea can be expanded to quality intelligence, which also looks at best practices, pharmacopeias and a whole assortment of inputs from agencies to industry associations to benchmarking with other companies.

To bring this post around to one of my long-term preoccupations, change management, the following request is found in 3 of the drug cGMP warning letters on the FDA website since the 01Mar2018.

A comprehensive, independent evaluation and remediation of your change management system. The evaluation should include, but not be limited to, assuring changes are appropriately justified, approved by your quality unit, and evaluated for effectiveness. Also, include a retrospective assessment of all changes executed outside an appropriate change management process.

Is your quality system strong enough? Have you evaluated the risks of your change management system? Are you prepared for your next regulatory inspection? How do you ensure you are evaluating these trends as they develop? Do you have a process in place to make sure you are not surprised?

 

Knowledge Management

ICH Q10 “Pharmaceutical Quality System” describes a lifecycle approach, from development through product discontinuation. The knowledge about a pharmaceutical product and the processes required to reliably produce that product starts with product and process development. An effective pharmaceutical quality system (PQS) uses the knowledge acquired throughout the lifecycle of the product, builds on that knowledge, and applies it to:

  • Other stages of the product lifecycle
  • Other product lifecycles

A change management system is defined as an important element of a PQS as seen in this figure reproduced from ICH Q10.

Q10

There are two enablers to this quality system model, knowledge management and risk management. The thing about those enablers is that they are really intertwined. Or put another way, risk management is a powerful way to make use of your knowledge.

ICHQ12 “Technical and Regulatory Considerations for Pharmaceutical Product Lifecycle Management” (in draft) expands on knowledge management and provides more examples of its use. The below illustration is an adaptation of one found in the draft Q12.

knowledge and change

There are many ways to tap into knowledge management in change management. The subject matter experts are critical, as is checklists and risk ranking and filtering tools. Knowledge should drive the development of an effectiveness review.

One of my favorite is the Living Risk Assessment approach. Living risk assessments are a holistic view of a system, product, or process in an effort to prevent risk realization. They are updated throughout the product /system lifecycle to continuously assess risks that may arise or change.

In the context of change management, the living risk assessment is both an input and an output. A rigorous, maintained, living risk assessment allows us to prospectively mitigate potential risks as part of our change management program.

Living Risk Assessments have a schedule, a review period (for example, once a year) to evaluate how risk has changed, drawing from all the sources of knowledge. It is also important to have a way to trigger adhoc reviews (for example, major process changes or critical deviations).

living risk assessments

In my ASQ World Conference workshop I will be going into more detail on knowledge management, risk management and the pharmaceutical quality system. I’ll also be discussing what non-Pharma companies can learn from the PQS.