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.

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.

Data Integrity in the quality system

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.

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:

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.

FDA Cycle Times and Compliance

Mark Schwarz reviews FDA compliance times in “Does FDA Need Statutorily Imposed Incentives for Regulatory Compliance Matters?” at FDA Law Blog (a must read blog for those in pharmaceutical, medical device or food quality). I found these cycle-times fascinating.

It also amazes me that after the last few years of the agency pushing quality metrics, this is the first time these numbers have been shared. I deeply hope they drive improvements.

Given these lead times I find it interesting that the FDA has taken to pointing out the need for a consultant in warning letters. By the time a warning letter is obtained, a meeting perhaps held, and a consultant obtained it is easily a year before real work is happening. This does not provide the most nimble of approaches.

Again, a good article I strongly recommend.

Barriers and root cause analysis

Barriers, or controls, are one of the (not-at-all) secret sauces of root cause analysis.

By understanding barriers, we can understand both why a problem happened and how it can be prevented in the future. An evaluation of current process controls as part of root cause analysis can help determine whether all the current barriers pertaining to the problem you are investigating were present and effective (even if they worked or not).

At its simplest it is just a three-part brainstorm:

Barrier Analysis
Barriers that failed	The barrier was in place and operational at the time of the accident, but it failed to prevent the accident.
Barriers that were not used	The barrier was available, but workers chose not to use it.
Barriers that did not exist	The barrier did not exist at the time of the event. A source of potential corrective and preventive actions (depending on what they are)

Three questions of barrier analysis

The key to this brainstorming session is to try to find all of the failed, unused, or nonexistent barriers. Do not be concerned if you are not certain which category they belong in.

Most forms of barrier analysis look at two types, technical and administrative, and we can further breakdown administrative into “human” and “organization.”

Choose

Technical

Human

Organization

A technical or engineering control exists

The control relies on a human reviewer or operator

The control involves a transfer of responsibility. For example, a document reviewed by both manufacturing and quality.

Examples

Separation among manufacturing or packaging lines

Emergency power supply

Dedicated equipment

Barcoding

Keypad controlled doors

Separated storage for components

Software that prevents a workflow from going further if a field is not completed Redundant designs

Training and certifications

Use of checklist

Verification of critical task by a second person

Clear procedures and policies

Adequate supervision

Adequate load of work

Periodic process audits

These barriers are the same as current controls is in a risk assessment, which is key in a wide variety of risk assessment tools.