Bridging Diverse Data Environments Through a Common Interface

IMPRESIVE connects national claims, hospital electronic health records, and other approved data settings. While variations across these environments significantly strengthen the generalizability of findings, they also introduce analytical complexity. Here is how we onboard new data partners and evaluate new research questions.

Four readiness questions

What makes a database ready for a study?

Data readiness

Can the environment identify the target population, exposure, comparator, outcome, covariates, time zero, and follow-up?

Variable availability
Coverage and observation time
Fit-for-purpose CDM status

Method readiness

Can the common study design be implemented and checked consistently?

Protocol and code lists
Variable definitions
QA and analysis programs

Collaboration readiness

Can the local team and governance processes support distributed research?

Local PI and analysts
IRB and data-owner review
Output sharing and revision

Interpretation readiness

Can results be understood in their population and healthcare context?

Coding and clinical practice
Coverage and comparability
Heterogeneity and transportability

The instrument behind the readiness check

Eight source-data domains, assessed before conversion begins

Our Source Data Survey evaluates each data dimension, categorizing items as:

Directly Available: Ready for immediate extraction and mapping.
Derivable: Obtainable through variable transformation or secondary logic.
Not Available: Absent from the local data environment.

This structured assessment captures both data availability and the analytical effort required for harmonization.

Source data survey framework: target domains, required columns, and derivations the programme documented
Target domain	Required columns	Typical availability	Possible proxy where needed
Demographic	Person identifier, sex, year of birth	Usually direct	Document whether population descriptors are directly recorded or assumed; do not present an assumption as measured data.
Enrollment	Person identifier, enrollment date, disenrollment date	Partly derived	Disenrollment commonly derived as the last date in the database or the death date.
Encounter	Person identifier, visit type, visit start and end dates	Partly derived	Visit end date derived by adding hospitalized days where the source records only an admission date.
Diagnosis	Person identifier, diagnosis code, diagnosis date	Usually direct	Coding systems differ by site — ICD-9-CM, ICD-10-CM, and KCD-7 all appear across the network.
Prescribing	Person identifier, drug code, treatment start and end dates	Partly derived	Drug end date derived by adding drug days. Drug codes are typically domestic rather than international.
Procedure	Person identifier, procedure code, procedure date	Usually direct	Procedure coding mixes international and domestic systems depending on the environment.
Laboratory result	Person identifier, laboratory data, examination date	Varies by site	Availability differs substantially between claims and hospital record environments.
Death	Person identifier, death date, cause of death	Varies by site	Cause of death is not available in every environment even where the death date is.

Directly available in the sourceRequires derivation, calculation, or additional data

Temporal granularity is a separate question.

Two environments can both carry a diagnosis date and still be incompatible for a study, because one records exact dates and another records only the month. That distinction constrains exposure windows, outcome ascertainment, and analytic time windows, and it is assessed alongside the domains above.

Data readiness self-assessment

Let’s check your data readiness

Rate your own database against each variable. Every variable comes with its definition, comments, and conversion guideline, so you can judge it against what the conversion actually needs.

Once you have reviewed your readiness summary, Contact Our Team to discuss potential research collaborations and integration opportunities.

This tool provides an exploratory readiness check for early planning. It does not replace study-specific feasibility protocols or formal data reviews.

How each table is judged

Only essential variables decide a table’s status — the identifiers, linking keys, and core date and code fields a table cannot be built without. The first rule that applies wins.

An essential variable is not available
Not ready
An essential variable is unanswered or not yet known
Incomplete
An essential variable is only derivable
Ready with derivation
Every essential variable is available
Ready

How the score is calculated

Available: 100%
Derivable: 75%
Not available: 0%
Not yet known: 0%

Essential variables count twice as much as supplementary ones. The core readiness index is the average of the eight core tables; Facility, Provider, and Drug_Strength are scored separately.

Privacy: answers remain only in this browser tab's memory. The tool uses no storage, network submission, or analytics. Do not enter person-level data, credentials, internal QA findings, or other restricted information.

Study-level decision

Readiness is not a permanent badge

The same data environment may be ready for one question and unsuitable for another. The decision must be revisited whenever the protocol, data period, definitions, or local environment changes.

Minimum feasibility record

Question and intended use
Required populations, variables, and follow-up
Local source and transformation assumptions
Quality findings and unresolved limitations
Governance, disclosure, and execution constraints
Interpretation plan for expected differences

Partner readiness needs an operating model

See the programme roadmap and the distinct roles of PHDc, AsPEN, and IMPRESIVE.

Programme roles & roadmap