CuRE — Collaborative Research Ecosystems
RWD-native, AI-native research infrastructure
An integrated suite that captures, connects, translates, analyzes, and activates cross-modal health data across institutional boundaries — turning fragmented real-world data into one governed research record that speaks FHIR, OMOP, SDTM/CDASH, eCTD, and RIM on the way to regulated outputs.
AI-driven validation EDC — clinical research data entry that catches errors at the keystroke.
See details
Explore the suite by bundle
The apps group into the bundles teams adopt together — a quick way to navigate the suite. Hover any app to see what it does and where else it shows up. Tap any app for details.
Run the study with fewer handoffs — enroll, randomize, supply, and collect data once.
Turn governed OMOP data into repeatable analyses, Briefings, and submission-grade outputs.
Connect molecular, manufacturing, shipping, and clinical signals to patient outcomes — now extending upstream toward first-in-human IND enablement across existing apps.
Engage patients, providers, sponsors, and sites in one research network — from ePRO and eConsent to point-of-care trial matching, feasibility, and sponsor-site introductions.
Capture issues, monitor risk, report safety, and preserve the validation evidence an inspector will ask for.
Carry governed evidence through sequence publishing, registration, and label lifecycle.
Turn the real-world-evidence moat into commercial-lifecycle decisions — market access and HEOR (Corridor) plus R&D portfolio go/no-go and program economics (Crucible).
↔ marks products that serve more than one team — adopt them once, and they pull their weight across every bundle they touch.
A different approach
RWD-native: data first, studies second
Traditional research platforms start with a study protocol and build data collection around it. CuRE inverts this: patient data flows continuously into a governed common model, and studies layer on top of data that already exists.
This bottom-up approach means studies start in weeks, datasets are richer, and one infrastructure serves many studies at once — because the data isn't locked inside a single protocol, every product composes on the same governed record, and validation evidence is captured as work happens.
- RWD-to-submission: FHIR, CRO files, registries, labs, and patient inputs land on OMOP, then flow toward SDTM, TMF, eCTD, registration, and labeling outputs
- Cross-modal evidence: Ask whether cryopreservation, manufacturing variance, shipping time, biomarkers, ePRO adherence, and EHR history affect CAR-T outcomes
- Attributable AI: Human-in-the-loop AI across capture, validation, mapping, briefings, and inspection support — with confidence, sources, and correction paths
- Compliance substrate: Part 11, Annex 11, audit chains, source lineage, AI logs, validation evidence, and regulatory acknowledgements are captured as product events
- Fewer steps: Reduce duplicate entry, manual queries, reconciliation, report assembly, and the cognitive load between a research question and usable evidence
Studies & Applications
Registries, trials, decision support, safety monitoring
OMOP Data Foundation
Harmonized, governed, multi-institutional
Patient & Clinical Data
EHRs, ePRO, labs, claims, manufacturing, shipping, biomarkers
Metadata-driven study build
Design once, generate everywhere
Most teams build CRFs, SDTM mappings, define.xml, and edit-checks separately, then reconcile them by spreadsheet. CuRE carries one governed, versioned study-design metadata record — a built-in Metadata Repository (MDR) — so downstream artifacts are generated from the design, not hand-built in parallel.
It's a capability woven through the apps you already run, not another standards tool to integrate: Control anchors the canonical, USDM-shaped study design; Conduct owns the standards plane — a governed CDISC Controlled Terminology register, a concept/vocabulary service, and the CDASH → SDTM → ADaM → define.xml traceability spine; Capture owns the reusable form library; Calculate owns the ADaM and define specs. One semantic substrate ties them together.
- One governed source of truth: Study design, controlled terminology, mappings, and forms are one versioned object — not four stores reconciled after the fact
- Generated, not rebuilt: CRFs, SDTM mapping, define.xml, and edit-checks emit from the design, so a change propagates instead of being re-keyed
- End-to-end traceability: Follow any value from protocol concept → CRF field → SDTM variable → ADaM → define.xml, both directions
- CDISC + OMOP, not either/or: OMOP-native at rest for analytics, CDISC/USDM-grounded for study design — a combination incumbents do not hold
Governed study-design metadata · MDR
Control · Conduct · Capture · Calculate — one versioned source
Generated from the design — not hand-rebuilt in parallel.
The platform, in general
Differentiators that come from the platform, not any one app.
Collaborative Research Ecosystems — from real-world data to submission-grade evidence on one governed OMOP record.
RWD from the ground up. trial, registry, EHR, ePRO, biomarker, cytogenetic, manufacturing, and shipping signals resolve to the same person, visit, specimen, and outcome context — cross-modal questions are native, not integration projects.
True integration, not an acquired portfolio. Conduit ingests every external feed; Conduct maps FHIR, CRO files, registries, labs, and claims to OMOP CDM v5.4 once; every other product reads from that canonical model.
Standards-native last mile. eCOA, RTSM, RBQM, E2B(R3), eTMF, eCTD, RIM, and labeling share one governed evidence chain instead of drifting into vendor-specific silos.
Design once, generate everywhere. one governed study-design metadata record — a built-in Metadata Repository (MDR) spanning Control (study design), Conduct (CDISC controlled terminology + concepts), Capture (forms), and Calculate (ADaM/define) — generates CRFs, SDTM mapping, define.xml, and edit-checks, instead of hand-building each in parallel and reconciling by spreadsheet.
AI-native throughout — field-level validation at capture, column classification at ingest, grounded RAG Q&A over the study corpus (TMF, patient chart, translational facts), AI-drafted case narratives and CSR scaffolding, and a closed RBQM loop where a risk signal re-scopes monitoring — with every model call mediated and audited through one gateway (Clarion).
Persona-first apps sit around the core. site staff (Capture), patients (Compass), physicians (Cue), analysts (Calculate), quality (Caliber), safety (Canary), translational (Cyto), BD (Commons), and regulatory teams (Compend/Consign/Consulate/Cachet).
Built for GxP from day one — 21 CFR Part 11 + EMA Annex 11 audit trails, RLS-isolated tenants, HMAC-chained migrations, validation evidence, and regulated outputs without a separate validation project.
Continuously validated, always current. Incumbent clinical platforms cut two or three validated releases a year — between them, your fix waits. CuRE ships continuously, and every release carries regenerated validation evidence (CSA-first, per FDA's 2025 guidance): validated on every deploy, not a few times a year. You're always on the current, validated version, and critical fixes reach you by construction — no backport schedule.
A fraction of the cost of the comparable point-solution stack. one platform, one data model, and one validation story replace per-vendor licenses, integration projects, and re-validation cycles.
How you adopt CuRE
One platform. One agreement. Adopt at your pace.
CuRE isn't sold module-by-module with an integration project bolted onto every addition. You sign one enterprise agreement — priced to start at a single app — and it scales with your program as your data estate grows and you switch more apps on. No re-procurement to add an app, no integration work between CuRE products, and no big-bang rollout.
Start with one app — priced as one app
Come in for the app you need today, at a single-app price of entry. One platform agreement covers the whole suite from day one, so there's no suite-sized commitment to begin and no separate purchase every time you grow.
See your own data across the whole suite
Because every app runs on one governed OMOP record, the moment your data lands in one app it's visible across the platform. Explore any app with your own data already in it, in a governed, sandboxed mode — and watch how it would surface before you activate it. No competitor whose apps don't share a substrate can show you that.
Activate app-by-app, when you're ready
Turn an app to production the moment you need it. Regulatory-required and advanced features light up per app, each with its own validation evidence delivered at activation — so you grow into the platform on your timeline, and only pay for what you're actually running.
No integrations inside CuRE — adapters ready for the rest
Adding a CuRE app takes zero integration work: apps are views on the same governed record, natively connected. You only integrate to reach outside systems — EHRs, safety databases, eTMF, and more — and adapters for many of them are already built and waiting.
The result: procurement happens once, expansion is a switch you flip, and the platform grows with you instead of restarting a buying cycle every time your program does.
AI usage & credits
AI that's built in — with room to reach further.
AI runs throughout CuRE — validating data, drafting narratives, summarizing a record, answering grounded questions. You get a generous allowance built into the platform, and when a task calls for the most capable models, you can reach for them on transparent, per-model terms. Three simple lanes, so the right model is always within reach.
Included allowance
Every plan comes with an included AI allowance on capable, cost-efficient models — enough to power the everyday AI woven through the platform at no extra charge. The AI that runs your day-to-day work is simply part of CuRE.
Prepaid credits — any model, including frontier
For the heaviest reasoning, CuRE's commercial model uses prepaid AI credits purchased by card for any allow-listed model, including frontier models. Per-model terms will publish the provider's own rate plus a clear margin, so teams can see what a premium run will draw before they choose it.
Bring your own keys
For contracted enterprises with their own model-provider agreement, the model supports bringing their own keys and rates — while every execution stays inside CuRE's governed, fully audited boundary.
No black-box AI bill and no lock-in: predictable everyday usage is included; premium-model terms will publish the provider rate plus a clear margin; contracted enterprises can use their own provider agreement.
See it work — cross-app journeys
One record, threaded through the whole platform
Each app has its own hands-on demo on its product page. A journey is different: it threads one synthetic patient record through a sequence of apps, where each stage's real engine consumes the output of the stage before it — the way a governed record actually moves across CuRE. All synthetic, all in your browser, nothing touches a backend.
One governed record, every app
Follow one synthetic patient — subject S-1001 — across the whole pipeline. Conduit classifies the raw tabular feed to OMOP domains; Conduct maps the FHIR Condition into an OMOP condition_occurrence; Capture's eCRF validation flags a value; Calculate characterizes the cohort the record lands in; Cue fires a point-of-care alert; and Canary surfaces the disproportionality signal. Step through the chain and watch each stage recompute from the one before it.
Classify the raw tabular feed to OMOP domains
A CRO subject-extract lands at the ingestion front door. Conduit's real column classifier decides each column's OMOP disposition — structural, terminology, or skip — for subject S-1001.
| Source column | Disposition | OMOP target / domain | Conf. |
|---|---|---|---|
| SubjectID | structural | person.person_source_value | 95% |
| Sex | structural | person.gender_concept_id | 95% |
| DateOfBirth | structural | person.birth_datetime | 96% |
| SiteName | structural | care_site.care_site_source_value | 78% ⚑ |
| EnrollmentDate | structural | observation_period.observation_period_start_date | 90% |
| MedicalHistory | terminology | → Condition | 86% |
| InternalRowSeq | skip | — | 90% |
| Comments | skip | — | 90% |
The free-text diagnosis routes to the OMOP Condition domain — Conduct resolves and maps it next.
Why this is more than a toy
Every stage above calls the same vendored per-app engine the standalone demos use — Conduit's column classifier, Conduct's FHIR→OMOP Condition mapper, Capture's field-save auto-query core, Calculate's cohort characterization, Cue's guideline matcher + SaMD firewall, and Canary's MGPS disproportionality methodology — nothing is re-implemented for the journey. The single record is shaped into each engine's input, and each stage's real output feeds the next: the condition_concept_id Conduct resolves is the exact key that defines Calculate's cohort. Where two engines don't share a data shape, a small, clearly labelled adapter bridges them — and the one place the clinical domain genuinely differs (Cue ships an oncology guideline pack) is called out in the stage itself rather than papered over. Everything runs client-side on synthetic data — no backend, no real patient record.
Design once, generate everywhere
Author a study-design element once in Control's metadata repository — the study phase and its condition of interest — and watch it propagate. Control's stage matrix re-derives from the phase; Conduct maps the design's condition into an OMOP condition_occurrence; Capture generates the eCRF and its edit checks; and Calculate regenerates the define.xml cohort and characterization. Change the design at the top and step through — every downstream artifact regenerates from the same metadata.
Author the study-design element once
In Control's metadata repository the design is set once: the study phase and its condition of interest. Control's real stage-matrix logic derives the funnel from the phase — change either and everything downstream re-derives.
Both dropdowns are the study design authored once in Control's metadata repository. The stage matrix above is Control's stagesForType() run live on the chosen phase; the counts come from the real assessStudy(). Everything below regenerates from this same design — no re-authoring.
The design's condition (a SNOMED code) is the metadata Conduct maps to an OMOP concept next — the single fact this journey threads forward.
Why this is more than a toy
Every stage above calls the same vendored per-app engine the standalone demos use — Control's stagesForType / assessStudy funnel logic, Conduct's FHIR→OMOP Condition mapper, Capture's field-save auto-query core, and Calculate's cohort characterization — nothing is re-implemented for the journey. The single design element is shaped into each engine's input, and one decision drives them all: the condition_concept_id Conduct resolves from the design's SNOMED code is the exact key that names Capture's disease-specific eCRF field and defines Calculate's cohort. That is the metadata-driven core of the platform — define a study once, and the mapping, the CRF, and the analytics generate themselves rather than being re-authored per app. Everything runs client-side on synthetic data — no backend, no real study.
The RWD-to-submission evidence chain
Trace one adverse event from the bedside to the submission gateway. Capture flags the out-of-range lab that surfaces the reaction; Canary works it up into an E2B(R3)-shaped safety case with a validated disproportionality signal; Compend takes the safety narrative into TMF custody, classifying it to a DIA-TMF zone with an inspection-readiness score; and Consign folds it into the assembled eCTD sequence as a Module 5 leaf, in force in the current view. Step through the chain and watch each stage build on the one before it.
Capture the adverse event at the bedside
A coordinator enters S-2001's labs at the AE visit for the ravucizumab study (VELT-042). Capture's real edit-check core flags the out-of-range hemoglobin — the acute-blood-loss lab behind the reaction.
Hemoglobin value 7.4 g/dL is outside the reference range (12–17.5). Please verify the source.
Capture's real field-save auto-query core, run on S-2001's AE-visit values — the low hemoglobin is the acute-blood-loss lab that evidences the GI haemorrhage reaction. Each query carries a 21 CFR Part 11 attribution (source AUTO, opened by the system user).
The captured suspect-product + reaction crosses to Canary as a pharmacovigilance case (a small adapter re-keys it onto Canary's surveillance subject — the engines were vendored separately, so the AE's identity is carried across, nothing is fabricated).
Why this is more than a toy
Every stage above calls the same vendored per-app engine the standalone demos use — Capture's field-save auto-query core, Canary's MGPS disproportionality methodology (PRR / ROR / EBGM / EB05), Compend's DIA-TMF cue-matcher and its six-criterion inspection-readiness scorer, and Consign's eCTD lifecycle fold + integrity validator — nothing is re-implemented for the journey. One adverse event is threaded end to end: the reaction Capture surfaces is the case Canary validates, whose narrative is the document Compend files and scores, which is the Module 5 leaf Consign shows in force in the assembled dossier. The four engines were vendored independently and don't literally share a wire type, so a small, clearly-labelled adapter carries the event's identity across each boundary — re-keying the same reaction, never fabricating a stage's output. The whole chain runs on the same synthetic IND (ravucizumab / VELT-042 / IND 123456) the standalone Compend and Consign demos carry. Everything runs client-side on synthetic data — no backend, no real patient record.
Randomize, supply, analyze
Follow one subject from allocation to analysis. Cascade's real randomization engine allocates subject S-1001 to a study arm — and therefore the drug that arm dispenses; Conduct writes that event to the platform OMOP store, mapping the subject's qualifying indication into an condition_occurrence; and Calculate reads the same cohort straight back out, reporting the arm's dispensed drug among its analyzed exposures. Step through the chain and watch the OMOP substrate close the loop from allocation to analysis.
Randomize the subject into a study arm
The SUGAR-01 trial enrolls its cohort. Cascade's real permuted-block engine allocates each subject to a 1:1 arm — metformin or placebo — with balance guaranteed at every block boundary. Subject S-1001's draw is the allocation event.
| Seq | Subject | Arm | Dispenses |
|---|---|---|---|
| 01 | S-1001 | Metformin | Metformin (concept 1503297)← threaded subject |
| 02 | S-1002 | Placebo | Placebo |
| 03 | S-1003 | Metformin | Metformin (concept 1503297) |
| 04 | S-1004 | Placebo | Placebo |
| 05 | S-1005 | Metformin | Metformin (concept 1503297) |
| 06 | S-1006 | Placebo | Placebo |
| 07 | S-1007 | Metformin | Metformin (concept 1503297) |
| 08 | S-1008 | Placebo | Placebo |
| 09 | S-1009 | Placebo | Placebo |
| 10 | S-1010 | Metformin | Metformin (concept 1503297) |
| 11 | S-1011 | Placebo | Placebo |
| 12 | S-1012 | Metformin | Metformin (concept 1503297) |
Cascade's real permutedBlockSequence — the bit-exact R-compatible MT19937 core the product validates for statistical equivalence against randomizeR / carat (ADR-PLT-042) — allocated the enrolled cohort. Balance holds at every block boundary. Subject S-1001 drew the Metformin arm — the allocation event written to OMOP next.
The randomization / dispensation event is written to the platform OMOP store via Conduct's ingest-runner. Conduct maps the subject's study-indication Condition to OMOP next — the honest seam: the vendored Conduct slice is the FHIR Condition mapper, so the event's OMOP write is carried by mapping the indication that keys the analysis; the arm + drug ride alongside as the allocation metadata.
Why this is more than a toy
Every stage above calls the same vendored per-app engine the standalone demos use — Cascade's bit-exact, R-compatible permuted-block randomization core (validated for statistical equivalence against randomizeR / carat, ADR-PLT-042), Conduct's FHIR→OMOP Condition mapper, and Calculate's cohort characterization — nothing is re-implemented for the journey. One allocation is threaded end to end: the arm Cascade draws for the subject dispenses a drug, that event is written to OMOP through Conduct's real mapper as a condition_occurrence, and Calculate reads the very same cohort back on the exact condition_concept_id Conduct wrote — where the arm's dispensed drug shows up among the analyzed exposures. The three engines were vendored independently and don't literally share a wire type, so a small, clearly-labelled adapter carries the allocation's identity across the OMOP write — mapping the study indication that keys the analysis, never fabricating a stage's output. Everything runs client-side on synthetic data — no backend, no real subject.
Safety signal to quality action
Follow one safety concern from a pharmacovigilance signal into a tracked, data-closed quality action. Canary's real disproportionality methodology validates a drug–event signal; Caliber's centralized statistical monitoring turns it into an AE-under-reporting KRI and flags the outlier site; and Credo grades the deviation, routes it to a CAPA, and binds the CAPA's effectiveness check back to that same KRI — so fresh monitoring data, not a human assertion, decides the fix worked. Step through the chain and watch a safety signal become a closed-loop quality action.
Surface the validated disproportionality signal
Over the whole synthetic spontaneous-reporting database, Canary's real MGPS methodology quantifies which drug–event pairs report more than expected. The shrinkage-robust EB05 validates the genuine signal and dismisses the merely-frequent.
| Drug | Event | PRR | EB05 | Triage |
|---|---|---|---|---|
| SSRI-Z | Serotonin syndrome | 18.2 | 10.99 | validated |
| Statin-Y | Rhabdomyolysis | 14.9 | 9.48 | validated |
| Biologic-V | Injection-site reaction | 11.6 | 8.39 | validated |
| Anticoagulant-X | GI haemorrhage | 7.0 | 5.42 | validated |
| NSAID-W | Acute kidney injury | 5.0 | 3.97 | validated |
DuMouchel MGPS shrinkage separates the planted adverse reaction from background events that are merely reported often — only the validated pair carries EB05 ≥ 2. That validated pair is the safety signal this journey hands to quality.
A validated safety signal is not the end — it is a quality question: is a site under-handling this reaction? Caliber's centralized statistical monitoring takes it up next.
Why this is more than a toy
Every stage above calls the same vendored per-app engine the standalone demos use — Canary's DuMouchel MGPS disproportionality methodology (PRR / ROR / EBGM / EB05 with Gamma-Poisson shrinkage), Caliber's centralized statistical monitoring (the additive KRI risk score + robust-z outlier flag, plus the sidecar-owned Poisson AE-under-reporting method), and Credo's deviation severity grading, disposition routing, CAPA lifecycle machine, and the line-for-line evaluateEffectivenessCriterion predicate — nothing is re-implemented for the journey. One safety concern is threaded end to end: the validated drug–event pair Canary surfaces is the KRI Caliber breaches on the outlier site, which is the deviation Credo routes to a CAPA — and the CAPA's effectiveness close binds back to the very same AE-under-reporting KRI, so the safety signal is not closed until the quality metric recovers. The three engines were vendored independently and don't literally share a wire type, so a small, clearly-labelled adapter carries the concern's identity across each boundary — re-keying the same reaction / breach, never fabricating a stage's output. Everything runs client-side on synthetic data — no backend, no real safety record.
See the platform in action
Every research ecosystem is unique. Let's discuss how CuRE can be configured for your needs.