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.
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.
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.
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.
Data integrity has been, for the last few years, one of the hot topics of regulatory agency inspections, one that it has often been noticed seems to be, at times, a popular umbrella for a wide variety of related topics (that usually have a variety of root causes).
Data Integrity is an interesting grab bag because it involves both paper and electronic data. While some of the principles overlap, it sometimes can seem nebulous, Luckily, the MHRA recently published a final guidance on GXP Data Integrity that ties together several threads. This is a great reference document that lays out some key principles:
Organizational culture should drive ALCOA
Data governance is part of the management review process
Data Risk Assessments with appropriate mitigations (full risk management approach)
I love the snarky comment about ALCOA+. More guidances should be this snarky.
The FDA so far this year has been issuing warning letters and 483s in more traditional GMP areas, such as testing and validation. It will be curious if this lessening of focus in a subtle shift in inspection, or just the result of the sites inspected. Either way, building data integrity into your quality systems is a good thing.
Processes and tools for the prevention, detection, analysis, reporting, tracking and remediation of noncompliance to data integrity principles should be integrated into the Quality Management System to:
Prevention of data integrity issues through governance, training, organizational controls, processes, systems underlying and supporting data integrity.
Detection of data integrity issues through leveraging existing Quality Systems, tools and personnel.
Remediation of data integrity issues through leveraging existing Quality Systems that identify and track implementation of corrective/preventive action(s).
Some ways to integrate includes:
Data integrity training for all employees
Include as an aspect of audits and self-inspections
Controls in place to ensure good documentation practices
good validation practices
Computer system lifecycle management (include audit trail reviews)
Ensure your root cause investigators and CAPA people are trained on data integrity
Data integrity as a critical decision point in change management
Data integrity, like many other aspects of a quality culture, are mindsets and tools that are applied throughout the organization. There really isn’t a single project or fix. By applying data integrity principles regularly and consistently you build and ensure. A such, data integrity is really just an affirmation of good quality principles.
“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.
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:
Changes come in different sizes
Keep your type of change control mechanisms to a manageable minimum.
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.