Registre clients (Client Registry, CR)

L’identité d’une personne qui reçoit des services de santé est cruciale pour permettre le partage des dossiers médicaux entre les établissements et les systèmes. Pourtant, le partage des dossiers médicaux peut s’avérer difficile dans un environnement complexe où il existe plusieurs systèmes dans plusieurs établissements de soins de santé et où chaque établissement et/ou système a une manière différente d’identifier ses clients. Même dans les environnements où les citoyens se voient attribuer des cartes d’identité nationales, il est nécessaire de garantir l’identité unique d’un individu parmi la myriade de systèmes d’information fragmentés qui représentent collectivement le dossier médical électronique d’une personne. Le registre des clients est conçu pour aider à identifier de manière unique les personnes qui reçoivent des services de soins de santé :

· en maintenant un registre central de tous les patients et de leurs données démographiques et en attribuant un identifiant unique à chaque patient,

· en liant les saisies d’enregistrement d’un patient qui résultent de changements dans les données démographiques du patient (patient déplacé vers un autre lieu), d’erreurs de saisie de données lors de l’enregistrement du patient ou d’informations démographiques manquantes,

· en permettant aux professionnels de santé d’identifier les établissements dans lesquels un patient a reçu des soins.

Voir également Exigences non fonctionnelles.

Exigences relatives au flux de travail OpenHIE CR

Un principe de base de l’architecture OpenHIE est de permettre aux différents services d’infrastructure (tels que le CR) d’être interchangeables. Pour cela, les normes et profils OpenHIE utilisés par le registre des clients sont décrits dans les flux de travail ci-dessous. Pour être un composant de OHIE CR, l’application CR doit être en mesure de prendre en charge les flux de travail OHIE répertoriés ci-dessous. Les implémentations ne peuvent prendre en charge que les flux de travail nécessaires pour prendre en charge leur cas d’utilisation :

N°	Flux de travail CR (décrits en détail dans la dernière partie de ce document)	Recommandation/Exigence
CRWF-1	Le CR prend en charge « Créer un flux de travail de l’enregistrement des données démographiques du patient »	Exigence
CRWF-2	Le CR prend en charge « Mettre à jour le flux de travail de l’enregistrement des données démographiques du patient »	Exigence
CRWF-3	Le CR prend en charge « Interroger les enregistrements des données démographiques du patient par flux de travail de l’identifiant »	Exigence
CRWF-4	Le CR prend en charge « Interroger les enregistrements des données démographiques du patient par flux de travail des données démographiques »	Exigence

Exigences fonctionnelles relatives à OpenHIE CR

Voici les caractéristiques typiques d’un registre de clients ou d’un index principal des patients. Selon le ou les cas d’utilisation souhaités, le système peut prendre en charge plusieurs ou toutes ces caractéristiques fonctionnelles.

N°	Exigences fonctionnelles relatives au CR	Recommandation/Exigence
CRF-1	Le système devrait prendre en charge l’appariement d’entités configurable, un service qui aide à identifier les patients en double. a. Les règles permettant de déterminer si deux dossiers correspondent l’un à l’autre devraient être configurables (par exemple, possibilité d’utiliser à la fois des statistiques et/ou des règles, etc.). b. La stratégie de blocage pour charger les appariements potentiels avant d’appliquer les règles d’appariement devrait être configurable. c. Tout composant configurable devrait avoir une interface afin que les utilisateurs avancés puissent écrire leur propre implémentation à partir de zéro s’ils le souhaitent. d. Toute interface devrait avoir au moins une implémentation par défaut. e. L’implémentation par défaut devrait être flexible et configurable afin que les non-programmeurs puissent l’ajuster pour qu’elle réponde à leurs besoins. f. Dans la mesure du possible, les informations de configuration du système CR devraient être gérées à l’aide de méthodes cohérentes et faciles d’accès, telles qu’une base de données, des fichiers de propriétés ou des fichiers XML). g. Elle devrait permettre une configuration « basée sur un assistant » ou « guidée » des règles d’appariement.	Recommandé
CRF-2	Le système prend en charge la liaison et la déduplication des patients. a. Le système met en œuvre des méthodes précises et efficaces de liaison et de déduplication des patients. b. Il fournit un moyen intuitif et facile à utiliser de voir les opérations de fusion/liaison. c. Il devrait permettre d’accepter ou de rejeter manuellement les suggestions de fusion d’une manière intuitive et facile à utiliser, avec la possibilité de choisir les champs de l’un ou l’autre enregistrement à fusionner.	Obligatoire
CRF-3	Le système devrait prendre en charge la capacité de suivre et de surveiller les transactions entrantes/sortantes. a. Le système doit avoir la capacité d’enregistrer la réception et la transmission des transactions.	Recommandé
CRF-4	Le système devrait prendre en charge la synchronisation des identifiants des clients avec un dossier médical partagé (SHR).	Recommandé
CRF-5	Le système devrait prendre en charge une interface utilisateur pour examiner et arbitrer manuellement les appariements incertains (« potentiels ») et remplacer les appariements incorrects.	Recommandé
CRF-6	Le système devrait prendre en charge les attributs configurables, notamment : a. Les attributs qui forment un dossier patient et sont utilisés pour l’appariement devraient être configurables. b. L’implémentation peut inclure un exemple/schéma patient par défaut. c. Il devrait être facile d’ajouter des attributs au schéma. d. Il devrait également être facile de supprimer des attributs du modèle par défaut (ou de recommencer à zéro).	Recommandé
CRF-7	Le système devrait prendre en charge la gestion des erreurs a. Assurer que la gestion des erreurs recueille et consigne de manière exhaustive toutes les exceptions associées et, dans la mesure du possible, affiche les relations entre les exceptions.	Recommandé
CRF-8	Le système gère un journal d’audit complet des modifications apportées aux données ainsi qu’aux configurations et aux utilisateurs.	Obligatoire
CRF-9	Confidentialité/sécurité : Le système devrait avoir des fonctions telles que la gestion des utilisateurs et les contrôles d’accès.	Recommandé
CRF-10	Le système devrait pouvoir conserver la relation parent/enfant, l’ordre de naissance et l’indicateur de naissances multiples.	Recommandé