EHDS Secondary Use: Who Verifies the Researcher Asking for Patient Data?

July 10, 2026 ·Mairi Kutberg ·

ehdssecondary-usehealth-data-spaceresearcher-identityhealth-data-access-bodyhdabhealthdataeuscientific-researchgdpreidas

The Health Data Access Body (HDAB) in each Member State is the gatekeeper. Designated by 26 March 2027 under Article 36 of the European Health Data Space Regulation, the HDAB verifies the researcher's identity, affiliation, ethics approval, and proposed processing scope at the data permit application step — and only then issues access to the Secure Processing Environment where the underlying patient data sits. The chain terminates at the researcher's identity record; the strength of every downstream control depends on the strength of that record.

EHDS Secondary Use: Who Verifies the Researcher Asking for Patient Data?

In our work helping research consortia and Member State health authorities plan cross-border data access flows for the EHDS rollout, the researcher-verification question is the one that universities and pharma research teams walk into thinking is solved by their existing ethics-committee process. It isn't. The ethics committee approves the research; it does not verify the researcher's identity at the moment data access is granted, and it does not produce the cryptographic record an HDAB needs to defend the access decision under audit. A KU Leuven-led cardiovascular research consortium we worked with discovered the gap when its data permit application to the Finnish HDAB came back with a request for IAL2-equivalent proofing evidence on each named investigator — the ethics approval was clean, the data minimisation rationale was clean, but the identity-binding evidence under the consortium's existing onboarding flow did not meet the threshold. The identity-verification piece sits between the ethics approval and the data permit, and it is where most secondary-use deployments will discover their evidence gap through 2027. This is the secondary-use counterpart of the primary-use verification flow we walked through in our post on EHDS patient summaries at the border and the prescribing-side equivalent of the cross-border ePrescription doctor-verification chain.

What does "EHDS secondary use" actually allow a researcher to do?

Apply for a data permit covering a defined research project, against a defined scope of health data, processed inside a Secure Processing Environment under a specified retention window.

The mechanism is set out in Articles 33-65 of Regulation (EU) 2025/327. The EHDS opens electronic health data held by Member State health systems for secondary use — secondary, as in not for the primary clinical care of the patient whose data is being processed. Article 53 lists the permitted purposes: scientific research, training and testing of AI systems in the health domain, public-health activities, policy-making, statistical purposes, and education-related personalisation of health services. Each permitted purpose carries its own additional conditions; the floor for all of them is that the data subject has not opted out and that the processing happens within the bounds of the data permit.

The categories of data covered are listed in Article 51 — they include the electronic health records of natural persons, claims and reimbursement data, biobanks and genomic data, registries and cohort data, clinical-trial data, public-health data, wellness data, and so on. The priority categories that have to be made available first under Article 12 — patient summaries, ePrescriptions, ePrescription dispensations, medical images, laboratory results, hospital discharge reports — are the same priority categories that EHDS primary use under MyHealth@EU exchanges across borders. The secondary-use access flows through a different infrastructure: HealthData@EU, the federation of Member State HDABs.

The researcher does not see the underlying record-level patient data directly outside the Secure Processing Environment. Under Article 67, the HDAB provides access via an SPE that the researcher logs into; data leaves the SPE only as aggregated or anonymised outputs that the researcher has cleared through the HDAB's egress check. This is the architectural pattern the EU has converged on after a decade of debates about pseudonymised data exports — keep the data inside a controlled environment, let the researcher reach in, restrict what leaves.

Who verifies the researcher's identity before access is granted?

The Health Data Access Body — at multiple steps, with the identity record carried forward across each step as the binding evidence.

Article 36 of the EHDS Regulation requires every Member State to designate one or more Health Data Access Bodies by 26 March 2027. The HDAB is the operational gatekeeper for secondary use in its jurisdiction. Its core verification responsibility under Articles 46-49 is to assess the data permit application — and that assessment includes verifying the applicant (typically a researcher or a research organisation), the ethics approval, the data minimisation rationale, the technical and organisational security measures, and the alignment of the request with permitted secondary-use purposes.

The identity verification step has three concrete sub-steps. First, identity at application — when the researcher submits the data permit request, the HDAB has to be able to confirm who is submitting. Second, identity at affiliation — the HDAB has to confirm the researcher's affiliation with the named research organisation, because the data permit binds the access to the organisation as data user under Article 50. Third, identity at access — when the researcher logs into the Secure Processing Environment, the SPE has to re-authenticate the researcher against the same identity record the HDAB approved at application time.

What the EHDS Regulation does not specify, and where the engineering pressure has landed in 2026-2027 implementation planning, is which identity assurance level the HDAB has to apply. NIST SP 800-63-4 (May 2025 draft) provides the framework that most planning documents are leaning on: IAL2 (verified identity, evidence-based) for routine research access, IAL3 (in-person or supervised-remote proofing with strong document verification) for sensitive categories such as genomic data or rare-disease cohorts where re-identification risk is elevated. The Member States that have published draft HDAB implementing guidance — France, Germany, the Netherlands, the Nordic group — are converging on IAL2 as the floor, with IAL3 step-up for sensitive-data permits.

What I see in the cross-Member State coordination conversations in 2026 is that compliance leads are increasingly aware that the HDAB's identity-verification quality is the audit anchor for every research output that flows from EHDS secondary use. A research result published in 2029 from a data permit granted in 2027 has to be traceable, at audit, to the identity record the HDAB validated at the application step. If the identity record is thin — self-declared affiliation, weak document verification — the entire research output sits on a fragile evidential base, and a regulator's later challenge of the data permit becomes an existential question for the research consortium.

How does cross-border researcher access work under HealthData@EU?

The researcher's identity is verified at the home Member State HDAB and asserted across the HealthData@EU network to the data-holding Member State HDAB. The federation mirrors the MyHealth@EU primary-use pattern, with a different gatekeeper.

Article 56 of the EHDS Regulation creates HealthData@EU — the EU-level federation infrastructure connecting Member State HDABs. The architecture is straightforward in concept and complex in execution. A researcher in country A who needs data held in country B submits the data permit application through their home HDAB (country A); the application is forwarded through HealthData@EU to country B's HDAB; the data-holding HDAB assesses the request, and if approved, opens an SPE at the data-holding side that the researcher accesses remotely. The identity assertion that travels from country A's HDAB to country B's HDAB carries the verified identity, the affiliation, the ethics approval, and the application's scope — signed by country A's HDAB on behalf of country A's trust framework.

What this means operationally is that the researcher does not have to be separately verified by every Member State's HDAB whose data the researcher requests. The home HDAB's identity-verification record is propagated through HealthData@EU and trusted by the receiving HDAB under the EU-level trust framework. This is the same federation pattern that MyHealth@EU established for primary-use clinical exchange; the EHDS extends the pattern to secondary use through a different gatekeeper layer.

The practical implication that compliance leads in research consortia should care about is that the first HDAB the researcher engages with sets the assurance level for every subsequent cross-border access under the same identity. A researcher whose home HDAB applies a weak identity-verification step is going to find that data-holding HDABs in other Member States either reject the federated assertion or require the home HDAB to upgrade the proofing before access is opened. The harmonisation pressure under HealthData@EU is pushing IAL2 as the floor and IAL3 for sensitive-data access — uniformly across the federation. The Member States that designate weak HDABs will discover quickly that their researchers can only access domestic data.

For non-EU collaborating researchers — a US-based academic on a joint project with a Dutch hospital, a UK pharma scientist accessing a German cohort, a Swiss biostatistician on an EU-funded clinical trial — the federation does not reach. Those researchers either have to be onboarded under one of the Member State HDABs' permitted procedures for non-EU collaborators (which each HDAB will publish separately under Article 35), or the data has to come out to them in a form the SPE permits (typically only anonymised statistical aggregates leave the SPE under Article 67). The non-EU researcher's identity verification is where the chip-anchored proofing primitive most clearly fills a gap that no EU-internal scheme covers.

EHDS secondary use researcher-verification flow — researcher submits data permit through home Health Data Access Body, HDAB verifies identity at IAL2 or higher, affiliation, and ethics approval, then forwards the application through HealthData@EU federation to the data-holding Member State HDAB, which opens a Secure Processing Environment for the researcher to access the underlying patient data.

Where does foundation-layer identity-proofing sit in the researcher onboarding flow?

At the application step, before the data permit is issued, and at the SPE access step every time the researcher logs in. The HDAB's identity assurance is only as strong as the proofing event behind it.

This is the practical question that turns the EHDS researcher-verification framework from a regulatory abstraction into an operational integration. The HDAB has to verify the researcher's identity at application time. The verification has to meet IAL2 (or IAL3 for sensitive categories). The verification has to produce an evidentiary record the HDAB can retain and defend at audit — typically AdES-bound under eIDAS Article 26 so the record carries forward as a binding statement of who was identified, when, and how.

For EU researchers, the verification flow most Member States are planning around the EUDI Wallet under Regulation (EU) 2024/1183. The researcher presents their wallet-held PID attestation, the HDAB validates the PID, the researcher additionally presents a professional affiliation EAA issued by their employing research organisation, the HDAB validates the EAA against the issuer's trust framework. The wallet-based flow handles both identity and affiliation in one transaction, and the chain back to the proofing event behind the PID issuance is what carries the IAL claim.

For non-EU researchers and for EU researchers whose home Member State's wallet provisioning is not yet operational — a large group through 2026-2027 — the verification flow leans on document-anchored proofing. The researcher presents their passport or national identity card, the proofing primitive reads the document chip (passport NFC under ICAO 9303 for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country), and the result is bound to the researcher's session through an AdES record. The HDAB retains the AdES record as the verification evidence. The IdentiGate Identity Verification product ships this foundation-proofing primitive at the assurance level the HDAB will need for IAL2-plus secondary-use applications, with the Authentication product handling the re-authentication step at every SPE login.

What I'd push back on hardest in the EHDS-rollout planning conversations is the assumption that the EUDI Wallet handles all researcher verification cases by 6 December 2026. It doesn't, and it isn't supposed to. The wallet covers EU residents; the wallet provisioning timeline varies by Member State; the wallet's professional EAA infrastructure lags the PID by months to years; and the non-EU collaborating researcher case is outside the wallet framework entirely. The honest read for any HDAB planning its researcher-onboarding flow in 2026-2027 is to specify a primary path (wallet-based) and a secondary path (chip-anchored proofing for the cases the wallet does not yet cover) — and to specify both at the same assurance level. The researcher who is identity-proofed through the chip-anchored primitive should be able to do the same research under the same data permit as the researcher who comes in through the wallet, with the same audit defensibility on the downstream output.

The architectural priority for the Member States designating HDABs ahead of the 26 March 2027 deadline is the same priority every other identity-bound regulatory regime has converged on in 2026: get the foundation-layer proofing right at IAL2 or IAL3, retain the AdES-bound evidence record, and design the downstream credential and access controls around that anchor. Get this right and the EHDS secondary-use framework delivers the research-access value it was designed for. Get it wrong and the secondary-use research outputs sit on an evidential base that will not survive a determined regulatory challenge. We have not yet seen an HDAB stress-tested in court; we expect to see the first one before the 2029 EEHRxF deadline lands.

Sources

Primary — EHDS and EU healthcare framework

Primary — eIDAS and EUDI Wallet

Primary — identity assurance and document chip standards

About the author

Mairi Kutberg is co-founder of IdentiGate. She focuses on identity-proofing operations under eIDAS, NIS2, AMLR, the AI Act, the EHDS, and adjacent regulatory frameworks, and on the institutional reality of running cross-border identity verification at scale.

The words we use in digital identity are load-bearing. Use the wrong one and the listener walks confidently down the wrong road — and in identity, security, and compliance, most of our everyday words send people the wrong way. This is the eleven-point vocabulary repair kit for anyone building identity infrastructure: data vs information, trust vs proof, authentication vs identity, permission vs authority, compliance vs evidence, disclosure vs predicate. If our language keeps reaching for words that can't be measured, are we building resilience — or performing security?

You verify the passport chip — remotely, in ninety seconds, with cryptographic evidence signed by the state that issued the document. The engineering answer for a remote-hire identity check without an in-person meeting is chip-anchored NFC read plus biometric face-match against the chip photo, wrapped in an AdES record retained under a Long-Term Validity envelope. This post walks the pattern for full-time employment remote hires (distinct from gig workers and contractor-of-record engagements), the four questions the pattern actually answers, and where the picture is genuinely harder than the identity layer alone.

Multi-party document signing takes one of two shapes — sequential (party A signs, then B, then C, each signature depending on the previous one) or parallel (all parties sign the same document independently, with an aggregator collecting and combining the signatures). Both are supported cleanly by the eIDAS AdES formats (PAdES, XAdES, CAdES) but the cryptographic semantics, the timestamp coordination, and the LTV envelope requirements differ meaningfully between them. This post walks the two patterns, when to use each, and what tends to break when the pattern is chosen wrong for the workflow.