FR 2880492 A1 20060707 FR 0500044 A 20050104 La présente invention concerne un procédé et un serveur de gestion d'identités de patients d'un réseau informatique de production et de mémorisation d'informations médicales relatives à ces patients et référencées sur le réseau par les identités de ceux-ci. De manière typique, les informations médicales informatiques d'un patient, générées lors de différents actes médicaux sur celui-ci, sont mémorisées sur une pluralité de serveurs de données. En effet, chaque organisation médicale, comme un hôpital, une clinique radiologique, un groupement géographique de praticiens de la santé, etc..., dispose de son propre matériel informatique de stockage de données. En outre, chaque organisation médicale peut utiliser généralement son propre format informatique pour référencer un patient, de sorte que plusieurs formats d'identité de patient sont utilisés. De plus, pour une même organisation médicale, il arrive que plusieurs identités pour un même patient soient actives, du fait par exemple de la création par erreur de multiples identités pour ce patient. Ainsi, il n'existe pas nécessairement une unique identité informatique pour un patient par organisation médicale. Aussi, un opérateur médical, souhaitant accéder aux diverses informations médicales d'un patient, doit alors procéder par recoupement pour définir quelles informations mémorisées sur les différents serveurs sont effectivement associées à ce patient ou disposer de l'ensemble des identités de celui- ci. De plus, l'opérateur médical peut ne pas consulter une information médicale importante du fait que celle-ci n'est pas référencée sous une identité connue de lui. Ce problème d'identités multiples pour un même patient est également présent entre différentes organisations médicales. En effet, du fait qu'il peut exister une identité par organisation médicale pour chaque patient, un opérateur est confronté au problème susmentionné lorsqu'il souhaite consulter les informations médicales du patient mémorisées dans les serveurs de différentes organisations. Le but de l'invention est de résoudre les problèmes susmentionnés en proposant un serveur de gestion d'identités de patients adapté pour gérer les identités des patients référencés sur un réseau informatique de production et de mémorisation d'informations médicales de manière à obtenir une unique identité par patient sur ce réseau. A cet effet, l'invention a pour objet un procédé de gestion d'identités de patients d'un réseau informatique de production et de mémorisation d'informations médicales relatives à ces patients et référencées sur le réseau par les identités de ceux-ci, caractérisé en ce qu'il comprend: une étape de recherche sur le réseau d'identités potentiellement associées à un même patient; - une étape de validation d'au moins une identité trouvée comme 10 étant effectivement associée à ce patient; - une étape de sélection d'une identité parmi les identités validées; et - une étape de fusion sous l'identité sélectionnée d'au moins une autre identité validée, de sorte que cette au moins une autre identité fusionnée est mise hors ligne, et que les informations relatives à ce patient préalablement 1.5 référencées par cette au moins une autre identité fusionnée sont à présent référencées par l'identité sélectionnée de ce patient. Suivant des modes particuliers de réalisation, le procédé comporte une ou plusieurs des caractéristiques suivantes: - l'identité d'un patient comprend une pluralité de champs alphanumériques d'identification de celui-ci, et l'étape de recherche comprend: - une étape de sélection d'au moins un ensemble d'identités du réseau en fonction d'un premier champ prédéterminé et/ou d'une partition prédéterminée du réseau en sousréseaux informatiques; - une étape de sélection de deux identités de l'ensemble sélectionné ; - une étape de comparaison de ces deux identités adaptées pour comparer les valeurs d'au moins un second champs de cellesci; et - une étape de création d'une relation logique entre ces deux identités si elles présentent un taux de similarité supérieur à une valeur prédéterminée, cette relation les définissant comme des identités potentiellement associées à un même patient; - la pluralité de champs d'identification de l'identité d'un patient comprend des chaînes de caractères relatives respectivement au nom, au prénom, à la date de naissance au sexe de celui-ci, l'étape de comparaison des deux identités comprend la mise en oeuvre d'un algorithme du type à comparaison phonétique entre, d'une pari, les noms de ces deux identités, et d'autre part, les prénoms de ces deux identités, et: - si les noms et les prénoms de ces deux identités correspondent phonétiquement, et que les sexes ou les dates de naissance de celles-ci sont identiques, alors les deux identités sont déterminées comme présentant un taux fort de similarité ; si seulement les noms de ces deux identités correspondent phonétiquement, et que les sexes et les dates de naissance de celles-ci sont identiques, alors les deux identités sont déterminées comme présentant un taux moyen de similarité ; et - sinon ces deux identités sont déterminées comme présentant un taux faible de similarité ; - la pluralité de champs d'identification de l'identité d'un patient comprend des chaînes de caractères relatives respectivement au nom et au prénom de celui-ci, l'étape de comparaison des deux identités comprend la mise en oeuvre d'un algorithme du type à écart entre, d'une part, les noms de ces deux identités, et d'autre part, les prénoms des ces deux identités, et pour déterminer un taux de similarité entre celles-ci en fonction de la moyenne des écarts entre les noms et les prénoms renvoyés par l'algorithme du type à écart; - il comprend une étape de création de liaison logique entre deux identités du réseau; - il comprend une étape de suppression d'une fusion entre deux identités du réseau, l'identité fusionnée étant alors remise en ligne et les référencements d'informations médicales par ces identités étant alors rétablis à leur état initial; - il comprend une étape de recherche, par un opérateur médical ou un système externe tiers, d'une identité de patient du réseau par interrogation de la valeur d'au moins un champ d'identification de l'identité ; - l'identité d'un patient du réseau comprend une pluralité de champs d'identification répartie en ensembles de champs d'identification, notamment un champ d'identifiant référençant de manière biunivoque sur le réseau le patient associé à l'identité et des propriétés relatives à des informations d'identifications principales, secondaires, complémentaires et d'administration de l'identité respectivement; et - lorsqu'une identité du réseau est modifiée, une notification en est faite à l'ensemble des moyens informatiques du réseau utilisant une telle identité pour la mise à jour de celle-ci dans ces moyens informatiques. L'invention a également pour objet un serveur de gestion d'identités de patients d'un réseau informatique de production et de mémorisation d'informations médicales relatives à ces patients et référencées sur le réseau par les identités de ceux-ci, caractérisé en ce qu'il comprend: des moyens de recherche sur le réseau d'identités potentiellement associées à un même patient; - des moyens de validation d'au moins une identité trouvée comme étant effectivement associée à ce patient; - des moyens de sélection d'une identité parmi les identités validées; et - des moyens de fusion sous l'identité sélectionnée d'au moins une autre identité validée, de sorte que cette au moins une autre identité fusionnée est mise hors ligne, et que les informations relatives à ce patient préalablement référencées par cette au moins une autre identité fusionnée sont à présent référencées par l'identité sélectionnée de ce patient. Suivant d'autres caractéristiques: - le serveur est adapté pour mettre en oeuvre le procédé de gestion d'identités du type susmentionné ; - il comprend des moyens de mémorisation de traces pour mémoriser des informations relatives à des d'accès à celui-ci et aux fonctions de celuici; - il comprend des moyens de génération de statistiques en fonction d'informations mémorisées dans les moyens sur une période de temps 30 prédéterminée dans les moyens de mémorisation de traces; - il comprend des moyens d'authentification d'un utilisateur connecté par un terminal; et il comprend des moyens d'alllocation, à l'utilisateur, d'autorisations d'un ensemble prédéterminé d'autorisations portant sur l'utilisation de fonctions et l'accès à des informations du serveur. L'invention a également pour objet un procédé de rapprochements des identités de patients d'une pluralité de réseaux informatiques de production et de mémorisation d'informations médicales relatives à ces patients, caractérisé en ce qu'il comprend: - une étape de création d'une identité fédératrice pour un patient identifié dans la pluralité de réseaux; - une étape de recherche d'identités de la pluralité de réseaux potentiellement associées à ce même patient; - une étape de validation d'une identité trouvée comme étant effectivement associée à ce même patient; - une étape de rapprochement sous l'identité fédératrice du patient de l'identité validée. Selon d'autres caractéristiques, - il comprend une étape de modification d'une identité fédératrice et de notification d'au moins un serveur de la pluralité de réseaux utilisant l'identité fédératrice d'une modification de celle-ci; - l'étape de recherche comprend une étape de sélection d'une identité de la pluralité de réseaux; - les identités de la pluralité de réseaux sont gérées par des serveurs informatiques, et l'étape de recherche comprend une étape de notification en recherche d'identités de chacun de ces serveurs en fonction d'informations relatives au patient mémorisées dans l'identité fédératrice; et - l'étape de validation comprend une étape de comparaison d'identités délivrées par les serveurs informatiques en réponse à la notification en recherche de ceux-ci. L'invention a également pour objet un serveur de rapprochement des identités de patients d'une pluralité de réseaux informatiques de production et de mémorisation d'informations médicales relatives à ces patients, caractérisé en ce qu'il comprend: - des moyens de création d'une identité fédératrice pour un patient identifié dans la pluralité de réseaux; - des moyens de recherche, sur la pluralité de réseaux, d'identités potentiellement associées à ce même patient; - des moyens de validation d'une identité trouvée comme étant effectivement associée à ce même patient; et - des moyens de rapprochement sous l'identité fédératrice du patient de l'identité validée. Selon une autre caractéristique, le serveur de rapprochement est 10 également un serveur d'identité du type susmentionné pour au moins un réseau de la pluralité de réseaux. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en relation avec les dessins annexés, dans lesquels: - la figure 1 est une vue schématique d'un réseau informatique de production et de mémorisation d'informations médicales relatives à des patients et comprenant un serveur de gestion d'identité et un serveur de rapprochements conformes à l'invention; - la figure 2 est une vue schématique plus en détail d'un serveur de gestion d'identités conforme à l'invention; - la figure 3 est un organigramme du fonctionnement du serveur de gestion d'identité de la figure 2; - la figure 4 est un organigramme du fonctionnement de la recherche de doublons d'identités mise en oeuvre par un serveur de gestion d'identités conforme à l'invention; - la figure 5 est un organigramme des étapes de la détection de doublons par comparaison du type phonétique; - la figure 6 est un organigramme des étapes de la détection de doublons par comparaison du type à écart; - la figure 7 est un organigramme des étapes de suppression logique d'une identité d'un serveur de gestion d'identités conforme à l'invention; - la figure 8 est une vue plus en détail du serveur de rapprochements conforme à l'invention; et - la figure 9 est un organigramme de fonctionnement du serveur de rapprochements de la figure 8. Sur la figure 1, un réseau 10 informatique de production et de mémorisation d'informations médicales relatives à des patients comprend une pluralité de sous-réseaux 12A, 12B, 12C, 12D. Chaque sous-réseau 12A, 12B, 12C, 12D est par exemple un réseau informatique interne d'une organisation médicale, comme par exemple un hôpital, une clinique, un médecin généraliste, un groupement départemental d'hôpitaux, etc... Le sous-réseau 12A, 12B, 12C, 12D comprend un ou plusieurs serveurs de contenu 14, 15, 16, 17, 18, 19, 20, 21 mémorisant sous format informatique des informations médicales de patients générées à la suite d'actes médicaux sur ceux-ci, comme par exemple, des radiographies, des comptes-rendus opératoires, des examens sanguins, etc... Chacune des informations médicales relatives à un patient est référencée dans le sous-réseau 12A, 12B, 12C, 12D par une identité informatique créée et renseignée par un opérateur autorisé par l'organisation médicale. Cette identité est mémorisée dans un serveur 22, 23 de gestion d'identités conforme à l'invention connecté aux serveurs 14- 21 de contenu. Ce serveur 22, 23 est adapté pour rechercher et supprimer les doublons d'identités, c'est-à-dire les identités multiples associées à un même patient, et ainsi assurer qu'une seule identité pour ce patient est mémorisée sur le réseau 12A, 12B, 12C, 12D de l'organisation médicale. Cette identité unique est alors utilisée par les serveurs de contenu 14, 15, 16, 17, 18, 19, 20, 21 de cette organisation pour l'indexation des informations médicales du patient que ces serveurs mémorisent. Bien qu'il ait été représenté un serveur de gestion d'identités distinct des serveurs de contenu, on comprendra bien entendu que le serveur de gestion d'identité puisse également être un serveur de contenu. De même, un serveur de gestion d'identités est adapté pour gérer de manière indépendante différents ensembles, ou domaines internes, d'identités de patients, chacun des ces ensembles étant associé à un découpage prédéterminé du réseau informatique. Chaque serveur 22, 23 de gestion d'identités est propre à mettre en oeuvre ses propres règles d'administration d'identités. Par exemple, des règles pour nommer des patients, des définitions de format d'identités, ou des niveaux de confidentialités différents peuvent être utilisés. De plus, il peut être requis, par exemple pour des raisons de sécurité, que des organisations médicales soient équipées de leurs propres serveurs de gestion d'identités respectifs, de sorte que la gestion des identités des patients n'est pas mise en oeuvre de manière centralisée. De manière avantageuse, le réseau 10 est équipé d'au moins un serveur 24, 25 de rapprochements connecté à plusieurs serveurs 22, 23 de gestion d'identités. Le serveur 24, 25 de rapprochements est également propre à être connecté à un ou plusieurs autres serveurs 24, 25 de rapprochements. Un tel serveur de rapprochements 24, 25 est adapté pour indexer, sous une identité fédératrice unique, des identités d'un patient mémorisées dans les serveurs de gestion d'identités et de rapprochements qui lui sont connectés. L'ensemble des identités gérées par un serveur tiers externe au serveur 24, 25 de rapprochements est qualifié de domaine externe pour celui-ci et l'ensemble des identités que le serveur 24, 25 rapprochent en les indexant sous les identités fédératrices qu'il mémorise est qualifié de domaine de rapprochements pour celui-ci. Le serveur 24, 25 de rapprochements reçoit des messages en provenance de chaque serveur de gestion d'identités et de rapprochement qui lui est connecté. Ce serveur externe notifie régulièrement au serveur 24, 25 de rapprochement son activité pertinente, c'est-à-dire des opérations de gestion et d'administration d'identités, comme cela sera expliqué plus en détail par la suite. Un serveur externe communique également avec le serveur 24, 25 de rapprochement pour rechercher et consulter des identités fédératrices. De manière préférentielle, le serveur 24, 25 de rapprochements ne différencie pas, dans son fonctionnement, un serveur de gestion d'identités d'un serveur de rapprochements. II communique de manière identique avec ces deux types de serveurs et exécute les mêmes services pour ceux-ci. Comme les serveurs 24, 25 de rapprochements peuvent être connectés entre eux pour rapprocher leurs domaines de rapprochements respectifs, on comprendra donc que, de proche en proche, les serveurs de rapprochements selon l'invention permettent d'obtenir une seule identité pour chaque patient à une échelle géographique ou organisationnelle quelconque, par exemple au niveau départemental, régional ou national ou au niveau de l'ensemble des CHU, des cabinets dentaires, etc..., en fonction de leurs localisations dans le réseau informatique 10. Bien qu'un serveur de rapprochements soit illustré ici comme une entité informatique distincte, en variante, un serveur de rapprochements peut également être adapté pour mettre en oeuvre les fonctions de serveur de gestion d'identités pour le réseau d'une organisation médicale. Pour l'ensemble des identités qu'il gère en tant que serveur de gestion d'identités, on parlera de domaine interne. Bien entendu, ce domaine interne participe au domaine de rapprochements du serveur, c'est- à-dire que le serveur de rapprochements rapproche son domaine interne avec ses domaines externes. Enfin, un utilisateur autorisé peut se connecter à chacun des serveurs de gestion d'identités ou de rapprochements par un terminal 26, 27, comme cela sera expliqué plus en détail par la suite. La figure 2 est une vue plus en détail d'un serveur 40 de gestion d'identités conforme à l'invention. Le serveur 40 comprend une interface 42 de communication avec des tiers. Cette interface 42 comprend une interface de communication 44 avec chaque serveur externe 46 de contenu pour lequel il gère les identités de patients et chaque serveur de rapprochements rapprochant les identités du serveur 40 et/ou dont les identités sont rapprochées par le serveur 40. L'interface 42 comprend également une interface utilisateur 48 pour la communication avec chaque utilisateur connecté au serveur 40 au moyen d'un terminal 50. De manière préférentielle, le serveur 40 de gestion d'identités et les serveurs 46 externes utilisent un protocole de communication d'informations basé sur des notifications et des requêtes/réponses, par exemple du type HL7 XML, et l'interface de communication 44 est un service applicatif du type service Web. De manière préférentielle, le serveur 40 et un terminal d'utilisateur, ou un serveur externe, communiquent 1par un protocole SOAP utilisant une couche de transport sécurisée du type SSL par exemple. L'utilisateur accède au serveur 40 au moyen d'un applicatif client léger, comme un navigateur web par exemple, et l'interface utilisateur 48 est un applicatif du type portlet. L'interface utilisateur 48 est associée à un applicatif 52 d'autorisation et d'authentification pour contrôler l'accès des utilisateurs au serveur 40 et à l'ensemble de ses fonctions et des informations qu'il mémorise. Cet applicatif 52 est associé à une base de données relationnelle d'utilisateurs 52a, ou annuaire d'utilisateurs, qui répertorie des informations d'authentification d'utilisateurs, comme des identifiants, des mots de passe et des certificats numériques par exemple. L'applicatif 52 est également associé à une base 52b de données d'autorisations d'accès aux fonctions et aux données du serveur 40. Cette base 52b répertorie des informations d'autorisations prédéterminées pour chaque utilisateur répertorié dans la base 52a, comme cela sera expliqué plus en détail par la suite. Le serveur 40 comprend en outre des moyens de stockage 54 de données comprenant une base de données 56 mémorisant des identités de patients, une base de données 58 mémorisant des informations relatives à la configuration du serveur 40 et une base de données 60 formant journal de traces mémorisant des informations relatives aux accès au serveur 40 par des tiers et les types d'opérations effectuées par ceux-ci. Le serveur 40 comprend un ensemble d'applicatifs 62, un premier applicatif 64 mettant en oeuvre des fonctions de gestion d'identités, un second applicatif 66 mettant en oeuvre des fonctions de configuration du serveur 40 et un troisième applicatif 68 mettant en oeuvre des fonctions de gestion des traces d'accès au serveur 40. Une identité mémorisée dans la base de données 56 d'identités comprend une pluralité de champs d'identification, notamment un identifiant principal, un ensemble de propriétés décrivant le patient et définissant des règles d'administration de l'identité et un drapeau d'état général de l'identité. L'identifiant principal référence de manière unique et biunivoque l'identité dans le domaine interne du serveur 40, c'est-à-dire sur le réseau informatique dont il gère les identités de patients. Les propriétés comprennent un ensemble d'informations de description du profil du patient pour l'identification de celui-ci, notamment des champs alphanumériques comme nom , prénom , sexe , lieu , date de naissance , pseudonyme du patient, etc.... Ces propriétés sont réparties entre des propriétés principales définies comme nécessaires pour l'identification du patient, des propriétés secondaires définies comme non nécessaires, et des propriétés complémentaires uniquement accessibles au personnel soignant autorisé, comme un médecin par exemple. Chaque propriété est associée à un drapeau d'état de celle-ci, pouvant prendre la valeur provisoire Si l'information contenue dans la propriété n'est pas certaine, validée Si cette information est certaine ou vide Si aucune information n'est contenue dans la propriété. Des propriétés d'administration définissent la manière selon laquelle l'identité est administrée par le serveur 40 (anonymat, confidentialité, informations pertinentes, mode de manipulation par défaut de l'identité en fonction du drapeau général et des drapeaux des propriétés de profil, etc...). Les propriétés comprennent également un ensemble de champs pour la description d'éventuelles liaisons logiques avec d'autres identités de patients de la base de données 56 d'identités, notamment un champ doublon , un champs filiation et un champ homonymie , comme cela sera expliqué plus en détail par la suite. Un champ de liaison logique comprend par exemple l'identifiant d'une identité, de sorte qu'il est possible d'accéder à une identité à travers sa liaison logique avec une autre identité. Le drapeau d'état général détermine l'état général de l'identité. Cet état peut être actif , c'est-à-dire que l'identité est en ligne, esclave , c'est- à-dire que l'identité est sous la dépendance d'une autre identité associée au même patient, vide , c'est-à-dire qu'au moins une des propriétés principales n'est pas renseignée, provisoire , c'est-à-dire qu'au moins une des propriétés principales est à l'état provisoire et hors ligne , c'est-à-dire que l'identité est non utilisée pour l'indexation d'informations médicales. La figure 3 est un organigramme des étapes principales du procédé de gestion d'identités mis en oeuvre par le serveur 40 de gestion d'identités. Dans une étape 70, un utilisateur, comme un opérateur médical ou un médecin par exemple, envoie une requête de connexion au serveur 40 de gestion d'identités via un navigateur Web installé sur le terminal informatique 50 connecté au serveur 40. En réponse, le serveur 40 envoie en 72 une requête d'authentification de l'utilisateur, par exemple en affichant une fenêtre demandant la saisie d'un identifiant et d'un mot de passe. L'utilisateur saisit en 74 son identifiant et son mot de passe, et le tout est notifié au serveur 40 par l'activation d'un bouton prévu à cet effet sur la fenêtre de demande de saisie. En variante, le serveur 40 requiert également un certificat numérique à des fins d'authentification de haut niveau de l'utilisateur. Ce certificat numérique est par exemple généré par un algorithme du type PKI utilisant une clef privée, et est mémorisé dans une carte à puce. Le terminal de l'utilisateur est équipé d'un terminal de carte à puce et, lors de la demande d'authentification, le lecteur lit le certificat contenu dans la carte et le notifie au serveur 40. Le serveur reçoit, en 76, ces informations et active l'applicatif 52 d'authentification et d'autorisation. Ce dernier compare les informations reçues aux informations contenues dans la base 52a de données d'utilisateurs pour l'authentification de l'utilisateur. Si l'utilisateur est authentifié par le serveur 40 de gestion d'identités, la connexion est ouverte et initialisée. Un ensemble prédéterminé d'autorisations d'accès aux fonctions et aux informations du serveur 40 est alors alloué en 78 à la connexion. Par exemple, un applicatif java est exécuté sur le terminal de l'utilisateur affichant une fenêtre répertoriant des fonctions et des types d'informations du serveur 40 auxquels l'utilisateur est autorisé à faire appel ou consulter. En 80, l'utilisateur manipule cette fenêtre sur la base d'une fonction du serveur 40 à laquelle il a accès et qu'il souhaite utiliser. Lors de l'étape 82 suivante du fonctionnement du serveur 40, l'applicatif correspondant à la fonction sélectionnée est activé et un échange d'informations est établi, si requis par la fonction, entre l'utilisateur et le serveur 40. Plus particulièrement, les fonctions mises en oeuvre par le serveur 40 au moyen des applicatifs susmentionnés et accessibles à un utilisateur, sous les conditions d'autorisation susmentionnées, sont notamment la: création d'une identité : sur requête de l'utilisateur, l'applicatif 64 de gestion d'identité crée une identité dans la base 56 de données d'identités et lui attribue un identifiant principal unique sur le domaine interne du serveur; - modification d'une identité : sur requête de l'utilisateur, l'applicatif 64 modifie une des propriétés ou un des états de celle-ci; - création et suppression d'une liaison logique entre identités: sur requête de l'utilisateur, l'applicatif 64 crée ou supprime une liaison logique entre deux identités; - recherche de doublons d'identités; - fusion et annulation de fusion entre identités; suppression physique d'une identité : sur requête de l'utilisateur, l'applicatif 64 supprime physiquement unie identité de la base de données 56 d'identités; - recherche multicritère d'identités: sur requête de l'utilisateur, une fenêtre de recherche est affichée sur le terminal 50. Cette fenêtre comprend par exemple des champs pour la saisie d'informations pour la recherche d'identités, comme un identifiant, un nom, un prénom, etc... De manière avantageuse, l'applicatif 64 comprend un moteur de recherche dans la base de données 56 d'identités. Ce dernier peut être interrogé selon un protocole d'interrogation du type à requête permettant l'utilisation de méta-caractères comme l'astérisque, le pointd'interrogation et des opérateurs logiques, comme cela est connu en soi; consultation d'une identité : sur requête de l'utilisateur, l'applicatif 64 affiche un profil prédéterminé d'une identité que l'utilisateur a sélectionnée, par exemple à la suite d'une recherche multicritère. Le profil affiché est déterminé en fonction des autorisations de l'utilisateur. Par exemple, seules les propriétés principales peuvent être affichées, ou bien la valeur du champ pseudonymé de l'identité est la seule à être affichée si l'identité est confidentielle; et - recherche de liaison logique entre identités: sur requête de l'utilisateur, l'applicatif 64 affiche sur le terminal 50 une fenêtre comprenant un champ de saisie d'identifiant et un champ de saisie du type de liaison logique recherché. L'utilisateur saisit l'identifiant d'une identité et le type de liaison recherchée. Ces informations sont notifiées à l'applicatif 64 qui délivre en retour au terminal 50 les informations recherchées. Une fois les opérations associées à la fonction terminées, si la fonction appelée a modifié une identité mémorisée dans la base de données d'identités 56, c'est-à-dire créé une identité, modifié des informations contenues dans celle-ci, l'a supprimée logiquement (i.e. mise hors ligne) ou physiquement, le serveur 40 notifie, en 84, les modifications survenues sur celle-ci à l'ensemble des serveurs de rapprochements et de contenu utilisant cette identité qui lui sont connectés. En réponse, ces derniers mettent à jour leurs propres bases de données d'identités. L'étape 86 suivante active l'applicatif 68 de gestion des traces qui met alors à jour la base de données 60 mémorisant les informations d'accès au serveur 40, à ses fonctions et à ses données. L'applicatif 68 inscrit par exemple dans cette base de données l'identifiant et l'instant de l'accès de l'utilisateur au serveur 40 et des informations relatives aux différents types d'opérations qu'il a effectuées sur celui-ci, comme par exernple la modification d'une identité, la recherche de doublons d'identités, la modification d'une règle d'administration d'une identité, etc... L'étape 86 boucle alors sur l'étape 80 pour l'appel à une autre fonction du serveur ou une étape 88 de fermeture de la session ouverte par l'utilisateur est activée. La figure 4 est un organigramme de l'algorithme mis en oeuvre par l'applicatif 64 de gestion d'identités pour la recherche de doublons d'identités dans la base de données 56 d'identités. Dans une étape 100, un utilisateur ayant ouvert une session sous le serveur 40 d'identités au moyen d'un terminal et étant autorisé à utiliser la fonction de détection de doublons d'identités envoie une requête de recherche de doublons d'identités au serveur 40. En réponse, ce dernier affiche, en 102, sur le terminal 50 de l'utilisateur une fenêtre de sélection de paramètres pour la recherche de doublons. Cette fenêtre de sélection comprend notamment un champ de sélection d'un domaine interne du serveur 40 et un champ de sélection d'un ] 0 mode de détection de doublons parmi un ensemble prédéterminé de modes de détection, par exemple un mode de détection du type à comparaison phonétique et un mode de détection du type à comparaison par écart, qui seront décrits plus en détail par la suite. Un autre champ de la fenêtre permet à l'utilisateur, s'il le désire, de ] 5 restreindre la recherche de doublons à un ensemble prédéterminé d'identités de patients, par exemple celles dont la valeur d'un champ alphanumérique commence par un préfixe saisi par l'utilisateur. Une fois que l'utilisateur a terminé la sélection des paramètres pour la recherche de doublons, il en notifie, toujours en 102, le serveur 40 en cliquant par exemple sur un bouton de la fenêtre prévu à cet effet et les paramètres sélectionnés dans les champs de la fenêtre sont alors délivrés, via l'interface utilisateur 48, à l'applicatif 64 de gestion d'identités. Dans une étape 104 suivante, l'applicatif 64 initialise la recherche de doublons en déterminant l'ensemble des identités de la base de données 58 qui satisfont au domaine et au préfixe qui ont été éventuellement sélectionnés par l'utilisateur. Sinon, la recherche de doublons est réalisée sur l'ensemble de la base de données 56 d'identités. Dans l'étape 106 suivante, l'applicatif 64 sélectionne une première et une seconde identités de l'ensemble sélectionné qui n'ont pas encore été 30 comparées. Dans une étape 108 suivante, l'applicatif 64 teste, en fonction des règles d'administration du serveur 40, si chacune des identités sélectionnées satisfait aux conditions prédéterminées pour pouvoir être comparées. Par exemple, l'applicatif 64 peut être configuré pour comparer des identités qui sont actives et dont l'ensemble des propriétés principales sont renseignées et à l'état validé . Dans le mode de réalisation ici décrit, l'applicatif 64 teste si les identités sont actives et si leurs champs nom et prénom sont à l'état validé . Si le mode de détection du type phonétique a été sélectionné, l'applicatif 64 teste en outre si les champs sexe et date de naissance sont à l'état validé . Si le résultat du test en 108 est négatif, l'applicatif 64 détermine, en 110, un taux de similarité faible entre les identités sélectionnées et boucle sur l'étape 106 pour la sélection d'une autre paire d'identités. Si le résultat de ce test est positif, le fonctionnement de l'applicatif 64 se poursuit par la comparaison en 112 des première et seconde identités sélectionnées afin de déterminer un taux de similarité entre celles-ci. Si le mode de détection des doublons par comparaison du type phonétique a été sélectionné par l'utilisateur, l'applicatif 64 exécute alors la comparaison phonétique des champs alphanumériques nom des première et seconde identités ainsi qu'à la comparaison phonétique des champs alphanumériques prénom de celles-ci. La comparaison phonétique de deux champs, par exemple les champs prénom , mise en oeuvre par l'applicatif 64, consiste tout d'abord à générer un code phonétique pour chacun des champs prénom des première et seconde identités, de la manière illustrée sur l'organigramme de la figure 5. Dans une étape 114, l'applicatif 64 crée une chaîne de caractères pour chacun des champs prénom en dupliquant celui-ci, puis en conservant la première lettre de cette chaîne et en suppriment ensuite les lettres A, E, I, O, U, Y, H et W de celle-ci. Dans une étape 116 suivante, chaque lettre restante de la chaîne créée en 114, hormis la première, est remplacée par l'applicatif 64 par un chiffre prédéterminé correspondant, tel que décrit par le tableau 1, afin de générer un code. 1 B,P C, Q, K 3 D, T 4 L M, N 6 R 7 G,J 8 X, Z, S 9 F,V Tableau 1: table de correspondance entre chiffres et lettres. Par exemple, la suite de lettres GRGR, produite à la suite de la suppression des lettes E, O et Y de la chaîne GREGORY, est remplacée par le code G676. L'étape 118 suivante, l'applicatif 64 élimine les multiplicités de chiffres identiques de manière à générer un code comprenant une seule occurrence par chiffre. Par exemple, le code G676 est remplacé en 116 par le code G67. De manière préférentielle, les chiffres les plus à gauche sont conservés. Dans l'étape 120 suivante, si le code généré en 118 comprend moins de N éléments, où N est un nombre prédéterminé, par exemple égal à 4, l'applicatif 64 le complète par un ou plusieurs zéros à droite de manière à obtenir une suite de N éléments. Par exemple, le code G67 est complété à droite par un zéro. L'étape 122 suivante consiste alors à sélectionner les N éléments les plus à gauche des codes générés en 116 pour chacun des champs prénom des identités pour obtenir un code phonétique pour celui-ci. Dans l'étape 124 suivante, l'applicatif 64 détermine un taux de similarité entre les première et seconde identités en fonction des codes phonétiques déterminés en 122. Si les champs nom et prénom des première et seconde identités correspondent phonétiquement, c'est-à-dire si leurs codes phonétiques respectifs sont identiques, et que leurs champs sexe ou leurs champs date de naissance sont respectivement identiques, alors l'applicatif 64 détermine un taux de similarité fort entre les deux identités. Si seulement leurs champs nom correspondent phonétiquement et que leurs champs sexe et leur champs date de naissance sont identiques, alors l'applicatif 64 de gestion d'identités détermine un taux de similarité moyen entre les deux identités. Dans tous les autres cas, l'applicatif 64 détermine un taux de similarité faible entre la première et la seconde identités. Bien entendu, d'autres champs des identités que les champs sexe et date de naissance peuvent être utilisés pour déterminer le taux de similarité entre deux identités. Si le mode de détection des doublons du type à écart a été sélectionné par l'utilisateur, l'applicatif 64 détermine le taux de similarité en fonction des champs nom et prénom des première et seconde identités, comme cela est illustré sur le diagramme de la figure 6. Une première étape 130 de la détermination du taux de similarité par comparaison du type à écart est une étape d'initialisation d'une matrice R pour chaque paire de champs de même type des première et seconde identités, par exemple les champs nom . Cette matrice comprend N lignes et M colonnes, où N et M sont les longueur des valeurs des champs nom de la première et de la seconde identités respectivement. La première ligne de la matrice R est initialisée au vecteur ligne [0 1 2... N] et la première colonne de la matrice R au vecteur colonne [0 1 2... MIT, où T est le symbole de la transposée. Lors de l'étape 130 deux compteurs i et j sont également initialisés à la valeur O. Un test est réalisé dans une l'étape 132 suivante pour savoir si la valeur du compteur i est égale à N+1. Si le résultat de ce test est positif, un écart de similarité est alors déterminé en 134 entre les deux champs nom comme étant égal à R(N,M). Si le résultat de ce test est négatif, un test est réalisé en 136 pour savoir si la valeur du compteur j est égale à M+1. Si le résultat de ce test est positif, le compteur i est incrémenté de 1 dans une étape 138 qui boucle ensuite sur l'étape 132. Si le résultat de ce test est négatif, une étape 140 suivante consiste à comparer la ième lettre de la valeur du champ nom de la première identité à la jème lettre de celle du champ nom de la seconde identité. Si celles-ci sont identiques, la valeur d'une variable c est réglée, en 140, sur 0, et si elles sont différentes, la valeur de c est réglée;sur 1, toujours en 140. Le minimum parmi les valeurs R(i-1,j)+1, R(i,j-1)+1 et R(i-1,j-1)+ c est alors déterminé et affecté à la valeur de R(i,j) dans une étape 142. Dans une étape 144 suivante, la valeur du compteur j est incrémentée de 1 et l'étape 144 boucle sur l'étape 136 pour un nouveau cycle. Un écart de similarité moyen entre la première et la seconde identités est ensuite calculé par l'applicatif 64 en réalisant la moyenne des écarts de similarité obtenus pour les champs nom et prénom de celles-ci. Le taux de similarité entre les deux identités est alors déterminé par correspondance entre la valeur de l'écart de similarité moyen calculé et un taux de similarité prédéterminé tel que décrit dans le tableau 2. Ecart moyen Taux de similarité 0 identique 1 fort 2 moyen 3 faible Tableau 2: correspondance entre l'écart moyen et le taux de similarité. La mise en oeuvre de l'une ou l'autre des détections de doublons susmentionnées permet de rechercher des identités potentiellement associées à un même patient, dont une, par exemple, comprendrait une erreur dans l'orthographe du nom du patient. En se référant de nouveau à la figure 3, l'étape 150 suivante du fonctionnement de l'applicatif 64 de gestion d'identité consiste à comparer le taux de similarité déterminé à un seuil prédéterminé. Par exemple, ce seuil est égal à fort, un taux de similarité identique étant supérieur à un taux de similarité fort, lui-même supérieur à un taux de similarité moyen, lui-même supérieur à un taux de similarité faible. Si le taux de similarité déterminé est supérieur au seuil prédéterminé, l'applicatif 64 crée, toujours en 150, une liaison logique entre ces deux identités, à savoir une liaison de doublon potentiel . L'applicatif 64 règle à cet effet le champ de liaison logique doublon de la première identité sur doublon potentiel et écrit l'identifiant principal de la seconde identité dans ce champ. D'une manière analogue, l'applicatif 64 règle le champ de liaison logique doublon de la seconde identité sur doublon potentiel et écrit l'identifiant principal de la première identité dans ce champ. Ainsi, la première et la seconde identités sont déterminées comme potentiellement associées au même patient et reliées logiquement dans la base de données 56 d'identités. Dans l'étape 152 suivante, l'applicatif 64 teste si toutes les identités de l'ensemble sélectionné par l'utilisateur ont été comparées. Si le résultat de ce test est négatif, l'étape 152 boucle sur l'étape 106 pour la sélection et la comparaison d'une nouvelle paire d'identités. Si le résultat de ce test est positif, l'applicatif 64 affiche en 154 sur le terminal 50 de l'utilisateur la liste des doublons potentiels qu'il a déterminés. L'organigramme de la figure 7 illustre l'algorithme de suppression de doublons d'identités potentiellement associées à un même patient mis en oeuvre par l'applicatif 64. Dans une étape 200, un utilisateur ayant ouvert une session sous le serveur 40 de gestion d'identités, et étant autorisé à utiliser la fonction de suppression de doublons d'identités mise en oeuvre par l'applicatif 64, envoie une requête en suppression de doublons au serveur 40. En réponse, ce dernier envoie en 202 au terminal 50 une fenêtre d'affichage de la liste des doublons potentiels mémorisés dans la base de données 56 d'identités, c'est-à-dire les paires d'identités reliées par une liaison logique de doublon potentiel . L'utilisateur sélectionne, en 204, une telle paire d'identités et en réponse l'applicatif 64 envoie, en 206, au terminal 50 de l'utilisateur une fenêtre d'affichage d'un profil prédéterminé du patient associé à chacune de ces identités, par exemple les valeurs des propriétés nom , prénom , sexe , date de naissance et adresse . L'utilisateur détermine alors en 208 si les deux identités sont effectivement associées au même patient. Si tel n'est pas le cas, l'utilisateur envoie une requête d'affichage de la liste des doublons potentiels et l'étape 208 boucle sur l'étape 202. Si tel est le cas, l'utilisateur envoie, toujours en 208, une requête de modification de la liaison logique doublon potentiel en doublon validé . En réponse, en 210, l'applicatif 64 modifie les identités en réglant leur champ doublon sur doublon validé . En réglant ainsi le champ doublon des identités sur doublon validé , celles-ci sont alors déterminées comme effectivement associées au même patient. L'utilisateur, ou en variante l'applicatif 64, sélectionne ensuite, en 212, l'une des identités comme étant une identité maître et le notifie au serveur 40. En réponse, l'applicatif 64 règle, en 214, le drapeau d'état général de l'autre identité sur l'état esclave et la désactive. Cette identité est alors mise hors-ligne et indexée sous son identité maître. L'identité esclave est ainsi fusionnée sous l'identité maître. Le serveur envoie ensuite, en 216, une notification à chaque système tiers externe de contenu et de rapprochements qui lui est connecté que l'identité a été désactivée et est à présent fusionnée sous l'identité maître. En réponse, ces derniers mettent à jours leurs bases de données d'identités. Ainsi, les informations médicales préalablement référencées sous l'identité esclave sont à présent référencées sous l'identité maître. L'étape 216 boucle alors sur l'étape 202 pour la sélection d'un nouveau doublon potentiel d'identités. Comme on peut le noter, de proche en proche, les identités associées à un même patient sont fusionnées sous une unique identité maître. Ainsi, l'ensemble des informations médicales relatives à un même patient sont référencées dans le domaine interne du serveur 40 par une unique identité de celui-ci. Un utilisateur autorisé peut défusionner deux identités fusionnées. Sur requête de celui-ci, l'applicatif 64 remet en ligne une identité esclave dans son état initial, c'est-à-dire l'état avant sa fusion, et règle le champ doublon sur collision pour indiquer que l'identité est à nouveau active. La remise en ligne de l'identité est alors notifiée aux serveurs tiers pour qu'ils remettent à jour leurs bases de données, et les informations médicales associées à cette identité sont ainsi de nouveau indexées par celle-ci. Le serveur 40 de gestion d'identités est également propre à, régulièrement, périodiquement, ou sur requête d'un utilisateur autorisé, générer des statistiques de type prédéterminé. L'applicatif 68 de gestion des traces met en oeuvre des calculs statistiques sur les informations de traces mémorisées dans la base de données 60 de traces pendant une période de temps prédéterminée, par exemple les dernières vingt-quatre heures, la dernière semaine, ou autres. Les calculs mis en oeuvre par cet applicatif 68 portent par exemple sur le nombre d'accès au serveur, le type et le nombre d'opérations effectuées par et sur celui-ci, le type d'informations consultées et/ou modifiées, les modifications des règles d'administration des identités, les modifications d'authentifications et d'autorisations, ou autres. Le serveur 40 est également propre à être accédé par chaque serveur externe de contenu et de rapprochements qui lui est connecté. Ce serveur est propre à lui délivrer des requêtes en recherche et en consultation d'identités auxquelles le serveur 40 répond en lui délivrant la liste d'identités trouvées ou l'identité consultée. II va maintenant être décrit un serveur de rapprochements conforme à l'invention en relation avec la figure 8. Sur la figure 8, il est illustré un serveur 300 de rapprochements qui est également un serveur de gestion d'identités pour des serveurs de contenu. Il partage donc des éléments communs avec le serveur de gestion d'identités décrit en relation avec la figure 2. Ces éléments sont référencés de manière identique à ceux du serveur de la figure 2 et leur description sera donc omise ici pour des raisons de concision. Le serveur 300 de rapprochements a donc un domaine interne d'identités pour lequel il met en oeuvre une gestion d'identités en tant que serveur de gestion d'identités, un domaine de rapprochements interne constitué d'un ensemble d'identités, mémorisées sur des serveurs de gestion d'identités, qu'il fédère sous ses identités fédératrices. Le serveur 300 de rapprochements comprend un applicatif 302 de gestion des rapprochements mettant en oeuvre des fonctions de rapprochements d'identités, comme cela sera expliqué plus en détail par la suite. Cet applicatif 302 de gestion de rapprochements est associé à une base de données 304 de rapprochements qui répertorie les identités fédératrices et des rapprochements associés, comme cela sera expliqué également plus en détail par la suite. L'applicatif d'autorisation et d'authentification 52, ainsi que la base de données d'autorisation 52b, comprennent des informations d'autorisations supplémentaires relatives à des droits d'utilisateurs sur l'utilisation des fonctions de l'applicatif 302 et de manipulations des informations de rapprochements de la base de données 304 de rapprochements. Le format des identités fédératrices est par exemple analogue à celui précédemment décrit pour l'identité d'un patient. L'identifiant principal d'une identité fédératrice est créé par le serveur pour qu'elle soit unique sur le domaine interne de rapprochements de celui-ci. L'organigramme de la figure 9 illustre le fonctionnement du serveur 300 en tant que serveur de rapprochements. Dans une étape 400, une identité fédératrice pour un patient, référencée sur le domaine de rapprochement du serveur de rapprochements, est créée par l'applicatif 302 de rapprochements dans la base de données 304 de rapprochements. Cette création peut être réalisée sur requête d'un utilisateur autorisé et connecté au serveur 302 d'une manière analogue à la création d'une identité sur le serveur de gestions d'identités décrit en relation avec la figure 2. L'utilisateur renseigne alors des champs de l'identité fédératrice créée avec des informations relatives à ce patient. Sinon, la création de l'identité fédératrice peut également être réalisée par l'applicatif 302 en réponse à une requête d'un serveur de gestion d'identités ou de rapprochements connecté au serveur 300. Lorsqu'un serveur tiers crée une identité pour un nouveau patient dans sa base de données d'identités ou de rapprochements, il en notifie le serveur 300 de rapprochements. Celui-ci vérifie alors si le patient est déjà référencé par une identité fédératrice de la base de données de rapprochements. Si tel n'est pas le cas, le serveur 302 de rapprochements créée alors une nouvelle identité fédératrice avec les informations délivrées par ce serveur externe. Par exemple, l'applicatif 302 de rapprochements est adapté pour convertir l'identité du patient notifiée par le serveur externe au format d'identités utilisé par le serveur 300 de rapprochements en lui attribuant en outre un identifiant unique sur son domaine de rapprochements. Lors de l'étape 402 suivante, le serveur 302 de rapprochements notifie les serveurs externes d'une telle création. Dans une étape 404 suivante, un utilisateur connecté au serveur 302 envoie une requête en rapprochement d'identités. Une fenêtre s'affiche alors sur le terminal de celui-ci et comprend un champ de saisie de l'identifiant d'une identité fédératrice du serveur et un champ de saisie de l'identifiant d'une identité d'un serveur externe à rapprocher. L'utilisateur saisie alors en 406 les identifiants des deux identités qu'il souhaite rapprocher et valide son choix. En réponse, l'applicatif 302 crée alors, en 408, dans la base de données 304 de rapprochements un nouveau rapprochement. Ce rapprochement comprend les identifiants de l'identité fédératrice et de l'identité rapprochée de sorte que l'identité du serveur externe est indexée, ou fédérée, sous l'identité fédératrice du serveur 300 de rapprochements. En variante, l'identité fédératrice peut comprendre des champs supplémentaires propres à répertorier les identifiants des identités qu'elle fédère. On comprendra que ce qui vient d'être décrit est également valable pour les identités que le serveur 300 de rapprochements gère en tant que serveur de gestion d'identités. En effet, les services de gestion d'identités et de rapprochements du serveur 300 communiquent entre eux pour le rapprochement des identités mémorisées dans la base de données 56 d'identités. De manière avantageuse, l'utilisateur peut, en variante, réaliser, en 410, une recherche des identités potentiellement associées au même patient sur les domaines internes ou externes du serveur 300 de rapprochements. Cette recherche est réalisée par exemple d'une manière analogue à celle de la recherche de doublons d'identités décrite précédemment. Par exemple, l'applicatif 302 envoie, en 412, des requêtes en recherche et consultation d'identités aux serveurs d'identités et de rapprochements tiers en fonction des informations contenues dans une identité fédératrice, par exemple les valeurs des champs nom et prénom de celle-ci. Les serveurs notifiés mettent alors en oeuvre, en 414, une recherche, dans leurs bases de données d'identités respectives ou de rapprochements, des identités satisfaisant ces informations et délivrent les identités trouvées au serveur 300 de rapprochements. Le serveur 300 de rapprochements met alors en oeuvre l'algorithme de comparaison du type phonétique ou du type à écart et génère une liste d'identités potentiellement associées au patient de l'identité fédératrice. L'utilisateur sélectionne alors, en 416, une ou plusieurs identités et valide chaque identité qu'il considère comme effectivement associée au patient de l'identité fédératrice. Le serveur 302 crée alors en réponse, en 418, un rapprochement entre l'identité fédératrice et l'identité validée comme cela a été décrit précédemment. D'une manière analogue à celle décrite précédemment, un utilisateur autorisé peut rechercher, consulter, supprimer, modifier ou supprimer une identité fédératrice. II peut également supprimer un rapprochement, consulter l'ensemble ou une partie des identités fédérées sous une identité fédératrice. Par exemple, un utilisateur peut créer des liaisons logiques entre deux identités fédératrices, modifier la valeur d'une propriété d'une identité ou d'un drapeau de celle-ci, etc... Dès qu'une modification sur une identité fédératrice est réalisée, l'applicatif 302 le notifie à chaque serveur de rapprochements externes qui lui est connecté pour qu'il mette à jour sa base de données de rapprochements. En outre, le serveur 300 de rapprochements est propre à recevoir des notifications sur des modifications d'identités de la part de chaque serveur de gestions d'identités ou de rapprochements qui lui est connecté. Ces notifications comprennent par exemple des informations relatives aux modifications survenues sur des identités gérées par ceux-ci, et, en réponse, le serveur 300 met à jours sa base de données 304 de rapprochements en fonction de ces informations. Par exemple, lorsqu'une identité est supprimée sur un serveur et fait l'objet d'un rapprochement sur le serveur 300, ce dernier supprime ce 5 rapprochement. De manière avantageuse, l'applicatif 302 est également propre à supprimer les doublons d'identités fédératrices de la base 304 de rapprochement en mettant en oeuvre un procédé analogue à celui décrit en relation avec les figures 4, 5, 6 et 7 afin qu'il n'existe qu'une seule identité fédératrice par patient. REVENDICATIONS 1. Procédé de gestion d'identités de patients d'un réseau (10) informatique de production et de mémorisation d'informations médicales relatives à ces patients et référencées sur le réseau (10) par les identités de ceux-ci, caractérisé en ce qu'il comprend: - une étape (100, 102, 104, 106, 108, 110, 112) de recherche sur le réseau d'identités potentiellement associées à un même patient; - une étape (208) de validation d'au moins une identité trouvée comme étant effectivement associée à ce patient; - une étape (214) de sélection d'une identité parmi les identités validées; et - une étape (216) de fusion sous l'identité sélectionnée d'au moins une autre identité validée, de sorte que cette au moins une autre identité fusionnée est mise hors ligne, et que les informations relatives à ce patient préalablement référencées par cette au moins une autre identité fusionnée sont à présent référencées par l'identité sélectionnée de ce patient. 2. Procédé selon la revendication 1, caractérisé en ce que l'identité d'un patient comprend une pluralité de champs alphanumériques d'identification de celui-ci, et en ce que l'étape de recherche comprend: - une étape (102, 104) de sélection d'au moins un ensemble d'identités du réseau en fonction d'un premier champ prédéterminé et/ou d'une partition prédéterminée du réseau en sous-réseaux informatiques; - une étape (106) de sélection de deux identités de l'ensemble sélectionné ; - une étape (110) de comparaison de ces deux identités adaptée pour comparer les valeurs d'au moins un second champs de celles-ci; et - une étape (150) de création d'une relation logique entre ces deux identités si elles présentent un taux de similarité supérieur à une valeur prédéterminée, cette relation les définissant comme des identités potentiellement associées à un même patient. 3. Procédé selon la revendication 2, caractérisé en ce que la pluralité de champs d'identification de l'identité d'un patient comprend des chaînes de caractères relatives respectivement au nom, au prénom, à la date de naissance au sexe de celui-ci, en ce que l'étape de comparaison des deux identités comprend la mise en oeuvre d'un algorithme du type à comparaison phonétique entre, d'une part, les noms de ces deux identités, et d'autre part, les prénoms de ces deux identités, et en ce que: - si les noms et les prénoms de ces deux identités correspondent phonétiquement, et que les sexes ou les dates de naissance de celles-ci sont identiques, alors les deux identités sont déterminées comme présentant un taux fort de similarité ; - si seulement les noms de ces deux identités correspondent phonétiquement, et que les sexes et les dates de naissance de celles-ci sont identiques, alors les deux identités sont déterminées comme présentant un taux moyen de similarité ; et -sinon ces deux identités sont déterminées comme présentant un taux faible de similarité. 4. Procédé selon la revendication 2, caractérisé en ce que la pluralité de champs d'identification de l'identité d'un patient comprend des chaînes de caractères relatives respectivement au nom et au prénom de celui-ci, en ce que l'étape (110) de comparaison des deux identités comprend la mise en oeuvre d'un algorithme du type à écart entre, d'une part, les noms de ces deux identités, et d'autre part, les prénoms des ces deux identités, et pour déterminer un taux de similarité entre celles- ci en fonction de la moyenne des écarts entre les noms et les prénoms renvoyés par l'algorithme du type à écart. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape (84) de création de liaison logique entre deux identités du réseau. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape de suppression d'une fusion entre deux identités du réseau, l'identité fusionnée étant alors remise en ligne et les référencements d'informations médicales par ces identités étant alors rétablis à leur état initial. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une étape (82) de recherche, par un opérateur médical ou un système externe tiers, d'une identité de patient du réseau par interrogation de la valeur d'au moins un champ d'identification de l'identité. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'identité d'un patient du réseau comprend une pluralité de champs d'identification répartie en ensembles de champs d'identification, notamment un champ d'identifiant référençant de manière biunivoque sur le réseau le patient associé à l'identité et des propriétés relatives à des informations d'identifications principales, secondaires, complémentaires et d'administration de l'identité respectivement. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lorsqu'une identité du réseau est modifiée, une notification en est faite à l'ensemble des moyens informatiques du réseau utilisant une telle identité pour la mise à jour de celle-ci dans ces moyens informatiques. 10. Serveur (40) de gestion d'identités de patients d'un réseau (10) informatique de production et de mémorisation d'informations médicales relatives à ces patients et référencées sur le réseau par les identités de ceux-ci, caractérisé en ce qu'il comprend: - des moyens (50, 56, 64) de recherche sur le réseau d'identités 20 potentiellement associées à un même patient; - des moyens (50, 64) de validation d'au moins une identité trouvée comme étant effectivement associée à ce patient; - des moyens (50, 64) de sélection d'une identité parmi les identités validées; et - des moyens (64) de fusion sous l'identité sélectionnée d'au moins une autre identité validée, de sorte que cette au moins une autre identité fusionnée est mise hors ligne, et que les informations relatives à ce patient préalablement référencées par cette au moins une autre identité fusionnée sont à présent référencées par l'identité sélectionnée de ce patient. 11. Serveur selon la revendication 10, caractérisé en ce qu'il est adapté pour mettre en oeuvre un procédé de gestion d'identités conforme à l'une quelconque des revendications 2 à 9. 12. Serveur selon la revendication 10 ou Il, caractérisé en ce qu'il comprend des moyens de mémorisation (60) de traces pour mémoriser des informations relatives à des d'accès à celui-ci et aux fonctions de celui-ci. 13. Serveur selon la revendication 12, caractérisé en ce qu'il comprend des moyens (68) de génération de statistiques en fonction d'informations mémorisées dans les rnoyens sur une période de temps prédéterminée dans les moyens de mémorisation de traces. 14. Serveur selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comprend des moyens (52, 52a) d'authentification d'un 10 utilisateur connecté par un terminal. 15. Serveur selon la revendication 14, caractérisé en ce qu'il comprend des moyens (52, 52b) d'allocation, à l'utilisateur, d'autorisations d'un ensemble prédéterminé d'autorisations portant sur l'utilisation de fonctions et l'accès à des informations du serveur. 16. Procédé de rapprochement des identités de patients d'une pluralité de réseaux informatiques (12A, 12B; 12C, 12D) de production et de mémorisation d'informations médicales relatives à ces patients, caractérisé en ce qu'il comprend: - une étape (400) de création d'une identité fédératrice pour un 20 patient identifié dans la pluralité de réseaux; - une étape (404; 410) de recherche, sur la pluralité de réseaux, d'identités potentiellement associées à ce même patient; - une étape (406; 416) de validation d'une identité trouvée comme étant effectivement associée à ce même patient; et - une étape (408; 418) de rapprochement sous l'identité fédératrice du patient de l'identité validée. 17. Procédé selon la revendication 16, caractérisé en ce qu'il comprend une étape de modification d'une identité fédératrice et de notification d'au moins un serveur de la pluralité de réseaux utilisant l'identité fédératrice d'une modification de celle-ci. 18. Procédé selon la revendication 16 ou 17, caractérisé en ce que l'étape de recherche comprend une étape de sélection d'une identité de la pluralité de réseaux. 19. Procédé selon la revendication 16, 17 ou 18, caractérisé en ce que les identités de la pluralité de réseaux sont gérées par des serveurs informatiques, et en ce que l'étape de recherche comprend une étape de notification en recherche d'identités de chacun de ces serveur en fonction d'informations relatives au patient mémorisées dans l'identité fédératrice. 20. Procédé selon la revendication 19, caractérisé en ce que l'étape de validation comprend une étape de comparaison d'identités délivrées par les serveurs informatiques en réponse à la notification en recherche de ceux-ci. 21. Serveur (300) de rapprochement des identités de patients d'une pluralité de réseaux informatiques (12A, 12B; 12C, 12D) de production et de mémorisation d'informations médicales relatives à ces patients, caractérisé en ce qu'il comprend: - des moyens (302) de création d'une identité fédératrice pour un patient identifié dans la pluralité de réseaux; - des moyens (50, 302) de recherche, sur la pluralité de réseaux, d'identités potentiellement associées à ce même patient; - des moyens (50, 302) de validation d'une identité trouvée comme étant effectivement associée à ce même patient; et - des moyens (302) de rapprochement sous l'identité fédératrice du patient de l'identité validée. 22. Serveur selon la revendication 21, caractérisé en ce que le serveur de rapprochement est également un serveur d'identité conforme à l'une quelconque des revendications 10 et 11 pour au moins un réseau de la pluralité de réseaux.