Federated TRE Reference Architecture for National Genomics
A federated Trusted Research Environment (TRE) reference architecture for a national genomics programme keeps every genome and health record inside the custodian that collected it, and moves compute, governance, and artificial intelligence (AI) to the data instead. The architecture has five layers: sovereign data nodes at each custodian, a harmonisation layer that maps local records to common standards, a federation layer that orchestrates queries and workloads across nodes, a governance layer that enforces the Five Safes and automated airlock output checking, and a Sovereign AI layer that trains and runs models across the network while data never leaves the source.
Why national programmes are redesigning their TRE architecture now
Two events reset the baseline for programme architects. The first was the May 2026 UK Biobank incident, in which approved researchers exported participant-level data through the ordinary workflow of a centralised research platform — no policy was breached, but the architecture permitted bulk egress by design. The second is the European Health Data Space (EHDS, Regulation (EU) 2025/327), whose Article 50 requires that secondary-use access to health data happens only inside secure processing environments that prevent data download. Together they make the architectural question explicit: a national genomics programme can no longer treat “copy everything into one platform” as an acceptable default, because both the risk record and the regulation now point the other way.
The scale of the programmes sharpens the point. Genomics England sequenced more than 100,000 genomes in its founding project and now operates one of the world’s largest national genomic research services; Singapore’s national precision medicine effort and Canada’s population cohorts are on similar trajectories. A whole genome is roughly 100 gigabytes of raw data — at population scale, physically centralising the data is expensive, slow, and creates a single point of catastrophic failure. Federation is not only the safer architecture; at genomic scale it is frequently the only practical one. For the underlying pattern, see what federation means in health data architecture.
The five-layer reference architecture
Layer 1 — Sovereign data nodes
Each data custodian — a sequencing centre, a hospital trust, a regional biobank, a partner country in a multi-national programme — runs a node inside its own security boundary and, where required, its own legal jurisdiction. The node holds the genomic files (FASTQ, CRAM, VCF) and linked phenotypic records in the custodian’s existing storage, under the custodian’s existing access controls. Nothing in the reference architecture requires the custodian to ship data to a central platform; the node exposes only a controlled compute interface. This is the property that makes the architecture compatible with data-sovereignty law: the data remains under the custodian’s jurisdiction because it never physically moves.
Layer 2 — Harmonisation
Federated analysis is only meaningful if a query means the same thing at every node. The harmonisation layer maps each custodian’s local schema to shared standards: the Observational Medical Outcomes Partnership (OMOP) Common Data Model v5.4 for clinical and phenotypic records, Global Alliance for Genomics and Health (GA4GH) standards such as CRAM, VCF, and Phenopackets for genomic data, and Fast Healthcare Interoperability Resources (FHIR) where operational systems feed the research environment. Mapping is the highest-effort part of any national deployment, which is why Lifebit invests in AI-assisted harmonisation tooling — but the target standards themselves are open and community-governed through the Observational Health Data Sciences and Informatics (OHDSI) collaborative and GA4GH. A grounding in data harmonisation practice is a prerequisite for evaluating this layer, because it is where most programme timelines are won or lost.
Layer 3 — Federation and orchestration
The federation layer is the programme’s control plane. It receives a researcher’s cohort query or analysis pipeline, decomposes it, dispatches it to the relevant nodes, executes it locally at each node, and returns only aggregate or approved results. Two patterns matter here: federated analytics, where each node computes statistics that are combined centrally, and federated learning, where model parameters — never records — travel between nodes during training. The orchestration layer must also handle the unglamorous realities of a national network: nodes with different compute capacity, nodes that are temporarily offline, and audit logging of every dispatched job.
Layer 4 — Governance and the automated airlock
Governance is where a TRE earns the word “trusted”. The reference model implements the Five Safes framework — safe people, safe projects, safe settings, safe data, safe outputs — originally articulated for the UK Office for National Statistics and now the de facto standard for research data governance. The architectural expression of “safe outputs” is the automated airlock: every artefact a researcher attempts to export is inspected against disclosure-control rules before release, with machine checks handling the routine cases and human review reserved for edge cases. This is the control the May 2026 incident showed to be missing from centralised platforms — an architecture in which bulk export is impossible by construction, not merely prohibited by policy. Each of the five safes maps to a named safeguard a programme board can audit, which is what makes the framework as useful to governance committees as to engineers.
Governance also has an institutional dimension the architecture must serve rather than replace: a data-access committee that approves projects, a researcher-accreditation process that satisfies “safe people”, and participant-facing transparency about how data is used. The reference architecture’s contribution is to make every committee decision technically enforceable — an approval in the governance layer provisions exactly the access granted, nothing more, and revocation takes effect immediately across every node.
Layer 5 — Sovereign AI
The top layer is what increasingly justifies the whole investment. Sovereign AI means the programme can train and deploy models — variant-effect predictors, polygenic risk tools, phenotype extraction models — on its own population’s data, inside its own jurisdiction, without exposing records to an external model provider. In the federated pattern, training jobs run at the nodes and only gradients or model weights aggregate centrally. For ministries and national programmes, Sovereign AI converts the genomics asset into a durable national capability rather than a dataset licensed outward, and it is the reason the architecture must be designed AI-ready from the start rather than retrofitted.
Centralised platform versus federated reference architecture
| Dimension | Centralised national platform | Federated TRE reference architecture |
|---|---|---|
| Data location | Copied into one central store | Remains at each custodian node; data never leaves the source |
| Jurisdiction and sovereignty | Determined by the platform’s hosting | Each node stays under its custodian’s jurisdiction |
| Bulk-egress risk | Possible through normal workflows (UK Biobank, May 2026) | Architecturally blocked; outputs pass an automated airlock |
| Onboarding a new data source | Full extract, transfer, and re-ingestion | Deploy a node and harmonise in place |
| Genomic data volumes | Petabyte-scale duplication and transfer costs | No duplication; compute moves to the data |
| AI model training | Requires pooling records centrally | Federated learning across nodes; only parameters move |
| EHDS Article 50 alignment | Depends on bolt-on controls | Secure processing environment by design |
The architecture in production: Genomics England and peers
This reference model is not theoretical. Genomics England, the UK government-owned company behind the 100,000 Genomes Project, works with Lifebit on federated research infrastructure that lets approved researchers analyse genomic and clinical data inside a controlled environment rather than distributing copies. The Canadian Partnership for Tomorrow’s Health (CanPath), Canada’s largest population health cohort, uses Lifebit’s federated Trusted Research Environment to open its data to researchers while the data remains under Canadian governance. In Singapore, national precision-medicine infrastructure applies the same principle across its health clusters. The common thread is that each programme retained custody and jurisdiction while widening researcher access — the two goals a centralised architecture forces you to trade against each other.
Common pitfalls in national deployments
Programme architects who have run this playbook report the same failure modes. First, treating harmonisation as a late phase: if OMOP and GA4GH mapping starts after the platform build, the federation layer ships with nothing consistent to query. Second, under-specifying the airlock: a manual output-review queue that works for fifty researchers collapses at five thousand, so disclosure control must be automated with human review as the exception path. Third, assuming node uniformity: partner hospitals and regional centres will have wildly different infrastructure, and the node software must run on modest on-premises hardware as well as public cloud. Fourth, governance debt: federating data across institutions without a pre-agreed access-committee model and data-access agreement template stalls the programme at the first real request. None of these is a technology problem alone — which is precisely why a reference architecture that binds the technical and governance layers together is worth adopting rather than reinventing.
What to do next
If you are designing or re-platforming a national genomics programme, start with a written architecture assessment against the five layers above: where does data physically sit, what maps it to OMOP and GA4GH standards, what orchestrates cross-node compute, what enforces the Five Safes and output control, and what makes the stack AI-ready. Score your current or proposed platform honestly against the comparison table — in particular, ask the vendor to demonstrate, not describe, how bulk export is prevented. A useful primer before that exercise is the foundational question of what a Trusted Research Environment actually is, since much of the market applies the label to platforms that meet none of the output-control tests.
Frequently asked questions
What is a federated TRE reference architecture?
It is a repeatable design for national-scale research infrastructure in which data stays at each custodian, and five layers — sovereign data nodes, harmonisation, federation and orchestration, governance with an automated airlock, and Sovereign AI — move compute and controls to the data instead of copying data to a central platform.
Why should genomic data not be centralised?
Genomes are large (roughly 100 GB raw per whole genome), legally sensitive, and impossible to anonymise fully. Centralising them creates transfer costs, a single point of failure, and a bulk-egress risk that the May 2026 UK Biobank incident demonstrated in practice. Federation removes all three by keeping data at source.
Which standards should a national genomics TRE adopt?
OMOP CDM v5.4 (OHDSI) for clinical and phenotypic data, GA4GH standards such as CRAM, VCF, and Phenopackets for genomic data, FHIR for operational interfaces, and the Five Safes framework for governance. All are open, community-governed standards.
How does the architecture satisfy EHDS Article 50?
EHDS Article 50 requires secondary-use access through secure processing environments that prevent data download. A federated TRE meets this by construction: researchers compute inside the environment, data never leaves the source, and every output passes automated disclosure control before release.
What is the difference between federated analytics and federated learning in this architecture?
Federated analytics runs statistical queries at each node and combines aggregate results; federated learning trains AI models by moving parameters between nodes while records stay put. A complete national architecture supports both within the same governance layer.
Can a federated architecture include existing centralised assets?
Yes. An existing central repository simply becomes one node among several. Programmes typically federate outward from a legacy core rather than migrating it, which preserves prior investment while extending sovereignty and access to new custodians.