EHDS Secondary Use: Preparing Health Data for the Access Bodies Without Breaching GDPR

The European Health Data Space frames secondary use as a request-and-response system: a researcher applies, an access body grants a permit, a dataset appears. For the organisation holding the data, none of that is the hard part. The hard part is being able to produce a structured, described, lineage-traceable dataset at all — and that is a data-engineering programme, not a legal one.

Most of the commentary on EHDS secondary use is written from the applicant’s side: how to get a data permit, what you can do inside the secure processing environment, what the fees might be. Far less is written for the side of the transaction that carries the operational weight — the health-data holder that has to make the data available in the first place. Under Regulation (EU) 2025/327, hospitals, registries, laboratories, insurers, biobanks and a long list of others become data holders with a standing obligation to supply. If your organisation sits anywhere in that list, the work you need to have started is not legal review. It is getting your data into a shape someone else can safely anonymise and query.

The obligation is to supply, and the clock is already running

The EHDS Regulation entered into force in 2025 and applies generally from 26 March 2027. The secondary-use chapter — Chapter IV — applies from 26 March 2029, with a further two years, to 26 March 2031, for the more complex categories such as genetic and genomic data, clinical-trial data, and research cohorts. Two thousand and twenty-nine sounds distant. It is not, for anyone who has ever tried to extract clean, coded, longitudinal data out of a clinical system that was designed to support one patient encounter at a time.

Article 51 sets out the minimum categories of electronic health data a holder can be required to make available — among them data from electronic health records, registry and mortality data, genomic and other molecular data, data from medical devices and wellness applications, reimbursement and administrative claims, and biobank data. It is a broad list, and the point to absorb is that being a data holder is not opt-in. If you hold data in an in-scope category, the duty to make it available on a valid data permit attaches to you by operation of the Regulation. The design question is not whether to comply but whether your estate can produce a compliant dataset without a heroic manual effort every single time a permit lands.

Who actually anonymises, and why that changes your build

This is the detail that most internal discussions get wrong, and getting it wrong sends the whole programme in the wrong direction. Under EHDS the anonymisation or pseudonymisation of data for secondary use is the health data access body’s responsibility, not the holder’s. The access body provides data to applicants in anonymised form by default, and only in pseudonymised form where the applicant can show the purpose cannot be met with anonymised data. Access happens inside a secure processing environment; raw records are not downloaded. I have written separately about the data permit, the access body and the environment you query through, and it is worth reading that mechanism in full before scoping your own side.

So if the access body does the anonymising, what is left for the holder? Everything that determines whether that anonymisation is safe and whether the resulting dataset is usable. The access body can only anonymise well what it receives in a well-structured, well-documented form. If you hand over free-text fields stuffed with identifiers, inconsistent coding, and no record of provenance, either the access body cannot reduce re-identification risk to an acceptable level — and refuses or degrades the dataset — or it does so and the residual risk becomes a shared problem. Your engineering job is to deliver data that is structured, coded to recognised terminologies, minimised to what the category requires, and accompanied by enough metadata that the anonymisation is defensible. That is not a data request. It is a pipeline.

Where the GDPR weight actually sits

The instinct is to treat EHDS and the GDPR as two problems. They are one problem. Anonymised data falls outside the GDPR; pseudonymised data remains personal data and stays fully within it. The moment your pipeline transmits identifiable or pseudonymised records to an access body, you are carrying out a processing operation that needs a lawful basis, a documented data-flow, and genuine data minimisation — you may only transfer what the category and the permit actually require, not a convenient superset. EHDS provides the framework for that disclosure, but it does not absolve you of the GDPR analysis; it presupposes you have done it.

Two engineering consequences follow. First, minimisation has to be built into the extract, not bolted on afterwards: the pipeline should be capable of producing category-scoped, permit-scoped subsets rather than dumping a whole table. Second, patient preference has to be honoured at the point of extraction. EHDS gives patients an opt-out from secondary use, and that flag has to be resolved inside your pipeline before data leaves your control — which is a data-model and lineage problem, not a form on a website. I have set out how building patient preference into every secondary-use query works in practice; the short version is that an opt-out you cannot reliably apply at extract time is an opt-out you have not implemented.

The four artefacts you will have to produce on demand

Strip away the legal framing and a data holder’s secondary-use obligation resolves into four concrete deliverables, each with an engineering cost:

• The dataset itself, structured and standardised. Coded to recognised terminologies, in a common format, extractable repeatedly without manual reconstruction. This is the same standardisation discipline that the European electronic health record exchange format demands for primary use — if you are building it once, build it to serve both.
• A dataset description. The Regulation requires holders to describe their datasets — source, scope, main characteristics, nature — and to keep those descriptions current. A machine-readable metadata catalogue, not a document someone updates once and forgets.
• A data quality and utility label. Where a dataset carries a quality label, you have to be able to evidence it — documentation, technical quality, coverage, and how the data has been modified over time. That evidence has to come from somewhere real.
• Lineage. Underneath all three sits provenance: where each field came from, what transformed it, when it changed. Without lineage you cannot substantiate a quality label, defend an anonymisation, or answer a supervisor. Lineage is the load-bearing artefact, and it is the one nobody has by accident.

The detailed technical specifications for descriptions and labels are being fixed through Commission implementing acts, expected to arrive around the 2027 general application date, with a shared metadata standard emerging alongside them. Waiting for the final schema before starting is a mistake. The specification will tell you the exact fields; it will not build your extraction, your terminology mapping, or your lineage capture for you, and those are the slow parts.

Why 2029 is a today problem

This is the same trap regulated firms keep walking into with staggered deadlines: reading a date three or four years out as permission to wait. It is the pattern I described in the context of the ECB’s IReF timeline — a later go-live still means starting your data model now. The obligation date is when you must be able to respond; the data-model, pipeline and lineage work that lets you respond takes years, not months, in any estate with legacy clinical systems and inconsistent coding.

Scope it honestly and the shape is clear. An in-scope holder needs a catalogue of what it holds against the Article 51 categories, a standardised extraction layer, minimisation and opt-out resolution at extract time, machine-readable descriptions, a quality-label evidence base, and lineage under all of it. Treat that as a legal deliverable due in 2029 and you will be assembling it by hand under time pressure while the permits queue up. Treat it as the multi-year data-engineering programme it actually is, and 2029 becomes a date you meet rather than a date that arrives.

The access bodies will anonymise your data. They cannot manufacture the structure, the description, or the provenance that makes anonymising it safe. That part is yours, and it was always going to be the expensive part.