In Part 4 of this series on Quality by Design we propose a simple method for identifying critical-to-quality factors, articulating risks, and planning mitigations.
As we saw in Parts 1, 2, and 3, the term "critical-to-quality" factor is subject to confusion. ICH E8 and industry tools all mix up underlying factors, risks, and mitigations. We would propose the following definitions:
Critical-to-quality factors are the activities that enable protection of participants or collection of data for primary safety and efficacy endpoints. For example, if patient-reported outcomes are a primary endpoint, then ePRO system development, testing, release, use, and data management are critical-to-quality factors.
A risk is a condition that increases the likelihood of a negative impact to a critical-to-quality factor. For example, if use of your ePRO system is dependent on a cellular network, and the cellular network in a particular country is prone to outages, then the risk can be articulated by saying, "Service disruptions in country X increase the likelihood of missed ePRO assessments."
Conditions that are prone to raising risks are as follows:
- Complexity
- Novelty
- Time pressures
- Layers (for example, use of vendors and sub-contractors, or multiple review committees - any organizational arrangement that slows things down and reduces transparency)
- Resource constraints or deficits
- Environmental issues like war, political conflict, strikes, or weather that could be disruptive
A mitigation is a step above and beyond the controls you would typically employ to reduce the likelihood of the negative impact. For example, if the team decided to address the risk of cellular outages by having participants in that country complete paper diaries, that's a mitigation, because it's not something they would typically do.
We've also developed a few principles to help guide this activity.
Save a tree. By focusing on participant safety and primary endpoints, we will naturally identify the things that are most important. No need for lengthy checklists or three-axis scoring systems. For a discussion of why scoring is actually counterproductive, see here.
Save another tree. Focus on risks that aren't controlled by our usual methods. For example, if we're using ePRO, there is a risk that the data collection forms will have errors - but that's a common risk that is already controlled by our specification and testing process. We would only cite this as a risk if there were something special or unusual about the form design.
Save a third tree. Only capture mitigations that are not standard. This principle goes hand in hand with the second tree. We frequently see study teams who use their RACT to list every common clinical research risk, then self-congratulatorily (why yes that is a word) cite every common control measure - site monitoring, medical monitoring, and data review - as mitigations, leaving them essentially with nothing new to do to address risk. Don't be that team! Identify what is really important and risky and then plan extra measures to address those risks.
