FDA RWD Guidance: Assessing EHR and Medical Claims Data

What it is

— Real-World Data: Assessing Electronic Health Records and Medical Claims Data To Support Regulatory Decision-Making for Drug and Biological Products is a final FDA guidance for industry (CDER/CBER, July 2024; finalizing the September 2021 draft of the same title) issued under the 21st Century Cures Act Real-World Evidence (RWE) Program. It is not a journal reporting checklist maintained by EQUATOR; it is a regulator's statement of the considerations sponsors should address when they propose to use EHR or medical claims data — alone or linked — as the data source for a clinical study intended to support a regulatory determination of effectiveness or safety. Its organizing logic is the fitness-for-use assessment: whether a given data source is relevant (does it capture the exposures, outcomes, covariates, and population needed to answer the question) and reliable (are the data accrued, curated, and quality-assured such that the captured values can be trusted), and whether those properties can be documented and audited. It sits alongside FDA's parent RWE Framework and its companion guidances on study designs using RWD and on regulatory submission of RWD/RWE.

When to use

— Apply this guidance whenever an EHR- or claims-based non-interventional study (or the external-control or hybrid arm of a trial) is being designed, conducted, or documented with the intent of submitting it to FDA to support an effectiveness or safety claim — an IND, NDA, BLA, sNDA/sBLA, or a required post-marketing study. Use it from the protocol stage, not retrospectively: the guidance expects the data-source assessment, study design, and analysis plan to be pre-specified before analytic results are seen, and it expects sponsors to engage the Agency early. Decision rules for this document versus its siblings: use this guidance when the central question is can this EHR/claims data source support the study (data provenance, linkage, validation, accrual, quality control); use FDA's "Considerations for the Use of RWD and RWE to Support Regulatory Decision-Making" guidance when the question is broader design/analysis considerations across RWD types; use the "Data Standards for Drug and Biological Product Submissions Containing RWD" guidance for the submission/format mechanics. For an HTA or payer dossier, or a peer-reviewed manuscript, this guidance is a strong reference standard but the reporting vehicle is typically STaRT-RWE, STROBE/RECORD-PE, or HARPER — use those for the report and this guidance to justify the data source. EMA/ENCePP work is governed by its own GVP and ENCePP instruments; this guidance carries no statutory force outside FDA but its fitness-for-use expectations are broadly concordant.

What it requires

— The guidance enforces documentation across several substantive domains. (1) Data source provenance and selection: why this EHR/claims source, who curates it, how raw records become the analytic dataset, and the full set of data-management/transformation steps, including any extraction-transformation-load conversions to a common data model. (2) Fitness-for-use — relevance: availability of the key exposures, outcomes, covariates, and a population that maps to the target; adequate follow-up and the temporality needed for the estimand. (3) Fitness-for-use — reliability: data accrual and lag, completeness, plausibility, conformance, and provenance/audit traceability back to source records. (4) Definition and validation of study variables: pre-specified operational definitions for exposure, outcomes, and covariates, and validation of the computable phenotype/algorithm (e.g., PPV, sensitivity against a reference standard such as chart review or adjudication), with the validation population representative of the study population. (5) Linkage: when EHR, claims, registries, or mortality files are linked, the linkage method, match rate, and the error/selection it introduces. (6) Design integrity: clear time-zero/index definition that avoids immortal time, appropriate comparator, and covariate assessment windows. (7) Quality assurance and governance: a data quality plan, study monitoring, and access for FDA inspection/audit of source data. Although FDA does not publish a numbered checklist, sponsors are expected to provide this evidence prospectively and to be able to reproduce the analytic dataset from source.

When NOT to use — limitations and common misapplications

— This is a regulatory framework, not a risk-of-bias instrument and not a numeric quality score: there is no item count, no threshold, and "addressing the guidance" produces no grade. The most damaging misapplications: (a) treating the guidance as a scorecard or checklist-as-theater — listing that each domain was "considered" without the underlying validation, lineage, and quality evidence; (b) assuming that satisfying the data-fitness expectations confers causal validity — the guidance governs whether the data can support the question, not whether the design identifies a causal effect, which still requires comparator choice, confounding control, and bias analysis; (c) conflating data accrual lag with fitness-for-use, or ignoring lag entirely so that recent outcomes are differentially undercaptured; (d) using an unvalidated computable phenotype, or borrowing a PPV from a different database/era as if it transports; (e) using EHR problem-list or claims service dates as time-zero without confirming the actual index event, which manufactures immortal time and misclassifies exposure; (f) declining negative-control or quantitative bias diagnostics on the grounds that "the guidance does not require them" — they are how reliability claims are stress-tested. It is also the wrong primary instrument for prospective registries collected to protocol, for primary-data-collection studies, or for non-US submissions where ENCePP/GVP govern; and it does not replace the design or data-standards guidances in its own family.

How it maps to this catalog

— Each requirement is implemented by a concrete concept here. Fitness-for-use (relevance + reliability) → `fit-for-purpose-data-assessment-rwe`, with payer structure and coding-intensity nuances in `medicare-ffs-ma-commercial-claims-differences-rwe` and data-source mechanics in `claims-analysis`. Phenotype/algorithm definition and validation → `diagnosis-phenotype-algorithm-1ip-2op-time-window-rwe`. Design integrity, comparator, and time-zero → `target-trial-emulation` and `active-comparator-new-user`, with immortal-time pitfalls in `immortal-time-bias-handling`. Estimand and intercurrent events → `estimands-ate-att-intercurrent-events-rwe`. Confounding control → `high-dimensional-propensity-score-hdps-rwe` and `propensity-score-methods-psm-iptw`. Attrition, accrual lag, and missingness → `attrition-and-loss-to-follow-up-rwe` and `database-feasibility-attrition-funnel-rwe`. Reliability stress-testing and sensitivity → `empirical-calibration-negative-controls-rwe`, `e-value-sensitivity-analysis`, and `quantitative-bias-analysis-toolkit-rwe`.

Applied note (claims/EHR/registry RWE). In a Medicare FFS + commercial claims effectiveness study, satisfying this guidance means: documenting the licensor, refresh cadence, and claims adjudication lag (often 3–6 months, longer for some settings) and excluding immature person-time; requiring continuous medical+pharmacy enrollment so absence of a code is true-negative rather than missing; restricting or flagging Medicare Advantage person-time where FFS claims are absent; pre-specifying and validating the outcome phenotype (e.g., a 1-inpatient-or-2-outpatient rule with PPV from chart-confirmed cases in this source); fixing time-zero at the first qualifying fill, not the diagnosis date; and pre-registering negative-control outcomes and an E-value so the reliability of the comparison is demonstrated, not asserted. Linked EHR adds severity and lab detail but its match rate and linkage selection must be reported.