Unattributed Code Systems

• http://dicom.nema.org/resources/ontology/DCMUID
• http://unstats.un.org/unsd/methods/m49/m49.htm
• urn:ietf:rfc:3986

Copyright Fragment

This fragment is available on en/copyright.html

Copyright and Registered Trademark Uses

• IG © 2025+ HL7 Europe. Package hl7.fhir.eu.health-data-api#1.0.0-ballot based on FHIR 4.0.1. Generated 2026-03-13 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 )
• 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/ExampleDocumentReferenceHDR... Show 8 more, DocumentReference/ExampleDocumentReferenceImagingManifestFHIR, DocumentReference/ExampleDocumentReferenceImagingManifestKOS, DocumentReference/ExampleDocumentReferenceImagingReport, DocumentReference/ExampleDocumentReferenceLaboratory, 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	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	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-03-13 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 QEDm - Defines how a client can query for existing FHIR resources from a FHIR server. Referenced where compatible with IPA.
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 (TLS 1.2 Floor using BCP195 Option).
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	QEDm Clinical Data Source ( CapabilityStatement ) - where compatible with IPA
web	profiles.ihe.net	QEDm Clinical Data Source ( CapabilityStatement ) - where compatible with IPA
web	profiles.ihe.net	QEDm Clinical Data Consumer ( CapabilityStatement ) - where compatible with IPA
web	profiles.ihe.net	QEDm Clinical Data Consumer ( CapabilityStatement ) - where compatible with IPA
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 with the TLS 1.2 Floor using BCP195 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	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	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	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	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	www.ehtel.eu	This specification provides an overview 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	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	profiles.ihe.net	IHE QEDm - Query Existing Data mobile, where compatible with IPA. QEDm has a goal of aligning with IPA. PCC-44 - Mobile Query Existing Data transaction
web	profiles.ihe.net	PCC-44 - Mobile Query Existing Data transaction
web	profiles.ihe.net	The IHE mXDE profile provides more detail on how to extract resources from documents while maintaining provenance.
web	profiles.ihe.net	IHE QEDm PCC-44 Mobile Query Existing Data
web	profiles.ihe.net	PCC-44 Mobile Query Existing Data
web	profiles.ihe.net	IHE mXDE
web	build-fhir.ehdsi.eu	MyHealth@EU NCPeH API

Internal Images

5-1_exchange.png

ContentExchangeXtEhr.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

xtehr-logo.png