Interopérabilité du SI hospitalier

Un résultat de biologie peut exister dans un logiciel sans jamais apparaître dans le dossier patient informatisé. Un compte rendu peut circuler par courriel au lieu d’alimenter automatiquement le bon dossier médical. Ces situations, banales dans beaucoup d’établissements, montrent que l’interopérabilité du SI hospitalier ne se résume pas à connecter deux applications entre elles. Elle suppose une architecture cohérente et des règles durables, que nous détaillons dans notre analyse de l’architecture et des obligations réglementaires du SIH.

Pour une direction des systèmes d’information de santé, le sujet touche directement la qualité des données de santé, la continuité des soins, la charge de travail des équipes et la capacité à faire évoluer le parc applicatif. La question n’est plus de savoir s’il faut échanger des données entre systèmes, mais quelles informations doivent circuler, avec quel niveau de contrôle et selon quelles normes.

Dans le secteur hospitalier, les établissements de santé font face à des défis multiples : multiplier les plateformes numériques sans perdre en cohérence, sécuriser l’accès aux dossiers médicaux, et répondre aux exigences réglementaires qui encadrent le partage des données de santé. Adopter une interopérabilité des données de santé solide demande du temps, des ressources et une vue d’ensemble du système d’information. Mais les coûts d’un SI cloisonné, entre ressaisies, erreurs et retards de prise en charge, dépassent souvent ceux d’une mise à niveau progressive.

Pourquoi l’interopérabilité change le quotidien de l’hôpital

Dans un établissement de santé, les données passent par de nombreux outils. Le DPI, la gestion administrative des malades, le laboratoire, l’imagerie, la pharmacie, les blocs opératoires, les dispositifs biomédicaux et les services administratifs ont chacun leurs propres contraintes et leurs propres formats.

Sans échange structuré, les professionnels compensent les limites du système par des manipulations manuelles. Ils téléchargent un document, le renomment, le déposent dans une autre plateforme ou ressaisissent une information déjà connue. Chaque étape ajoute un risque d’erreur, de retard ou de perte de contexte pour le patient.

L’interopérabilité permet au contraire de transmettre une donnée au bon endroit, dans un format exploitable, avec les éléments nécessaires à son interprétation. Un résultat de laboratoire ne doit pas seulement arriver dans le DPI. Il doit être rattaché au bon patient, associé à la bonne unité, horodaté, tracé et présenté avec une unité de mesure comprise par le système destinataire. C’est cette mécanique, répétée des milliers de fois par jour, qui contribue à améliorer la qualité des soins et à fluidifier le parcours patient.

Cette logique concerne aussi les échanges entre établissements et avec la médecine de ville. Les lettres de sortie, les comptes rendus d’imagerie, les prescriptions et les informations d’identité doivent accompagner le patient sans multiplier les ruptures de traitement. Pour approfondir l’organisation des applications, des données et des responsabilités, notre guide complet du système d’information hospitalier replace l’interopérabilité dans l’architecture globale du SI.

Les quatre niveaux à distinguer

Deux systèmes peuvent échanger des données sans réellement comprendre leur contenu. Cette distinction évite de déclarer un projet réussi alors que les équipes continuent, en pratique, à interpréter ou à ressaisir à la main les informations reçues.

L’interopérabilité technique est la base. Elle s’appuie sur des protocoles, des interfaces, des certificats, des règles réseau et des mécanismes d’authentification permettant de sécuriser chaque connexion. Elle ne suffit pas à assurer qu’un diagnostic ou un résultat biologique sera correctement interprété par le système qui le reçoit.

L’interopérabilité syntaxique apporte une structure commune. Les messages HL7, les documents CDA, les ressources FHIR ou les fichiers DICOM donnent aux systèmes un cadre partagé pour organiser l’information. L’interopérabilité sémantique va plus loin. Elle impose de partager le même vocabulaire, par exemple pour les examens, les médicaments, les pathologies ou les unités de mesure, et donc d’adopter des référentiels communs plutôt que des libellés locaux.

Le niveau organisationnel reste souvent le plus difficile à stabiliser. Deux établissements peuvent disposer d’interfaces compatibles, mais appliquer des règles différentes pour valider une prescription, corriger une identité ou partager un compte rendu. Le projet doit alors traiter les procédures et les responsabilités, pas uniquement les connecteurs techniques.

Les standards qui structurent les échanges

Un projet d’interopérabilité ne repose pas sur une seule norme. Chaque standard répond à un usage particulier et doit s’inscrire dans un ensemble cohérent de systèmes interopérables.

HL7 version 2 reste utilisé pour de nombreux flux événementiels, notamment les admissions, les mouvements de patients, les demandes d’examens et les résultats. HL7 CDA sert à structurer des documents cliniques, tandis que DICOM se concentre sur l’imagerie médicale et les informations associées aux examens.

FHIR adopte une logique plus modulaire. La spécification FHIR décrit des ressources comme Patient, Observation, DiagnosticReport ou MedicationRequest, échangées via des API et des formats courants comme JSON ou XML. Cette approche facilite l’accès progressif à l’information de santé sans reconstruire tout le système existant.

FHIR ne remplace pas automatiquement les autres standards. Dans de nombreux établissements, les flux historiques continuent de fonctionner pendant que de nouvelles interfaces sont développées en FHIR. La coexistence entre plusieurs générations de normes doit être assumée dans l’architecture, documentée et surveillée dans le temps.

Le cadre français ajoute des règles nationales, des profils d’intégration et des référentiels adaptés aux besoins du secteur de la santé. Le CI-SIS, l’Identité Nationale de Santé, les terminologies de référence, les services publics numériques et les exigences de sécurité doivent être pris en compte dès la conception des flux.

Dans son rapport d’activité 2025, l’Agence du Numérique en Santé met notamment en avant l’enrichissement des terminologies LOINC et SNOMED, ainsi que l’interconnexion accrue entre les systèmes d’information hospitaliers et médico-sociaux. Ces travaux montrent que la qualité du vocabulaire compte autant que le protocole de transport des données.

Pourquoi FHIR ne règle pas tout

FHIR facilite l’échange de données, mais il ne corrige pas une donnée mal saisie, une identité incertaine ou un processus mal défini. Une API bien conçue peut transmettre rapidement une information incomplète. Elle peut aussi diffuser une donnée dans plusieurs systèmes sans résoudre les divergences entre les référentiels locaux.

Avant de développer une interface FHIR, l’établissement doit répondre à plusieurs questions simples. Quelle donnée doit être exposée ? Qui peut la consulter ? Quelle est sa source de référence ? À quel moment est-elle considérée comme valide ? Comment gérer une correction ou une suppression ? Que se passe-t-il si le système destinataire est indisponible ?

Les terminologies jouent ici un rôle déterminant pour assurer la fiabilité des échanges de données. Un résultat biologique n’est exploitable que si le code de l’analyse, l’unité, la méthode et les valeurs de référence sont suffisamment explicites. Un médicament doit pouvoir être rapproché d’un référentiel commun, sans dépendre uniquement d’un libellé local.

Le projet doit aussi prévoir les cas d’erreur. Une identité non rapprochée, une ressource incomplète ou un message rejeté ne doit pas disparaître dans un journal technique inaccessible aux utilisateurs. Les équipes doivent savoir qui reçoit l’alerte, qui corrige la donnée et comment le flux est rejoué sans créer de doublon.

Cartographier les flux avant de moderniser

La cartographie constitue souvent le point de départ le plus utile. Elle donne une vue d’ensemble des flux officiels, des échanges historiques, des dépendances entre applications et des pratiques développées en dehors des circuits prévus.

Pour chaque flux, il faut identifier la source, le destinataire, le contenu, le format, la fréquence, le niveau de criticité, les règles d’accès et le responsable métier. Cette description doit couvrir les échanges internes, mais aussi les liens avec les laboratoires partenaires, les établissements du territoire, les professionnels libéraux et les services publics nationaux.

Un flux peut fonctionner depuis plusieurs années tout en reposant sur une configuration fragile. Un serveur intermédiaire oublié, une adresse réseau non documentée ou un certificat arrivé à expiration peuvent interrompre une chaîne complète de prise en charge du patient. La cartographie permet de hiérarchiser ces risques avant d’engager une migration.

Nous recommandons de distinguer trois catégories. Les flux critiques pour les soins doivent bénéficier d’une supervision et d’un plan de reprise adaptés. Les flux importants pour la gestion peuvent être modernisés selon les priorités du projet. Les flux secondaires peuvent être rationalisés ou supprimés lorsqu’ils ne répondent plus à un besoin réel.

Notre approche de cartographie des systèmes d’information s’inscrit dans cette logique. Elle relie la vision technique aux applications réellement utilisées, aux contraintes des métiers et aux dépendances qui pèsent sur la continuité d’activité.

Interopérabilité et sécurité doivent avancer ensemble

Chaque nouvelle interface élargit les possibilités d’échange, mais aussi le nombre de points à protéger. Une architecture interopérable et sécurisée doit limiter les accès, chiffrer les flux, journaliser les événements et vérifier les identités des utilisateurs et des systèmes.

La sécurité commence par une séparation claire des environnements. Les flux de production, de test et d’administration ne doivent pas être confondus. Les comptes techniques doivent disposer de droits limités et être renouvelés selon une procédure connue. Les certificats, clés et secrets doivent être inventoriés et surveillés en continu, avec des tests réguliers pour vérifier qu’ils tiennent la charge.

La traçabilité doit permettre de répondre à des questions concrètes. Qui a consulté une donnée ? Quel système l’a modifiée ? Quand le message a-t-il été reçu ? Pourquoi a-t-il été rejeté ? Ces informations servent à la fois la sécurité, le support et l’analyse des incidents, tout en protégeant la confidentialité des données des patients.

Notre offre associe conseil, hébergement HDS, infogérance, supervision SOC et NOC, audits de sécurité et préparation des plans de continuité et de reprise. Cette combinaison aide un établissement à ne pas traiter l’interopérabilité des données comme un chantier séparé de l’exploitation et de la cybersécurité.

La dimension européenne renforce cette exigence. Le règlement sur l’Espace européen des données de santé est entré en vigueur le 26 mars 2025. La Commission européenne prévoit des étapes d’application en mars 2029 pour les résumés de patients et les prescriptions électroniques, puis en mars 2031 pour les images médicales, les résultats de laboratoire et les comptes rendus de sortie.

Les systèmes de dossier médical électronique devront aussi respecter des exigences d’interopérabilité, de sécurité et de journalisation. La certification des systèmes EHR devient donc un sujet à intégrer dans les achats, les renouvellements de logiciels et les contrats d’interface.

Une méthode de déploiement réaliste

Un projet d’interopérabilité avance mieux lorsqu’il commence par un périmètre limité et mesurable. Chercher à connecter toutes les applications en même temps multiplie les dépendances et complique l’analyse des incidents.

• Cartographier l’existant en recensant les applications, les flux, les référentiels et les responsables.
• Prioriser les usages selon leur impact sur les soins, la sécurité, la charge des équipes et la continuité d’activité.
• Définir les données de référence pour les patients, les professionnels, les actes, les médicaments, les examens et les documents.
• Choisir les normes adaptées au type de flux, sans imposer FHIR là où un autre standard reste nécessaire pendant la transition.
• Tester avec les métiers sur des scénarios réels, notamment les admissions, les transferts, les résultats urgents et les situations dégradées.
• Superviser après la mise en production avec des indicateurs sur les rejets, les délais, les doublons, les erreurs d’identité et les interruptions.

La conduite du changement doit accompagner chaque étape. Un flux techniquement correct peut rester inutilisé si les professionnels ne savent pas où retrouver l’information, ou s’il ajoute une étape à leur travail quotidien. Les équipes médicales, soignantes, administratives, juridiques et informatiques doivent donc participer aux arbitrages pour faciliter l’adoption des nouveaux outils. Ce travail nécessite une communication continue entre les équipes métier et les équipes techniques, tout au long du projet.

Pour les établissements qui disposent d’un parc ancien, la modernisation progressive reste souvent préférable à une rupture complète. Des passerelles peuvent maintenir certains flux HL7 ou CDA tout en introduisant de nouvelles API FHIR. L’objectif est de réduire progressivement les dépendances, pas de remplacer tous les composants au même moment.

Notre accompagnement peut couvrir le diagnostic, la conception d’architecture, l’intégration, la supervision, la sécurité et la formation, avec des solutions adaptées à la taille, à l’architecture et au niveau de maturité de l’établissement. Pour replacer ces décisions dans une trajectoire plus large, notre analyse de l’évolution du SIH revient sur les transformations qui ont modifié les priorités des DSI hospitalières au fil des ans.

Ce qu’il faut retenir pour votre établissement

L’interopérabilité du SI hospitalier repose sur un ensemble de décisions techniques, sémantiques et organisationnelles. HL7, FHIR, CDA et DICOM facilitent l’échange de données, mais ils ne remplacent ni la cartographie des flux, ni la gouvernance des données, ni la sécurité. En 2026, les établissements français ont intérêt à avancer par domaines prioritaires, à documenter leurs interfaces et à préparer les prochaines exigences européennes sans attendre une refonte complète du système existant. Ce niveau de vigilance reste essentiel pour les flux critiques, ceux qui touchent directement la prise en charge du patient.