EHDS, FR Core 2.2.0 and timetable 2025

Direct answer

The EHDS has been in force since March 26, 2025. Implementing acts are due March 26, 2027. Category 1 applies to March 26, 2029. Overlay FR Core 2.2.0 and INS; do not send a generic Patient R4.

Two pages, two jobs

The English page EU Core and EHDS implementation pliers HL7 Europe Base/Core 2.0.0 and EEHRxF artifacts. This one is for a French-speaking product team which must make this European calendar coexist with the national overlay: FR Core 2.2.0, theNational Health Identity and the CI-SIS. This is not a translation. This is also not the page IPR manufacturer, chapter III.

Schedule to stick to backlog (not made up phase names)

To be pinned from regulation (EU) 2025/327 and the EHDS Commission page :

Milestone	Date	What the product team is planning	What it is not
Entry into force	March 26, 2025	The clock has started. Version dependencies (GI, identifiers, future actions).	“All CIOs already speak EEHRxF”.
Implementing acts / common specifications	March 26, 2027	Art. 15 EEHRxF and Art. 36 common specifications. Pinch what the acts name.	A private XML called EEHRxF in 2026.
Category 1 (primary use)	March 26, 2029	Patient summary, ePrescription, eDispensation for PGD in the field.	A `Patient` REST naked.
Category 2 (primary use)	March 26, 2031	Imaging, test results (including laboratory), hospitalization reports.	A DICOM C-Store “so we are EHDS”.

Secondary use (HealthData@EU, access organizations) is another pipeline: permits, datasets, secure environments. This is not the patient summary API. Don't build a "FHIR EHDS dump" and claim both.

Overlay France: FR Core 2.2.0 and INS

The pinner guide for French administrative resources is FR Core 2.2.0 (trial-use, active as of March 25, 2026), on FHIR R4. Official URL: https://hl7.fr/ig/fhir/core/ImplementationGuide/hl7.fhir.fr.core. Publication: https://hl7.fr/ig/fhir/core/. Package: hl7.fhir.fr.core#2.2.0. Interop'Santé / HL7 France indicate that national GIs (including ANS) must rely on FR Core, and that subsequent versions will aim for a legacy of HL7 Europe Base — announced alignment, not a Commission certificate.

The INS is not a Patient.id. The profile FR Core Patient INS (https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-patient-ins) fixed:

Slice/artifact	`identifier.system`	Role	Trap
INS-NIR	`urn:oid:1.2.250.1.213.1.4.8`	INS registration number obtained via teleservice INSi	Paste the NIR into `Patient.id` or in a `system` house
INS-NIA	`urn:oid:1.2.250.1.213.1.4.9`	Wait ID	Treat a NIA like a “VALI” NIR
INS-NIR-TEST / DEMO	`urn:oid:1.2.250.1.213.1.4.10` / `.4.11`	Fixture games	Publish a real NIR in a gist
PPI	Establishment OID/URI	Local identifier	Believe that the IPP replaces the INS at the national border
IDNatPS	`urn:oid:1.2.250.1.71.4.2.1`	Professional	An application login
IDNatStruct	`urn:oid:1.2.250.1.71.4.2.2`	Structure	A SIRET stuck in `Organization.id`

The invariant fr-core-1 profile Patient INS: if the identity status is VALI, at least one INS-NIR or INS-NIA (or TEST/DEMO slice) SHALL be present. A “qualified” identity without an INS slice is not compliant, even if the JSON is valid FHIR.

De-identified fixture (system TEST, not a person):

{
  "resourceType": "Patient",
  "meta": {
    "profile": ["https://hl7.fr/ig/fhir/core/StructureDefinition/fr-core-patient-ins"]
  },
  "identifier": [
    {
      "use": "official",
      "type": {
        "coding": [
          {
            "system": "https://hl7.fr/ig/fhir/core/CodeSystem/fr-core-cs-v2-0203",
            "code": "INS-NIR"
          }
        ]
      },
      "system": "urn:oid:1.2.250.1.213.1.4.10",
      "value": "EXEMPLE-INS-TEST-NON-NOMINATIF"
    }
  ]
}

Never publish an actual NIR. The INS repository v2.1 (decree of December 13, 2024) describes the referencing obligation; INSi teleservice remains the way to get identity, not a hand-entered field.

CI-SIS is not EEHRxF

The CI-SIS is the national ANS framework (CDA, IHE, FHIR, HL7 v2 depending on the component). EEHRxF is the exchange format that implementing acts 2027 must freeze for the six priority categories. A CI-SIS “synthesis” section or a CDA IPS-FR document is not, on its own, proof that a DPI will issue the appointed EEHRxF in 2027.

Until deeds, treat HL7 Europe Base/Core like implementable preview, not as a substitute for actions. Treat FR Core + INS as national constraint which remains on the European Patient : the INS is not replaced by patient-eu-core. A German KVNR, a Dutch BSN or a French NIR remain identifier.system Member State.

What the product team actually implements

CapabilityStatement, not a slide. Declare FR Core and, for categories sold, IG Europe (EPS, MPD, laboratory, HDR) in instantiates / supportedProfile.
Documents where the GI is a document. A patient summary is not a GET /Patient/{id}.
INSi before cross-border upsert. Without identity VALI, you export an IPP. This is not a Patient Summary EHDS.
Terminology. The EEHRxF logic models link SNOMED CT, LOINC, ICD, ATC. A Observation "code local only" will fail semantic checks.
Two backlogs. Overlay France (INS, CI-SIS, FR Core) and EHDS calendar (2027 / 2029 / 2031). A single milestone “we’re doing FHIR” mixes the two.

What this page is not

This is not an EHDS conformity assessment, not a CE marking, not a DPI system certificate, not legal advice. Implementing FR Core 2.2.0 or HL7 Europe Base/Core does not make a product “EHDS certified”. The 2027 Acts may still name other artifacts. I do not represent the Commission, the ANS, or Interop'Santé. Nothing here is clinical advice.

If you need the interoperability architecture (FR Core + Europe Base/Core on an existing HIS), it is interoperability in digital health. For a bounded spike, use the contact with project intention.

EHDS: 2025–2031 calendar and FR Core overlay for product teams