Un patient arrive aux urgences. Son dossier existe : chez son médecin de famille, dans le système du laboratoire qui a fait ses analyses il y a trois semaines, dans celui de la clinique spécialisée où il a été vu l’an dernier, dans la pharmacie qui délivre ses médicaments. Quatre systèmes contiennent chacun une partie de la réponse. Aucun ne la donne à l’équipe qui en a besoin maintenant.
On parle d’interopérabilité en santé depuis plus de vingt ans. Les normes existent, les investissements ont été massifs, les stratégies nationales se sont succédé. Et pourtant, dans la plupart des établissements, l’échange d’information passe encore par le télécopieur, le PDF et le téléphone.
Comprendre pourquoi demande de sortir d’un raccourci répandu : l’idée que l’interopérabilité serait un problème de connexion technique.
Échanger des données n’est pas être interopérable
L’interopérabilité se joue sur quatre niveaux, et les organisations n’en franchissent souvent qu’un ou deux.
Le niveau technique. Deux systèmes peuvent se connecter et se transmettre un fichier. C’est le niveau du tuyau. Il est aujourd’hui rarement le blocage principal.
Le niveau syntaxique. Le message reçu respecte une structure attendue : le système sait où trouver le nom, la date, le résultat. C’est le domaine des normes de format.
Le niveau sémantique. Le système receveur comprend ce que la donnée signifie. Un résultat de laboratoire codé d’une manière dans un système et d’une autre dans le système voisin peut être transmis parfaitement et rester inutilisable. C’est ici que se situe l’essentiel de la difficulté réelle.
Le niveau organisationnel. Les règles de gouvernance, de consentement, de responsabilité et de processus permettent effectivement l’usage de la donnée reçue. Un établissement peut être techniquement capable de recevoir une information et juridiquement ou organisationnellement incapable de s’en servir.
La plupart des projets d’interopérabilité budgètent le premier niveau, sous-estiment le troisième, et ignorent le quatrième.
Les trois blocages réels
L’héritage des systèmes en silo
Les systèmes d’information hospitaliers ont été construits par domaine : laboratoire, imagerie, pharmacie, admission, dossier clinique. Chacun a été acheté à un moment différent, à un fournisseur différent, avec son propre modèle de données et souvent son propre identifiant patient.
Ces systèmes fonctionnent. Ils ne sont pas défaillants, ils sont simplement conçus pour être complets à l’intérieur de leur périmètre. Les remplacer d’un bloc est rarement envisageable, financièrement comme cliniquement. L’interopérabilité consiste donc presque toujours à construire des ponts entre des systèmes qui n’ont pas été pensés pour en avoir.
La sémantique et les terminologies
C’est le blocage le plus coûteux et le moins visible.
Pour qu’une donnée clinique soit comprise sans ambiguïté par un système qui ne l’a pas produite, il faut qu’elle soit codée dans un référentiel commun : des terminologies standardisées pour les résultats de laboratoire, pour les diagnostics, pour les médicaments, pour les procédures. Ces référentiels existent et sont matures.
Le travail consiste à faire correspondre les codes internes de chaque système à ces référentiels. C’est un travail long, manuel par endroits, qui exige une expertise clinique en plus de l’expertise technique, et qui doit être maintenu dans le temps parce que les référentiels évoluent. Il n’est pas spectaculaire, il ne fait l’objet d’aucune démonstration convaincante, et il représente souvent la majorité de l’effort réel d’un projet d’interopérabilité.
Un projet qui n’a pas budgété l’alignement terminologique n’a pas budgété l’interopérabilité.
La gouvernance et le consentement
À qui appartient la donnée ? Qui autorise sa circulation ? Qui répond en cas d’utilisation non conforme ? Ces questions ne sont pas des formalités administratives à régler à la fin : elles déterminent l’architecture.
Au Québec et au Canada, l’encadrement des renseignements personnels de santé impose des exigences précises en matière de consentement, de traçabilité des accès et de finalité d’usage. Ces exigences ne s’ajoutent pas à un système déjà construit, elles se conçoivent avec lui. Un mécanisme de consentement granulaire imaginé après coup se traduit généralement par une couche applicative fragile, contournée par les utilisateurs dès qu’elle ralentit une prise en charge.
FHIR ne règle pas tout
Les normes modernes d’échange en santé ont considérablement simplifié la couche technique et syntaxique. Elles s’appuient sur des technologies web standards, elles sont documentées, elles disposent d’un écosystème actif. Leur adoption est une bonne décision.
Mais une norme d’échange définit un contenant, pas un contenu. Deux organisations peuvent être parfaitement conformes à la même norme et rester incapables d’exploiter mutuellement leurs données, parce qu’elles codent différemment ce qu’elles y mettent, ou parce qu’elles ont fait des choix d’implantation divergents sur les éléments optionnels.
C’est la raison d’être des profils d’implantation nationaux, qui restreignent la liberté laissée par la norme pour garantir une compréhension commune. Adopter la norme sans adopter le profil, c’est parler la même langue avec un vocabulaire différent.
Par où commencer
Un projet d’interopérabilité qui vise l’ensemble du système d’information dès le départ échoue presque toujours. Une démarche par étapes donne de bien meilleurs résultats.
- Partir d’un cas d’usage clinique précis. Pas « connecter nos systèmes », mais par exemple : permettre à l’urgentiste de voir les résultats de laboratoire externes des trente derniers jours. Un cas d’usage étroit force à définir exactement quelles données, pour qui, dans quelles conditions, et rend le succès mesurable.
- Cartographier le flux réel. Où naît la donnée, par quels systèmes transite-t-elle, qui la saisit, qui la corrige, où sont les ressaisies manuelles. Cette cartographie révèle systématiquement des circuits parallèles que personne n’avait documentés.
- Évaluer la qualité avant de connecter. Connecter deux systèmes dont les données sont incomplètes ou incohérentes ne fait que diffuser le problème plus vite. Un audit de qualité et d’identification du patient précède toute intégration.
- Traiter la terminologie comme un chantier à part entière. Avec son propre responsable, son propre budget et son propre plan de maintenance.
- Fixer la gouvernance en même temps que l’architecture. Règles de consentement, traçabilité des accès, responsabilités en cas d’incident, processus de mise à jour. Écrites, validées, avant le développement.
- Mesurer. Nombre de demandes d’information transmises par télécopieur, délai moyen d’obtention d’un résultat externe, taux de ressaisie manuelle, nombre de doublons d’identité. Ces indicateurs, relevés avant le projet, sont la seule preuve possible de sa valeur.
Le coût de l’attente
L’absence d’interopérabilité a un prix quotidien qui n’apparaît dans aucun budget de projet : des examens refaits parce que le résultat précédent est introuvable, du temps clinique consacré à chercher de l’information, des décisions prises sans données complètes, des erreurs de médication évitables.
Ce coût est diffus, réparti sur des milliers de petites frictions, et c’est précisément pour cela qu’il est rarement chiffré et donc rarement combattu. Le mesurer, ne serait-ce que sur un seul parcours de soins, suffit généralement à déplacer le débat.
Vous travaillez sur un projet d’échange de données en santé ? Ruby Edge Consulting accompagne les établissements et les éditeurs sur l’interopérabilité et la sécurisation des échanges de données d’envergure, du diagnostic à la validation.
