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.