# European Health Data Space (EHDS) pour les développeurs

> Règlement (UE) 2025/327 pour les équipes de développement logiciel : les dates de 2029 et 2031, les composants des systèmes de DSE (Dossier de Santé Électronique), l'étiquetage des applications de bien-être, le format d'échange FHIR et ce qu'il faut construire dès maintenant.

Source: https://developers.anpheros.com/fr/guides/ehds-for-developers

**L'Espace européen des données de santé (EHDS) est un règlement de l'UE — Règlement (UE) 2025/327, en vigueur depuis le 26 mars 2025 — qui donne aux citoyens de l'UE le droit d'accéder à leurs données de santé électroniques et de les partager, établit des formats communs pour leur échange transfrontalier, et impose des exigences aux logiciels qui stockent et échangent des dossiers de santé.** La plupart des obligations s'appliquent à partir de mars 2029 et mars 2031, ce qui correspond à peu près à une génération de produits. Pour les développeurs, cela signifie : un format d'échange européen commun basé sur HL7 FHIR, une interopérabilité et une journalisation des accès obligatoires dans les systèmes de DSE, un étiquetage pour les applications de bien-être qui prétendent fonctionner avec eux, et de nouvelles règles pour la réutilisation des données de santé à des fins de recherche. Cette page résume ce qui a été décidé, ce qui est encore en cours de spécification, et ce qu'il faut construire dès maintenant.

## Chronologie

Selon la [Commission européenne](https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en) :

| Date | Ce qui s'applique |
|---|---|
| 26 mars 2025 | Le règlement entre en vigueur ; la transition commence |
| Mars 2027 | Date limite pour les actes d'exécution clés de la Commission (spécifications techniques) |
| Mars 2029 | Échange des premières catégories prioritaires — **résumés de patients et prescriptions électroniques / dispensations électroniques** — dans tous les États membres ; les règles d'utilisation secondaire commencent pour la plupart des catégories de données |
| Mars 2031 | Échange du deuxième groupe — **images médicales, résultats de laboratoire et rapports de sortie d'hôpital** ; règles d'utilisation secondaire pour les catégories restantes (telles que les données génomiques) |
| Mars 2035 | Les pays tiers et les organisations internationales peuvent demander à rejoindre HealthData@EU pour une utilisation secondaire |

## Les deux volets

**Usage principal — soins.** Les citoyens obtiennent un accès électronique à leurs données prioritaires, peuvent les partager avec des professionnels de santé dans un autre État membre via les points de contact nationaux (MyHealth@EU), peuvent ajouter des informations, restreindre l'accès et consulter les informations sur qui a accédé à leurs données. Les professionnels de santé obtiennent l'accès aux données dont ils ont besoin pour les soins.

**Usage secondaire — recherche, innovation, politique.** Les chercheurs et les entreprises peuvent demander aux organismes d'accès aux données de santé l'accès aux données de santé à des fins autorisées, traitées dans des environnements sécurisés, selon des règles définissant ce qui peut et ne peut pas être fait avec ces données.

## Ce qui change pour les logiciels

**Systèmes DME (Dossier Médical Électronique).** La réglementation établit un cadre juridique et technique pour les logiciels qui stockent et partagent des dossiers médicaux électroniques. Les fabricants doivent démontrer leur conformité aux exigences essentielles, y compris deux composants logiciels harmonisés — un **composant d'interopérabilité européen** pour l'échange de données au format européen et un **composant de journalisation européen** qui enregistre les accès aux données. Les spécifications communes pour ceux-ci sont définies par des actes d'exécution.

**Applications de bien-être.** Les applications qui prétendent être interopérables avec les systèmes DME — trackers de fitness et applications de santé qui y envoient des données — relèvent des exigences d'étiquetage et d'information (articles 47 et 48 du règlement).

**Dispositifs médicaux et systèmes d'IA** qui prétendent à l'interopérabilité avec les systèmes DME doivent également satisfaire aux exigences essentielles pertinentes en matière d'interopérabilité.

Les détails — ensembles de données exacts, profils et procédures de conformité — sont spécifiés dans des actes d'exécution et des normes de support. Lisez le règlement sur [EUR-Lex](https://eur-lex.europa.eu/eli/reg/2025/327/oj) et suivez les actes d'exécution plutôt que de vous fier à des résumés, y compris celui-ci.

## Le format d'échange : FHIR

Le format européen d'échange de dossiers de santé électroniques est spécifié autour de HL7 FHIR, avec des guides d'implémentation HL7 Europe pour les catégories prioritaires :

- **Résumé Patient**, basé sur le Résumé Patient International (IPS).
- **Rapport de Laboratoire**, **Rapport de Sortie d'Hôpital** et **Rapport d'Imagerie**.
- Un guide [EU Health Data API](https://hl7.eu/fhir/health-data-api/) (en cours de vote au moment de la rédaction) sur la manière dont les systèmes exposent ces documents via les API FHIR.

Si vos données sont déjà structurées en FHIR R4 avec des systèmes de codage standard (LOINC pour les résultats, SNOMED CT et ICD-10 pour les problèmes, ATC pour les médicaments, UCUM pour les unités), la cartographie vers les profils européens relève de contraintes plutôt que d'une réécriture. Si elles résident dans des tables personnalisées, l'écart est plus important.

## Que construire maintenant

1. **Stocker les données cliniques au format FHIR R4** (ou conserver une cartographie fiable vers celui-ci), avec des codes et des unités standard.
2. **Être capable de produire un Résumé International de Patient** pour une personne sur demande.
3. **Conserver les résultats de laboratoire structurés** : code LOINC, unité UCUM, plage de référence, statut, heures et laboratoire émetteur — ce que le profil de laboratoire européen demande.
4. **Enregistrer chaque accès** aux données d'une personne, avec qui, quand et quoi, et le rendre visible pour la personne.
5. **Modéliser le consentement et les restrictions par personne**, afin que l'accès puisse être limité par la personne plutôt que uniquement par vos rôles.
6. **Héberger dans l'UE et documenter votre base légale RGPD** ; l'EHDS s'appuie sur le RGPD, il ne le remplace pas.

## Où Anpheros s'intègre

Anpheros est une infrastructure de données de santé hébergée dans l'UE, construite sur FHIR R4, et plusieurs des capacités ci-dessus en font déjà partie : `Patient/{id}/$summary` renvoie un International Patient Summary (IPS) suivant le guide d'implémentation HL7 IPS ; les Observations de laboratoire peuvent être vérifiées par rapport à un profil de laboratoire européen (`$validate?profile=eu-lab`, également dans le [valideur FHIR R4](https://developers.anpheros.com/tools/fhir-validator) gratuit) ; chaque lecture et écriture est enregistrée et visible par le patient ; et l'accès par d'autres applications nécessite le consentement du patient, qu'il peut révoquer.

Cela ne fait pas d'Anpheros, ni d'une application construite sur celui-ci, un système EHR certifié EHDS. Anpheros ne se connecte pas aux points de contact nationaux ni à MyHealth@EU, n'implémente pas les composants harmonisés tels qu'ils seront spécifiés, et n'est pas un organisme d'accès aux données de santé. Considérez-le comme une longueur d'avance sur la structure des données, les résumés, la journalisation et le consentement, et non comme une conformité.

## Foire aux questions

### Quand le EHDS s'applique-t-il ?
Il est entré en vigueur le 26 mars 2025. La plupart des obligations débutent en mars 2029 (résumés de patients, prescriptions électroniques et la plupart des règles d'utilisation secondaire) et en mars 2031 (images, résultats de laboratoire, rapports de sortie et les catégories d'utilisation secondaire restantes).

### Le EHDS exige-t-il FHIR ?
Le règlement exige un format européen d'échange de dossiers de santé électroniques, spécifié dans des actes d'exécution ; les travaux sur ce format et ses guides d'implémentation sont basés sur HL7 FHIR, en commençant par le résumé international des patients.

### Le EHDS s'applique-t-il aux applications de santé et de remise en forme ?
Les applications de bien-être qui revendiquent l'interopérabilité avec les systèmes EHR sont soumises à des exigences d'étiquetage et d'information. Les applications qui sont des dispositifs médicaux restent sous les règles des dispositifs médicaux et doivent également répondre aux exigences d'interopérabilité lorsqu'elles prétendent fonctionner avec des systèmes EHR.

### Qu'est-ce que le composant de journalisation européen ?
L'un des deux composants logiciels harmonisés que les systèmes EHR doivent inclure : il enregistre l'accès aux données personnelles de santé électroniques, soutenant le droit des personnes à voir qui a accédé à leurs données.

### Anpheros est-il conforme au EHDS ?
Anpheros n'est pas un système EHR certifié. Il fournit déjà un stockage FHIR R4, des résumés internationaux de patients, des vérifications de profils de laboratoire européens, des journaux d'accès par patient et le consentement, qui sont des éléments constitutifs des exigences.

## Liens connexes

- [RGPD et données de santé pour les développeurs](https://developers.anpheros.com/fr/guides/gdpr-health-data-developers)
- [International Patient Summary (IPS) en FHIR](https://developers.anpheros.com/fr/guides/international-patient-summary-fhir)
- [Interopérabilité des données de santé](https://developers.anpheros.com/fr/guides/interoperability)
- [API des résultats de laboratoire : HL7 v2, FHIR et LOINC](https://developers.anpheros.com/fr/guides/lab-results-api)
- [Sécurité, confidentialité et résidence des données](https://developers.anpheros.com/fr/guides/security)
- [Application de dossier de santé personnel (PHR) avec FHIR](https://developers.anpheros.com/fr/guides/personal-health-record-app)
- [Données médicales dans l'UE (guide du patient)](https://anpheros.com/guides/medical-data-in-the-eu-ehds)