Data report for OMOP

[myyong]

This feature is developed for the following customers:

• OMOP #207

Description

Demographics, Measurements, Visit:

• Description of tables
• Description of relationship
• For Us: Demographics from marginals, measurements sampled from table, linked to visits
• For IG:

[crangelsmith]

This is still WIP, report will be committed to OMOP example in SSG.

MIMIC OMOP Snapshot & Synthetic Generation Proposal

Dataset Scope

This summary covers the mimic schema with emphasis on the three tables that matter most for clinical trajectories: demographics in person, encounter context in visit_occurrence, and the downstream clinical evidence captured in measurement and procedure_occurrence. All metrics, caveats, and generation steps below describe how we preserve relationships among those tables when synthesizing data for the client.

1. Dataset Profile (MIMIC schema)

Metric	Value
Patients (person)	100
Visits (visit_occurrence)	852
Avg visits per patient	8.5
Measurements (rows / distinct concepts)	338,550 / 450
Procedures (rows / distinct concepts)	18,447 / 240
Patients with ≥1 measurement	100 (100%)
Patients with ≥1 procedure	100 (100%)
Visits with measurements	846 (99.3%)
Visits with procedures	173 (20.3%)

Interpretation

• Measurement coverage is nearly universal per visit, ensuring vitals/labs are broadly available for modeling and QA.
• Patients average ~8.5 visits in this cohort, so longitudinal trajectories matter when evaluating realism.
• Only about one in five visits include a procedure, so any synthetic pipeline should allow procedure-free encounters while preserving the observed co-occurrence where they do appear.
• A wide concept mix (450 measurement types, 240 procedure types) sets expectations for downstream analytics breadth without exposing PHI.

2. Synthetic Data Generation Approach

Generation Overview

The synthetic pipeline replays the same structural flow as the source: create a person, anchor one visit per person, and then layer time-ordered measurements and procedures sampled from aggregate stats. Every downstream story (person, measurement, procedure) consumes SQL-derived aggregates from mimic/config_story.yaml so the stochastic choices remain auditable.

Person & Visit Story (sqlsynthgen/person_story.py)

• Synthetic persons draw demographics from aggregate distributions (gender, race, year of birth) and may receive a probabilistic death row based on proportion_alive and age_at_death stats.
• Visit timing mirrors the real cohort via gender-specific age-of-first-admission and length-of-stay stats; death timing truncates visits where necessary.
• Each visit samples a measurement/procedure bundle from unique_measurements_in_visits, keeping real-world co-occurrence patterns intact.

Measurement Story (sqlsynthgen/measurement_story.py)

• For every measurement concept in the bundle, _fallback_measurement_generator pulls measurement_stats to decide counts per visit, timestamps via sample_event_datetimes, and value trajectories using generate_time_series (random walk with drift/epsilon tuned to source aggregates).
• Blood pressure specifically uses the bp_profile aggregates from mimic/config_story.yaml, which compute systolic/diastolic means and standard deviations separately by gender and by age bucket (≤60 vs. >60). Those gender/age-sensitive priors drive the value sampling so hypertension trends respect demographic differences.
• This yields lifelike vitals/labs that follow realistic trends without copying source rows.

Procedure Story (sqlsynthgen/procedure_story.py)

• _fallback_procedure_generator uses procedure_stats to sample procedure counts per visit and aligns timestamps within the visit window. The generator naturally produces many visits without procedures, matching the 20.3% coverage seen in the source.

Governance & Privacy

• All randomness is anchored to aggregate SQL outputs (counts, averages, std devs) gathered via mimic/config_story.yaml.
• The linked person→visit→measurement/procedure structure ensures downstream analytics (LOS, vital trends, intervention rates) behave like the original cohort while remaining entirely synthetic.

Source Queries (mimic/config_story.yaml)

• Demographic options (gender_options, race_options, ethnicity_options) and year_of_birth_stats drive person-row sampling.
• Survival and visit timing rely on proportion_alive, age_first_admission, age_at_death, and visit_duration queries, each defined directly against the OMOP tables in config_story.yaml.
• Measurement intensity and composition leverage bp_profile, avg_measurements_per_visit_hour, and measurements_in_visits, tying the story generators back to specific SQL extracts the client can audit.

3. Known Caveats Between Source and Synthetic Data

• Each synthetic patient currently receives a single visit, so multi-visit longitudinal patterns from the source collapse into one encounter (the visit-level measurement richness remains intact).
• Measurement series are sampled independently per concept except for paired systolic/diastolic blood pressure, which share the gender/age-aware bp_profile priors; other lab correlations are not modeled yet.
• Procedure assignment mirrors visit-level frequencies but does not yet condition on specific measurement outcomes, so some fine-grained clinical triggers may differ from the source.
• Random-walk measurement values respect high-level stats but may not capture rare outliers beyond the provided standard deviations.
• We consider the relationships between measurement/procedure concepts to be non-disclosive, the frequencies of which are sampled from aggregate stats so they shouldn't replicate the source.