Hi everyone,
I’m building a domain-driven ETL from Synthea CSV to OMOP CDM and would like a sanity check on how procedure source rows should fan out across OMOP tables.
Context
- Source: Synthea procedures.csv (15,884 rows in my run)
- Approach: resolve each source CODE to standard concept via “Maps to”, then route each standard concept to the OMOP table matching its domain_id (Condition → condition_occurrence, Procedure → procedure_occurrence, Measurement → measurement, etc.)
- This follows the guidance I’ve seen on the forums: source concepts may be ambiguous / dual-domain; standard concepts are clean and decide the destination table; one source row may generate multiple OMOP rows.
What I observe from procedures.csv alone
- procedure_occurrence: ~8,643 rows
- measurement: ~4,170 rows
- observation: ~3,017 rows
- drug_exposure: ~45 rows
- condition_occurrence: ~4 rows
- Total OMOP facts from procedures ≈ 15,879 (≈ all source rows; ~5 codes seem unmapped)
Questions
- Is it expected/correct that a large share of Synthea procedures.CODE values map to Measurement or Observation standard concepts (not only Procedure), and therefore land outside procedure_occurrence?
- For parity with ETL-Synthea specifically: ETL-Synthea appears to read procedures into procedure_occurrence and measurement (domain filters) but not broadly into observation/condition from that file. Is that a deliberate simplification of the generic “map to all standard domains” rule, or should a Synthea ETL also emit observation/condition rows when procedures.CODE maps to those domains?
- When comparing row counts to ETL-Synthea, should we compare (a) total facts derived from procedures.csv across all OMOP tables, or (b) only procedure_occurrence row counts?
I’d like to know whether my distribution is considered valid under CDM practice, even if it diverges from ETL-Synthea’s table-oriented implementation.
Thanks!
