Spend any time around molecular genetics labs and you'll find REDCap quietly doing work it was never built for. A study database becomes the place cases get tracked. A form designed for a research cohort turns into the intake sheet for routine referrals. And it works — for a while — because REDCap is good software and lab people are resourceful. The question isn't whether you can bend it to the task. You can bend most things. It's whether it's the right shape for diagnostic operations, and how long before the seams start to show once your case volume climbs and an accreditation cycle comes around.
To be clear, this isn't a pile-on. REDCap is free at most academic institutions, it's trusted, and for structured research data capture it's excellent — genuinely hard to beat. But a diagnostic lab isn't running a study. It's moving cases through a pipeline, tracking samples it's legally accountable for, curating variants, and signing out results under NATA or ISO 15189. Different problem entirely. The gap between those two jobs is where a surprising amount of manual, avoidable work ends up living.
What REDCap was built for — and does well
REDCap — Research Electronic Data Capture — came out of Vanderbilt with one clear job: letting research teams build and run structured data-collection instruments quickly, securely, and without needing a database administrator on hand. For a multi-site clinical study, a registry, or a cohort you're following over years, it's genuinely hard to beat. Form logic, validation rules, controlled exports, a solid permission model — all of it out of the box.
So nothing that follows is a criticism of REDCap on its own terms. It's just what happens when you ask a research instrument to carry a diagnostic workflow it was never scoped for.
Where it starts to strain
The friction turns up in a handful of specific, recurring places. Any one of them is survivable on its own. Stacked together, they're the reason labs eventually go looking for something else.
1. There is no concept of a case moving through a workflow
REDCap thinks in records and forms. A diagnostic lab thinks in cases that move — received, extracted, QC-passed, sequenced, analysed, curated, reviewed, signed out. This isn't some hidden flaw, either; REDCap's own institutional documentation says it flat out: "REDCap is not a workflow tool." There's no native status pipeline, no queues, no assignment model. Labs fake it with a status field and a lot of discipline, but the system doesn't actually understand the workflow — so it can't tell you what's stuck, what's overdue, or where this week's bottleneck is.
Where it breaks
The moment a lab head asks "which cases have been sitting in curation past their turnaround target?", a research-form model has nothing useful to say — because it never knew curation was a step.
2. No sample chain of custody
A molecular genetics lab is accountable for physical samples — where they are, which run they went into, which aliquot came off which primary. REDCap has no structured idea of a specimen, a location, a freezer, or a batch. So that accountability lands in a separate spreadsheet, and you've just reintroduced the exact fragmentation you were trying to get away from.
3. Variant curation has nowhere proper to live
NGS work throws off variants that need classifying, evidence attached, and a defensible ACMG rationale on record. A REDCap field can hold the final classification fine. What it can't do is model a curation queue, a review chain, or the evidence trail behind the call. So curation happens in yet another tool, and the link back to the case is a copy-paste that someone has to remember to do.
4. The audit trail is thorough — but it answers a research question, not a workflow one
Credit where it's due — REDCap's audit trail is genuinely comprehensive. It logs data changes, exports, page views, user-rights changes, all timestamped and tied to a user. For research integrity, that's exactly what you want. The mismatch is quieter, and it tends to stay invisible right up until an assessor is standing in your lab. Because REDCap isn't a workflow tool, a case has no native status pipeline, no sign-out authority, no panel version, no review chain — those only exist as ordinary fields you've bolted on. So the log dutifully records that a field called "status" went from one value to another. That's not the same thing as an authorised, auditable sign-out event, and accreditation is asking about the second kind. Which means someone assembles the answer by hand.
Where it breaks
Prepping for a NATA / ISO 15189 audit on REDCap has a way of turning into a multi-week reconstruction job — not because data is missing, but because the workflow was never something the system understood in the first place, so its evidence has to be stitched back together after the fact.
5. Family and patient linking is all manual
Genetics is relational in a way research records just aren't. A proband connects to affected and unaffected relatives; a fresh referral might already have prior cases sitting in your lab. REDCap has no patient registry, no family-linking model — so that context lives in people's heads and in side documents, which is exactly where it goes missing.
Roughly the difference at audit time between reconstructing workflow evidence out of a form log, and reading it straight off a system that logged every status change as it happened.
What this looks like in practice
One paediatric epilepsy panel, two systems
Say a clinician orders a paediatric epilepsy panel. On a REDCap setup, someone creates a record, keys in the demographics, and the case exists — as a row. Sample location goes in a spreadsheet. Sequencing status is a field somebody has to remember to update. Variant calls get curated in a separate tool, then pasted back. Sign-out is an email plus a status change. Every one of those hand-offs is a spot where the trail thins out a little.
On a workflow-native system, the same order comes in, a case is created and linked to any prior cases on that patient or their family, the sample is scanned into a tracked location, the case moves through defined queues, curation runs against a versioned panel with the evidence attached, and sign-out is an authorised action — all of it logged as it happens. What you're left with at the end isn't a tidier spreadsheet. It's a defensible record of what actually happened.
REDCap vs a purpose-built lab workflow layer
The honest framing here isn't "REDCap is bad." It's that these are two different tools for two different jobs. Here's the comparison a lab head is actually weighing up.
| Capability | REDCap | Purpose-built workflow layer |
|---|---|---|
| Core model | Records & forms | Cases, samples, panels, variants |
| Case workflow & queues | Simulated via a status field | Native status pipeline, assignments, queues |
| Sample chain of custody | Not modelled | Locations, freezers, batches, aliquots |
| Variant curation | Final value only | Curation queue with ACMG evidence trail |
| Audit trail | Thorough — but logs field & record actions, not workflow events | Workflow-native: status changes, sign-out & panel version as events |
| Family / patient linking | Manual | Central registry with family linking |
| NATA / ISO 15189 readiness | Manual reconstruction | Audit-ready by default |
| Best fit for | Research studies & registries | Routine diagnostic lab operations |
The accreditation angle — NATA, ISO 15189, and why it decides this
For Australian labs the pressure point is NATA assessment against ISO 15189, plus the RCPA Quality Assurance Programs. Internationally it's the same ISO 15189, just wrapped in CAP or CLIA framing depending where you are. Underneath all of them, the requirement is the same: you have to be able to evidence the workflow, not just store the data. That's the clearest single reason labs move off REDCap for diagnostic work — and again, it's not a dig at REDCap's logging, which is thorough. It's that REDCap isn't a workflow tool, so status transitions, review chains, sign-out authority, and panel versions simply aren't things it models. The system that treats those as first-class, logged events is the one that turns a NATA audit from a three-week ordeal into a one-day exercise. For more on how that trail ought to be built, see our piece on why pathology labs need dedicated case management beyond EMRs and our NATA / ISO 15189 compliance approach.
So what should you actually do?
If REDCap is running your research studies, leave it alone — it's the right tool for that, and nothing here says otherwise. The decision only really bites when REDCap has quietly turned into the operational backbone of a diagnostic service. At that point the honest replacement isn't another form builder. It's a workflow layer built around how the lab actually works, sitting over the EMR and LIS you already run instead of becoming one more silo to maintain. And getting out is usually less painful than labs expect: REDCap exports to CSV, and a decent migration maps those rows into real case, sample, and patient structures rather than dumping them in flat.
That's the thing CassianLab builds — a custom workflow layer for molecular genetics labs, configured to each lab's own protocols and terminology, with the kind of audit trail NATA and ISO 15189 assessors actually look for baked in from day one. It grew up inside a working clinical genetics lab in Sydney, which is why it thinks in cases, samples, panels, and variants instead of survey records.
See what a workflow-native system looks like on your cases
Book a demo and we'll run your actual workflow — intake, sample tracking, curation, sign-out — through a system that was built for it, not talked into it.
Frequently asked questions.
Common questions about lab middleware and how CassianLab fits.
Is REDCap a good long-term system for a diagnostic molecular genetics lab?
For the job it was built for — structured research data capture and multi-site study forms — REDCap is excellent. As a long-term home for routine diagnostic operations, it's a poor fit: no native concept of a case moving through a workflow, no sample chain of custody, no variant curation queue, and a logging model built around form edits rather than the lab actions a NATA or ISO 15189 assessor asks about. Plenty of labs start on REDCap because it's free and familiar, then outgrow it once case volume and accreditation pressure ramp up.
What is the best REDCap alternative for a molecular genetics lab?
Depends what you're replacing it for. If it's research data capture, another EDC platform is the like-for-like swap. But if REDCap has become your stand-in for lab operations — tracking cases from sample receipt through to sign-out — then the right replacement is a purpose-built workflow layer structured around cases, samples, panels, and variants. That's what CassianLab builds: custom to each lab's protocols, and integrated with the EMR and LIS you're already running rather than bolted on beside them.
Does REDCap meet NATA / ISO 15189 requirements for a clinical lab?
REDCap's audit trail is genuinely thorough — data changes, exports, page views, user-rights changes, all timestamped and attributed. The gap isn't the logging. It's that REDCap isn't a workflow tool, so a case has no native status pipeline, sign-out authority, panel version, or review chain to log — those only exist as fields you've built yourself. An assessor wants to know who moved this case to sign-out, on whose authority, against which panel version. Since the workflow was never modelled, the log shows a field changing value rather than an authorised workflow event — which is why labs usually end up reconstructing that evidence by hand at audit time.
Can we migrate our existing REDCap data into a new system?
Yes. REDCap exports cleanly to CSV, and a well-planned migration maps those records into structured case, sample, and patient fields rather than importing them as flat rows. CassianLab handles this as part of implementation — including linking historical cases back to patients and family members wherever the data allows it.