Livre blanc — Santé connectée : interopérabilité et sécurité des données patients

Livre blanc · Février 2026

Santé connectée : interopérabilité et sécurité des données patients

Faire circuler la donnée de santé sans jamais la perdre — ni la laisser fuir

« La donnée de santé a deux façons de ne servir à personne : rester enfermée dans un logiciel, ou finir sur un forum de rançongiciel. Tout ce document tient entre ces deux échecs. »

4 couches

1 identité

90 jours

d'interopérabilité — technique, syntaxique, sémantique, organisationnelle — et laquelle bloque vraiment vos projets

L'INS, socle de tout échange — et le chantier de qualité d'identités que personne ne budgète

Le plan d'action, de l'inventaire des flux au premier exercice de crise cyber

Ce livre blanc s'appuie sur les missions de pilotage digital du réseau Clarendis auprès d'établissements et d'acteurs de la e-santé ; il se lit seul, et se relit à chaque nouveau projet d'échange de données.

Sommaire

Avant-propos 03 Synthèse exécutive — le document en dix affirmations 04 Votre parcours de lecture 06 1 Le malentendu de la santé connectée L'outil n'est pas le projet · Ce que le cadre exige déjà — Ségur, INS, Mon espace santé · Ce que coûte le statu quo · La question qui ordonne tout 07 2 L'interopérabilité : quatre couches, une identité Les quatre couches · L'INS, socle de tout · Les services socles — DMP, MSSanté, Pro Santé Connect · FHIR et le CI-SIS · Ce qui casse en pratique 12 3 La sécurité : le socle réglementaire et l'architecture RGPD et données de santé · HDS · NIS2 et le programme CaRE · L'architecture qui résiste : identités, segmentation, sauvegardes · Le facteur humain 18 4 Les angles morts Les dispositifs connectés · Le shadow IT soignant · Les sous-traitants · La télésurveillance · Les données de recherche · Le DPI historique · La crise cyber 25 5 2026-2031 : la trajectoire européenne L'EHDS, l'espace européen des données de santé · Usage primaire, usage secondaire · De la conformité à la valeur · Les décisions sans regret de 2026 31 6 Le plan d'action 90 jours D'où partez-vous ? · J1-J30 : voir clair · J31-J60 : fiabiliser les fondations · J61-J90 : éprouver — flux pilote et exercice de crise · Le tableau de bord en cinq nombres 35 Passer à l'exécution 40 Annexes — Glossaire, références, à propos de Clarendis 41

Avant-propos

La santé française vit un paradoxe numérique. Jamais autant de données n'ont circulé — comptes rendus dans Mon espace santé, résultats de biologie en messagerie sécurisée, objets connectés au domicile des patients — et jamais les deux reproches symétriques n'ont été aussi vifs : « je ressaisis tout, rien ne se parle » d'un côté ; les établissements paralysés par rançongiciel de l'autre. Interopérabilité et sécurité sont les deux faces d'un même sujet : la maîtrise du trajet de la donnée patient. On les confie pourtant, presque partout, à deux équipes qui ne se parlent pas.

Ce livre blanc est né d'un constat de mission : les projets de santé connectée qui échouent butent rarement sur la technique — ils butent sur des identités patients non qualifiées, des flux non inventoriés et des responsabilités non écrites. Les référentiels existent, les standards existent, les financements existent. Ce qui manque est une méthode qui les ordonne, et c'est ce que ce document propose : le cadre d'abord (chapitre 1), la circulation ensuite (chapitre 2), la protection (chapitre 3), les angles morts (chapitre 4), la trajectoire européenne (chapitre 5), et un plan exécutable (chapitre 6).

Une précision d'honnêteté intellectuelle : nous ne vendons ni DPI, ni hébergement, ni solution de cybersécurité, et nous ne percevons aucune commission de prescription. Chaque affirmation réglementaire s'appuie sur un texte ou un référentiel public, listés en annexe ; ce qui relève de notre expérience de terrain est signalé comme tel.

Comment lire ce document. Les chapitres sont autonomes. Si vos projets d'échange patinent, commencez par le chapitre 2. Si le dernier audit de sécurité vous a inquiété, le chapitre 3 est votre plan. Si vous préparez 2027 et l'espace européen des données de santé, le chapitre 5 vous attend. Chaque chapitre se clôt par le même encart, ce que ça change pour vous, décliné pour trois lecteurs : le dirigeant d'établissement ou d'entreprise de santé, le DSI, le RSSI ou DPO. C'est volontairement le même sujet vu sous trois angles, car ces projets échouent précisément là où direction, informatique et sécurité ne partagent pas la même carte.

Bonne lecture, et bons échanges — sécurisés.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

pour l'équipe Clarendis

Synthèse exécutive

Le document en dix affirmations. Chacune est développée et sourcée dans le chapitre indiqué.

1

2

Interopérabilité et sécurité sont un seul sujet. Les deux décrivent le trajet de la donnée patient : qui la produit, où elle passe, qui y accède. Les traiter séparément, c'est cartographier deux fois — ou pas du tout. (Chapitre 1)

Le cadre n'est plus une perspective, c'est un acquis. INS obligatoire, référencement Ségur des logiciels, alimentation de Mon espace santé, certification HDS des hébergeurs : les obligations structurantes sont en vigueur. La question n'est plus « faut-il ? » mais « où en sommes-nous réellement ? ». (Chapitre 1)

3

4

L'interopérabilité a quatre couches, et la plus dure n'est pas technique. Transporter (technique), structurer (syntaxique), se comprendre (sémantique), s'accorder (organisationnelle) : la plupart des projets bloquent sur les deux dernières — les terminologies et les responsabilités. (Chapitre 2)

Le premier chantier n'est pas l'outil, c'est l'identité patient. Tout échange repose sur l'INS qualifiée ; toute INS douteuse est un document qui ne part pas — ou pire, qui part dans le mauvais dossier. Le taux d'identités qualifiées est le premier indicateur du tableau de bord. (Chapitre 2)

5

6

FHIR est la langue de la décennie — le CI-SIS reste la grammaire française. Exigez les deux de chaque éditeur : conformité aux volets du cadre d'interopérabilité, et une API FHIR documentée, testable avant signature. (Chapitre 2)

La menace n'est pas hypothétique, elle est statistique. Le secteur santé reste l'une des premières cibles de rançongiciel en France ; l'enjeu n'est pas d'empêcher toute intrusion, mais de continuer à soigner pendant — segmentation, sauvegardes immuables testées, mode dégradé écrit. (Chapitre 3)

7

8

La conformité ne protège pas — elle finance et elle ordonne. RGPD, HDS, NIS2, programme CaRE : le mille-feuille converge vers quelques exigences simples (inventaire, identités, sauvegardes, exercices). Traitez-le comme un plan d'architecture financé, pas comme une pile d'attestations. (Chapitre 3)

Vos angles morts sont périphériques — donc décisifs. Dispositifs connectés jamais mis à jour, WhatsApp entre soignants, sous-traitants non audités, DPI historique inextricable : chaque angle mort du chapitre 4 est un chemin d'attaque ou une rupture de parcours patient. (Chapitre 4)

9

10

L'Europe fixe l'horizon : l'EHDS. Le règlement sur l'espace européen des données de santé est entré en vigueur en mars 2025 ; ses obligations s'appliqueront par paliers à partir de 2027-2029. Les choix de 2026 — formats, terminologies, architecture d'accès — décident du coût de cette échéance. (Chapitre 5)

La contrainte cache un actif. La même tuyauterie qui satisfait le régulateur ouvre trois chantiers de valeur : des parcours patients sans ressaisie, des données mobilisables pour la recherche et le pilotage, et une continuité d'activité qui devient argument de confiance. (Chapitre 5)

Par où commencer selon votre situation :

Rien n'est cartographié. Chapitre 1 (ce que le cadre exige déjà), puis directement le plan 90 jours du chapitre 6, séquence « départ à froid ». Votre priorité absolue : l'inventaire des flux et l'état de vos identités patients.

Les projets d'échange patinent. Chapitre 2 : les quatre couches vous diront laquelle bloque — c'est rarement celle qu'on instruit. Puis chapitre 4, §4.6 : le DPI historique est souvent le nœud.

L'audit de sécurité a fait peur. Chapitre 3 en entier, puis l'exercice de crise du chapitre 6 (J61-J90) : un plan de crise jamais joué n'est pas un plan, c'est un document.

Votre parcours de lecture

Votre parcours de lecture

Trois itinéraires balisés. Les encarts « Ce que ça change pour vous », en fin de chaque chapitre, sont écrits pour votre siège.

DIR Dirigeant 25 minutes

DSI DSI 1 h 30

RSSI RSSI / DPO 1 heure

01 Synthèse exécutive

Document complet recommandé. Votre chemin critique :

Vous vivez le sujet au quotidien. Votre chemin :

02 chapitre 1 (§1.3 : ce que coûte le statu quo, en langage business)

01 chapitre 2 en entier (les quatre couches, l'INS, les services socles)

01 chapitre 3 en entier (le socle réglementaire mis en ordre, l'architecture)

03 chapitre 3, §3.5 (le facteur humain — la décision d'arbitrage qui vous revient)

02 chapitre 3, §3.4 (l'architecture qui résiste)

02 chapitre 4 (les sept angles morts — votre plan d'audit de l'année)

03 chapitre 4 (votre carte des angles morts — DPI historique inclus)

04 chapitre 6, §6.4 (les cinq nombres à mettre à votre ordre du jour).

03 chapitre 2, §2.2 (l'INS : là où identitovigilance et sécurité se rejoignent)

04 chapitre 5, §5.3 (EHDS : les choix techniques de 2026)

04 les six encarts « RSSI / DPO », en fin de chapitre.

Vous saurez quoi financer, quoi exiger, et comment vérifier que ça avance.

05 chapitre 6 en entier — le plan est le vôtre.

Ce que vous êtes venu chercher

Besoin

Où

Sous quelle forme

Une carte du cadre réglementaire qui tient sur une page

Chapitres 1, 3

Ségur, INS, HDS, RGPD, NIS2, CaRE : qui exige quoi, de qui, et ce qui converge

Une méthode d'interopérabilité qui débloque les projets

Chapitre 2

Les quatre couches, l'INS, les services socles et la grille d'exigences éditeur

Une architecture de sécurité qui tient un rançongiciel

Chapitres 3-4

Identités, segmentation, sauvegardes immuables, mode dégradé — et les sept angles morts

Un plan exécutable demain

Chapitre 6

90 jours en trois temps, un flux pilote, un exercice de crise, cinq nombres

Chapitre 1

Le malentendu de la santé connectée

1

Avant de parler standards et pare-feu, il faut débarrasser le sujet de son malentendu fondateur — croire que la santé connectée est une affaire d'applications — et poser ce que le cadre français exige déjà.

1.1 L'outil n'est pas le projet

Dix ans de « virage numérique en santé » ont produit un réflexe : à chaque problème, une application. Prise de rendez-vous, télésurveillance, portail patient, plateforme de coordination — chacune achetée pour un besoin réel, chacune ajoutant sa base de patients, ses identifiants, ses exports. Le résultat de mission le plus constant que nous observons : l'établissement moyen ne souffre pas d'un manque d'outils, il souffre d'un excès d'outils qui ne partagent ni les identités, ni les données, ni les responsabilités.

La santé connectée n'est pas une collection d'applications : c'est un système de circulation. Une donnée patient naît quelque part (un DPI, un automate de biologie, un capteur), voyage (messagerie sécurisée, API, alimentation du DMP), et sert à quelqu'un (un soignant, le patient, un chercheur, un régulateur). Chaque maillon de ce trajet pose exactement deux questions : la donnée arrive-t-elle intacte et comprise ? — c'est l'interopérabilité ; n'arrive-t-elle qu'à ceux qui y ont droit ? — c'est la sécurité. Deux questions, un seul trajet : voilà pourquoi ce document traite les deux ensemble.

Ce renversement a une conséquence pratique immédiate : le premier livrable d'un projet de santé connectée n'est pas un cahier des charges d'outil, c'est une carte des flux. Qui produit quelle donnée, dans quel système, vers qui part-elle, par quel canal, sous quelle identité patient ? Cette carte — une page par domaine suffit — est le document le plus rentable du chapitre 6, et le plus souvent absent des projets que nous reprenons.

Sur le terrain. Dans un groupement d'établissements que nous avons accompagné, le recensement initial a dénombré 47 applications manipulant des données patients — la DSI en connaissait 31. Les 16 autres étaient arrivées par les services, les projets de recherche et les partenariats. Aucune malveillance : simplement personne n'avait la carte. C'est le point de départ le plus fréquent, et il n'est pas honteux — il est juste urgent.

1

Chapitre 1 — Le malentendu de la santé connectée

1.2 Ce que le cadre exige déjà

Le numérique en santé français n'est plus un champ de recommandations : c'est un cadre opposable, construit par strates depuis 2019, et dont l'essentiel est déjà en vigueur. Cinq briques structurent tout le reste :

Brique

Ce qu'elle impose

Où elle se joue chez vous

INS — identité nationale de santé

Référencer toute donnée de santé avec l'INS qualifiée du patient — obligatoire depuis 2021 pour tous les acteurs

Vos admissions, votre identitovigilance, chaque logiciel qui crée un dossier

Ségur du numérique

Des logiciels référencés (DPI, biologie, imagerie, officine…), financés pour alimenter les services socles

Vos contrats éditeurs : la version référencée est-elle déployée — et paramétrée ?

Mon espace santé / DMP

Alimenter le dossier du patient avec les documents clés — compte rendu, biologie, imagerie, lettre de liaison

Vos taux d'alimentation réels, service par service — pas le taux contractuel

HDS

Toute donnée de santé hébergée pour un tiers l'est chez un hébergeur certifié

Chacun de vos contrats SaaS — y compris les « petits » outils métiers

PGSSI-S / CaRE / NIS2

Un socle de sécurité opposable et, pour les établissements, un programme national financé d'exercices et de remédiation

Votre feuille de route sécurité — détaillée au chapitre 3

Deux lectures de ce tableau. La lecture défensive : « encore des obligations ». La lecture juste : l'État a construit, financé et rendu obligatoires les fondations que chaque projet local devait auparavant réinventer — une identité unique, des formats d'échange, un dossier patient national, un socle de sécurité. Le travail qui reste est le vôtre, mais il est désormais borné : brancher proprement vos systèmes sur ces fondations, et tenir la qualité de ce qui y circule.

D'où la question qui ordonne tout ce document, à poser avant tout achat : « pour chaque flux de données patients, savons-nous dire qui le produit, par où il passe, qui y accède — et sous quelle identité ? » Tout ce qui suit est une méthode pour répondre oui.

1

Chapitre 1 — Le malentendu de la santé connectée

1.3 Ce que coûte le statu quo

Le statu quo — des systèmes qui ne se parlent pas, une sécurité de périmètre vieillissante — a un coût, mais il est dispersé, donc invisible aux budgets. Le rendre visible est le premier acte de pilotage :

Le coût de la ressaisie. Chaque donnée qui ne circule pas est ressaisie — par une secrétaire médicale, une infirmière, le patient lui-même qui rapporte ses résultats. La ressaisie coûte du temps soignant, et elle coûte des erreurs : une partie des événements indésirables liés aux soins a pour origine une information absente, périmée ou rattachée au mauvais patient. C'est le coût clinique de la non-interopérabilité, et il se mesure — les revues de pertinence internes suffisent à l'objectiver.

Le coût de l'arrêt. Un rançongiciel dans un établissement de santé, ce n'est pas une indisponibilité informatique : ce sont des blocs déprogrammés, des transferts de patients, des semaines de fonctionnement au papier, et des mois de reconstruction. Les retours d'expérience publics des établissements touchés en France convergent : l'ordre de grandeur se compte en millions d'euros et en mois — sans compter ce qui ne se chiffre pas, la perte de chance et la confiance.

Le coût de l'opportunité manquée. Financements Ségur non mobilisés faute de prérequis, projets de recherche impossibles faute de données structurées, télésurveillance non déployée faute d'architecture d'accueil : le statu quo ne fait pas que coûter, il empêche de gagner.

3 coûts

1 carte

2 questions

Ressaisie · arrêt · opportunité — à objectiver chez vous, chiffres en main

Des flux de données patients — le premier livrable, avant tout achat

Arrive-t-elle comprise ? N'arrive-t-elle qu'aux ayants droit ? — sur chaque flux

1.4 À qui s'adresse ce document

Nous écrivons pour trois maisons qui partagent les mêmes obligations avec des moyens très différents : l'établissement de santé (public ou privé, seul ou en groupement), le médico-social et la ville (où les mêmes règles s'appliquent avec des équipes sans DSI), et l'entreprise de e-santé (éditeur, exploitant de télésurveillance, startup — pour qui la conformité est une condition d'accès au marché). Les principes sont communs ; quand une recommandation diverge selon la maison, nous le signalons.

Une conviction pour finir ce chapitre : dans la santé plus qu'ailleurs, la technique est au service d'une promesse simple — que la bonne information soit devant le bon soignant au bon moment, et devant personne d'autre. Chaque page qui suit se juge à cette aune.

1

Chapitre 1 — Le malentendu de la santé connectée

1.5 Les trois maisons, en pratique

Les principes de ce document sont communs ; leur mise en œuvre diffère profondément selon votre maison. Voici, pour chacune, le point d'entrée le plus rentable et l'erreur la plus fréquente :

Maison

Le point d'entrée rentable

L'erreur fréquente

Le chapitre à lire deux fois

Établissement de santé — public, privé, en groupement

La cellule d'identitovigilance dotée, et la gouvernance commune DSI-biomédical

Confier interopérabilité et sécurité à deux équipes qui ne partagent pas la même carte des flux

Chapitre 3 — les cinq barrières, sur financements CaRE

Ville et médico-social — cabinets, EHPAD, SSIAD, CPTS

Les services socles tels quels : MSSanté, Mon espace santé, e-CPS — sans projet d'infrastructure propre

Attendre un « projet SI » : la conformité passe ici par le paramétrage du logiciel métier référencé Ségur

Chapitre 2 — les quatre couches, version minimum viable

Entreprise de e-santé — éditeurs, télésurveillance, plateformes

FHIR + CI-SIS + HDS démontrés en bac à sable : la conformité comme argument de vente

Traiter la conformité en fin de roadmap, quand les acheteurs la posent désormais en prérequis d'appel d'offres

Chapitres 4-5 — télésurveillance, EHDS et le marché des 27

Trois maisons, un point commun : aucune ne peut plus traiter le sujet en silo. L'établissement dépend des logiciels de ville pour ses adressages ; la ville dépend des établissements pour ses retours d'hospitalisation ; l'entreprise de e-santé dépend des deux pour exister. La qualité du système se joue à la jointure — c'est précisément là que ce document place ses chapitres 2 et 4.

Pour les plus petites structures. Si vous n'avez ni DSI ni RSSI, le document reste lisible en une heure par le parcours « Dirigeant » — et le plan du chapitre 6 se réduit pour vous à cinq gestes : le logiciel référencé Ségur à jour et paramétré, l'INS qualifiée aux admissions, la MFA sur les accès distants, une sauvegarde testée, et le numéro du CERT Santé affiché. C'est déjà 80 % du chemin.

1

Chapitre 1 — Le malentendu de la santé connectée

Le modèle de décision datée, à copier tel quel

Comme dans chaque volume de cette collection, tout commence par une page signée. En santé, elle a une vertu supplémentaire : elle matérialise la responsabilité de la direction sur un sujet que NIS2 lui attribue désormais explicitement.

Décision de mise sous contrôle des données patients

« [Date]. La direction de [établissement / société] décide la mise sous contrôle des flux de données patients : interopérabilité et sécurité, conduites comme un seul programme. [Prénom Nom] est désigné(e) responsable. Jalons : carte des flux et des applications sous 30 jours ; état des identités patients et des sauvegardes sous 60 jours ; premier flux fiabilisé et premier exercice de crise sous 90 jours. Un journal de bord des incidents et décisions est ouvert à compter de ce jour. Signature. »

Ce texte ne s'envoie à personne : c'est une note interne. Elle date votre trajectoire — utile au régulateur, indispensable à vos équipes. Cinq lignes datées d'aujourd'hui valent mieux que dix pages datées du prochain incident.

Ce que ça change pour vous

DIR

DSI

RSSI

Dirigeant. Signez cette semaine la décision datée ci-dessus — une page, un responsable, trois jalons. Et posez la question des deux chiffres : combien d'applications manipulent des données patients, et combien la DSI en connaît. L'écart est votre vraie feuille de route.

DSI. Le premier livrable est la carte des flux, pas un schéma d'architecture cible. Une page par domaine : qui produit, où ça passe, qui accède, sous quelle identité. Le chapitre 2 vous donne la grille pour la remplir.

RSSI / DPO. La même carte des flux est votre registre des traitements rendu vivant. Chaque flux non cartographié est à la fois un trou RGPD et un chemin d'attaque non surveillé : vous avez désormais un argument commun avec la DSI pour l'obtenir.

Chapitre 2

L'interopérabilité : quatre couches, une identité

2

« Nos systèmes ne se parlent pas » est un diagnostic trop flou pour être traité. Ce chapitre le découpe en quatre couches — et montre pourquoi tout commence par l'identité du patient.

2.1 Les quatre couches — et laquelle bloque vraiment

Q uand deux systèmes de santé « ne se parlent pas », quatre choses très différentes peuvent être en cause. La couche technique : le tuyau existe-t-il — réseau, API, messagerie ? C'est la plus simple, et la seule que les projets instruisent spontanément. La couche syntaxique : le message a-t-il une structure convenue — un document CDA, une ressource FHIR, un message HL7 ? La couche sémantique : les deux systèmes donnent-ils le même sens aux mêmes codes — une créatinine codée en LOINC, un diagnostic en CIM, un acte en CCAM ? La couche organisationnelle : qui envoie quoi, quand, qui vérifie que c'est parti, qui traite les rejets ?

Notre constat de mission, constant : les projets achoppent aux couches trois et quatre, et dépensent aux couches un et deux. On achète un moteur d'intégration (technique), on négocie des formats (syntaxique) — et le projet meurt six mois plus tard parce que les libellés locaux du laboratoire n'ont jamais été alignés sur LOINC, ou parce que personne n'a décidé qui corrige une identité douteuse. Le budget des deux dernières couches — terminologies et procédures — doit être posé dès le premier jour, et il est humain plus que logiciel.

Le test des quatre couches. Prenez votre échange en souffrance et posez les questions dans l'ordre : le message part-il (technique) ? Est-il bien formé (syntaxique) ? Est-il compris à l'identique (sémantique) ? Quelqu'un s'en aperçoit-il quand il échoue (organisationnelle) ? La première réponse « non » — ou « on ne sait pas » — désigne le chantier. Dix minutes, et le débat « c'est la faute de l'éditeur » devient un plan d'action.

2

Chapitre 2 — L'interopérabilité

2.2 L'INS : le chantier n°1, et le plus sous-estimé

Tout échange de données de santé repose sur une certitude : les deux systèmes parlent du même patient. C'est le rôle de l'identité nationale de santé — le matricule INS (issu du NIR) et les cinq traits d'identité de référence, récupérés par téléservice auprès de l'Assurance maladie et qualifiés après vérification d'une pièce d'identité à haut niveau de confiance. Depuis 2021, référencer les données de santé par l'INS est une obligation pour tous les acteurs.

L'obligation est connue ; ses conséquences le sont moins. Une INS non qualifiée, et le document ne part pas vers Mon espace santé. Une identité en doublon, et l'historique du patient se fragmente en deux dossiers que personne ne réconciliera. Une collision — deux patients fusionnés — et c'est un risque clinique direct. Le taux d'identités qualifiées et le taux de doublons sont donc les deux premiers indicateurs de tout programme de santé connectée — avant tout indicateur technique. La cellule d'identitovigilance, longtemps fonction administrative discrète, devient l'équipe la plus stratégique du projet.

Trois chantiers concrets : la qualification au fil de l'eau (le téléservice INSi appelé aux admissions, avec la vérification de pièce d'identité outillée dans le poste de travail — pas dans un classeur) ; la reprise du stock (qualifier et dédoublonner l'existant, en commençant par les patients actifs) ; la propagation (chaque application périphérique — biologie, imagerie, spécialités — doit consommer l'INS du référentiel d'identités, jamais recréer la sienne).

2.3 Les services socles : ce qui existe déjà, à brancher

Service

À quoi il sert

Le piège classique

Mon espace santé / DMP

Le dossier national du patient, alimenté en documents structurés (comptes rendus, biologie, lettres de liaison) — consultable par le patient et les soignants autorisés

Alimenter sans vérifier : le taux d'échec silencieux (INS non qualifiée, document mal typé) n'est suivi par personne

MSSanté

Les messageries sécurisées de santé — l'échange de professionnel à professionnel, et vers le patient via sa messagerie citoyenne

La boîte organisationnelle que personne ne relève — l'équivalent numérique du fax oublié

Pro Santé Connect / e-CPS

L'identification des professionnels, adossée aux répertoires nationaux (RPPS) — le « qui accède » de tout service de santé connectée

Le maintenir pour les services nationaux et garder des comptes locaux partagés partout ailleurs

CI-SIS (ANS)

Le cadre d'interopérabilité : volets par cas d'usage, formats de documents, terminologies de référence publiées sur un serveur national

Le citer dans les marchés sans jamais recetter la conformité réelle des livraisons

La leçon transversale : ces services existent, fonctionnent et sont financés — le travail restant est le branchement et la qualité de ce qu'on y verse. Un projet local qui réinvente l'un d'eux se trompe de décennie.