E-santé et interopérabilité : ce qui peut changer le cabinet

L’interopérabilité n’est pas la capacité de copier un PDF d’un logiciel à un autre. Elle vise à transmettre une information structurée, comprise de la même façon et accessible uniquement aux personnes autorisées. Pour un cabinet d’ostéopathie, les changements pourraient concerner identité professionnelle, messagerie sécurisée, documents, consentement et continuité. Mais une norme technique ne crée jamais, à elle seule, un droit d’accès à une donnée de santé.

Validation humaine requise avant publication — Faire contrôler par l’Agence du numérique en santé ou un expert du cadre e-santé, un DPO et un juriste. L’éligibilité aux services doit être vérifiée selon le titre, le statut et l’enregistrement exacts du praticien. Cette prospective ne présume aucun droit d’accès au DMP ou à Mon espace santé.

En bref

• Fait : le CI-SIS publié par l’ANS définit des règles d’interopérabilité sémantique et technique pour les systèmes de santé.
• Fait : identification, authentification et habilitation répondent à des questions différentes ; une identité valide ne suffit pas à autoriser un accès.
• Signal : les services numériques nationaux imposent progressivement des référentiels communs aux logiciels.
• Scénario : un cabinet mieux connecté pourrait réduire les doubles saisies, à condition que droits, qualité des données et responsabilités soient explicites.
• Risque : multiplier les flux sans gouvernance augmente les destinataires, les erreurs de rapprochement et la surface d’incident.

Question et périmètre

Quels éléments de l’écosystème français d’e-santé peuvent transformer l’organisation d’un cabinet et quelles conditions empêchent les raccourcis ? L’article distingue faits actuels, signaux à surveiller et scénarios. Il ne décide pas si un ostéopathe particulier peut utiliser un service : certains détiennent aussi une profession de santé, d’autres non, et les habilitations peuvent différer.

Méthode de lecture

Consultation de la doctrine du numérique en santé, du Cadre d’interopérabilité des systèmes d’information de santé (CI-SIS), de Pro Santé Connect, MSSanté et des ressources CNIL. Nous n’utilisons pas les pages de fournisseurs pour décrire un droit. Pour chaque fonction, quatre contrôles sont séparés : identité, éligibilité, habilitation et traçabilité.

Faits établis en août 2026

Le CI-SIS fournit un langage commun

L’Agence du numérique en santé présente le CI-SIS comme un ensemble de règles destiné à permettre aux systèmes de partager de l’information de santé avec un sens conservé. Il comprend des volets de contenu et de transport ; son existence ne garantit pas qu’un logiciel implémente correctement tous les volets (ANS, CI-SIS).

Un document structuré peut distinguer auteur, personne concernée, date, type et sections. Cette structure facilite traitement et recherche, mais une donnée correctement encodée peut toujours être inexacte. L’interopérabilité améliore le transport du sens, pas la vérité clinique.

Pro Santé Connect traite l’authentification

Pro Santé Connect est un fournisseur d’identité pour des services numériques en santé. L’ANS indique qu’il permet aux professionnels enregistrés dans l’annuaire santé de s’authentifier via e-CPS ou carte CPS selon les conditions du service (ANS, Pro Santé Connect).

S’authentifier répond à « qui se connecte ? ». L’habilitation répond à « que cette personne peut-elle voir ou faire dans ce contexte ? ». Confondre les deux conduit à croire qu’un compte ou une carte ouvre tous les services.

MSSanté sécurise un espace d’échange défini

L’espace de confiance MSSanté vise les échanges sécurisés entre acteurs habilités et avec les usagers selon les services. L’ANS en publie le cadre et les opérateurs (ANS, MSSanté). La présence d’une adresse ne supprime pas la nécessité de vérifier destinataire, pertinence de l’envoi, information de la personne et minimisation du contenu.

Les données de santé restent soumises au RGPD

La CNIL rappelle que le professionnel libéral doit déterminer finalité, base juridique, durée, sécurité, destinataires et droits pour les traitements de données de santé. Externaliser vers un logiciel ou un service national ne transfère pas toute responsabilité au fournisseur (CNIL, professionnels de santé libéraux).

Signaux à surveiller

Signal 1 — Référencement et conformité des logiciels

La doctrine du numérique en santé décrit des référentiels de sécurité, d’identification et d’interopérabilité qui structurent les programmes publics. Le signal pour un cabinet est la montée d’exigences documentaires dans les cahiers des charges, mais le périmètre applicable à l’ostéopathie doit être vérifié (ANS, doctrine du numérique en santé).

Signal 2 — Identité professionnelle mieux normalisée

Le développement d’annuaires et moyens d’authentification communs peut simplifier la preuve d’identité. Il peut aussi révéler des divergences entre titre déclaré, statut, structure et logiciel. La qualité des données de référence devient une tâche de continuité.

Signal 3 — Documents plus structurés

Les éditeurs peuvent proposer des modèles compatibles avec des profils nationaux. Il faut surveiller si le document répond à un usage réel, quels champs deviennent obligatoires et si la structuration incite à collecter trop d’informations.

Signal 4 — Attentes croissantes de continuité

Patients et correspondants s’habituent à des échanges plus rapides et traçables. Ce signal ne crée pas une obligation de répondre instantanément. Les règles de canal, délai et urgence doivent rester explicites.

Trois scénarios conditionnels

Scénario A — Cabinet connecté avec droits clairs

Hypothèse : identité à jour, logiciel conforme au besoin, habilitations minimales et procédure de consentement. Effet possible : moins de ressaisie et documents mieux identifiés. Risque résiduel : donnée source erronée ou destinataire mal choisi. Indicateur : erreurs de rapprochement et accès refusés examinés chaque trimestre.

Scénario B — Interopérabilité de façade

Hypothèse : le logiciel exporte un PDF ou un format propriétaire présenté comme « compatible santé ». Effet : la transmission existe, mais le destinataire ne peut ni intégrer ni vérifier correctement. Signal d’alerte : absence de profil CI-SIS nommé, de test et de documentation de version.

Scénario C — Hyperconnexion sans gouvernance

Hypothèse : messagerie, agenda, formulaires et IA échangent automatiquement. Effet possible : rapidité, mais aussi propagation d’une erreur et multiplication des sous-traitants. Décision prudente : cartographier les flux, désactiver les intégrations sans finalité et tester restauration et révocation des accès.

Une matrice de contrôle avant tout nouveau flux

1. Quelle finalité précise justifie l’échange ?
2. Quelle donnée minimale est nécessaire ?
3. Qui est la personne ou le service destinataire ?
4. Quelle règle autorise l’accès dans ce contexte ?
5. Quel standard et quelle version sont utilisés ?
6. Comment l’erreur, le refus ou l’indisponibilité sont-ils gérés ?
7. Quel journal permet de reconstituer l’action ?
8. Comment retire-t-on un accès ou un connecteur ?

Cette matrice évite de réduire un achat à une liste de fonctions.

Niveaux de confiance

Élevé : existence des référentiels, nécessité de distinguer authentification et habilitation, protection des données de santé.

Modéré : extension des usages compatibles dans les cabinets, dépendante des éditeurs et règles d’éligibilité.

Faible : bénéfice quantifié pour les ostéopathes, faute de données indépendantes spécifiques sur temps gagné et incidents.

Ouvert : place exacte des ostéopathes exclusifs dans chaque futur service national.

Limites

L’écosystème change vite et les pages produits ne constituent pas un contrat d’éligibilité. Les règles peuvent différer selon double qualification, structure et territoire. L’article n’analyse ni chaque référentiel technique ni les conditions générales des éditeurs.

Implications pour la veille des praticiens

Tenez un inventaire des flux et versions plutôt qu’une liste de logos. À chaque annonce, demandez le texte d’éligibilité, le profil technique, la politique d’accès et le plan de panne. La question prioritaire n’est pas « le logiciel est-il connecté ? », mais « quelle information circule, pour quel usage, sous quel contrôle et avec quelle possibilité de correction ? ».

Cartographier une interopérabilité utile au cabinet

L’interopérabilité devient concrète seulement lorsqu’un flux part d’une situation de travail identifiable. « Envoyer des données » est trop vague. Il faut nommer l’événement déclencheur, la personne qui agit, le document ou le champ concerné, le destinataire, la raison de l’échange et le résultat attendu. Un compte rendu transmis à un correspondant, un rappel de rendez-vous et un export de fin de contrat n’ont ni la même finalité, ni les mêmes destinataires, ni la même durée de conservation. Les réunir sous une étiquette unique « connexion santé » empêche de vérifier les responsabilités.

Commencez donc par une carte de flux à petite échelle. Une ligne représente un seul événement. Elle indique le système source, la donnée minimale, le canal, le système destinataire, les personnes autorisées, le journal disponible et la conduite à tenir si la transmission échoue. Cette carte n’est pas une architecture informatique exhaustive : c’est un outil de décision. Elle permet de repérer une double saisie réellement coûteuse, un transfert manuel risqué ou, au contraire, une automatisation séduisante qui n’apporte aucune continuité utile.

Décrire le flux avant de choisir le standard

Le standard vient après le besoin. Pour chaque ligne de la carte, écrivez une phrase testable : « après validation du document par son auteur, transmettre cette version au destinataire désigné, sans pièce jointe superflue, et conserver la preuve de l’envoi ». Cette phrase force à distinguer création, validation et transmission. Elle évite qu’un brouillon devienne automatiquement visible ou qu’une correction reste sans effet chez le destinataire. Elle rend également visible la question de la version : quel document fait foi et comment une rectification est-elle signalée ?

Un format structuré peut aider les logiciels à reconnaître auteur, date, personne concernée et type de document. Il ne remplace ni le contrôle de l’identité, ni la qualité du contenu. Un champ bien codé peut contenir une erreur ; une identité bien rapprochée peut correspondre à la mauvaise personne si le contrôle initial est insuffisant. La promesse raisonnable est donc la conservation du sens défini par le profil d’échange, pas l’exactitude automatique de tout ce qui circule.

Séparer quatre couches de décision

Pour ne pas attribuer à une brique ce qu’elle ne garantit pas, examinez quatre couches. La couche sémantique demande si les deux systèmes comprennent les champs de la même manière. La couche technique demande si le message est transporté selon une version documentée. La couche de sécurité vérifie authentification, chiffrement, disponibilité et journalisation. La couche d’usage détermine enfin qui est autorisé, dans quel contexte et pour quelle finalité. Un connecteur peut réussir techniquement tout en échouant sur la sémantique ou l’habilitation.

Le CI-SIS et les orientations d’interopérabilité publiés par l’ANS décrivent ces enjeux au niveau national et orientent notamment vers des profils et standards partagés. Pour un cabinet, cette documentation sert de source de questions : profil nommé, version, périmètre testé, preuve de conformité, gestion des erreurs. Elle ne vaut ni certification générale de l’éditeur, ni autorisation d’accès à un service.

Identifier, authentifier, habiliter et tracer sans raccourci

Ces quatre verbes répondent à quatre questions différentes. Identifier consiste à rattacher une action à une personne ou une structure de référence. Authentifier consiste à vérifier qu’elle contrôle un moyen de connexion accepté. Habiliter consiste à déterminer l’action permise dans un contexte donné. Tracer consiste à conserver les éléments nécessaires pour reconstituer l’accès ou la transmission. Les fusionner dans une formule comme « accès professionnel sécurisé » masque les décisions qui doivent rester explicites.

L’identité de référence doit rester exacte

Un changement d’adresse, de structure, de statut ou de situation professionnelle peut créer un écart entre l’annuaire, le logiciel et les documents. Le cabinet doit donc savoir quelle source alimente chaque identité et qui corrige une divergence. Une bonne procédure comporte un contrôle lors de l’installation, un contrôle après toute modification administrative et une revue périodique. Elle n’a pas besoin d’accumuler des copies : elle doit surtout conserver la date, la source consultée et la correction demandée.

Selon l’ANS, la dernière bascule ADELI vers le RPPS a concerné les ostéopathes le 11 octobre 2024 afin de leur attribuer un numéro RPPS unique et pérenne. Cet identifiant national ne suffit toutefois pas à conclure qu’un service précis est ouvert. Le droit d’usage dépend encore de ses propres règles, du statut du praticien et parfois de la structure. Lorsqu’un praticien possède plusieurs qualifications, l’équipe doit savoir au titre de laquelle l’action est effectuée ; le logiciel ne devrait pas transformer cette pluralité en autorisation indistincte.

L’authentification n’est qu’une porte d’entrée

Pro Santé Connect et l’IGC Santé participent à une stratégie commune d’identification et d’authentification des acteurs. L’ANS précise toutefois que l’accès effectif dépend du service raccordé et de ses règles. La bonne question pour un éditeur n’est donc pas seulement « utilisez-vous Pro Santé Connect ? », mais « quelles catégories d’utilisateurs, quelles opérations et quelles restrictions avez-vous effectivement testées ? ».

Le cabinet doit aussi prévoir le retrait. Un compte partagé interdit d’attribuer correctement une action et complique la fermeture d’un accès. Préférez des comptes nominatifs, des droits minimaux et une procédure datée pour arrivée, changement de rôle et départ. Si une personne doit intervenir en urgence, documentez un accès exceptionnel plutôt que de conserver une permission large « au cas où ».

L’habilitation se prouve par le contexte

Être connu d’un annuaire ou posséder un moyen d’authentification ne répond pas à la question « puis-je voir cette information ? ». L’habilitation dépend de la finalité, du rôle, du lien avec la personne, du service et de ses textes. Pour chaque action sensible, le cabinet doit pouvoir formuler une règle compréhensible : qui peut consulter, créer, corriger, exporter ou supprimer, et sous quelles conditions. Une matrice simple vaut mieux qu’un profil « administrateur » utilisé pour tous.

Un refus d’accès n’est pas toujours un incident à contourner. Il peut signaler une identité incorrecte, une règle de service, une relation absente ou une permission retirée. Le processus de support doit permettre de qualifier le refus sans demander l’envoi de données de santé par un canal ordinaire. Une capture d’écran peut elle-même exposer des informations ; masquez les données non nécessaires et utilisez le canal convenu.

Construire le cahier de preuve d’un connecteur

Une démonstration commerciale montre un chemin heureux. Le cahier de preuve demande au contraire ce qui se passe lorsque l’identité diffère, que le destinataire est introuvable, que le réseau tombe, qu’un document est corrigé ou qu’un compte est fermé. Ce document doit rester court : une page de périmètre, une matrice des accès, cinq à dix cas de test et la liste des preuves conservées. Il sera réutilisé lors d’une mise à jour ou d’un changement d’éditeur.

Exiger un périmètre vérifiable

Demandez le nom précis du standard, du profil ou du volet, sa version, les opérations couvertes et les exclusions. « Compatible FHIR » ne suffit pas : FHIR est un ensemble vaste, et une mise en œuvre repose sur des ressources, profils, extensions et règles de transport particulières. De même, « compatible CI-SIS » doit renvoyer à des volets identifiés. Une déclaration sans rapport de test, environnement de démonstration ni politique de mise à jour ne permet pas de décider.

Vérifiez aussi la direction du flux. Un logiciel peut importer sans exporter, produire un document structuré sans intégrer celui qu’il reçoit, ou exporter seulement à la fin du contrat. Notez les formats, métadonnées, pièces jointes et journaux récupérables. La réversibilité est une fonction à tester pendant que le service fonctionne, pas une question à découvrir lors de la résiliation.

Tester les erreurs qui peuvent toucher une personne

Préparez au minimum les cas suivants : homonyme ou identité proche ; destinataire erroné ; document corrigé après envoi ; pièce jointe trop volumineuse ; connecteur indisponible ; transmission en double ; compte retiré ; export partiel. Pour chaque cas, observez le message affiché, l’état du document, le journal, l’alerte et la procédure de reprise. Un système silencieux après un échec est plus dangereux qu’un système qui refuse proprement.

Le test ne doit pas employer de vraies données patient si des données fictives suffisent. Créez un jeu de test clairement marqué et séparé de la production. Évitez néanmoins des valeurs trop irréalistes : elles peuvent ne pas révéler les problèmes d’accents, de noms composés, de changements d’adresse ou de dates. Documentez la suppression du jeu à la fin de l’essai.

Question	Preuve et décision
Quel profil et quelle version ?	Preuve : référence et périmètre écrits. Décision : ne pas qualifier la fonction d’interopérable sans eux.
Qui peut faire quoi ?	Preuve : matrice des rôles testée. Décision : limiter le pilote si elle manque.
Que devient une erreur ?	Preuve : journal, alerte et reprise. Décision : ne pas automatiser le flux sans eux.
Comment sortir ?	Preuve : export relu et procédure de fermeture. Décision : exiger une correction contractuelle si elle manque.

Protéger les données sans multiplier les copies

Chaque intégration crée potentiellement un nouveau destinataire, une nouvelle copie ou un nouveau journal. La CNIL rappelle aux professionnels libéraux qu’ils doivent définir finalités, bases, durées, destinataires, sécurité et exercice des droits. Le fait qu’un éditeur traite les données ne supprime pas les obligations du responsable de traitement. Le contrat et les annexes doivent décrire les rôles réels, pas seulement employer le mot « conforme ».

Pour limiter les copies, partez de la donnée minimale. Un rendez-vous peut nécessiter des coordonnées ; il ne justifie pas automatiquement un motif détaillé ou un document clinique. Un support technique a besoin d’un identifiant d’incident ; il ne devrait pas recevoir par défaut le dossier complet. Un tableau de pilotage peut fonctionner avec des volumes agrégés. À chaque nouveau flux, demandez si le même résultat peut être obtenu avec moins de champs, une pseudonymisation ou une durée plus courte.

Encadrer les sous-traitants et leurs propres prestataires

La fiche CNIL sur la sous-traitance recommande de vérifier garanties, instructions, confidentialité, sécurité, assistance, sort des données et audits. Pour un connecteur, identifiez l’éditeur, l’hébergeur, le service d’authentification, le routeur éventuel et le support. Une chaîne longue n’est pas nécessairement interdite, mais elle doit rester compréhensible et gouvernable.

Les mises à jour peuvent modifier cette chaîne. Ajoutez une obligation d’information suffisamment précoce et une revue déclenchée par tout nouveau sous-traitant, nouveau pays, nouvelle finalité ou nouveau type de donnée. La revue ne doit pas se réduire à accepter une nouvelle politique en ligne : elle doit vérifier l’effet sur la carte des flux et sur les personnes.

Prévoir l’indisponibilité et la correction

Une organisation interopérable reste capable de fonctionner lorsque le connecteur tombe. Décrivez le mode dégradé : où noter l’action à reprendre, comment éviter un double envoi, qui surveille le rétablissement et comment vérifier la cohérence après reprise. Le mode dégradé ne doit pas devenir un dossier parallèle durable. Une fois le service restauré, rapprochez les actions, corrigez les écarts et fermez le support temporaire.

La correction mérite sa propre procédure. Si une donnée transmise est inexacte, identifier le système source ne suffit pas : il faut savoir qui corrige, comment le destinataire est informé et si les journaux permettent de relier les versions. Automatisez seulement lorsque cette chaîne est testée. Sans elle, une automatisation rapide propage une erreur plus efficacement.

Un plan de mise en œuvre en six semaines

1. Semaine 1 — Cadrer : choisir un seul flux et écrire sa finalité, son déclencheur et son résultat.
2. Semaine 2 — Cartographier : lister données, acteurs, systèmes, sous-traitants et journaux.
3. Semaine 3 — Prouver : obtenir versions, périmètre technique, règles d’éligibilité et matrice des droits.
4. Semaine 4 — Tester : exécuter le chemin heureux et les erreurs importantes avec des données fictives.
5. Semaine 5 — Piloter : ouvrir à un périmètre réduit, suivre refus, doublons, corrections et temps de reprise.
6. Semaine 6 — Décider : maintenir, corriger ou retirer le flux selon les preuves, puis fixer la prochaine revue.

Ce calendrier n’est pas une norme : un flux complexe peut demander davantage de temps. Il protège toutefois l’ordre des décisions. L’équipe ne généralise pas avant d’avoir observé la sécurité, l’usage et la réversibilité sur un périmètre limité. Lorsque le flux vient d’un agenda, reprenez également les tests du guide Agenda et rendez-vous : choisir ses critères avant l’outil.

Décider aujourd’hui sans spéculer sur l’éligibilité

Au 29 août 2026, l’écosystème national continue d’évoluer. Les fondations de la doctrine — identité, sécurité, interopérabilité et éthique — fournissent un cadre de lecture, mais chaque service conserve son périmètre. Un cabinet d’ostéopathie ne doit donc ni s’exclure par principe, ni se déclarer éligible sur la seule présence d’un identifiant ou d’une carte. Il doit lire la règle du service, vérifier sa situation et conserver la réponse datée.

La décision robuste porte moins sur une promesse générale de « cabinet connecté » que sur un flux démontré. Si finalité, données, droits, erreurs, journal et sortie sont clairs, le pilote peut commencer. Si un seul de ces éléments manque, l’équipe garde le processus manuel ou limite la fonction jusqu’à obtention de la preuve. Cette discipline réduit les doubles saisies sans déplacer le risque vers une zone invisible.

Suivi éditorial

Sources contrôlées le : 29 août 2026. Prochaine revue prévue : 29 septembre 2026.

Sources primaires et officielles

• ANS, interopérabilité et orientations 2026 : Consulter la source officielle
• ANS, Pro Santé Connect et IGC Santé : Consulter la source officielle
• ANS, MSSanté : Consulter la source officielle
• ANS, fondements de la doctrine du numérique en santé : Consulter la source officielle
• ANS, bascule des professionnels ADELI dans le RPPS : Consulter la source officielle
• CNIL, RGPD et professionnels libéraux : Consulter la source officielle
• CNIL, gérer la sous-traitance : Consulter la source officielle

À lire ensuite

• IA et avenir du métier
• Hébergement des données de santé
• Habilitations et accès aux données