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

> Product team guide to stick Regulation (EU) 2025/327 to the French backlog: dates of March 26, 2025, 2027, 2029 and 2031, FR Core 2.2.0, INS, and why CI-SIS is not EEHRxF.

Author: Ala Ben Aicha

Canonical page: https://alabenaicha.me/insights/ehds-product-team-calendar

Updated: 2026-09-17

## 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](https://alabenaicha.me/insights/fhir-eu-core-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](https://hl7.fr/ig/fhir/core/), the[National Health Identity](https://esante.gouv.fr/ens/offre/referentiel-ins) and the [CI-SIS](https://esante.gouv.fr/offres-services/ci-sis/espace-publication). This is not a translation. This is also not the page [IPR manufacturer, chapter III](https://alabenaicha.me/insights/ehds-readiness-for-ehr-manufacturers).

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

To be pinned from [regulation (EU) 2025/327](https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32025R0327) and the [EHDS Commission page](https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en) :

| 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.html) (`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):

```json
{
  "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](https://esante.gouv.fr/ens/offre/referentiel-ins) (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](https://esante.gouv.fr/offres-services/ci-sis/espace-publication) 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](https://alabenaicha.me/insights/fhir-eu-core-ehds-implementation) 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

1. **CapabilityStatement**, not a slide. Declare FR Core and, for categories sold, IG Europe (EPS, MPD, laboratory, HDR) in `instantiates` / `supportedProfile`.
2. **Documents where the GI is a document.** A patient summary is not a `GET /Patient/{id}`.
3. **INSi before cross-border upsert.** Without identity `VALI`, you export an IPP. This is not a Patient Summary EHDS.
4. **Terminology.** The EEHRxF logic models link SNOMED CT, LOINC, ICD, ATC. A Observation "code local only" will fail semantic checks.
5. **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](https://alabenaicha.me/services/digital-health-interoperability). For a bounded spike, use the [contact with project intention](https://alabenaicha.me/contact?intent=project).