Multi-Database / Distributed Network Study

A multi-database (distributed network) study answers a single research question by executing one harmonized protocol across several independently governed data sources — commercial and Medicare claims plans, integrated-delivery EHRs, registries — and then combining the results, not the records. Each data partner maps its data to a shared structure (a common data model such as OMOP CDM or the Sentinel SCDM, or a shared analytic-table specification), runs byte-identical or specification-identical code locally, and returns only aggregate output. The patient-level protected health information never leaves the partner's firewall. This is the operating model of the FDA Sentinel System, the Canadian Network for Observational Drug Effect Studies (CNODES), the OHDSI network, and most multinational PASS.

Core conceptual distinction

The defining choice is distributed analysis vs centralized pooling, and it is separable from the choice of estimator.

1. Distributed vs pooled individual-level data (IPD): in a distributed network each site holds its own data and shares only aggregates; in a pooled study all records are physically combined in one analytic file. Distributed analysis is what makes data partners willing to participate (governance, HIPAA, GDPR), but it constrains what you can compute — you must design every quantity so it can be assembled from site-level pieces.
2. Common data model vs ad hoc harmonization: a CDM (OMOP, SCDM/Sentinel) fixes table schemas and vocabularies so the same code runs everywhere; ad hoc harmonization writes bespoke extraction per site and is fragile.
3. What gets shared sits on a spectrum: fully aggregate counts/effect estimates (most private), stratified risk-set or propensity-score-stratum tables that enable exact stratified or conditional analyses without IPD (Toh's distributed risk-set sharing), or, rarely, a curated pooled extract under a data-use agreement. The estimand is still a comparative effect (e.g., a hazard ratio or risk difference for drug A vs B), but it is a network-level summary of site-specific estimates whose interpretation depends on whether you fix-effect or random-effect combine them, and on how heterogeneous the sites are.

Pros, cons, and trade-offs

• vs a single-database study: A network buys sample size for rare exposures and outcomes, broader generalizability across payers/regions/care settings, and the ability to measure heterogeneity (is the signal real or one site's artifact?). Cost: enormous operational overhead — common-protocol governance, CDM mapping, code distribution, site QC, and a slower timeline. Prefer a network when one database lacks power, when external validity matters for a regulatory or coverage decision, or when reproducibility across data sources is itself the evidentiary claim; prefer a single well-characterized database for an exploratory or hypothesis-generating analysis where speed and deep knowledge of one source outweigh breadth.
• vs centralized pooled individual-level analysis: Distributed analysis preserves privacy and partner autonomy and sidesteps the legal/ethical barriers to moving PHI. Cost: you cannot run arbitrary individual-level models centrally; you are limited to what aggregates support (stratified Cox/conditional logistic via risk sets, site-specific PS models, meta-analytic combination). Some flexible estimators (certain machine-learning PS, individual-level g-methods) are awkward or impossible without IPD. Prefer distributed unless a data-use agreement genuinely permits pooling and the analysis demands individual-level modeling that aggregates cannot reproduce.
• vs aggregate meta-analysis of separately published studies: A distributed network uses one protocol, one set of code lists, and one outcome definition everywhere, eliminating the between-study methodological heterogeneity and publication bias that plague literature-based meta-analysis. Cost: it requires a live, governed network rather than a desk review. Prefer the network when you control the analysis; fall back to meta-analysis of published estimates only when you cannot access the underlying data.

When NOT to use — and when it is actively misleading or dangerous

• When one database already answers the question with adequate power and validity. The network's overhead buys nothing and slows the answer; the breadth is decorative.
• When the exposure, outcome, or confounders are not measurable identically across sites. If inpatient drug administration is captured at one integrated-delivery site but invisible in another's claims, the "same" exposure definition means different things; combining them manufactures a spurious network estimate. Pooling or meta-analyzing non-comparable site definitions is the dangerous failure mode — heterogeneity then reflects measurement, not biology, and a fixed-effect summary will confidently report a number that means nothing.
• When sites differ structurally in ways the analysis ignores. Different drug launch dates and formulary timing by plan create calendar-time confounding that varies by site; Medicare Advantage vs fee-for-service capture differs; case-mix differs. Blindly fixed-effect combining hides this. Always report between-site heterogeneity (I², τ², forest plot) and investigate large I² before trusting a pooled number.
• When privacy constraints force aggregates so coarse that the estimator is biased. If a site can only return marginal counts (not PS-stratified risk sets), residual confounding cannot be controlled distributedly and the network estimate is no better than a crude one.

Data-source operational depth

• Claims (commercial / Medicare FFS): The workhorse of Sentinel and CNODES. Exposure = pharmacy claim (`ndc` + `fill_date` + `days_supply`); enrollment spans define observable time. Require continuous medical + pharmacy enrollment across washout and follow-up so absence of a fill is real. Failure mode: Medicare Advantage person-time lacks FFS claims — MA enrollees' encounters are paid by the plan, not adjudicated as FFS claims, so diagnoses/procedures are missing or undercounted; exclude MA-only person-time (or use MA encounter data only where a partner certifies its completeness). Sample fills, 90-day mail order, and free samples distort `days_supply`.
• EHR / integrated delivery (e.g., a Sentinel data partner with an internal pharmacy): Captures inpatient administrations, labs, and vitals that claims miss — an advantage that becomes a threat to comparability when pooled with claims-only partners. A drug given in hospital is observed at the EHR site and invisible at the claims site, so the operational exposure definition silently differs. Visit-driven capture also means patients who leave the system are differentially lost. Workaround: restrict to the lowest common denominator of captured care, or model site as a fixed effect and stratify so each site's estimate uses only its own internally consistent data.
• Registry: Strong for indication, disease severity, and adjudicated outcomes (e.g., cancer stage, validated MI); weak for complete longitudinal drug exposure. Use registries in a network for the outcome/severity layer and link to claims for exposure and to a death index for censoring; never assume a registry's drug history is complete.
• Linked claims–EHR–vital records: The richest partner type, but linkage selects the linkable subset and creates order/fill/service date discrepancies that must be reconciled before time-zero assignment. In a network, a few linked sites plus many claims-only sites create a capability gradient — design the common protocol to the weakest site, then run richer sensitivity analyses only where the data support them.
• Cross-cutting failure modes: differential competing risks by exposure (in elderly claims populations a drug preferentially used in frailer patients faces higher competing mortality, biasing cause-specific estimates differently across sites with different age mixes); immortal time in procedure studies (defining exposure by a procedure that can only occur after surviving to it); and outcome-algorithm portability (a claims-based MI algorithm validated in one plan may have different PPV in another).

Worked claims example (distributed safety study)

Question: incidence of acute pancreatitis among new users of incretin-based therapy (GLP-1/DPP-4) vs sulfonylureas, run across four data partners (two commercial claims plans, one Medicare FFS extract, one integrated-delivery EHR), one common protocol. At each site, local code builds the analytic table identically:

1. Cohort entry = first fill (`fill_date`) of either drug class with no fill of any study or comparator drug in the prior 365 days (washout), among adults with ≥2 type-2-diabetes diagnoses in the baseline window.
2. Observable time = continuous medical + pharmacy enrollment spanning the full 365-day washout through follow-up; exclude MA-only person-time at the Medicare partner because FFS claims are absent there.
3. Index date / time zero = the qualifying fill date; assign the arm from the `ndc` dispensed that day.
4. Outcome = first inpatient acute-pancreatitis diagnosis (validated algorithm) after time zero; censor at disenrollment, death (death index), end of data, treatment discontinuation (`days_supply` end + 30-day grace), or switch.
5. Each site estimates a site-specific propensity score from baseline covariates measured only in `[index_date-365, index_date]`, forms PS strata, and returns only a stratified risk-set / event-count table per PS stratum and arm (person-time and events) — no patient-level rows leave the site.
6. The coordinating center combines the four site-specific stratified incidence-rate ratios with a random-effects meta-analysis, reports the pooled IRR with its 95% CI, and reports I² and a forest plot; a high I² triggers investigation of whether one partner's inpatient capture or formulary timing — not biology — drives the divergence before any pooled number is released.

Decision diagram

flowchart TD
  Q[Common protocol + shared code list<br/>one operational definition] --> CDM[Map each source to shared CDM<br/>OMOP / Sentinel SCDM]
  CDM --> S1[Site 1: commercial claims]
  CDM --> S2[Site 2: Medicare FFS]
  CDM --> S3[Site 3: integrated-delivery EHR]
  CDM --> S4[Site 4: registry-linked claims]
  S1 --> A1[Run identical code locally<br/>build cohort + site PS]
  S2 --> A2[Run identical code locally]
  S3 --> A3[Run identical code locally]
  S4 --> A4[Run identical code locally]
  A1 --> Agg[Return ONLY aggregates<br/>PS-stratum x arm events + person-time]
  A2 --> Agg
  A3 --> Agg
  A4 --> Agg
  Agg --> Meta[Coordinating center:<br/>random-effects meta-analysis]
  Meta --> Het{High I-squared?}
  Het -->|Yes| Inv[Investigate measurement /<br/>formulary / capture heterogeneity]
  Het -->|No| Out[Pooled estimate + forest plot]

flowchart LR
  subgraph Site[Inside each data partner's firewall]
    PHI[Patient-level records<br/>person_id, fill_date, dx] --> Cohort[New-user cohort + local PS]
    Cohort --> StratTab[PS-stratum x arm table<br/>events, person-time, n]
    StratTab --> Supp[Cell suppression n<11]
  end
  Supp -->|aggregate only| Center[Coordinating center]
  Center --> Pool[Stratified MH + random-effects pool]
style PHI fill:#fde2e2
style Supp fill:#e2f0fd

Worked example

Scenario

A research team wants to know whether GLP-1 diabetes medications are associated with fewer hospitalizations for pancreatitis compared with sulfonylureas. No single insurance database has enough pancreatitis cases to answer this reliably, so the team runs the identical study at three separate data partners. Each partner maps its data to a shared common data model, runs the same code locally, and returns only a small table of event counts and patient-years. The coordinating center then pools those three site-level estimates.

Dataset

Privacy-preserving summary table returned by each data partner (no patient rows cross the firewall). events_study = pancreatitis hospitalizations in GLP-1 arm; PY_study = patient-years in GLP-1 arm; events_comp = hospitalizations in sulfonylurea arm; PY_comp = patient-years in sulfonylurea arm.

Steps

Result

Pooled IRR = (0.500 + 0.625 + 0.750) / 3 = 1.875 / 3 = 0.625. Across all three data partners, GLP-1 users had approximately 37.5% fewer pancreatitis hospitalizations per patient-year than sulfonylurea users (IRR 0.625). The finding is consistent in direction across all three sites, which strengthens confidence in the signal. The range of site-specific estimates (0.500 to 0.750) is worth reporting so readers can judge how much the result varies by data source.

Trade-offs

Runnable example

import pandas as pd
import numpy as np

WASHOUT_DAYS = 365   # drug-free + continuous-enrollment lookback defining a new user
GRACE_DAYS   = 30    # as-treated grace period after last days_supply
MIN_CELL     = 11    # suppress small cells before sharing (re-identification guard)

def site_summary(rx: pd.DataFrame, enroll: pd.DataFrame,
                 events: pd.DataFrame, cov: pd.DataFrame, data_partner_id: str) -> pd.DataFrame:
    rx = rx.sort_values(["person_id", "fill_date"])
    study = rx[rx["drug_class"].isin(["STUDY", "COMPARATOR"])]

    # New-user index: first qualifying fill; arm = drug_class dispensed that day.
    idx = (study.groupby("person_id").first().reset_index()
                .rename(columns={"fill_date": "index_date", "drug_class": "arm"}))

    # Washout: drop anyone with a prior study/comparator fill in the 365 days before index.
    prior = study.merge(idx[["person_id", "index_date"]], on="person_id")
    bad = prior[(prior["fill_date"] < prior["index_date"]) &
                (prior["fill_date"] >= prior["index_date"] - pd.Timedelta(days=WASHOUT_DAYS))]["person_id"]
    idx = idx[~idx["person_id"].isin(bad)].copy()

    # Continuous, FFS-observable enrollment across washout through index (no MA-only person-time).
    e = enroll.merge(idx[["person_id", "index_date"]], on="person_id")
    e["ok"] = ((e["enroll_start"] <= e["index_date"] - pd.Timedelta(days=WASHOUT_DAYS)) &
               (e["enroll_end"]   >= e["index_date"]) & (~e["ma_only"]))
    idx = idx[idx["person_id"].isin(e.loc[e["ok"], "person_id"])].copy()

    # As-treated exit: min(last days_supply end + grace, end of enrollment).
    last_supply = (study.merge(idx[["person_id"]], on="person_id")
                        .assign(supply_end=lambda d: d["fill_date"] + pd.to_timedelta(d["days_supply"], "D"))
                        .groupby("person_id")["supply_end"].max())
    enr_end = enroll.groupby("person_id")["enroll_end"].max()
    c = idx.merge(last_supply.rename("supply_end"), on="person_id") \
           .merge(enr_end.rename("enr_end"), on="person_id") \
           .merge(events.groupby("person_id")["event_date"].min().rename("event_date"),
                  on="person_id", how="left") \
           .merge(cov[["person_id", "ps_stratum"]], on="person_id", how="left")
    c["tx_exit"]  = (c["supply_end"] + pd.Timedelta(days=GRACE_DAYS)).clip(upper=c["enr_end"])
    c["exit"]     = c[["tx_exit", "enr_end"]].min(axis=1)
    had_event     = c["event_date"].notna() & (c["event_date"] <= c["exit"])
    c["exit"]     = np.where(had_event, c["event_date"], c["exit"])
    c["event"]    = had_event.astype(int)
    c["pt_days"]  = (pd.to_datetime(c["exit"]) - c["index_date"]).dt.days.clip(lower=0)

    # Aggregate to PS-stratum x arm; this is the ONLY thing that leaves the site.
    agg = (c.groupby(["ps_stratum", "arm"])
             .agg(events=("event", "sum"), person_years=("pt_days", lambda s: s.sum() / 365.25),
                  n=("person_id", "size")).reset_index())
    agg["data_partner_id"] = data_partner_id
    agg.loc[agg["n"] < MIN_CELL, ["events", "person_years", "n"]] = np.nan  # cell suppression
    return agg

library(data.table)
library(metafor)

pool_network <- function(sites) {
  setDT(sites)
  sites <- sites[!is.na(events) & !is.na(person_years)]   # drop suppressed cells

  # Site-specific log-IRR via PS-stratified Mantel-Haenszel (study vs comparator).
  w <- dcast(sites, data_partner_id + ps_stratum ~ arm,
             value.var = c("events", "person_years"))
  setnames(w, c("events_STUDY","events_COMPARATOR","person_years_STUDY","person_years_COMPARATOR"),
           c("e1","e0","pt1","pt0"))
  w <- w[pt1 > 0 & pt0 > 0]
  site <- w[, {
    tot <- e1 + e0; pt <- pt1 + pt0                       # stratum totals
    num <- sum(e1 * pt0 / pt); den <- sum(e0 * pt1 / pt)  # MH rate-ratio components
    v   <- sum((e1 + e0) * pt1 * pt0 / pt^2) / (num * den)
    .(logirr = log(num / den), se = sqrt(v))
  }, by = data_partner_id]

  # Random-effects (DerSimonian-Laird) pooling across sites + heterogeneity.
  m <- rma(yi = site$logirr, sei = site$se, method = "DL")
  list(IRR = exp(m$beta[[1]]),
       CI  = exp(c(m$ci.lb, m$ci.ub)),
       I2  = m$I2, tau2 = m$tau2,
       per_site = site[, .(data_partner_id, IRR = exp(logirr))])
}

%let washout = 365;
%let grace   = 30;
%let mincell = 11;   /* suppress small cells before sharing */

/* --- STEP 1 (runs at EACH data partner) --- */
/* First qualifying fill = time zero; arm = drug_class on that fill. */
proc sort data=work.rx(where=(drug_class in ('STUDY','COMPARATOR'))) out=rx_q;
  by person_id fill_date;
run;

data idx;
  set rx_q;
  by person_id;
  if first.person_id;
  index_date = fill_date;
  format index_date date9.;
  length arm $12;
  arm = drug_class;
  keep person_id index_date arm;
run;

/* New-user washout + continuous FFS-observable enrollment (no MA-only person-time). */
proc sql;
  create table cohort as
  select i.person_id, i.arm, i.index_date,
         max(e.enroll_end) as enr_end format=date9.
  from idx i
  inner join work.enroll e
    on e.person_id = i.person_id and e.ma_only = 0
   and e.enroll_start <= i.index_date - &washout and e.enroll_end >= i.index_date
  where not exists (select 1 from work.rx p
                    where p.person_id = i.person_id and p.drug_class in ('STUDY','COMPARATOR')
                      and p.fill_date <  i.index_date
                      and p.fill_date >= i.index_date - &washout)
  group by i.person_id, i.arm, i.index_date;
quit;

/* As-treated exit, event flag, person-time, then aggregate to ps_stratum x arm. */
proc sql;
  create table perpat as
  select c.person_id, c.arm, v.ps_stratum,
         min( (select max(r2.fill_date + r2.days_supply) from work.rx r2
                 where r2.person_id = c.person_id and r2.drug_class in ('STUDY','COMPARATOR')) + &grace,
              c.enr_end,
              coalesce((select min(ev.event_date) from work.events ev
                          where ev.person_id = c.person_id), c.enr_end) ) as exit_date,
         (case when (select min(ev.event_date) from work.events ev
                       where ev.person_id = c.person_id) <= c.enr_end then 1 else 0 end) as event
  from cohort c left join work.cov v on v.person_id = c.person_id;
  create table site_summary as
  select "PARTNER_A" as data_partner_id length=12, ps_stratum, arm,
         sum(event) as events,
         sum( (exit_date - index_date) ) / 365.25 as person_years,
         count(*) as n
  from (select p.*, c.index_date from perpat p inner join cohort c on c.person_id = p.person_id)
  group by ps_stratum, arm
  having calculated n >= &mincell;   /* cell suppression */
quit;

/* --- STEP 2 (coordinating center) on stacked work.allsites = site_summary from every partner --- */
/* Poisson rate model: rate ratio for STUDY vs COMPARATOR, site fixed effect, PS-stratum adjustment. */
proc genmod data=work.allsites;
  class arm(ref='COMPARATOR') data_partner_id ps_stratum;
  model events = arm data_partner_id ps_stratum / dist=poisson link=log offset=log_py;
  estimate 'log RR (STUDY vs COMPARATOR)' arm 1 -1 / exp;   /* exp() = pooled rate ratio */
run;

Citations

1. [1]Toh S, Gagne JJ, Rassen JA, Fireman BH, Kulldorff M, Brown JS. Confounding adjustment in comparative effectiveness research conducted within distributed research networks. Medical Care. 2013;51(8 Suppl 3):S4-S10.
2. [2]Toh S, Reichman ME, Houstoun M, et al. Multivariable confounding adjustment in distributed data networks without sharing of patient-level data. Pharmacoepidemiology and Drug Safety. 2013;22(11):1171-1177.
3. [3]Platt RW, Henry DA, Suissa S. The Canadian Network for Observational Drug Effect Studies (CNODES): reflections on the first eight years, and a look to the future. Pharmacoepidemiology and Drug Safety. 2020;29(S1):103-107.

1. [4]Hripcsak G, Ryan PB, Duke JD, et al. Characterizing treatment pathways at scale using the OHDSI network. Proceedings of the National Academy of Sciences. 2016;113(27):7329-7336.

1. [5]Desai RJ, Wang SV, Sreedhara SK, et al. The FDA Sentinel Real-World Evidence Data Enterprise (RWE-DE). Pharmacoepidemiology and Drug Safety. 2024.