EU Core and EHDS: implementing HL7 Europe Base/Core for primary-use payloads
A product-team guide to HL7 Europe Base and Core 2.0.0, EHDS dates 26 March 2025 / 2027 / 2029 / 2031, and EEHRxF category 1 versus category 2 — distinct from the regulation overview.
Ala Ben Aicha
Direct answer
EHDS entered into force 26 March 2025. Implementing acts are due by March 2027. Category 1 applies March 2029; category 2 March 2031. Product teams should implement HL7 Europe Base/Core, not a generic R4 server.
Two pages, two jobs
The EHDS regulation overview on this site stays the policy map: primary versus secondary use, certification pressure, and why FHIR shows up in European tenders. This page is for product teams implementing HL7 Europe Base and Core so an EHR or integration layer can emit EEHRxF-shaped payloads. Do not treat the two articles as duplicates.
EHDS dates product teams should schedule against
From the Commission EHDS pages and Regulation (EU) 2025/327 (the Commission’s EHDS regulation page):
| Milestone | Date | What it means for an implementing team |
|---|---|---|
| Regulation in force | 26 March 2025 | Clock started. Not “every EHR must already speak EEHRxF”. |
| Implementing acts | By March 2027 | Commission specifications for EEHRxF, common specifications and related acts. Pin whatever the acts name; do not invent a private format. |
| Category 1 primary use | March 2029 | Patient summary, ePrescription and eDispensation obligations for in-scope EHR systems. |
| Category 2 primary use | March 2031 | Medical imaging studies and reports, laboratory and other test results, hospital discharge reports. |
Secondary use (HealthData@EU, health data access bodies) is a different pipeline: permits, datasets and governance, not the same as a Patient Summary document API. Primary use is care delivery and patient rights; secondary use is research, policy and innovation under a separate chapter. Do not build one “EHDS FHIR dump” and claim both.
EEHRxF category 1 versus category 2
The European electronic health record exchange format (EEHRxF) is the payload contract the implementing acts will lock. Xt-EHR is producing logical models; HL7 Europe is producing FHIR IGs that those models can bind to. Until the 2027 acts are in force, treat the HL7 Europe IGs as the implementable preview, not as a substitute for the acts.
| EHDS primary-use category | EEHRxF artefact | Example FHIR IG (HL7 Europe) |
|---|---|---|
| Category 1 — patient summary | EEHRxF Patient Summary | HL7 Europe Patient Summary 1.0.0-ballot (http://hl7.eu/fhir/eps/ImplementationGuide/hl7.fhir.eu.eps), on IPS |
| Category 1 — ePrescription / eDispensation | EEHRxF ePrescription and eDispensation | HL7 Europe Medication Prescription and Dispense |
| Category 2 — medical test results (incl. laboratory) | EEHRxF medical test results | HL7 Europe Laboratory Report 2.0.0 (http://hl7.eu/fhir/laboratory/ImplementationGuide/hl7.fhir.eu.laboratory) |
| Category 2 — medical imaging studies and reports | EEHRxF imaging studies and reports | Follow the HL7 Europe / IHE imaging IG the acts name; do not treat DICOM C-Store as EEHRxF |
| Category 2 — discharge reports | EEHRxF discharge report | HL7 Europe Hospital Discharge Report (http://hl7.eu/fhir/hdr/ImplementationGuide/hl7.fhir.eu.hdr) |
Category 1 is the 2029 production target. Category 2 is the 2031 target. Shipping laboratory FHIR in 2026 is useful rehearsal; it is not early compliance with a 2031 obligation.
HL7 Europe Base versus Core
The IG to pin for shared building blocks is HL7 Europe Base and Core FHIR IG 2.0.0 (trial-use / STU 2), generated 27 April 2026, on FHIR R4. Official URL: http://hl7.eu/fhir/base/ImplementationGuide/hl7.fhir.eu.base. Published home: https://hl7.eu/fhir/base/. Package: hl7.fhir.eu.base#2.0.0. An R5 twin exists at https://hl7.eu/fhir/base-r5; most national stacks in Europe are still R4 — see the German R4 calendar if Germany is in the same release train.
The IG’s own split:
- Base profiles — loosely constrained European concepts (Patient, Practitioner, Organization). Foundation for national and scoped IGs.
- Core profiles — essential constraints intended for reuse across most European IGs, with IPS alignment where it is reasonable. Example: Patient (EU core) at
http://hl7.eu/fhir/base/StructureDefinition/patient-eu-core.
Xt-EHR supported this STU 2 version. That is alignment work, not a Commission certificate.
National identifiers still sit on EU Patient, they are not replaced by it. A German KVNR, a French NIR or a Dutch BSN remains a country-specific identifier system. The EU Core vs US Core article lists those systems; this page does not repeat that table.
What a product team actually implements
- Capability, not a blog post. Declare EU Base/Core and the scoped IG (EPS, MPD, laboratory, HDR) in
CapabilityStatement.instantiates/supportedProfilefor the categories you sell. - Documents where the IG is a document. Patient summary and laboratory report IGs expect FHIR Documents (Bundle + Composition) as well as RESTful resources. A bare
Patientread is not a Patient Summary. - Member-state overlay. EU Core is not CH Core, not ISiK, not a French national profile. If the buyer is a Swiss community, use the EPD article. If the buyer is a German hospital, use ISiK / MIO.
- Terminology. EEHRxF logical models bind SNOMED CT, LOINC, ICD and ATC. Local code-only Observations will fail semantic checks even if the JSON is valid FHIR.
What this is not
This page is not an EHDS conformity assessment, not a CE or EHR-system certificate, and not legal advice. Implementing HL7 Europe Base/Core does not make a product “EHDS certified”. The 2027 implementing acts can still change the named artefacts. I do not represent the Commission, Xt-EHR or HL7 Europe. Nothing here is clinical advice.
Related reading
- Regulation overview: European Health Data Space
- Profile differences versus the US: EU Core vs US Core
- Country map: FHIR implementation guides by country
If you need the integration architecture for EU Base/Core payloads on top of existing hospital v2, that is digital health interoperability.