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.

Risk Filtering – A popular tool that is easy to abuse

An article titled “ICE Modified Its ‘Risk Assessment’ software So It Automatically Recommends Detention” is probably guaranteed to reach me, for a myriad of ways.

I believe strongly in professional codes of conduct, and the need to speak out. In this case, I am thinking of two charges:

Hold paramount the safety, health, and welfare of individuals, the public, and the environment.
Avoid conduct that unjustly harms or threatens the reputation of the Society, its members, or the Quality profession.

Reading this article, and doing some digging, tells me that the tools of quality that I hold dear have been abused and I believe it is appropriate to call that out.

Now, a caveat, risk assessment, and management have some flavors out there and I’ll be honest that I once made the mistake of getting into a discussion with a risk management expert from a bank and realizing we had very different ideas of risk management. But supposedly we’re all aligned (sort of) to ISO Guide 73:2009, “Risk management. Vocabulary.” And as such, I’ll try to stick pretty close to those shared commonalities. I also assume that ISO Guide 73:2009 is a shared point between me and whoever designed the ICE risk assessment software.

Risk assessment is one phase in risk management, and I’ll focus on that here. Risk assessment is about identifying risk scenarios. What we do is:

Establish the context and environment that could present a risk
Identify the hazards and considering the hazards these risks could present
Analyze the risks, including an assessment of the various contributing factors
Evaluate and prioritize the risks in terms of further action required
Identify the range of options available to tackle the risks and decide how to implement risk management strategies.

A look at the decision making around this found in the Reuters article, leads me to believe that what ICE is using meets these criteria and we can call it a risk assessment (why it is in quotes in the Motherboard article mystifies me).

There are a lot of risk assessment tools out there. it is important to know that risk assessment is not perfect, and as a result, we are constantly developing better tools and refining the ones we have.

My guess is we are seeing a computerized use of the risk ranking and filtering tool here. Very popular, and something I’ve spent a great deal of time developing. This tool involves breaking a basic risk question down into as many components as needed to capture factors involved in the risk. These factors are then combined into a relative risk score for ranking. Filters are weighting factors used to scale the risks to objectives.

And that is where this tool can often go wrong. It appears ICE under the Trump administration has determined its objective is to jail everyone. By adjusting the filters, the tool easily drives to that conclusion. And this is a problem. Here we see a quality tool being used to excuse inhumane policy choices. It is not the ICE agents separating families and jail people over a misdemeanor, it is the tool. And if that doesn’t strike to the heart of the banality of evil concept I’m not sure what does.

I could go deeper into the tool, how I would have built it, the ways you validate the effectiveness of it. And that all probably will make an excellent follow-up someday. But the reason I’m writing this post is primarily that I read this article and it dawned on me that someone very similar to me in skill set probably created this tool. Someone who maybe I’ve sat across the table at a professional conference, who has read the same articles, probably debates the same qualitative vs. quantitative debates. And this is a great example of when its necessary to speak up and criticize a tool of my profession being used for evil. I probably will never talk to the team who developed this tool, but we all see instances of companies around us being asked to build similar applications, using the tools of our profession, that will be used for the wrong results. And we owe it to our code of ethics to refuse.

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.

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.