EHDS : ce que l'espace européen des données de santé impose aux éditeurs de DME

Le 26 mars 2029, un logiciel qui gère des résumés de dossiers patients ou des prescriptions électroniques ne pourra plus être mis sur le marché ni mis en service dans l'Union sans déclaration UE de conformité, marquage CE et enregistrement européen. C'est ce qu'impose le règlement (UE) 2025/327 sur l'espace européen des données de santé (EHDS) à tout éditeur de système de dossier médical électronique, y compris en SaaS. La vue d'ensemble de l'EHDS présente les droits des patients et l'usage secondaire. Cet article traite un seul sujet : ce que l'éditeur doit construire, documenter et déclarer, et dans quel ordre.

Êtes-vous fabricant d'un système DME au sens de l'EHDS ?

Tout part de la définition de l'article 2, paragraphe 2, point k). Un système de DME est un logiciel, seul ou combiné à du matériel, qui permet de stocker, d'intermédier, d'exporter, d'importer, de convertir, d'éditer ou de consulter des données de santé appartenant aux catégories prioritaires, et que le fabricant destine aux professionnels de santé pour soigner ou aux patients pour accéder à leurs données.

Trois critères cumulatifs se dégagent : une fonction de traitement très large, des données d'une catégorie prioritaire, une destination de soin ou d'accès patient. Les six catégories prioritaires sont fixées par l'article 14 :

• les résumés de dossiers de patients ;
• les prescriptions électroniques ;
• les dispensations électroniques ;
• les examens et comptes rendus d'imagerie médicale ;
• les résultats d'examens médicaux, dont la biologie, et leurs comptes rendus ;
• les rapports de sortie d'hôpital.

Le mot « destiné » compte. C'est la destination déclarée par l'éditeur, dans sa documentation et son discours commercial, qui fait entrer le produit dans le régime. Un logiciel de gestion de cabinet qui édite des ordonnances y entre. Un PACS ou un RIS qui archive et affiche des examens d'imagerie y entre. Un logiciel de laboratoire qui publie des résultats de biologie y entre. Un portail patient qui affiche des comptes rendus y entre aussi, puisque la définition vise l'accès des patients.

Ce qui reste hors champ

L'article 25, paragraphe 2, exclut les logiciels à usage général utilisés dans un environnement de soins. Le considérant 38 donne les exemples : le traitement de texte qui sert à rédiger un compte rendu, le middleware généraliste, le système de gestion de base de données d'une solution de stockage. Le critère est celui de la conception spécifique : un outil généraliste ne devient pas un système de DME parce qu'un hôpital l'utilise.

Les cas frontières sont nombreux. Un agenda de prise de rendez-vous ne traite en principe aucune catégorie prioritaire. Un entrepôt de données de santé destiné à la recherche n'est pas destiné aux soins. Une messagerie sécurisée qui transporte des comptes rendus de biologie fait de l'intermédiation, l'un des verbes de la définition. La lecture la plus probable est qu'elle entre dans le champ si elle est conçue pour ces échanges, mais aucune ligne directrice de la Commission ne tranche encore ces cas.

Le SaaS est « mis en service » dans l'Union

Un éditeur SaaS ne peut pas s'abriter derrière l'absence de livraison d'un produit. L'article 26, paragraphe 2, assimile à une mise en service le système de DME proposé en tant que service à une personne établie dans l'Union. Le même article vise les systèmes fabriqués et utilisés en interne par un établissement de santé : un CHU qui développe son propre dossier patient est traité comme l'ayant mis en service, avec un calendrier propre.

Deux requalifications méritent l'attention. L'article 34 traite comme fabricant le distributeur ou l'intégrateur qui vend un système de DME sous sa propre marque, ou qui le modifie au point de compromettre sa conformité ou de changer sa destination. Une marque blanche sur un moteur tiers transfère donc toutes les obligations. Et un éditeur établi hors de l'Union doit désigner un mandataire européen par écrit (article 31), qui devient solidairement responsable si le fabricant manque à ses obligations.

Les deux composants harmonisés : interopérabilité et journalisation

L'EHDS ne réglemente pas tout le logiciel. Il impose deux composants logiciels harmonisés, définis aux points n) et o) de l'article 2, paragraphe 2, et rendus obligatoires par l'article 25 :

• le composant d'interopérabilité européen, qui fournit et reçoit les données des catégories prioritaires dans le format européen d'échange des dossiers médicaux électroniques ;
• le composant de journalisation européen, qui fournit les informations sur les accès des professionnels et des autres personnes à ces données.

Les deux composants doivent être indépendants l'un de l'autre. L'article 30, paragraphe 1, point b), ajoute que le fabricant veille à ce que les autres modules du système ne les perturbent pas. En pratique, cela pousse vers une architecture où l'export, l'import et les journaux d'accès forment des briques isolées, testables séparément, avec leurs propres numéros de version.

Le format européen d'échange n'existe pas encore sous forme opposable. L'article 15 charge la Commission de le fixer par acte d'exécution au plus tard le 26 mars 2027 : ensembles de données harmonisés, systèmes de codage, spécifications techniques d'échange. À la date de rédaction, je n'ai trouvé au Journal officiel aucun acte d'exécution publié sur ce format ni sur les spécifications communes. Les choix techniques se font donc sur la base des travaux préparatoires, ce qui plaide pour une couche de transformation découplée du modèle de données interne.

Les exigences essentielles de l'annexe II, en langage produit

L'annexe II fixe les exigences essentielles. Elles tiennent en une page, mais chacune se traduit par des tickets dans le backlog.

Interopérabilité : l'export n'est plus une option commerciale

• Exposer (point 2.1) : un système qui stocke ou intermédie des données fournit une interface d'accès aux données dans le format européen.
• Recevoir (points 2.2 et 2.3) : il sait ingérer des données dans ce même format, y compris lorsqu'il sert seulement à les consulter.
• Saisir finement (point 2.4) : une saisie structurée doit être assez granulaire pour produire le format européen. Un champ libre « antécédents » ne suffira pas à générer un résumé patient conforme.
• Ne pas verrouiller (points 2.5 et 2.6) : aucune fonctionnalité ne doit restreindre l'accès ou le partage autorisés, ni l'export destiné à changer de logiciel, ni leur imposer des contraintes excessives.

Les points 2.5 et 2.6 touchent directement le modèle économique. Un export payant, bridé ou volontairement incomplet au moment où un établissement change d'éditeur devient une non-conformité du produit, contrôlable par l'autorité de surveillance du marché. La clause de réversibilité du contrat ne peut plus être plus restrictive que ce que le produit doit permettre.

Sécurité et journalisation : ce que chaque ligne de journal doit contenir

Le point 3.1 impose une identification et une authentification fiables des professionnels de santé. Le point 3.2 fixe le contenu minimal de chaque événement d'accès :

1. l'identité du prestataire de soins ou de la personne qui a accédé aux données ;
2. l'identité de la ou des personnes physiques précises qui ont accédé ;
3. les catégories de données consultées ;
4. la date et l'heure ;
5. l'origine des données.

Le point 3.3 exige des outils d'analyse des journaux, ou la possibilité de les brancher sur un outil externe. Le point 3.4 impose de gérer des durées de conservation et des droits d'accès différents selon l'origine et la catégorie des données. Beaucoup de logiciels du marché journalisent l'utilisateur et l'horodatage, rarement la catégorie de données et l'origine. C'est souvent là que se trouve le plus gros chantier.

Point de vigilance. La journalisation EHDS n'est pas un journal technique pour l'équipe d'exploitation. Elle alimente le droit des patients de savoir qui a consulté leurs données. Un journal incomplet devient donc à la fois une non-conformité du produit et un manquement que l'établissement client vous reprochera.

Autocertification, déclaration UE de conformité et marquage CE

Le régime repose sur une autoévaluation : aucun organisme notifié n'intervient. Le considérant 39 en fait un choix de proportionnalité. Cela ne veut pas dire légèreté, car la déclaration engage le fabricant seul (article 39, paragraphe 5).

La séquence imposée avant la mise sur le marché

1. Passer l'environnement d'essai. L'article 40 oblige le fabricant à tester ses composants harmonisés dans les environnements d'essai numériques, européen ou nationaux. Les éléments testés avec succès sont présumés conformes. Les résultats entrent dans la documentation.
2. Constituer la documentation technique (article 37 et annexe III) : destination, catégories de données traitées, architecture avec schémas, structures de données et entrées-sorties, versions, historique des modifications, notice d'utilisation, résultats de tous les essais. L'autorité peut l'exiger, avec traduction, dans un délai de 30 jours.
3. Rédiger la fiche d'information (article 38) : identité du fabricant, nom et version du système, destination, catégories de données, normes et formats supportés avec leurs versions.
4. Signer la déclaration UE de conformité (article 39 et annexe IV). Si le logiciel relève d'autres textes qui exigent une déclaration, une seule déclaration couvre l'ensemble.
5. Apposer le marquage CE (article 41) sur les documents d'accompagnement, avant la mise sur le marché.
6. Enregistrer le système dans la base de données de l'Union (article 49), avec les résultats de l'environnement d'essai.

Les spécifications communes de l'article 36, attendues au plus tard le 26 mars 2027, donneront la présomption de conformité. Tant qu'elles ne sont pas publiées, on ne peut pas figer la conformité, seulement préparer l'architecture et le dossier.

Ce qui dure après la vente

La documentation et la déclaration se conservent dix ans après la mise sur le marché (article 30, paragraphe 3). Sur requête motivée, le fabricant remet aux autorités le code source ou la logique de programmation, si c'est nécessaire pour vérifier la conformité. Chaque évolution des composants harmonisés doit être reflétée dans la documentation. Pour un SaaS qui livre chaque semaine, cela suppose une gestion de configuration rigoureuse : savoir quelle version du composant d'export tournait à quelle date, et sur la base de quels essais.

L'article 28 interdit enfin les allégations trompeuses sur l'interopérabilité et la sécurité : prêter au système des fonctions qu'il n'a pas, taire ses limites, suggérer des usages hors destination. Une plaquette commerciale qui promet « compatible EHDS » avant toute autoévaluation est un risque, pas un argument.

Enregistrement, surveillance du marché et sanctions

Les systèmes de DME relèvent du règlement (UE) 2019/1020 sur la surveillance du marché (article 43). L'autorité désignée par chaque État membre peut exiger des mesures correctives dans un délai fixé, puis interdire, rappeler ou retirer le produit si la non-conformité persiste (article 45). Les cas de non-conformité visés expressément sont concrets : exigence essentielle non respectée, documentation absente ou incomplète, déclaration mal établie, marquage CE manquant ou abusif, enregistrement non fait.

L'article 44, paragraphe 7, crée une obligation proche de la matériovigilance. Le fabricant signale tout incident grave impliquant son système aux autorités de surveillance du marché, au plus tard trois jours après en avoir eu connaissance. Est un incident grave tout dysfonctionnement qui entraîne ou pourrait entraîner un préjudice grave pour la santé, une atteinte grave aux droits d'une personne ou une perturbation grave d'infrastructures critiques de santé. Une fuite massive de résumés patients due à un défaut du composant d'export entre dans cette définition. Ce signalement s'ajoute à la notification de violation à la CNIL et, le cas échéant, aux obligations issues de NIS 2.

Les sanctions : un régime national encore à écrire

L'article 99 renvoie aux États membres le soin de fixer les sanctions, effectives, proportionnées et dissuasives, en tenant compte notamment du chiffre d'affaires réalisé dans l'Union. Ils doivent notifier leur régime à la Commission au plus tard le 26 mars 2027. À ce jour, je n'ai trouvé aucun texte français qui le fixe, ni qui désigne l'autorité française de surveillance du marché des systèmes de DME. L'Agence du numérique en santé et l'ANSM sont évoquées dans les échanges publics. L'article 100 ouvre en outre un droit à réparation à toute personne lésée.

Le droit français donne déjà une idée de l'ordre de grandeur. L'article L. 1470-6 du Code de la santé publique permet au ministre de la Santé d'infliger à l'éditeur qui ne respecte pas les référentiels opposables une pénalité pouvant atteindre 1 % du chiffre d'affaires réalisé en France, dans la limite d'un million d'euros, assortie d'une astreinte jusqu'à 1 000 euros par jour. Le risque le plus immédiat reste commercial : sans marquage, plus de mise sur le marché du tout.

Le cumul DM, IA et EHDS : un seul produit, trois régimes

L'EHDS s'applique « sans préjudice » des règlements sur les dispositifs médicaux et sur l'IA (article 1er, paragraphe 5). Les régimes s'additionnent.

Dispositif médical et système de DME

Un logiciel peut être les deux. Une fonction d'aide à la prescription qui calcule une posologie a en principe une finalité médicale au sens de l'article 2, point 1, du règlement (UE) 2017/745, et la règle 11 de son annexe VIII la classe au moins en classe IIa lorsqu'elle fournit des informations utilisées pour des décisions diagnostiques ou thérapeutiques. Le test de qualification d'un logiciel en dispositif médical détaille la méthode. Si le même logiciel gère aussi des prescriptions électroniques, il cumule marquage CE au titre du MDR et autoévaluation EHDS.

L'article 27 règle un cas voisin : le fabricant d'un dispositif médical qui allègue l'interopérabilité avec les systèmes de DME doit prouver la conformité aux exigences des composants harmonisés. L'article 49, paragraphe 3, impose alors un double enregistrement, dans EUDAMED et dans la base EHDS. Pour la surveillance, c'est l'autorité compétente en matière de dispositifs médicaux qui intervient (article 43, paragraphe 7).

IA à haut risque et système de DME

Un module d'IA intégré à un dossier patient, qui est lui-même un dispositif médical soumis à un organisme notifié, est un système d'IA à haut risque au titre de l'article 6, paragraphe 1, et de l'annexe I du règlement (UE) 2024/1689. Depuis le règlement (UE) 2026/1744 du 8 juillet 2026, qui a modifié l'article 113 de l'AI Act, les exigences applicables à ces systèmes s'appliquent à partir du 2 août 2028, et à partir du 2 décembre 2027 pour ceux de l'annexe III. L'articulation entre AI Act, RGPD et dispositif médical en santé est traitée à part.

Le calendrier donne une fenêtre utile : AI Act en 2028, première vague EHDS en 2029. Une seule documentation technique, un seul système de gestion des versions et une déclaration de conformité unique, comme le permet l'article 39, paragraphe 2, coûtent moins cher que trois dossiers montés à la suite.

Le cas particulier de la cyberrésilience

Le considérant 112 précise que le règlement (UE) 2024/2847 sur la cyberrésilience ne couvre pas le SaaS en tant que tel. Un système de DME installé chez le client, en revanche, est un produit comportant des éléments numériques et doit aussi respecter les exigences de cybersécurité de ce règlement, avec la possibilité de les démontrer dans le cadre d'évaluation de l'EHDS. Le mode de distribution change donc le nombre de régimes applicables.

Le calendrier par catégorie de données

L'article 105 fixe une application par vagues :

• 26 mars 2027 : application générale du règlement. Échéance des actes d'exécution sur le format européen (article 15) et des spécifications communes (article 36), et de la notification des régimes nationaux de sanctions.
• 26 mars 2029 : les articles 25 à 27 et 47 à 49 (composants obligatoires, mise sur le marché, enregistrement) s'appliquent aux systèmes de DME destinés à traiter les résumés de dossiers patients, les prescriptions et les dispensations électroniques.
• 26 mars 2031 : les mêmes articles s'appliquent aux systèmes destinés à traiter l'imagerie, les résultats d'examens et les rapports de sortie d'hôpital, et l'ensemble du chapitre III s'applique aux systèmes développés et utilisés en interne par les établissements.

Un logiciel de cabinet qui édite des ordonnances est donc concerné dès 2029. Un PACS pur l'est en 2031. Un dossier patient hospitalier couvrant les six catégories doit être prêt pour les premières dès 2029, puis étendre sa conformité en 2031.

Et les référentiels français ?

L'EHDS ne supprime pas les exigences nationales. L'article 42 autorise les États membres à maintenir des exigences propres sur tout ce qui n'est pas un composant harmonisé, à condition de ne pas perturber ces composants. En France, l'article L. 1470-5 du Code de la santé publique rend opposables les référentiels d'interopérabilité et de sécurité élaborés par l'Agence du numérique en santé, et l'article L. 1470-6 conditionne les financements publics à des engagements de conformité. Un éditeur français cumulera donc les deux niveaux. La mécanique du référencement Ségur pour les éditeurs reste la référence nationale, et il faudra suivre la manière dont les profils français s'aligneront sur le format européen.

Feuille de route produit : ce que je recommande de lancer maintenant

Attendre les actes d'exécution de 2027 pour démarrer, c'est se donner deux ans pour un chantier qui touche le modèle de données, l'architecture, la documentation et le contrat. Voici l'ordre que je propose aux éditeurs que j'accompagne.

1. Qualifier chaque produit : est-il un système de DME, pour quelles catégories, et donc pour quelle échéance ? La réponse dépend de la destination que vous affichez : relisez vos plaquettes et vos CGU.
2. Cartographier l'écart sur l'annexe II : export et import, granularité de la saisie structurée, contenu des journaux, durées de conservation par catégorie et par origine.
3. Isoler les deux composants dans l'architecture, avec un versionnage propre, pour pouvoir les faire évoluer au rythme des actes d'exécution sans toucher au reste.
4. Ouvrir le dossier technique dès aujourd'hui sur le modèle de l'annexe III, et le fusionner avec le dossier MDR ou AI Act si le produit en relève.
5. Revoir les contrats : répartition des rôles avec les intégrateurs et revendeurs au regard de l'article 34, clause de réversibilité alignée sur les points 2.5 et 2.6, clause d'évolution réglementaire dans les contrats pluriannuels, mandataire européen si vous êtes établi hors de l'Union.
6. Nettoyer le discours commercial au regard de l'article 28 : on ne promet pas une conformité qui n'a pas encore été évaluée.

Ce chantier est à la fois juridique et technique. Mon double profil d'avocat et de développeur me permet de lire votre architecture et votre documentation avec le même regard que l'autorité qui les contrôlera. C'est le cœur de mon accompagnement des éditeurs e-santé et healthtech. Si vous voulez savoir où se situe votre logiciel et par quoi commencer, échangeons sur votre feuille de route EHDS.