|
Type
|
Reference
|
Content
|
|
web
|
example.org
|
subject
: Jan Jansen
|
|
web
|
example.org
|
author
: Dr. Maria Schmidt
|
|
web
|
example.org
|
custodian
: Amsterdam University Medical Center
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/eps-jan-jansen
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/hdr-jan-jansen
|
|
web
|
example.org
|
author
: Radiology Department, Amsterdam UMC
|
|
web
|
example.org
|
http://example.org/fhir/ImagingStudy/ct-chest-study
|
|
web
|
example.org
|
http://example.org/wado-rs/studies/1.2.840.113619.2.55.3.604688119.969.1234567890.123/series/1.2.840.113619.2.55.3.604688119.969.1234567890.124/instances/1.2.840.113619.2.55.3.604688119.969.1234567890.125
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/imaging-report-jan-jansen
|
|
web
|
example.org
|
http://example.org/fhir/Bundle/lab-report-jan-jansen
|
|
web
|
github.com
|
EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/euridice-org/eu-health-data-api/
and changes regularly. See the Directory of published versions
|
|
web
|
hl7.eu
|
|
|
web
|
ihe-europe.net
|
|
|
web
|
euridice.org
|
|
|
web
|
hl7.eu
|
IG © 2025+ HL7 Europe
.
Package hl7.fhir.eu.health-data-api#1.0.0-ballot based on FHIR 4.0.1
.
Generated
2026-11-05
|
|
web
|
profiles.ihe.net
|
The Health Data API Authorization Client obtains an access token from the selected Authorization Server
and presents it to a protected API. Client authentication, grants, scopes, discovery, and
launch context depend on the selected environment and protocol; public SMART interactive
clients do not authenticate at the token endpoint. This generic role does not by itself
claim IHE IUA or SMART conformance. See the applicable IHE IUA Authorization Client
,
SMART App
, or SMART Backend Service
definition and the relevant Authorization
requirements.
|
|
web
|
profiles.ihe.net
|
The Health Data API Resource Server hosts a protected API, validates or introspects access
tokens as applicable, and enforces granted authorization and local policy. It does not issue
access tokens or validate client assertions for an independent Authorization Server. This
generic role does not by itself claim IHE IUA or SMART conformance. See the applicable
IHE IUA Resource Server
or SMART FHIR Resource Server
definition and the relevant Authorization
requirements.
|
|
web
|
profiles.ihe.net
|
The Health Data API Authorization Server issues access tokens after applying the authentication and
authorization requirements of the selected environment and protocol. When user authentication
is required, it relies on an acceptable result from the
Authentication Service
, with which it MAY
be grouped. Authentication alone does not establish API access entitlement. Client assertion
validation applies only when the selected flow uses asymmetric client authentication. The
Authorization Server remains responsibility-distinct from a Resource Server, including when
the two are co-located. This generic role does not by itself claim IHE IUA or SMART conformance.
The Health Data API qualifier identifies this IG's role, not a central EU-operated service.
See the applicable IHE IUA Authorization Server
or SMART Authorization Server
definition and the relevant Authorization
requirements.
|
|
web
|
profiles.ihe.net
|
The IHE IUA Authorization Client authenticates to the Authorization Server, requests
least-privilege scopes, and presents the resulting bearer token to the Resource Server.
It implements the applicable IUA transactions. See the
IHE IUA Authorization Client
and Authorization
.
|
|
web
|
profiles.ihe.net
|
The independent IHE IUA Authorization Server authenticates clients, validates client
assertions when selected, applies issuance policy, prevents replay, and issues tokens.
Where user authentication is required, it may use the IG-defined Authentication Service;
this does not remove any applicable IUA Authorization Server conformance obligation.
It does not provide protected-resource enforcement. See the
IHE IUA Authorization Server
and Authorization
.
IUA requires this role to be grouped with a CT Time Client; see
required actor groupings
and the shared Time Synchronization
deployment guidance.
|
|
web
|
profiles.ihe.net
|
The independent IHE IUA Authorization Server authenticates clients, validates client
assertions when selected, applies issuance policy, prevents replay, and issues tokens.
Where user authentication is required, it may use the IG-defined Authentication Service;
this does not remove any applicable IUA Authorization Server conformance obligation.
It does not provide protected-resource enforcement. See the
IHE IUA Authorization Server
and Authorization
.
IUA requires this role to be grouped with a CT Time Client; see
required actor groupings
and the shared Time Synchronization
deployment guidance.
|
|
web
|
profiles.ihe.net
|
The IHE IUA Resource Server validates or introspects access tokens and enforces granted
authorization and local policy for protected resources. It does not validate client
assertions for an independent Authorization Server. See the
IHE IUA Resource Server
and Authorization
.
IUA requires this role to be grouped with a CT Time Client; see
required actor groupings
and the shared Time Synchronization
deployment guidance.
|
|
web
|
profiles.ihe.net
|
The IHE IUA Resource Server validates or introspects access tokens and enforces granted
authorization and local policy for protected resources. It does not validate client
assertions for an independent Authorization Server. See the
IHE IUA Resource Server
and Authorization
.
IUA requires this role to be grouped with a CT Time Client; see
required actor groupings
and the shared Time Synchronization
deployment guidance.
|
|
web
|
eur-lex.europa.eu
|
The EHDS Regulation initially defines six priority categories of electronic health data that all Member States must support first for cross-border primary use. These categories are explicitly listed in Article 14
of Regulation (EU) 2025/327.
|
|
web
|
eur-lex.europa.eu
|
Article 105
specifies the date when support for these priority categories is required: 26 March 2029 for categories (a), (b) and (c); 28 March 2031 for (d), (e) and (f).
|
|
web
|
eur-lex.europa.eu
|
The definitions of the priority categories comes from ANNEX I
of the EHDS Regulation.
|
|
web
|
profiles.ihe.net
|
IHE IUA
— Internet User Authorization
|
|
web
|
eur-lex.europa.eu
|
EHDS Regulation (EU) 2025/327
|
|
web
|
www.xt-ehr.eu
|
Xt-EHR Joint Action
|
|
web
|
profiles.ihe.net
|
IHE IUA
- Defines authorization and access control actors and mechanisms. Wether IUA is required depends on the environment and use case.
|
|
web
|
profiles.ihe.net
|
IHE Consistent Time
- Defines the use of Network Time Protocol (NTP) to provide consistent time across systems. See
SMART Server Time Synchronization
for this IG's recommendation for SMART server roles.
|
|
web
|
profiles.ihe.net
|
IHE ATNA
- Referenced for secure transport requirements (TLS 1.2 Floor using BCP195 Option).
|
|
web
|
profiles.ihe.net
|
Authentication and authorization are required by the EHDS. This IG applies SMART App Launch 2.2
and IHE IUA Revision 2.5
, as selected for each environment in The European Interoperability Landscape
. This page summarizes the EHDS evidence, compares the two specifications, selects a conformance target for each environment, and then defines the applicable actors, discovery, token, scope, and enforcement requirements. Potential hybrid rules remain future work.
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
The EHDS requires identification and authentication of natural persons and health professionals, proxy and representation services, security controls, and logging. The applicable enacted provisions are Article 4(2)-(3)
, Articles 12
, 16
, 30
, 36
, and 73
; Recitals 7
, 21
, and 112
; and Annex II section 3
. This factual summary is not legal advice, and several details remain subject to future implementing acts. A valid API token is not itself evidence of consent, a treatment relationship, patient identity, or entitlement beyond its granted scope and applicable local policy. Technical authentication and API authorization do not determine the applicable lawful basis under GDPR Article 6 or the applicable condition under Article 9(2).
|
|
web
|
eur-lex.europa.eu
|
Article 16
establishes electronic identification for access services and future interoperable cross-border mechanisms. Article 12
and Annex II section 3.1
address health-professional identification and authentication.
|
|
web
|
eur-lex.europa.eu
|
Article 16
establishes electronic identification for access services and future interoperable cross-border mechanisms. Article 12
and Annex II section 3.1
address health-professional identification and authentication.
|
|
web
|
eur-lex.europa.eu
|
Article 16
establishes electronic identification for access services and future interoperable cross-border mechanisms. Article 12
and Annex II section 3.1
address health-professional identification and authentication.
|
|
web
|
eur-lex.europa.eu
|
Recital 21
states that digital proxy solutions should align with European Digital Identity Wallet technical specifications. The Wallet is an electronic-identification means recognised under Article 6 of eIDAS
, on which Articles 12
and 16
rely; detailed cross-border alignment remains subject to Article 16 implementing acts.
|
|
web
|
eur-lex.europa.eu
|
Recital 21
states that digital proxy solutions should align with European Digital Identity Wallet technical specifications. The Wallet is an electronic-identification means recognised under Article 6 of eIDAS
, on which Articles 12
and 16
rely; detailed cross-border alignment remains subject to Article 16 implementing acts.
|
|
web
|
eur-lex.europa.eu
|
Recital 21
states that digital proxy solutions should align with European Digital Identity Wallet technical specifications. The Wallet is an electronic-identification means recognised under Article 6 of eIDAS
, on which Articles 12
and 16
rely; detailed cross-border alignment remains subject to Article 16 implementing acts.
|
|
web
|
eur-lex.europa.eu
|
Recital 21
states that digital proxy solutions should align with European Digital Identity Wallet technical specifications. The Wallet is an electronic-identification means recognised under Article 6 of eIDAS
, on which Articles 12
and 16
rely; detailed cross-border alignment remains subject to Article 16 implementing acts.
|
|
web
|
eur-lex.europa.eu
|
Article 4(2)-(3)
and Recital 21
require transparent proxy services and representation arrangements.
|
|
web
|
eur-lex.europa.eu
|
Article 4(2)-(3)
and Recital 21
require transparent proxy services and representation arrangements.
|
|
web
|
eur-lex.europa.eu
|
Article 30
, Article 36(3)(e)-(f)
, Recital 112
, and Annex II section 3
address security, confidentiality, integrity, and EHR security controls.
|
|
web
|
eur-lex.europa.eu
|
Article 30
, Article 36(3)(e)-(f)
, Recital 112
, and Annex II section 3
address security, confidentiality, integrity, and EHR security controls.
|
|
web
|
eur-lex.europa.eu
|
Article 30
, Article 36(3)(e)-(f)
, Recital 112
, and Annex II section 3
address security, confidentiality, integrity, and EHR security controls.
|
|
web
|
eur-lex.europa.eu
|
Article 30
, Article 36(3)(e)-(f)
, Recital 112
, and Annex II section 3
address security, confidentiality, integrity, and EHR security controls.
|
|
web
|
eur-lex.europa.eu
|
Annex II sections 3.2-3.3
require identified access-event logging and review tooling; Article 73(1)(e)
requires identifiable logs for secure secondary-use processing.
|
|
web
|
eur-lex.europa.eu
|
Annex II sections 3.2-3.3
require identified access-event logging and review tooling; Article 73(1)(e)
requires identifiable logs for secure secondary-use processing.
|
|
web
|
profiles.ihe.net
|
SMART and IUA both apply OAuth-based authorization to healthcare APIs, but neither is a subset of the other. SMART couples authorization discovery to the FHIR endpoint and supplies application-launch context and FHIR resource scopes. IUA
supports direct access and access through intermediaries using OAuth-based authorization. Its JWT option
profiles claims for user identity, clinical context, and consent-related information where applicable; other supported token options do not require JWT format. Cross-community use still requires agreed trust and authorization policy.
|
|
web
|
profiles.ihe.net
|
SMART and IUA both apply OAuth-based authorization to healthcare APIs, but neither is a subset of the other. SMART couples authorization discovery to the FHIR endpoint and supplies application-launch context and FHIR resource scopes. IUA
supports direct access and access through intermediaries using OAuth-based authorization. Its JWT option
profiles claims for user identity, clinical context, and consent-related information where applicable; other supported token options do not require JWT format. Cross-community use still requires agreed trust and authorization policy.
|
|
web
|
profiles.ihe.net
|
Claims and scopes are orthogonal. Scopes express requested or granted access to interactions;
claims convey identity or other context that an Authorization Server issues and a Resource Server
may use with the granted scope and local policy. A scope may itself be represented as a token claim,
but that does not make the concepts interchangeable. Core IUA defines no API-specific scope
vocabulary; the MHD integration
defines transaction scopes only for the corresponding MHD transactions grouped with IUA. Neither
contextual claims nor scopes alone establish consent or entitlement to every matching resource.
|
|
web
|
profiles.ihe.net
|
The Authentication Service MAY be grouped with the Authorization Server in one implementation,
or they may be separately deployed. In the latter case, their trust relationship and authentication
interface are deployment-defined, not an interoperable transaction specified by this IG. The
deployment must establish trusted authentication sources, intended recipients, freshness and replay
controls, applicable assurance, and mapping to local users and patients. Authentication alone
does not grant API access. The Authentication Service is IG-defined; using it does not transfer
the formal IUA Authorization Server
or SMART Authorization Server
conformance obligations.
|
|
web
|
openid.net
|
An OIDC ID token
describes an
authentication event for its intended client; it is not an API access token. A Wallet presentation
is likewise not an API access token. A deployment could separately profile
OAuth Token Exchange
, but neither this actor
separation nor Wallet support requires an app to exchange identity evidence for an API token.
Acceptance of such evidence, its audience, trust and authorization semantics would need a separate
profile; no such exchange is claimed here.
|
|
web
|
www.rfc-editor.org
|
An OIDC ID token
describes an
authentication event for its intended client; it is not an API access token. A Wallet presentation
is likewise not an API access token. A deployment could separately profile
OAuth Token Exchange
, but neither this actor
separation nor Wallet support requires an app to exchange identity evidence for an API token.
Acceptance of such evidence, its audience, trust and authorization semantics would need a separate
profile; no such exchange is claimed here.
|
|
web
|
profiles.ihe.net
|
IUA's grant discussion
also describes optional SAML and JWT assertion grants for federation. These are distinct from
RFC 8693 token exchange and from an OIDC ID token; accepting a particular assertion still requires
the deployment's trust and protocol agreements. This IG does not select one of those interfaces
for the Authentication Service.
|
|
web
|
eur-lex.europa.eu
|
The European Digital Identity Wallet
(under eIDAS) can work alongside a SMART authorization flow. The Authorization Server can use the Wallet as one way to authenticate the user, while SMART handles the application’s authorization to access health data.
|
|
web
|
eur-lex.europa.eu
|
Where the selected environment requires support for eIDAS-recognised electronic identification—for example, electronic health data access services under EHDS Article 16(1)
—the Authorization Server SHALL support authentication using those means, directly or through an identity provider. This applies to interactive
SMART or IUA authorization-code flows, not to a pre-authorized SMART Backend Service using
client_credentials
. The Authorization Server validates the authentication result, establishes
the user session, applies the applicable authorization policy, and issues a code or token only
after successful authorization.
|
|
web
|
openid.net
|
A deployment MAY use
OpenID for Verifiable Presentations 1.0
to obtain and validate a verifiable presentation from a Wallet, but this IG does not select a
presentation format, credential schema, or Wallet-to-Authorization-Server profile. The
applicable eIDAS assurance, health-professional status, and local authorization policy remain
separate from the OAuth grant and access-token scopes. Where an applicable rule or deployment
specifies an eID assurance level, eIDAS Article 8
and Commission Implementing Regulation (EU) 2015/1502
address assurance levels for electronic-identification schemes and means. The EHDS does not
select a universal assurance level for health API access, and an eID assurance level does not
itself authorize access to an API resource.
|
|
web
|
eur-lex.europa.eu
|
A deployment MAY use
OpenID for Verifiable Presentations 1.0
to obtain and validate a verifiable presentation from a Wallet, but this IG does not select a
presentation format, credential schema, or Wallet-to-Authorization-Server profile. The
applicable eIDAS assurance, health-professional status, and local authorization policy remain
separate from the OAuth grant and access-token scopes. Where an applicable rule or deployment
specifies an eID assurance level, eIDAS Article 8
and Commission Implementing Regulation (EU) 2015/1502
address assurance levels for electronic-identification schemes and means. The EHDS does not
select a universal assurance level for health API access, and an eID assurance level does not
itself authorize access to an API resource.
|
|
web
|
eur-lex.europa.eu
|
A deployment MAY use
OpenID for Verifiable Presentations 1.0
to obtain and validate a verifiable presentation from a Wallet, but this IG does not select a
presentation format, credential schema, or Wallet-to-Authorization-Server profile. The
applicable eIDAS assurance, health-professional status, and local authorization policy remain
separate from the OAuth grant and access-token scopes. Where an applicable rule or deployment
specifies an eID assurance level, eIDAS Article 8
and Commission Implementing Regulation (EU) 2015/1502
address assurance levels for electronic-identification schemes and means. The EHDS does not
select a universal assurance level for health API access, and an eID assurance level does not
itself authorize access to an API resource.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eudi.dev
|
The EUDI Wallet Architecture and Reference Framework (ARF) v3.0.0
is an informative guide to harmonised Wallet implementation, not a replacement
for binding eIDAS requirements ( §1.3
).
Its Annex 2 requirements apply to named actors, not Users
( A.2.1.1
,
A.2.1.2
).
For implementation guidance, see the reference architecture
,
presentation flows
,
OpenID4VP with HAIP
,
and trust model
.
|
|
web
|
eur-lex.europa.eu
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
eudi.dev
|
Under eIDAS, using the Wallet for user authentication is at the User's
voluntary request and limited to the minimum data necessary
;
this does not remove an applicable environment-conditioned identification
requirement. A service provider is a Wallet Relying Party when it requests
Wallet attributes; an Authorization Server is not automatically one. For
Relying Party registration and Wallet authentication, including request replay
protection, see ARF §6.4.2
for registration, and §6.6.3.2
with Annex 2 RPA_01
for Wallet authentication of the Relying Party and replay protection.
The Wallet authenticates its User and obtains approval before releasing
attributes ( §6.6.3.5
);
that approval is not a legal basis for processing
( §6.6.3.5.1
). If a Relying Party relies on
Wallet-side authentication to bind a presenter to a PID or device-bound
attestation, it verifies device binding; the ARF also describes other
user-binding methods
.
LoA High concerns PID authentication, not all attestations
( §2.2
).
|
|
web
|
profiles.ihe.net
|
MyHealth@EU:
authorization is outside the scope of this IG. Alignment with IHE IUA
is recommended.
|
|
web
|
profiles.ihe.net
|
National Interoperability Infrastructure:
established Member State infrastructure with
preconfigured participants. IHE IUA
is recommended where
user or patient claims
are needed.
|
|
web
|
profiles.ihe.net
|
National Interoperability Infrastructure:
established Member State infrastructure with
preconfigured participants. IHE IUA
is recommended where
user or patient claims
are needed.
|
|
web
|
profiles.ihe.net
|
Authorization for MyHealth@EU is outside the scope of this IG. Deployments should align with
IHE IUA
.
|
|
web
|
profiles.ihe.net
|
For preconfigured system-to-system endpoints in the national infrastructure,
IHE IUA
is RECOMMENDED where national policy requires
IUA transaction integration or its JWT Token Option
.
This recommendation is limited to those endpoints; it does not require every endpoint in the
National Interoperability Infrastructure to use IUA. A system-to-system endpoint MAY instead use
SMART Backend Services
when all of its applicability conditions are met. The deployment selects one profile per
Resource Server endpoint; distinct endpoints may select different profiles, but this IG does not
define dual conformance on one endpoint.
|
|
web
|
profiles.ihe.net
|
For preconfigured system-to-system endpoints in the national infrastructure,
IHE IUA
is RECOMMENDED where national policy requires
IUA transaction integration or its JWT Token Option
.
This recommendation is limited to those endpoints; it does not require every endpoint in the
National Interoperability Infrastructure to use IUA. A system-to-system endpoint MAY instead use
SMART Backend Services
when all of its applicability conditions are met. The deployment selects one profile per
Resource Server endpoint; distinct endpoints may select different profiles, but this IG does not
define dual conformance on one endpoint.
|
|
web
|
profiles.ihe.net
|
For endpoints selecting IUA, use the applicable IUA actors
and metadata. Add IUA MHD transaction scopes
only for supported ITI-65 through ITI-68 transactions whose MHD actors are grouped with IUA.
Core IUA defines no API-specific scope vocabulary, and ITI-105 has no IUA-defined transaction
scope. SMART endpoints use the applicable SMART FHIR resource scopes instead.
|
|
web
|
profiles.ihe.net
|
For endpoints selecting IUA, use the applicable IUA actors
and metadata. Add IUA MHD transaction scopes
only for supported ITI-65 through ITI-68 transactions whose MHD actors are grouped with IUA.
Core IUA defines no API-specific scope vocabulary, and ITI-105 has no IUA-defined transaction
scope. SMART endpoints use the applicable SMART FHIR resource scopes instead.
|
|
web
|
profiles.ihe.net
|
Environment and flow are separate dimensions. "Application-guided authentication" is not an
alternative to patient or clinician access: either user type may authenticate through an app-guided
flow, and IUA supports interactive access
as well as system-to-system exchange. The existing environment selections above remain applicable.
|
|
web
|
profiles.ihe.net
|
For both interactive SMART App Launch and SMART Backend Services, this IG recommends ( SHOULD
)
that SMART Authorization Server and SMART FHIR Resource Server actors be grouped with the
IHE Consistent Time (CT) Time Client
. This is
an additional IG-level recommendation; SMART App Launch does not itself require CT. It applies to
the two server roles, not to SMART Apps or SMART Backend Services solely by virtue of their client
roles.
|
|
web
|
profiles.ihe.net
|
The IUA roles used by this IG are IUA Authorization Client
, IUA Authorization Server
, and IUA Resource Server
. IUA mode uses the applicable Authorization Client
, Authorization Server
, and Resource Server
requirements. Core IUA requirements are separate from this IG's MHD transaction integration and from the additional recommendations here.
|
|
web
|
profiles.ihe.net
|
The IUA roles used by this IG are IUA Authorization Client
, IUA Authorization Server
, and IUA Resource Server
. IUA mode uses the applicable Authorization Client
, Authorization Server
, and Resource Server
requirements. Core IUA requirements are separate from this IG's MHD transaction integration and from the additional recommendations here.
|
|
web
|
profiles.ihe.net
|
The IUA roles used by this IG are IUA Authorization Client
, IUA Authorization Server
, and IUA Resource Server
. IUA mode uses the applicable Authorization Client
, Authorization Server
, and Resource Server
requirements. Core IUA requirements are separate from this IG's MHD transaction integration and from the additional recommendations here.
|
|
web
|
profiles.ihe.net
|
IHE IUA Revision 2.5
requires
its
Authorization Server and Resource Server actors to be grouped with a CT/Time Client. This IUA
requirement is distinct from the additional SMART-specific SHOULD
recommendation above.
See Time Synchronization
for shared NTP deployment guidance.
|
|
web
|
profiles.ihe.net
|
The IHE Consistent Time (CT) profile
specifies NTP synchronization and references NTPv3. As informative deployment guidance for both
SMART and IUA server roles, deployments are encouraged to use NTPv4 for time synchronization,
while satisfying the applicable IHE CT requirements.
NTPv4 is backward compatible with NTPv3
;
interoperability with the selected time service should be verified.
|
|
web
|
www.rfc-editor.org
|
The IHE Consistent Time (CT) profile
specifies NTP synchronization and references NTPv3. As informative deployment guidance for both
SMART and IUA server roles, deployments are encouraged to use NTPv4 for time synchronization,
while satisfying the applicable IHE CT requirements.
NTPv4 is backward compatible with NTPv3
;
interoperability with the selected time service should be verified.
|
|
web
|
profiles.ihe.net
|
All token and protected-resource exchanges SHALL use TLS 1.2 or later. Access tokens are short-lived bearer tokens; they need not be JWTs unless the selected IUA option requires JWT format. A Resource Server MAY use IUA ITI-102 token introspection
where selected.
|
|
web
|
profiles.ihe.net
|
Protected-resource error responses follow the selected authorization specification. IUA token verification, scope matching, and access-policy failures return 401 Unauthorized
as specified in ITI-72
. SMART requests may return 403 Forbidden
when access is denied by underlying permissions, as described in SMART scopes
. A deployment MAY use 404 Not Found
to conceal resource existence only where permitted by the selected specification and when it documents that policy consistently. Consent and audit remain separate responsibilities.
|
|
web
|
profiles.ihe.net
|
Where IUA is selected, the established deployment preconfigures the Authorization Server and
the client applies the selected IUA metadata and transaction requirements. A CapabilityStatement
does not replace either SMART or IUA metadata. See SMART conformance
and IHE IUA ITI-103
.
|
|
web
|
profiles.ihe.net
|
IHE Document Sharing
distinguishes type
(specific document types, typically LOINC codes) from category
(broad classification) on DocumentReference. This IG constrains type
for document discovery but leaves the category
vocabulary to content IGs
and implementations. Providers still support the category
search parameter.
|
|
web
|
eur-lex.europa.eu
|
Article 14
of the EHDS regulation defines six priority categories of electronic health data. EEHRxFDocumentPriorityCategoryCS
provides informative codes for these categories, organizing them by the LOINC type
codes consumers use for document search.
|
|
web
|
hl7.eu
|
Europe Laboratory Report
|
|
web
|
profiles.ihe.net
|
IHE Document Sharing
|
|
web
|
profiles.ihe.net
|
SMART Backend Services
or IHE IUA
authorization sequence
|
|
web
|
eur-lex.europa.eu
|
This page provides informative
guidance for how EHR systems supporting the Interoperability Component fit into the European interoperability landscape and can support
different actors in meeting their EHDS obligations. While EHDS does not dictate interoperability implementation details at the Member State or healthcare organization level, Member States and healthcare organizations can deploy these capabilities within their existing domains to support EHDS implementation. For example, the Member State obligation to connect all healthcare providers to their MyHealth@EU national contact point for eHealth (NCPeH, shortened to NCP in this guide) ( Art. 23(5)
) can be supported by a healthcare provider deploying an EHR system as a Document Access Provider
to make the organization's priority-category data available to the NCP, which retrieves it by acting as a Document Consumer
.
|
|
web
|
eur-lex.europa.eu
|
MyHealth@EU and National Contact Points (NCPs):
Member States must operate NCPs that connect to the MyHealth@EU central platform ( Art. 23(2)
) and must ensure healthcare providers are connected to that infrastructure ( Art. 23(5)
). NCP-to-NCP exchange is governed by the NCPeH API specification
, not by this IG.
|
|
web
|
build-fhir.ehdsi.eu
|
MyHealth@EU and National Contact Points (NCPs):
Member States must operate NCPs that connect to the MyHealth@EU central platform ( Art. 23(2)
) and must ensure healthcare providers are connected to that infrastructure ( Art. 23(5)
). NCP-to-NCP exchange is governed by the NCPeH API specification
, not by this IG.
|
|
web
|
eur-lex.europa.eu
|
Health data access service (HDAS):
Member States must operate a patient-facing health data access service ( Art. 4
). For the purposes of this Implementation Guide, this is modeled primarily as a user-facing interface that can act as a consumer of the Interoperability Component API surface; its service requirements are not specified here.
|
|
web
|
eur-lex.europa.eu
|
Health professional access service (HPAS):
Member States must operate a health professional access service ( Art. 12
). For the purposes of this Implementation Guide, this is modeled primarily as a user-facing service that can act as a consumer of the Interoperability Component API surface; its service requirements are not specified here.
|
|
web
|
eur-lex.europa.eu
|
Healthcare providers:
Healthcare providers deploy one or more EHR systems to support care delivery, including EHR systems which support internal
clinical workflows within an organization as well as EHR systems which support cross-organization
exchange with national infrastructure, for example to meet the member state requirement Art. 23(5)
to connect their data to the national NCP for cross-border exchange. This environment holds the following system actors:
|
|
web
|
eur-lex.europa.eu
|
EHR systems
: EHR systems must conform to the Interoperability Component implemented in this IG. Art. 25(1)
requires EHR systems to include the European interoperability software component; Annex II §2.1–2.4
requires that component to provide and receive priority-category data in EEHRxF format. An EHR system may expose the API surface directly, or the capability may be delivered by an associated gateway or facade treated as part of the deployed EHR (
EHR System Composition Patterns
).
|
|
web
|
eur-lex.europa.eu
|
EHR systems
: EHR systems must conform to the Interoperability Component implemented in this IG. Art. 25(1)
requires EHR systems to include the European interoperability software component; Annex II §2.1–2.4
requires that component to provide and receive priority-category data in EEHRxF format. An EHR system may expose the API surface directly, or the capability may be delivered by an associated gateway or facade treated as part of the deployed EHR (
EHR System Composition Patterns
).
|
|
web
|
eur-lex.europa.eu
|
Wellness applications:
A wellness application is software, or a combination of hardware and software, intended for use by a natural person to process electronic health data for information on a person's health or for the delivery of care for purposes other than the provision of healthcare ( Art. 2(2)(ab)
). A wellness application may claim interoperability with an EHR system ( Art. 47-48
) by implementing the applicable Interoperability Component functionality. It may also be the mechanism by which the patient exercises their ( Art. 5
) right to insert data into their own EHR through electronic health data access services or applications linked to those services
. Article 48 frames wellness-app interoperability as patient-controlled sharing or transmission of data from the wellness application to the EHR - a wellness application may therefore exchange EEHRxF data through the health data access service, or via an EHR system directly depending on the needs of the implementation. This IG models that exchange using the same Interoperability Component transactions described here.
|
|
web
|
eur-lex.europa.eu
|
Wellness applications:
A wellness application is software, or a combination of hardware and software, intended for use by a natural person to process electronic health data for information on a person's health or for the delivery of care for purposes other than the provision of healthcare ( Art. 2(2)(ab)
). A wellness application may claim interoperability with an EHR system ( Art. 47-48
) by implementing the applicable Interoperability Component functionality. It may also be the mechanism by which the patient exercises their ( Art. 5
) right to insert data into their own EHR through electronic health data access services or applications linked to those services
. Article 48 frames wellness-app interoperability as patient-controlled sharing or transmission of data from the wellness application to the EHR - a wellness application may therefore exchange EEHRxF data through the health data access service, or via an EHR system directly depending on the needs of the implementation. This IG models that exchange using the same Interoperability Component transactions described here.
|
|
web
|
eur-lex.europa.eu
|
Wellness applications:
A wellness application is software, or a combination of hardware and software, intended for use by a natural person to process electronic health data for information on a person's health or for the delivery of care for purposes other than the provision of healthcare ( Art. 2(2)(ab)
). A wellness application may claim interoperability with an EHR system ( Art. 47-48
) by implementing the applicable Interoperability Component functionality. It may also be the mechanism by which the patient exercises their ( Art. 5
) right to insert data into their own EHR through electronic health data access services or applications linked to those services
. Article 48 frames wellness-app interoperability as patient-controlled sharing or transmission of data from the wellness application to the EHR - a wellness application may therefore exchange EEHRxF data through the health data access service, or via an EHR system directly depending on the needs of the implementation. This IG models that exchange using the same Interoperability Component transactions described here.
|
|
web
|
eur-lex.europa.eu
|
EHDS Annex II §2.1
: "SHALL provide an interface enabling access
to the personal electronic health data [formatted in EEHRxF]"
|
|
web
|
eur-lex.europa.eu
|
EHDS Annex II §2.2
: "SHALL be able to receive
personal electronic health data [formatted in EEHRxF]"
|
|
web
|
www.rfc-editor.org
|
The uppercase key words in this IG have the meanings defined in RFC 2119
,
as clarified by RFC 8174
(BCP 14). These meanings apply only when
the keywords appear in uppercase.
|
|
web
|
www.rfc-editor.org
|
The uppercase key words in this IG have the meanings defined in RFC 2119
,
as clarified by RFC 8174
(BCP 14). These meanings apply only when
the keywords appear in uppercase.
|
|
web
|
profiles.ihe.net
|
IHE IUA
- Defines authorization and access control actors and mechanisms. Aligned with SMART. We use the actors and transactions model from this specification.
|
|
web
|
hl7.eu
|
HL7 Europe Laboratory Report
|
|
web
|
hl7.eu
|
HL7 Europe Hospital Discharge Report
|
|
web
|
hl7.eu
|
HL7 Europe Imaging Study/Report
/ Imaging Manifest
|
|
web
|
eur-lex.europa.eu
|
This page is informative
. This Implementation Guide specifies interoperability
for API interactions. It does not define an EHR logging format, a common audit
service, or an exchange mechanism for audit records between systems.
EHDS Annex II sections 3.2-3.3
include local logging and review requirements for EHR systems; the applicable
requirements and their implementation are determined by the regulation and
relevant deployment policy. This page is explanatory and does not add conformance
requirements to this Implementation Guide. See Regulatory Anchors
for the scope of this guide.
|
|
web
|
www.rfc-editor.org
|
Deployments may use syslog
,
IHE ATNA
, or
IHE BALP
, as appropriate to their
logging needs. This informative guidance does not mandate a particular logging
technology or profile.
|
|
web
|
profiles.ihe.net
|
Deployments may use syslog
,
IHE ATNA
, or
IHE BALP
, as appropriate to their
logging needs. This informative guidance does not mandate a particular logging
technology or profile.
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
github.com
|
GitHub Issue
|
|
web
|
github.com
|
GitHub Issue
| Priority:
Medium
|
|
web
|
fhir.ehdsi.eu
|
The main difference between the two guides is that the EU Health Data API IG describes ways to find patient records based on different parameters whereas the MyHealth@EU uses the patient search transaction for validation of the patient identity
that was acquired via different means (e.g. EUDI Wallet).
|
|
web
|
fhir.ehdsi.eu
|
Nevertheless, the EU Health Data API implementation guide is aligned as much as possible with the corresponding patient search transaction
from the MyHealth@EU cross-border specification. This includes conformance language and the requirements for search parameters.
Whether identifiers and/or demographic data of a patient are used as search parameters depends on the agreed identification attributes for a patient of each member state for the cross-border scenario.
|
|
web
|
hl7.eu
|
The Patient Resource in the input parameter resource
SHOULD comply to the EU Base Profile for Patient
, which also enables the use of Extensions for demographic data like birthPlace
or citizenship
defined in this profile as search input.
|
|
web
|
fhir.ehdsi.eu
|
In most European exchanges the consumer already holds a trusted patient identifier (national health ID, MRN, or similar). Identifier-based lookup produces an unambiguous match and avoids dependence on demographic data quality, which varies in completeness and localization across member states. The MyHealth@EU cross-border infrastructure
already follows this pattern and makes use of the patient search transcation.
|
|
web
|
hl7.eu
|
This section defines the API requirements for EHR systems that provide EEHRxF data that conforms to the HL7 EU Hospital Discharge Report
content profile.
|
|
web
|
hl7.eu
|
For detailed content profiles, see the EU Imaging Study Manifest IG
.
|
|
web
|
hl7.eu
|
The EURIDICE MADO profile
defines both a FHIR encoding and a DICOM KOS encoding for imaging manifests. When a system supports both representations, it publishes two DocumentReference resources
linked via relatesTo
:
|
|
web
|
github.com
|
This pattern was chosen ( #50
) because it works across all Document Sharing transports (MHD, XDS, XCA) without requiring content negotiation at the server.
|
|
web
|
euridice.org
|
Feedback requested on the dual-DocumentReference pattern.
The MADO profile
dual-encodes imaging manifests in both FHIR and DICOM representations. This IG uses two DocumentReferences linked via relatesTo.transforms
so that consumers can select the encoding they support based on contentType
. This pattern was chosen for compatibility with document sharing infrastructures (MHD, XDS, XCA), where each document entry carries exactly one format.
|
|
web
|
github.com
|
Implementers: does the dual-DocumentReference pattern work for your imaging infrastructure and content negotiation needs? Would a single-DocumentReference model be preferable? Feedback is welcome via Issue #50
.
|
|
web
|
hl7.eu
|
The content is defined by the HL7 EU Medication Prescription and Dispense
profile.
|
|
web
|
hl7.eu
|
HL7 Europe Laboratory Report
|
|
web
|
eur-lex.europa.eu
|
The regulatory basis is primarily found in EHDS ANNEX II - Essential Requirements for EHR Systems ( EUR-Lex
), which describes an obligation for EHR systems to include an Interoperability Component
that does the following:
|
|
web
|
www.xt-ehr.eu
|
For more details on the Xt-EHR work, see the Xt-EHR Website
. The Xt-EHR deliverables, including D5.1, D5.2, and D8.1, are available on the Xt-EHR deliverables page
.
|
|
web
|
www.xt-ehr.eu
|
For more details on the Xt-EHR work, see the Xt-EHR Website
. The Xt-EHR deliverables, including D5.1, D5.2, and D8.1, are available on the Xt-EHR deliverables page
.
|
|
web
|
profiles.ihe.net
|
[Out of Scope] 6 Logging Component Requirements:
This Implementation Guide does not specify the logging component format or the interoperability of logs from EHR systems. EHDS ANNEX II requires the generation of local audit logs for review, but does not specify the data format or require interoperability of those logs. Implementers needing standardized audit logging should consider IHE ATNA
and IHE BALP
(Basic Audit Log Patterns), which define FHIR AuditEvent-based audit log profiles. The IHE profiles used in this IG (MHD, PDQm, IUA) recommend but do not require ATNA grouping.
|
|
web
|
eur-lex.europa.eu
|
The Access Provider
actors ( Document Access Provider
, Resource Access Provider
) satisfy EHDS Annex II §2.1
by serving Document and Resource FHIR queries.
|
|
web
|
eur-lex.europa.eu
|
Alternatively, this IG proposes a path for EHR systems to delegate their EHDS Annex II §2.1
obligations to another system.
|
|
web
|
eur-lex.europa.eu
|
The Consumer
actors ( Document Consumer
, Resource Consumer
) satisfy EHDS Annex II §2.2
by initiating Document and Resource queries to retrieve and receive data from Access Providers.
|
|
web
|
eur-lex.europa.eu
|
Systems that need to accept documents pushed from Publishers (e.g., national infrastructure, regional repositories, integration engines) may implement the
Document Submission Option
on the Document Access Provider actor. This is an additional
capability for systems acting as aggregation points—it is not required to satisfy EHDS Annex II §2.2
.
|
|
web
|
www.xt-ehr.eu
|
Note: D8.1
is published on the Xt-EHR deliverables page. This section summarizes the concepts this IG builds upon.
|
|
web
|
profiles.ihe.net
|
IHE-QEDm
- Search parameters for resources not covered by IPA (e.g., DiagnosticReport, Encounter)
|
|
web
|
hl7.eu
|
Data type-specific implementation guides MAY extend the required search patterns and search parameters for the resources in their domain. For example, the MADO
implementation guide may define additional search requirements for ImagingStudy and DiagnosticReport in the Imaging Results priority category.
|
|
web
|
profiles.ihe.net
|
In the regulatory context of EHDS, the following resources represent individual data entries included in the priority data categories, so should be made available for read/search access if the system claims support for the corresponding priority data category. Data models inherit from HL7 Europe Core
. Required search parameters are from HL7 International Patient Access (IPA)
version 1.1.0, supplemented by IHE-QEDm
where IPA does not define them.
|
|
web
|
hl7.eu
|
Data model: Patient (EU Core)
|
|
web
|
hl7.eu
|
Data model: Practitioner (EU Core)
|
|
web
|
hl7.eu
|
Data model: Organization (EU Core)
|
|
web
|
hl7.eu
|
Data model: Condition (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: Condition
and QEDm 2:3.44
. Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource.
|
|
web
|
hl7.eu
|
Data model: AllergyIntolerance (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: AllergyIntolerance
and QEDm 2:3.44
. Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource.
|
|
web
|
hl7.eu
|
Data model: MedicationRequest (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: MedicationRequest
and QEDm 2:3.44
. Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource.
|
|
web
|
hl7.eu
|
Data model: MedicationStatement (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: MedicationStatement
and QEDm 2:3.44
. Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource.
|
|
web
|
hl7.eu
|
Data model: Immunization (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: Immunization
and QEDm 2:3.44
. Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource.
|
|
web
|
hl7.eu
|
Data model: Not included in EU Core. Refer to MedicationDispense: MPD
|
|
web
|
hl7.eu
|
Data model: Observation: Medical Test Result (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at IPA CapabilityStatement: Observation
and QEDm 2:3.44
. Resource access providers are required to support Search requests that include both patient and category, both patient and code, all of patient, category, and code, or all of patient, category, and date.
|
|
web
|
hl7.eu
|
Data model: DiagnosticReport (EU Core)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described at QEDm 2:3.44
(not included in IPA). Resource Access Providers are required to support searching by patient and category, all of patient, category, and code, or all of patient, category, and date. For imaging reports, the MADO
implementation guide may define additional search requirements.
|
|
web
|
hl7.eu
|
Search parameters: As described at QEDm 2:3.44
(not included in IPA). Resource Access Providers are required to support searching by patient and category, all of patient, category, and code, or all of patient, category, and date. For imaging reports, the MADO
implementation guide may define additional search requirements.
|
|
web
|
hl7.eu
|
Data model: Not included in EU Core. Refer to ImagingStudy: General
from HL7 Europe Imaging Report
|
|
web
|
hl7.eu
|
Search parameters: Not included in IPA or QEDm. As this is a patient-scoped resource, Resource Access Providers are required to support searching by patient, as long as the Resource Consumer provides at least an id value for the Patient resource. The MADO
implementation guide may define additional search requirements.
|
|
web
|
hl7.eu
|
Data model: Not included in EU Core. Refer to Encounter (HDR)
|
|
web
|
profiles.ihe.net
|
Search parameters: As described in QEDm 2:3.44
. Resource Access Providers are required to support searching by patient or patient and date.
|
|
web
|
profiles.ihe.net
|
The IHE mXDE
profile is an informative reference for extracting resources from documents while maintaining provenance. This IG does not require conformance to mXDE.
|
|
web
|
profiles.ihe.net
|
IHE mXDE
(informative)
|
|
web
|
eur-lex.europa.eu
|
Cross-border health-data exchange routes through National Contact Points for eHealth (NCPeHs), called NCPs below, over the MyHealth@EU infrastructure ( Art. 23(2)
). When a patient from Country A receives care in Country B, the requesting EHR in Country B queries its national infrastructure. The request passes through the two countries' NCPs to Country A's national infrastructure, which obtains the data from the holding EHR and returns it along the chain.
|
|
web
|
fhir.ehdsi.eu
|
NCP-to-NCP exchange follows the NCPeH API specification
. Interfaces within national infrastructure are defined by Member States.
|
|
web
|
profiles.ihe.net
|
The final infrastructure-to-EHR hop is separate from NCP-to-NCP exchange. For MyHealth@EU, authorization remains outside this IG; Authorization
recommends alignment with IHE IUA
. This use case does not select an authorization flow for MyHealth@EU; applicable MyHealth@EU and deployment requirements govern its participants and prerequisites. For a separate National Interoperability Infrastructure hop, IHE IUA
is recommended only under the conditions in Authorization
. If selected, the generic roles are realized by the IHE IUA Authorization Client
, IHE IUA Resource Server
, and a distinct IHE IUA Authorization Server
; the client obtains a token with ITI-71
and presents it with ITI-72
. Any MHD transaction scope depends on the supported interaction and deployment. This use case does not select an IUA transaction or flow for a particular endpoint. The NCPeH API remains the specification for NCP-to-NCP exchange.
Cross-border patient consent, health-professional authentication in the requesting country, and authorization at the NCP and national-infrastructure layers are governed by MyHealth@EU and Member State infrastructure. At the EHR-facing API boundaries, the consumer is an authorized EHR system or national-infrastructure component; how that authorization was established is outside the scope of this example.
|
|
web
|
profiles.ihe.net
|
The final infrastructure-to-EHR hop is separate from NCP-to-NCP exchange. For MyHealth@EU, authorization remains outside this IG; Authorization
recommends alignment with IHE IUA
. This use case does not select an authorization flow for MyHealth@EU; applicable MyHealth@EU and deployment requirements govern its participants and prerequisites. For a separate National Interoperability Infrastructure hop, IHE IUA
is recommended only under the conditions in Authorization
. If selected, the generic roles are realized by the IHE IUA Authorization Client
, IHE IUA Resource Server
, and a distinct IHE IUA Authorization Server
; the client obtains a token with ITI-71
and presents it with ITI-72
. Any MHD transaction scope depends on the supported interaction and deployment. This use case does not select an IUA transaction or flow for a particular endpoint. The NCPeH API remains the specification for NCP-to-NCP exchange.
Cross-border patient consent, health-professional authentication in the requesting country, and authorization at the NCP and national-infrastructure layers are governed by MyHealth@EU and Member State infrastructure. At the EHR-facing API boundaries, the consumer is an authorized EHR system or national-infrastructure component; how that authorization was established is outside the scope of this example.
|
|
web
|
profiles.ihe.net
|
The final infrastructure-to-EHR hop is separate from NCP-to-NCP exchange. For MyHealth@EU, authorization remains outside this IG; Authorization
recommends alignment with IHE IUA
. This use case does not select an authorization flow for MyHealth@EU; applicable MyHealth@EU and deployment requirements govern its participants and prerequisites. For a separate National Interoperability Infrastructure hop, IHE IUA
is recommended only under the conditions in Authorization
. If selected, the generic roles are realized by the IHE IUA Authorization Client
, IHE IUA Resource Server
, and a distinct IHE IUA Authorization Server
; the client obtains a token with ITI-71
and presents it with ITI-72
. Any MHD transaction scope depends on the supported interaction and deployment. This use case does not select an IUA transaction or flow for a particular endpoint. The NCPeH API remains the specification for NCP-to-NCP exchange.
Cross-border patient consent, health-professional authentication in the requesting country, and authorization at the NCP and national-infrastructure layers are governed by MyHealth@EU and Member State infrastructure. At the EHR-facing API boundaries, the consumer is an authorized EHR system or national-infrastructure component; how that authorization was established is outside the scope of this example.
|
|
web
|
profiles.ihe.net
|
For the National Interoperability Infrastructure environment, Authorization
recommends IHE IUA
when participants and the Authorization Server are preconfigured and user or patient claims are needed. The consumer is the Health Data API Authorization Client
, the protected EHR or repository endpoint is the Health Data API Resource Server
, and the Health Data API Authorization Server
is distinct.
|
|
web
|
profiles.ihe.net
|
When a deployment selects IUA, these roles are realized by the IHE IUA Authorization Client
, IHE IUA Resource Server
, and IHE IUA Authorization Server
. The client obtains a token with ITI-71
and presents it to the protected endpoint using ITI-72
. Any MHD transaction scope depends on the supported interaction and deployment, as described in Authorization
. A direct-system endpoint may instead select SMART Backend Services
only when the client is pre-authorized, uses asymmetric client authentication, and has no runtime end-user authorization. That flow uses a SMART Backend Service
, the distinct SMART Authorization Server
, and a SMART FHIR Resource Server
, with applicable system/
scopes. See Authorization
for the normative profile requirements. It is a separate endpoint profile and does not imply dual conformance.
|
|
web
|
profiles.ihe.net
|
When a deployment selects IUA, these roles are realized by the IHE IUA Authorization Client
, IHE IUA Resource Server
, and IHE IUA Authorization Server
. The client obtains a token with ITI-71
and presents it to the protected endpoint using ITI-72
. Any MHD transaction scope depends on the supported interaction and deployment, as described in Authorization
. A direct-system endpoint may instead select SMART Backend Services
only when the client is pre-authorized, uses asymmetric client authentication, and has no runtime end-user authorization. That flow uses a SMART Backend Service
, the distinct SMART Authorization Server
, and a SMART FHIR Resource Server
, with applicable system/
scopes. See Authorization
for the normative profile requirements. It is a separate endpoint profile and does not imply dual conformance.
|
|
web
|
eur-lex.europa.eu
|
A Health Data Access Service
( Art. 4
) is provided by a Member State to natural persons or their representatives for accessing their health data. The service can be delivered as a web portal, an API, or other means. It authenticates the patient and accesses data from EHR systems on the patient's behalf. The infrastructure behind these services is country-specific — see Member State Architectures
.
|
|
web
|
profiles.ihe.net
|
For a MyHealth@EU hop, authorization remains outside this IG; deployment guidance recommends
alignment with IHE IUA
, as described in
Authorization
.
|
|
web
|
profiles.ihe.net
|
For a National Interoperability Infrastructure hop, IHE IUA
is recommended when participants
and the Authorization Server are preconfigured and user or patient claims are needed. When
selected, the generic roles map to the IHE IUA Authorization Client
,
IHE IUA Resource Server
, and
IHE IUA Authorization Server
; the
deployment selects applicable transactions and MHD scopes. The client obtains a token with
ITI-71
and presents it to the protected
endpoint with ITI-72
; any MHD transaction
scope is limited to the supported interaction, as described in
Authorization
.
|
|
web
|
profiles.ihe.net
|
For a National Interoperability Infrastructure hop, IHE IUA
is recommended when participants
and the Authorization Server are preconfigured and user or patient claims are needed. When
selected, the generic roles map to the IHE IUA Authorization Client
,
IHE IUA Resource Server
, and
IHE IUA Authorization Server
; the
deployment selects applicable transactions and MHD scopes. The client obtains a token with
ITI-71
and presents it to the protected
endpoint with ITI-72
; any MHD transaction
scope is limited to the supported interaction, as described in
Authorization
.
|
|
web
|
profiles.ihe.net
|
For a National Interoperability Infrastructure hop, IHE IUA
is recommended when participants
and the Authorization Server are preconfigured and user or patient claims are needed. When
selected, the generic roles map to the IHE IUA Authorization Client
,
IHE IUA Resource Server
, and
IHE IUA Authorization Server
; the
deployment selects applicable transactions and MHD scopes. The client obtains a token with
ITI-71
and presents it to the protected
endpoint with ITI-72
; any MHD transaction
scope is limited to the supported interaction, as described in
Authorization
.
|
|
web
|
eur-lex.europa.eu
|
A Health Professional Access Service
( Art. 12
) is provided by a Member State to health professionals for accessing their patients' health data. The service can be delivered as a web portal, an API, or other means. It authenticates the professional, locates the patient, and accesses data from EHR systems. The infrastructure behind these services is country-specific — see Member State Architectures
.
|
|
web
|
profiles.ihe.net
|
The service may reach EHRs directly or through national infrastructure, so its title does not by itself determine the authorization environment. For a Healthcare Provider hop, an interactive clinician request maps to SMART App Launch
: the client is a SMART App
, the protected endpoint a SMART FHIR Resource Server
, and the SMART Authorization Server
is distinct. A SMART Launching System
participates for EHR Launch. Identify the target FHIR base and registered app, then use the endpoint's SMART discovery metadata
and how the app is started to select Clinician Access for EHR Launch or Clinician Access for Standalone. Interactive access uses authorization code with PKCE as described in Authorization
. A server-side request maps to a SMART Backend Service
only when access is pre-authorized, the client uses asymmetric confidential-client authentication, and no runtime end-user authorization is required. For a National Interoperability Infrastructure hop, IHE IUA
is recommended only under the conditions in Authorization
; when selected, the generic roles map to the IHE IUA Authorization Client
, IHE IUA Resource Server
, and IHE IUA Authorization Server
. The actual environment and flow remain deployment-dependent. See Authorization
for the normative requirements and protocol roles.
|
|
web
|
profiles.ihe.net
|
For the server-side flow, see the SMART Backend Services profile
and its requirements in Authorization
. When an NII endpoint selects IUA, the client obtains a token with ITI-71
and presents it with ITI-72
; MHD transaction scopes depend on the supported interaction and are described in Authorization
.
|
|
web
|
profiles.ihe.net
|
For the server-side flow, see the SMART Backend Services profile
and its requirements in Authorization
. When an NII endpoint selects IUA, the client obtains a token with ITI-71
and presents it with ITI-72
; MHD transaction scopes depend on the supported interaction and are described in Authorization
.
|
|
web
|
eur-lex.europa.eu
|
A wellness application is software, or a combination of hardware and software, intended for use by a natural person to process electronic health data for information on a person's health or for the delivery of care for purposes other than the provision of healthcare ( Art. 2(2)(ab)
).
|
|
web
|
eur-lex.europa.eu
|
Under EHDS, wellness application interoperability is not a separate API defined by this IG. A wellness application may claim interoperability with an EHR system only when the relevant common specifications and Annex II requirements are met ( Art. 47-48
). Article 48 limits sharing or transmission of data from the wellness application to the patient's Article 5 right to insert information into their EHR, with patient consent and control over the categories and circumstances of sharing.
|
