Tout programme technologique en santé comporte désormais un chantier d'interopérabilité, et la plupart réussissent sur le papier. Un message est conforme à la norme, une API renvoie la charge utile attendue, un test d'intégration passe dans un environnement de préproduction. Puis le système entre en production et une infirmière ou un médecin ouvre encore trois fenêtres pour répondre à une seule question sur un patient. La norme a été respectée. Le flux de travail, non.
Cet écart entre conformité et expérience est l'endroit où une part importante des dépenses technologiques en santé sous-performe discrètement. Il vaut la peine d'être précis sur les raisons, car le correctif n'est presque jamais un énième moteur d'intégration ou une nouvelle version d'une norme de messagerie. C'est généralement une décision sur l'endroit où l'information doit apparaître, dans quel ordre, et sur la quantité que le clinicien doit reconstituer lui-même.
Le coût du changement de contexte
Le travail clinique est par nature un travail interrompu, si bien que chaque écran, connexion ou étape de recoupement supplémentaire n'est pas un simple désagrément : c'est une taxe sur l'attention à des moments qui comptent. Quand un résultat se trouve dans un système et l'historique des médicaments dans un autre, le clinicien devient lui-même la couche d'intégration, tenant les deux en tête et vérifiant leur cohérence.
Cela reste rarement visible dans les indicateurs remontés à la direction. La disponibilité est bonne, les volumes de messages sont bons, la norme est certifiée. Ce qui n'apparaît pas dans un rapport d'état, ce sont les quatre-vingt-dix secondes supplémentaires par patient que les cliniciens passent à reconstituer le tableau, multipliées sur un service, une garde, un hôpital.
Une norme certifiée garantit que la donnée peut circuler entre systèmes. Elle ne dit rien sur le fait qu'un clinicien doive encore reconstituer le tableau dans sa tête.
Les normes sont nécessaires, pas suffisantes
Rien de tout cela n'est un argument contre les normes. Une structure commune pour les données cliniques, des identifiants cohérents et des vocabulaires partagés sont ce qui rend l'intégration possible, et les organisations qui sautent cette étape se retrouvent avec des connexions point à point fragiles et coûteuses à faire évoluer.
L'erreur consiste à traiter la certification de conformité comme une ligne d'arrivée. La norme garantit que la donnée peut circuler et être comprise par un autre système. Elle ne dit rien sur la question de savoir si le système récepteur présente cette donnée au bon moment du flux de travail clinique, avec la bonne densité, sans exiger d'ouvrir autre chose d'abord.
- ·Cartographier le flux de travail clinique avant le flux de données, pour que l'intégration serve une séquence de décisions plutôt qu'une séquence de systèmes
- ·Traiter l'écran récepteur comme faisant partie du périmètre d'interopérabilité, et non comme un sujet aval confié à quelqu'un d'autre
- ·Tester avec les personnes qui utiliseront le résultat sous contrainte de temps, pas seulement avec des messages d'échantillon en laboratoire
- ·Mesurer les clics, écrans et connexions évités avec autant de sérieux que la conformité des messages
Où se trouvent généralement les coutures
Dans la plupart des programmes que nous observons, les coutures visibles se concentrent en quelques points : la conciliation des allergies et des médicaments entre soins primaires et secondaires, les comptes rendus de sortie qui arrivent sous forme de documents plutôt que de données structurées, et l'appariement d'identité lorsque le même patient existe sous des données démographiques légèrement différentes dans plusieurs systèmes.
Chacun de ces points a un correctif technique, mais chacun a aussi une dimension de gouvernance et de flux de travail facile à ignorer quand un programme subit une pression de calendrier. Corriger la couche technique sans corriger le flux de travail autour d'elle produit un système interopérable au sens de l'audit et toujours frustrant dans le service.
Concevoir pour le moment d'usage
Les organisations qui réussissent ont tendance à impliquer le personnel clinique tôt, non pas comme une étape de validation finale mais comme co-concepteurs de ce qui doit apparaître, quand, et dans quel ordre. Cela change le carnet d'intégration, car la priorité passe de ce qui est le plus facile à connecter à ce qui change réellement une décision clinique.
Cela change aussi la définition du succès. Un programme qui mesure sa réussite en interopérabilité uniquement par les normes adoptées et les messages échangés mesure le mécanisme, pas le résultat. Le résultat, c'est un clinicien qui fait suffisamment confiance à l'information affichée pour agir sans ouvrir un second système pour vérifier.
Les programmes d'interopérabilité continueront d'être jugés, à juste titre, sur les normes qu'ils adoptent, car ce sont les jalons les plus faciles à vérifier et à rapporter. Mais la norme est un moyen, pas une fin. La fin, c'est un clinicien qui traverse une rencontre avec un patient sans une friction qu'il ressent mais ne sait pas toujours nommer lors d'un point d'avancement.
Y parvenir suppose de traiter la conception du flux de travail comme un périmètre central plutôt qu'une couche accessoire ajoutée à un projet de messagerie, et d'admettre qu'une intégration techniquement conforme peut encore décevoir les personnes pour qui elle a été construite.