CI-SIS : ce que la nouvelle doctrine change pour l'interopérabilité des projets de santé

Numérique et IA en santé Publié le 07/07/2025 Dimitri Jorand

L'Agence du Numérique en Santé a publié le 30 juin 2025 une nouvelle doctrine et gouvernance du CI-SIS. Décryptage des cas d'usage, des rôles et de la checklist à suivre avant tout achat ou développement d'une solution de santé.

Le 30 juin 2025, l'Agence du Numérique en Santé a publié une nouvelle version de la doctrine et de la gouvernance du CI-SIS, le cadre d'interopérabilité des systèmes d'information de santé. Ce document technique clarifie les volets applicables, les instances de décision et les modalités de contribution des industriels. Pour un porteur de projet, cela change surtout la façon de choisir un format, de documenter un cas d'usage et de sécuriser un achat ou un développement logiciel avant tout déploiement.

Le CI-SIS, un cadre technique au service de l'échange de données de santé

Le Cadre d'Interopérabilité des Systèmes d'Information de Santé (CI-SIS) est publié par l'Agence du Numérique en Santé (ANS), opérateur de l'État en matière de e-santé. Le texte relève de la doctrine technique plutôt que de la loi : il rassemble des spécifications et des règles d'usage que les éditeurs et les établissements peuvent mobiliser pour faire communiquer leurs systèmes. La publication du 30 juin 2025 concerne la version 0.1.0 de la doctrine et de la gouvernance associée. Elle précise le périmètre des volets fonctionnels du CI-SIS (échange de comptes rendus, gestion des identités, sécurité des transactions) et la manière dont ces volets évoluent dans le temps.

Cette doctrine ne crée pas d'obligation nouvelle par elle-même. Son opposabilité dépend des référentiels auxquels elle est rattachée, notamment le cadre d'interopérabilité et de sécurité prévu par la réglementation applicable aux systèmes d'information partagés de santé. C'est un point essentiel à garder en tête avant d'en tirer des conséquences contractuelles.

Pourquoi cette doctrine intervient maintenant

La montée en charge des échanges de données de santé, entre établissements, avec la médecine de ville et avec les services numériques nationaux, a rendu nécessaire une clarification du rôle de chaque acteur autour du CI-SIS. Les retours d'expérience des dix dernières années ont montré que l'absence d'une gouvernance lisible ralentissait les projets : un éditeur pouvait se prévaloir d'une conformité partielle, un établissement pouvait se retrouver sans recours en cas de blocage technique, et les évolutions de volets n'étaient pas toujours anticipées par les équipes projet. La nouvelle doctrine répond directement à ces difficultés en formalisant un cycle de vie des volets, depuis leur mise en concertation jusqu'à leur publication et leur éventuel retrait.

Cette évolution s'inscrit aussi dans un mouvement plus large de structuration du numérique en santé en France, en cohérence avec les travaux menés au niveau européen sur le partage des données, comme le règlement européen sur les données applicable aux objets connectés et aux services numériques. Un établissement qui pilote plusieurs projets numériques en parallèle a donc intérêt à articuler sa feuille de route CI-SIS avec sa feuille de route de conformité aux autres textes applicables au numérique en santé.

Ce que la nouvelle gouvernance modifie concrètement

La gouvernance rénovée introduit une comitologie plus lisible : un comité de pilotage arbitre les priorités, des groupes de travail thématiques instruisent les évolutions de volets, et une procédure de consultation permet aux éditeurs et aux représentants des établissements de faire remonter des besoins avant publication d'une nouvelle version. Pour un directeur des systèmes d'information ou un chef de projet, cela signifie qu'il existe désormais un circuit identifié pour suivre les évolutions à venir plutôt que de découvrir un changement de format au moment d'un renouvellement de marché.

La doctrine distingue également plus nettement les rôles : l'éditeur qui conçoit un logiciel conforme aux spécifications, l'intégrateur qui adapte et paramètre la solution dans l'environnement de l'établissement, et le déployeur qui met le système en service pour des utilisateurs finaux. Cette distinction n'est pas un détail administratif : en cas de non-conformité constatée lors d'un contrôle ou d'un audit, la responsabilité contractuelle se répartit différemment selon le rôle exercé.

Cas d'usage concernés en priorité

Les volets aujourd'hui documentés couvrent en priorité l'échange de documents de santé (comptes rendus, lettres de liaison), l'identification des patients et des professionnels, et la sécurisation des transactions entre systèmes. Un projet de dossier patient informatisé, de messagerie sécurisée de santé ou de connexion à un service régional d'échange doit être évalué au regard du volet correspondant, et non d'une lecture globale et approximative du CI-SIS.

Articulation avec les autres référentiels du numérique en santé

Le CI-SIS ne fonctionne pas isolément. Il s'articule avec le cadre plus large de sécurité des systèmes d'information de santé et avec les référentiels d'identification électronique des professionnels et des patients. Une direction des systèmes d'information gagne à cartographier ces différents référentiels avant de lancer un appel d'offres, afin d'éviter des exigences contradictoires entre le cahier des charges technique et les obligations de sécurité déjà en vigueur. Cette cartographie peut s'appuyer sur une methode DESC : maitriser la CNV en un clin d'oeil pour recadrer sans braquer déjà utilisée par ailleurs pour la sécurité des soins, adaptée au contexte des systèmes d'information.

Sur le plan organisationnel, l'intégration d'un nouveau volet CI-SIS dans un système existant constitue un changement qui mérite d'être traité comme tel, avec une information des utilisateurs finaux, une période de test et un accompagnement des équipes. Les principes classiques de la methode SMART pour fixer des objectifs utiles en etablissement de sante s'appliquent pleinement à ce type de projet technique, souvent perçu à tort comme purement informatique alors qu'il concerne directement les pratiques professionnelles au quotidien.

La responsabilité du donneur d'ordre dans un projet d'interopérabilité

Un établissement sanitaire ou médico-social qui achète ou fait développer une solution reste responsable de la vérification de son interopérabilité effective, même lorsqu'il s'appuie sur les déclarations d'un éditeur. La doctrine du CI-SIS ne se substitue pas à une clause contractuelle : elle fournit un référentiel commun que l'acheteur public ou privé peut exiger dans son cahier des charges. En pratique, cela suppose de faire tester la solution sur un environnement de qualification avant la mise en production, et de documenter les écarts éventuels.

Le responsable de traitement au sens de la protection des données reste identifié séparément : la conformité technique au CI-SIS n'emporte pas automatiquement conformité au règlement général sur la protection des données. Les deux démarches sont complémentaires mais distinctes, et doivent être pilotées ensemble par la direction du système d'information et le délégué à la protection des données.

Cas concrets

Centre hospitalier de taille moyenne. Un CH qui prépare le renouvellement de son dossier patient informatisé intègre désormais dans son cahier des charges une exigence de conformité au dernier volet CI-SIS applicable à l'échange de comptes rendus, avec obligation pour l'éditeur de fournir un rapport de tests d'interopérabilité daté.

EHPAD rattaché à un groupement. Un EHPAD qui doit connecter son logiciel de soins à un dossier de coordination territoriale profite de la clarification des volets pour identifier précisément quel module de son éditeur doit être mis à jour, plutôt que de renégocier l'ensemble du contrat de maintenance.

Financement et accompagnement des projets d'interopérabilité

Les projets de mise en conformité avec les volets CI-SIS peuvent mobiliser des ressources internes limitées, en particulier dans les structures médico-sociales de taille modeste. Il est donc utile d'anticiper un plan de montée en compétences des équipes techniques et métiers concernées, en s'appuyant si besoin sur une bilan ANFH 2025 : mobiliser les dispositifs de formation au bon moment de la carrière. Cette montée en compétences concerne aussi les référents qualité et les responsables de la gestion des risques : au-delà des équipes informatiques, ils ont intérêt à comprendre les grandes lignes de la doctrine pour évaluer les impacts d'un projet d'interopérabilité sur la sécurité des parcours de soins.

Un chef de projet qui pilote plusieurs interfaces à mettre à niveau peut également s'appuyer sur les principes présentés dans santé mentale 2026 : ce que l'accélération gouvernementale implique pour les acteurs, transposables à l'évaluation de l'impact d'un déploiement technique sur les pratiques professionnelles.

Ce que votre organisation peut faire maintenant

Trois actions peuvent être engagées sans attendre une nouvelle version de la doctrine. D'abord, recenser les systèmes en place et les volets CI-SIS qu'ils mobilisent réellement. Ensuite, insérer dans les prochains marchés une clause de suivi des évolutions de doctrine, avec obligation de mise à jour par l'éditeur. Enfin, sensibiliser les équipes projet à la distinction entre doctrine technique, recommandation et obligation contractuelle, pour éviter les approximations lors des négociations.

Ce travail de cadrage rejoint plus largement une santé mentale au travail : passer de la sensibilisation à la prévention collective et peut s'appuyer sur une IA éthique en santé : appliquer le guide d'implémentation à un projet réel pour clarifier qui décide, qui exécute et qui contrôle la conformité technique.

Statuts des textes à ne pas confondre

Processus pour cadrer un projet à l'aune de la nouvelle doctrine

1. Identifier les systèmes d'information concernés par le projet et leurs interfaces existantes.
2. Recenser les volets CI-SIS applicables aux cas d'usage visés (documents, identités, sécurité).
3. Vérifier la version de doctrine et de volet à laquelle se réfère l'éditeur pressenti.
4. Intégrer une clause de conformité et de mise à jour dans le cahier des charges ou le contrat.
5. Prévoir un environnement de qualification pour tester l'interopérabilité avant mise en production.
6. Documenter les écarts constatés et le plan de remédiation avec l'éditeur.
7. Associer le délégué à la protection des données pour distinguer conformité technique et conformité RGPD.
8. Planifier une revue périodique des évolutions de doctrine publiées par l'ANS.

Checklist avant achat ou développement d'une solution

• Le cahier des charges cite la version de doctrine CI-SIS applicable au projet.
• Les volets fonctionnels concernés sont listés explicitement, pas de façon générique.
• L'éditeur fournit un rapport de tests d'interopérabilité daté et vérifiable.
• Le rôle de chaque partie prenante (éditeur, intégrateur, déployeur) est défini par écrit.
• Une clause de mise à jour en cas d'évolution de la doctrine est prévue au contrat.
• Un environnement de qualification est disponible avant la mise en production.
• La conformité RGPD est traitée séparément avec le délégué à la protection des données.
• Une revue de veille réglementaire est planifiée au moins une fois par an.

Conclusion

La publication de la nouvelle doctrine et gouvernance du CI-SIS par l'ANS en juin 2025 clarifie utilement les responsabilités et le circuit de décision autour du cadre d'interopérabilité des systèmes de santé. Pour les établissements, l'enjeu est moins de suivre chaque évolution technique dans le détail que d'intégrer un réflexe de vérification systématique avant tout achat ou développement logiciel, et de distinguer clairement ce qui relève de la doctrine technique de ce qui relève d'une obligation contractuelle ou réglementaire. Ce travail de cadrage gagne à s'appuyer sur une la methode SMART pour fixer des objectifs utiles en etablissement de sante associant DSI, direction qualité et représentants des utilisateurs.

Questions fréquentes

Le CI-SIS est-il une obligation légale pour tous les établissements de santé ?

Le CI-SIS est une doctrine technique publiée par l'Agence du Numérique en Santé. Il devient contraignant lorsqu'il est repris dans un référentiel rendu obligatoire par un texte distinct ou dans un contrat. Il convient de vérifier au cas par cas le fondement de son opposabilité.

Que change concrètement la version 0.1.0 publiée le 30 juin 2025 ?

Elle clarifie la gouvernance du cadre, avec une comitologie et une procédure de consultation des parties prenantes, ainsi que la structuration des volets fonctionnels utilisés pour les échanges de données de santé.

Qui est responsable si une solution achetée n'est finalement pas interopérable ?

La responsabilité se répartit selon les rôles contractuels entre éditeur, intégrateur et déployeur. Le donneur d'ordre reste responsable de vérifier la conformité annoncée avant la mise en production.

Le CI-SIS remplace-t-il les exigences de protection des données personnelles ?

Non. La conformité technique au CI-SIS est distincte de la conformité au règlement général sur la protection des données, qui reste pilotée séparément par le responsable de traitement et le délégué à la protection des données.

Comment suivre les évolutions futures de la doctrine CI-SIS ?

L'Agence du Numérique en Santé publie ses actualités et ses référentiels sur esante.gouv.fr. Une revue périodique de ces publications, intégrée à la veille réglementaire de l'établissement, est recommandée.

Faut-il exiger un rapport de tests d'interopérabilité auprès de chaque éditeur ?

C'est une bonne pratique. Ce rapport permet de documenter la conformité déclarée par l'éditeur et de limiter les litiges en cas de non-conformité constatée après la mise en service.