Health data holder

Your hospital becomes a health data holder in March 2029

The European Health Data Space gives research hospitals a defined role in the secondary use of health data.Source The duties are fixed in law. The work of meeting them takes longer to build than the time left.

Regulation (EU) 2025/327, the European Health Data Space Regulation, entered into force in March 2025.Source Most attention has gone to its first half: patients' access to their own records across borders. For a research hospital the second half matters more. It creates a system for using health data for research, innovation, policy, and regulation, and it names the hospital as a health data holder inside that system.Source

A health data holder describes the datasets it holds, keeps those descriptions current, and supplies data to a national health data access body when a permit is issued. From March 2029 that applies to most data categories. Clinical trial, genomic, and research cohort data follow in March 2031.Source

This guide sets out what the duties mean inside a hospital, where hospitals usually slip, and a plan that starts in 2027 with one dataset.

Who it is for

Heads of clinical research units, research office directors, data protection officers, and hospital IT.

What you get

The dates, the six duties, a worked example, ten readiness capabilities, and a 2027 to 2031 plan.

How to use it

Read pages 2 to 5 alone. Work through pages 8 to 10 with your DPO and IT lead in the room.

From the research office

A hospital can only describe and release data it can locate. Before anyone answers a permit, someone has to establish where each record physically sits and who processes it. That inventory is the first job, and it does not need software to start.

Four dates, fixed in the regulation

The calendar is set. What a hospital controls is how much of the work is done before each date arrives.

The hospital holds the data. The access body decides who uses it.

Data holders do not choose recipients on their own. Requests run through a national authority, and the hospital's job is to supply what each permit covers, correctly and on time.Source

In plain words: health data holder

How a request travels

Approved users do not receive patient-level files. They work inside a secure processing environment under the access body's control, on anonymised data by default and pseudonymised data only where the purpose needs it, and they take out only non-personal results.Source

The same regulation counts the training, testing, and evaluation of AI algorithms used in health or care as scientific research.Source A hospital that can describe and supply its data well is ready for the access body, and for research partnerships in which it keeps hold of its own records.

Six duties, and what each means on a Monday morning

Each duty is short in the regulation and long inside the hospital, because each one touches every system that holds research-relevant records.

One permit, Hospitals A, B, and C, the same three months

An access body issues a permit for anonymised data on adults with type 2 diabetes treated between 2020 and 2028 who had retinal imaging. The request is identical in all three versions below. Only where the hospital's records sit changes.

Hospital A: records where they were created

Deadline at risk. Diagnoses sit in the health record, results in the laboratory system, retinal images in the imaging archive. Each system has its own owner and its own patient identifier. The research office asks three owners for three exports, matches patients by hand, applies opt-outs from a spreadsheet, and anonymises the result once, without a repeatable method. Nothing is reusable for the next permit.

Hospital B: a registry, with the images outside it

Extension likely. A diabetes registry holds coded diagnoses and results with consent, so the cohort is found in one query. The images still sit in the archive under a different identifier, and linking them is a separate project. The hospital meets most of the request and asks for the extension.

Hospital C: one governed layer

Within the window. Records, results, and images already sit together under one permission model, coded at capture, with opt-outs applied at extraction and every release logged. The research office runs the permit's criteria, reviews the anonymised extract, and releases it through the defined channel. The next permit starts from the same place.

What the example shows

None of the hospitals is careless. The difference is where the work was done: once, in advance, in one layer, or again, by hand, for every permit. Hospital C is an illustration of a target state, and not a measured result.

From the platform

One record per child, across every centre

The Scientific and Research Data Hub grew out of work that already runs. A national paediatric oncology register runs on the platform, with imaging, pathology, genomic data, and biobank samples in each record.

A national register is a harder case than one hospital's dataset: many centres, long follow-up, every data type, and consent held with each registration. The capabilities a health data holder needs are the ones such a register runs on every day.

The register is anonymised in this guide at the request of the institutions involved. It is shown as a deployment of the platform and not as a ZINOS customer.

The platform behind ZINOS was developed by MIA Solutions over ten years across more than 40 clinical sites.

Five ways readiness breaks, and how to spot each one

All five are cheap to fix in 2027 and expensive to fix under a permit deadline.

1. The IT project

Readiness is handed to IT as an interoperability upgrade. The research office, which knows what the datasets are for, and the DPO, who answers for every release, join after the design is set.

2. The catalogue without an owner

Dataset descriptions are written once for a pilot and never reviewed. The regulation expects a check at least once a yearSource, and a stale description invites requests the hospital cannot meet.

3. Coding after the fact

Diagnoses and histology are recoded for each request. Coding at capture to ICD-10, ICD-O-3, or Orpha codes is what makes a dataset describable and combinable.

4. The opt-out spreadsheet

Opt-outs are held outside the systems that extract the data and applied by hand. One missed record is a release the hospital cannot take back.

5. Waiting for 2031

Trial, genomic, and cohort data are left until their date.Source These are the datasets researchers value most, and they are the hardest to bring under one governed layer late.

Ten capabilities that decide whether you answer a permit in three months

Print this page. Work through it with your research office, your DPO, and IT in one room. A box you cannot tick is next year's work.

• An inventory of every system that holds research-relevant data, and who owns each one.
• One governed layer where records from those systems sit together, under one permission model and one audit trail.
• Coding at capture to international classifications, so datasets can be described and combined without recoding.
• A dataset catalogue that can generate descriptions in the standard format and keep them current.
• Provenance: where each record came from, when, and how it has changed.
• Quality documentation that can support the data quality and utility label.
• Repeatable extraction, anonymisation, and pseudonymisation for a permit-scoped extract.
• An opt-out register applied automatically at extraction.
• A permit and release log: every request, every approval, every release, on the record.
• Clear ownership: the research office, the DPO, and IT agree who does what before the first request arrives.

Start in 2027 with one dataset

Readiness is built one dataset at a time. Pick the pilot that teaches the most: a registry or biobank with a clear owner, a defined population, and existing coding.

A first dataset description, in five sentences

• [dataset name] holds [data types: records, results, images, samples] on [population and condition].
• It covers [period] and is updated [frequency].
• Records are coded to [classifications] at [point of capture].
• It is held in [system or layer] and owned by [named role].
• It excludes [populations, data, or uses not covered].

A starting point for internal work, not a HealthDCAT-AP record. Your access body's published profile decides the final fields.

One governed layer, inside your hospital

The ZINOS Scientific and Research Data Hub is EHDS-aligned. It brings a hospital's research records under one governed layer inside the hospital and releases data on the hospital's terms.

What it joins

Health records, laboratory results, imaging, digital pathology, genomics, biobank samples, and trial data, coded to international classifications at capture.

How it releases

Anonymised extracts on the hospital's terms, with every release logged in one audit trail.

Where it runs

On the hospital's own servers. Under on-premise deployment no patient data is exported, and sponsors, monitors, and inspectors work through scoped access.

With the trial record

The ZINOS clinical site operating system runs the site file, case report forms, visits, consent, and oversight on the same core, ahead of the 2031 date for trial data.Source

Spend the next hour on your own hospital

Three ways to start, from a meeting you can hold this month to a conversation with us.

Hold the governance meeting

This month, one hour. Research office, DPO, and IT in one room with the checklist on page 9. Leave with a named owner and a draft system inventory.

Choose the pilot dataset

This quarter. Use the five-sentence template on page 10 to describe one registry or biobank. Where you cannot fill a blank, you have found the first piece of work.

Book a call with ZINOS

When you want a second view. Bring your DPO, IT, and quality leads. We will walk through your inventory and show how the data hub keeps records inside your walls.

Sources

1. Regulation (EU) 2025/327 of the European Parliament and of the Council on the European Health Data Space, Official Journal of the European Union, 5 March 2025.
2. European Commission, Frequently asked questions on the European Health Data Space.
3. TEHDAS2, guideline for data holders on describing health datasets with HealthDCAT-AP, 27 October 2025.
4. Bird & Bird, Health data holders' obligations under the EHDS: what, when, and how will we know.
5. Covington, Inside Privacy, The European Health Data Space from the health data holder's perspective.

This guide is general information about Regulation (EU) 2025/327 and does not replace legal advice on your hospital's position. Summaries of the regulation are ours; the Official Journal text is authoritative. Facts are current at October 2026. The worked example on page 6 is illustrative and not a measured result. Implementing acts due by March 2027 may change the detail of dataset descriptions and the data quality and utility label.Source