EHDS Patient Summary 2026: Who Verifies the Patient at the Border?

June 14, 2026 ·Mairi Kutberg ·

ehdseuropean-health-data-spacepatient-summarycross-border-healthcarepatient-identitymyhealth-euhealthcare-identityeidasicao-9303

The EHDS Regulation (EU) 2025/327 applies from 26 March 2026; cross-border Patient Summary and ePrescription exchange goes live across Member States by 26 March 2029. MyHealth@EU specifies the data exchange. The identity verification of the patient at the point of care is delegated to the receiving healthcare professional under national rules.

EHDS Patient Summary 2026: Who Verifies the Patient at the Border?

The EHDS Regulation (EU) 2025/327 applies from 26 March 2026, with the first cross-border Patient Summary and ePrescription exchanges going live across all Member States by 26 March 2029. Identity verification of the patient at the point of care is delegated to the receiving healthcare professional under national rules. That is the architectural gap.

The short version

The EU has built a serious cross-border health-data infrastructure. MyHealth@EU — formerly the eHealth Digital Service Infrastructure (eHDSI) — connects national contact points across Member States, runs over secure channels, and is governed by Regulation (EU) 2025/327 with implementing acts due by March 2027. The data layer is solved at the institutional level; the legal-basis layer is clear; the procurement budget exists. The hospital teams we work with — a regional Catalan teaching hospital network that receives roughly 200 cross-border patients per week from French and Andorran feeder regions, and a Berlin charity-funded tertiary hospital running a dedicated cross-border admissions desk — are the ones discovering that the verification gap sits at the person layer, not the data layer. The doctor-side equivalent of the same gap is the topic of our post on cross-border ePrescription doctor verification.

What is not solved at the EU level is the question that determines whether the right patient receives the right care: how does the receiving doctor know the patient standing in front of them is the patient whose Patient Summary is about to be requested through MyHealth@EU? In the regulation's current shape, the answer is national — every Member State does this its own way, and the receiving healthcare professional is the legal verifier of record. In practice, in early 2026 audits I sit in on, it looks roughly like the way it has looked for the last ten years of cross-border eHealth: a photocopied passport, a fax of an insurance card, a hand-typed identifier into a national portal, and a verification step that survives because it is rarely tested against an adversarial case.

Watching the EHDS implementing-act schedule against the existing eHDSI rollout, what stands out is the asymmetry: the Patient Summary infrastructure is moving at EU pace, the patient identity infrastructure is moving at the slowest Member State's pace. By 26 March 2029, when cross-border Patient Summary exchange is meant to be live across all Member States, that asymmetry is going to be the thing that determines whether the system is actually trustworthy or only architecturally complete.

What does EHDS actually say about patient identity verification?

Less than you'd hope, and that is on purpose.

Regulation (EU) 2025/327 defines the cross-border data exchange architecture — Patient Summary as the priority data category at primary use, with ePrescriptions and eDispensations alongside it, going live in all Member States by 26 March 2029 (European Commission — EHDS Regulation page). The second priority group — medical images, lab results, hospital discharge reports — follows by March 2031. The infrastructure layer is mandated; the implementing acts that flesh out the technical details are due from the Commission by March 2027.

The patient identity verification step is not on that list of standardised primitives. The eHDSI and MyHealth@EU operator role is documented as: the National Contact Point operator has access to and stores only administrative/operational data related to the identification of the patient, which must be verified by the healthcare professional in order to request the ePrescription (European Commission — Electronic cross-border health services). The verification of the patient is, legally and operationally, the healthcare professional's responsibility at the point of care.

There is a defensible reason for that. Identity proofing is jurisdictional in a way that data formats are not. Each Member State has its own national health identifier, its own eID infrastructure, its own conventions for patient ID at the hospital reception. The EHDS Regulation deliberately does not legislate across that — it builds the rails and lets each Member State plug in. The same architectural reasoning sits behind why EBSI delegates holder binding to the wallet rather than the ledger; see Post 5 of the education cluster on EBSI holder binding for the equivalent pattern in academic credentials.

The honest reading is that this is the right architectural call at the EU layer. It is also the layer where every actual identity-fraud case will sit.

Who verifies the patient at the receiving doctor's office?

The receiving healthcare professional, against whatever national document or identifier the patient happens to present.

In practice this varies by Member State and by setting. A French patient arriving at a Berlin hospital for elective care may present a French Carte Vitale, a French national ID, a passport, or — increasingly — an EUDI Wallet credential by 6 December 2026 once each Member State has at least one wallet available (Regulation (EU) 2024/1183 — EUDI). A Spanish pharmacy filling an ePrescription issued by a Polish GP via MyHealth@EU verifies the patient at the counter against whatever document the patient produces. The combination of accepted documents is institutional, not regulatory.

What concerns me about this state of affairs, sitting on the ops-and-compliance chair at the receiving Member State end, is three things at once.

First, the variance is wide. The hospital admissions teams I've spoken with in the past quarter range from "we check the photograph and the date of birth and that's it" through to "we already do NFC chip reads on the biometric passport at every cross-border admission, but only because our IT director read a paper about deepfakes". There is no national, let alone EU, baseline.

Second, the legal locus of identity verification — the healthcare professional must verify the patient — places liability on individual clinicians without giving them a standardised tool. When an audit goes wrong, the question lands on the clinician who admitted the patient. The same audit at a hospital with chip-read primitives would have produced a binary verification record; at a hospital with photocopy-based verification, the question is "do we have notes from the admission".

Third, and the one that hospital IT leads I've talked to don't see as their problem yet: as MyHealth@EU goes from limited pilot to full Member State coverage in 2029, the volume of cross-border patient identity verifications a typical receiving hospital does will increase by an order of magnitude. The current process scales poorly. The fraud window — which is small today because the volume is small — opens at the same rate as the legitimate volume does.

Where does this leave cross-border patients in 2026-2029?

In a three-year window where the data infrastructure is being deployed faster than the identity infrastructure to use it safely.

There are concrete consequences that the implementing-act drafting process in 2026-2027 has to address, and that hospital procurement should be planning against now. From inside the compliance audit, the question that always comes up at month fourteen is: can we show, in the audit log, who verified this patient's identity at the moment we requested their Patient Summary from MyHealth@EU? In a hospital with a standardised chip-read identity-proofing primitive at admission, the answer is yes, with cryptographic evidence. In a hospital with photocopy-based admission, the answer is "the clinician signed the admission form" — which is not, by 2027 audit standards, a defensible identity verification record.

The European Commission's EHDS Regulation page is explicit that secondary use of health data carries different obligations from primary use. Identity-proofing of the patient at the point of care is firmly a primary-use concern. The implementing acts due by March 2027 are likely to tighten the conformity-assessment language around what counts as adequate patient identity verification, particularly given the parallel obligations under the NIS2 Directive (EU) 2022/2555 for healthcare entities as essential entities.

What I'd recommend any hospital-side compliance lead do this quarter is the same shape of recommendation I made for university admissions in the education cluster's playbook: move the patient identity-proofing event to admission, anchor it on a primitive that survives the audit, and document the binding before the implementing acts land. For receiving hospitals seeing cross-border patients, that primitive looks like the biometric passport NFC chip for the 179 ICAO 9303 countries that issue them, with document authenticity plus biometric face match (FaceTec liveness) for every remaining country — what we ship as the Identity Verification product. The output is an audit-defensible record signed under eIDAS Article 26 AdES (signatures product) that the hospital retains independently of MyHealth@EU.

What an EHDS-ready patient identity layer would look like

A 2027-ready cross-border patient identity layer has three properties.

It is proofed once at admission, not redone at each cross-border data request. Today, every time a hospital requests a Patient Summary via MyHealth@EU, the verification quality depends on the receiving healthcare professional's judgement at that moment. With an admission-time AdES record bound to a chip-read identity, every subsequent cross-border data request references the same verified identity. The hospital's identity record is the source of truth; MyHealth@EU consumes that record rather than expecting the receiving doctor to recreate it.

It is vendor-independent and Member-State-portable. The hospital should not be locked into a particular national eID scheme or wallet provider for cross-border patient identity. The chip-anchored primitive is country-agnostic by design — it works for the Lagos patient arriving on a tourist visa just as it works for the EU citizen presenting an EUDI Wallet credential. The receiving hospital runs the same flow regardless of the patient's home jurisdiction, which is the operational property the MyHealth@EU rollout depends on.

It is audit-defensible against the conformity-assessment language the implementing acts will likely adopt by March 2027. The implementing-act drafting process is currently looking at NIS2-aligned obligations for healthcare entities. What survives an auditor walk-back is the kind of evidence chain a chip read produces — verifiable offline, cryptographically signed by the issuing state, presence-bound through PACE. What does not survive is the photocopy of a national ID with no provenance.

EHDS patient summary cross-border journey — five stages from patient arrival at the receiving Member State through identity verification, NCPeH request, MyHealth@EU exchange, home Member State data return, and Patient Summary delivered. The identity verification step is currently delegated to the receiving healthcare professional under national rules; the architectural gap sits there.

The honest read is that the next eighteen months of EHDS rollout are when the patient identity layer either gets built into the hospital admission stack or gets left as a 2029 problem. The implementing acts due March 2027 will set the conformity-assessment ceiling. The hospitals that have a chip-anchored admission-time identity record by then are in a different procurement and audit position from the hospitals that don't.

Sources

Primary — EHDS and EU health data infrastructure

Primary — identity and cybersecurity regulatory framing

Primary — identity-proofing 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 signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.