IRT Commandment #6

The Randomization Schedule Is Sacred & Shall Not Be Modified

There’s a question that surfaces sooner or later in many studies:

“This patient was randomized in error; can you just remove them from the list?”

It sounds reasonable. It never is.

Why This Matters

Randomization is not a visit. Randomization It is a moment in time, a discrete system action that assigns treatment based on the information available at that exact moment.

Once it happens, it becomes part of the study’s permanent record.

Any attempt to remove, adjust, or “clean up” that action undermines the integrity of the randomization process itself.

The Risk You Inherit

When a randomized subject is removed, the questions don’t stop at why the error occurred. They multiply:

• Was the subject removed because the allocated treatment was undesirable?

• Was the decision influenced by emerging data?

• Was someone trying to improve the apparent performance of the study?

Even if none of those things are true, the optics alone can be damaging.

Intent-to-treat principles exist precisely to protect against these risks.
Undoing randomization, even with good intentions, cuts directly across that protection.

System Record vs. Clinical Record

The data used at the moment of randomization, whether later found to be correct or not, is the data that actually determined the treatment assignment. That record must not be changed.

If more accurate or corrected information becomes available later, it should be captured as new/revised clinical data and documented appropriately. It should not be used to rewrite the randomization history.

The clinical record can evolve, but the randomization record cannot.

Trying to correct randomization after the fact does not improve data quality. It undermines the credibility of the process itself.

A Line That Shouldn’t Be Crossed

Once a subject is randomized, that record must stand, even if the subject is later withdrawn, deemed ineligible, or never dosed.

That’s not rigidity, that’s integrity and scientific rigor.

IRT Commandment #5

Thou Shall Think Long and Hard About Reconciliation

Reconciliation is a heavy resource activity that, under most circumstances, should not be undertaken.

This commandment is part of a larger, consistent story — using the IRT for its primary purposes (Commandment #1), understanding the nature of the data (Commandment 3), and sending very little data to the EDC (Commandment #4). If you internalize those principles, this one becomes obvious.

If you don’t, reconciliation becomes inevitable.

A Mindset Problem

If you recognize that the IRT is a tool, not a data collection or data management system, you’re already in the right mindset to understand why reconciliation should be rare. Many sponsors do not do it at all.

If, however, you think of IRT as an eCRF or as a secondary data management system, you will inevitably paint yourself into the reconciliation corner.

Once that happens, every difference looks like an error.
And every error demands explanation.

What IRT Must Be the Source Of

There are typically only two data elements that the IRT must be considered the source of — because it is the place where the data is first created:

• Randomization (date, time, and treatment assignment)

• Assignment / allocation of IMP to the subject

These are system acts. They happen in IRT by definition.

Reconciling these data points against another system is unnecessary and, in many cases, illogical.

A Sensible Extension

Some sponsors choose to go further and designate IRT as the source of what was dispensed to the subject — not just what was assigned or allocated.

I support this approach.

It further minimizes reconciliation and clearly establishes the IRT dataset as the source of truth for IMP activities, rather than forcing EDC to play that role.

This is not about moving data into IRT for convenience. It’s about assigning ownership where it naturally belongs — which is central to deciding whether reconciliation is necessary at all.

Even Strata Doesn’t Always Need Reconciliation

I’ll go one step further.

You could reasonably argue that strata data doesn’t need reconciliation at all, because the data entered into IRT — correct or not — is the data that was actually used to perform the randomization. It determined in that moment the treatment assignment.

That makes it operationally true, even if it later turns out to be clinically incorrect.

The truth can live in EDC.
The action lives in IRT.

Those two things are not the same — and that distinction matters.

We’ll come back to this in Commandment #6.

The Takeaway

Reconciliation should be intentional, limited, and justified — not automatic.

If you design IRT for its primary purposes, understand the nature of the data, and limit integrations, most reconciliation simply disappears.

And that’s not a risk.
That’s maturity.

Next up: Commandment 6 - The Randomization Schedule Is Sacred & Shall Not Be Modified

IRT Commandment #4

Thou Shall Limit IRT to EDC Data Point Integrations

In EDC integrations, less is more.

When sponsors limit and standardize what flows between IRT and EDC, they gain consistency, stability, and predictability.

It has been my experience that when each study starts from scratch with determining what data points to send to EDC, you compromise timelines and quality for both IRT and EDC vendors

Consistency is not a luxury. It’s an accelerator.

Use A Simple, Repeatable Standard

After watching what works (and what doesn’t), I’ve settled on a simple best practice:

Only send what is required to establish:

·       The existence of the participant

·       Their basic identifiers

·       Their randomization or enrollment transaction date

That’s it. By going beyond this, you welcome the death spiral of “system of record” or the “reconciliation loop of doom”. More on that in Commandment #5.

The Payoff

Sponsors who limit integrations don’t lose information — they regain control.

They:

• Standardize implementation

• Simplify vendor coordination

• Reduce review cycles

• Minimize reconciliation

• Scale more easily

Integration discipline pays off everywhere: operations, quality, timelines, and sanity.

I would feel sorry for my IRT brethren who had to struggle with EDC integrations at the start of every study. I never had to answer the question, "What do we need to send?" which meant we never had to worry about whether the IRT to EDC integration would be ready at go-live. It was always ready every single time, without exception, because we never had to struggle with that question.

Profit from my experience

Next up: Commandment 5 — Thou Shall Think Long and Hard About Reconciliation.

IRT Commandment #3

Thou Shall Not Conflate Visit Date & Transaction Date…or Reconcile Them

In IRT, few misunderstandings create more noise — or more reconciliation work — than confusing Visit Dates with Transaction Dates. Too much time, too much money, and too many human hours are spent trying to force these two dates to match, as if difference automatically implies error.

It doesn’t.

Let’s Level-Set the Definitions

Visit Date
When the patient shows up and the site conducts clinical activities.
This is the clinical timeline.

Transaction Date
When the IRT action occurs; randomization, allocation, acknowledgement of shipment, etc.
This is the system timeline.

They live in different domains for a reason. One reflects the patient’s reality; the other reflects the system’s record of operational actions. They can both be accurate even when they’re not the same.

Trying to force alignment is like trying to make EDC and IRT identical — and that brings us right back to Commandment #1 (https://www.irtadvisorsgroup.com/unblinded/irt-commandment-1).

They’re built for different jobs.

A Legacy Problem With a Long Shadow

IRT doesn’t manage visits — it manages IMP allocation for visits. But the industry’s early language (“visit-based IRT”) created expectations that have never fully gone away. The genie is out of the bottle, and it refuses to climb back in.

So teams inevitably ask:

“Why is the IRT visit date wrong?”

And that’s where the unnecessary work begins:

• Extra data fields “just to be safe”

• New integration rules

• Reconciliation loops that were never needed

All to fix a “problem” that isn’t actually a problem.

The Modern Misstep

To address the confusion, some vendors now store two dates inside IRT:

• Transaction Date

• Visit Date, which is just a direct copy of Transaction Date waiting to be corrected… ugh

This subtly reinforces the wrong idea that the IRT should be a place to manage visit dates.

It shouldn’t. That’s EDC territory.

There are far better uses of time, budget, and cognitive energy than trying to reconcile dates that were never meant to align in the first place.

Understanding the distinction helps simplify integrations, reduce reconciliation, and prevent IRT from becoming a shadow EDC — which leads us to Commandment 4.

Next up: Commandment 4 — Thou Shall Limit EDC Data Point Integrations

IRT Commandment #2

Thou Shall Not Defer Functionality

This one might start a fight

I recognize my opposition to this practice is a bit controversial in the IRT space. This is primarily true because it is common practice and promoted by both sponsors and vendors. 

When timelines are short and teams are focused on the “go live date”, they often choose to defer limited IRT functionality to a future 2nd or even 3rd release to reach first patient in (FPI) deadline. My experience has repeatedly demonstrated that this approach leads to

·       Inefficiencies  

·       compromised quality

·       regulatory misalignment

I have been the victim of a deferred functionality quality failure. The cause of the failure was directly attributed to the functionality being designed and implemented after the initial “go live”. When the change was deployed the context of this feature within the broader system and its downstream impacts were not fully understood. This is even more likely to happen when “Change Control” development resources are brought in rather than the original development team.

In a past life, my organization had a finding by a regulatory authority because we put a system live that was not 100% in alignment with the protocol as written, having chosen to defer functionality that was not immediately needed. I was surprised by the finding but the discussion with the inspector helped me see the light. The expectation was that even a protocol with a long open label run-in period must deploy unblinding in the initial go live if there is a future blinded part of the regimen.

I wish every IRT provider and sponsor would run this simple exercise; Review your IRT go live date with the date of first action or first site activated. The notion that IRT is the rate limiting factor for studies to go live is simply nonsense. I won’t tell you how long it was when I reviewed data from my organization but let’s just say it was looooong. You’re trying to solve for a problem that is unlikely to be a real problem while creating a whole host of others that can absolutely sink your study.

I know this is hard. Particularly when every voice in your ear is saying “this is the most important study in the company”. If this is true, then treat it that way with the highest degree of quality and not just speed.

Up Next Commandment #3- Thou Shall Not Conflate Visit Date & Transaction Date

IRT Commandment #1

The IRT system is to serve only its primary purposes

Every good belief system starts with a first commandment — and in IRT, this is where most heresies begin. Before we debate integrations, reconciliation, or user experience, let’s start simple: what is IRT actually for?

The primary purpose of an IRT system

·       enroll/randomize patients

·       provide a system to manage IMP from release through to return/destruction,

·       mechanism to unblind patients.

It provides some great downstream benefits like reporting for project management, but those are by-products not primary responsibilities.

Too often an IRT system is viewed as a place to collect data that belongs to the EDC, a mechanism to control site activity, or even a tool for sponsor approval workflows.

The urge to collect data in IRT is a reflexive response to the problem that sites delay data entry into the EDC system. It is the number one reason that sponsors give for adding data collection to the IRT. Followed closely by the desire to manage adherence to the protocol. My perspective is that one should channel their inner Six Sigma expert and address the root cause, which is site’s EDC delay, and the inherent tension between scientific study and real-world circumstances.

Making your IRT a replacement or EDC supplement leads to downstream issues like

·       longer development timelines

·       additional validations

·       reconciliation nightmares

·       site frustration    

A friend of mine — let’s call him Big Al — works at a large pharma company and insists on using the term RTSM instead of IRT.

Why? Primarily to fend off colleagues who want to “put more in the IRT.”
He believes the broader acronym clarifies purpose. I disagree on semantics (after all, “Excel” isn’t “accounting”), but I understand his defense completely. He’s trying to protect the boundaries that make IRT effective.

When you perform UAT, you confirm that your system was built for purpose.
Design your IRT the same way — for its primary purposes only.

Leave the rest where it belongs.

Next up: Commandment 2 — Thou Shall Not Defer Functionality.

Why IRT Needs Its Own Commandments

Clinical trials rely on Interactive Response Technology (IRT) every single day — yet too often, we treat it like a flexible catch-all system. Randomization? Sure. IMP management? Of course. But then someone says, “Can’t we just collect this extra data in IRT? Can’t we just bolt on another workflow?”

That’s how trouble starts.

The truth is simple: IRT has a core purpose. It’s there to randomize patients, manage investigational product, and provide a controlled way to unblind when necessary. Everything else is ancillary or a byproduct of these core responsibilities. When we overload it with extras or bend it into shapes it was never meant to hold, the results are predictable: longer timelines, frustrated sites, messy reconciliations, and unnecessary regulatory exposure.

I’ve seen it firsthand. I’ve been in the room when “shortcuts” at go-live blew up months later. I’ve seen sponsors sink enormous resources into reconciliation exercises that should never have been necessary in the first place. And I’ve seen studies jeopardized because the blind wasn’t adequately protected.

It’s not because people don’t care. It’s because the industry keeps repeating the same bad habits.

That’s why I wrote The 11 Commandments of IRT.

These aren’t abstract principles. They’re lessons carved out of hard experience, regulatory findings, and trial-by-fire. Each one exists because I’ve watched what happens when it’s broken. Spoiler alert: it’s never good.

Over the coming weeks, I’ll walk through each commandment one by one. Some may feel obvious. Others may challenge the way you’ve been trained to think about IRT. The goal is that all of them will make you pause and reconsider how you’re approaching IRT systems.

Because here’s the thing: patients are waiting. Investigators are relying on us. And sponsors can’t afford to gamble with timelines or integrity.

IRT deserves better. And so do the people who depend on it.

Follow along — the first commandment drops next week.

Introducing The Unblinded View

Welcome to The Unblinded View — the new home for perspective, opinion, and the occasional heresy from the world of IRT/RTSM and clinical trial technology.

This isn’t a news feed or a marketing blog. It’s a place for ideas — drawn from decades in the trenches of trial operations, system design, and the sometimes-awkward intersection between the conduct of clinical trials and reality.

Here you’ll find:

• Straight talk about what works (and what doesn’t) in IRT.

• Reflections on technology, process, and the people who make trials happen.

• The occasional story from behind the scenes — where lessons are learned the hard way.

The name says it all: this is a viewpoint — informed, opinionated, and transparent. IRT is too important, too nuanced, and too human to discuss only in press releases and conference panels.

If you’re someone who believes quality comes from understanding — and that better systems make better studies — you’re in the right place.

Pull up a chair. Let’s get unblinded.