What Actually Happens When Medical Data Gets Treated Like Real Data
Most people working in healthcare IT think the problem is access. It isn't. The problem is consistency. A patient's lab result from LabCorp looks nothing like the same lab result from Quest. Both are valid. Both are wrong when you try to query them together. This is the space Emma Reckenberg has been operating in for years, and the work she pushes — mainly around standardized vocabulary, common data models, and open-source tooling like OMOP — is why some of us can actually build something that runs across multiple health systems without rewriting it from scratch every time. I'm not going to sell you on the philosophy of open data. I'll tell you what it feels like to sit down at 2 AM trying to map ICD-10 codes from three different hospital networks into a single phenotype definition, and then realize half the fields are missing because one EHR vendor stores diagnoses as free text and the other stores them as coded structured fields. That's the actual bottleneck. Not the technology. The data structure itself.
The Impact Of Emma Reckenberg Pioneering Change In Medical Data Science
Reckenberg's contribution isn't a single tool or paper. It's the accumulation of practical guidance, community leadership, and hands-on implementation work that makes the OMOP Common Data Model feel less like an academic exercise and more like something you can actually drop into a production pipeline. She's worked extensively within the OHDSI ecosystem, contributed to the ATLAS tool, and spent more time in the trenches of real-world data than most academics ever will. That shows in the output. Here's what that actually looks like in practice:
How The Standardization Pipeline Actually Works
Before you can do anything meaningful with multi-site medical data, you need to get it into a common format. The OMOP CDM does this by defining a fixed set of tables — PATIENT, VISIT_OCCURRENCE, CONDITION_OCCURRENCE, DRUG_EXPOSURE, MEASUREMENT, and a handful of lookup tables — that any source system can be mapped into. The vocabulary tables (CONCEPT, CONCEPT_ANCESTOR, RELATIONSHIP) are what make cross-system querying possible. They map SNOMED, LOINC, ICD-10, RxNorm, NDC, and others into a single concept ID universe. Step one is source data extraction. You pull raw data from the EHR or claims system. This is usually the hardest part because every site has a different schema, different date formats, different ways of handling nulls, and different opinions on what constitutes a complete record. I've seen sites where the encounter table had no start date. Just nothing. You build around that. You write a mapping script that flags missing dates and imputes them from the closest available timestamp, then you document exactly what you did so someone else can reproduce it or catch the error later. Step two is the mapping. You take each source field and decide which CDM table and column it maps to. This requires understanding both the source system and the target model. A simple example: a lab result in the source might have a result value, a unit, a code, and a reference range. In OMOP, that becomes a MEASUREMENT record with separate columns for measurement_concept_id, value_as_number, value_as_concept, unit_concept_id, and range_low/range_high. The mapping itself is usually done through a combination of automated scripts and manual review. You can't fully automate it because edge cases like duplicate codes, deprecated terms, and system-specific abbreviations require human judgment.
Get the Full Details
Step three is validation. You run the CDM validation tool, which checks referential integrity, plausibility, and basic statistics. It will tell you if your PATIENT table has orphan records, if your VISIT_OCCURRENCE dates overlap in impossible ways, if your concept mappings resolved to ZERO_CONCEPT_ID (meaning the source term couldn't be found in the vocabulary). This step usually catches 80 percent of problems. The other 20 percent shows up later when you're running analyses and the results look wrong.
What Nobody Tells You About Vocabulary Mapping
The concept mapping step is where most projects stall. The OMOP vocabulary is comprehensive but not perfect. Here are the issues I've actually hit: Deprecated concepts. CDC changes ICD-10 codes regularly. Some hospitals still use codes that were retired five years ago. The vocabulary update process catches most of these, but not all. When a source code doesn't map, it falls back to ZERO_CONCEPT_ID and your analysis silently drops that patient. I learned to run a pre-mapping audit that flags all unmapped source terms before you commit to a full load. Takes ten minutes and saves three days of debugging. Granularity mismatches. A source system might have a detailed SNOMED concept like "Type 2 diabetes mellitus with diabetic chronic kidney disease" while your analysis only needs the parent concept "Type 2 diabetes mellitus." The CONCEPT_ANCESTOR table handles this through the hierarchy, but only if the mapping went through correctly. If the source used a custom code that maps to the generic concept, you lose the clinical detail. I've seen this cause phenotype definitions to either over-include or under-include patients depending on how the hierarchy was traversed.
Unit normalization. Lab results come in different units. mmol/L versus mg/dL for glucose. IU/L versus U/L for enzymes. The MEASUREMENT table has a standard_unit_concept_id column, but getting there requires a conversion step that depends on having the right source and standard unit concepts linked in the vocabulary. If the conversion isn't defined, the value stays unstandardized and your analysis either filters it out or produces garbage. There's a script in the OHDSI tools called Unit_Standardization.sql that handles most of this, but it only works for units that have predefined conversion factors in the vocabulary. Everything else requires manual intervention.
Building a Practical Analysis Pipeline
Once your data is in the CDM, you can run analyses. The Achilles tool generates a default set of quality reports, but most research requires custom queries. I typically write these in SQL against the CDM schema. The key insight is that OMOP is designed for SQL, not for R or Python dataframes. You can do everything in R using the cohortBuilder or PatientLevelPrediction packages, but the underlying queries are SQL and understanding them helps when something goes wrong. For a typical cohort definition — say, identifying all patients with a specific condition who also received a specific drug — you'd join CONDITION_OCCURRENCE to DRUG_EXPOSURE on PERSON_ID, filter by concept IDs, and apply date constraints. The tricky part is handling time windows correctly. A drug exposure record in OMOP has a drug_exposure_start_date and drug_exposure_end_date. If you're looking for patients who were on a drug at the time of diagnosis, you need to check for date overlap, not just equality. This seems obvious until you've spent two weeks debugging a query that returned zero results because of a subtle date boundary issue. One thing that catches people frequently: the difference between observation_period and visit_occurrence. Observation_period defines the window during which a patient is actively covered by the health plan or registered with the system. If you don't filter by observation_period, you might count events that happened outside the patient's actual coverage window. This is especially important for claims-based data where coverage gaps are common. I always add a join to observation_period as a sanity check in my cohort queries.
The Real Bottleneck: Data Quality Across Sites
Multi-site studies sound great in theory. You pool data from ten health systems and suddenly you have a dataset big enough for robust statistical analysis. In practice, each site has different data quality issues. Site A might have excellent problem list data but poor medication reconciliation. Site B might have complete prescription records but missing lab results. Site C might have everything but the coding is inconsistent because they switched EHR vendors mid-study. The workaround I've settled on is to run site-level quality checks before pooling. Use the AchillesHeels reports to compare each site against a baseline. Flag sites that fall outside acceptable ranges for key metrics like percent of records with valid concept IDs, completeness of date fields, and plausibility of event sequences. Don't exclude sites automatically. Document the differences. When you're presenting results, you should be able to say "Site C had 40 percent missing lab units, so I excluded lab-based endpoints for that site but kept condition and drug endpoints." That level of transparency matters more than having a bigger N. I once worked on a study where two sites had nearly identical patient demographics but completely different distributions of a key outcome variable. Turns out one site was using a different case definition that was capturing milder cases. The pooled analysis was misleading until we separated them. The data wasn't wrong. The definitions were just different. This happens all the time in multi-site work and it's not something a tool can fix for you.
Where This Approach Falls Apart
OMOP and standardized data models work well for observational research, cohort building, and epidemiological studies. They don't work well for real-time clinical decision support. The data latency in most CDM implementations is days to weeks, sometimes months. If you need live data, you're querying the source system directly, not the CDM. They also don't handle unstructured data well. Clinical notes, radiology reports, and pathology narratives are mostly left out unless you invest in NLP pipelines, which is a separate project entirely. And they struggle with rare diseases simply because the sample sizes at individual sites are too small. You need hundreds of sites to make rare condition studies viable, and most health systems aren't willing to go through the mapping process for that. The CDM also assumes you have structured data. Many smaller hospitals and clinics still operate primarily on paper or legacy systems that don't export clean data. For those sites, the cost of CDM conversion often exceeds the value of inclusion. You end up with a dataset that's representative of large health systems and nothing else, which introduces its own selection bias.
What You Should Actually Do If You Want to Start
Download the OHDSI Atlas tool. It's free, web-based, and runs against any OMOP CDM. Build a simple cohort. Run Achilles. Read the reports. Most people skip this and jump straight into analysis, which is like learning to drive by racing. You'll crash. The atlas also has a vocabulary search feature that lets you explore how different source codes map to standard concepts, which is invaluable when you're building phenotype definitions. Use the Postman or DBeaver client for SQL development against your CDM. Don't write queries in a notebook and hope for the best. Test them on a small patient subset first. Check the result count. If it's orders of magnitude different from what you expect, something is wrong with your joins or filters. Verify the concept IDs exist in the CONCEPT table. Verify the date ranges make sense. Verify the patient counts are plausible. Document everything. Every mapping decision, every exclusion criterion, every data quality finding. Six months from now when someone asks why your results differ from another study, you'll need that documentation. Without it, you're just guessing.
The work Reckenberg and others in the OHDSI community have done has genuinely made medical data science more repeatable and less dependent on individual expertise. But the tooling only gets you so far. The rest is patience, skepticism, and a willingness to spend more time on data quality than on analysis. The results are better when you do.
