Les fournisseurs MPI ne s'entendaient pas. Nous avons résolu la fusion de patients

Après deux décennies de travail, le comité IHE PIX/PDQ a délibérément laissé la sémantique de fusion de patients définie par l'implémentation. La norme précise que les fusions surviennent au sein d'un domaine d'identité de patient, mais s'abstient de spécifier ce que fait une fusion — laissant la « responsabilité de la qualité et de la gestion des informations démographiques des patients au sein de chaque domaine d'identité de patient ». Ce n'est pas une lacune dans la spécification — c'est un aveu. Il n'existe pas de fusion correcte universelle.

IHE n'est pas seul en cause. Une récente revue de l'industrie qualifie les opérations de fusion de « procédures opératoires dispersées plutôt que d'un cadre unifié et accessible » — aucun organisme de normalisation, aucun organisme de réglementation n'a comblé cette lacune. ONC et CMS exigent des pistes d'audit et continuent de pousser les taux de correspondance à la hausse ; ni l'un ni l'autre ne prescrit la procédure de fusion elle-même. C'est le même aveu qu'a formulé IHE, à un niveau d'abstraction supérieur.

Notre article précédent se terminait en promettant $unmerge. Cette promesse tient toujours, mais une question restait en suspens : pourquoi la fusion et la défusion devraient-elles fonctionner de cette façon en premier lieu ? Cet article comble cette lacune. Il explique pourquoi une fusion pilotée par le serveur ne peut pas fonctionner, peu importe l'ingéniosité du serveur.

Ce que la spécification FHIR vous offre aujourd'hui

FHIR R5 définit Patient/$merge au niveau de maturité 0. Les entrées : source-patient, target-patient, result-patient (optionnel). Le serveur est censé désactiver la source, copier les identifiants et mettre à jour les références. La façon dont il accomplit chacune de ces tâches est laissée à l'implémentation. L'opération n'a pas dépassé le niveau de maturité 0 depuis la sortie de R5.

La raison n'est pas le manque d'effort. C'est que chaque aspect de la « fusion » est une décision de politique, et les politiques varient de manière structurelle — d'un fournisseur à l'autre, d'un déploiement à l'autre, d'une juridiction à l'autre.

Fusion et liaison sont des points sur le même spectre

Avant d'aborder les axes, un recadrage s'impose. La fusion et la liaison sont souvent regroupées comme des opérations rivales, mais elles constituent des points sur le même spectre.

À l'extrémité de la liaison, les deux dossiers survivent, les références restent pointées là où elles pointent, les deux demeurent actifs et les données en aval restent rattachées à chacun. À l'extrémité de la fusion, les règles de survivance déterminent quels champs l'emportent, les références sont réécrites, la source est désactivée ou supprimée, et les données dérivées doivent être reconsidérées. Les implémentations réelles se situent entre ces deux pôles : CommonWell classe explicitement la force des liens ; Oracle Health Millennium conserve la source inactive mais adressable par identifiant ; VistA supprime définitivement ; NHS PDS retire l'ancien identifiant et redirige les recherches historiques. Plus une implémentation se comporte comme une liaison, moins elle s'engage sur l'état survivant. Plus elle se comporte comme une fusion, plus elle doit assumer de politiques.

Les quatre axes ci-dessous définissent où une implémentation se situe sur ce spectre. Ce ne sont pas de simples variations mineures à l'intérieur de « la fusion, l'opération » — ce sont précisément ce qui distingue la liaison de la fusion. Dès lors que chaque axe admet plusieurs réponses légitimes, les combinaisons explosent rapidement.

Quatre axes de variabilité

Survivance — quels champs survivent

Lorsque deux dossiers de patients sont combinés, des dizaines de champs entrent en conflit : nom, adresse, téléphone, identifiants, allergies, liste de problèmes, médicaments, statut de réanimation. Quelle valeur l'emporte est la règle de survivance.

Chaque fournisseur MPI sérieux expose cela comme un paramètre configurable, et non comme une valeur codée en dur :

• IBM InfoSphere MDM fournit quatre règles distinctes de survivance des parties lors de la fusion sous forme de classes Java enfichables, déclenchées lors de la détection de doublons suspects et de l'effondrement explicite des parties. La règle est un paramètre de configuration, non un algorithme codé en dur.
• Verato propose Auto-Steward et Smart Steward comme produits de gestion distincts : l'un résout automatiquement les doublons par rapport à une base de données de référence, l'autre fournit des recommandations assistées par IA pour les gestionnaires humains — deux réponses différentes à la question « cette décision peut-elle être automatisée du tout ».
• Smile CDR, un MDM natif FHIR, fait de la survivance un gestionnaire JavaScript que le client rédige. Des utilitaires auxiliaires mergeAll() et replaceAll() sont fournis ; le gestionnaire les compose ou implémente sa propre logique au niveau des champs. Il n'y a pas de valeur par défaut — le client est contraint de rendre la décision de politique explicite.

S'il existait une stratégie de survivance correcte unique, les fournisseurs l'auraient codée en dur. Ils ne l'ont pas fait, parce qu'elle n'existe pas.

Le coût d'une politique incorrecte est immédiat. Un cas de l'AHRQ PSNet décrit un patient dont l'allergie aux produits de contraste a été supprimée lors de la réconciliation parce qu'un clinicien a jugé qu'il ne s'agissait « pas d'une véritable allergie ». Le DSE affichait alors « aucune allergie connue » — et le patient a par la suite été planifié pour un scanner avec contraste. Il s'agit de la même catégorie d'échec qu'une fusion naïve : une règle « éliminer les sources qui semblent de faible qualité » a silencieusement effacé des données cliniquement importantes. Une politique de survivance différente — ne jamais supprimer une allergie, toujours signaler pour révision — aurait permis de l'intercepter.

Le guide d'identification des patients d'ECRI énonce directement la préférence directionnelle : « les dossiers en double sont préférables aux dossiers fusionnés par erreur. » Mieux vaut conserver les dossiers séparés que de les combiner incorrectement. Cette règle ne peut pas être encodée de façon générique, parce que « erroné » est défini par le contexte clinique que le serveur ne perçoit pas.

Gestion des références — que faire des pointeurs vers la source

Chaque fusion soulève une deuxième question : des dizaines ou des milliers de ressources référencent le patient source — Encounters, Observations, Claims, Appointments. Que leur arrive-t-il ?

Les implémentations publiques donnent des réponses différentes :

• Oracle Health Millennium (Cerner) retourne un patient combiné comme inactif avec un lien vers le patient actuel, et documente que la décombinaison du patient est prise en charge.
• VistA (VA) déplace les données du dossier DE vers le dossier VERS, redirige les fichiers concernés et élimine le dossier DE en tant que dossier actif. Si un champ est renseigné dans DE et vide dans VERS, cette valeur est fusionnée automatiquement ; pour obtenir un résultat vide à la place, la valeur source doit être supprimée en dehors du flux de fusion.
• CommonWell Health Alliance, un réseau d'échange d'informations de santé à l'échelle des États-Unis, modélise l'identité comme des liens entre organisations plutôt que comme un dossier survivant unique fusionné. Ces liens sont classés selon des niveaux d'assurance de lien (LOLA).
• NHS England's PDS fusionne les numéros NHS en double confirmés en un seul numéro survivant, et son guide d'API documente comment les numéros NHS remplacés retournent un numéro de remplacement.

Quatre formes, quatre positions différentes sur le spectre liaison↔fusion. Certaines conservent les deux dossiers et résolvent l'identité par des liens. D'autres redirigent chaque référence vers le survivant au moment de la fusion. D'autres encore conservent la source comme dossier inactif que les clients peuvent toujours résoudre. D'autres enfin s'appuient sur un mécanisme de pointeur séparé entre l'ancienne et la nouvelle identité. Toutes sont défendables dans leur propre contexte.

Disposition de la source — ce que devient le dossier source

La gestion des références concerne les pointeurs entrants. La disposition de la source est différente : que devient le dossier source lui-même après la fusion ? La spécification FHIR admin-incubator énumère deux résultats permis en une seule phrase — « un GET sur l'ID de la ressource Patient source retournera soit 200 OK (inactif, replaced-by renseigné) soit 404 not found (lorsque le système de fusion a supprimé la ressource) ». Les déploiements réels ajoutent d'autres variantes :

• Inactif avec lien replaced-by. Oracle Health Millennium utilise exactement ce modèle : la source est retournée comme inactive et liée au patient actuel, adressable uniquement par recherche directe par identifiant, jamais via la recherche.
• Suppression définitive. VistA déplace les données du dossier DE vers le dossier VERS, redirige les fichiers concernés et élimine le dossier DE en tant que dossier actif. Un GET ultérieur ne retourne rien.
• Identifiant remplacé, nouveau numéro canonique. NHS England's PDS retire l'ancien numéro NHS comme superseded et émet un numéro de remplacement ; les recherches historiques sont redirigées vers le survivant plutôt que le dossier source lui-même étant conservé.
• Obsolète mais suivi dans une machine à états séparée. IBM Initiate conserve le membre obsolète avec sa propre ligne et le type de liaison Merged, portant l'EID du survivant. La source n'est ni active ni disparue — elle se trouve dans un état de cycle de vie distinct pour que le MDM puisse toujours raisonner à son sujet.

S'ajoutent à cela les règles de conservation et d'effacement propres à chaque juridiction — l'article 17 du RGPD dans l'UE, la segmentation 42 CFR Part 2 aux États-Unis, les lois étatiques sur le consentement des mineurs — chacune contraignant ce que le dossier source peut ou doit devenir. La pile fédérale américaine illustre le même modèle par omission : ONC et CMS exigent l'auditabilité et la qualité des données, tandis que des initiatives comme le MATCH IT Act réintroduit en mars 2025 et TEFCA poussent la qualité d'identité en amont. Elles cherchent à réduire le besoin de fusion ; elles ne prescrivent toujours pas la procédure de fusion elle-même.

Effets en aval — artefacts dérivés et travaux de suivi

Fusionner le dossier patient n'est que le problème de premier ordre. Le problème de second ordre concerne tout ce qui est dérivé du dossier et qui ne suit pas mécaniquement une réécriture de référence : les graphes de liaisons au sein du MDM, les calculs cumulatifs comme la dose de rayonnement ou les totaux cumulatifs d'opioïdes, les caches tiers. Deux exemples publics illustrent le point :

• IBM Initiate documente que lorsque le membre C est fusionné dans une nouvelle entité, les membres A et B précédemment liés à C ne suivent pas automatiquement. Ils reçoivent chacun un nouvel EID et passent à nouveau par le processus de comparaison. La fusion ne ferme pas transitivement le graphe de liens — le MDM réévalue, et certains dossiers précédemment liés peuvent se retrouver attachés ailleurs ou pas du tout.
• La documentation EHI publique d'Epic réserve un flux de révision explicite sur l'historique des doses à vie après la fusion. La table PAT_LIFEDOSE_HX comporte des colonnes dédiées indiquant qui a examiné l'entrée après la fusion/défusion, quand, et un énumérateur de motifs de révision comprenant Patient Merge, Patient Unmerge, Patient Contact Move, avec les statuts Need Review, Accepted, Rejected. Pour les calculs cliniques cumulatifs, la distribution automatisée est considérée comme non sécuritaire — un être humain doit statuer sur ce qui appartient à quel dossier.

Le fil conducteur : certains artefacts post-fusion ne peuvent pas être réécrits dans la même transaction. Ils nécessitent une réévaluation (graphe de liens MDM), un acheminement vers une file de révision (dose cumulative) ou une réconciliation avec des systèmes externes qui ont mis en cache l'ancienne identité. Un serveur qui traite la fusion comme « réécrire les références et passer à autre chose » abandonne silencieusement cette catégorie de travail.

Où se situe la ligne de démarcation

Remarquez le modèle. La fusion côté serveur veut être un algorithme unique. La réalité comporte au moins quatre axes de politique indépendants, chacun avec plusieurs variantes déployées. C'est une explosion combinatoire avant même que les contraintes réglementaires entrent en jeu.

La solution n'est pas un serveur plus intelligent. C'est de déplacer la politique là où elle réside — chez le client. Dans notre $merge, le client envoie un Bundle de transaction décrivant chaque PUT, POST et DELETE. Le serveur est responsable des invariants : atomicité, audit, vérifications anti-fusion circulaire, verrouillage optimiste via ifMatch. Le client est responsable de la politique : quels champs survivent, comment les références sont réécrites, ce qu'il advient de la source, et quels travaux en aval doivent être acheminés vers une file de révision.

La piste d'audit n'est pas un atout facultatif. La boîte à outils d'identification des patients d'ECRI et les règles de documentation de CMS exigent effectivement le même enregistrement : qui a effectué la fusion, quand, pourquoi, un instantané pré-fusion des deux dossiers, et la liste des ressources concernées. Mappé en FHIR, cela correspond à une Task (opération, acteur, motif, source/cible liées), une entrée Provenance sur chaque ressource touchée, et l'API History FHIR pour l'instantané pré-fusion — le tout écrit dans la même transaction que la fusion elle-même. Répartir tout ceci sur plusieurs transactions et la piste d'audit cesse d'être une vérité unique.

La défusion soulève la même question à un niveau supérieur. Lorsque la fusion a eu lieu lundi et que trois nouveaux Encounters ont été publiés sur la cible mardi, où vont-ils mercredi — retour vers la source restaurée, distribués, ou conservés sur la cible ? Lorsque la source a été supprimée définitivement, peut-elle être recréée du tout ? Il n'existe pas de réponse générale. C'est pourquoi notre $unmerge reflète $merge : le serveur est responsable des invariants, le client est responsable de la politique — la seule forme que nous sachions comment rendre sécuritaire à cette échelle. Nous parcourons la conception complète dans Designing $unmerge: Reversing the FHIR Patient Merge. Pour le contexte sur les mécanismes sous-jacents de correspondance et d'index maître des patients, voir Master Patient Index (MPI): How It Works + Examples.

Vous souhaitez essayer la fusion pilotée par le client dans votre projet ? MDMbox est disponible dès aujourd'hui.