Unattributed Code Systems

• http://unstats.un.org/unsd/methods/m49/m49.htm

Copyright Fragment

This fragment is available on en/copyright.html

Copyright and Registered Trademark Uses

• IG © 2025+ HL7 Europe. Package hl7.fhir.eu.eu-health-data-api#0.1.0 based on FHIR 4.0.1. Generated 2026-03-04 Links: Table of Contents | QA Report CC0 Propose a changeexternal ( src )
• hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )
• 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). ( src )
• Copyright/Legal: This material contains content from LOINC (http://loinc.org). LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license at http://loinc.org/license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc ( src )
• 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 ( src )
• This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc. Show Usage * LOINC: DocumentReference/ExampleDocumentReferenceEPS, DocumentReference/ExampleDocumentReferenceImagingManifestFHIR... Show 5 more, DocumentReference/ExampleDocumentReferenceImagingManifestKOS, EEHRxFDocumentTypeDischargeReportVS, EEHRxFDocumentTypeLaboratoryReportVS, EEHRxFDocumentTypeMedicalImagingVS and EEHRxFDocumentTypePatientSummaryVS ( src )
• This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html Show Usage * UsageContextType: EEHRxFDocumentTypeDischargeReportVS, EEHRxFDocumentTypeLaboratoryReportVS, EEHRxFDocumentTypeMedicalImagingVS and EEHRxFDocumentTypePatientSummaryVS ( src )

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	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	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-03-04 Links: Table of Contents | QA Report Propose a change
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	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 category to content IGs and implementations.
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	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 Imaging Study/Report / Imaging Manifest
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	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.
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	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

ExGroup_Doc.png

ExGroup_DocAssembly.png

ExGroup_Group.png

actors_overall.png

docExchange_1.png

docExchange_2.png

resExchange_1.png

resExchange_2.png

tree-filter.png