Published 1st November 2026
By Pollyanna Jones – Emrys Health co-founder
This week we are publishing the code for Afon, our data fabric for joining up health data for research, under an open licence. This post explains the problem it is for, how it works, why we have built it as open infrastructure rather than as a product, and how to get involved.
Consider a woman in her fifties, call her Sarah, who has just been diagnosed with a cancer that has spread further than anyone expected. Sarah is a composite of the journeys described to us, again and again, by clinicians and data teams across the UK over the past year.
Her GP holds fifteen years of her health records: the symptoms she mentioned in 2019, her blood pressure, the repeat prescriptions, her pain. Her hospital holds the imaging, the pathology, the operation notes. A third system holds what the hospital pharmacy actually dispensed. A fourth holds the laboratory results. If she moved house in 2021, some of her data would sit in a different region under entirely different governance.
Somewhere, there is a researcher who wants to know whether patients like Sarah were showing a detectable signal in their primary care records eighteen months before diagnosis. High-quality data to answer it already exists.
But it takes far too long to pull this data together, if it happens at all. Not because anyone objects to the research, but because every organisation holding a piece of Sarah’s journey negotiates a separate data-sharing agreement and someone rebuilds the pipeline from scratch. The answer arrives long after treatment decisions are made, and the opportunity for early detection is missed.
Our proposed solution: a data fabric
In May 2026, we published, with Nesta, Newmarket Strategy, Joe Zhang and Jess Morely, a review of the digital technology underpinning the UK’s health data ecosystem, commissioned by Wellcome to inform the design of the government’s Health Data Research Service. We identified a critical missing layer across the national health data ecosystem. There is no standard, secure way to connect data across the UK’s health data environments.
The obvious question to ask is how we can connect UK health data environments. The question that we think matters more is whether the solution can also be built as public infrastructure: not a platform the NHS rents, but a pattern the NHS owns, openly licensed, buildable from published components, operable by any competent team, and shaped by the technical community who run it
A data fabric has never been deployed cross-regionally in the UK. HDRS has commissioned this because of its potential to join up, in the first instance, the regional NHS secure data environments (SDEs), and in full knowledge that the evidence base for it is thin.
What is the Afon data fabric?
Afon is Emrys Health’s vendor-agnostic data fabric: it runs on any cloud and alongside any supplier’s tools, so no organisation has to change what it already uses in order to take part. It is the connective layer flowing between multiple organisations. The fabric can run federated research questions and aggregate answers across organisational boundaries, without centralising patient data. We have called the data fabric Afon, Welsh for river. The code is published this week under the Apache 2.0 licence here
Over the summer of 2026, HDRS commissioned Emrys to test the Afon data fabric using synthetic data and deployed open catalogs across half the English SDEs. We are now working with Health Data for London and the North West SDE to make the Afon code production-grade and to deploy it on pseudonymised patient data, with the accreditation that requires.
Most federation today works by sending a query to each environment separately and combining the summary results. That is the right approach for many questions. For others, it loses statistical power and cannot support patient-level linkage. Afon is built to allow approved analysis to run across the source data in the environments where it sits, inside a controlled research space, rather than only on summaries. Both approaches have a place; we are testing where each is the better choice.
In plain terms: each organisation keeps a catalogue of its own data in its own cloud. Sarah’s GP record stays where it is held; her pathology stays with the hospital. Afon lets an approved piece of work read across those catalogues for as long as it runs, with every access logged and nothing copied out. Where a genuine linkage is unavoidable, it happens in a space created for that purpose and is closed afterwards.
In technical terms: each participating organisation deploys an Apache Polaris catalog inside its own cloud account – not ours and not anyone else’s – sitting over Apache Iceberg tables holding its own data. The catalog is reachable over HTTPS and issues credentials that are short-lived and scoped tightly to exactly what a given piece of approved work requires. We validate researcher identity through a shared identity provider and a zero-trust network that continually verifies who is doing what, across clouds. Queries run from a research environment that cannot write data back out and logs continuously.
What Afon is not
It is not a catalogue for people to browse and discover data. At its core it is a reference architecture that lets machines share data with minimal movement. The controlled research environment we run on top is one way to use it, not the only one.
It does not require harmonisation before joining. Assets connect when their storage format meets the specification, not when schemas match. OMOP conversion remains the right investment for a great deal of research; it just isn’t a precondition.
The technology is not locked-in; it is built on open table formats and vendor-neutral catalogs, is cloud-agnostic and organisations can use it without a migration project.
Why a pattern and not a platform
Suppose you could move every NHS organisation onto a single platform. You can’t, but suppose it. You would still have solved almost nothing, because the research that matters does not happen inside the NHS alone. It involves pharmaceutical companies, biotechs, universities, charities and small firms, and none of them is going to adopt someone else’s stack. Nor should they.
So the answer cannot be a product everyone runs. It has to be a data pattern everyone can join: agreed storage formats, catalogue behaviour, and rules for how credentials are scoped, and activity is logged. Everyone keeps their stack and conforms only at the boundary. Put simply: this could connect the health data of patients like Sarah across multiple organisations, giving a complete research view across the whole patient journey.
Take a real-world example: a consented research cohort like Our Future Health holds data its participants agreed to make available for research. A company holds trial data that is consented, commercially sensitive and protected as intellectual property. A legitimate question needs both, but neither side would – or should need to – adopt the other’s platform.
Which puts the whole problem at the join: the rules about how you see data to link it. The endpoints are well understood. The join is not, and it has to hold several things at once:
1. Minimise the data to what the question actually requires, in line with the law.
2. Keep the data non-identifiable in the context it is used in, taking into account how additional data may impact the risk of disclosure and standard approaches for egressing safe data.
3. Produce evidence rather than assertion. How do audit records from several organisations reconcile into something each data controller can rely on? How does anyone know that a linkage is correct, and who is accountable when it isn’t?
Those are the questions we are testing. They are also why the join has to be open. Every organisation whose data meets at the join needs to be able to see for itself how data is minimised, how identifiability is checked and how audit records are produced. A single supplier can offer that to its own customers. It cannot offer it to the universities, companies and charities who will join at the boundary without ever buying the platform, and the research that matters needs them. A join that only its customers can inspect is a new dependency sitting in the middle of everything, which is the problem we started with.
What open actually means
Open source and open data are different things. Afon’s code is open. The data is not. It stays in the organisation that holds it, under that organisation’s control, reachable only by people that organisation has approved.
Openly licensed under Apache 2.0 means no licence fee, no per-seat cost, no per-query cost, and no permission to seek. An NHS organisation can run it, read it, modify it, build further tools on it, and keep the modifications. Support is a separate arrangement from the licence, contracted in a market where more than one supplier can compete rather than rented from one supplier.
What remains chargeable is work, not access: cloud compute, engineering time, assurance, integration and support. Emrys earns from doing some of that work: maintaining the core, and helping organisations deploy, integrate and assure it. So can anyone else and, if Afon is any good, other people should be able to deploy and support it, and we should have to compete on being good at it.
National public infrastructure that only one small company can operate is not national infrastructure. One test: if any operator’s trains can run on the track, it is public infrastructure. If only one can, it is a product.
The key tests for production-grade Afon
- Easy to join. An SDE should be able to deploy Afon from the published components without an Emrys engineer present, as one did this summer, and researchers should be able to work across environments without learning a new system.
- Secure. We have tested the design against the Five Safes framework, including how access is logged, stored and reviewed.
- Affordable. Whether cost and query performance hold up across clouds at realistic data volumes, and whether information governance for cross-boundary queries can be standardised rather than bespoke. Early indications are that running costs are materially lower than managed alternatives, but that is precisely what the next phase has to test.
We will publish what we find, including what fails.
Our ambition for where this goes
Afon is open source under Apache 2.0, and the work will continue with HDRS, participating secure data environments, and the digital public infrastructure programme we are delivering with Nesta.
Infrastructure of this kind is not a product one company hands over. It is a community maintaining something in common, and it only works if the people who run the data environments have a say in how the thing connecting them behaves. That community already exists: it built the environments, the linkage methods and the governance models that make this attempt possible. A good outcome looks like more of their work becoming reusable across a growing number of environments.
We do all of this so that we can join up the health data of patients like Sarah who are ill and need help now. Was the signal detectable eighteen months earlier? Can the next woman with those symptoms be identified and given early interventional treatment? We think that Afon could make this possible.
Connecting Sarah’s data would not treat her. This is research, not direct care. That is a slower kind of hope than promising to fix her, and the only honest one.
The documentation can be found here, SDEs and other organisations wanting to deploy Afon, contribute to it, or join the fortnightly community call can reach us at afon@emrys.health.