Igor Stefanov
CEO @ SRG CRO & A Kingsman @ ACROSS Global™

Even though I’m an engineer by my first education, I don’t believe solely in technology. I believe in common sense and good reasoning. Both are rare nowadays. The pharmaceutical industry is no exception. Risk management isn’t anything but common sense. Risk Based Monitoring (RBM) is one of the first steps in bringing back common sense into clinical trials.

First Failure

Our first attempt to implement RBM back in 2013 failed. I found TransCelerate Risk Assessment and Categorization Tool (TC RACT) on their Website and realized that it could give us a certain competitive advantage as a CRO. Nevertheless, I couldn’t assess its practical value at that time, since I’m not a clinical trial professional. I prepared a short presentation for my management team and asked everyone to take those TransCelerate questions which relate to their specific area (Medical Writing, Regulatory Affairs, Data Management etc.) and evaluate whether they can be applied in practice. After three weeks of flaccid discussions, only six questions were selected and absolute majority voted not to proceed with the methodology. We got back on the traditional track to the formal risk management standard operating procedure which was already in place. That was one of my major management mistakes.

Second Try

As time went on, the inevitability of RBM became obvious, and shortly before the “ICH risk based addendum” introduction, we’d come back to the question again. This was our second try. I promised to myself that we wouldn’t give up this time. It became a question of life and death (read more here to understand, why).

The start was very similar to the first attempt. Everyone was quite skeptic about TC RACT applicability in practice. At least, the small local CRO practice. Nonetheless, we proceeded. We set up the working group and created an RBM board in Trello (our preferred project management tool). This time we decided to apply the agile approach and move forward in small steps having a minimum viable product (MVP) at the end of each step. (Read more about agile approach in clinical trials here.)

After six weeks of brainstorming we identified a broad range of TC RACT’s methodological and practical drawbacks and we had to rethink and redefine a number of its concepts and ideas. In addition, I soon realized during our brainstorming sessions that everyone had their own understanding of the terms. We used the same words, but didn’t understand each other. It led us to a state of near total confusion and misunderstanding. But I didn’t want to give up again.

No matter how far you’ve gone down the wrong road, turn back (Turkish proverb)

TransCelerate RACT Drawbacks

So, we’ve turned back and started again from the very basis, the definition of risk itself which TransCelerate RACT lacks. The risk management theory requires a solid foundation, without a clear definition of risk and its understanding we were like a foolish man who built his house on the sand. After three weeks of research we’ve stuck to the ISO 3100:2018 definition of risk as being ‘’the effect of uncertainty on objectives”. This definition is clarified by a note to the definition stating that risk is usually expressed in terms of risk sources, potential events, their consequences (the effect on study objectives or impact, if you want to stay in line with TC RACT) and their probability (not just likelihood).

Detectability is Awful

Secondly, for the purpose of further risk quantification and measurement during study conduct we’ve eliminated Detectability, since you cannot control what you cannot detect. The consequences were twofold:

1. The risk got back its physical sense, i.e. now you can better understand the effect of uncertainty by objectives. For example, I have $100 in my wallet, and the probability of lost is 0.3, then the impact of lost will be 0.3 X $100 = $30. Crystal clear.
2. When validating the original TransCelerate RACT model among our Project Mangers, the Detectability was one of the most uncertain areas which resulted in the highest variability. Taking into account the well known TransCelerate RACT’s subjectivity issue, the less subjective variables we have, the better.

As a matter of fact, we didn’t simply exclude the Detactability at all, for the pupose of initial simplification we assumed Detectability as a constant of 1 and reserved it for further use. Once the overall model matures, the category can be easily introduced again.

The other idea behind such approach is once we identify risk, it automatically becomes detectable even if at the assessment stage we didn’t know how to detect it using the traditional approaches. The project team then starts thinking about how it can be detected, and finally will come back with solution. This is how creativity and innovations work.

Think Big

Most of CRO risks are operational, so they cannot be tied directly to TransCelerate RACT categories of subject safety, data quality and regulatory compliance. We’ve introduced traditional project’s “iron triangle” categories of speed, cost and quality (Synergy’s Troika). The latter is the most important and tied directly to all three categories of TransCelerate RACT. As a matter of fact, in my personal opinion, CRO quality is a binary value (either 0 or 1) and a multiplier for all TransCelerate’s three categories. At Synergy, we understand quality as being “an absence of risk of not collecting enough accurate data to verify a study hypothesis”.

Finally, the particular risks and risk indicators depend on the responsibility matrix and their number vary for different outsourcing models, i.e. functional or full service models. Obviously CRO cannot be responsible for patient recruitment, if it’s only supposed to submit the CTA.