Data Management · Data managers
CuRE Conduct
OMOP mapping, governance, and the data plane every other product reads from.
What it does
OMOP mapping, governance, and the data plane every other product reads from. Configure a pipeline, not a services project — FHIR, CRO CSVs, registries, labs, and claims map to one canonical OMOP data plane.
Key capabilities
- FHIR/HL7 → OMOP CDM v5.4 mapping engine
- ColumnMappingTemplate authoring (Mapping Workbench)
- Vocabulary management + concept/vocabulary API (search, hierarchy, multilingual synonyms, semantic search)
- Governed CDISC Controlled Terminology register (versioned, hash-anchored)
- End-to-end CDASH → SDTM → ADaM → define.xml traceability
- Consent scope + DUA enforcement, provenance/lineage, data enclaves
- AI structural ETL authoring (propose transform rules)
- Source-data profiling / scan report
- Vocabulary-refresh / concept-deprecation remediation
- Mapping-coverage drift monitoring
- Per-form UDM ↔ OMOP authority transitions with retained source custody
- Central-data-manager query review lane over site CRF data
- Cellular-product (graft) OMOP-extension model — product identity, processing methods, ISBT-128 identifiers
- CAR-T manufacturing + cold-chain projection onto OMOP, with lossless reconstruction
- Typed donor↔recipient person relationships on the EMPI substrate, DUA-gated
What sets it apart
- Configure a pipeline, not a services project — FHIR, CRO CSVs, registries, labs, and claims map to one canonical OMOP data plane.
- Vocabulary-as-a-service: a governed CDISC Controlled Terminology register plus a concept API (search, hierarchy, multilingual synonyms, semantic search) that sibling apps read instead of forking a second copy of your standards.
- The standards/terminology plane of the platform Metadata Repository — CDISC CT, Biomedical Concepts, and the CDASH → SDTM → ADaM → define.xml traceability spine in one governed substrate.
- Governance is in the data plane, not an afterthought: row-level security + consent scope at every read.
- Versioned dataset releases, de-identification/PPRL, lakehouse deployment, and synthetic data run on the same governed plane.
- AI structural ETL authoring profiles an unmapped source and proposes the transform rules, grounded on the tenant's own accepted-mapping history and governed vocabulary.
- Migrate registry forms to OMOP progressively: parity-gated authority changes preserve field lineage and frozen historical report rows without an uncontrolled dual-write system.
- Workbench UI for data managers + service API for sibling apps — dual-nature by design.
- Cell-therapy products are first-class governed records: the graft itself — product identity, processing methods, and ISBT-128 identifiers — is a queryable OMOP-extension entity, not free text on a form (ADR-CON-061).
- CAR-T manufacturing and cold-chain data land on the patient's OMOP timeline and reconstruct back out losslessly, so release-checkpoint measurements, transit times, and temperature excursions align to outcomes (ADR-CON-038).
- Allogeneic donor↔recipient pairs are typed relationships on the EMPI substrate with their own DUA-gated disclosure scope — graft source, matching, and paired outcomes are queryable across the transplant, not a sidebar (ADR-CON-047).
Map FHIR to OMOP, field by field
Pick or edit a FHIR Condition resource and watch Conduct's mapper produce the OMOP condition_occurrence row live — resolving the source code to an OMOP standard concept (following Maps to when the source is non-standard), applying the onset-date priority chain, and flagging domain-routing or unmapped codes.
A non-standard ICD-10-CM source code — the resolver follows "Maps to" to the SNOMED standard concept, so source_concept_id ≠ condition_concept_id.
| condition_concept_id | 201826 |
| condition_source_concept_id | 45542738 |
| condition_source_value | http://hl7.org/fhir/sid/icd-10-cm|E11.9 |
| condition_start_date | 2022-11-30 |
| condition_end_date | ∅ |
| condition_type_concept_id | 32817 |
| condition_status_concept_id | 32902 |
| condition_status_source_value | active |
This is Conduct's real Condition mapper running client-side: the onset-date priority chain (onsetDateTime → onsetPeriod.start → recordedDate), the clinicalStatus→concept map, the EHR type concept, and the concept resolver that follows OMOP Maps to so a non-standard source code lands on the right standard concept while its origin is preserved in source_concept_id. Edit the JSON above and the row remaps instantly — no backend.
Why this is more than a toy
This is Conduct's actual Condition mapper, ported dependency-free from the platform monorepo (apps/conduct/…/mapping-engine): the same FHIR-system→OMOP-vocabulary table, vocabulary-priority coding selection, concept resolver, and field-for-field condition_occurrence construction. In the product Conduct owns the canonical FHIR→OMOP mapping (Conduit → Conduct → omop, per ADR-PLT-026) and resolves concepts against the full OMOP vocabularies; here it runs against a hardcoded vocabulary slice, entirely in your browser. No backend.
See CuRE Conduct in action
Every research ecosystem is unique. Let's discuss how CuRE can be configured for your needs.