Que doit-il se passer après qu'un MPI trouve une correspondance de patient?
Un MPI a identifié deux dossiers comme une correspondance probable. Le système peut conserver les deux dossiers et établir une relation entre eux, ou consolider un dossier dans un autre.
Ces actions sont parfois traitées comme des étapes consécutives d'un même processus. En pratique, la correspondance ne fait qu'identifier les dossiers qui peuvent appartenir à la même personne. Elle ne détermine pas ce qui devrait leur arriver ensuite.
Grâce à la liaison, les applications peuvent récupérer les dossiers connexes, associer les identifiants entre les systèmes et construire une vue longitudinale du patient, tandis que les dossiers d'origine restent intacts.
La fusion modifie les dossiers eux-mêmes. La cible devient l'identité active du patient, les références à la source doivent être redirigées, et les valeurs conflictuelles doivent être résolues.
Alors, quand une liaison est-elle suffisante, et quand un flux de gestion de l'identité des patients exige-t-il une fusion? La réponse dépend du niveau de confiance dans la correspondance, de la propriété des données, de la provenance, des flux de travail en aval, et de ce qui se passe si la décision s'avère erronée.
Pourquoi une fusion incorrecte n'équivaut pas à une correspondance manquée
Un faux négatif laisse séparés les dossiers d'un même patient. L'historique du patient peut rester incomplet, mais les données sont toujours attribuées aux identités d'origine.
Un faux positif a un effet différent. Une fois que les dossiers appartenant à deux personnes distinctes sont fusionnés, leurs informations démographiques, administratives et cliniques peuvent faire partie de la même identité de patient.
Le rapport final de l'ONC sur l'identification et la correspondance des patients décrit les correspondances fausses positives comme un risque plus grand pour la sécurité des patients que les correspondances manquées, car des soins peuvent être prodigués à partir d'informations appartenant à une autre personne. Cette asymétrie est l'une des raisons pour lesquelles les systèmes de correspondance sont généralement configurés pour tolérer quelques doublons non résolus plutôt que d'augmenter le nombre de substitutions.
Substitution de patient
Une substitution se produit lorsque des informations appartenant à deux patients se retrouvent mélangées dans un même dossier médical.
Le dossier résultant peut contenir les informations suivantes d'un autre patient :
- allergies;
- médicaments;
- diagnostics;
- résultats de laboratoire;
- groupe sanguin;
- interventions.
Des informations cliniques incorrectes peuvent influencer les décisions thérapeutiques. La fusion peut également donner à un patient accès aux renseignements personnels sur la santé d'une autre personne via un portail patient, une demande de divulgation ou une règle d'accès fondée sur l'identité.
Lorsqu'une fusion incorrecte entraîne un accès non autorisé ou une divulgation non autorisée de renseignements personnels sur la santé (RPS), l'incident peut devoir être évalué en vertu de la règle de notification des violations du HIPAA. En vertu du 45 CFR Part 164, toute utilisation ou divulgation non autorisée de RPS est présumée constituer une violation, à moins que l'entité couverte ou l'associé commercial ne démontre une faible probabilité que l'information ait été compromise.
Les conséquences peuvent donc aller au-delà de la qualité des données et de la sécurité clinique pour inclure des obligations d'enquête, de notification et de correction.
Annulation de fusion
La réactivation du dossier source ne restaure pas nécessairement l'état qui existait avant la fusion.
L'équipe de correction peut devoir examiner les consultations, les observations, les documents, les réclamations et d'autres ressources pour déterminer à quel patient chaque élément appartenait. Certains systèmes ne prennent en charge l'annulation de fusion que par un processus manuel. D'autres exigent que les dossiers d'origine soient reconstruits à partir de l'historique d'audit.
L'auditabilité doit donc être intégrée au flux de fusion. L'organisation doit être en mesure d'identifier les dossiers source et cible, les valeurs modifiées, la personne ayant approuvé l'action, et les preuves utilisées pour prendre la décision.
Propagation en aval
Les mises à jour de l'identité des patients peuvent être consommées par des DMÉ, des laboratoires, des systèmes de facturation, des portails patients, des environnements d'analyse et des applications de payeurs.
Une fusion incorrecte peut continuer à affecter ces systèmes après la correction du MPI. Chaque destinataire doit disposer d'un moyen de traiter la correction et de déterminer quelles données reçues antérieurement doivent être modifiées.
Plus la distribution de l'identité du patient est large, moins il est utile de traiter la fusion comme une opération de base de données locale.
Quand les dossiers de patients doivent rester séparés
Les risques liés à la fusion ne signifient pas que chaque correspondance doit rester non résolue. Ils signifient que reconnaître une même personne à travers plusieurs dossiers et consolider physiquement ces dossiers doivent être traités comme des décisions distinctes.
La correspondance n'est pas encore concluante
La correspondance probabiliste divise généralement les résultats en correspondances définitives, correspondances possibles et non-correspondances.
Une correspondance définitive peut être admissible à un traitement automatisé dans le cadre d'une politique approuvée. Une correspondance possible nécessite un examen supplémentaire.
Pendant l'examen du dossier, les deux dossiers restent disponibles. Un gestionnaire de données peut inspecter les identifiants, les attributs démographiques, les valeurs manquantes, la fiabilité de la source et les événements d'identité antérieurs sans avoir à séparer au préalable des données déjà fusionnées.
Le réviseur peut confirmer la correspondance, la rejeter ou laisser le dossier non résolu. La confirmation établit que les dossiers appartiennent à la même personne. Cela n'exige pas, en soi, une consolidation physique.
Les dossiers appartiennent à différentes organisations
Un réseau d'échange d'informations sur la santé (RIS), un réseau de laboratoires, un groupe hospitalier ou un échange payeur-fournisseur peut avoir besoin de reconnaître que plusieurs identifiants locaux font référence à la même personne.
Chaque participant maintient toujours son propre dossier patient et reste responsable de ses données. Un service d'identité partagé peut associer les identifiants et récupérer les informations connexes sans transférer la propriété des dossiers sources.
Le profil IHE Patient Identifier Cross-referencing (PIX), le profil Patient Demographics Query (PDQ) et le profil Cross-Community Patient Discovery (XCPD) traitent de l'identification des patients et du référencement croisé au sein des communautés de soins de santé et entre elles. La plateforme de normes d'interopérabilité de l'ONC répertorie ces profils comme des approches de niveau production pour l'échange d'informations sur l'identité des patients.
Sans cadre de gouvernance qui autorise explicitement la consolidation, une correspondance interorganisationnelle devrait aboutir à une liaison plutôt qu'à une fusion.
Le contexte source doit être préservé
Les informations sur les patients peuvent provenir de systèmes ayant différents niveaux d'autorité, d'exhaustivité et de fiabilité.
Une source peut contenir un nom légal vérifié. Une autre peut avoir une adresse ou un numéro de téléphone plus récent. Conserver les dossiers séparés permet d'afficher ces valeurs ensemble tout en conservant l'origine de chaque valeur, la date de sa réception et l'organisation qui l'a fournie.
Cela favorise naturellement les exigences en matière de provenance et d'audit. Un dossier fusionné peut également préserver la provenance, mais la mise en œuvre doit l'enregistrer explicitement après que les frontières entre les sources d'origine ont été supprimées.
Le flux de travail n'a besoin que d'une vue combinée
Un MPI de type registre associe une identité d'entreprise aux identifiants de patients utilisés par les systèmes sources individuels.
Les applications peuvent utiliser ces liens pour trouver des dossiers connexes et les présenter sous forme de vue longitudinale du patient. Les systèmes sources restent inchangés, et le MPI ne devient pas le propriétaire transactionnel de leurs données cliniques.
Ce modèle peut prendre en charge la découverte de dossiers, l'analyse, la coordination des soins et l'accès intersystèmes sans créer un seul dossier patient physique. Le rapport de l'ONC sur la gestion des données de référence dans les infrastructures de RIS décrit l'utilisation d'un identifiant maître pour connecter les identités locales des patients dans des systèmes distribués.
Quand un seul dossier physique devient nécessaire
La liaison fonctionne tant que les applications consommatrices peuvent opérer avec plusieurs dossiers connectés. Elle cesse d'être suffisante lorsqu'un processus opérationnel exige une seule identité de patient active.
Un doublon à l'intérieur d'un seul DMÉ, par exemple, peut perturber la facturation, les mises à jour transactionnelles, l'accès fondé sur l'identité ou la tenue d'un système de référence centralisé. Dans ce cas, récupérer les dossiers connexes ensemble ne résout pas le problème. Le doublon lui-même doit être supprimé.
Avant de procéder, l'organisation doit établir trois choses :
- Elle a le pouvoir de consolider les deux dossiers.
- Les dossiers ont été confirmés comme appartenant à la même personne.
- Une vue liée ne peut pas répondre à l'exigence opérationnelle.
Le cas de fusion le plus évident est un doublon confirmé à l'intérieur d'un seul DMÉ, MPI ou autre système contrôlé par la même organisation.
Un second dossier peut avoir été créé en raison d'une différence d'orthographe, de données d'inscription incomplètes, d'un identifiant manquant ou d'une inscription en double lors d'une consultation urgente. Une fois le doublon confirmé, conserver les deux dossiers peut continuer à perturber les processus qui dépendent d'un seul identifiant patient.
La fusion interorganisationnelle est un cas distinct. Elle requiert un cadre de gouvernance convenu qui définit la propriété de l'identité résultante, l'autorité de fusion et les actions attendues des systèmes participants.
Le profil IHE Patient Master Identity Registry (PMIR) décrit un flux de travail dans lequel plusieurs identités maîtres sont consolidées en une seule identité dorée de patient et la décision est distribuée aux propriétaires des données. Sans ce type de gouvernance, la gestion de l'identité interorganisationnelle demeure un cas d'utilisation de liaison.
Ce qui doit être résolu avant la fusion
Une fois que la consolidation physique est justifiée, l'équipe doit déterminer comment la fusion modifiera l'identité du patient et les données qui y sont associées.
Sélectionner la source et la cible
Un dossier devient l'identité cible. L'autre devient la source qui est remplacée ou rendue inactive.
La cible ne doit pas être sélectionnée uniquement parce qu'elle a été créée en premier. La décision peut également dépendre des identifiants déjà en usage, de l'autorité et de l'exhaustivité de chaque dossier, et des systèmes qui y font référence.
Définir les règles de survie
Des dossiers en double confirmés peuvent tout de même contenir des noms, des identifiants, des adresses, des numéros de téléphone et des attributs démographiques différents.
Les règles de survie déterminent quelles valeurs sont écrites dans la cible. Elles peuvent prioriser :
- une source plus fiable;
- une valeur vérifiée;
- la valeur la plus récente;
- le dossier le plus complet;
- une décision prise par un gestionnaire de données.
Les valeurs qui ne survivent pas doivent rester accessibles via l'historique des ressources, la provenance ou un autre mécanisme d'audit. Autrement, il peut être impossible d'expliquer comment le dossier cible a été créé ou de reconstituer l'état avant la fusion.
Avec la liaison, ces conflits n'ont pas besoin d'être résolus immédiatement. Chaque valeur reste dans son dossier source et peut être présentée avec son contexte d'origine.
Rediriger les références
Les données cliniques, administratives et financières peuvent déjà référencer le patient source.
Une fusion doit identifier ces références et les rediriger vers la cible. La portée peut s'étendre au-delà des données stockées dans le MPI aux applications connectées qui ont déjà reçu ou copié l'identité.
Se préparer à la correction
L'organisation doit comprendre ce que ses systèmes peuvent et ne peuvent pas inverser automatiquement.
Un processus de correction doit définir :
- comment une fusion incorrecte est détectée et examinée;
- qui décide quelles données appartiennent à chaque patient d'origine;
- comment l'état avant fusion est reconstitué;
- comment les systèmes en aval reçoivent la correction;
- comment les incidents liés à la vie privée et à la sécurité des patients sont traités.
Ces contrôles font partie de la préparation à la fusion, et non d'un travail à concevoir après la première erreur.
Faire passer une correspondance de la découverte à la fusion
Un flux de gestion de l'identité des patients bien contrôlé sépare la génération de candidats, la confirmation d'identité et la consolidation physique.
1. Trouver des candidats
Le moteur de correspondance compare les identifiants et les attributs démographiques et retourne les dossiers qui peuvent appartenir à la même personne.
Le résultat doit inclure les preuves utilisées dans la correspondance et, le cas échéant, un score de confiance.
2. Classifier le résultat
Chaque candidat est assigné à une catégorie opérationnelle :
- correspondance définitive;
- correspondance possible;
- non-correspondance.
L'organisation définit les seuils et les actions permises pour chaque catégorie.
3. Examiner les cas incertains
Les correspondances possibles restent séparées et entrent dans une file d'attente de gestion.
Le réviseur examine les preuves disponibles et confirme la correspondance, la rejette ou laisse le dossier non résolu.
4. Choisir l'action d'identité
Une correspondance confirmée peut rester liée lorsque le flux de travail n'a besoin que d'accéder à des dossiers connexes.
Le dossier passe à la fusion lorsque la consolidation est autorisée et qu'un processus exige une seule identité de patient active.
5. Appliquer les contrôles de fusion
Avant la consolidation, l'équipe sélectionne le dossier cible, applique les règles de survie, préserve l'historique des décisions et identifie les systèmes en aval affectés.
Le flux de travail peut être résumé ainsi :
correspondance → classification → examen si nécessaire → liaison ou fusion
La liaison est le résultat approprié pour les cas incertains, la propriété distribuée des données et les flux de travail qui n'ont besoin que d'une vue combinée. La fusion est réservée aux cas confirmés où un seul dossier physique est opérationnellement nécessaire.
Correspondance, liaison et fusion de patients dans FHIR
FHIR fournit un mécanisme distinct pour chaque partie du flux de travail.
Patient/$match
Patient/$match accepte des informations d'identité de patient et retourne des ressources Patient candidates.
Les mises en œuvre peuvent inclure un score de 0 à 1 représentant le niveau de confiance de chaque résultat. Le score peut ensuite être évalué par rapport aux seuils de l'organisation.
Patient.link
Patient.link enregistre une relation entre des ressources Patient qui font référence à la même personne réelle.
Les ressources restent séparées et conservent leurs identifiants et données d'origine. Cela rend Patient.link adapté aux références croisées, aux mises en œuvre MPI de type registre et aux relations qui peuvent nécessiter un examen ou une suppression.
FHIR définit quatre types de liens Patient : replaced-by, replaces, refer et seealso.
Patient/$merge
Patient/$merge consolide une ressource Patient source dans une ressource Patient cible.
Les références à la source sont redirigées vers la cible. La source devient inactive, tandis que les liens replaced-by et replaces préservent une trace de la relation entre les ressources.
FHIR sépare ces mécanismes parce que confirmer une correspondance de patient n'exige pas toujours de consolider les dossiers.
Gestion du flux de travail avec MDMbox
MDMbox prend en charge la correspondance, la liaison, la gestion et la fusion comme parties distinctes du flux de travail d'identité des patients.
Les équipes peuvent utiliser Patient/$match pour trouver et scorer des candidats. Les dossiers devant rester séparés peuvent être connectés via Patient.link, tandis que les correspondances possibles peuvent être acheminées pour examen.
Lorsqu'un doublon confirmé doit être consolidé, Patient/$merge redirige les références vers la cible et préserve la relation entre les ressources Patient.
L'organisation définit la politique derrière ces actions, notamment les seuils de correspondance, l'autorité de fusion, les responsabilités de gestion, les règles de survie et les systèmes devant recevoir les mises à jour d'identité.
Vérifier un flux de travail avant d'activer la fusion
La liste de contrôle de décision « Identité du patient : liaison ou fusion? » aide les équipes à déterminer si un flux de travail nécessite une liaison, un examen de gestion ou une consolidation physique.
La première partie couvre la propriété, le niveau de confiance dans la correspondance et le besoin d'un seul dossier patient. La seconde vérifie si les contrôles de fusion requis sont en place.
