Process

Why should we care about root causes?

So, there’s been an accident. Let’s patch everyone up and fix the bollard. Why do we care about how the accident happened? One of the reasons I enjoy training people is the questions they ask. Every time I run training, I get at least one question that really makes me think. And often, the question is surprisingly simple – on the surface at least. One of the areas I regularly train organisations on is root cause analysis methods and how issue management should link back to risk management. I presented on this topic at SCOPE Europe last year. So how intriguing it was at a recent training to get a question which I had not really considered in any depth before: why do we need root causes of an issue?

The stock answer is that knowing the root causes helps you to focus on those to try to reduce the likelihood of such issues recurring in the future. It means you focus on the issue at its fundamentals rather than just treating the symptoms. It is here that the realisation hit me – we are actually determining root causes primarily so we can reduce the risk of future issues. If we were not concerned about the risk of the issue recurring then there would be little point in spending time trying to get to root causes. And if it is about reducing the risk, then it is not just about the likelihood of the issue recurring. It could also be about the impact and possibly the detectability. We evaluate risks based on these three after all: likelihood, impact and detectability. For a traffic accident, if the root cause was that a child’s ball had rolled into the road and a car had swerved to avoid the child hitting the bollard instead we could:

- - Erect a fence next to the play area to stop balls going into the road (and children following them) – reducing likelihood
  - Reduce the speed limit near the play area to reduce the likelihood of serious injury – reducing impact
  - Erect motion sensors in the play area and link them to a flashing warning sign for road users – to improve detectability

Thinking of a clinical trial example: If the issue is that very few Adverse Events (AEs) are being reported from a particular site and the root cause is determined to be lack of site understanding on AE reporting then to reduce the risk we could:

- - Work with the site to make sure they understand the reporting requirements (to reduce the likelihood)
  - Review source data and raise queries where AEs should have been reported but were not (to reduce the impact)
  - Monitor the Key Risk Indicator for AEs per participant visit at a greater frequency for that site to see if it picks up (to improve detectability)

You may do one or more of these. In risk terms, you are trying to reduce the risk by modifying one or more of – likelihood, impact and detectability. And, of course, you might decide to take these actions across all sites and even in other studies.

And it brings me back to that thorny problem of corrective actions and preventive actions. Corrective actions work on reducing the risk of the issue recurring – whether it is reducing the likelihood, impact and/or improving detectability. If that is so, what on earth are preventive actions? Well, they should be about reducing the risk of issues ever happening – by building quality in from the start. Before a clinical trial starts, GCP requires that a risk assessment is carried out. And as part of the risk assessment, risks are evaluated and prioritised. The additional risk controls that are implemented before the start of the trial are true preventive actions.

It is unfortunate that GCP confuses the language by referring to corrective actions and preventive actions in relation to issue management rather than showing how they relate to risk. And from the draft of E6 R3, it appears that will not be fixed. ISO 9001 fixed this with the 2015 version. Let’s hope that one day, we in clinical trials, can catch up with thinking in other industries and not continue to confuse people as we do now.

As so often, we should ask the “why” question to get to a deeper truth – as encouraged by Taicchi Ohno. And I was very grateful to be reminded of this as part of a training program I was providing.

I have modified my training on both issue and risk management to show better how the two are intricately linked. Is your organization siloing issues and risks? If so, I think there is a better way.

No children, animals or balls were harmed in the writing of this blog post.

Bringing Processes into Focus

I have been leading a process integration from a merger recently. The teams provided their many long SOPs and I tried to make sense of them – but with only minimal success. So, at the first meeting (web-based of course), I said we should map the process at high level (one page) for just one of the organisations. People weren’t convinced there would be a benefit but were willing to humour me. In a two-hour meeting, we mapped the process and were also able to:

Mark where the existing SOPs fit in the high-level process – giving a perspective no-one had seen before
Highlight differences in processes between the two organisations – in actual process steps, equipment or materials
Discuss strengths, weaknesses and opportunities in the processes
Agree an action plan for the next steps to move towards harmonisation

Mapping was done using MS PowerPoint. They loved this simple approach that made sure the focus of the integration effort was on the process – after all, to quote W. Edwards Deming, “If you can’t describe what you are doing as a process, you don’t know what you’re doing.” At a subsequent meeting, reviewing another process, one of the participants had actually mapped their process beforehand – and we used that as the starting point.

Process maps are such a powerful tool in helping people focus on what matters – without getting into unnecessary detail. They help people to come to a common perspective and to highlight differences to discuss. We also use them this way at the Metrics Champion Consortium where one of the really important outcomes from mapping is the recognition of different terminology used by different organisations. We can then focus on harmonising the terminology and developing a glossary of terms that we all agree on. This reduces confusion in subsequent discussions.

Process maps are really a great tool. They are useful when complete, but so much more benefit comes from a team of people with different perspectives actually developing them. They help to bring processes into focus. And can even help with root cause analysis. If you don’t use them, perhaps you should!

For those that use process maps, what do you find as the benefits? And the challenges?

Picture – PublicDomainPictures from Pixabay

Go Step-By-Step to get to Root Cause

In an earlier post, I described my DIGR^® method of root cause analysis (RCA):

Define

Is – Is Not

Go Step By Step

Root Cause

In this post, I wanted to look more at Go Step By Step and why it is so powerful.

“If you can’t describe what you’re doing as a process, you don’t know what you’re doing” – a wonderful quote from W. Edwards Deming! And there is a lot of truth to it. In this blog, I’ve been using a hypothetical situation to help illustrate my ideas. Consider the situation where you are the Clinical Trial Lead on a vaccine study. Information is emerging that a number of the injections of trial vaccine have actually been administered after the expiry date of the vials. This has happened at several sites. You’ve taken actions to contain the situation for now. And have started using DIGR^® to try to get to the root cause. It’s already brought lots of new information out and you’ve got to Go Step By Step. As you start to talk through the process, it becomes clear that not everyone has the same view of what each role in the process should do. A swim-lane process map for how vaccine should be quarantined shows tasks split into roles and helps the team to focus on where the failures are occurring:

In going step-by-step through the process, it becomes clear that the Clinical Research Associates (CRAs) are not all receiving the emails. Nor are they clear what they should do with them when they do receive them. The CRA role here is really a QC role however – the primary process takes place in the other two swimlanes. And it was the primary process that broke down – the email going from the Drug Management System to the Site (step highlighted in red).

So we now have a focus for our efforts to try to stop recurrence. You can probably see ways to redesign the process. That might work for future clinical trials but could lead to undesired effects in the current one. So a series of checks might be needed. For example, sending test emails from the system to confirm receipt by site and CRA or regular checks for bounced emails. Ensuring CRAs know what they should do when they receive an email would also help – perhaps the text in the email can be clearer.

By going step-by-step through the process as part of DIGR^®, we bring the team back to what they have control of. We have moved away from blaming the pharmacists or the nurses at the two sites. Going down the blame route is never good in RCA as I will discuss in a future post. Reviewing the process as it should be also helps to combat cognitive bias which I’ve mentioned before.

As risk assessment, control and management is more clearly laid out in ICH GCP E6 (R2), process maps can help with risk identification and reduction too. To quote from section 5.0 “The sponsor should identify risks to critical trial processes and data”. Now we’ve discovered a process that is failing and could have significant effects on subject safety. By reviewing process maps of such critical processes, consideration can be given to the identification, prioritisation and control of risks. This might involve tools such as Failure Mode and Effects Analysis (FMEA) and redesign where possible in an effort to mistake-proof the process. This helps to show one way how RCA and risk connect – the RCA led us to understand a risk better and we can then put in controls to try to reduce the risk (by reducing the likelihood of occurrence). We can even consider how, in future trials, we might be able to modify the process to make similar errors much less likely and so reduce the risk from the start. This is true prevention of error.

In my next post I will talk about how (not) to ‘automate’ a process.

DIGR^® is a registered trademark of Dorricott MPI Ltd.