Unattributed Code Systems

Copyright Fragment

This fragment is available on en/copyright.html

This publication includes IP covered under the following statements.

Copyright and Registered Trademark Uses

External References

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 github.com EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.0 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.eu-health-data-api#0.1.0 based on FHIR 4.0.1 . Generated 2026-02-06
web profiles.ihe.net IUA Authorization Server
web profiles.ihe.net IUA Resource Server
web profiles.ihe.net IUA Authorization Client
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 - Defines authorization and access control actors and mechanisms. We use the actors and transactions model.
web profiles.ihe.net IHE Consistent Time - Defines the use of Network Time Protocol (NTP) to provide consistent time across systems.
web profiles.ihe.net IHE ATNA - Referenced for secure transport requirements. See the TLS 1.2 Floor Option for TLS requirements.
web profiles.ihe.net IHE ATNA - Referenced for secure transport requirements. See the TLS 1.2 Floor Option for TLS requirements.
web profiles.ihe.net IUA Resource Server - Required
web profiles.ihe.net IUA Authorization Server - Required if authorization is handled internally; not required if using external authorization infrastructure. See Authorization Server Deployment .
web profiles.ihe.net Authorization Server
web profiles.ihe.net Resource Server
web profiles.ihe.net Authorization Client
web profiles.ihe.net In deployments using an external Authorization Server, token validation commonly involves coordination with that Authorization Server; where supported and required by policy, Resource Servers MAY use token introspection via IHE IUA ITI-102 .
web profiles.ihe.net All API communications SHALL use secure transport as defined by IHE ATNA Secure Node with the TLS 1.2 Floor Option .
web profiles.ihe.net All API communications SHALL use secure transport as defined by IHE ATNA Secure Node with the TLS 1.2 Floor Option .
web profiles.ihe.net This IG uses IHE IUA for actor definitions and groups those actors with SMART Backend Services behavior. IUA itself notes its relationship to SMART-on-FHIR : "IUA is not based on SMART-on-FHIR, but does strive to not conflict with that standard."
web profiles.ihe.net IHE IUA
web profiles.ihe.net This IG follows the IHE Document Sharing approach:
web eur-lex.europa.eu The EHDS priority categories are defined by Article 14 of the EHDS Regulation . We define codes specifically for EEHRxF that map directly to these regulatory categories.
web profiles.ihe.net IHE Document Sharing
web eur-lex.europa.eu Source: EUR-Lex Regulation (EU) 2025/327
web github.com This IG is under active development. Feedback and issues are tracked on GitHub Issues . Please join our weekly meetings to participate in this development.
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 MPD
web github.com Open issues under discussion in this IG. Each has a corresponding GitHub Issue where you can add input to existing issues, or create your own.
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
web github.com GitHub Issue
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 content is defined by the HL7 EU Medication Prescription and Dispense profile.
web www.ehtel.eu This specification prov of the data sets required by XtEHR WP5.1 .
web profiles.ihe.net IHE-QEDm
web eur-lex.europa.eu The regulatory basis is primarily found in EHDS ANNEX II - Essential Requirements for EHR Systems ( EUR-Lex , Local Copy ), 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 . Note: Xt-EHR deliverables are not yet publicly released.
web build-fhir.ehdsi.eu MyHealth@EU NCPeH API

Internal Images

5-1_exchange.png
5-1_exchange.png
ExGroup_Doc.png
ExGroup_Doc.png
ExGroup_Group.png
ExGroup_Group.png
actors_overall.png
actors_overall.png
docExchange_1.png
docExchange_1.png
docExchange_2.png
docExchange_2.png
resExchange_1.png
resExchange_1.png
resExchange_2.png
resExchange_2.png
tree-filter.png
tree-filter.png