Interopérabilité en santé : relier les données au parcours de soins

Pour qu’une donnée change quelque chose dans la prise en charge, cinq questions doivent trouver une réponse, du système qui l’émet à celui qui la reçoit.

Les trois premières relèvent des normes et des référentiels. Les deux dernières sont souvent oubliées : la provenance, qui dit quelle confiance accorder à la valeur, et l’organisation, qui dit qui la lit et dans quel délai. Un projet qui s’arrête aux premières produit un flux techniquement correct que personne n’exploite.

Un projet ne devrait pas commencer par « intégrer FHIR », mais par une situation : récupérer un compte rendu après une hospitalisation, actualiser la liste des traitements, transmettre une mesure au professionnel qui assure le suivi, réunir les pièces d’un deuxième avis médical.

Décrivez pour chacune les acteurs, les événements déclencheurs, les données minimales, les délais et les décisions attendues. Cette cartographie révèle ce qui est indispensable et les exceptions à prévoir. Elle évite surtout de construire un flux riche mais inutilisable.

Avec MyTwin pour les cliniciens, le jumeau numérique du patient se construit à partir du dossier médical, des examens, de l’imagerie et des traitements, et l’établissement peut utiliser l’application de suivi MyTwin ou intégrer les modules qu’il retient dans ses propres outils. Les mêmes scénarios s’appliquent alors : création du patient, import des documents, rapprochement d’identité, alerte, retour vers le système source. MyTwin formule des recommandations ; la décision clinique reste au professionnel.

Une donnée exacte rattachée à la mauvaise personne devient dangereuse. Le rapprochement d’identité doit gérer les doublons, les homonymes, les changements d’état civil et les données incomplètes.

En France, cette question a un cadre commun. Depuis le 1er janvier 2021, il est obligatoire de référencer chaque usager par l’Identité nationale de santé (INS), qui associe un matricule à cinq traits d’identité : nom de naissance, prénom(s) de naissance, date de naissance, sexe et lieu de naissance, rappelle l’Agence régionale de santé Hauts-de-France. Un système qui s’insère dans le parcours doit donc savoir recevoir, conserver et transmettre cette identité, plutôt que d’en reconstruire une à partir d’un nom et d’une date de naissance.

La provenance, condition de la confiance

Chaque information devrait conserver son auteur, son système d’origine, sa date, sa version, sa méthode et son statut. Une valeur déclarée par le patient, une mesure issue d’un objet connecté et un résultat validé par un laboratoire ne portent pas le même niveau de confiance. Les fusionner sans étiquette, c’est retirer au clinicien ce qui lui permet de les pondérer.

Le nombre « 5 » ne veut rien dire sans unité, type de mesure et contexte. Les terminologies, les jeux de valeurs et les profils forment la grammaire commune qui lui en donne un. C’est le rôle du CI-SIS : il rassemble les spécifications des informations à échanger, identifie la norme la plus adaptée à chaque échange et le vocabulaire à utiliser pour coder l’information, en s’appuyant sur les travaux internationaux d’IHE, de HL7 et de DICOM.

FHIR, publié par HL7, est un standard d’échange de données de santé organisé en ressources, utilisable notamment au travers d’API. Il ne règle pas tout à lui seul, et l’ANS le dit sans détour : « FHIR n’est pas interopérable de base ». Conçu pour un maximum de cas d’usage, il n’impose presque aucun champ obligatoire ni presque aucune contrainte de terminologie, et autorise les extensions. D’où les profils FR Core et les guides d’implémentation par cas d’usage, sur lesquels l’ANS demande de s’appuyer pour tout développement FHIR en France.

Deux implémentations FHIR peuvent ainsi retenir des versions, des profils ou des extensions différents. Les guides d’implémentation et les tests de conformité restent indispensables.

Une intégration massive peut saturer le dossier de doublons, de résultats sans rapport avec la question clinique et de notifications. Fixez une politique de sélection : quelles données, pour quel usage, à quelle fréquence, conservées combien de temps ?

Pour les objets connectés santé, agréger chaque battement de cœur est rarement nécessaire. Une synthèse peut suffire, à condition de garder l’accès à la mesure source lorsqu’il faut investiguer. C’est le principe développé dans notre article sur les données de vie réelle : la valeur vient de la décision que la donnée éclaire, pas de son volume.

Un flux techniquement réussi échoue si personne ne sait qui doit le consulter. Avant la mise en service, définissez :

• le rôle destinataire ;
• le délai de prise en compte ;
• les critères d’escalade ;
• la trace laissée dans le dossier ;
• le comportement en cas de panne ;
• le canal par lequel le patient signale une erreur.

La chaîne d’alerte elle-même, des seuils à la réponse de l’équipe, est détaillée dans notre guide du suivi patient à distance. Testez ensuite les scénarios atypiques : patient inconnu, code absent, unité inattendue, document corrigé, accès révoqué, fusion de doublons. Ces tests associent les utilisateurs, pas seulement les équipes techniques.

Gouvernance et sécurité

Cartographiez les responsables de traitement, les sous-traitants, les finalités et les durées de conservation. Vérifiez les habilitations, la journalisation, le chiffrement, la continuité de service, la réversibilité et la gestion des incidents. L’interopérabilité multiplie les flux : elle doit aussi les rendre plus visibles.

Le cadre devient par ailleurs européen. Le règlement sur l’Espace européen des données de santé, entré en vigueur le 26 mars 2025, prévoit des échanges progressifs : les résumés patients et les prescriptions électroniques à partir de mars 2029, puis les images médicales, les résultats de biologie et les comptes rendus de sortie d’hospitalisation à partir de mars 2031. L’ANS indique que ce cadre européen sera repris dans le CI-SIS. Mieux vaut suivre ces échéances que supposer toutes les fonctions disponibles dès aujourd’hui.

Suivez des indicateurs liés au parcours, pas seulement au transport :

• le taux de rapprochement d’identité automatique correct ;
• les doublons créés et les messages rejetés ;
• les données reçues sans unité ;
• le délai d’arrivée de l’information ;
• les documents corrigés après coup ;
• les alertes non distribuées ;
• le temps gagné, ou ajouté, pour l’équipe.

Un objectif de « 100 % de messages transmis » ne suffit pas. Il faut vérifier que l’information est compréhensible, visible au bon endroit et utilisée lorsque le protocole le prévoit.