The OMOP common data model represents observational health records in a shared structure with standardized clinical concepts. Researchers use it to reuse methods across datasets. Prepare it by mapping the source meaning, checking the resulting data and assessing its fitness for the study; the common structure alone cannot establish that the needed observations are present.
A research query written for one hospital may depend on its local codes and date fields. At another hospital, the same test may have a different code, and the available date may describe a different event. Those differences have to be understood before results can be compared.
OMOP supplies a shared representation. Mapping establishes how each source reaches it.
Reuse methods across different sources
OMOP gives researchers a common representation on which to run analytical methods. Its table conventions establish where records belong. Standardized concepts describe their clinical meaning. OHDSI maintains this common model.
A study can define a cohort against that representation and reuse the method at participating sites. This removes some repeated query work against local schemas. It does not remove the need to understand the observations each site contributes.
A claims dataset and a hospital dataset may cover different events and populations. Their common structure helps researchers apply the method, while their source coverage determines what the result can support. Keep that distinction in the study review.
Preserve the meaning of clinical records
A useful mapping preserves what a source record means, including the details that affect its interpretation. For a laboratory result, the test, value, unit and date must remain connected. A numeric value alone cannot establish that two measurements are comparable.
Local codes require more than a match between labels. Source specialists can explain how a field was used; clinical reviewers can assess whether a standard concept represents that use. The mapping should retain the source information needed to investigate the decision later.
Dates need the same attention. A result date and a specimen collection date describe different events. Selecting one without understanding the source can change the order in which events appear in an analysis.
These are practical reasons to involve domain expertise during preparation. A transformation can run correctly while encoding the wrong interpretation of its input.
Design the mapping before the load
Mapping design should settle how the source represents an event before engineers automate its conversion. The OHDSI ETL chapter describes contributions from source and model experts, clinical reviewers and technical implementers.
Profile the fields and values required by the study. Record where they belong in OMOP and which interpretation each mapping expresses. White Rabbit and Rabbit-in-a-Hat support profiling and mapping design within the OHDSI tooling.
The implemented load must be repeatable. Version the code and mapping decisions, including unresolved items. A later refresh should use an identifiable set of rules, so another person can explain the result when the original implementer is unavailable.
The team needs to be able to inspect how an unmapped value was handled. Establish how it is represented, counted and investigated under the chosen conventions. Hiding that gap makes it difficult to assess the population available for a study.
Check fitness for the research question
A database can follow the OMOP structure and still lack the observations a study needs. Its technical representation and its suitability for that study require separate examination.
The Data Quality Dashboard evaluates checks against configured thresholds and reports issues for review. A finding about a value or relationship needs interpretation by people familiar with the source. It may indicate a preparation error or a property of the observations.
For a missing event, establish what the source could capture. Check for an excluded feed or an incomplete mapping. Only then can the researcher judge what the absence means for the study. Missing data and an event that did not occur are different explanations.
Check coverage over time as well. A source migration or a newly connected department may change the records available halfway through a study period. An apparent trend can therefore require an explanation about capture before it supports a research interpretation.
Keep dataset releases explainable
Each research release needs a record of the source period, mapping and vocabulary used to produce it. The record lets a researcher identify the representation behind an analysis and investigate why a later release differs.
A corrected mapping may move records into a cohort that previously excluded them. That can be a useful correction, but it changes the analysis. Compare affected counts and describe the change before replacing the dataset used by a study.
Preserve quality results alongside the release information. An unresolved issue may matter to one study and have little effect on another. Researchers need enough context to assess that applicability without repeating the entire preparation review.
Ongoing operation therefore includes more than loading new rows. Source changes, vocabulary updates and study feedback all need a route into reviewed mappings and tested releases.
Connect source access to research delivery
Source integration and research validation need to be planned as parts of the same delivery. Epic records from Clarity or Caboodle are inputs to that work. Their configuration and history affect the available mappings.
Databasin supports Epic connections, governed infrastructure and implementation of pipelines and models. The project can use that foundation while defining the clinical mappings and validation needed for its research.
Plan the route through preparation, review, release and use. Include support for researchers who question a record or find a changed cohort. The research owner approves the interpretation; the implementation makes it repeatable and preserves the evidence needed to investigate a later difference.
Example: preparing laboratory records for analysis
This illustrative review checks whether laboratory records from two sources can support the same research release.
| Check | What the preparation team finds | Decision recorded |
|---|---|---|
| Test identity | Local codes have matching test names. | A clinical reviewer assesses whether their meaning supports the same concept mapping. |
| Units | One source reports mg/dL, the other mmol/L. | Retain units and apply a reviewed, test-specific conversion where appropriate. |
| Timing | Collection and result times exist in one source; only result time exists in the other. | Specify the date used and the missing timing detail. |
| Missing values | Some test records have no numeric value. | Count these records and examine how the source represents them. |
| Release | A mapping correction changes the usable count. | Record the version, quality findings and reason for the difference. |
A shared table structure is only part of the preparation. The mapping decisions explain which records can be used together and what a researcher must account for.
Before releasing a research dataset
- Define the research useEstablish which population, events and period the study needs. Direct the coverage and mapping review towards those requirements first.
- Examine source coverageWork with source specialists to understand capture. Identify gaps that would change what a missing observation means in the study.
- Review the mappingsInclude clinical and model expertise in the interpretation of records. Preserve decisions and make unresolved values available for investigation.
- Establish release ownershipAssign refresh testing, change review and support for researchers. Retain the versions and quality findings needed to investigate later analytical differences.
Sources
OHDSI, OMOP Common Data Model, 2026, accessed · ohdsi.github.io/CommonDataModel
OHDSI, The Book of OHDSI, Extract Transform Load, 2026, accessed · ohdsi.github.io/TheBookOfOhdsi/ExtractTransformLoad.html
OHDSI, Data Quality Dashboard, 2026, accessed · ohdsi.github.io/DataQualityDashboard
Talk about the research data work
We can discuss the sources your research depends on and where access, preparation or refreshes slow progress. A demo can explore how Databasin could support the data foundation and the work needed to put it into use.