Elles s’adressent aux lecteurs cherchant à positionner leurs développement - systèmes, logiciels, services - au regard de la réglementation encadrant le marquage CE. Elle visent également à permettre à chacun d’approfondir le sujet de manière autonome à partir des références mentionnées.

Etat d’esprit

La réglementation, en particulier lorsqu’elle s’applique à la santé, peut être percue comme contraignante, superflue ou redondante.

Elle peut toutefois être envisagée comme une opportunité:

• certaines questions sont tranchées par les textes : il n’est pas nécessaire de les réinventer
• instaurer un climat de confiance
• renforce la sécurité — protection contre les accidents — notamment via la conformité à des normes comme ISO 14971 pour les dispositifs médicaux
• participe à la sûreté — protection contre les actes intentionnels — par l’analyse des risques, par exemple à travers ISO 27001
• …

Ces notes sont rédigées dans cet esprit. Elles n’analysent pas les biais, jeux d’acteurs, délais ou les éventuelles limites inhérentes à des directives et règlements traitant de problématiques complexes et globales. Elles partent au contraire du principe que les règles existent lorsque les enjeux ne peuvent se réguler d’eux-mêmes, dans l’intérêt du plus grand nombre.

Elles présentent néanmoins trois « scénarios » dans lesquels la réglementation relative aux dispositifs médicaux peut ne pas s’appliquer, ou à partir desquels il est possible d’organiser et de structurer son effort de conformité.

Historique

Le DM est l’un des premiers cas d’usage sur lequel s’est penchée l’Europe:

Directive et règlement : une différence structurante

Une directive européenne doit être transposée dans le droit national de chaque État membre. Cette transposition peut varier en portée, en moyens mobilisés et en calendrier d’application. Par nature, elle laisse une marge d’interprétation aux États, ce qui peut conduire à des disparités et à des failles dans l’application pratique (cf scandales retentissants: PIP, ImplantFiles)

Ces insuffisances justifient ont largement contribué au choix d’un instrument juridique plus contraignant : le règlement. Contrairement à la directive, le règlement s’applique directement et de manière uniforme dans tous les États membres, sans nécessiter de transposition nationale.

Toutefois, malgré cette harmonisation renforcée, de nombreuses références à des concepts, terminologies et mécanismes issus des anciens textes subsistent. Cette superposition historique rend parfois l’interprétation et la mise en œuvre du règlement de 2017 complexe pour les acteurs du secteur.

Références réglementaires

Le Règlement (UE) 2017/745 (Medical Device Regulation MDR) est librement accessible en ligne. Il est vivement recommandé d’en lire au minimum les considérants : ils éclairent l’intention du législateur, explicitent les objectifs poursuivis et facilitent l’interprétation des articles opérationnels.

La base de données européenne dédiée aux dispositifs médicaux, Eudamed, a été mise en place dans le cadre de ce règlement. Elle centralise notamment les informations relatives aux opérateurs économiques, aux dispositifs, aux investigations cliniques et à la vigilance.

Concernant les dispositifs médicaux logiciels, le document d’orientation MDCG 2019-11 Rev.1 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR constitue une référence incontournable. Il précise les critères de qualification (un logiciel est-il ou non un dispositif médical ?) et les règles de classification applicables dans le cadre du règlement (Union européenne) 2017/745.

Classes de DM

La classe I, fondée sur une auto-déclaration, constitue souvent une première étape pour se préparer à des procédures réglementaires plus exigeantes.

Les DM logiciels relève souvent d’une Classe IIa.

Les DM logiciels classés en IIb / III sont des logiciels qui:

• pilotent des dispositifs implantables (pacemaker, pompe à insuline);
• contrôlent des traitements vitaux tels que la radiothérapie ou la chimiothérapie à risque mortel.

Planning

Le MDR a instauré une période transitoire (« biseau ») pour les dispositifs médicaux encore certifiés sous les anciennes directives.

Cette phase arrive désormais presque à son terme, ce qui laisse très peu — voire aucune — marge de manœuvre stratégique sur le calendrier de mise en conformité.

Acteurs

Autorité compétente = Competent Authorities (CA)

En France

L’ANSM est autorité compétente sur le DM.

Au niveau européen

Le réseau des autorités compétentes des États membres est coordonné au sein de CAMD (Competent Authorities for Medical Devices). Cette structure favorise l’harmonisation des pratiques et la coopération entre autorités nationales dans le cadre de l’application du MDR.

En Allemagne, l’autorité compétente en matière de DM est le BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte), en charge notamment de la surveillance du marché et de certaines procédures réglementaires.

Organismes notifiés = Notified Bodies (NB)

Le NANDO (New Approach Notified and Designated Organisations) est la base de données officielle de la Commission européenne qui recense l’ensemble des organismes notifiés désignés par les États membres pour l’évaluation de conformité des produits soumis aux réglementations européennes, dont le Règlement (UE) 2017/745 (MDR).

👉 La liste complète et à jour des organismes notifiés sous MDR est accessible via la base NANDO (filtrable par pays, statut et législation).

FR

À ce jour, les organismes notifiés français sous MDR incluent :

EU

La Commission européenne met également à disposition une page d’information dédiée aux organismes notifiés, qui renvoie vers la base NANDO pour la liste officielle et actualisée au titre du MDR.

⚠️ Pour toute vérification réglementaire (choix d’un organisme notifié, validité d’un certificat, périmètre de désignation), la base NANDO reste la référence officielle.

Mandataire = Authorized Representative (AR)

Le mandataire européen (Authorized Representative) est requis pour les fabricants établis hors Union européenne.

“Accompagnement” / “consultants”

Ce tableau ne recense ni des autorités compétentes (CA) ni des organismes notifiés (NB).

Ce sont des sociétés de conseil et d’accompagnement réglementaire pour les dispositifs médicaux.

Les sociétés listées dans ton tableau : prestataires privés qui accompagnent les fabricants pour :

• préparer les dossiers CE
• mettre en place un SMQ ISO 13485…
• gérer la documentation et la stratégie réglementaire
• faire de la veille réglementaire ou des audits internes

Roles

flowchart TD
    A["Autorités Compétentes (CA)\nex. ANSM, BfArM"] -->|Désignation & surveillance| B["Organismes Notifiés (NB)\nex. GMED, AFNOR"]
    B -->|Évaluation conformité & certificat CE| C["Fabricants / Hôpitaux\nDéveloppement DM logiciel"]
    C -->|Préparation dossier CE / SMQ / gestion risques| B
    C -->|Accompagnement, audit, formation| D["Consultants / Experts DM\nex. DMEXPERTS, ASPE-Conseil, ..."]

Les organismes notifiés sont les interlocuteurs directs des fabricants pour l’évaluation de conformité des dispositifs médicaux relevant des classes nécessitant une intervention tierce (IIa, IIb, III et certains I stériles / mesurage).

Un fabricant peut en principe choisir n’importe quel organisme notifié désigné pour le MDR. Il n’y a donc pas d’obligation de choisir un NB dans son propre pays — la certification est valable dans toute l’Union européenne.

Chaque NB est :

• désigné par une Autorité Compétente (CA) nationale ;
• notifié à la Commission européenne ;
• autorisé pour certains types de dispositifs et certaines classes de risque uniquement (périmètre de désignation précis et public dans NANDO).

Le pari initial de l’Europe était de stimuler la concurrence en favorisant la désignation de plusieurs organismes notifiés (Notified Bodies – NB).

Dans les faits, la transition vers le Règlement (UE) 2017/745 (MDR) a entraîné une forte réduction du nombre d’organismes désignés, alors même que le volume de dispositifs à certifier a considérablement augmenté. Résultat :

• engorgement des organismes notifiés,
• délais d’accès très longs pour les fabricants,
• tension importante sur les calendriers de certification.

Critères pour qu’un logiciel soit un DM logiciel

Exemples et références :

• Le logiciel ou l’application santé que je vais mettre sur le marché relève-t-il du statut de dispositif médical (DM) ou de dispositif médical de diagnostic in vitro (DM DIV) ?
• Exemples de logiciels et applications mobiles illustrant le positionnement réglementaire
• Logigramme d’aide à la qualification du logiciel DM
• MDCG 2019-11 Rev.1 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR

Les ISO du DM logiciel

Lorsqu’on traite des dispositifs médicaux logiciels, il est crucial de distinguer le scope « personne morale » (l’organisation/fabricant) du scope « produit » (le dispositif logiciel lui-même). Cette distinction est cruciale car elle détermine la norme qui doit s’appliquer.

Toutes les montées de versions ne nécessitent pas une requalification DM mais l’application des ISO 13485, ISO 14971 et IEC 62304 impose de définir en amont comment sont gérées les évolutions et montées de version du DM.

Le plus structurant / utile : ISO 13485:2016 (Systeme de Management de la Qualité)

La norme ISO 13485:2016 est la pierre angulaire pour structurer le développement, la maintenance et la surveillance des dispositifs médicaux, y compris les logiciels. Elle agit à l’échelle de l’organisation et fournit le cadre pour documenter les processus et responsabilités.

Principes clés

• PDCA (Plan – Do – Check – Act) : planifier, exécuter, contrôler, agir pour améliorer continuellement le Système de Management Qualité (SMQ).
• CAPA (Corrective and Preventive Action) : actions correctives et préventives pour traiter non-conformités et incidents.

Même sans marquage CE immédiat, la mise en place d’un SMQ permet :

• de documenter les cas d’usage et process ;
• de créer une base de connaissance pour l’équipe et les nouveaux arrivants ;
• de préparer le terrain pour un futur marquage CE ou pour un accompagnement par un organisme notifié.

Cet exercice peut se faire en imaginant que l’on rédige la documentation d’ “onboarding” d’un nouvel arrivant qui pourrait comprendre comment fonctionne l’organisation puis le produit rien qu’en lisant, et qu’il y trouverait les réponses à ses questions:

• “comment vous gérer les authentification, les backup, tel ou tel type de risque…”
• pour un dev: “comment je setup, comment on livre, qui reviews…””
• pour du support: “quelles sont les conversions de tickets”
• “qui fait la veille”
• …

L’effort doit être proportionnel à la taille du DM et de l’équipe : trop détailler pour rien peut être frustrant.

Le scope de l’ISO 13485:2016 est l’organisation:

7 et 8 peuvent faire le lien au niveau produit avec:

• IEC 62304 : plan de développement logiciel, tests unitaires et d’intégration
• IEC 62366 : analyse ergonomique et tests d’utilisabilité
• ISO 14971 : plan de gestion des risques, analyse et matrice des risques

Points de vigilance

• Le SMQ ne garantit pas la qualité scientifique ou clinique du logiciel : il garantit que les tests et process sont planifiés, documentés et appliqués.
• Si les tests sont mal conçus ou incomplets, le DM logiciel peut être conforme au niveau réglementaire mais inefficace ou incorrect.

En pratique : même avant toute certification CE, initier le SMQ et documenter les process est l’exercice le plus structurant pour un DM logiciel, interne ou destiné au marché.

Stratégie 1 : s’organiser pour proposer un « service » plutôt qu’un « logiciel »

“logiciel” vs “service”

Dans « DM logiciel », il y a bien logiciel.

Le guide MDCG 2019-11 Rev.1 définit le software comme :

“a set of instructions that processes input data and creates output data” (« un ensemble d’instructions qui traite des données d’entrée pour produire des données de sortie »).

Un logiciel est donc un produit constitué d’instructions exécutables produisant un résultat déterminé.

Un service (prestation intellectuelle, conseil, interprétation humaine, télésurveillance réalisée par un professionnel, etc.) n’est pas un logiciel au sens de cette définition.

Par conséquent :

• un service seul n’est pas un dispositif médical ;
• il ne relève pas du MDR en tant que tel.

⚠️ En revanche, un service peut s’appuyer sur un logiciel.

Attention : si le service manipule des données de santé, il reste soumis :

• au Code de la Santé Publique (France),
• au RGPD,
• au référentiel CHDS et à ses exigences ISO 27001 sur les périmètres physiques et organisationnels.

Implication : embarquer un logiciel dans un service non classé fait peser la responsabilité réglementaire sur le fournisseur du service.

Stratégie 2 : développer le logiciel en interne à l’hôpital

Une autre approche pour éviter qu’un logiciel devienne un DM logiciel consiste à le développer et l’utiliser exclusivement en interne, au sein de l’établissement de santé (“fabrication in-house”). Cela repose sur le cadre de l’Article 5(5) du MDR.

Référence : Article 5(5) du MDR

“5. À l’exception des exigences générales en matière de sécurité et de performances énoncées à l’annexe I, les dispositions du présent règlement ne s’appliquent pas aux dispositifs fabriqués et utilisés exclusivement dans les établissements de santé établis dans l’Union, si toutes les conditions suivantes sont remplies:

a) les dispositifs ne sont pas transférés vers une autre entité juridique;

b) la fabrication et l’utilisation des dispositifs s’effectuent dans le cadre de systèmes de gestion de la qualité appropriés; …”

Pas considéré comme DM logiciel

Quand un logiciel in-house devient un DM logiciel

Un « logiciel interne » devient un dispositif médical logiciel dès que l’une des situations suivantes se produit :

• Partage avec un autre hôpital ou établissement de santé
• Déploiement régional ou à l’échelle d’un GHT
• existence d’un logiciel équivalent sur le marché
• Toute forme de distribution commerciale ou SaaS externe

Stratégie 3: modulariser

Une approche efficace pour réduire l’exposition au MDR consiste à modulariser le logiciel en isolant les parties sujettes à DM au sein de l’organisation et au sein de chaque produit

InterHop est née pendant la crise COVID, face à la centralisation massive des données de santé chez des clouders extra-territoriaux. Son combat emblématique est celui contre l’hébergement du HealthDataHub chez Microsoft Azure.

Projets phares de 2025

LibreDataHub.org - Plateforme de science des données

InterHop a continué à faire évoluer LibreDataHub, sa plateforme open-source de science des données, notamment avec une version 3 publiée en 2025. Cette version améliore la gestion des ressources serveur, intègre de nouveaux outils comme Airflow et MyST, renforce la sécurité, facilite l’installation et l’usage pour des équipes de recherche ou des institutions. Le support pour les GPUs et l’IA générative est aussi ajouté avec notamment l’implémentation dans LibreDataHub de Ollama.

LibreDataHub permet d’exécuter des environnements tels que Jupyter, RStudio, LinkR, Grafana, etc., tous accessibles via un navigateur dans un cadre collaboratif sécurisé.

La plateforme a également été déployée sur des serveurs certifiés Hébergeur de Données de Santé (HDS), ce qui renforce son utilisation sur des données sensibles en conformité avec la réglementation française et européenne.

LibreDataHub sert à la fois d’outil concret pour des projets collaboratifs de science des données, de support pédagogique (par exemple dans des cours universitaires) et d’infrastructure utilisée dans des datathons.

LinkR - Data science low-code

LinkR, au cœur de LibreDataHub, continue d’améliorer son ergonomie, d’enrichir la documentation et a abouti à la publication d’un article dans l’International Journal of Medical Informatics.

LinkR facilite l’analyse de données en santé avec une approche low-code, rendant accessible la data science à des clinicien·nes, chercheur·es et data scientists sans expertise avancée en programmation.

Rekkord.org - Sauvegarde chiffrée

En 2025, InterHop a propulsé Rekkord, un outil libre de sauvegarde chiffrée asymétrique. Présenté notamment dans l’émission Libre à vous ! sur Radio Cause Commune, Rekkord s’inscrit dans l’écosystème d’outils visant à garantir sécurité, autonomie et transparence dans la gestion de données.

Goupile - eCRF libre pour le recueil de données

En 2025, InterHop a poursuivi le développement de Goupile, son outil libre de création de formulaires et de cahiers d’observation électroniques (eCRF) dédiés à la recherche et aux enquêtes en santé. Les travaux menés, notamment dans le cadre du soutien du programme NGI Zero via la fondation NLnet, ont permis d’améliorer la robustesse du cœur applicatif, l’ergonomie de création des formulaires, la gestion hors ligne, l’internationalisation de l’outil ainsi que la qualité de la documentation.

Présence médiatique et évènement

Radio Cause Commune - “Libre à vous !”

En septembre 2025, InterHop était l’invitée de l’émission Libre à vous ! sur Radio Cause Commune, pour parler de son histoire, de ses valeurs et de ses outils libres pour la santé.

L’émission a permis de rappeler le militantisme de l’association, né de la résistance au projet de centralisation des données de santé (Health Data Hub) confiées à des infrastructures extra-européennes, et de présenter concrètement les outils (Matrix/Element, Goupile, Rekkord, LibreDataHub) développés ou promus par InterHop.

Datathon 2025

InterHop a organisé la 2ᵉ édition de son datathon autour de la science des données, les 11 et 12 septembre 2025 à Rennes, réunissant des participant·es pluridisciplinaires autour d’analyses collaboratives et de défis en data science.

Lors de cet événement, LibreDataHub a servi d’infrastructure principale pour les travaux, avec des serveurs mis à disposition par l’association et son clouder GPLExpert, renforçant l’engagement collectif autour des outils libres.

Plaidoyer : souveraineté, données de santé et faux-semblants

Non au transfert des données de 10 millions de Français

En 2025, InterHop a publié une prise de position forte contre le transfert des données de santé de 10 millions de personnes vers des infrastructures cloud extra-européennes. L’association y dénonce un choix politique lourd de conséquences, qui fragilise la protection juridique des données et renforce une dépendance structurelle à des acteurs privés non soumis au droit européen.

La “pseudo-souveraineté” numérique

Dans un autre article, InterHop a analysé les discours autour de la “souveraineté numérique”, pointant les contradictions entre les mots et les actes. L’association y rappelle que la souveraineté ne peut être réduite à des labels ou à des montages juridiques, mais qu’elle repose sur des choix techniques réels, des logiciels libres, des infrastructures maîtrisées et une gouvernance transparente.

Ces prises de position s’inscrivent dans la continuité du travail d’InterHop depuis plusieurs années : alerter, documenter et proposer des alternatives concrètes.

Une communauté avant tout

Comme les années précédentes, InterHop fonctionne grâce à une communauté de bénévoles et de sympathisants aux profils variés : développeur·euses, professionnel·les de santé, chercheur·euses, juristes, militant·es du libre. En 2025, cette dynamique collective a permis de maintenir les services, d’améliorer les outils et de nourrir une réflexion politique exigeante sur l’avenir du numérique en santé.

A ce titre les rencontres InterCHU vise à faciliter la coopération inter-hospitalière, le partage sécurisé de savoirs informatiques et l’autonomie des établissements face aux solutions propriétaires. L’association vous donne toujours rendez-vous environ une fois par mois lors de ces rencontres en visioconférence.

🚀 Perspectives 2026

Pour l’année à venir, InterHop se concentre sur plusieurs axes majeurs :

• Accroître les usages de nos outils Goupile (eCRF), LinkR (outil lowcode) et Rekkord au sein des communautés scientifiques, en facilitant l’accès aux outils d’analyse de données pour les chercheur·ses et professionnel·les de santé.

• Développer toujours sa communauté d’utilisatrices et de contributeurs plus large.

• Poursuivre le plaidoyer pour un numérique en santé réellement libre, éthique et souverain, en promouvant des solutions ouvertes et responsables.

Nous voulons particulièrement renforcer LibreDataHub. De nouveaux développements sont prévus, notamment autour du traitement du signal en anesthésie-réanimation. LibreDataHub sera également présenté lors du congrès d’informatique médical ÉMOIS 2026, à travers des retours d’expérience et d’un tutoriel d’utilisation de la plateforme.

Par ailleurs, en 2026, InterHop collabore avec l’association Latitudes pour expérimenter un outil libre visant à structurer automatiquement les informations contenues dans les ordonnances médicales. Ce projet permet de tester et d’améliorer des technologies d’intelligence artificielle en santé, en générant des ordonnances synthétiques (sans données sensibles), en reconnaissant automatiquement les médicaments et leurs dosages, et en rendant ces informations exploitables via une interface web ou une API. L’objectif est de faciliter le travail des professionnel·les de santé tout en respectant les principes du logiciel libre, de la sécurité et de la reproductibilité, et de contribuer à l’adoption de solutions IA ouvertes dans le secteur médical.

Comment faire un don ?

Votre soutien est essentiel pour continuer à porter des projets ambitieux en 2025. Vous pouvez faire un don directement sur notre site ici. Chaque contribution, même modeste, nous aide à aller plus loin et à rendre nos projets accessibles à tous.

Restez connectés

N’hésitez pas à suivre nos actualités sur Mastodon, Matrix et LinkedIn, et rejoignez-nous pour promouvoir un numérique éthique en santé.

Librement, InterHop

Le paradoxe des solutions “souveraines” françaises

Dans l’écosystème de la e-santé française, un phénomène inquiétant se développe : l’illusion de souveraineté.

Imaginons un chatbot médical se revendiquant “Made in France”, utilisant un modèle d’IA français comme Mistral, certifié HDS et conforme au RGPD. À première vue, tous les indicateurs de souveraineté semblent réunis. Pourtant, si à un moment de la chaîne de traitement - que ce soit pour l’hébergement de l’application, le stockage des données, ou l’infrastructure de calcul - les données transitent ou sont stockées sur des serveurs américains, l’ensemble de la solution devient vulnérable aux lois extraterritoriales américaines.

Cette situation illustre un problème systémique : derrière les étiquettes rassurantes de “Made in France”, “conforme RGPD” ou “certifié HDS”, se cache une réalité plus complexe. Une part importante de ces solutions repose sur des infrastructures cloud américaines, exposant ainsi les données de santé des citoyens français à des risques juridiques majeurs, indépendamment de la qualité ou de l’origine du modèle d’IA utilisé.

Le cadre juridique américain : CLOUD Act et FISA 702

Deux textes législatifs américains créent un risque structurel pour les données hébergées sur des infrastructures américaines, même situées en Europe :

• Le CLOUD Act permet aux autorités américaines d’exiger des fournisseurs de services cloud américains qu’ils transmettent des données stockées n’importe où dans le monde, y compris en Europe.

• La section 702 du FISA autorise les agences de renseignement américaines à collecter sans mandat individuel des données électroniques de non-Américains auprès de fournisseurs américains. Comme le souligne la CNIL dans son mémoire au Conseil d’État, cela soulève de sérieuses préoccupations quant à la souveraineté et à la confidentialité des données.

Une reconnaissance officielle au Sénat français

Cette réalité a été confirmée lors d’une audition au Sénat français en juin 2025, où un représentant de Microsoft France a reconnu ne pas pouvoir garantir que les données françaises ne seraient jamais transmises aux autorités américaines sans accord préalable des autorités françaises.

Cette déclaration met en lumière une vulnérabilité systémique qui touche l’ensemble des solutions françaises s’appuyant sur des infrastructures américaines.

L’ambiguïté de la certification HDS

La certification HDS (Hébergeur de Données de Santé), censée garantir la capacité d’héberger en toute sécurité des données de santé, n’exclut pas l’hébergement sur des infrastructures américaines. Cette certification se concentre sur la sécurité technique et organisationnelle, mais ne prend pas en compte les risques juridiques liés aux lois extraterritoriales américaines.

Un hébergeur peut donc être certifié HDS tout en exposant les données à un risque de réquisition par les autorités américaines.

Les conséquences de cette ambiguïté

Cette situation crée plusieurs problèmes majeurs :

• Pour les utilisateurs, qu’il s’agisse de professionnels de santé ou de citoyens, une confusion existe sur le niveau réel de protection de leurs données. L’affichage de labels “Made in France” ou de certifications peut créer une impression de sécurité qui ne correspond pas à la réalité juridique.

• Pour le débat public, cette ambiguïté complique la discussion sur la souveraineté numérique en santé et empêche une prise de décision éclairée sur les investissements nécessaires.

• Pour l’écosystème européen, tant que les solutions s’appuient massivement sur des infrastructures américaines, les investissements dans des alternatives véritablement européennes restent limités, bloquant l’émergence d’une autonomie stratégique.

Les principes d’une véritable souveraineté

Pour qu’une solution soit véritablement souveraine, plusieurs critères doivent être réunis :

• Être opérée par une entreprise non soumise aux lois extraterritoriales américaines
• Être hébergée sur des infrastructures européennes contrôlées par des entités européennes
• Utiliser des technologies open source permettant l’audit et la maîtrise technique
• Garantir juridiquement qu’aucun transfert de données ne peut avoir lieu sans accord des autorités européennes

Appel à l’action

Les pouvoirs publics doivent imposer une transparence réelle sur l’hébergement et le traitement des données de santé. Les acteurs de la e-santé doivent assumer clairement leurs choix technologiques. Les utilisateurs doivent être informés des risques réels associés aux solutions qu’ils utilisent.

Des investissements importants dans des infrastructures européennes souveraines sont nécessaires. Cette souveraineté a un coût, mais l’illusion de souveraineté pourrait nous coûter bien plus cher en termes de confiance, de sécurité des données et d’autonomie stratégique.

La souveraineté numérique en santé ne doit pas être une simple étiquette marketing, mais une réelle protection des droits fondamentaux des citoyens européens.

Cette émission était l’occasion de revenir sur la genèse d’InterHop, association qui promeut et propose des logiciels libres pour la recherche en santé.

Née en 2020 en réaction au projet de centralisation des données de santé via le Health Data Hub hébergé sur Microsoft Azure, l’association milite contre la dépendance à un cloud extra-européen et les risques liés à l’extraterritorialité des données. Elle défend l’usage de logiciels libres pour garantir transparence, auditabilité et autonomie dans la gestion des données sensibles de santé, tout en soulignant qu’il ne suffit pas d’avoir du code libre — il faut aussi maîtriser l’infrastructure et l’hébergement.

Les outils mis à disposition de l’association sont énumérés : une messagerie instantanée basée sur le protocole Matrix, des formulaires de recueil de données pour la recherche clinique Goupile, RekKord un outil de sauvegarde chiffrée ou encore LibreDataHub, une plateforme de data science légère et sécurisée pour les projets de recherche. Ces outils sont utilisés par des centres hospitaliers ou installés localement par ces derniers.

LibreDataHub a d’ailleurs été utilisée dans le cadre d’un datathon le datathon organisé récemment, utilisé comme levier pour tester des usages (notamment autour de l’IA et des GPU) sur LibreDataHub, et pour renforcer les liens de la communauté.

Voici quelques sources :

• linux.fr : linuxfr.org/news/interhop-des-logiciels-libres-pour-la-recherche-en-sante-libre-a-vous-du-16-septembre-2025
• retranscription : www.librealire.org/emission-libre-a-vous-diffusee-mardi-16-septembre-2025-sur-radio-cause-commune
• podcast : www.libreavous.org/254-interhop-des-logiciels-libres-pour-la-recherche-en-sante

Notre objectif est de réunir des professionnel·les de santé, des data scientists, des ingénieur·es et des designer·euses pour travailler ensemble sur des projets concrets dans le domaine de la santé numérique.

📅 Une réunion d’information en visioconférence aura lieu en visio le mardi 8 juillet à 13h, pour présenter le format du Datathon, les jeux de données, l’infrastructure, et répondre aux questions.

🔗 Plus d’infos sur l’événement : Page Datathon InterHop

🙏 Merci à l’Agence du Numérique en Santé, partenaire de l’événement !

🔍 Sources de données

• Base principale : MIMIC-III (Medical Information Mart for Intensive Care), adaptée au modèle OMOP CDM. L’ accès nécessite la création d’un compte sur physionet et la signature de l’accord sur l’utilisation des données (DUA).
• Possibilité de travailler avec des données synthétiques pour les projets sensibles ou expérimentaux (voir sujet “LLMs”).

🖥️ Infrastructure technique

• Accès à la plateforme LibreDataHub fournie par InterHop.
• Serveurs GPU fournis par notre prestataire HDS GPLExpert pour les projets nécessitant des capacités de calcul élevées (LLM, NLP, etc.).
• Apportez votre ordinateur portable !

💡 Sujets proposés

1. 🗺️ Cartographie de l’offre de soins

Compétences : Data Engineer · UX Design · Web

Objectif : Améliorer la plateforme carto.toobib.org, en enrichissant les données issues de FINESS avec celles d’OpenStreetMap (OSM), et en développant un export automatique vers data.gouv.fr.

Partenariat : Toobib.org, association militante pour un numérique en santé libre et éthique.

Sources utiles :

• RPPS
• CNAM - Annuaire santé
• FINESS
• Forum OSM - Offre de santé
• Alignements vers Base Adresse Nationale BAN et Référentiel National des Bâtiments RNB

2. 📊 Dashboard en anesthésie et réanimation

Compétences : Data Engineer · Data Science · UX Design · Web

Objectif : Concevoir des dashboards pour visualiser les indicateurs en anesthésie-réanimation à partir des extractions de logiciels métiers (Philips, Bow Medical), dans le modèle OMOP.

Partenaires : Philips, Bow Medical ainsi que des membres du groupe numérique de la SFAR (Société Française d’Anesthésie-Réanimation) seront présents pour nous aider.

Ressources :

• Development, implementation and preliminary evaluation of clinical dashboards
• The Development of a Clinical Dashboard for Monitoring of Key Performance Indicators in ICU
• How Do We Use Dashboards to Enhance Quality in Cardiac Anesthesia?

3. 🤖 LLM & Données Synthétiques

Compétences : Data Engineer · Data Science

Objectif : Générer un jeu de données synthétique (tabulaire, texte, voire image) au format OMOP à l’aide de LLMs open source.

Outils pressentis :

• Ollama
• DeepSeek

Ressources :

• OMOP CDM
• SynthMed - Synthetic Medical Images
• On LLMs-Driven Synthetic Data Generation, Curation, and Evaluation: A Survey
• Generating high-quality and diverse synthetic datasets with large language models: A survey
• A Text-to-tabular Approach to Generate Synthetic Patient Data using LLMs

4. 🏥 Maternité – Visualisation d’indicateurs

Compétences : Data Viz · Data Engineer · Data Science

Objectif : Dynamiser et visualiser les indicateurs d’activité des maternités françaises : césariennes, péridurales, transferts, etc.

Partenaires : Acteurs bretons de la périnatalité - Réseau Périnatalité Bretagne

Contexte : Suite du projet présenté en 2024

Ressources :

• Development of maternity dashboards across a UK health region; current practice, continuing problems.
• Identifying and Determining Effective Key Performance Indicators in the Development of Maternity Dashboard
• Quality indicator development and implementation in maternity units

5. 🧩 LinkR – Statistiques low-code

Compétences : R · Web · UX Design · Data Engineer

Objectif : Améliorer le module statistique de LinkR, outil low-code destiné aux pros de santé.

Fonctionnalités visées :

• Import automatisé des données
• Tests de qualité (données manquantes, valeurs extrêmes…)
• Statistiques automatiques selon les types de variables
• Génération de sections “Méthodologie” et “Résultats” pour la rédaction scientifique

6. 📄 Reconnaissance des ordonnances médicales (OCR & NLP)

Compétences : Data Engineer · NLP · OCR · Data Science

Objectif : Créer une pipeline d’analyse de documents médicaux PDF (ordonnances) pour extraire, structurer et normaliser les données (actes, médicaments, dispositifs).

Livrable souhaité : Une API open-source de reconnaissance et normalisation des ordonnances, compatible avec des ontologies de santé comme SNOMED CT ou CIM-10.

Ressources complémentaires :

• Deepparse (adresse et texte OCR)
• MedCAT – NLP médical
• OCRmyPDF
• Extraction of Medicine Names from Prescriptions Using Scanning Techniques
• Medical prescription classification: a NLP-based approach

💬 Vous avez une idée ?

Cette liste est ouverte et évolutive : les propositions spontanées sont encouragées ! Vous pouvez aussi rejoindre un sujet existant ou former une équipe autour de votre projet. L’important, c’est l’impact.

📩 Contactez-nous ou venez en discuter lors de la réunion d’information.

Depuis maintenant plusieurs années, le réseau InterCHU rassemble des ingénieur·es et professionnel·les de santé engagés dans la structuration et l’interopérabilité de données de santé. En partageant nos expériences, nos codes et nos outils, nous progressons collectivement vers des solutions ouvertes et interopérables pour la recherche. Aujourd’hui, notre réseau se renforce grâce à la participation de professionnels issus des CHU d’Amiens, Brest, Lille, Rennes, Rouen, Toulouse, Marseille mais aussi des hôpitaux Foch et de Saint-Malo.

Chaque rencontre sera l’occasion d’échanger sur les avancées, d’explorer de nouvelles perspectives et de renforcer notre dynamique collective autour des données de santé.

Voici le programme de la saison 2025.

La prochaine réunion aura lieu le vendredi 23 mai à 13h en visio : https://visio.octopuce.fr/b/int-a1t-rpf-huo

Nous accueillerons Alexandre PETIT, directeur interopérabilité chez BOW MEDICAL.
Il nous parlera des travaux autour du logiciel d’anesthésie-réanimation Diane et de l’interopérabilité.
Nous parlerons plus spécifiquement de l’utilisation secondaire des données et des modèles communs de représentation des données (OMOP, FHIR).

Pour plus d’informations sur InterHop et le réseau InterCHU : interhop@riseup.net

Pour être au courant des prochaines réunions vous pouvez nous rejoindre sur nos fils de discussion associatifs en vous inscrivant sur Element.

Le 11 mars, la Cnil a donné son feu vert au projet Darwin EU qui prévoit un transfert massif d’informations de la Cnam vers le géant de la Tech domicilié aux Etats-Unis et sous la coupe des autorités américaines. Un collectif prépare un recours devant le Conseil d’Etat et appelle syndicats, associations et personnalités à le rejoindre.

Voir l’article dans Libération

Une chance sur 7. Vous avez une chance sur 7 de voir vos données de santé migrer dans le cloud de Microsoft et tomber sous les lois américaines et donc sous le bon vouloir de son Président Donald Trump et du patron du DOGE, Elon Musk. Alors heureux ? Eh oui, vous faites peut-être partie des 10 millions de Français et Françaises tirés au sort dans le cadre du projet DARWIN EU coordonné par l’Agence européenne des médicaments et conduit, en France, par le groupement d’intérêt public « Plateforme des données de santé », plus connu sous le nom de Health Data Hub (HDH).

Dans une délibération publiée le 11 mars dernier¹, la Commission nationale de l’informatique et des libertés (CNIL) a donné son feu vert au HDH pour sélectionner un échantillon aléatoire de la population française de 10 millions de personnes représentatif en termes d’âge, de sexe et de département de résidence dans la base principale du Système national des données de santé. Les objectifs sont certes louables : déterminer en routine la prévalence et l’incidence de l’utilisation des médicaments et des vaccins en France selon une méthodologie standardisée.

Moins louable, l’hébergeur choisi pour stocker ces données, issues en grande majorité de la Caisse nationale d’assurance maladie, est l’entreprise Microsoft. En 2020, nous alertions déjà sur le fait que les données sensibles de santé de la population française tombaient sous le coup des lois américaines en raison de la domiciliation de Microsoft aux États-Unis dans le cadre d’une procédure en référé. En octobre 2020², le Conseil d’Etat reconnaissait ce risque d’extraterritorialité du droit américain. Un mois plus tard, dans un courrier daté du 19 novembre 2020, le Ministre de la santé, Olivier Véran³, engageait le Gouvernement à faire disparaître complètement, d’ici 2 ans, les risques que présente l’hébergement des données de santé par un opérateur américain.

Cinq ans ont passé : la solution technique est toujours Microsoft. Les autorités états-uniennes, aujourd’hui représentées par Donald Trump, peuvent adresser à Microsoft des injonctions de communication des données de santé de 10 millions de Français et Françaises (avec une profondeur historique de 9 ans, plus l’année en cours). Dans son avis du 11 mars 2025, la CNIL alerte à nouveau sur le risque “de communication à des puissances étrangères” des données de santé hébergées chez “un acteur soumis à un droit extra-européen”, et regrette l’absence de solution souveraine.

Ceux-là même qui, au Gouvernement, se targuent de défendre la « souveraineté » de notre pays nous mènent-ils en bateau depuis presque 10 ans ? La main sur le cœur, on nous dit qu’un appel d’offre est en préparation pour choisir un hébergeur européen. Paroles, Paroles.

Cela apparaît d’autant plus urgent que Donald Trump vient de paralyser l’agence de supervision indépendante - le Privacy and Civil Liberties Oversight Board – chargée de garantir un niveau protection « adéquat » à celui définit par le règlement européen RGPD et ainsi d’autoriser le transfert des données personnelles entre l’Europe et les États-Unis.

Aussi, face à l’inertie du Gouvernement, nous préparons un nouveau recours devant le Conseil d’Etat et appelons syndicats, associations et personnalités à nous rejoindre pour que les données de santé de 10 millions de Français et Françaises ne risquent pas d’être exploitées par des tiers non désirés.

Aujourd’hui, alors que le contexte international est bouleversé, que nos « amis » à la tête des Etats-Unis ne semblent plus l’être, nous - syndicats, associations et citoyens - réitérons nos demandes de solutions exclusivement soumises au droit de l’Union européenne pour nos données de santé destinées à des fins de recherche scientifique et de santé publique. Nous demandons également que des solutions déconcentrées soient recherchées. Pour que les discours sur la souveraineté numérique ne restent pas des paroles en l’air.

Signataires :

• Association Constances
• Association InterHop
• AIDES
• Ligue des Droits de l’Homme (LDH)
• Fédération SUD Santé Sociaux
• Syndicat de la Médecine Générale (SMG)

Depuis maintenant plusieurs années, le réseau InterCHU rassemble des ingénieur·es et professionnel·les de santé engagés dans la structuration et l’interopérabilité de données de santé. En partageant nos expériences, nos codes et nos outils, nous progressons collectivement vers des solutions ouvertes et interopérables pour la recherche. Aujourd’hui, notre réseau se renforce grâce à la participation de professionnels issus des CHU d’Amiens, Brest, Lille, Rennes, Rouen, Toulouse, Marseille mais aussi des hôpitaux Foch et de Saint-Malo.

Chaque rencontre sera l’occasion d’échanger sur les avancées, d’explorer de nouvelles perspectives et de renforcer notre dynamique collective autour des données de santé.

Voici le programme de la saison 2025.

La prochaine réunion aura lieu le mercredi 30 avril à 13h en visio : https://visio.octopuce.fr/b/int-a1t-rpf-huo

Nous accueillerons Thierry Dart de l’Agence du Numérique en Santé pour nous parler du Serveur Multi-Terminologies SMT.

Pour plus d’informations sur InterHop et le réseau InterCHU : interhop@riseup.net

Pour être au courant des prochaines réunions vous pouvez nous rejoindre sur nos fils de discussion associatifs en vous inscrivant sur Element.

Depuis maintenant plusieurs années, le réseau InterCHU rassemble des ingénieur·es et professionnel·les de santé engagés dans la structuration et l’interopérabilité de données de santé. En partageant nos expériences, nos codes et nos outils, nous progressons collectivement vers des solutions ouvertes et interopérables pour la recherche. Aujourd’hui, notre réseau se renforce grâce à la participation de professionnels issus des CHU d’Amiens, Brest, Lille, Rennes, Rouen, Toulouse, Marseille mais aussi des hôpitaux Foch et de Saint-Malo.

Chaque rencontre sera l’occasion d’échanger sur les avancées, d’explorer de nouvelles perspectives et de renforcer notre dynamique collective autour des données de santé.

Voici le programme de la saison 2025.

La prochaine réunion aura lieu le jeudi 27 mars à 13h en visio : https://visio.octopuce.fr/b/int-a1t-rpf-huo

Nous accueillerons Julien DUBIEL ingénieur au sein de l’EDS de l’APHP.
Il nous parlera d’un outil opensource développé au sein des équipes de l’APHP : Cohort360
C’est un outil de visualisation de cohortes de patients. Il permet de visualiser les données de cohortes sélectionnées automatiquement mais aussi affinées manuellement, avec la possibilité de visualiser des graphiques. Il permet également de réaliser des recherches puissantes directement dans les textes médicaux.

Pour plus d’informations sur InterHop et le réseau InterCHU : interhop@riseup.net

Pour être au courant des prochaines réunions vous pouvez nous rejoindre sur nos fils de discussion associatifs en vous inscrivant sur Element.

N’hésitez pas à nous contacter par courriel !

Si votre navigateur ne supporte pas les PDF, vous pouvez télécharger le fichier PDF.