How Does Doctor Identity Move Across EU Borders in 2026?

July 8, 2026 ·Gustav Poola ·

doctor-identitycross-border-healthcareeudi-walleteu-professional-cardeidasehdsprofessional-qualificationsverifiable-credentialcredential-architectureidentity-verification

Through three overlapping credential schemas — the doctor's national professional certificate (issued by the home medical register), an extended EU Professional Card under Directive 2005/36/EC (planned, not yet operational for physicians), and a Person Identification Data attestation in their EUDI Wallet under Regulation (EU) 2024/1183 (provisioned by 6 December 2026). None of the three yet covers the full cross-border scope alone. The deployment question for digital health platforms in 2026 is which schema to read first and which to fall back to.

How Does Doctor Identity Move Across EU Borders in 2026?

In our work shipping the foundation-layer identity-proofing primitive that sits underneath the doctor-side credentials in the EU's emerging cross-border health stack, the credential-architecture question is the one digital health platforms walk into thinking is a procurement problem. It isn't. It is an architectural problem about which schema carries which assertion, which authority issues each schema, and which schema's lifecycle the deployment depends on. A Bavarian regional university hospital we worked with — recruiting Polish anesthesiologists under temporary cross-border recognition — discovered the three-schema reality the hard way: the doctors arrived holding a Polish national professional certificate that the hospital's HR system could not consume, and the eHDSI integration the hospital had budgeted for did not solve the HR onboarding problem at all. The procurement comes after the architecture. The pattern this post walks through is the architecture, which connects directly to the doctor-side equivalent of our earlier post on cross-border ePrescription doctor verification and to the staff-identity layer covered in our NIS2 hospital staff identity post.

What does "doctor mobility" actually mean at the EU's identity layer?

Three distinct movement patterns, each with a different identity-verification surface.

The first pattern is temporary cross-border practice under Article 5 of Directive 2005/36/EC — a doctor licensed in their home Member State provides services occasionally in a host Member State without establishing there. The receiving health system has to verify both that the person is who they claim to be and that they hold an authentic licence in their home country. The verification surface here is a one-off transaction, often time-pressured (the patient is in front of the physician), and the credential the verifier sees has to be presentable in a single interaction.

The second pattern is establishment in another Member State under Articles 7-15 of the same Directive — the doctor moves their practice permanently to a host country, files for recognition of qualifications, and registers with the host country's medical council. The identity-verification surface here is the registration event itself: the host medical register has to verify the doctor's identity against the home Member State's register record, against the qualification certificate, and against the foundational identity proofing. This is a slower, more thorough verification but the artefacts the host register issues are then trusted by every downstream system in that Member State for years.

The third pattern is cross-border telemedicine — the physician practises remotely from one Member State to a patient in another, without physically moving. This is the fastest-growing pattern through 2026, and it is the one where the verification surface is most fragmented: the receiving platform sees a digital identity claim and has to validate it against multiple registers without a face-to-face anchor. The European Commission's 2024 telemedicine recommendation urges Member States to harmonise the digital identity primitives that travel with the physician's prescribing or consultation event, but the harmonisation is still in early implementation.

What I see in production deployments in mid-2026 is that the three patterns load different parts of the credential stack. Temporary practice leans on the EU Professional Card workflow (when it covers the profession) and on national medical register lookups. Establishment leans on the qualification-recognition machinery and produces durable host-register records. Telemedicine leans on whatever digital primitives the prescribing physician presents — usually a national professional certificate, increasingly a wallet-presented attestation. The architectural lesson is that no single credential schema is sufficient for all three patterns, and the platforms that try to serve all three with one schema end up retrofitting bridging logic for the patterns the chosen schema does not cover.

Why does a doctor's identity hit three credential schemas at the border?

Because each schema was designed for a different purpose by a different authority, and the cross-border health stack is being assembled by composing them rather than replacing them.

The first schema is the doctor's national professional certificate — issued by the national medical register (or an authorised QTSP acting on its behalf), used to sign clinical documents, anchored on the home Member State's trust framework. This is the schema that eHDSI today relies on. It is operational, in production across all twenty-five Member States exchanging cross-border services, and it carries the doctor's signing authority. What it does not carry is portability — the certificate is bound to the home Member State's PKI, and the receiving system has to resolve it through the EU Trusted List and through the home NCPeH.

The second schema is the European Professional Card (EPC) under Directive 2005/36/EC, Articles 4a-4e. The EPC was introduced in 2016 as an electronic certificate that proves the holder has the qualifications required to provide services in a particular Member State; it currently covers nurses responsible for general care, pharmacists, physiotherapists, mountain guides, and real estate agents. The European Commission opened a consultation in January 2026 on extending the EPC to physicians, and the implementing-act draft is expected in late 2026 for application in 2027. The EPC's distinctive feature is that it lives in the Internal Market Information System (IMI) and can be validated by any host Member State authority through that infrastructure, without needing a direct bilateral check with the home register. What the EPC does not carry is signing authority — it attests qualification, not the right to produce a binding clinical signature.

The third schema is the EUDI Wallet Person Identification Data (PID) attestation under Regulation (EU) 2024/1183 plus the Electronic Attestation of Attributes (EAA) schema for professional qualifications. The PID carries the doctor's core identity attributes as a wallet-held credential, signed by the Member State PID issuer. The EAA can carry the professional qualification as a separate attestation, signed by the medical register or by an EHDS-designated digital health authority. Together, the PID + EAA pair can theoretically substitute for both the national professional certificate (with the right signing-key binding) and the EU Professional Card (with the right qualification-attestation schema). Practically, the substitution is still in pilot. The 6 December 2026 deadline applies to PID provisioning to citizens; professional EAAs follow on a slower implementation timeline tied to each Member State's digital health authority designation under EHDS Article 14.

The architectural reading is that the three schemas occupy three different layers of the trust stack — signing authority, qualification attestation, and portable identity — and the cross-border health stack composes them. The composition is not optional; the verification chain reaches into all three when the deployment is serious about audit. The platforms that design around all three from the start ship cleanly. The platforms that pick one and bridge to the others at runtime accumulate technical debt at the bridging layer.

How are the three schemas supposed to interoperate?

Through the W3C Verifiable Credentials Data Model 2.0 at the credential-format layer, the EUDI Wallet ARF at the presentation-protocol layer, and the IMI / eHDSI bridges at the registry-federation layer — with each schema referencing the others by identifier rather than embedding them.

The credential-format question is closest to resolution. The W3C Verifiable Credentials Data Model 2.0 (W3C Recommendation, 15 May 2025) and W3C Decentralized Identifiers v1.1 (Candidate Recommendation, 5 March 2026) together define how each schema is serialised, signed, and resolved by identifier. The doctor's PID is a verifiable credential referencing the doctor's DID; the professional EAA is a separate verifiable credential referencing the same DID; the national professional certificate is an X.509 certificate that can be cross-referenced by fingerprint inside a verifiable credential rather than embedded. The receiving system follows the DID, resolves the credential chain, and validates each link against the appropriate trust framework.

The presentation-protocol question is partly resolved. The EUDI Wallet Architecture Reference Framework v2.2.0 defines how the wallet presents credentials to a verifier using OpenID for Verifiable Presentations (OID4VP) and SD-JWT under RFC 9901. The wallet can present the PID, the professional EAA, and a signing-authority reference in one transaction. The receiving system parses the presentation, validates each credential against its issuer's published trust framework, and resolves the overall claim "this is doctor X, licensed in country Y, authorised to sign clinical document Z".

The registry-federation question is least resolved. The eHDSI infrastructure federates national medical registers through NCPeHs for cross-border clinical exchange. The Internal Market Information System (IMI) federates qualification registries through a different protocol. The EUDI Wallet framework expects PID issuers and EAA issuers to publish trust framework metadata in a standard form, but the mapping from EUDI EAA to the IMI EPC schema is still being specified, and the mapping from EUDI EAA to the eHDSI professional certificate model is even earlier. What this means in 2026 deployment terms is that platforms wanting to consume all three schemas end up writing bridging code per Member State pairing — the harmonisation is at the credential-format and presentation-protocol layers, not yet at the registry-federation layer.

Where does foundation-layer identity-proofing sit relative to these three schemas?

At the issuance step for all three. The schema choice is downstream; the proofing event is upstream.

This is the part the architectural diagrams of the EU credential stack tend to underspecify. Each of the three schemas — national professional certificate, EU Professional Card, EUDI Wallet PID+EAA — depends on the doctor having been identity-proofed at IAL2 or higher (NIST SP 800-63-4 (May 2025 draft) terminology) at the moment the issuing authority writes the credential record. The certificate, card, and wallet attestation are downstream artefacts of that proofing event. If the proofing event is weak — if the issuing register accepts a self-declared identity claim with light documentation — every credential the register subsequently issues inherits the same weakness, regardless of which schema it serialises into.

The foundation-layer primitive that produces the strongest proofing event in 2026 is chip-anchored verification. The doctor's passport NFC chip read under ICAO 9303, or the doctor's national eID card chip read where available, produces a cryptographic record that the holder is the document's rightful holder. For doctors holding documents from the 179 ICAO 9303 countries, that is the primitive that ships in production today. For doctors holding documents from the remaining countries (smaller subset, generally pre-biometric national IDs or older travel documents), the foundation-layer primitive is document authenticity verification plus biometric face match with FaceTec liveness — sufficient to establish the document-to-holder binding even without a chip read. We ship both primitives at IdentiGate as the Identity Verification product, with the resulting record AdES-bound under eIDAS Article 26.

The IdentiGate Identity Verification product ships this foundation-proofing primitive — chip-anchored verification under eIDAS Article 26 at IAL2 or higher. The distinctive value is the chip-anchored proofing that travels with the doctor across borders even when the home Member State's national infrastructure does not federate to the receiving Member State's stack — particularly relevant for the cross-border telemedicine pattern and for non-EU physicians practising under temporary recognition. The Authentication product provides the re-authentication step at the credential-presentation moment (when the doctor presents the wallet credential to a verifier, the wallet's key has to be re-bound to the verified doctor in that session).

What I'd push back on hardest in the architectural discussion around the three schemas is the assumption that the schema choice is the load-bearing decision. It isn't. The proofing-event quality at issuance is the load-bearing decision; the schema choice is operational packaging of the proofed identity. Get the proofing right and the three schemas are roughly substitutable downstream. Get the proofing wrong and no schema choice rescues the chain. The architectural priority for any digital health platform deploying into the EU in 2026-2029 is to specify the foundation-layer proofing requirement first — what IAL is needed, what primitive produces evidence at that IAL, what AdES record gets retained — and then choose which of the three schemas to read at the credential-consumption interface based on what the upstream issuers actually publish into the doctor's wallet or register.

Sources

Primary — EU healthcare and professional-qualifications framework

Primary — eIDAS and EUDI Wallet

Primary — credential and presentation standards

Primary — identity assurance and document chip standards

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

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.