Between two transfers from the central laboratory, one LDL cholesterol result in a cardiovascular trial fell from 3.1 to 2.4 mmol/L. The value was participant 1047’s reading at visit 6, an input to the trial’s primary endpoint, the percent change in LDL-C from baseline. Below is everything the sponsor’s clinical data repository recorded about the change.
| Row | Time (UTC) | Action | Old | New | User (role, organisation) | Reason recorded |
|---|---|---|---|---|---|---|
| 1 | 2026-03-03 09:12 | Value loaded | 3.1 | lab_transfer (system, central lab) | Transfer 14 | |
| 2 | 2026-03-19 09:10 | Value updated | 3.1 | 2.4 | lab_transfer (system, central lab) | Transfer 15 |
| 3 | 2026-03-19 09:31 | Discrepancy raised | recon_check (system, CRO) | Differs from previous transfer | ||
| 4 | 2026-03-24 11:40 | Discrepancy closed | dm_03 (data manager, CRO) | Confirmed with lab |
Simplified from load histories we’ve reviewed. The trial, identifiers, and values are invented.
A reconciliation check did its job and flagged the change. What the repository can’t show is why the laboratory’s number moved, or what the data manager saw before closing row 4. The answer exists. The lab’s triglyceride result for that sample was too high for a calculated LDL-C, so the lab measured LDL-C directly and issued a revised value. A lab project manager explained this in an email to the contract research organisation (CRO). The data manager read the email, checked the lab’s report, and closed the discrepancy. The lab, the CRO, and data management each followed their own procedures. But the evidence that turns row 4 from an assertion into a fact sits in a laboratory information system, an inbox, and the data manager’s memory.
That matters most in a sponsor inspection, often long after the people who closed row 4 have moved on. A value that feeds the primary endpoint dropped by more than a fifth, and the only explanation on record is “Confirmed with lab.”
Evidence Versus Speed argued for capturing lineage at the moment data is written. Trials complicate that advice, because most of the writes behind one endpoint value happen in systems the sponsor doesn’t run. Chain of custody, borrowed from forensics, is a better frame here: evidence keeps its value only if every handover leaves a record of who passed what to whom, and in what condition.
Custody inside one system
Inside each system, custody is usually in good shape. 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions that create, modify, or delete electronic records, without obscuring what was there before, and retained for as long as the records themselves (FDA, n.d., §11.10(e)). It requires authority checks so only authorised individuals can alter a record (§11.10(g)), and signatures that show the signer’s printed name, the time, and the meaning of the signature (§11.50). The repository’s audit trail above captures what those sections ask for.
ICH E6(R3), adopted in January 2025, sets a higher bar for data of higher criticality, such as endpoints. It asks for systems that document changes including, where appropriate, the reason for the change, and for audit trails that are interpretable and can support review (ICH, 2025, §4.2.2). Its section on corrections says a correction should be attributed to the person or system making it, justified, and supported by source records from around the time of the original entry (§4.2.4). The EMA’s guideline on computerised systems in clinical trials is specific about what an audit trail should show: what changed, by whom (username, role, and organisation), when, and where applicable why (EMA, 2023, §6.2.1).
Organisation is the field that marks a handover, and it’s where most audit trails stop. Row 2 says the central lab changed the value. It can’t say why, because the reason lives in the lab’s own system. Row 4 records a reason, but “Confirmed with lab” points to a conversation, not a record. In the programmes we see, trial data lineage problems usually start this way, with an audit trail that is complete and accurate and still doesn’t lead to the evidence.
Custody between systems
A single endpoint value can pass through three or four organisations before it reaches an analysis dataset. This one began in the lab’s information system and travelled as a cumulative transfer file under a data transfer agreement. It was loaded into the sponsor’s repository by the CRO, reconciled, and would later move again into the datasets used for analysis. Lab results like this one are usually kept from site staff after randomisation in a lipid trial, since the drop would reveal treatment, so the chain runs between lab, CRO, and sponsor rather than through the site.
The guidance is direct about these hops. E6(R3) asks for validated processes or reconciliation to make sure data transferred between computerised systems, including relevant metadata, keeps its integrity, and for transfers and migrations to be documented to ensure traceability (ICH, 2025, §4.2.5). The EMA requires every transfer during a trial to be pre-specified and validated, and expects transferred data and their audit trails to remain continuously accessible (EMA, 2023, §6.1.2). In a sponsor inspection, the FDA says it will generally focus on, among other things, the processes that keep data from being altered in value or meaning, including during transfer to durable electronic repositories, along with change control and contracts with service providers (FDA, 2024, Q8).
E6(R3) does require interfaces between systems to be validated (ICH, 2025, §4.3.4(e)). But a validated interface shows the file arrived intact. It doesn’t show why its contents differ from the last one. The transfer for participant 1047 was validated, and the lab’s revision followed the lab’s own procedures, yet neither record pointed at the data point it changed. The chain recorded the files and none of the decisions behind them.
Custody after the trial
The last handover is the one teams plan least: from live systems to the archive, as trials finish, CRO contracts end, and vendor systems are decommissioned. The EMA expects inspectors to keep direct, read-only access to a decommissioned system’s data, and expects archived formats to allow the database to be restored with its metadata (audit trail, event logs, edit checks, queries, and user logs). Where that isn’t possible, data and metadata should be kept as dynamic files, and static copies of dynamic data aren’t considered adequate (EMA, 2023, §4.11, §6.12). FDA guidance makes the same point when a hosted-system contract ends: the sponsor should make sure the metadata is obtained, retained, and linkable to each data element (FDA, 2024). E6(R3) asks for data and metadata to stay retrievable and readable, and protected from unauthorised access and alteration, for the whole retention period (ICH, 2025, §4.2.7).
For participant 1047, this is where the chain could break for good. If the lab’s direct-measurement record and the email behind row 4 aren’t in the sponsor’s archive when the lab and CRO contracts close, row 4 can only be explained from memory. A programme that runs across several labs and CROs repeats that risk at every exit, which is why audit-ready clinical data at closeout depends on planning those exits at the start.
A receipt at every handover
None of this needs a new clinical data platform. Each handover needs to produce a record the trial keeps, and four changes do most of the work.
Each inbound transfer is logged as an event in its own right, with the file’s hash, the specification version, the sending system, and a link to the reconciliation that checked it. A change that starts outside the repository carries its source identifier, such as the lab’s accession number for the direct measurement. Correspondence that justifies a change is filed in the trial master file and linked to the data point. And data transfer agreements require those records to reach the sponsor’s archive with each transfer.
The core component is a lineage store keyed on the data point, fed by events from each system and queryable by anyone with the right access. The unambiguous timestamps E6(R3) asks for, with UTC as its example (ICH, 2025, §4.2.2(d)), make it possible to put events from different organisations in one order. That store is itself a computerised system in scope for validation and access control (ICH, 2025, §4.3.4), so it belongs in the validation plan from the start. Sakura’s Data & AI practice builds this layer for sponsors and CROs, usually starting from the transfers they already receive.
With those records in place, row 4 reads differently. The closure links to the lab’s revised result and the reason for it, the result links to the transfer that carried it, and the transfer links to the reconciliation that caught it. An inspector can follow the chain outward from the data point using records the sponsor already holds. The risk-based review E6(R3) asks for (ICH, 2025, §4.2.3) gets easier too: when central monitoring flags a run of revised lab values from one transfer, the reasons are already linked.
The cheapest place to add a receipt is a contract that hasn’t been signed yet. A data transfer agreement can name the events a lab or CRO must deliver, the identifiers they carry, and where they go when the contract ends, while retrofitting the same terms at closeout means renegotiating with a vendor who is already leaving. Sakura’s GRC service helps sponsor teams write those terms and set up the checks that confirm they’re met.
Not legal advice. This article offers general commentary on FDA 21 CFR Part 11 and ICH E6(R3) Good Clinical Practice for a pharma and healthcare engineering audience. It is not legal advice and is not a substitute for advice from qualified counsel or qualified regulatory affairs professionals. Specific obligations depend on the nature of your clinical programme, the jurisdictions in which you operate, your sponsor and CRO agreements, and the inspection regime to which you are subject. Readers must obtain independent legal and regulatory advice on how these regulations apply to their specific products and clinical operations.
References
European Medicines Agency (EMA), 2023. Guideline on computerised systems and electronic data in clinical trials. EMA/INS/GCP/112288/2023. European Medicines Agency. Available at: https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/guideline-computerised-systems-and-electronic-data-clinical-trials_en.pdf [Accessed 1 October 2026].
International Council for Harmonisation (ICH), 2025. ICH Harmonised Guideline: Guideline for Good Clinical Practice E6(R3). Adopted 6 January 2025. ICH. Available at: https://database.ich.org/sites/default/files/ICH_E6(R3)_Step4_FinalGuideline_2025_0106.pdf [Accessed 1 October 2026].
US Food and Drug Administration (FDA), n.d. 21 CFR Part 11: Electronic Records; Electronic Signatures. Electronic Code of Federal Regulations. Available at: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 [Accessed 1 October 2026].
US Food and Drug Administration (FDA), 2024. Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers. Guidance for Industry. Procedural, Revision 1, October 2024. FDA. Available at: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-systems-electronic-records-and-electronic-signatures-clinical-investigations-questions [Accessed 1 October 2026].