Real-World Evidence Pipelines: The Compliance Controls Sponsors Need

Why the Pipeline Is Part of the Evidence

In a randomized trial, the sponsor controls data capture from the start. Sites enter data into a validated electronic data capture system, monitors check it against source, and the database is locked under a documented process. Real-world data works differently. The data was recorded for patient care or billing, by people who never expected it to support a regulatory decision, in systems the sponsor does not own. By the time it reaches a sponsor’s analysis environment, it has usually passed through several hands: the health system or payer that recorded it, a data aggregator that cleaned and standardized it, perhaps a tokenization vendor that removed identifiers, and the sponsor’s own programmers who shaped it into an analysis file.

Every one of those steps can change the data. A code gets remapped. A duplicate patient gets merged, or fails to get merged. A lab value in the wrong unit gets dropped as implausible. A new data feed starts partway through the study period and makes an outcome look more common in later years. None of these changes are visible in the final table of results. They are visible only if the pipeline recorded them.

That is why FDA’s framing of real-world evidence has always included the data handling, not just the statistics. FDA’s 2018 framework for its RWE program defines real-world data as data relating to patient health status or the delivery of health care routinely collected from a variety of sources, and real-world evidence as the clinical evidence about a product’s use and potential benefits or risks derived from analysis of that data.¹ The framework says FDA will look at three things: whether the real-world data are fit for use, whether the study design can provide adequate scientific evidence, and whether the study conduct meets FDA regulatory requirements.¹ The first and third questions are both about the pipeline.

What a Successful Submission Looked Like

FDA’s July 2021 approval of Prograf (tacrolimus) for preventing organ rejection in lung transplant patients is the example most people cite. The approval rested on a non-interventional study that used data from the U.S. Scientific Registry of Transplant Recipients, which FDA noted collected data on all lung transplants in the United States, supplemented with mortality information from the Social Security Administration’s Death Master File.² FDA said the approval reflected how a well-designed, non-interventional study relying on fit-for-purpose real-world data, compared with a suitable control, can be considered adequate and well-controlled under FDA regulations.²

Look at what that sentence depends on. “Fit-for-purpose” is a claim about the data source and its processing. The study also linked two data sources: a registry and a national death file. So even this clean example involved a documented source, a linkage step, and a comparison against a known natural history. Sponsors who want to repeat that kind of outcome need to be able to show the same things about their own data, and most real-world datasets are messier than a national transplant registry.

The Shift From “Good Data” to “Provable Data”

Many RWE teams still treat data quality as a property of the vendor’s product. The vendor says its data is high quality, the license agreement is signed, and the analysis begins. The final FDA guidance does not support that approach. It asks sponsors to describe and justify how data was accrued, curated, transformed, and linked, to show that curation did not change the meaning of the data, and to keep audit trails from extraction through dataset retention.³⁴ That is a set of controls the sponsor must own, even when a third party runs part of the pipeline.

Where FDA’s RWE Guidance Stands in 2026

Before building controls, it helps to be precise about which documents are final and which are still drafts. Guidance status matters because draft guidance is issued for comment and does not represent FDA’s current thinking for implementation, while final guidance does. Both are nonbinding. FDA’s own data standards guidance for real-world data reminds readers that guidance describes the Agency’s current thinking, that the word “should” means something is recommended rather than required, and that specific regulatory or statutory requirements are the exception.⁶

The table below lists the drug and biologic documents most relevant to pipeline controls, with the status and date shown on FDA’s guidance pages as of September 2026.

The Parts That Are Requirements, Not Recommendations

Most of the pipeline expectations in these documents are recommendations. A few rest on regulations or statute, and a pipeline design should treat those as fixed:

• Patient-level data for applications. The August 2023 considerations guidance states that sponsors must ensure they can submit patient-level data for any real-world data analyzed as part of a clinical study included in a marketing application, when required under 21 CFR 314.50 and 601.2.³
• Electronic study data format. The data standards guidance explains that the electronic submission requirements under section 745A(a) of the Federal Food, Drug, and Cosmetic Act apply to real-world data submitted as study data in covered application types. Absent a waiver, sponsors must use the formats in FDA’s study data guidance and the standards listed in the Data Standards Catalog.⁶
• Electronic records. For marketing applications containing non-interventional study data, the considerations guidance says the electronic systems the sponsor uses to manage the data and produce required records should comply with 21 CFR Part 11, FDA’s regulation on electronic records and electronic signatures.³
• Safety reporting. If a sponsor identifies adverse events subject to postmarketing reporting while conducting a non-interventional study, those events must be reported under the applicable regulations, although FDA does not expect a sponsor to search an entire database for all uses of a product.³

What EMA Adds

Sponsors filing in both the US and EU should also read EMA’s Data Quality Framework for EU medicines regulation: application to Real-World Data. The document is dated 27 March 2026 and was adopted by CHMP on 16 March 2026, following a public consultation that opened in November 2024.¹² It organizes data quality around dimensions including reliability, extensiveness, coherence, timeliness, and relevance, and it treats RWD quality as a responsibility shared among data holders, data users, and regulators.¹² For pipeline design, its most useful parts are a responsibility matrix and a short list of minimum information to provide about a data source in a regulatory submission, both covered below.

Control 1: Provenance and Data Access

Provenance means knowing where each data element came from and what happened to it on the way. In real-world data, provenance starts before any code runs: it starts with the choice of data source and the contract that governs access to it.

Justify the Data Source Before the Analysis

The considerations guidance addresses a specific risk: that a sponsor might try several databases and report the one that gives the best answer. FDA says it must be confident, based on documentation, that data sources were not selected and analyses were not conducted to favor a certain conclusion.³ To support that, sponsors should describe in the protocol, or an appendix to it, the data sources evaluated when designing the study, including results of feasibility evaluations, and should justify selecting or excluding relevant sources.³

The guidance also draws a useful line around feasibility work. Feasibility evaluations help assess whether a source is fit for use and estimate statistical precision, but they do so without evaluating outcomes for treatment arms.³ A pipeline control follows from this. Feasibility queries should run in a separate, logged environment that cannot produce comparative outcome results, and the log should be kept as part of the study record. If an inspector asks how the sponsor knows no one looked at outcomes before the protocol was final, the answer should be a record, not a recollection.

Put Data Access in the Contract

Many sponsors license real-world data from a vendor that does not allow patient-level data to leave its environment. That creates a direct conflict with the patient-level data expectation described above. The considerations guidance says that when real-world data are owned and controlled by other entities, sponsors should have agreements in place to ensure that relevant patient-level data can be provided to FDA and that source data needed to verify the real-world data are available for inspection as applicable.³

When a sponsor has a justified reason it cannot submit patient-level data through the usual channels, the same guidance describes a route in which the third-party data provider opens a pre-investigational new drug application (pre-IND) or a Type V drug master file, and the sponsor provides a letter of authorization for FDA to reference the data. The guidance also states that FDA does not currently accept links to external databases for such data.³

The practical control is a data access clause reviewed by regulatory and quality before signature, not after. At minimum, the agreement should cover:

• Delivery of patient-level analysis data to FDA, or cooperation with a pre-IND or Type V drug master file route.
• Availability of source data for verification and inspection, to the extent the data holder can provide it.
• Notice of changes the data holder makes to collection, coding, or processing during the study period.
• Retention of the data version used in the study for as long as regulatory retention periods require.
• Roles and responsibilities for each organization, since the guidance says sponsors should document the roles of third parties such as data service providers and make those documents available to FDA on request.³

Trace Each Element Back to Its Origin

The EHR and claims guidance recommends that data quality reports include traceability of data elements, so that each element can be tracked back to its point of origin, with clear documentation of modifications that may have occurred.⁴ For registries, FDA lists among governance attributes a data dictionary that includes information on the origin of the data for each data element, and conformance with Part 11 where applicable, including “maintenance of access controls and audit trails to demonstrate the provenance of the registry data and to support traceability of the data.”⁵

In pipeline terms, this means every derived variable in the analysis dataset should carry lineage metadata: which source table and field it came from, which data holder release, which transformation programs touched it, and which version of each program ran. Lineage tools can capture much of this automatically for code-based pipelines. What they cannot capture is the data holder’s upstream processing, which is why the contract and the data holder’s own documentation matter.

Know What the Data Holder Changed

Real-world data sources change during a study period. Data holders fix errors, change adjudication rules, add or lose data feeds, and move to new coding versions. The EHR and claims guidance asks sponsors to address the reason for and timing of error corrections and process changes implemented by data holders during the relevant period of data collection.⁴ ICH M14, as issued by FDA, lists similar data holder considerations, including the frequency and type of error corrections or changes in adjudication policies, updates to coding practices, and changes in the availability of key data elements, such as when access to a key data feed is no longer available.¹¹

EMA’s framework reaches the same conclusion from the other side. Its high-level responsibility matrix assigns the data holder the job of documenting data provenance, implementing a quality management system, providing data quality metrics, and publishing metadata, and assigns the data user the job of assessing fitness for use, documenting data quality metrics, and validating and interpreting the data.¹² A sponsor cannot do its half well unless the data holder does its half and shares the results.

Control 2: Data Quality Checks at Every Stage

The single most useful section of FDA’s RWE guidance for pipeline teams is section VI of the July 2024 EHR and claims guidance, on data quality during data accrual, curation, and transformation into the final study-specific dataset. It describes a data life cycle with multiple phases: accrual from original source data, curation into a clinical data repository, transformation and de-identification where needed, creation of a data warehouse, and production of a study-specific dataset for analysis.⁴

The key instruction is that quality assessment is not a single event. FDA describes it as an ongoing process in which data quality checks, cleansing, and monitoring occur at each phase, with some checks repeated across phases.⁴ For a pipeline, that means a quality gate at each hand-off, not one review at the end.

Automated Data Quality Reports

FDA says it “recommends automated data quality reports that include the following characteristics and processes in a standardized way, when applicable to the chosen data source,” and then lists them by phase.⁴ This is the closest thing in the RWE guidance to a specification for a pipeline’s quality output. The list is long, but it groups into a manageable set of checks:

Use a Shared Vocabulary for Checks

FDA does not endorse a particular set of data quality guidelines, but it asks sponsors to evaluate completeness, accuracy, and plausibility, including verifying data against the original source and conforming to consensus-based data standards where applicable.⁴ The same section says the points it lists include characterizing the data with respect to completeness, conformance, and plausibility of data values.⁴ Those three words come from a harmonized data quality framework that many RWE groups already use, and FDA’s reference list includes work from the Duke-Margolis Center for Health Policy that builds on it.⁴¹³

The Duke-Margolis paper, published in September 2019, describes how verification checks for completeness, conformance, and plausibility contribute to assessing whether real-world data are reliable enough to be fit for use.¹³ In its terms, conformance checks show compliance with a prespecified standard, and completeness checks measure how the data aligns with expectations, usually against practical thresholds set for the context.¹³ The paper also separates verification, which tests data against the metadata constraints and system assumptions within the dataset, from validation against external expectations, and it focused on verification as the first step toward standard checks.¹³ It is also candid that verification checks alone are not enough to show that data are fit for use.¹³

Using these categories matters less for theory than for audit. When every check in the pipeline is tagged as conformance, completeness, or plausibility, and as verification or validation, a quality reviewer can see coverage gaps quickly. A pipeline with hundreds of conformance checks and no checks on how values change over time will miss a coding change that doubled an outcome’s apparent incidence in one year.

Validate the Variables That Drive the Result

Pipeline checks confirm that data moved correctly. They do not confirm that a claims-based algorithm correctly identifies the patients who had the outcome. The EHR and claims guidance treats this separately, as validation of study variables, and asks sponsors to define exposures, outcomes, and key covariates conceptually and operationally and to justify which variables need validation.⁴ For compliance purposes, the pipeline control is to store each operational definition (the code lists, lookback windows, and logic) as a versioned, reviewable artifact rather than as logic buried inside a program.

Keep the Checks Risk-Based

Not every variable needs the same scrutiny. ICH M14 recommends a risk-based approach to quality assurance, balancing the need for QA against reasonable resource use, and says issues essential to the reliability and relevance of the data should be addressed in the protocol.¹¹ In practice, the variables that define the population, the exposure, the primary outcome, and the key confounders get source verification and validation. Descriptive variables get automated checks. That split, written down in the QA/QC plan, is the kind of decision reviewers expect to see justified.

Control 3: Linkage and Deduplication

Linkage is where many real-world data pipelines introduce bias without anyone noticing. Linking EHR data to claims, or registry data to a death file, fills gaps in the patient record. It also introduces two kinds of error: false matches, where records from different people are joined, and missed matches, where records from the same person are not. Both can distort results, and the distortion is rarely random.

Describe the Method and Test Its Impact

The EHR and claims guidance says that when a study involves new data linkages, the protocol should describe each data source, the information to be obtained, the linkage methods, and the accuracy and completeness of the linkages over time.⁴ It distinguishes deterministic linkage, which requires exact matches on a unique identifier or set of identifiers, from probabilistic linkage, which can link on fewer identifiers or partial matches. Both can have value, but when a probabilistic approach is used, the analysis plan should include testing the impact of the degree of match on the findings.⁴

In its list of transformation characteristics, the guidance goes further. It asks for quantification of linkage errors, such as false matches and missed matches, and says it is important to report details of the linkage algorithm and metrics such as linkage error rates, match rates, and a comparison of the characteristics of linked and unlinked data. It also asks whether the error is random or not, what the potential bias is, and what the impact is on risk estimates.⁴

Three Ways to Measure Linkage Quality

FDA cites Harron and colleagues’ 2017 guide to evaluating linkage quality, which offers a practical structure.⁴¹⁴ The authors describe three complementary methods:¹⁴

1. Compare against a gold standard. Run the linkage on a subset of records where the true match status is known, and measure how many false and missed matches the algorithm produces.
2. Compare linked and unlinked records. Look at whether demographic or clinical characteristics differ between records that linked and records that did not. If older patients or certain regions link less often, the linked population is not representative.
3. Run sensitivity analyses. Change the linkage thresholds or algorithm and repeat the analysis to see whether the results hold.

Each of these produces a document that belongs in the study record: the gold standard evaluation results, the linked versus unlinked comparison table, and the sensitivity analysis output. A pipeline that performs linkage without producing these artifacts has done the work but cannot show it.

Tokens, De-Identification, and Traceability

Much real-world data linkage in the US now uses privacy-preserving tokens: encrypted values derived from identifiers, generated separately at each data holder so that records can be matched without sharing names or dates of birth. The EHR and claims guidance recognizes this, asking sponsors to address de-identification of patient records and any process that could be used to re-identify unique patients in the original source data without losing traceability, with linkage tokens given as an example.⁴

Tokens make linkage possible, but they do not remove the need to measure linkage quality. Token-based matching depends on how consistently identifiers were recorded at each source. A name recorded with a nickname in one system and a legal name in another may produce different tokens. The linkage quality metrics above apply to token-based linkage as much as to any other method, and the sponsor should ask the tokenization vendor for match rate data by source and by subgroup.

Registry Linkage Has Extra Steps

The registries guidance adds requirements that apply whenever registry data are combined with another source. Sponsors should have a plan for addressing the adequacy and accuracy of patient-level linkages. Where data are transmitted to the registry electronically, sponsors should ensure that testing demonstrates interoperability of the linked systems, that automated transmission works in a consistent and repeatable way, and that data are transmitted accurately, consistently, and completely.⁵ The guidance also recommends predefined rules to check logical consistency and value ranges, to confirm that data were retrieved accurately from a linked source and that operational definitions of linked variables are aligned.⁵

The registries guidance also lists questions to ask of each potential linked source, including whether informed consent provided by patients contributing to each source would allow the linkage, and whether procedures and access controls protect the privacy of patient data.⁵ Consent scope is a compliance control, not just an ethics review item. If consent does not cover the linkage, the linked dataset may not be usable.

Deduplication Is Linkage Within a Source

Duplicates exist even within a single data source. The EHR and claims guidance notes that patients typically visit multiple health care sites, so de-identified data from many sites can contain several records for one person, leading to overcounts, or fragmented records that show only part of a patient’s care history.⁴ FDA recommends documenting the type of curation performed to address duplication or fragmentation and documenting approaches for issues that curation cannot fully fix.⁴ In the data management section, it adds that process descriptions should include safeguards or checks to ensure patient data are not duplicated or overrepresented.⁴

Control 4: Versioning and Audit Trails

An RWE result is only reproducible if every input can be recreated: the data release, the reference terminology versions, the transformation code, the operational definitions, the protocol, and the analysis programs. Versioning is what makes that possible. Audit trails are what show that nothing changed without a record.

What FDA Says About Audit Trails

The considerations guidance contains the clearest statement: “Sponsors should enable and maintain audit trails of data, starting from extracting RWD sources through maintenance and retention of dataset(s).” It continues that this process should include tracking of user access, data changes, changes to the protocol, and analyses performed.³

Notice the scope. This is not only an audit trail inside a database. It covers who accessed the data, what changed in the data, what changed in the protocol, and which analyses were run. Many RWE environments meet the first two through platform logging and miss the last two. Analyses run in an exploratory notebook, then deleted, leave no trace. That is exactly the gap FDA’s transparency concerns point to.

The data standards guidance makes a related point. During curation and transformation, documentation of processes may include electronic documentation such as audit trails and quality control procedures of data additions, deletions, or alterations from the source data system to the final study analytic datasets.⁶ ICH M14 uses almost the same language, describing electronic documentation that may include metadata-driven audit trails and QC procedures covering additions, deletions, or alterations from the data source to the final analytic datasets.¹¹

Part 11 for the Sponsor’s Systems

As noted above, the considerations guidance says the electronic systems a sponsor uses to manage non-interventional study data and produce required records should comply with 21 CFR Part 11.³ For registries, FDA lists validation of the electronic systems used to collect registry data and conformance with Part 11, as applicable, among the governance attributes it expects.⁵

This has a concrete meaning for pipeline design. The analysis environment, the code repository, the data storage layer, and the tools that produce study outputs are regulated systems for this purpose. They need access controls, audit trails, and a documented basis for trusting that they work as intended. Teams used to academic analysis environments sometimes find this the hardest adjustment: a shared drive of SAS or R programs with no change history does not meet the expectation.

Version the Inputs, Not Just the Code

Code versioning is common. Versioning of everything else is less common. A reproducible RWE pipeline versions at least these inputs:

• The data release. The ISPE-ISPOR joint task force on real-world evidence recommended reporting, among other parameters, the date or version number when data were extracted from a dynamic source, along with the source data range.¹⁵ A pipeline should keep an immutable snapshot of the exact release analyzed, or a documented way to recreate it.
• Terminology versions. The EHR and claims guidance asks sponsors to address any updates or changes in coding practices and versioning, such as ICD diagnosis codes and HCPCS procedure codes, across the study period.⁴ Code lists should record which version of each terminology they use.
• The common data model version. If data is converted into a common data model, the model version and the conversion code version both affect results.
• Operational definitions. Exposure, outcome, and covariate definitions should be stored as versioned artifacts with change history.
• The protocol and SAP. FDA says protocol revisions should be date-stamped with a rationale for each change, and that the protocol and SAP should be finalized and shared with FDA before conducting the prespecified analyses.³ ICH M14 calls version control for the protocol essential.¹¹
• Software environments. Statistical package versions and library versions, so that a rerun produces the same output.

Change Control Across Organizations

Change control in an RWE pipeline crosses company boundaries. The data holder changes its processing; the aggregator releases a new version; the sponsor’s programmers update a definition. A sponsor’s change control process should capture all three, with an impact assessment for each change that occurs during the study. The data holder change notices negotiated in the contract (Control 1) feed this process. Without them, the sponsor may not learn about an upstream change until an unexplained shift appears in the data.

Record Retention and Inspection Readiness

ICH M14 sets out principles for study documentation and record retention that translate directly into pipeline requirements. It says systems should be in place to ensure completeness of documentation, enable version control, prevent accidental or premature loss, prevent unauthorized access or alteration, and ensure that an audit trail is maintained. It also says study information should be readily available and directly accessible on request by regulators, and that information should be retained for at least the period applicable regulations require.¹¹

Retention is harder than it sounds for licensed data. A vendor license may expire before the retention period ends, or may require deletion of data at contract end. The sponsor needs a plan for keeping the analyzed data version, or a certified way to recreate it, available for as long as FDA may ask for it. That plan belongs in the data license negotiation, not in a scramble after an information request.

Control 5: Documentation FDA Expects

Documentation is where the other four controls become visible to a reviewer. The final guidances describe a fairly specific set of documents. Taken together, they form the evidence package for the pipeline.

The QA/QC Plan

The EHR and claims guidance says a QA/QC plan for construction of analytical data, the planned approach for handling quality control issues during analysis, and consideration of differing levels of data quality by data element (with their potential implications) should be described in the study protocol and analysis plan.⁴ It describes quality control as the decisions and steps taken from data collection through compilation of the final analytic dataset to ensure it meets prespecified standards and that the processes used are reproducible. It also says a multidisciplinary approach that includes clinical input is necessary.⁴

ICH M14 adds that researchers should implement and maintain QA/QC systems with written procedures, and it places responsibility clearly. The data holder maintains control of the data and is responsible for the underlying data quality, while the researchers are responsible for aligning QC and QA with the data holder and for the management and QA of all data cleaning, processing, and analytic datasets.¹¹

Data Management Documentation and Annotated Programs

The EHR and claims guidance says all manual and automated data retrieval and transformation processes should be thoroughly assessed from data collection through the final study report, and that sponsors should ensure curation and transformation do not alter the meaning of data or cause loss of important contextual information.⁴ Where unstructured data such as clinician notes are mined, documentation should describe the techniques used, such as natural language processing.⁴

Two specific points in that section are easy to miss. First, analysts should have appropriate training or experience with the data and software used. Second, to support FDA review, all submitted programs should be thoroughly annotated with comments describing the intent or purpose of each data management and analysis step.⁴ The considerations guidance adds that real-world data and associated programming code and algorithms submitted to FDA should be documented, well annotated, and complete, so that FDA can replicate the study analysis using the same dataset and analytic approach.³

Replication by FDA is the standard to design for. If an FDA analyst receives the dataset and the programs, can they run them and get the same result without calling the sponsor? That single test covers annotation, versioning, environment documentation, and completeness of the submitted code.

Standards Conversion Documentation

Real-world data submitted as study data in covered applications must meet FDA’s electronic study data requirements, which usually means converting to CDISC standards such as the Study Data Tabulation Model (SDTM) and the Analysis Data Model (ADaM). The data standards guidance says that with adequate documentation of the conformance methods used and their rationale, data derived from real-world sources can be transformed into SDTM and ADaM and submitted.⁶ The documentation it describes includes:

• Mapping rationale in the Study Data Reviewer’s Guide, including the general approach and anticipated impact of mapping, and the rationale for choosing particular standard data elements to represent real-world data.⁶
• A data dictionary documenting the definition of every data element derived from real-world sources that was mapped to the standard, with its relationships to other data, origin, usage, and format.⁶
• Define-XML mappings, including use of the Alias element to document conversion of source codes to CDISC controlled terminology while keeping traceability.⁶
• Transformation challenges and their handling, such as inconsistent coding, ICD-9 to ICD-10 transitions during the study, and missing information, with a justification for the approach taken.⁶

The guidance gives a pointed example: sex may be coded in CDISC terminology as a concept based on physical characteristics, while some EHRs record sex identity, so sponsors should document the potential impact of mapping that variable on study findings.⁶ The same logic applies to race and ethnicity categories, medication terminologies, and vital signs. Every mapping decision that could change a result needs a written rationale.

Protocol Transparency and the Submission Itself

Several documentation expectations are about transparency rather than data handling. The considerations guidance recommends that sponsors post study protocols on a publicly available website such as ClinicalTrials.gov or the ENCePP website, describe the source population and study population in the final report, and describe any analyses beyond the SAP as exploratory.³ It also says FDA expects sponsors to retain, and provide on request, a log of researchers with significant involvement in the design or conduct of the study, including their roles and qualifications.³

At the submission stage, the September 2022 guidance on submitting documents asks sponsors to identify in the cover letter of a submission containing RWD/RWE in support of labeling certain information, starting with the purposes for which RWD/RWE are used, to support FDA’s internal tracking of these submissions.⁷

Use a Structured Protocol Template

ICH M14 points to several sources of detailed templates, including the ISPE/ISPOR HARmonized Protocol Template to Enhance Reproducibility (HARPER).¹¹ HARPER was developed by a joint ISPE/ISPOR task force with input from regulators, health technology assessment bodies, industry, and academia. It combines free text, structured tables, and design diagrams, with the aims of helping investigators document their choices, helping reviewers assess potential bias, and making results easier to reproduce.¹⁶ For pipeline teams, HARPER’s value is that its structured tables force data source, linkage, and variable definition decisions into a consistent format that maps well to the controls in this article.

What EMA Asks For

EMA’s framework includes a short list of minimum information to provide about real-world data in a regulatory submission. It covers the data collection or generation context, including selection mechanisms; quality management practices, including the level of automation, extraction, cleaning and transformation steps, quality checks for inconsistent, missing, or out-of-range values, and remedial actions at the source; data enhancement measures, including linkage information such as data elements used and the linkage method; and whether patient-level or only aggregate data are available.¹² EMA notes that data holders can make this information public by registering the source in the HMA-EMA Catalogue of RWD Sources.¹² A sponsor that builds its documentation to satisfy both FDA’s lists and this EMA summary will rarely need to rebuild it for a second region.

Building the Controls Register

The five controls above are easier to manage when they are written down as a controls register: a table that names each control, its source in guidance, the evidence it produces, and its owner. The register becomes the index to the study’s data evidence package. When an FDA information request arrives, the team knows where each answer lives.

A Practical Build Order

Sponsors rarely build all of this at once. The order below puts the controls that are hardest to add later at the front.

Common Gaps to Look For

When a sponsor first maps its RWE work against these controls, these are the gaps worth checking for first. Each one is easier to fix before a submission than during review:

• Analysis history that disappears. Exploratory analyses run in notebooks or personal workspaces with no log. FDA’s audit trail expectation explicitly includes analyses performed.³
• Vendor quality claims with no metrics. The data holder says its data is curated but provides no release-level quality report, error correction log, or process change history.
• Linkage treated as a vendor service. The tokenization or linkage vendor returns a linked file, and no one produces match rates by subgroup or a linked versus unlinked comparison.
• Terminology drift left unmanaged. Code lists written for one ICD version and applied across a study period that includes a transition, without documenting how the transition was handled.
• A license that ends before retention does. The analyzed data version cannot be recreated once the vendor contract ends.
• Standards mapping decided late. SDTM conversion done at the end, by a different team, without a documented rationale for mapping choices that could affect results.

Conclusion

FDA’s RWE guidance for drugs and biologics has moved from mostly draft to mostly final, and the final documents are specific about the pipeline. They ask sponsors to justify their data sources, secure access for FDA, check quality at every stage of the data life cycle, measure linkage error rather than assume it away, keep audit trails from extraction to retention, version every input, and document the whole process well enough for FDA to replicate the analysis. ICH M14, issued by FDA as final guidance in March 2026, and EMA’s March 2026 data quality framework for real-world data point in the same direction. The sponsors that do well with real-world evidence will be the ones that treat the pipeline as a regulated process from the first data license, not as an analytics project that gets documented at the end.

Sakara Digital works with pharma and biotech organizations building the data, quality, and system controls behind regulated evidence. If you are planning a real-world evidence program and want an independent view of where your pipeline controls stand against current FDA and EMA expectations, we are happy to have that conversation.

For Further Reading