AESI Definitions Change Mid-Trial. Here's How to Handle It

Every PV team I've worked with eventually hits the same wall: an AESI definition changes mid-trial, and nobody can say with confidence which cases were adjudicated under the old criteria versus the new one.

New safety evidence comes in, a DSMB tightens the criteria, and the definition your team built its whole case processing workflow around six months ago isn't the one you're working with today. Now you're not just applying a new rule going forward — you're going back and asking whether every case adjudicated under the old definition still holds up.

I've watched teams manage this by memory and spreadsheet cross-checks. It works, until it doesn't — usually right around the time an inspector asks why two similar-looking cases got classified differently.

Why this is harder than it sounds

The instinct is to treat this like any other data update: change the field, reprocess, move on. But an AESI definition change isn't a data update. It's a rule change with retroactive implications, and that creates three separate problems at once:

Reclassification. Cases adjudicated under the old definition may or may not meet the new one. Someone has to go back and re-adjudicate, and you need to know exactly which cases are affected without re-reviewing your entire case volume by hand.

Timing. When did the definition change take effect? Cases before that date were reasonably adjudicated under the standard that existed at the time. That's not a data error — that's the system working as designed. But if your platform doesn't distinguish "adjudicated under v1" from "adjudicated under v2," you can't tell the difference between a legitimate historical decision and a case that just needs updating.

Defensibility. When an inspector or a DSMB asks why two clinically similar cases got classified differently, "the definition changed on this date, here's the version each case was assessed against" is a complete answer. "We're not totally sure" is not.

What your system actually needs

If you're managing this with spreadsheets or static case report forms, here's the short list of what actually solves it:

Versioned definitions, not overwritten ones. Every AESI definition should live as a dated version. When it changes, you create a new version instead of editing the old one in place — otherwise you've quietly erased the history of what changed and when.

A permanent link between each case and the definition it was adjudicated against. Not the current version. The version that was current at the time. That one field is what lets you answer "was this case handled correctly" months later.

A way to flag every historical case the change touches — same event type, same trial arm — without pulling case lists by hand.

An audit trail that captures the reasoning, not just the status change. Under 21 CFR Part 11 and ICH E6(R3), "who changed it, when, against which version, and why" is the standard. "Status changed from X to Y" isn't enough.

In Cloudbyz, this is built into how the adjudication workflow works: definitions are version-controlled objects, a definition update automatically surfaces every case adjudicated against the prior version for review, and the audit trail captures the version at time of decision without anyone having to remember to log it.

The point isn't the specific configuration — it's that definition drift has to be designed for, not patched around after the fact.

The real question to ask your platform

Next time your team faces a definition change mid-trial, here's the test: can you produce, in minutes, a complete list of every case that needs re-review, along with a clean record of which definition each existing case was adjudicated against?

If the honest answer is "we'd need to pull that together," that's not a training problem. That's a systems architecture problem — and it's worth solving before your next inspection, not during it.