Aller au contenu
OpesCare Développeurs
EN FR
Obtenir des clés API

Architecture et flux

Détection des doublons et fusion réversible

Deux Health ID pour une même personne scindent son historique médical. L’index patient maître repère les doublons probables, mais c’est une personne qui décide, et chaque fusion est réversible.

Le flux

Faites défiler les étapes sous le diagramme, ou survolez-en une, pour la mettre en évidence.

Détection des doublons et fusion réversible Des analyses planifiées proposent des Health ID probablement en double, une personne examine chaque paire, et une fusion conserve un survivant, transforme l’autre en alias et peut être annulée. Planificateur chaque nuit et semaine Noter les paires candidates Analyse doublons Paires mises en revue Bureau de revue Comparer côte à côte Bureau de revue Un seul Health ID l'ancien ID devient un alias Les recherches suivent Registre patients Fusion : survivant + alias Bureau de revue Ou rejeter la paire Bureau de revue Dossiers séparés fusion annulée Annuler si besoin Bureau de revue planifié même personne annuler Personne ou appareil Service OpesCare Données stockées Décision Issue : réussie Issue : refusée Requête Réponse En file / asynchrone Refus ou échec
  1. Lancer l’analyse Les analyses tournent chaque nuit et chaque semaine selon le planning.
  2. Noter les paires candidates Les dossiers sont comparés par blocs pour rester rapides sur un registre national.
  3. Paires mises en revue Les doublons probables deviennent des candidats. Rien n’est fusionné automatiquement.
  4. Comparer côte à côte Un administrateur examine les deux dossiers. Une paire peut aussi être signalée à la main.
  5. Fusion : survivant + alias Un Health ID survit ; l’autre devient un alias qui reste résolu.
  6. Les recherches suivent Recherches, scans et liens vers l’ancien ID aboutissent au survivant.
  7. Ou rejeter la paire Une paire rejetée est écartée et les deux dossiers restent inchangés.
  8. Annuler si besoin Les fusions sont réversibles, dernière entrée première sortie, depuis l’onglet Fusionnés.
Comment ce diagramme est vérifié 21 contrôles sur 21 réussis

L'image, les étapes, le PDF et le JSON sont générés à partir d'une seule spécification. Un test automatisé démontre le graphe et vérifie chaque référence ci-dessous dans l'application en fonctionnement.

  • Chaque carte a un identifiant unique
  • Chaque carte a un type connu
  • Chaque flèche relie deux cartes existantes
  • Un seul point de départ (personne, appareil ou partenaire)
  • Chaque carte est atteignable depuis le départ
  • Chaque carte mène à une issue (aucune impasse)
  • Aucun cycle sauf les boucles de nouvel essai déclarées
  • Chaque étape numérotée suit de vraies flèches
  • Les issues terminent le flux
  • Deux cartes ne partagent jamais une case
  • Chaque carte cite sa preuve
  • Chaque route, classe, méthode et réglage existe
  • Chaque icône vient du jeu Lucide
  • Chaque icône correspond au type de sa carte
  • Chaque libellé existe en anglais et en français
  • Chaque libellé tient dans sa carte
  • Aucune flèche ne traverse une carte
  • Deux flèches sans rapport ne se superposent jamais
  • Aucune étiquette de flèche ne couvre une carte ou une autre étiquette
  • Chaque pointe de flèche est visible
  • Deux cartes reliées de types différents ne partagent jamais une couleur
CartePreuve dans le code
Planificateur command:mpi:detect class:App\Console\Commands\DetectDuplicatePatients
Noter les paires candidates method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::detectDuplicates method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::scoreMatch
Paires mises en revue class:App\Models\MpiCandidate route:portals.admin.mpi.index route:portals.admin.mpi.candidates.raise
Comparer côte à côte route:portals.admin.mpi.candidates.show
Un seul Health ID class:App\Models\PatientMergeAlias
Les recherches suivent method:App\Models\Patient::findExistingIdentity class:App\Models\PatientMerge
Fusion : survivant + alias route:portals.admin.mpi.candidates.merge method:App\Modules\MasterPatientIndex\Services\PatientMergeService::merge
Ou rejeter la paire route:portals.admin.mpi.candidates.reject method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::rejectMatch
Dossiers séparés method:App\Modules\MasterPatientIndex\Services\PatientMergeService::unmerge
Annuler si besoin route:portals.admin.mpi.merges.unmerge

Tous les flux en JSON

Ce que cela garantit

  • Aucune identité n’est fusionnée sans décision humaine.
  • Le Health ID retiré continue de fonctionner comme alias.
  • Chaque fusion peut être annulée.

Où cela se trouve dans le code

  • command:mpi:detect
  • class:App\Console\Commands\DetectDuplicatePatients
  • method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::detectDuplicates
  • method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::scoreMatch
  • class:App\Models\MpiCandidate
  • route:portals.admin.mpi.index
  • route:portals.admin.mpi.candidates.raise
  • route:portals.admin.mpi.candidates.show
  • class:App\Models\PatientMergeAlias
  • method:App\Models\Patient::findExistingIdentity
  • class:App\Models\PatientMerge
  • route:portals.admin.mpi.candidates.merge
  • method:App\Modules\MasterPatientIndex\Services\PatientMergeService::merge
  • route:portals.admin.mpi.candidates.reject
  • method:App\Modules\MasterPatientIndex\Services\MasterPatientIndexService::rejectMatch
  • method:App\Modules\MasterPatientIndex\Services\PatientMergeService::unmerge
  • route:portals.admin.mpi.merges.unmerge