IRT Commandment #11

Thou Shall Develop & Enforce Standards, Until It Is Time To Break Them

I can’t believe I am writing about standards in IRT. It’s the kind of topic that makes me want to yawn. It feels so played out and obvious. It is on the agenda of every IRT conference.

But let’s look at them from a different angle: why we need them and how to avoid making them immutable or a barrier.

The best way to achieve efficiency, repeatability, and quality in IRT is through the use of standards.

If you are a small company taking a transactional approach, it is understandable for standards to not be high on your list of imperatives. But for organizations pursuing an enterprise approach, standards are essential.

Why Standards Matter

Standards work best, and perhaps only, when they are aligned with upstream and downstream processes, and with the cross-functional teams that support them.

When they are implemented well, standards create consistency across studies, reduce variability, and allow organizations to scale without reinventing processes each time.

They also serve as a bulwark against rogue clinical teams that argue that their study is different because “this is the most important study in the company.” I used to hear that phrase often.

Standards help organizations resist that pull toward unnecessary customization.

Knowing When to Break Them

But standards are not meant to be rigid rules that ignore reality. I often say that we are doing research, and that means being dynamic in the face of new data.

There will be times when breaking a standard is necessary. This may be driven by a unique study design, an operational constraint, or a situation that cannot be reasonably addressed within existing frameworks.

They should be intentional, well thought out, and agreed upon by the appropriate cross-functional stakeholders.

Breaking a standard should never be casual. It should be deliberate.

A Shared Responsibility

When the decision is made to break a standard, vendors must be prepared to support that decision. They should, of course, remind the sponsor of their standard, but be ready to flex with appropriate justification and leadership acknowledgement.

Standards are a tool to serve the study, not a mechanism to prevent thoughtful adaptation when circumstances require it.

The goal is not to enforce standards for their own sake. The goal is to create a stable foundation that supports thoughtful flexibility when needed.

The Takeaway

Standards bring order, consistency, and scalability to IRT.

But maturity is knowing when adherence strengthens the study and when thoughtful deviation is the better path.

Develop standards. Enforce them. Respect them. And when the time comes, be prepared to break them for the right reasons.

IRT Commandment #10

Thou Shall Not Have Hard Stops

Through experience gained from the early days of IVRS, this principle has largely been adopted. Yet there are still those who continue to insist on hard stops, grinding transactions to a halt and requiring human intervention before the system will proceed.

In theory, hard stops can appear disciplined. In practice, they often create friction at the exact moment care must move forward.

My experience has been that hard stops are almost always overridden when a patient is physically on site. It is in that moment that sponsors recognize the difference between the theoretical world of a written protocol and the real world in which sites and patients operate. This leads to panic and scrambling to override the system or initiate a manual intervention.

That tension is not new. It simply seems to be continually unrecognized.

The Protocol vs. The Patient

Sometimes visits occur outside of defined windows. Sometimes dosing must happen despite imperfect timing. Sometimes real life does not align neatly with system logic.

Not allowing a patient to be treated because a system refuses to proceed is not discipline. It is rigidity, and in the wrong moment, it can be unethical.

This is not an argument for ignoring the protocol. It is an acknowledgment that clinical care does not always unfold in perfect alignment with theoretical design.

Alignment with Earlier Commandments

Commandment #1 reminds us that IRT should serve its primary purposes. Overextending system control beyond those purposes creates unnecessary barriers.

Commandment #3 reminds us to respect what the system records versus what occurs in the clinical environment. A transaction date and a visit date may differ. That does not make one wrong.

Commandment #9 reminds us that there is often a patient waiting. Systems are used by sites in service of real people.

Hard stops ignore all three principles.

They assume that control is more important than care.

Control Without Paralysis

Systems should guide.
They should warn.
They should document.

But they should not prevent appropriate clinical action from occurring.

If a visit falls outside a window, the system can capture it.
If an exception occurs, the system can document it.
If follow-up is needed, governance processes can address it.

The Takeaway

There is a difference between protecting protocol integrity and impeding patient care.

Design systems that guide and record.
Avoid designs that paralyze.

Because when the patient is sitting in the room, theory gives way to reality.

And reality must prevail.

We’re getting close to the end so let’s turn it up to 11!

IRT Commandment #9

Thou Shall Remember the Site and Patient

Sponsors are an IRT vendor’s clients. Sites, and by extension their patients, are the customers.

Sites are a primary user of the system. They use it in service of patients who are seeking relief from unmet medical needs. That distinction matters.

IRT systems are not patient-facing, but they are patient-impacting. Every interaction at the site level ultimately affects a patient who is typically waiting for something to happen. Often, that patient is sitting in a clinic room while the system is being used.

There is almost always a patient waiting. That patient could be your mother, your father, a friend, or a neighbor. Keeping that in mind should shape how systems are designed.

Design for the Site, in Service of the Patient

Once accuracy and reliability are addressed, the next priorities are speed and usability.

The system must be easy to use and fast to operate. Simplicity serves site users best.

This is where Commandment #1 quietly reinforces itself.

When IRT is limited to its primary purposes, systems become more efficient, more predictable, and easier for sites to use under real-world conditions.

Every additional feature, data point, or workflow that falls outside those core purposes adds friction for the people who rely on the system to be quick and accurate.

Simplicity Is a Choice

Just because a system can do something does not mean it should do it.

Overengineering is easy. Designing something simple, intuitive, and resilient requires forethought and discipline.

There is an old story about a priest who once said,
“I would have written a shorter sermon, but I ran out of time.”

System design is no different.

Simple systems require more thinking up front. They require designers to anticipate how the system will be used when time is tight, patients are waiting, and mistakes have real-world consequences.

Sites do not have time to admire clever logic. They need systems that help them do their jobs quickly and correctly. I will come back to this theme in Commandment #10 up next (aren’t you curious?).

The Takeaway

IRT systems exist to support sites in delivering care within the constraints of a protocol. The right drug for the right patient, at the right time, every time.

If a system slows a site down, adds unnecessary friction, or creates confusion, it is not just an inconvenience. It has real downstream impact.

Design with the site in mind. Remember the patient in the room.

Because when usability is sacrificed, the system stops serving its purpose.

IRT Commandment #8

Thou Shall Protect The Blind

You can jeopardize the results of an entire study through inappropriate disclosure of participant treatment assignment.

That is not theoretical risk. It is an operational reality, and I have seen it live and in person

Most people understand the obvious unblinding risks. Fewer recognize how often unblinding happens indirectly, through combinations of data points, access patterns, or operational shortcuts.

Protecting the blind is not just a system feature. It is a discipline requiring forethought and execution.

Unblinding Is Not Always Obvious

Unblinding does not only occur when a treatment is clearly disclosed. It can happen when multiple data elements are combined and interpreted together.

Shipment patterns, flawed kit ID schemes, resupply timing, replacement logic, role-based access, and assignment patterns are all common paths to unintended disclosure Even when no single data point reveals treatment, a combination may.

That is why unblinding risk must be evaluated across the full operational workflow, not just at the field level.

A Special Responsibility for IRT Providers

IRT providers are in a unique position. They are one of the few partners who routinely operate across both blinded and unblinded domains at the sponsors, CROs, depots, and sites.

That creates special responsibility in system design, access control, reporting, and support processes. It also requires disciplined role separation and strict handling of sensitive data.

This is not just good practice. It is foundational to study integrity.

Sponsor Accountability

Sponsors also carry clear responsibility here. They must define, in precise terms:

• What constitutes unblinding (feels obvious but you would be surprised at what I’ve seen)

• Who is considered unblinded

• When unblinded data may be accessed

• When, how, and to whom unblinded data may be distributed

This sounds obvious, but modern trial designs add layers of complexity that did not exist in the early IVRS era.

Adaptive designs, supply optimization, integrated platforms, and expanded data flows all increase the number of ways the blind can be compromised if definitions and controls are not explicit.

A Brief Word About Aggregate Data…

I’ll tease this for a future column. Even a study that is open label may restrict access to treatment assignment beyond an individual patient. Aggregate data may drive independent analysis and bias in an ongoing study, but I digress. A fight for another day.

The Takeaway

The blind is not protected by configuration alone. It is protected by definition, process, access control, and discipline.

Treat the blind as a study asset that requires continuous protection, not a checkbox at go live.

IRT Commandment #7

IRT Provider Shall Not Develop Scripts For Or Perform Sponsor UAT

Even an IRT provider you trust, and who has provided good service, may still have an unconscious bias or built-in conflict.

That is not an accusation. It is simply human nature.

For that reason, I have always recommended that sponsors either perform UAT themselves or outsource it to a qualified third-party expert. That recommendation has not changed, regardless of which side of the sponsor–provider equation I have been on.

UAT is not just a technical exercise. It is a confirmation that the system is fit for purpose. That accountability belongs with the sponsor.

Why Independence Matters

UAT findings are often treated as a KPI for vendors. That creates a business incentive to fix an issue quickly and keep it from showing up as an official finding.

That does not mean vendors act in bad faith. It means incentives shape behavior.

You will sometimes hear vendors point out that CROs or third parties can have their own incentives as well. In some cases, more findings can be seen as a way to demonstrate value.

That observation is not wrong. But it is also not the real issue.

Do not let that argument distract from the much larger and more important conflict of interest, which is having the system builder test and approve their own work.

No testing model is perfectly neutral. But independent testing is still the right trade-off.

One bias favors minimizing findings. The other may favor surfacing more than strictly necessary. Neither is perfect, but only one preserves independence.

And independence is the point.

The goal of UAT is not to minimize findings or to maximize them. It is to surface real issues, document them, address them, and confirm that the system preforms as intended.

A Consistent Position

My opinion on this has never changed.

Whether I was sitting on the sponsor side or the provider side, my recommendation has always been the same, often to the chagrin of some past employers.

That separation is not adversarial. It is good governance.

Regulatory Perspective

This is not just personal preference.
The EMA has stated it clearly in their reflection paper:

“The sponsor should assure themselves through UAT of the suitability of each system. It is expected that the sponsor will write their own test scripts for testing the system.”

That guidance exists for a reason.

Accountability for system suitability cannot be outsourced.

Read more here Sponsors & UAT with Poxy Clinical

The Takeaway

Sponsors own UAT.

Vendors support the process. They should not control it.

That boundary protects everyone.

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.