Topic 4.10 — Secure Data Environments & Research Data Access

In health and care, the safe re-use of patient data for research and planning depends on a single hard-won principle — bring the analyst to the data, never the data to the analyst — enforced through secure environments, layered governance and visible public accountability.

Why this matters in health and care#

Health and care systems hold some of the richest longitudinal data about human lives ever assembled: births, diagnoses, prescriptions, operations, deaths, and the social circumstances around them. Re-used well, that data finds safer medicines, spots failing services, targets scarce resources, and powers the discovery of treatments that save lives. Re-used badly, it breaches the confidence of millions of people who never chose to be data subjects, corrodes the trust the whole system runs on, and — because trust once lost is slow to rebuild — sets back the very research it was meant to enable.

The tension is structural, not incidental. The public consistently supports the use of their data for research in the public interest, and just as consistently objects to data leaving safe custody, being sold without accountability, or flowing to commercial hands on terms they cannot see. A digital leader sits exactly on that fault line. You are asked to unlock value from data (a duty to patients not yet born, and to the public purse) while holding an equally serious duty of confidentiality to the people the data describes.

Secure Data Environments (SDEs), also called Trusted Research Environments, are the operational answer the UK has converged on. They change the default from copying data out to researchers, towards researchers coming in to work on data that never moves. This is not a technical nicety; it is the mechanism by which the system keeps a public promise. Getting it right is a clinical-safety-adjacent, equity, and public-trust responsibility (see Topic 1.8 — Data Ethics, Consent & Public Trust), and it is increasingly a statutory expectation, not a matter of local discretion.

Core concepts#

A Secure Data Environment (SDE) — the term now preferred in NHS policy — is a data storage and analysis platform in which approved researchers access approved data for approved purposes, without the data being extracted or copied out. The older and internationally common name is the Trusted Research Environment (TRE); the two describe the same model. The governing idea is bring the analyst to the data, not the data to the analyst: computation happens inside the walls, and only checked, aggregated results leave.

The framework that structures this is the Five safes, developed at the UK Office for National Statistics. It decomposes safe data access into five dimensions: safe people (are the researchers trained, accredited and accountable?), safe projects (is this use lawful, ethical and in the public interest?), safe settings (does the environment prevent leakage?), safe data (has the data been minimized and de-identified to the extent the project allows?), and safe outputs (are the results checked before release so no individual can be identified?). No single control is sufficient; safety is the product of all five.

Two disciplines protect the data itself. Data minimization means providing only the fields and records a project genuinely needs, never the whole record "just in case". De-identification is the umbrella term for reducing the identifiability of data. Within it, pseudonymization replaces direct identifiers (name, NHS number) with a key-linked token, so re-identification is possible only by holding the separate key — the data remains personal data in law. Anonymization aims to render data no longer personal at all, which is far harder than it sounds, because re-identification — matching supposedly anonymous data against other datasets to reveal who someone is — becomes easier as more data exists in the world. Genuine anonymization of rich clinical data is often impossible; this is precisely why the SDE model exists.

Before results leave the environment, they pass output checking, the human and procedural gate that applies statistical disclosure control — techniques that stop small cell counts, unique outliers or differencing attacks from exposing individuals. The gate is often called an airlock: results go into a holding area, a trained checker reviews them, and only cleared outputs pass to the researcher. Emerging privacy techniques such as differential privacy, which adds calibrated statistical noise to bound what any single record contributes to a result, complement rather than replace this human control.

Two further concepts shape the future. Federated learning and federated analytics let a query or model run across several SDEs, each holding its own data, so that insights are combined without any raw data being pooled — the natural next step for a distributed national network. And social licence — the informal, ongoing public permission a data programme operates under — is the intangible asset that all the machinery above exists to protect. The cautionary tale is care.data, the 2013–2016 NHS England programme to extract GP data, abandoned after it failed to explain itself to the public and lost their confidence.

Best practices#

1. Make the environment, not the export, the default. The single most important design decision is that data does not leave. Provision researchers with compute, tools and curated datasets inside the SDE, and remove the routes by which data used to trickle out — bulk downloads, emailed extracts, copied spreadsheets. Every legacy data-sharing agreement that ends in a copy leaving the building is a liability you should be actively retiring in favour of in-situ access.

2. Operationalize all Five Safes, not just the technology. It is tempting to buy a secure platform and declare the problem solved, but a hardened setting with weak project vetting or no output checking is a breach waiting to happen. Build explicit, evidenced processes for each safe: researcher accreditation and training, an independent view on whether a project is lawful and in the public interest, minimized and de-identified data provisioning, and disciplined output checking. Treat the five as a system where the weakest link sets your real level of safety.

3. Minimize and de-identify to the lowest identifiability the project can tolerate. Do not hand over the whole record when a cohort and a dozen fields would answer the question. Pseudonymize direct identifiers by default, strip or coarsen quasi-identifiers such as full postcode and exact date of birth, and reserve access to more identifiable data for the rare projects that genuinely require it, under stricter approval. Remember that pseudonymized data is still personal data in law (see Topic 1.7 — Information Governance, Data Protection & Cyber Security), so the SDE's controls, not a claim of anonymity, are what keep you lawful.

4. Put a real airlock and trained output checkers between results and release. The moment of highest risk is when something leaves the environment. Route every output through a holding area where a trained checker applies statistical disclosure control — suppressing small cells, rounding, and watching for differencing across a researcher's successive requests — before anything reaches the outside. Resource this properly: output checking is skilled work, and a backlog that tempts people to "just email it" defeats the entire model.

5. Make information governance approval rigorous, independent and fast enough to use. Access should turn on an independent judgement that the project is lawful and in the public interest, typically through a data access committee and, where confidential patient information is used without consent, the Confidentiality Advisory Group (CAG) advising on section 251 support under the relevant regulations. Rigour and speed are not opposites: a transparent, well-staffed committee with clear criteria approves good projects faster and rejects bad ones more defensibly than an opaque, slow one. A process so slow that researchers route around it is a governance failure, not a governance success.

6. Earn and keep social licence through radical transparency. The lesson of care.data is that lawful is not the same as trusted. Publish a data uses register showing who accessed what data, for what purpose, and with what result; run genuine public and patient involvement in how the SDE is governed; and offer a clear, respected national data opt-out. Transparency is not a communications afterthought bolted on at launch — it is the operating condition that lets the whole enterprise continue (see Topic 1.8 — Data Ethics, Consent & Public Trust).

7. Design for federation across the SDE network, not one walled garden. England's model is a national SDE alongside accredited sub-national SDEs, and research increasingly needs to combine data that legitimately cannot be pooled. Adopt common standards, curated data models and interoperable tooling so a project can, in time, run federated queries or train models across environments while raw data stays put in each (see Topic 4.3 — Interoperability & Data Standards). Building a bespoke, isolated environment that cannot interoperate is a strategic dead end, however good it looks locally.

8. Govern commercial access explicitly, with value flowing back. Industry access to NHS data is legitimate and often essential for developing treatments and technologies, but it is where public suspicion concentrates. Set clear rules: the same SDE controls apply to commercial users as to academics, agreements are transparent and published, and the public gets fair value in return — whether in price, access to the resulting innovation, or reinvestment in the data infrastructure. Never let "commercial partnership" become a euphemism for data leaving safe custody on quiet terms (see Topic 6.3 — Procurement & Commercial).

Questions to discuss with your team#

1. When we say our data is "de-identified", what re-identification risk are we actually accepting — and who signed off on that judgement? This matters because "anonymized" is used loosely to mean everything from truly non-personal data to lightly pseudonymized records that a determined analyst could re-identify by linking to other sources. Debate the specifics: which quasi-identifiers remain (postcode granularity, dates, rare diagnoses), what external datasets an attacker could realistically link against, and whether your controls are the SDE itself or an optimistic label. Consider that rich longitudinal clinical data is often not truly anonymizable, which means the environment's controls — not the data transformation — are what make you lawful and safe. Surface who owns this risk assessment: a named accountable person applying a documented methodology, or an unexamined assumption inherited from an old data-sharing agreement. A good, honest answer states the residual re-identification risk in plain terms, ties it to specific controls, and names the person accountable for the judgement rather than hiding behind the word "anonymous".

2. How would we explain a specific data access to a sceptical patient on the front page of a newspaper — and would the explanation survive? The care.data collapse was not primarily a technical failure; it was a failure to explain and to command trust. Take a real or realistic access — a pharmaceutical company running a study in your SDE — and role-play the public conversation: what data, why, who benefits, what the company gets, what the public gets back, and how someone can opt out. Debate where your current transparency is thin: is there a public data uses register, is commercial access visible, do patients know the opt-out exists and that it was honoured? Consider the difference between defensible-because-lawful and defensible-because-trusted, and be honest that the second is harder and more fragile. A strong answer produces a clear, jargon-free account a patient would find reasonable, and identifies the specific transparency gaps you would need to close before you could give it with a straight face.

3. Is our governance fast and independent enough that good researchers use it rather than route around it? There is a real tension between rigour and access: govern too loosely and you betray public trust; govern too slowly and researchers either give up (public value lost) or find informal workarounds (control lost entirely). Discuss your actual timelines from application to data access, where the bottlenecks are (information governance, CAG, data engineering, output checking), and whether your data access committee has clear published criteria or decides case-by-case in ways applicants cannot predict. Probe independence honestly: does someone with the authority to say no actually say it, or does commercial or institutional pressure make approval a formality? Consider the failure mode where a slow process pushes work into un-governed corners, which is worse than a fast transparent one. A good answer names real cycle times, distinguishes rigour from mere delay, and commits to specific improvements that speed access without weakening the independent judgement at the centre.

4. When a commercial partner works in our SDE, what fair value flows back to the public — and can we show it? Industry access is legitimate and often the only route to turning data into treatments, but it is exactly where public suspicion concentrates, because the fear is that a public asset is being handed to private hands on quiet terms. Debate what "fair value" concretely means for your organization: a preferential price on the resulting product, guaranteed access to the innovation for your population, reinvestment in the data infrastructure, or simply cash — and who decides which. Probe whether the same SDE controls genuinely apply to commercial users as to academics, or whether a well-resourced company quietly gets a smoother path. Ask whether the agreement and its value-sharing terms are published, or negotiated case-by-case behind closed doors where no one can check them. An honest answer names the value your last commercial arrangement returned, states where that value went, and admits where "commercial partnership" is at risk of becoming a euphemism for privileged access without accountability.

5. Does the data in our environment — and the research it enables — represent the whole population, or only the parts of it that are easiest to capture? Equity is a duty, not an afterthought: if the data under-represents certain groups (people who use services less, are recorded less completely, or opt out at higher rates), then research built on it will work less well for exactly those groups, quietly widening health inequalities under a veneer of evidence. Discuss which populations are thin or missing in your data, how coding and recording practices skew what is captured, and whether high opt-out rates in particular communities are eroding representativeness in ways no one is tracking. Consider the tension that improving inclusion can pull against data minimization and against the trust of groups with good historical reasons for wariness. Think about who reviews project outputs for differential impact, and whether "public benefit" in your access decisions ever explicitly asks benefit for whom. A strong answer identifies concrete representation gaps, names the equity risk in current or planned research, and commits to monitoring benefit and inclusion rather than assuming a large dataset is a fair one.

6. Are we certain the SDE is the only route data leaves — or do legacy exports quietly persist alongside it? A secure environment only delivers its promise if it becomes the single door; every surviving bilateral agreement, emailed extract or copied spreadsheet is a route that bypasses every control you have built, and these arrangements are notorious for outliving the memory of who signed them. Discuss whether anyone holds a live inventory of existing data-sharing agreements, where copies of data currently sit outside your walls, and who owns the deliberate work of retiring them. Probe the uncomfortable incentives: exports are fast and familiar, and both researchers and internal teams may prefer the old path while paying lip service to the new one. Consider that a gleaming SDE launched on top of an un-retired export estate is a false sense of security, not a solved problem. An honest answer states how many legacy exports still exist, names the plan and owner for closing them, and is candid about which ones are proving hardest to switch off and why.

In practice: a health & care example#

The Fenwater Integrated Care System spans three acute trusts, community and mental-health services, and around ninety GP practices. Its analysts have long relied on bespoke data extracts — pseudonymized files copied to a research partner's servers under bilateral agreements — and the information governance team has quietly worried for years about where those copies now sit. When NHS England's SDE policy makes in-situ access the expectation, Fenwater's board decides to stand up the Fenwater Secure Data Environment as an accredited sub-national SDE rather than keep signing export agreements.

The programme starts not with technology but with the Five Safes. Fenwater defines researcher accreditation and mandatory training (safe people); establishes a data access committee, with lay members and an independent chair, that assesses every project for lawfulness and public benefit and refers confidential-data cases for section 251 advice (safe projects and settings); builds a curated, minimized data model where direct identifiers are pseudonymized and postcodes coarsened to the first part only (safe data); and hires and trains two output checkers to run the airlock (safe outputs). Crucially, it publishes a public data uses register from day one and convenes a standing patient panel to scrutinize governance.

The first real test is a request from a diagnostics company to study early markers of a cancer across five years of pathology and imaging data. Under the old model this would have been another export. Now the company's analysts are accredited, their project is assessed for public benefit and approved with conditions, and they work entirely inside the SDE — no raw data leaves. Their statistical outputs pass through the airlock, where a checker suppresses several small cell counts that would have singled out patients with a rare subtype. The commercial agreement is published on the register, including a commitment that any resulting test is offered to the ICS on preferential terms.

Eighteen months on, Fenwater retires the last of its legacy export agreements. A subsequent request needs data Fenwater holds combined with a neighbouring ICS's records; rather than copying either dataset, the two accredited SDEs pilot a federated query so the analysis runs in both environments and only aggregate results are combined. When a local journalist asks who has been using patients' data, the ICS points to its public register. The work was slower to build than emailing a spreadsheet — but it turned an anxious, invisible export habit into a defensible, transparent public asset.

Sector lenses#

Startup#

A health-tech startup rarely builds its own SDE; it is a user of someone else's, and its ways of working must assume the environment, not the export. Design your analytics and model-training pipelines to run inside a TRE against data you cannot download, because that is increasingly the only lawful route to NHS data at scale — and a hospital or ICS will assess your governance maturity before letting you in. Budget realistically for accreditation, for the slower cadence of in-situ work, and for output checking that will hold back results you expected to take away. Your competitive advantage is not privileged access to raw data (that era is ending) but the ability to generate credible, publishable insight within the constraints, and to be transparent about what you did with the access you were granted.

Small business#

An established small provider or supplier — a GP practice, a community pharmacy, a care home, a single-site clinic, or a small analytics vendor past the startup stage — is far more often a data controller with duties than a would-be researcher, and it will never run its own SDE. Its practical task is to resist the old habit of copying pseudonymized extracts to a partner's laptop or a spreadsheet, and instead insist that any secondary use of its patients' data happens inside an accredited environment it can point to and account for. With no dedicated information-governance staff, lean on shared and regional SDEs, your data protection officer or ICB, and template data-sharing terms rather than negotiating bespoke arrangements you cannot properly scrutinize. Know that the national data opt-out and the duty of confidentiality apply to you in full, regardless of size, so the safest posture is to route requests for your data toward a governed SDE and decline informal exports, even when a trusted local researcher asks nicely.

Enterprise#

A large NHS trust, ICS or pharmaceutical firm operates SDEs at scale and across many concurrent projects, so its challenge is throughput without loss of control. The realistic goal is an accredited environment with industrialized processes — standing data access committees, a curated and minimized data model, resourced output checking, and a published uses register — not a bespoke platform per project. Embed the SDE into procurement and partnership terms so commercial access flows through it by default and value-sharing is contractual rather than negotiated ad hoc (see Topic 6.4 — Governance & Assurance). At this scale the biggest risks are a slow governance pipeline that pushes researchers toward workarounds, and legacy export agreements that quietly persist alongside the shiny new environment; retire them deliberately.

Government#

A national body — NHS England, the devolved health administrations, UK Statistics Authority — sets the rules everyone else works within, and its leverage is standards, accreditation and public trust. It defines the SDE policy, accredits sub-national environments, runs a national SDE, and — following the Goldacre Review's "Better, broader, safer" recommendations — pushes toward a smaller number of well-governed, interoperable environments rather than hundreds of uncontrolled data flows. Its hardest and most important duty is stewarding social licence nationally: honouring the national data opt-out, insisting on transparency about commercial access, and ensuring the public sees fair value returned for the use of a public asset (see Topic 9.2 — Global & International Digital Health). Government also holds the equity duty — that research using this data benefits the whole population, not only the groups best represented in it.

Common failure modes#

• The export that never really stopped. A gleaming new SDE launches while old data-sharing agreements quietly keep copying data out the back. Inventory and retire legacy exports deliberately; the environment only helps if it becomes the only route.
• "Anonymized" as a comfort word. Calling rich clinical data anonymous does not make it so; re-identification risk is often real and rising. Assess and document the actual residual risk and rely on the environment's controls, not the label.
• Technology without governance. A secure platform with weak project vetting or no output checking is a breach waiting to happen. All Five Safes must be operational, not just the setting.
• The airlock that leaks. Under-resourced output checking creates backlogs, and backlogs create pressure to bypass the airlock. Staff it as skilled, valued work with achievable turnaround.
• Governance so slow it is routed around. An opaque, months-long approval process pushes good researchers into informal workarounds — the worst of both worlds. Make approval independent and usably fast.
• Silent commercial deals. Industry access arranged on unpublished terms is the fastest way to lose public trust, however lawful. Apply the same controls to commercial users and publish the arrangements.
• Transparency as launch-day theatre. A one-off public campaign is not social licence; a maintained data uses register and genuine public involvement are. Care.data is the standing reminder that trust is an operating condition, not a launch event.

Maturity model#

Checklist#

• In-situ access through the SDE is the default; legacy data exports are inventoried and being retired.
• All Five Safes are operationalized with evidenced processes, not just a secure platform.
• Data is minimized and de-identified to the lowest identifiability each project can tolerate, with pseudonymization by default.
• Re-identification risk is assessed and documented by a named accountable owner, not assumed from an "anonymized" label.
• Every output passes through an airlock where trained checkers apply statistical disclosure control before release.
• An independent data access committee approves projects against published criteria, with a CAG / section 251 route for confidential data.
• Governance timelines are measured, published, and fast enough that researchers use the process rather than route around it.
• A public data uses register shows who accessed what data, for what purpose, and with what result.
• The national data opt-out is honoured and its existence is clearly communicated to patients.
• Commercial access runs through the same SDE controls, is published, and returns fair value to the public.
• The environment adopts common standards so it can interoperate and, in time, support federated analytics across SDEs.

Key sources#

• NHS England — Secure Data Environment (SDE) policy guidelines and the national and sub-national SDE network.
• Ben Goldacre et al. — Better, broader, safer: using health data for research and analysis (the Goldacre Review), Department of Health and Social Care, 2022.
• Office for National Statistics — the Five Safes framework for safe data access.
• UK Health Data Research Alliance / Health Data Research UK (HDR UK) — principles and standards for Trusted Research Environments.
• Health Research Authority — Confidentiality Advisory Group (CAG) and section 251 support for the use of confidential patient information without consent.
• UK Statistics Authority — accreditation and the safe use of data for research and statistics.
• Information Commissioner's Office — guidance on anonymisation, pseudonymisation and data minimisation under UK GDPR.

References#

1. Five safes — Wikipedia — https://en.wikipedia.org/wiki/Five_safes
2. Data minimization — Wikipedia — https://en.wikipedia.org/wiki/Data_minimization
3. De-identification — Wikipedia — https://en.wikipedia.org/wiki/De-identification
4. Pseudonymization — Wikipedia — https://en.wikipedia.org/wiki/Pseudonymization
5. Data anonymization — Wikipedia — https://en.wikipedia.org/wiki/Data_anonymization
6. Data re-identification — Wikipedia — https://en.wikipedia.org/wiki/Data_re-identification
7. Statistical disclosure control — Wikipedia — https://en.wikipedia.org/wiki/Statistical_disclosure_control
8. Differential privacy — Wikipedia — https://en.wikipedia.org/wiki/Differential_privacy
9. Federated learning — Wikipedia — https://en.wikipedia.org/wiki/Federated_learning
10. care.data — Wikipedia — https://en.wikipedia.org/wiki/Care.data
11. Better, broader, safer: using health data for research and analysis (the Goldacre Review) — Department of Health and Social Care / Ben Goldacre — https://www.gov.uk/government/publications/better-broader-safer-using-health-data-for-research-and-analysis
12. Secure data environment for NHS health and social care data — policy guidelines — NHS England — https://www.gov.uk/government/publications/secure-data-environment-policy-guidelines
13. The Five Safes framework — Office for National Statistics — https://www.ons.gov.uk/aboutus/whatwedo/statistics/requestingstatistics/approvedresearcherscheme
14. UK Health Data Research Alliance — Trusted Research Environments — Health Data Research UK — https://www.hdruk.ac.uk/
15. Confidentiality Advisory Group and section 251 support — Health Research Authority — https://www.hra.nhs.uk/approvals-amendments/what-approvals-do-i-need/confidentiality-advisory-group/
16. Anonymisation, pseudonymisation and privacy-enhancing technologies guidance — Information Commissioner's Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/anonymisation/