Home / How it works / Methods

Technical reference

How each step was actually implemented

This page is the canonical destination for definitions, conversion specifications, quality rules, and analytical components. For the architecture these steps sit inside, start with How IMPRESIVE works.

Fit for purpose

When a multinational study is—or is not—ready

Fitness is judged for a question × source pair. A converted database is not automatically ready for every question, and the assessment is repeated whenever the protocol, data period, definitions, or operating environment changes.

Strong candidate questions

  • Rare events or clinically important subgroups
  • Post-marketing safety or utilization questions
  • Cross-system treatment-pattern comparisons
  • Transportability and heterogeneity assessment

Needs feasibility work first

  • Key exposures, outcomes, or covariates are unavailable
  • Follow-up or time zero cannot be defined consistently
  • Local governance cannot support the planned execution
  • Differences cannot yet be interpreted responsibly
Falling short is a result, not a failure.

Where a pair is not fit for purpose, the characterization becomes the deliverable and defines what the next round must change: a re-scoped question, extended mappings, additional sites, or an alternative design.

Semantic implementation

One clinical concept, different local code lists

Compare the source lists used for ischemic stroke and statins. Local lists differ by site; select Harmonize to see every list resolve to the same standard OMOP concept and concept ID.

Distributed data networks

Three alternatives for what travels

The approaches are parallel options with different trade-offs. More standardization can reduce site-to-site implementation variation and speed up repeated analyses, but it requires greater upfront preparation and infrastructure.

01

Common Question

What crosses the boundary: the coordinating centre sends the research question.

What remains locally variable: study design, definitions, methods, and implementation.

02

Common Protocol

What crosses the boundary: study design, eligibility criteria, variable definitions, and analytic methods.

What remains locally variable: some interpretation and implementation of the protocol.

03

Common Data Model + Code

What crosses the boundary: a standardized data structure and a common analytic program.

What remains local: person-level data, access controls, governance, and documented adaptations.

Trade-offs at a glanceThe selected approach is highlighted. Ratings are relative and qualitative (lower, moderate, higher), not measured scores.
Trade-offs of the three distributed approachesRelative qualitative ratings from 1 (lower) to 3 (higher) on six aspects. Common Question: cross-site consistency 1, local flexibility 3, upfront infrastructure 1, analysis speed once set up 1, reuse across studies 1, site analytic workload 3. Common Protocol: cross-site consistency 2, local flexibility 2, upfront infrastructure 2, analysis speed once set up 2, reuse across studies 2, site analytic workload 2. Common Data Model + Code: cross-site consistency 3, local flexibility 1, upfront infrastructure 3, analysis speed once set up 3, reuse across studies 3, site analytic workload 1.Cross-siteconsistencyLocalflexibilityUpfrontinfrastructureAnalysis speedonce set upReuseacross studiesSiteanalytic workloadLowerModerateHigher
  • Common Question
  • Common Protocol
  • Common Data Model + Code

Fit-for-purpose standardization

Compare two common-data-model routes with different strengths and implementation demands.

Starting point

Different tables, fields, dates, and local codes

Example NHIRD drug record: a locally structured pharmacy claim contains domestic product code A039307100. The study first documents where it lives, what its dates mean, and what can be derived.

Local pharmacy claimA039307100Meaning remains tied to the approved local code list

Stewardship context: Sentinel CDM was developed for the US FDA Sentinel active-surveillance programme. OMOP CDM is stewarded by the Observational Health Data Sciences and Informatics (OHDSI) community.

Stronger semantic standardization

OMOP CDM

  • Standardizes structure and semantic vocabularies.
  • Required extensive vocabulary mapping and greater computing resources in the implementation described by the programme.
  • Required ETL development with dummy data outside the secure environment before transfer into that environment.
  • Requires locally maintained mappings where source codes have no established crosswalk.
Source-preserving operational fit

Sentinel CDM

  • Emphasizes structural standardization while retaining more source terminology.
  • Manages vocabulary differences through study definitions and site-level code lists.
  • Was easier to implement within the secure SAS environment described by the programme.
  • Still requires documented local adaptation, including drug-strength and source-code handling.
Local adaptation is part of the method.

Structural conversion alone is not enough. Date construction, drug information, source-specific code mapping, and variable definitions must be documented and validated.

Structural mapping example

The NHIRD mapping shows how the same clinical domains are represented in OMOP and Sentinel.

NHIRD source domains mapped to OMOP CDM and Sentinel CDM
Clinical domainTaiwan NHIRDOMOP CDMSentinel CDM
DemographicsBeneficiary dataPERSONDEMOGRAPHIC
Observation periodEnrollment dataOBSERVATION_PERIODENROLLMENT
Healthcare encountersInpatient, outpatient & pharmacy claimsVISIT_OCCURRENCEENCOUNTER
DiagnosesInpatient & outpatient claimsCONDITION_OCCURRENCEDIAGNOSIS
MedicationsInpatient, outpatient & pharmacy claimsDRUG_EXPOSUREDISPENSING
ProceduresInpatient & outpatient claimsPROCEDURE_OCCURRENCEPROCEDURE
Laboratory resultsN/AMEASUREMENT, OBSERVATIONLABORATORY_RESULT, VITAL_SIGN
MortalityDeath registryDEATHDEATH & CAUSE_OF_DEATH
Drug doseDrug reference dataDRUG_STRENGTHStandard OMOP tableN/A [Self-created]Local extension required

Implementation evidence

A four-step ETL process with revision built in

Walk through the conversion cycle

Select a step. The static outline below the widget remains available if scripting is unavailable.

    ETL illustration: heterogeneous source-data bricks enter a conversion funnel and emerge in a standardized structure.

    Quality assurance

    Three canonical dimensions, then study-specific validity

    General common-data-model quality checks are distinct from validating whether a specific cohort or analysis behaves as intended.

    1

    Conformance

    Structure, formats, and identifiers.

    2

    Completeness

    Domain and variable availability.

    3

    Plausibility

    Values, dates, and clinical patterns.

    4

    Study-specific validity

    Cohorts, variables, frequencies, and analytic outputs compared with the protocol and source context.

    OMOP CDM

    Official Data Quality Dashboard

    3,000+ automated checks support general CDM quality assessment.

    Sentinel CDM

    Self-developed quality checks

    Three Qchecks, plus native-versus-CDM result comparison using a 5% difference threshold.

    See these methods in use

    Three cases exercised this machinery: cross-database comparability, framework reuse, and evidence transportability.

    All accomplishments