REDCap is good at what it was built for
REDCap is a widely used electronic data capture tool, and for good reason. It is fast to stand up, it is well understood by research teams, and the academic edition is free to use across Canadian medical centres. A research group can design a project, build its forms, and start collecting structured data in days. For a single study with a defined cohort and a defined endpoint, that is exactly the right shape.
None of what follows is a claim that REDCap is a poor tool. The point is narrower and more structural: the thing that makes a project-scoped tool quick to start is the same thing that makes it hard to analyse across an enterprise.
The unit of authority is the project
In a project-scoped tool, each project is the unit of schema and value-list authority. Every project defines its own variable names, its own value lists, its own validation rules, and its own conventions for missing data. Within one project, that is fine. Everything is internally consistent because one team built it.
The trouble starts when an organisation runs dozens of projects, and then wants to analyse across them.
What that costs at scale: schema fragmentation
At a health authority or a province, the same clinical concept turns up in project after project. An INR level, an NYHA class, a post-operative complication: each one likely has a different variable name, a different value vocabulary, and a different missing-value convention in every project it appears in. The concept is the same; the representation is not.
The result is that cross-programme analysis requires manual harmonisation downstream, every single time. Someone has to reconcile the variable names, map the value lists onto each other, and reconcile the conventions before any combined question can be asked. That work is slow, it is error-prone, and it has to be redone whenever a project changes its forms. This is the real cost of project-scoped schema authority across an enterprise, and it does not show up until you try to scale.
A platform-level data contract moves authority up a level
Tessera centres the platform, rather than the project, as the unit of authority. That is what the Tessera data contract enforces:
- Every variable carries a stable definitionId and a stable linkId. Question text can be reworded, translated, or clinically revised without the variable identifier changing.
- Retired questions are deprecated, not deleted, so historical data using a retired question stays valid and queryable.
- Values are coded against standard terminologies, and where an authority maintains the codes, they are pulled live from the source rather than frozen at project setup.
- Validation runs at the point of capture, provenance is complete, and observations are date-stamped, so point-in-time queries are the default rather than a special feature.
Because the contract lives at the platform layer, the same concept maps to the same identifier across every programme and every site. Cross-programme analysis is possible by default, rather than after months of harmonisation.
Two REDCaps, two conversations
It is worth being precise about which REDCap is in the room, because the comparison is not the same in both cases.
The Vanderbilt edition is the academic, free-to-use data capture tool found across Canadian academic medical centres. It is researcher-loved, quick to deploy, and genuinely good for studies. Its limitation at enterprise scale is the project-scoped schema authority described above, not the tool itself.
REDCap Cloud, a separate commercial product, launched its 2.0 release in September 2025 with explicit analytics-ready and auditable-lineage language, aimed at sponsors, contract research organisations, and medical technology companies. It sits closer to where Tessera lives, so the contest there is more head-to-head. The differentiators are the same three: the platform-level data contract, Canadian data residency, and specialty-programme depth.
What to ask when you evaluate
If you are weighing a registry tool for more than a single project, a few questions cut to the structural difference quickly:
- When the same concept appears in two programmes, does it carry the same identifier, or does each programme name it independently?
- When a question is reworded or retired, does historical data stay valid and queryable, or does the change break past analysis?
- Are values coded against authoritative terminologies and kept current, or frozen as a static list at project setup?
- Is cross-programme analysis possible by default, or does it depend on someone harmonising the data first?
The answers tell you where schema authority actually lives, which is the decision that determines whether analysis at scale is straightforward or a perpetual reconciliation project.
When this distinction matters
If you are running one study, a project-scoped tool may be all you need. If you are a health authority or a province standing up multiple specialty programmes, and you expect to analyse outcomes across them and over years, the unit of authority is the decision that determines whether that analysis is straightforward or a perpetual harmonisation project.
That is the structural difference, and it is why Tessera puts schema authority in the platform. See how it carries through to registry management.