Handling 'randomization failures' in a multicenter RCT
Marco Barbara
Dear REDCap users,
Over the next few weeks I need to set up a REDCap project for a multicenter open-label RCT. We'll need to randomize 170 patients across 14 sites (competitive enrollment), using site-stratified permuted blocks of size 4.
The trial evaluates a small variation of a machine perfusion procedure performed prior to liver transplantation. This procedure is used, among other things, to assess donor organ viability immediately before transplantation, and the transplant may occasionally be aborted if the organ is deemed unsuitable.
Despite our protocol specifying that randomization should occur only after a definitive decision to proceed, I anticipate a small number of “randomization failures”, meaning that a participant is randomized but ultimately is not transplanted. In those cases, the participant would not enter the analysis.
These post-randomization dropouts can break block completion and potentially compromise allocation balance within strata. In a previous similar study, an external CRO implemented a custom eCRF solution: when a randomization failure occurred, the randomization number was marked as failed, but the treatment assignment was carried forward (“re-use of assignment within stratum”) so that the next eligible participant in the same stratum received the same allocation, preserving block balance.
With REDCap’s randomization module (especially the newer version, which unfortunately I do not yet have available), is there a recommended/safe way to implement this workflow while keeping the site workflow simple (sites just click “Randomize”)?
Any suggestion by more experienced users is very welcome.
Thank you very much
Marco
Luke Stevens
Hello Marco,
Firstly: “the newer version, which unfortunately I do not yet have available” Assuming you mean your REDCap is still <v14.7, which is getting on for two years out of date, upgrading must be your first priority. There is no way that being open to multiple critical security vulnerabilities (and major, medium!) can be acceptable to you, your Cyber Security folks, to your Ethics and Governance folks, other researchers, …
Other thoughts:
- Spreading only 170 records over 14 sites is always going to be a recipe for ending up with incomplete blocks.
- Why not use blocks of size 2 as well as 4, randomly distributed? That would be a simple way to reduce the impact of randomisations that end up not being followed through. (It’s how we do our lists.
- Once you’re using the new randomisation functionality available from v14.7 you can utilise the “automatic triggering” function. This is a very handy feature that enables you to randomise records using a survey form e.g. on a device in the OR where there is this kind of time-criticality to the randomisation. It would mean that you might be able to randomise only after the organ is deemed suitable, and hence reduce the incidence of randomisations that “fail”. By way of example, we’ve done a trial where randomisation was done this way after a baby is delivered with the randomisation result indicating whether the cord cutting is performed immediately or delayed.
I hope that helps.
Regards,
Luke
Luke Stevens
Research Data Systems Manager
Clinical Epidemiology & Biostatistics Unit (CEBU)
Murdoch Children's Research Institute
The Royal Children's Hospital, 50 Flemington Road
Parkville, Victoria 3052 Australia
T +61 3 9345 6552
E luke.s...@mcri.edu.au
W mcri.edu.au
From: redca...@googlegroups.com <redca...@googlegroups.com>
On Behalf Of Marco Barbara
Sent: Friday, 8 May 2026 00:09
To: Redcap Open <redca...@googlegroups.com>
Subject: [REDCap Open] Handling 'randomization failures' in a multicenter RCT
CAUTION: External Email. Please be cautious with attachments and clicking links
--
You received this message because you are subscribed to the Google Groups "Redcap Open" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
redcap_open...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/redcap_open/269747c1-d874-4a3c-baf7-b3ddcd5a8579n%40googlegroups.com.
This e-mail and any attachments to it (the "Communication") are, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Murdoch Children’s Research Institute (MCRI) ABN 21 006 566 972 or any of its related entities. MCRI does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.
Marco Barbara
I’m very grateful for your reply, all of your suggestions are extremely helpful. I hadn’t considered using block size 2; I think we can do that. Regarding your other point (device in the OR), that’s an interesting idea. I’ll need to discuss it with the surgeons, though.