A database that fits the protocol.
We derive the instruments from your actual data collection, write branching logic that mirrors the eligibility criteria, set roles that match who is allowed to see what, and switch on an audit trail before the first participant. We build inside your institution's own REDCap, because that is where it belongs.
Studies fail in cleaning, eighteen months in, because of a decision the database made on day one that nobody noticed.
REDCap is genuinely excellent software, and most of what it is blamed for is a configuration decision nobody documented: a free-text field where a coded one belonged, a repeating instrument used for something that was not repeating, or eligibility logic that lived in a coordinator's head.
We build the project from the protocol, in that order: what will be analysed, therefore what must be collected, therefore what the field must be. The data dictionary comes first, as the design document.
Then we hand it over — yours to run, with the documentation to run it.
We do not host your REDCap.
REDCap is licensed by Vanderbilt University to non-profit institutions. A commercial company cannot run an instance of it, and any vendor offering to host REDCap for you is either a non-profit or is worth a second question. So we work inside the instance your institution already has — under its licence, on its servers, governed by its policies.
In practice this suits everybody. Your institution keeps the licence, the server, the backups and the upgrade schedule. You grant us project-design rights on one project, and nothing else. When our engagement ends, nothing has to move and no account has to be migrated, because everything we built is already sitting where it belongs.
Where the instance itself needs attention — an upgrade that will break a module, a backup nobody has tested, a role model that leaks between studies — we write down what to ask your IT department, and why, without taking any access ourselves.
- We do Design and build the project Instruments, events, logic, roles, randomisation, consent, API integrations, migration — inside your instance, with project-design rights and nothing more.
- We do Document, validate and train Data dictionary as a design document, project-level validation evidence, SOPs and training material your coordinators keep.
- We do Advise your IT in writing What to verify about backups, upgrades, access control and instance qualification — specified so they can act on it without us.
- We do not Host, patch or operate the server Not for licence reasons and not for commercial ones. Uptime, backups, restores and REDCap version upgrades stay with the institution that holds the licence.
- We do not Hold instance administration No system-admin rights, no control panel, no access to other groups' projects. If you ever hear otherwise from a supplier, ask to see the licence.
Then there are two honest routes, and we will tell you which is cheaper for your study. Your institution can obtain the licence itself — it is free to non-profits, and we can specify exactly what the server and the support arrangement need to look like before they commit. Or, where the study is really a large questionnaire study rather than a clinical database, our own platform is the better tool anyway and we host that ourselves. See the survey platform.
The parts that decide whether cleaning takes a week.
Fields that already know their answer
Validated field types, coded response sets, units on every measurement, and required-field rules only for what is genuinely required.
- Coded choices with stable numeric values — never re-numbered after go-live
- Validation and range checks at entry, so cleaning has less to find
- Field notes and annotations that answer the coordinator's question in place
Events, arms and the things that repeat
The single most common structural mistake we fix: a visit schedule modelled as thirty numbered fields instead of an event grid. One is analysable; the other is an afternoon of reshaping per question.
- Arms, events and instrument-event mapping from the visit schedule
- Repeating instruments for genuinely repeating data — adverse events, medications, labs
- Scheduling with windows, so a late visit is flagged rather than silently accepted
Logic that survives an amendment
Branching that mirrors the protocol's eligibility and skip rules, calculated fields for scores and derived variables, and action tags that do the small things people otherwise remember to do.
- Instrument-level logic documented in one place
- Scores computed in the database, so every analyst gets the same number
- Amendment-safe: adding an arm does not mean rewriting every condition
Allocation that cannot be peeked at
Stratified and block randomisation with real concealment, blinded and unblinded roles separated at the data access layer, and an emergency unblinding path that is logged the moment it is used.
- Allocation tables generated, sealed and version-stamped before first enrolment
- Blinded views for investigators; unblinded views for pharmacy and safety only
- Documented unblinding procedure with a timestamped, attributable record
Consent recorded as structured data
Versioned consent forms, captured signatures, re-consent flows when the protocol changes, and participant-facing questionnaires that work on the phone people actually own.
- Consent version recorded per participant, with the exact text they saw
- Witnessed and proxy consent flows where the population requires them
- Survey queues, invitations and reminder scheduling out of the box
Stop typing numbers that already exist
Lab results, biobank identifiers, imaging metadata, device readings, wearables and hospital systems feeding the project directly — with reconciliation so a mismatch surfaces as a query.
- Scheduled and event-driven imports through the REDCap API
- HL7 / FHIR bridges into hospital record systems where policy allows
- Push to your analysis environment on every dataset freeze
Six years of spreadsheets, reconciled
Existing data moved into a structure that can be analysed, with a written reconciliation report: what merged, what conflicted, what had to be re-collected, and what we could not save.
- Duplicate and identity resolution with a documented rule set
- Original files preserved untouched as the source of record
- An honest gap list — the useful deliverable, even when it stings
So your team can run it without us
The project handed over properly: a data dictionary that reads as a design document, written procedures, training material for coordinators, and a named engineer on the project for the months after go-live.
- SOPs and site-facing guides in your own wording
- Project-level validation evidence you can hand to a monitor
- Support on the project — instance incidents go to your IT, and we say so
Samples, and studies that outlive the grant.
Two requests arrive so regularly alongside a database build that they belong on the same page. People usually try both in REDCap first, and both are better served by a system built for the job.
Where is aliquot three?
Freezer inventory with position down to the box and the well, aliquot lineage from the primary sample onwards, freeze-thaw counts, and a shipment manifest that reconciles on arrival. Linked to the clinical record by the same participant identifier, so a sample can be found from a result and a result from a sample.
- Barcode and label printing that matches your existing scanners
- Consent state enforced by the system at the point of release
- Volume and depletion tracking, so a sample cannot be promised twice
- Chain of custody for shipments, including temperature excursions
Infrastructure for the long term
A disease or quality registry is a database with a governance structure attached and a twenty-year horizon. We build both: the data model, the inclusion pipeline from clinical systems, the steering committee's reporting, and the annual report that keeps its funding.
- Data model designed for questions nobody has asked yet
- Automated inclusion from hospital systems where policy allows
- Access and re-use requests as a workflow with a decision log
- Public-facing indicators, and the caveats printed beside them
Ask fifty questions. Show nine.
The instrument on the right is a real pattern from a real protocol: eligibility screening where the answer to one question decides whether the next twelve exist. Watch a participant go through it.
The expression under each revealed field is the actual branching logic in the data dictionary. This is what we mean by logic that mirrors the protocol: a reviewer can read the condition, compare it with the inclusion criteria, and see that they say the same thing.
- Fewer questions asked means fewer wrong answers to clean later
- The logic is documented in the dictionary itself
- Amendments are edits to one condition in one place
A visit schedule is a grid.
Instruments across, events down, one cell per thing that has to be collected. Designed this way, every longitudinal question (change from baseline, time to event, missing-visit patterns) is a single query. Designed as numbered fields, every question needs a reshape first.
| Event | Consent | Demographics | Vitals | PROM | Labs | Meds | AE log |
|---|---|---|---|---|---|---|---|
| Screening | |||||||
| Baseline (day 0) | |||||||
| Week 12 | |||||||
| Week 26 | |||||||
| Week 52 (primary) |
- Collected once at this event
- Repeating instrument — as many rows as reality needs
- Primary endpoint
From protocol PDF to first participant.
Read the protocol
Properly, including the appendices. We come back with the questions that will otherwise surface in month nine.
- Endpoint and variable list
- Visit schedule and windows
- Ambiguities, listed and resolved
Data dictionary
Every field, type, validation, coding and condition written down and reviewed before anything is built.
- Reviewed by you, in a spreadsheet
- Analysis-ready coding decided now
- Signed off, then frozen
Build & validate
Instruments, events, logic, roles, randomisation and consent, plus a test script that proves each rule does what it claims.
- Validation evidence as output
- Synthetic test participants
- Every rule exercised once
Acceptance test
Your coordinators enter real-looking data and try to break it. What they find is cheaper to fix now than ever again.
- Half a day, your people
- Findings logged and closed
- Training material written
Hand over
The project moved into production with audit trails on, change control from day one, and a named engineer on it for the months that follow.
- Backup coverage confirmed with your IT, in writing
- Change control on the project
- Support scope written down
What REDCap does, and what it deliberately doesn’t.
REDCap is a superb data capture tool with a clear philosophy about where its job ends. This is the honest map of that boundary — including the rows where you do not need us at all.
| Capability | REDCap out of the box | With Viceron |
|---|---|---|
| Forms, validation, audit trail | Excellent — this is what it is for | We design them from the protocol; the tool is already good |
| Longitudinal event design | Fully supported, frequently misused | Event grid derived from the visit schedule, reviewed before build |
| Randomisation | Basic stratified randomisation module | Allocation generation, concealment, blinded roles, unblinding trail |
| Large-scale survey waves | Fine to a few thousand invitations | 100k+ per wave through COHORT, feeding REDCap by API |
| Adaptive instruments & item banks | Out of scope by design | Computer-adaptive testing and item banks alongside the project |
| Statistical analysis | Exports, and rightly stops there | STATLAB plus statisticians, on the frozen export |
| Participant mobile app | Mobile-friendly surveys; no native app | Native iOS and Android, writing back through the API |
| Hosting, patching, restores | Your institution's, by licence | Not ours to touch. We specify what to verify and hand that to your IT |
| Simple project, capable staff | Genuinely enough | A written instruction and a review. That is the whole engagement |
What to settle before the first participant.
Because the instance is your institution's, these are questions for the people who run it, and we cannot answer them on their behalf. We ask them at the start of every engagement, write down the answers, and tell you which ones we think are a problem. Half of them have never been asked at the institutions we work in.
- Where it runs
- Which server, in which country, under whose licence, and whether it is shared with other faculties. We need to know, but only they can answer, and it belongs in your DPIA either way.
- Backup & recovery
- What the recovery point and recovery time objectives actually are, and the date a restore was last tested. Until a backup has been restored, nobody knows whether it works.
- Access control
- Whether institutional single sign-on is available, and what happens when a coordinator leaves. We configure roles, data access groups and export rights inside the project; account lifecycle is theirs.
- Upgrades
- How often the instance is upgraded, how much notice you get, and whether a staging copy exists to test against. If an external module you rely on breaks, this is where you find out.
- Validation
- Instance-level qualification is the institution's; we produce the project-level validation evidence — requirement traceability, test scripts, results and a summary sized to the study. A monitor needs both, and we will tell you which half is missing.
- Support
- Which incidents reach whom. We answer on the project — instruments, logic, exports, integrations. Server incidents go to their helpdesk, and the escalation path should be written down before you need it at eight on a Friday.
- Export & exit
- Full data export, data dictionary and audit trail are available to you at any time from your own instance. Because everything is built there, you have nothing to exit from with us.
- Retention
- What the institution's retention rules are, and whether deletion actually executes when the ethics approval says it should. We configure the project to match; execution depends on the instance.
Recruitment is halfway, the data is in three formats, the person who built it has left, and something has to be defensible by a deadline.
That sentence arrives in our inbox most months, and the answer is the same each time: a two-week assessment — what exists, what is recoverable, what has to be re-collected, and the honest options with their costs. You get a written report and a recommendation. It is useful to you whether or not you continue with us, and occasionally the recommendation is to change the analysis rather than the data.
The six we are asked every time.
Why will you not host REDCap for us?
Because the licence does not allow it. REDCap is licensed by Vanderbilt University to non-profit institutions, and Viceron is a company. Every REDCap instance we work in belongs to the institution that holds the licence for it — a university, a hospital, a region.
So the arrangement is always the same: you grant us project-design rights on one project, we build in it, and the server, the backups, the upgrades and the uptime stay with your IT department. We advise them in writing where it matters, and we have no administrator rights and no access to anybody else's projects.
We do not have a REDCap instance at all. What then?
Two routes, and the honest recommendation depends on the study. Your institution can obtain the licence itself — it is free to non-profits and thousands of institutions hold one — and we will specify what the server, the backup regime and the internal support arrangement need to look like before anybody commits to it. That is a short piece of advisory work and it saves an expensive false start.
Or, if what you actually need is a large questionnaire study rather than a clinical database, our own platform is the better tool and we operate that ourselves. Some studies end up using both, with the two synchronised through the API.
Is REDCap enough for a randomised clinical trial?
For most investigator-initiated trials, yes — with the caveat that “REDCap” and “a validated REDCap project with documented randomisation, blinded roles, a validation package and change control” are different things. The software supports the second; somebody has to actually do it.
That work is what our clinical trials page describes. Where a sponsor mandates a specific commercial EDC, we build in that instead and will say so plainly rather than argue REDCap into a role it was not asked for.
Can you fix a project that is already collecting data?
Usually, and carefully. Some changes are safe mid-study — adding fields, tightening validation for future entries, fixing branching logic. Others change the meaning of data already collected, and those need an amendment, a documented cut-over date and sometimes a derived variable that reconciles the two eras.
We tell you which category each change is in before touching it, and we never silently re-code a field that has values in it. That single rule has saved more studies than any clever migration.
What about the external modules?
We use them where they earn their place, and we assess each one before recommending it: who maintains it, when it was last updated, what it does to the database, and whether it survives the next REDCap upgrade. Installing it is your administrator's decision and their action — we give them the assessment to decide on.
A module that is abandoned upstream is a liability in a study that runs for five years. Where the need is real and the module is not trustworthy, we build the small piece ourselves against the API — outside the instance, so an upgrade cannot break it.
How do we get data out for analysis?
Through a freeze. We cut a versioned snapshot with a hash, a record of which records and fields it contains, and a labelled data file for R, Python, Stata or SAS with the coded values already turned into factors.
That snapshot is what the analysis runs against, and it is what the supplement refers to. When somebody asks nine months later why a number changed, the version number answers it. See AI-assisted analysis.
What does a build cost?
Quoted as a fixed fee against the data dictionary, so a grant can carry it as a line item. A single-arm cohort with clean instruments sits at the low end; a multi-site blinded trial with e-consent, randomisation and monitoring views at the high end.
We will also tell you when the honest answer is a two-hour review and a written instruction for your research assistant. That conversation costs nothing and has started more long relationships than any proposal we have written.
The database is rarely the whole job.
Send us the protocol. We will send back the questions.
The fastest way to find out whether we are useful: give us the protocol and the visit schedule. Within a week you get a variable list, the structural decisions we would make, the ambiguities we found, and a fixed price. No obligation attached to any of it.