You are sitting with a group of people around a table in a conference room. On the wall, a monitor displays a spreadsheet showing the inputs and outputs of a complex manufacturing process in a vast matrix. The purpose of the meeting is to assign risk values for each input and output for the different unit operations in your process. The meeting quickly bogs down as attendees start asking what the different risk values mean, 3 or 4, 7 or 8. What is the difference between a 3 and a 4, or a 7 and an 8? Two other people, one from the formulation team and one from the Quality team, are debating whether a risk is medium or high. Decisions are made, justifications are written in a notebook or on a post-it note. Then, another team member asks how to assess the risk of the outputs in this unit operation to downstream unit operations. The meeting leader says that this has to be done in another spreadsheet tab of the workbook. The meeting gets bogged down yet again when the Quality group starts asking for documentation and data to substantiate these risk ratings.
For very complex processes, these spreadsheets can have many tabs and can contain large amounts of information. At the end of the meeting, you have only made it through one unit operation and there are still six to go! You wake up in a sweat realizing you were dreaming…..or maybe you weren’t dreaming. Unfortunately, this is the status quo and repeated at many companies around the world today. If this scenario is familiar to you, then you know that the process of risk assessment is very frustrating and often viewed as a chore, a box to check, something not really providing value.
This blog post series is intended to rationalize and standardize the risk assessment discussion to communicate strategies that provide consistency, objectivity, and risk understanding. Over the next few weeks, we’ll be sharing strategies and approaches that explain how to manage these situations. These are sourced from industry-leading experts, customer input, and our own experiences.
Today, we’ll start with the core: defining some common terms.
A Common Structure
The first thing to know is that there is no single, all-encompassing definition of risk in the Pharma industry or any other industry for that matter. The reason, of course, is that the context of risk has to be defined relative to a subject and an object. That is, it is “the risk of impurities to patient safety” or “the risk of a gas leak to operator safety”. Given the different types of subjects and objects, different risk methodologies and accompanying definitions have been created such as FMEA, HAZOP, HACCP, etc.
With these different risk methodologies, there is an underlying structure that is common to different methodologies. The general, underlying structure follows the definition and logic described below.
- Hazard – This is the answer to the question, “What can go wrong?”. The Hazard is essentially a deviation from a specification or the design or operating intent of a parameter (e.g. gas leak).
- Potential Causes – The causes or potential causes of the hazard should be identified (e.g., incorrectly installed valve leads to gas leak).
- Harm/Consequences – The existence of the hazard can lead to harm or consequences which need to be defined (e.g. a gas leak can lead to an explosion).
- Impact/Severity – If the harm or consequence were to be realized, what would the impact or severity of the harm be to the patient, end-user, or downstream process? If there is an explosion, how would it affect the operator in the room? If it could kill the operator, then the impact/severity would be very high.
- Probability/Occurrence/Frequency – How likely is it the harm or consequence will occur? For example, if there is a gas leak that could lead to an explosion. How likely is the explosion? This concept is a bit muddled because it is more specifically defined as the Probability of Occurrence of Harm which includes both the probability of there being a gas leak and the gas leak leading to an explosion. We will explore this more carefully in the next section.
- Risk – This is a value to provide an estimate of relative risk usually calculated as the product of Severity and Occurrence.
- Safeguards/Mitigation – Once a risk is estimated, it is important to define and discuss potential safeguards or risk mitigation strategies to lower the risk usually by lowering the occurrence. If a safeguard or mitigation can be implemented that eliminates the hazard, then the risk can be permanently lowered. (e.g. gas valve includes automatic leak detection which immediately shuts off the value.)
- Control Strategies – Control strategies are closely related to the idea of safeguards and mitigation activities. However, the concept differs slightly in that control strategies are methodologies or activities that can be employed to manage any residual risk (e.g. sensor installed in the room to alert personnel inside to any gas leak so the gas valve can be manually shut off). This is sometimes modeled as another layer of risk called Detectability or Controllability. The overall risk then becomes the product of all three layers (severity * occurrence * detectability).
- Detectability/Controllability – How easily, and more importantly how early on, can you detect the occurrence of the deviation? The further in the process a deviation is detected the less likely you are to detect or control it before it can cause harm.
Simple enough, right?
Now that we have our terms defined, next week we’ll explore how these definitions intersect with ISO 14971. Even though this standard is designed for medical devices, a number of the definitions just reviewed are found in this standard and are applied to other sectors such as the pharmaceutical/biotech industry (ICH Q9). Our next post will cover how to use the concepts of ISO 14971 to create a generalized framework for risk management that works across pharma and is compatible with (and leverages the best parts from) medical devices.
This post is part 1 of 7 in a series on practical risk management for pharmaceutical process development. Tune in next week for a discussion on ISO 14971.
