RTSM Design – The Tip of the Iceberg

Known by a variety of different names (IVRS, IWRS, IRT), Randomization & Trial Supply Management (RTSM) has existed for around 20 years and is key to running a successful trial. In the clinical trials landscape, RTSM is either viewed as a newer system or a mature solution depending on the sponsor organization involved. This either results in RTSM being a high visibility, critical path system for a trial, or something that is almost an afterthought. The industry needs to re-emphasize RTSM as a critical path, high-impact system to ensure smooth trial conduct, but for different reasons than are traditionally considered. 

In its initial inception, RTSM was simply a tool designed to manage randomization in order to achieve the randomization balance required for the study, and reduce product waste by allocating drugs to patients at the time of need, not at time of shipment. Historically, randomization was managed by shipping kits to sites in blocks of a fixed size, with randomized supplies in each block. Each kit was packed to include all the medication a single patient would require for the length of their treatment. If handed out in sequence, with the whole block consumed, the required study balance was achieved. This method is inherently wasteful, especially if a site does not use all kits or a patient is withdrawn from the study before treatment completion. Clearly, there was a need for more structured management of supplies and randomization. 

RTSM has grown in scope over the years to solve this and other study conduct problems, and has evolved with the increasing needs of study teams and the complexities of trial operations. Where previously it was sufficient to develop RTSM studies using per-study custom programming as the main development method, the industry has required ever decreasing timelines, necessitating the need to move to RTSM platforms that enable per-study configuration. 

As RTSM has evolved, sponsors have pushed the industry to deliver on a laser-focused goal: go-live of an RTSM system for a study in a matter of weeks, regardless of complexity. This is very much in reaction to what Sponsors have deemed necessary over the years, based on their previous experience and RTSM requirements. Signant has evolved its platform to ensure consistent delivery to these expectations. That said, we must consider if this concentration on delivery timelines alone is the right focal point. 

The Standard RTSM Roadmap 

In the clinical trials industry and others, we concentrate on key milestones. In drug development, we think about production and distribution timelines. From a clinical standpoint, we split trials up by phase and talk of study start and close, of site activation dates, and others. Thinking about those milestones gives us an indication of the study’s complexity and the management required to ensure that the trial starts successfully. Milestones are, without doubt, an important consideration in any study. 

If we think about the number of items required before even thinking about what systems to use for the particular study, we can see the sheer volume of work that is needed to develop a clinical trial, let alone those systems. 

Study activities prior to RTSM 

There is often a consistent pattern of conduct where RTSM is one of the later decisions to be made in clinical trials – this standard process is less than ideal and has its consequences.  

Study activities including RTSM 

Let’s consider the typical RTSM development process for a study. There are effectively two ways these systems are developed, a more traditional waterfall approach versus a more agile approach, depending on the vendor/platform in use. 

A traditional waterfall approach assumes that requirements are gathered up front, translated into an RTSM study, and tested internally. Assuming the testing is successful, then access is granted to the Sponsor or CRO to perform User Acceptance Testing (UAT). Again, assuming the testing is successful, the study goes into production. Since the Sponsor/CRO sees the RTSM late, the likelihood of changes and misinterpretation of requirements is high, which requires rework. 

Waterfall RTSM Development Cycle 

An agile approach, like the one performed at Signant, solves the potential issue of findings at UAT due to the Sponsor’s use of the study later in development. 

Agile RTSM Development Cycle 

RTSM systems are designed from a combination of the study protocol requirements, the study team’s requirements (based on their knowledge of what is not said in the protocol), and the standards defined between the sponsor and the RTSM vendor. Once the RTSM system is designed and configured, it is ideally shown to the sponsor and/or CRO and changes are made before entering formal validation. Assuming that testing by the vendor is successful, the study is delivered for client UAT. This step is hopefully a simple one, given the combination of early visualization and standards, which should keep UAT to a minimum. Again, assuming no changes are required, the system then moves into its go-live phase. 

Why does this process exist? What drives the need to develop RTSM in this way, and within these shortened timelines? If we add a single box to the previous flow, the answer is clear. It is the one milestone that cannot be moved by a vendor, First Patient In (FPI). 

There are many reasons why FPI is an important milestone in a study: it is when the first patient enters the study and predictions around the study close begin to become more of a reality. We must remember that this is the other key milestone, especially in Phase 3 studies. Only once Phase 3 concludes and approval is given can a drug go to market and start to recoup the study’s considerable R&D budget. 

The thing that is often not considered is the amount of time between the two key study milestones of FPI and Database Lock, and the eventual study close.  

RTSM and the Iceberg 

Forgive me for this analogy, but I think about RTSM as two things: a set of Lego™ building blocks or Microsoft Office. Either way, you have a standardized set of functionalities that enables the configuration of whatever you want. With the Lego™ analogy, it’s all about picking the right blocks to make whatever you need, whether that’s a spaceship, castle, or car. With Microsoft Office, if you want to create a letter or presentation and then include a table, picture, or graph in your document, you can. If you want to create a spreadsheet and use it elsewhere, you can. To carry the analogy forward, assuming the function or the brick is available, there is no limit to what you can achieve. RTSM platforms should act in a similar way, offering functionality that can be used in a multitude of ways for any study design, no matter how complex. 

Our industry requires that we measure RTSM system build times in weeks. Over time, RTSM vendors have all updated software and processes to facilitate this requirement. Vendors have simplified tooling, standardized processes, and increased knowledge of what is required and what can be done in that period. We, the vendors, have also integrated RTSM with other systems and made APIs so that data is more accessible. RTSM vendors have done their level best to meet the perceived needs of the industry that these platforms operate in.  

Now, let’s compare and contrast the “Build” phase where RTSM development occurs and the “Live” phase where the system is in use. 

The graphic here will no doubt give away my point. The industry considers RTSM build in weeks, yet if we think about that using the concept of an iceberg – both vendors and sponsors are quite clearly missing something. 

Icebergs are fascinating things; the standard wisdom is that regardless of size, 90% of any one iceberg is underwater. In the same way that most nature documentaries focus on ice falling into the sea, we as an RTSM industry primarily concentrate on what is above the surface rather than under, and we do not think about the consequences of the surface falling into the sea. 

So, if 90% of an iceberg is underwater and we know that the average length of Phase 3 clinical trials is 1 to 4 years, that means that the RTSM study will run far longer than the initial Build phase. 

Expressed as an iceberg, our system lifecycle actually looks like this. 

This means that our focus on FPI is important but is not the be-all-and-end-all of RTSM study and platform development. 

Change is inevitable 

Over the years, protocols have become more adaptable, which can result in a multitude of potential RTSM changes. As an RTSM vendor, Signant experiences this every day. When changes are required to an initial build after the study goes live and subjects are already enrolled, we introduce risk to our RTSM system, whether we are adding an arm or more visits, amending the dispensing design, adding another pack type, or amending reports or integrations.  

Getting the right drug to the right patient at the right time is critical to successful RTSM, so these amendments will also directly impact every patient in the trial. So, what can we do differently? 

RTSM vendors will all sell the merits of their platforms, and they are right to do so. These platforms are technological marvels that have helped clinical development become what it is today. But for all that technological prowess, it is equally as important that RTSM vendors have the appropriate expertise.  

On average, Signant Health is involved in over 1000 studies a year across its portfolio of products, across as many therapeutic areas as you could think of. This means we have a wealth of knowledge that can be leveraged when developing an RTSM system. So, if there is this wealth of expertise within Signant and other vendors, why does the industry require that vendors compress RTSM development and scope to meet a milestone of FPI, knowing that change is inevitable? 

I am certainly not saying that change is a bad thing – change is good if performed correctly. But if we shift our perspective on which milestones are important, we can improve the situation. It is far cheaper to add in some complexity today than it ever is to change a study that is in-flight where the risks are higher. 

I would like to see an industry where RTSM is considered earlier in the study process to allow for proper consideration of the proper design for go-live, instead of rushing to FPI. I would also love to see RTSM studies developed with change in mind to enable fewer post-go-live amendments, reduce downtime, and reduce complexity or risk from amendments.  

In RTSM development, both per study and for the platforms themselves, let’s consider what lies beneath the waves. 

James Stringer

Senior Product Manager