Federated and Distributed Network Analysis

In plain language

Federated network analysis is a way to study a drug or treatment across many hospitals or insurance databases simultaneously without ever moving patient records between them. Instead of combining all the data in one place, a single computer program travels to each database, runs locally on that site's own data, and returns only a small summary number — for example, how much faster or slower a particular health event occurred in one group of patients compared to another. Those site-level summaries are then combined mathematically, giving more influence to results from larger or more precise sites. This approach lets researchers draw on the scale of many data sources while respecting the privacy rules that prevent sharing patients' protected health information across organizational boundaries.

Federated and distributed network analysis

is the enabling machinery that makes a multi-database study physically possible when patient-level protected health information (PHI) cannot cross data-custodian boundaries. The governance constraint is the starting point: under HIPAA in the United States, GDPR in the European Union, and analogous statutes in Japan, Canada, and the UK, a health data custodian — an insurer, a hospital system, a national statistics agency — cannot ship row-level patient records to a coordinating team without a data-use agreement that may take years to negotiate or may never be approved. The architectural response is to move the analysis to the data rather than moving the data to the analysis. A coordinating center distributes a study package (code, concept-set definitions, analytic parameters) to each participating site; each site executes the package on its local data and returns only a small, privacy-preserving summary — a table of counts and person-time, a vector of log hazard ratios, or a gradient contribution to a distributed optimizer. No individual patient row ever crosses a custodian boundary.

This entry covers the analytic machinery — the spectrum of federation approaches, the flagship regulatory and academic networks, heterogeneity handling, and the characteristic failure modes. The multi-database entry covers the study-design layer: when to use a network rather than a single source, how the estimand changes across a network, and how to interpret network-level conclusions.

The federation spectrum

Federation is a family of approaches ordered by what crosses the firewall and how much statistical work happens locally versus centrally.

(1) Common protocol with site-run analyses. Each site implements the study independently from a prospectively harmonized protocol document. The coordinating center receives pre-specified estimates — a log hazard ratio and its standard error — from each site and combines them by inverse-variance-weighted meta-analysis. Easiest to operationalize for sites without shared infrastructure; hardest to guarantee truly identical phenotyping and covariate capture.

(2) Common data model with distributed code execution. Each site maps its raw data to a standardized schema — the OMOP CDM or the FDA Sentinel SCDM — and runs byte-identical code distributed by the coordinating center. The coordinating center receives aggregated tables (stratum-specific event counts, person-time, PS-adjusted incidence rates). This is the OHDSI and Sentinel operating model. The CDM enforces structural portability; vocabulary standardization (SNOMED, RxNorm, LOINC) is what makes a concept set mean the same thing at every site.

(3) Meta-analysis of site-specific model estimates. Each site fits its own regression model against its locally held data and shares only the estimated coefficient and its variance. The coordinating center pools across sites by fixed-effect or random-effects meta-analytic weights. Computationally transparent and auditable; requires each site to fit and validate its own model. This is the approach detailed in the worked example below.

(4) True federated estimation via gradient or score sharing. The optimizer for a global model iterates in rounds: each site computes its local gradient contribution (or score function, or log-likelihood piece) on its own data and submits it to the coordinating center; the center aggregates gradients, updates the global model parameter, and returns the updated parameter to all sites for the next iteration. Distributed Cox score aggregation achieves mathematical equivalence to a single pooled IPD analysis; federated gradient descent does the same for machine-learning models. Infrastructure and communication overhead are substantially higher.

Sentinel System — FDA active surveillance

The FDA Sentinel System is the regulatory flagship of the CDM-plus-distributed-code model. Launched in 2007 and continuously expanded, Sentinel operates across more than 60 data partners — commercial claims plans, Medicare FFS extracts, and integrated-delivery systems — whose data are mapped to the Sentinel Common Data Model (SCDM). A coordinating center (currently Harvard Pilgrim Health Care Institute / Kaiser Permanente) distributes analytic queries as SAS programs; each data partner executes the program locally and returns only cell-level counts and person-time. The PRISM (Prospective Routine Observational Monitoring Program) and ARIA query modules enable self-service active surveillance: a regulatory scientist can issue a standardized safety query and receive pooled results spanning more than 500 million person-years of longitudinal data, with all PHI remaining at each partner. Platt et al. (2018) describe how the Sentinel Initiative evolved from a pilot to a national pharmacovigilance resource.

OHDSI network and LEGEND

The Observational Health Data Sciences and Informatics (OHDSI) collaborative is the leading academic network using the OMOP CDM plus distributed code execution. Hripcsak et al. (2015) articulate the opportunities that arise when databases independently governed by hundreds of institutions map to a single CDM and share analytic code without sharing data. The LEGEND (Large-scale Evidence Generation and Evaluation across a Network of Databases) initiative demonstrates federated network analysis at scale: Suchard et al. (2019) ran a systematic comparison of all first-line antihypertensive drug classes across nine databases, generating 4.9 million patient-years of follow-up. Every site ran the same OHDSI CohortMethod package against its local OMOP CDM instance; results were meta-analyzed across sites with empirical calibration using negative controls — drug-outcome pairs with no plausible causal effect — to detect and adjust for residual systematic error. LEGEND is the proof of concept that federated analysis can produce large-scale, reproducible, calibrated comparative effectiveness evidence at a speed no single site or literature review could approach.

EHDEN and DARWIN EU

In Europe, the European Health Data Evidence Network (EHDEN) and the European Medicines Agency's DARWIN EU (Data Analysis and Real World Interrogation Network) replicate the OMOP-based federated model under GDPR constraints. EHDEN has mapped records from hundreds of millions of European patients across EHRs and administrative databases to OMOP CDM and certifies data partners for study execution. DARWIN EU provides the EMA with a governed access mechanism for OMOP network studies to support regulatory decisions, functioning as the European analog to the FDA Sentinel System.

Heterogeneity across sites — signal, not noise

When site-specific estimates diverge — as measured by I-squared, tau-squared, or a forest plot — the appropriate response is investigation, not suppression. Between-site heterogeneity usually reflects one of three sources: (a) real biological or population heterogeneity (the drug genuinely works differently in the older, higher-comorbidity Medicare population than in the younger commercially insured population); (b) measurement heterogeneity (a hospital-based site captures inpatient drug administrations invisible in claims-only sites, producing a different effective exposure definition despite identical code); or (c) ETL heterogeneity (the same OMOP concept maps to different source codes at two sites because their ETLs were implemented differently). Random-effects meta-analysis acknowledges between-study variance (τ²) rather than forcing all heterogeneity into sampling error; but even a random-effects pool is a weighted average of potentially incomparable estimates. Distinguishing biological from measurement and ETL heterogeneity requires cohort characterization output — covariate means by site, concept-set coverage checks — not just the effect estimates themselves.

Reproducibility wins

A versioned study package is the key advantage of the CDM-plus-distributed-code model over ad hoc harmonization. The same code, same concept-set definitions, and same analytic parameters run at every site; the only difference is the underlying patient population and the local ETL. Every site's output can be compared against the same specification. OHDSI study packages stored in versioned GitHub repositories and tagged to specific releases provide an audit trail from code to estimate that satisfies emerging regulatory expectations for RWE reproducibility. A literature-based meta-analysis combining studies that each used slightly different washout periods, comparator definitions, and covariate sets cannot achieve this level of methodological control.

Failure modes

Two failure patterns recur across networks regardless of architecture tier.

Semantic drift — same code, different meanings. When a data partner's ETL maps a concept incorrectly — excluding drug salt forms that should be included, or mapping an ICD code to a SNOMED concept that excludes a clinically important subtype — the code runs without error but the effective exposure or outcome definition silently differs from every other site. Semantic drift is invisible from the coordinating center and surfaces, if at all, as an anomalous site-specific estimate with no obvious data-quality flag. The defense is mandatory cohort characterization (OHDSI's DataQualityDashboard, concept-set coverage reports) before any estimate is interpreted.

Small-cell suppression breaking estimates. Most data partners apply a minimum-cell-count rule (commonly n < 11) before sharing any aggregate, to prevent re-identification. In sparse strata — uncommon outcomes in a minority exposure arm — suppression can remove enough cells to make a stratum-adjusted estimate impossible or to bias surviving strata. Cell suppression is a privacy requirement, not an analytic choice; the study design must pre-specify what happens when a site cannot contribute a stratum, and the coordinating center must report how many site-strata were suppressed.

Pros, cons, and trade-offs

Vs centralized pooled individual-level analysis: Federated analysis preserves patient privacy and partner autonomy, satisfies HIPAA and GDPR without a multi-party data-use agreement, and operates at network scale within weeks rather than years. The cost is a constraint on the estimator: only quantities that can be assembled from site-level aggregates or gradient contributions are available. Standard survival, logistic, and Poisson regressions can be expressed in distributed form; some flexible individual-level methods requiring cross-fitted iteration are harder without full IPD. Prefer federated analysis whenever direct PHI-sharing agreements are unavailable, which is the practical default in nearly every real-world network. Vs ad hoc harmonization across sites: A CDM enforces a structural contract — table names, column types, standardized vocabulary — that ensures the same code executes portably. Without the CDM, each site must write its own extraction code from a protocol document, reintroducing the between-site implementation divergence the network is designed to prevent. Ad hoc harmonization is appropriate only for a small number of sites where deep data knowledge and bilateral agreements make bespoke extraction preferable to full CDM investment. Vs literature-based meta-analysis: A federated network with one common protocol, one code base, and one set of concept definitions eliminates between-study methodological heterogeneity and prospectively avoids publication bias. A literature meta-analysis combines studies with five slightly different eligibility criteria, washout definitions, and confounder sets; the network's consistency is its central epistemic advantage.

When to use

Use federated network analysis when: (a) the question requires a multi-database design — rare outcomes, external validity, regulatory mandate — see the multi-database entry; (b) site-level PHI cannot be pooled under available data-use agreements, which is the default assumption in US and European regulatory networks; (c) the study will run within a governed network infrastructure (OHDSI, Sentinel, DARWIN EU) where CDM mapping and code-distribution machinery already exist; or (d) reproducibility and transparency of the analytic code across sites are explicit regulatory or scientific requirements. The LEGEND and Sentinel models are the appropriate templates for large-scale pharmacoepidemiologic questions in these contexts.

When NOT to use

Do not apply the federated label to an analysis that does not actually operate under the architecture it claims: if a study pools de-identified data under a shared data-use agreement, it is a pooled analysis, with different governance and analytic properties. Avoid federated approaches when: (a) the required network infrastructure (CDM, code-distribution pipeline, site QC process) does not exist and cannot be established within the study timeline — ad hoc harmonization without a CDM reintroduces between-site divergence; (b) the estimator requires individual-level iteration that cannot be faithfully approximated from aggregates, and the analytic need is strong enough to justify the legal burden of a pooled DUA; or (c) small-cell suppression across sparse strata will remove so much data that the residual estimate is more biased than a well-designed single-site analysis with adequate power. Federated analysis is not a panacea: the governance advantage is real but the analytic constraints are real too.

Interpreting the output

The worked example below yields a pooled log-HR of 0.12 from three sites (HRs of approximately 1.22, 1.11, and 1.00) combined by inverse-variance weighting.

Formal interpretation: Under the fixed-effect assumption — that a single true log-hazard ratio underlies all sites and observed variation is sampling error — the pooled inverse-variance weighted log-HR is 0.12. The variance of the pooled estimate equals 1 divided by the total weight (1/10 = 0.10), giving a standard error of sqrt(0.10) ≈ 0.316. A 95% confidence interval on the log-HR scale spans approximately 0.12 ± 1.96 × 0.316; on the HR scale the interval would be approximately (0.50, 2.89). The HR is the instantaneous rate of the event among those still at risk in the treated group relative to the comparator, averaged across sites proportional to their precision. Under the repeated-sampling interpretation, a CI that excludes 1.0 would reject the null at the 5% level; a CI that includes 1.0 is consistent with a range of effects including no effect — it does not mean the null is true.

Practical interpretation: Across the three data partners, patients on the study drug had approximately 13% higher event rate per unit of follow-up time compared to patients on the comparator drug (pooled HR ≈ 1.13). All three sites are in the same direction (HR above 1.0), which provides some reassurance that no single site's data anomaly is driving the result. However, the site-specific HRs range from 1.00 to 1.22 — a decision-maker should ask whether that spread represents genuine differences across patient populations or differences in how the drug or outcome is captured at each site before acting on the pooled number. In a real network study, the random-effects tau-squared and I-squared would be reported alongside the fixed-effect summary to flag whether the fixed-effect model's assumption of a single true HR is defensible.

Worked example

Scenario

A research team wants to know whether a new anticoagulant drug is associated with a higher rate of major bleeding events compared to a standard anticoagulant. They run a harmonized study package across three data partners — a commercial claims database, a Medicare claims extract, and a large integrated hospital network. Each site fits a Cox proportional hazards model on its own data and returns only the log hazard ratio and a measure of how precise that estimate is (the inverse-variance weight, which equals 1 divided by the squared standard error). The coordinating center then combines the three site estimates using inverse-variance weighting to produce a single pooled answer.

Dataset

Summary table returned by each data partner. log_HR is each site's estimate of the log hazard ratio for the new drug vs the standard drug; W is the inverse-variance weight (larger W means the site's estimate is more precise). No patient-level rows are shared.

Steps

• Step 1: Sum the inverse-variance weights across all three sites: 4 + 4 + 2 = 10

• Step 2: Multiply each site log-HR by its weight. Site A contribution: 4 * 0.2 = 0.8

• Step 3: Site B contribution: 4 * 0.1 = 0.4

• Step 4: Site C contribution: 2 * 0.0 = 0.0

• Step 5: Add the weighted contributions: 0.8 + 0.4 + 0.0 = 1.2

• Step 6: Divide by the total weight to get the pooled log-HR: 1.2 / 10 = 0.12

• Step 7: Convert the pooled log-HR to a hazard ratio. exp(0.12) is approximately 1.13, meaning patients on the new drug had about 13% higher event rate per unit of follow-up time than those on the standard drug. The standard error of the pooled estimate is sqrt(1/10), approximately 0.316, and the full 95% confidence interval should be computed before drawing any conclusions.

Result

Pooled log-HR = 1.2 / 10 = 0.12; pooled HR is approximately 1.13. Across all three data partners, patients on the new anticoagulant experienced approximately 13% higher rate of major bleeding per unit of follow-up time compared with the standard drug. The three site-specific estimates (log-HRs of 0.2, 0.1, and 0.0) point in the same direction, which is reassuring, but their spread suggests further investigation of whether the difference reflects genuine population heterogeneity or differences in how bleeding events are captured at each site.

Runnable example

import math
from typing import Sequence


def ivw_fixed(
    log_hrs: Sequence[float],
    weights: Sequence[float],
) -> dict:
    """
    Inverse-variance weighted fixed-effect pool of site log-HR estimates.

    Parameters
    ----------
    log_hrs : log hazard ratio from each site's local Cox / Poisson model
    weights : inverse-variance weight per site  (W_i = 1 / SE_i ** 2)

    Returns
    -------
    dict: pooled_log_hr, pooled_hr, pooled_se, ci_lo_hr, ci_hi_hr
    """
    W_total = sum(weights)
    pooled_log_hr = sum(w * lh for w, lh in zip(weights, log_hrs)) / W_total
    pooled_var = 1.0 / W_total
    pooled_se = math.sqrt(pooled_var)
    z = 1.96
    return {
        "pooled_log_hr": pooled_log_hr,
        "pooled_hr": math.exp(pooled_log_hr),
        "pooled_se": pooled_se,
        "ci_lo_hr": math.exp(pooled_log_hr - z * pooled_se),
        "ci_hi_hr": math.exp(pooled_log_hr + z * pooled_se),
    }


def ivw_random_dl(
    log_hrs: Sequence[float],
    weights: Sequence[float],
) -> dict:
    """
    DerSimonian-Laird random-effects meta-analysis with heterogeneity statistics.

    Returns
    -------
    dict: pooled_log_hr, pooled_hr, pooled_se, ci_lo_hr, ci_hi_hr, tau2, I2_pct, Q
    """
    k = len(log_hrs)
    W = list(weights)
    W_total = sum(W)
    theta_fe = sum(w * lh for w, lh in zip(W, log_hrs)) / W_total

    # Cochran Q
    Q = sum(w * (lh - theta_fe) ** 2 for w, lh in zip(W, log_hrs))
    W2_total = sum(w ** 2 for w in W)

    # DL tau-squared (floored at zero)
    tau2 = max(0.0, (Q - (k - 1)) / (W_total - W2_total / W_total))

    # Random-effects weights and pooled estimate
    W_re = [1.0 / (1.0 / w + tau2) for w in W]
    W_re_total = sum(W_re)
    theta_re = sum(w * lh for w, lh in zip(W_re, log_hrs)) / W_re_total
    se_re = math.sqrt(1.0 / W_re_total)
    I2 = max(0.0, 100.0 * (Q - (k - 1)) / Q) if Q > 0 else 0.0
    z = 1.96
    return {
        "pooled_log_hr": theta_re,
        "pooled_hr": math.exp(theta_re),
        "pooled_se": se_re,
        "ci_lo_hr": math.exp(theta_re - z * se_re),
        "ci_hi_hr": math.exp(theta_re + z * se_re),
        "tau2": tau2,
        "I2_pct": I2,
        "Q": Q,
    }


if __name__ == "__main__":
    # Worked example: 3-site network study (weights 4, 4, 2; log-HRs 0.2, 0.1, 0.0)
    log_hrs = [0.2, 0.1, 0.0]
    weights = [4, 4, 2]

    fe = ivw_fixed(log_hrs, weights)
    print(f"Fixed-effect pooled log-HR : {fe['pooled_log_hr']:.4f}")
    print(f"Fixed-effect pooled HR     : {fe['pooled_hr']:.4f}")
    print(f"95% CI for HR              : ({fe['ci_lo_hr']:.4f}, {fe['ci_hi_hr']:.4f})")

    re = ivw_random_dl(log_hrs, weights)
    print(f"\nRE (DL) pooled HR : {re['pooled_hr']:.4f}")
    print(f"I-squared         : {re['I2_pct']:.1f}%")
    print(f"tau-squared       : {re['tau2']:.4f}")

library(metafor)

# Site-level estimates returned by each data partner.
# W_i = 1/SE_i^2  =>  SE_i = 1/sqrt(W_i)
sites <- data.frame(
  site   = c("Site A (commercial claims)",
             "Site B (Medicare FFS)",
             "Site C (integrated-delivery EHR)"),
  log_hr = c(0.2, 0.1, 0.0),
  weight = c(4,   4,   2)
)
sites$se <- 1 / sqrt(sites$weight)   # recover SE from inverse-variance weight

# ------ Fixed-effect meta-analysis ------
m_fe <- rma(yi = log_hr, sei = se, data = sites, method = "FE")
cat(sprintf(
  "Fixed-effect pooled HR: %.4f  (95%% CI %.4f-%.4f)\n",
  exp(coef(m_fe)), exp(m_fe$ci.lb), exp(m_fe$ci.ub)
))

# ------ Random-effects (DerSimonian-Laird) ------
m_re <- rma(yi = log_hr, sei = se, data = sites, method = "DL")
cat(sprintf(
  "RE pooled HR: %.4f  I^2 = %.1f%%  tau^2 = %.4f  Q p-value = %.3f\n",
  exp(coef(m_re)), m_re$I2, m_re$tau2, m_re$QEp
))

# ------ Forest plot (HR scale) ------
forest(
  m_re,
  slab      = sites$site,
  transf    = exp,
  xlab      = "Hazard Ratio (new drug vs standard)",
  header    = c("Data Partner", "HR [95% CI]"),
  refline   = 1,
  main      = "Federated network meta-analysis — bleeding risk"
)
# Large I^2 (> 25%) would prompt investigation of measurement or ETL heterogeneity
# before releasing the pooled estimate; small I^2 supports the fixed-effect model.