Tracing Analysis Datasets Back to Source Under ICH E6(R3)

Where ICH E6(R3) Stands in October 2026

Before looking at what the guideline asks for, it helps to be exact about where it applies. Status claims about E6(R3) are often written loosely, and the details matter for which text an inspector will hold you to.

The Principles and Annex 1

The ICH Regulatory Members endorsed the E6(R3) principles and Annex 1 at Step 4 on 6 January 2025.¹ The European Medicines Agency lists 23 July 2025 as the effective date for the principles and Annex 1 in the EU.³ In the United States, FDA announced the final guidance “E6(R3) Good Clinical Practice” in the Federal Register on 9 September 2025. The notice describes the guidance as a principles document plus Annex 1, finalizing the draft of June 2023.⁴ As with any FDA guidance, it is FDA’s current thinking rather than a binding rule; the binding requirements for US trials remain in the regulations.

In the UK, MHRA guidance states that compliance with the ICH E6 GCP principles became a legal requirement on 28 April 2026, the date the amended UK clinical trials regulations took full effect. The same guidance notes that UK-specific principles were kept, including one requiring investigators and sponsors to have regard to relevant guidance, so the annexes cannot simply be set aside.⁶

Annex 2 and the Consolidated Text

Annex 2, which covers decentralized elements, pragmatic elements, and real-world data (RWD), was endorsed at Step 4 on 3 June 2026. ICH then adopted a consolidated E6(R3) guideline on 16 June 2026 that brings the principles, Annex 1, and Annex 2 into one document.² EMA lists 15 January 2027 as the effective date for Annex 2 and for the consolidated guideline in the EU.³ As of the end of September 2026, FDA’s Annex 2 page still shows the December 2024 draft, marked as not for implementation.⁵

For traceability, the sections that matter most (Annex 1 sections 3.16 and 4.2) carry the same numbers in the January 2025 text and the June 2026 consolidated text. We cite the January 2025 text throughout because it is the version in force today in the EU and the version FDA published.

What ICH E6(R3) Says About Data Traceability

Traceability in E6(R3) is not confined to one section. It appears in the principles, in the investigator and sponsor responsibilities, and in the new data governance section. Reading them together gives a fuller picture than any single clause.

The Principle

Principle 9.4 asks that clinical trials include processes for managing records, including data, that maintain record integrity and traceability and protect personal information, so that trial information can be accurately reported, interpreted, and verified.¹ Note the last three verbs. A result that cannot be traced back cannot be verified, and the principle treats verification as part of the purpose of record management, not an afterthought.

The Statistical Programming Clause

The most direct statement is in the sponsor’s responsibilities, under section 3.16.2 on statistical programming and data analysis. Clause (c) reads: “The sponsor should ensure the traceability of data transformations and derivations during data processing and analysis.”¹ Clause (f) adds that the sponsor should retain the statistical programming records behind the outputs used in trial reports, including quality control and validation work, and says: “Outputs should be traceable to the statistical software programs, dated and time stamped, protected against any changes, and have access controls implemented to avoid inappropriate viewing of information that may introduce bias.”¹

Two further clauses in the same section shape what “traceable” has to cover. Clause (d) asks that the criteria for including or excluding participants from any analysis set be defined in advance, with the reason for excluding any participant or data point documented. Clause (e) says that deviations from the planned analysis, and data changes made after unblinding, should be documented, justified, and reported in the clinical trial report, and that post-unblinding data changes should happen only in exceptional cases, be authorized by the investigator, and be reflected in an audit trail.¹ A traceability model that follows values but not population membership, or that stops at database lock, does not meet these clauses.

The Data Governance Section

Section 4 is new in E6(R3). Its introduction says it gives guidance on the management of data integrity, traceability, and security, and it asks for key processes that cover the full data life cycle, including processes that support key decisions such as data finalization before analysis, unblinding, and allocation to analysis data sets.¹ Section 4.2 then walks the life cycle:

• 4.2.1 Data capture. Data from any source should be accompanied by relevant metadata.
• 4.2.2 Metadata, including audit trails. Systems should log user account creation, role and permission changes, and user access, keep initial entries and later changes, record workflow actions, and capture date and time unambiguously (the guideline gives coordinated universal time as an example).
• 4.2.4 Data corrections. Corrections should be attributed, justified, and supported by source records.
• 4.2.5 Data transfer, exchange, and migration. “The data exchange/transfer process or system migration should be documented to ensure traceability, and data reconciliation should be implemented as appropriate to avoid data loss and unintended modifications.”
• 4.2.6 Finalization of data sets before analysis. Finalization activities, such as reconciliation, coding, and handling of protocol deviations, should be confirmed and documented, and data extraction and determination of analysis sets should follow the planned analysis and be documented.
• 4.2.7 Retention and access. Data and relevant metadata should be archived so they can be retrieved and read, and protected from unauthorized change, for the whole retention period.¹

The Supporting Clauses

Several shorter clauses fill in the rest. Section 2.12.2 asks investigators to define what counts as a source record, the methods of capture, and their location before the trial starts, and says unnecessary transcription steps between the source record and the data acquisition tool should be avoided. Section 3.16.1(c) asks the sponsor to pre-specify the data to be collected and, where needed, to put further details, including a data flow diagram, in a protocol-related document such as a data management plan. Section 3.16.1(s) calls for an unambiguous participant identification code that links all data reported for each participant. Section 3.16.1(r) asks that edit access to data acquisition tools be restricted before data are provided for final analysis and, where applicable, before unblinding.¹

Finally, Appendix C’s Essential Records Table lists, among other items, documentation relating to data finalization for analysis (with output data sets as an example) and documentation of statistical considerations and analysis, which includes analysis sets decisions, analysis data sets, analysis programs, quality control records, and outputs. The appendix states that if these records are produced, they are essential and should be retained.¹ In plain terms: the analysis datasets and the programs that built them are trial records, not working files.

How the Submission Standards Fill In the Detail

E6(R3) tells sponsors what must be true. It does not say what the datasets should look like. For US submissions, that detail comes from FDA’s study data guidance and its technical specifications, which in turn point to the CDISC standards.

FDA’s Study Data Framework

FDA’s guidance “Providing Regulatory Submissions in Electronic Format: Standardized Study Data” (Revision 2, June 2021) implements the electronic submission requirement in section 745A(a) of the Federal Food, Drug, and Cosmetic Act for standardized study data. It names separate technical documents that are updated over time, including the Data Standards Catalog and the Study Data Technical Conformance Guide.⁸ The Catalog lists which standards and versions FDA supports; its current page is dated March 2025.⁹ The Technical Conformance Guide (TCG) gives the detailed recommendations. The current version is dated June 2026 (version 6.2.1).⁷

Section 8 of the TCG covers study data traceability. It says that understanding the provenance of the data is an important part of review, and that traceability allows the reviewer to understand how analysis datasets were built, which observations and algorithms were used to derive variables, how a confidence interval or p-value was calculated, and how counts in tables, listings, and figures relate to the underlying data.⁷ The guide is direct about the stakes: “Based upon reviewer experience, establishing traceability is one of the most problematic issues associated with any data conversion.” It continues: “If the reviewer is unable to trace study data from the data collection of subjects participating in a study to the analysis of the overall study data, then the regulatory review of a submission may be compromised.”⁷

The TCG also says traceability is improved when data are collected on a standardized case report form such as CDASH, and “further enhanced when a flow diagram is submitted showing how data move from collection through preparation and submission to the Agency.”⁷ That recommendation lines up with E6(R3) section 3.16.1(c), which asks for a data flow diagram in a protocol-related document. One diagram, kept current, can serve both.

SDTM, ADaM, and Define-XML

CDISC’s Study Data Tabulation Model (SDTM) organizes collected data into standard domains. The Analysis Data Model (ADaM) defines analysis datasets. CDISC describes ADaM as supporting efficient generation, replication, and review of analyses, and traceability among analysis results, analysis data, and data represented in SDTM.¹⁰ Define-XML carries the metadata for SDTM, SEND, and ADaM datasets.¹¹

The TCG adds practical expectations for each. ADaM datasets should be derived from SDTM datasets, and the guide adds: “To ensure traceability, all SDTM variables utilized for variable derivations in ADaM should be included in the ADaM datasets when practical.” For numeric dates in ADaM, the SDTM character dates in ISO 8601 format should also be included, for traceability. Imputation methods should be explained in define.xml and the Analysis Data Reviewer’s Guide.⁷ On the data definition file, the guide calls it “arguably the most important part of the electronic dataset submission for regulatory review” and warns: “An insufficiently documented data definition file is a common deficiency that reviewers have noted.” It asks sponsors to give complete detail, especially for derived variables, and to make the origin of each variable easy to find.⁷

Sponsors are also asked to submit the source code used to create all ADaM datasets, tables, and figures for the primary and secondary efficacy analyses, and to state the software, version, and operating system in the Analysis Data Reviewer’s Guide.⁷ That is the submission-side counterpart of E6(R3) section 3.16.2(f).

Metadata Traceability and Data Point Traceability

ADaM practitioners separate two kinds of traceability. Metadata traceability explains, in the dataset and variable documentation, how an analysis variable was derived. Data point traceability links an individual analysis record to the specific input records it came from, for example through the SDTM sequence number or the ADaM variables SRCDOM, SRCVAR, and SRCSEQ, which name the source dataset, source variable, and source record.¹³

Two members of the CDISC ADaM team, writing in a 2025 PharmaSUG paper, quote the ADaM implementation guide’s definition of traceability as the “property that enables the understanding of the data’s lineage and/or the relationship between an element and its predecessor(s)”. They also quote the ADaM model on the relationship between the two kinds: metadata traceability “must always clearly explain how an analysis variable was populated regardless of whether datapoint traceability is also provided.”¹² In other words, record-level links are welcome where practical, but the written derivation is not optional.

The EU View of the Same Flow

EMA’s guideline on computerized systems and electronic data in clinical trials asks for a detailed diagram and description of the data flow in the protocol or a protocol-related document. It lists what the description should cover: which data will be transferred and in what format, the origin and destination, the parties with access, the timing of transfer, and any actions applied along the way, such as validation, reconciliation, verification, and review. It then repeats the E6(R3) sentence on traceability of transformations and derivations.¹⁷ The same guideline asks that transfers be validated, pre-specified, and tested with challenging data sets, and that data migrations be planned, risk assessed, and verified afterward with a focus on key data.¹⁷

Behind all of this is an older ICH expectation. ICH E9 states that “The credibility of the numerical results of the analysis depends on the quality and validity of the methods and software” used for data management and for statistical processing, and asks for documented testing of that software.¹⁸ E6(R3) section 3.16.2 says it should be read together with E9.¹

Five Handoffs From Source to Result

A clinical result passes through several hands and systems before it reaches the clinical study report. Traceability is created, or lost, at each handoff. Treating each one as a separate control point makes the problem manageable, because each handoff has a different owner, a different failure pattern, and a different piece of evidence that answers the question “where did this come from?”

Handoff 1: Source Record to Data Acquisition Tool

The first handoff moves data from the source (a medical record, a participant’s diary, an instrument reading) into the case report form or other data acquisition tool. E6(R3) asks investigators to define source records and capture methods before the trial starts, and to avoid unnecessary transcription.¹

FDA’s guidance on electronic source data in clinical investigations sets out what the record at this handoff should carry. The eCRF should record who entered or generated the data and when, and changes should not obscure the original entry. Each data element should carry identifiers for its originator (a person, system, device, or instrument), the date and time it entered the eCRF, and the subject it belongs to. FDA says these identifiers allow authorized parties to examine the audit trail and help FDA reconstruct and evaluate the investigation. The guidance also says the sponsor should develop and maintain a list of all authorized data originators and make it available at each site.¹⁵ Where data come from an electronic health record, FDA’s EHR guidance says the EHR is identified as the data originator for those data elements.¹⁶

Evidence at this handoff: the source data location list, the list of authorized data originators, the eCRF audit trail, and the annotated case report form that maps each collection field to a variable.

Handoff 2: External Data Into the Sponsor Database

Central laboratory results, imaging reads, electronic patient-reported outcomes, randomization and dispensing data, and device readings usually arrive by transfer rather than entry. E6(R3) section 4.2.5 asks that these transfers be documented and reconciled. EMA’s guideline asks that they be pre-specified, validated with challenging test sets, and described in the data flow.^1,17

This handoff fails more often than teams expect, because each vendor controls its own format, and specifications drift during a long trial. A transfer specification that was agreed at study start and never versioned is a common gap: when a vendor adds a field or changes a unit, the downstream mapping no longer matches the document that describes it.

Evidence at this handoff: versioned data transfer agreements and specifications, transfer logs with record counts, reconciliation reports (for example serious adverse event reconciliation between the safety and clinical databases), and the validation record for each transfer process.

Handoff 3: Clinical Database to SDTM

The third handoff restructures collected data into tabulation domains. This is where the annotated CRF and the SDTM define.xml do their work. The TCG describes the annotated CRF as a document that maps each collection field to the corresponding SDTM variable or value, and it asks that collected data not included in the converted datasets be apparent on the annotated CRF and explained in the reviewer’s guide.⁷

Mapping specifications are the main control here. The specification states the rule; the program implements it; the define.xml publishes it. When the three disagree, traceability is lost even if every value is correct, because no one outside the programming team can confirm which version of the rule was applied.

Evidence at this handoff: the annotated CRF, versioned SDTM mapping specifications, the SDTM programs with version history, the SDTM define.xml, the clinical Study Data Reviewer’s Guide, and the conformance check results with explanations for any issues left open.

Handoff 4: SDTM to ADaM

The fourth handoff is where E6(R3) section 3.16.2(c) applies most directly: derivations. Baseline flags, analysis visits, imputed dates, responder definitions, time-to-event variables, and population flags are all created here. Each is a judgment written as code, and each has to be traceable to the statistical analysis plan and to the SDTM records that feed it.

A 2013 PharmaSUG paper on ADaM traceability shows why record-level links matter when an analysis value can come from more than one SDTM domain. In the paper’s example, a score drawn partly from one domain and partly from another cannot be traced with a single sequence variable; SRCDOM, SRCVAR, and SRCSEQ record which domain, variable, and record each analysis value came from.¹³

Evidence at this handoff: the statistical analysis plan, versioned ADaM specifications, ADaM programs and their validation records, the ADaM define.xml with derivation text for every derived variable, the Analysis Data Reviewer’s Guide, and records of analysis set decisions.

Handoff 5: ADaM to Tables, Figures, and the Report

The final handoff produces the numbers people read. E6(R3) section 3.16.2(f) asks that outputs be traceable to the programs that produced them, dated and time stamped, protected against change, and access controlled.¹ The TCG lists “Limited traceable path from ADaM to the Tables, Figures and the Clinical Study Report” among the problems it sees in converted legacy data.⁷

Evidence at this handoff: a program-to-output index, output logs showing the program version and input dataset versions used, independent QC records, and the final output files in a protected location.

What Sponsors Must Be Able to Show

Two audiences test traceability, and they come at it from opposite ends. An FDA reviewer usually starts from a result and works backward to understand how it was produced. A GCP inspector often starts from a participant’s source record and works forward to see what happened to it. A sponsor needs to support both directions.

The Reviewer’s Questions

The TCG lists what traceability should let a reviewer do: understand how analysis datasets were built, determine the observations and algorithms used to derive variables, understand how a confidence interval or p-value was calculated, and relate counts in tables, listings, and figures to the underlying data.⁷ Each of these maps to a specific artifact. The first is answered by ADaM specifications and the reviewer’s guide; the second by derivation metadata and data point links; the third by the analysis program and analysis results documentation; the fourth by population flags, analysis set records, and the program-to-output index.

The Inspector’s Questions

E6(R3) gives inspectors a broader set of questions, because the guideline covers conduct as well as analysis. Can the sponsor show that data were not changed after the fact without explanation? Were post-unblinding changes documented, justified, and authorized by the investigator? Was edit access restricted before final analysis? Were transfers reconciled? Can the analysis datasets and programs be retrieved and read years later?¹ These questions reach beyond the submission package into audit trails, access logs, and retention.

The Trace Drill

The simplest way to find out whether you can answer both sets of questions is to try it before anyone asks. A trace drill picks real values and walks them through every handoff with the documents a reviewer or inspector would see.

Where Traceability Breaks in Practice

Most traceability failures are not caused by bad programming. They come from change: to the database, the protocol, the vendor, the standard, or the team. The patterns below come from the regulator and practitioner sources cited here, and each one points to a specific control.

Mid-Study Database Changes

A 2024 PharmaSUG paper by statistical programmers at a rare disease sponsor sets out how EDC updates and protocol amendments cascade into SDTM and ADaM.¹⁴ Some examples from its tables:

• When a form is replaced with a new version and data already collected on the old form are not moved across, SDTM programs must read both forms, and the specifications must say so.
• When new fields are added to a visit form for future visits only, earlier visits will be missing those values, and the paper suggests explaining this in the clinical Study Data Reviewer’s Guide.
• When fields stop being integrated from an external system, the team has to decide whether to map them from another source or drop them, and update specifications and annotations to match.

Each of these is a point where the annotated CRF, the mapping specification, the program, and the define.xml can fall out of step. The control is simple to state: every database change should trigger an impact check on downstream specifications, with the result recorded in change control.

Legacy Conversions

When older studies are converted to SDTM and ADaM after the fact, often for an integrated summary, the TCG lists the traceability problems reviewers see. They include limited ability to locate collected variables in converted SDTM data unless the annotated CRF is re-annotated, limited ability to replicate legacy analysis datasets from SDTM, and, where SDTM and ADaM were converted independently, a limited path from SDTM to ADaM.⁷ FDA recommends a legacy data conversion plan and report, provided in the reviewer’s guide, and, when legacy datasets are submitted, two separate CRF annotations: one based on the original legacy data and one based on the converted data.⁷

Complex Derivations in One Step

Time-to-event endpoints are a frequent example. The 2025 PharmaSUG paper by two ADaM team members points out that building an event or censoring date directly from several SDTM domains leaves a reviewer to open each of those domains to find the source. They recommend an intermediate dataset that collects every candidate event and censoring date, with SRCDOM, SRCVAR, and SRCSEQ in both the intermediate and final datasets pointing to the immediate predecessor.¹² The general lesson applies beyond oncology: when a derivation takes several decisions, keep each decision visible in data rather than hidden inside one program.

Late Data Changes and Unblinding

E6(R3) section 3.16.2(e) expects changes made after unblinding to be exceptional, documented, justified, authorized by the investigator, audit trailed, and reported in the clinical trial report.¹ In practice, the weak point is often not the change itself but the rerun. If a corrected value flows through reprocessed SDTM and ADaM datasets, the sponsor needs to show which outputs changed, which program versions produced them, and that nothing else moved. Without dataset versioning and run logs, this cannot be shown.

Handoffs Between Sponsor and Service Providers

Statistical programming is frequently outsourced, and sometimes split across providers: one CRO builds SDTM, another builds ADaM, and a third produces an integrated summary. E6(R3) section 3.6.6 is clear that sponsors may transfer activities but keep ultimate responsibility, including for the reliability of trial data.¹ Traceability gaps tend to appear at the boundary between providers, where each party’s documentation is complete for its own work and nobody owns the connection.

Real-World Data Under Annex 2

Annex 2 adds another source of lineage risk. It describes the reliability of RWD as including accuracy, completeness, provenance, and traceability, and it notes that sponsors generally do not control how RWD were originally collected, recorded, or curated.² It also states that, whoever owns the data or performs the processing, sponsors remain responsible for oversight of the processing steps, including extraction, linkage, and transformation.² For higher-criticality uses, such as key efficacy or safety endpoints, Annex 2 says a fitness-for-purpose assessment of the RWD source may not be enough on its own, and sponsors may need access to source records.² Annex 2 applies in the EU from 15 January 2027, so trials planned now that use RWD should design for it.³

Practical Controls That Hold Up

The controls below are proportionate by design. E6(R3) asks that data governance processes focus on data criticality and be implemented proportionately.¹ Not every variable needs record-level links, and not every exploratory output needs the same protection as the primary endpoint. What every study needs is a clear decision about where the line is, written down before the data arrive.

Decide Where Data Point Traceability Is Required

Because the ADaM model allows data point traceability to be left out where it is not practical, but always requires metadata traceability, sponsors should make this decision deliberately.¹² A sensible rule is to require record-level links for primary and key secondary endpoints, for any value drawn from more than one source domain, and for any imputed or derived record, and to rely on complete derivation metadata elsewhere. Write the rule into the ADaM specification template so it is applied the same way across studies.

Write Traceability Into Service Provider Agreements

Given E6(R3) section 3.6.6, the sponsor’s agreements with programming and data management providers should state what traceability evidence each provider delivers, in what format, and when. Useful items include the specification versions, program source code, run logs, QC records, and a handoff note describing any known limitations. Where more than one provider works on the same study, name who owns the interface between them.

Keep the Reviewer’s Guides Honest

The clinical Study Data Reviewer’s Guide and the Analysis Data Reviewer’s Guide are where a sponsor explains anything unusual: data that were collected but not submitted, conversions, imputations, and conformance findings left open.⁷ They are most useful when they are written during the study, as decisions are made, rather than reconstructed at submission. A running log of data handling decisions, owned by the study statistician, makes the final guides faster to write and more accurate.

Assign Clear Ownership

Traceability crosses functions, which is why it often has no single owner. The table below shows one practical split. The names of the roles matter less than the fact that each handoff has one accountable owner.

Where to Start

For most sponsors, the gap is not a missing standard. The standards are in use. The gap is usually evidence that exists in pieces, held by different teams and providers, without a single thread connecting them. The sequence below starts with what you have and closes the largest gaps first.

Conclusion

E6(R3) does not introduce traceability to clinical data. Statistical programmers have built it into submissions for years because reviewers asked for it. What changes is the source of the obligation. Traceability of transformations, documented transfers with reconciliation, outputs traceable to protected programs, and retained analysis datasets are now written into the GCP guideline that applies across the EU and UK and that FDA has adopted as guidance. That makes traceability a sponsor accountability that inspectors can test, not only a review convenience. The practical answer is to stop treating inspection readiness and submission readiness as separate projects. The same evidence set, organized by handoff and owned by named people, serves both.

Sakara Digital works with pharma and biotech organizations on the data governance and quality systems behind clinical data, including the controls that connect source records to submitted results. If you are reviewing how your studies meet E6(R3) data traceability expectations, or planning for RWD under Annex 2, and want an independent perspective on where to start, we are happy to have that conversation.

For Further Reading