One governed clinical trial data platform, from site data to submission datasets

The situation

A biotech with several programmes in clinical development worked, like most of its peers, through vendors: one for electronic data capture, others for central labs, patient-reported outcomes, wearable devices and imaging. Each study's data team built its own transfers, mappings and checks. Submission datasets were produced by statistical programmers working from extracts, and the reasoning behind many transformations existed only in their code and memory.

As the pipeline grew, leadership saw the risk: every new study cost the same effort as the last, and an inspection question about where a value came from could take days to answer.

What had to be true

• Traceability from every submission value back to its source record and every transformation in between.
• Reuse across studies: shared ingestion, mapping patterns and checks, not bespoke pipelines per protocol.
• Quality visible early, to data managers during the study, not at database lock.
• Audit trails and access control by design, suitable for computerised system validation.
• Vendor independence: changing an EDC or lab vendor should not mean rebuilding the platform.

The regulatory direction supported this. ICH finalised the revised Good Clinical Practice guideline, E6(R3), in January 2025, and commentary highlights its risk-proportionate approach and a new data governance section that acknowledges digital trial data handling¹. In the EU, the principles and Annex 1 applied from 23 July 2025².

Architecture

The data flow, end to end

Submission requirements anchored the design. The FDA lists the study data standards it supports and requires, including SDTM versions, with dates from which each version is supported and then required³. Building SDTM mappings as versioned, reviewable assets meant a standards update became a controlled change rather than a scramble.

The hard part: one mapping layer for many protocols

Every protocol is different, and the temptation is to treat every study as a special case. The platform separated what genuinely varies by study, such as visit schedules, endpoints and specific forms, from what doesn't, such as demographics, adverse events, concomitant medications and lab structures.

• A shared library of mappings and derivations for common domains, with study-level extensions rather than copies.
• Controlled terminology managed centrally, so the same concept is coded the same way across studies.
• Mapping specifications stored with the code, reviewed like code and versioned with each data cut.
• Blinded and unblinded data separated by access control and environment, not convention.

How it ran

Key decisions and trade-offs

For systems that create or modify records required by FDA regulations, 21 CFR Part 11 sets expectations for electronic records, including secure, computer-generated, time-stamped audit trails⁴. Designing those in from the first phase was far cheaper than retrofitting them.

What I'd do again, and differently

Again: one study end to end before building the shared library, and quality at the table from the first week. Differently: negotiate transfer agreements with vendors as part of platform work, not study start-up. Consistent vendor formats are what make shared mappings possible. Related approaches are in data contracts and FHIR to OMOP architecture.

If your clinical data is growing faster than your ability to trace it, the healthcare data architecture page describes how I work, or analyse your challenge and bring the result to a call.