FR 2841073 A1 20031219 FR 0207499 A 20020618 La presente invention concerne un systeme de gestion dtinformations, et notamment d'informations medicales, chaque information concernant une premiere entite, le systeme comprenant: - au moins une base de donnees pour le stockage: desdites informations; À d'un identifiant de la premiere entite concernee par chaque in formation, chaque information etant associee a l'identifiant de S la premiere entite concernee; et - au moins un posse d/interrogation comprenant des moyens d'acces a la ou cheque base de donnees pour la consultation desdites informations. Dans de nombreux domaines, il est necessaire de pouvoir assurer le stockage confidential et la consultation autorisee et controlee d'informations validees concernant une personne. Ces informations peuvent etre par exemple des informations medica les concernant un patient. Ces informations medicales vent engendrees par un ou plusieurs praticiens medicaux soumis a des obligations deontologi ques. En particulier, ces obligations deontologiques imposent aux praticiens le respect du secret professionnel, de sorte qu'il est interdit aux praticiens de rendre accessibles ces informations sans l'autorisation du patient concerne et le patient doit pouvoir acceder aux informations le concernant. Les obligations deontologiques des praticiens rendent difficiles ['exploitation des donnees concernant le patient en cas d'urgence. En parti culier, si le patient est victime d'un malaise sur le vole publique, les services d'urgence prenant en charge le patient ne peuvent acceder directement aux informations medicales concernant le patient, dans la mesure ou ce service d'urgence n'a pas ete prealablement autorise a acceder a ces informations et que le patient n'est pas necessairement facilement identifiable notamment s' il est i n co nscient. L'invention a pour but un systeme de gestion dtinformations permet tant de rendre accessible des informations utiles, meme lorsque la personne concernee par ses informations n'est pas consciente, tout en garantissant le respect des obligations deontologiques. A cet effet, I'invention a pour objet un systeme de gestion d'informa tions du type precise, caracterise en ce qu'il comporte: - des moyens pour definir des informations d'alerte parmi lesdites in formations; - des moyens pour associer un code d'acces d'urgence, aux informa tions d'alerte concernant une meme premiere entite, le code d'acces d'urgence etant different de l'identifiant de la premiere entite; et en ce que lesdits moyens d'acces comportent des moyens d'entree du code d'acces d'urgence et des moyens pour, lors de ['entree du code d'acces d'urgence associe a l'identifiant d'une premiere entite, mettre a disposition les informations d'alerte concernant la premiere entite associee au code d'acces d'urgence, sans que l'identifiant de la premiere entite ne soit mis a disposition. Suivant des modes particuliers de realisation, le systeme de gestion d'informations comporte l'une ou plusieurs des caracteristiques suivantes: - il comprend: des moyens pour creer au moins un evenement regroupant, de maniere indissociable, dans une meme donnee elementaire: À Ia ou chaque information concernant la premiere entite; et À I'identifiant de la premiere entite; et À des moyens de stockage definitif du contenu du ou de cheque evenement, chacun en tent que donnee elementaire dans la ou cheque base de donnees; - les moyens pour dbfinir des informations d'alerte parmi les informa tions component: des moyens pour fixer, pour chaque information, un indicateur d'alerte representatif de la definition des informations; À des moyens pour integrer dans la donnee elementaire corres pondant a l'evenement contenant ladite information, I'indicateur d'alerte representatif de la definition des informations; et À des moyens pour integrer dans la don nee elementa ire corres pondant a l'evenement contenant ladite information, I'indicateur d'alerte, et lesdits moyens pour mettre a disposition les informations d'alerte compor tent des moyens d'analyse de l'indicateur d'alerte contenu dans chaque evenement contenant l'identifiant de la premiere entite associee au code d'acces d'urgence, et les moyens pour mettre a disposition les informations d'alerte vent adaptes pour mettre a disposition la ou chaque information contenue dans ltevenement, si l'analyse de l'indicateur d'alerte montre que la ou cheque information est une information d'alerte; - le systeme comporte des moyens pour integrer dans chaque don nee elementaire correspondent a un evenement un identifiant d'une se conde entite ayant engendree ladite information; lesdits moyens pour associer un code d'acces d'urgence, aux infor mations d'alerte concernant une meme premiere entite comportant une base de donnees etablissant une correspondence entre chaque code d'acces d'urgence et un identifiant d'une premiere entite; et - le systeme comporte des moyens de generation aleatoire d'un code d'acces d'urgence pour chaque nouvel identifiant d'une premiere entite. L'invention a egalement pour objet un procede de gestions d'informa tions, cheque information concernant une premiere entite dans un systeme comprenant: - au moins une base de donnees pour le stockage: desdites informations; À d'un identifiant de la premiere entite concernee par chaque in formation, chaque information etant associee a l'identifiant de la premiere entite; - au moins un posse d'interrogation comprenant des moyens d'acces a la ou cheque base de donnees pour la consultation desdites informations, et - des moyens pour definir des informations d'alerte parmi lesdites in formations, et dans lequel un code d'acces d'urgence est associe aux informations d'alerte concernant une meme premiere entite, le code d'acces d'urgence etant dif ferent de l'identifiant de la premiere entite, caracterise en ce qutil comprend lientree depuis lesdits moyens d'acces, d'un code d'acces d'urgence, et, lors de ['entree audit code d'acces d'urgence associe a l'identifiant d'une premiere entite, la mise a disposition des informations d'alerte concernant la premiere entite associee au code d'acces d'urgence, sans que l'identifiant de la premiere entite ne soit mis a disposition. L'invention sera mieux comprise a la lecture de la description qui va suivre, donnee uniquement a titre d'exemple et faite en se referent aux des sins, sur lesquels: - la figure 1 est une vue schematique d'un systeme de gestion d'in formations selon ['invention; - la figure 2 est une vue schematique illustrant le format d'une donnee elementaire utilisee par le systeme de gestion d'informations de la figure 1; - la figure 3 est un organigramme de l'algorithme principal mis en ceu vre dans le systeme, et - la figure 4 est un organigramme de l'algorithme de consultation d'urgence du systeme selon ['invention. Le systeme de gestion d'informations 10 selon ['invention est illustre schematiquement sur la figure 1. Celui-ci comporte, d'une part, un ensemble de posses utilisateurs designee par la reference generale 12, chacun relic a un reseau 14 collectif de transmission d'informations tel que le reseau Inter net et, d'autre part, un centre 16 de stockage et de gestion des informations. Le systeme de gestion d'informations 10 est destine, dans ltexemple co ns id ere, a la gestion dt i nform ations med ical es co ncern a nt d es patie nts identifies. Ces informations vent engendrees par des praticiens medicaux tels que des medecins, des radiologues ou des biologistes en charge d'un laboratoire d'analyses. En particulier, le systeme de gestion est adapte pour permettre le stockage definitif d'une information dans le centre 16 de stockage, sans que cette information ne puisse etre ulterieurement modifiee. De plus, il est conserve, associes a cette information, au moins un identifiant du patient concerne, ainsi qutun identifiant du praticien ayant engendre ['information. Le systeme permet de donner acces a une information stockee a par tir de l'identifiant du patient seulement au patient concerne et au praticien ayant engendre ['information, ainsi que, eventuellement, apres accord du patient, a d'autres praticiens. En outre, le systeme permet l'acces a certaines informations stockees concernant un patient par des personnel disposant d'un code d'acces d'urgence. Les informations vent alors mises a disposition en nombre reduit, et sans que l'identifiant du patient concerne par ces informations ne soit mis a disposition. Chaque entite intervenant dans le systeme, qu'il s'agisse d'un patient ou d'un praticien, est equipe ou a acces a un posse d'utilisateur 12. Ainsi, par exemple, un premier posse d'utilisateur 12A equipe le cabinet d'un medecin generaliste et un posse d'utilisateur 12B equipe ie domicile d'un patient. De meme, par exemple, un laboratoire dtimageries medicales est equipe d'un posse d'utilisateur 12C. Chaque posse d'utilisateur 12A, 12B, 12C comporte un micro ordinateur 20 equipe d'un navigateur Internet adapte. II est relic par une in terface adaptee au reseau 14. Cheque posse d'utilisateur comporte des moyens 22 de recueil de donnees d'entree tels qu'un clavier ou un module de conversion de donnees. A partir du clavier, peuvent etre entree notam ment une information medicale, un identifiant d'un patient tel que son nom, ainsi qu'un identifiant du praticien ayant produit ['information. Cheque posse d'utilisateur 12 est adapte pour mettre en ceuvre, de puis des moyens de traitement d'informations 24, des moyens logiciels d'ac ces au centre 16 de stockage et de gestion des informations. Selon ['invention, cheque posse d'utilisateur 12A, 12B, 12C comporte des moyens logiciels pour creer un evenement regroupant de maniere indissociable dans une meme donnee eldmentaire, des informations recueillies concernant un patient, un identifiant du patient et un identifiant du praticien. Ces moyens de creation d'un evenement vent avantageusement telecharges depuis le centre 16 et vent par exemple constitues d'une page au format HTML (Hyper Text Markup Language) formant interface de dialo gue. Certains de ces posses d'utilisateur, comme le posse 12C, component, en plus du micro-ordinateur 20, une interface 30 de connexion du micro ordinateur a une installation 32 d'imagerie medicale ou de recueil d'informa tions medicales apte a produire des images ou informations numeriques sous un format predefini tel que le format DICOM Hprim HL7. Par nature, cette image ou information numerique comporte un identifiant du patient concerne. Le posse d'utilisateur met en couvre en outre un module logiciel 34 propre a analyser ['image numerique produite par ['installation 32 et a ex traire de celle-ci un identifiant du patient concerne. En outre, le systeme comporte des posses d'interrogation 36 relies au centre 16 de stockage et de gestion des informations au travers du reseau 14. Chaque posse d'interrogation 36 est constitue par n'importe quel micro ordinateur 20 equipe d'un navigateur internet adapte. Ces posses d'interrogation n'ont pas a etre identifies initialement par le centre de stoc kage et de gestion des informations 16. Chaque posse d/interrogation 36 comporte des moyens d'entree d'un code d'acces d'urgence, tels qu'un clavier 37, ou un lecteur de carte a puce 38 ainsi qu'un peripherique de mise a disposition d'informations tel qu'un ecran ou une imprimante 39. Le centre de stockage et de gestion des informations 16 comporte un ensemble de serveurs 40 pour la gestion des acces au centre 16. Cet en semble de serveurs 40 comporte notamment un serveur d'authentification 40A adapte, comme connu en soi, pour identifier ltorigine d'une requete adressee au centre serveur. II comporte en outre un ou plusieurs serveurs B propres a la gestion d'echange de fichiers executables et de pages HTML suivant le protocole HTTP entre le centre de stockage et de gestion 16 et les posses d'utilisateurs. En particulier, le ou chaque servour 40B com porte un module logiciel propre a assurer le telechargement dans chaque posse utilisateur demandeur de pages HTML constituent des interfaces utili sateurs permettant l'acces aux informations stockees, ainsi que la sauve garde de nouvelles informations. Cet ensemble de serveurs 40 est relic di rectement au reseau 14 au travers d'une premiere barriere de securite 42 (firewalls). L'ensemble des serveurs de gestion d'acces 40 est relic en outre a un ensemble de serveurs 44 de gestion d'evenements au travers d'une se conde barriere de securite 46 (firewalls). En particulier, I'ensemble de ser veurs 44 est propre a mettre en couvre un module logiciel 44A de transcrip tion des images numeriques re,cues dans des formats differents notamment au format DICOM en un meme format, par exemple le format XML. L'ensemble de serveurs 44 est propre en outre a mettre en ceuvre un module logiciel 44B de gestion du stockage d'evenements dans une unite de stockage 48 et de gestion des acces a ces evenements. Cette unite de stockage 48 est destinee a la memorisation perma nente d'une ou plusieurs bases de donnees dont les donnees elementaires vent constituees par des evenements definis par les posses utilisateurs et comportant notamment les informations a sauvegarder. En outre, une unite supplementaire 49 de stockage est reliee a ['ensemble de serveurs 44. Cette unite de stockage est destinee a la memo risation permanente d'une base de donnees dans laquelle est stocke, pour cheque identifiant d'un patient concerne par des informations, un code d'acces d'urgence associe. Le code d'acces d'urgence est defini aleatoirement par le module de gestion 44B pour chaque nouveau patient gere par le systeme. Le code est different de l'identifiant du patient tel que son nom. Le code d'acces d'urgence est inscrit sur une carte remise au patient. Sur cette carte figure egalement l'adresse IP du centre 16 de stockage et de gestion des informations. En variante, le code d'acces d'urgence est memorise dans une carte a memoire pouvant etre lu dans un lecteur de carte d'un ordinateur. Cette carte porte egalement l'adresse IP du centre 16. Sur la figure 2 est representee schematiquement la structure d'une donnee elementaire stockee dans la base de donnees 48. Celle-ci corres pond a un evenement. Cheque evenement comporte au moins une information proprement cite 52. Cette information est constituee par exemple de donnees numeri ques correspondent au resultat d'une analyse ou d'un texte correspondent a l'avis d'un praticien sur l'etat clinique d'un patient. Une information peut ega S lement etre constituee par un fichier rattache a l'evenement tel qu'un docu ment au format HTML ou un fichier image au format DIBCOM ou une piece jointe dans un format bureautique. En outre, cheque evenement comporte un identifiant 54 d'une pre miere entite. Cet identifiant designe le patient concerne par les informations 52. De meme, I'evenement comporte un identifiant 56 d'une seconde entite. Cet identifiant designe le praticien ayant produit ['information. Avantageusement, chaque evenement comporte une liste 58 des identifiants d'entites supplementaires pouvant avoir acces aux informations. L'evenement comporte egalement avantageusement mais non obliga toirement d'autres informations a remplir par l'utilisateur telles que: - un titre; - une date de creation eVou de complements de l'evenement; et - une liste de mots cles. En outre, cheque evenement comporte un indicateur d'alerte consti tue d'un indicateur bouleen indiquant dans son premier etat (valide) que les informations contenues dans l'evenement constituent des informations d'alerte pouvant etre communiquees en cas d'urgence, et dans son deuxieme etat (non valide), que les informations contenues dans l'evenement ne doivent pas etre communiquees en cas d'urgence. Pour l'ajout d'une information dans le centre de stockage, le comple ment d'une information pre-existante par une information supplementaire, ia modification des droits d'acces a une information, la modification de l'indicateur d'alerte d'une information ou la consultation d'une information, I'utilisateur se connecte depuis un posse d'utilisateur 12 au centre de stoc kage 16. L'algorithme de la figure 3 est alors mis en ceuvre. Le posse d'utilisateur 12 peut etre constitue, pour les operations les plus simplex, seulement d'un micro-ordinateur relic au reseau Internet a I'aide d'un navigateur de tout type adapte. Apres connexion du posse d'utiii sateur, a l'etape 100, I'ensemble de serveurs 40 du centre de stockage 16 retourne une interface de dialogue au format HTML au posse d'utilisateur 12, a l'etape 102. A l'etape 104, le centre 16 procede au travers de ['interface de dialogue mise en ceuvre par le posse d'utilisateur a une authentification de l'utilisateur. En fonction de l'identifiant entre par l'utilisateur, des controles des actions autorisees a celui-ci vent effectues, a l'etape 106, et un controle des droits d'acces de l'utilisateur est realise, a l'etape 108. L'utilisateur est alors libre de proceder a plusieurs operations en fonc tion des actions qui lui vent autorisees. II procede, a partir de ['interface mise a sa disposition, a l'etape 110, au choix d'une operation a realiser. Celle-ci peut etre ['entree d'une information nouvelle dans le centre de stockage 16. La branche 110A de l'organigramme est alors mise en ceuvre. II peut s'agir egalement de l'ajout d'une information supplementaire pour completer une information deja presente dans le centre de stockage 16. La branche 1 1 OB de l'organigramme est alors mise en ceuvre. L'utilisateur praticien peut egalement modifier les droits d'acces aux informations stockees en habilitant un nouveau praticien a acceder aux in formations concernant un patient. La branche 110C de l'organigramme est alors mise en ceuvre. Lorsque le praticien souhaite modifier l'indicateur d'alerte diun eve nement, la branche 110D de l'algorithme est mise en ceuvre. L'utilisateur peut egalement prendre seulement connaissance dtinfor mations stockees dans le centre de stockage par mise en ceuvre de la bran che 11OE de l'organigramme. Lorsque un praticien souhaite entrer une nouvelle information dans le centre 16, I'algorithme differe suivant que ['information medicale que sou haite entrer le praticien peut etre associee automatiquement a un patient constituent une premiere entite, ou que la liaison au patient doit etre realisee manuellement. Ce choix est effectue a l'etape 111. Si ['information ne contient pas initialement l'identifiant du patient concerne, I'information est entree par le praticien, par exemple au clavier, a l'etape 1 12. Une identification du patient concerne est saisie, a l'etape 1 14, notamment par selection d'un identifiant du patient parmi une liste d'identi fiants de patients ou par frappe au clavier. En revanche, et dans le cas d'un posse d'utilisateur tel que le posse 12C, la reconnaissance de l'identifiant du patient concerne peut se faire au tomatiquement lors de l'entrbe de ['information. Ainsi, I'information contenant l'identifiant du patient concerne est entrbe, a ltetape 122, par exemple au travers de ['interface 30. Cette information est par exemple constitube d'une image mbdicale au format DiCOM. A l'btape 124, le module logiciel 36 pro cede a une analyse de ['image et a une reconnaissance de l'identifiant du patient dans ['image transmise. A l'btape 130, le praticien dbfinit la liste des identifiants des entitbs supplementaires autorisbes a acceder aux informations contenues dans l'bvenement. Cette etape consiste a definir la liste 58 des identifiants des praticiens autorisbs a accdder. A l'btape 131, le praticien dbfinit l'indicateur d'alerte en prbcisant si ['information contenue dans l'evenement peut ou non etre rendue accessible en cas diurgence suivant une procddure decrite dans la suite de la descrip tion. Si le praticien souhaite rendre cette information accessible en cas d'urgence, il s'assure que ['information en elle-meme ne contient pas de donnees permettant d'identifier le patient comme son nom. A l'btape 132, le praticien valide, par saisie d'un code de signature, I'ensemble des blements constituent l'bvenement, a savoir ['information mb dicale proprement cite, I'identifiant du patient concerne, son propre identi fiant,la liste des identifiants des entitbs supplementaires autorisbes a acce der, et l'indicateur d'alerte. A ['issue de cette etape, les eldments constituent l'bvenement ne peuvent plus etre modifies et l'bvenement peut seulement etre complbtb. A l'btape 134, le posse d'utilisateur 12 assure la crbation d'une donnbe elementaire reprenant les diffbrents bibments de l'evenement. Cette donnbe elementaire est cryptee par tout prochdb adapte et est adressee par l'inter face de dialogue au centre 16 de stockage et de gestion des informations. A sa reception, la donnee elementaire est traitee par les servours de gestion d'evenements 44, a l'etape 136. Si la donnee elementaire contient des images numeriques dans des formats differents du format XML, ces images vent automatiquement converties au format XML, a l'etape 138, et la donnee elementaire est completee par des donnees images au format XML en plus des donnees images dans un autre format. La donnee elementaire ainsi retraitee est sauvegardee definitivement dans ['unite de stockage 48, a l'etape 140. Lorsque l'utilisateur souhaite completer un evenement en ajoutant une information supplementaire, les etapes de la branche 110B vent mises en ceuvre apres l'etape 1 10. A l'etape 150, I'evenement a completer est selectionne. La donnee elementaire correspondent a l'evenement selectionne est transmise par le centre 16 au posse utilisateur, a l'etape 152. La donnee elementaire n'est transmise que si l'identifiant de l'utilisateur est compris dans ltevenement en cause, soit qu'il s'agisse du patient concerne, du prati cien a ltorigine de ['information ou d'un praticien supplementaire dont l'identi fiant figure dans la liste 58. L'information supplementaire est entree a l'etape 154, soit manuelle ment depuis le clavier, soit par reprise d'un fichier deja existent. Dans ce dernier cas, I'information supplementaire constitue un nouveau fichier atta che. A l'etape 156, I'utilisateur valide l'ajout de ['information par entree d'un code de signature. L'information supplementaire est ajoutee a l'etape 158 pour former u ne nouvelle don nee elementaire constituent l'evenement mod ifie. En outre, la date, et l'identifiant de l'utilisateur ayant ajoute ['information, ainsi qu'un lien avec ['information vent ajoutes dans la donnee elementaire pour assurer un suivi des modifications. La nouvelle donnee elementaire ainsi constituee est ensuite traitee conformement aux etapes 136 et suivantes. Lorsque l'utilisateur souhaite modifier un droit d'acces, celui-ci peut seulement ajouter de nouveaux identifiants d'utilisateur habilites a acceder a une information donnee. A cet effet, I'evenement dont les acces vent a com pleter est selectionne a l'etape 200. La donnee elementaire correspondent a ltevenement selectionne est alors-transmise au posse utilisateur a l'etape 202. La donnee elementaire n'est transmise que si l'identifiant de l'utilisateur est compris dans l'evenement en cause, soit qu'il s'agisse du patient concerne, du praticien a ltorigine de ['information ou d'un praticien supple mentaire dont l'identifiant figure dans la liste 58. A l'etape 204,1'utilisateur selectionne ou entre au clavier un ou plu sieurs identifiants supplementaires d'utilisateurs habilites a acceder a l'in formation puis il valide, a l'etape 206, les nouveaux identifi-ants. Les identi fiants supplementaires vent ajoutes dans la donnee elementaire constituent l'evenement a ltetape 208. En outre, la date, et l'identifiant de l'utilisateur ayant ajoute les nouveaux identifiants, ainsi qu'un lien avec les nouveaux identifiants vent ajoutes dans la donnee elementaire pour assurer un suivi des modifications. Les etapes 136 et suivantes vent alors a nouveau mises en oeuvre. Lorsque l'utilisateur, et notamment le praticien souhaite modifier l'indicateur d'alerte associe a une information, afin de rendre accessible cette information en cas d'urgence, ou au contraire ne pas mettre a disposi tion cette information, la branche 11 OD de l'algorithme est mise en oeuvre. A l'etape 210 I'evenement dont l'indicateur d'alerte doit etre modifie est selectionne. La donnee elementaire correspondent a l'evenement selec tionne est transmise au posse utilisateur 12 a l'etape 212, sous reserve que l'identifiant de l'utilisateur soit compris dans l'evenement en cause parce qu'il stagit du patient concerne, du praticien a l'origine de ['information ou d'un praticien supplementaire dont l'identificateur figure dans la liste 58. A l'etape 214, I'utilisateur change l'etat de l'indicateur d'alerte, par exemple par validation a l'ecran d'une zone predefinie. Si le praticien sou haite rendre cette information accessible en cas d'urgence, il s'assure que ['information en elle-meme ne contient pas de donnees permettant d'identifier le patient comme son nom. L'evenement modifie est alors valide ensuite a l'etape 216. La nouvelle valeur de l'indicateur d'alerte est ajoutee dans la donnee elementaire constituent l'evenement a l'etape 218. En outre, la date et l'identifiant de l'utilisateur ayant modifie l' indicateur d'alerte vent ajoutes dans la don nee elementaire pour assurer u n suivi des modifications. Les etapes 136 et suivantes vent alors a nouveau mises en ceuvre. S Pour la consultation des informations stockees dans le centre 16, et depuis n'importe quel posse d'utilisateur 12, les etapes de la branche 110E vent mises en couvre. A l'etape 250, u ne requete est formu lee par l'utilisateur depu is le posse d'utilisateur. Celle-ci est prise en compte par les serveurs de gestion des evenements 44, a l'etape 252. En fonction des droits d'acces contenus dans l'evenement en cause dans la requete, et en fonction des droits de l'uti lisateur, le contenu de la donnee elementaire est transmis du centre de stockage 16 au posse utilisateur 12, a ltetape 254. En particulier, la donnee elementaire ntest transmise que si l'identi fiant de l'utilisateur est compris dans l'evenement en cause dans la requete, soit qu'il s'agisse du patient concerne, du praticien a l'origine de ['information ou d'un praticien supplementaire dont l'identifiant figure dans la liste 58. L'information est alors mise a disposition de l'utilisateur a l'etape 256, par exemple par affichage, ou bien par sauvegarde du contenu de la donnee elementaire sur le disque dur du posse utilisateur. A l'etape 258, un journal des acces est mis a jour dans le centre 16 pour enregistrer l'identifiant de l'utilisateur, la nature de ['information mise a disposition, la date d'acces fournie par le systeme et toute autre information utile. Afin de permettre que des informations necessaires en cas d'urgence puissent etre rendues accessibles aux services de secours, que ceux-ci soient des praticiens de sante ou non, le patient, dont les informations vent stockees dans le systeme, porte sur lui la carte sur laquelle figure l'adresse IP du centre 16 de gestion et de stockage d'informations sur le reseau 14, ainsi que le code d'acces d'urgence associe au patient. Pour permettre l'acces aux informations d'alerte, I'algorithme de ia figure 4 est mise en ceuvre. Lorsque le patient necessite des veins medicaux, alors que celui-ci niest pas chez un praticien habilite a acceder aux informations, le patient peut fournir a n'importe quel interlocuteur la carte qu'il porte sur lui pour permettre a son interlocuteur d'acceder a certaines informations d'alerte que le patient a prealablement selectionnees en pla,cant ou faisant placer les in dicateurs d'alerte associes a ces informations dans un etat validepredeter mine. Au cas ou le patient est inanime, les services de secours peuvent se saisir de la carte portee par le patient et effectuer eux-memes le recueil des informations d'urgence. A cet effet, a l'etape 402, le service de secours se connecte au centre 16 de stockage et de gestion des informations grace a l'adresse IP mention nee sur la carte portee par le patient. Cette connexion peut etre effectuee depuis n'importe quel ordinateur connecte au reseau 14 et disposant d'un navigateur internet adapte. Cet ordinateur forme alors un posse d'interrogation 36. Apres connexion, le centre 16 assure a l'etape 404 le chargement dans le posse d/interrogation 36 d'une interface d'utilisateur. A l'etape 406, le service de secours est invite a entrer le code d'acces diurgence propre au patient. Ce code d'acces d'urgence etant totalement independent de l'identifiant du patient, I'identifiant du patient n'est pas necessaire pour ['entree du code d'alerte. Le module logiciel 44B de gestion des acces aux evenements stockes determine a ltetape 408 si le code d'acces d'urgence est ou non associe a un identifiant connu, par interrogation de la base de donnees hebergee dans ['unite de stockage 49. Si le code d'acces d'alerte est inconnu, I'etape 406 est a nouveau mise en ceuvre. En revanche, si le code d'acces d'alerte est connu, le centre 16 de stockage et de gestion des informations determine a l'etape 410 I'identifiant du patient concerne. A l'etape 412, le module logiciel 44B de gestion des evenements re cherche, parmi les evenements stockes, les evenements contenant I'identifiant de la premiere entite. Parmi ces evenements trouves, il analyse a l'etape 414 I'indicateur d'alerte associe a chaque evenement. II selectionne parmi les evenements ceux dont les indicateurs d'alerte vent dans un etat valide indiquant que les informations contenues dans l'evenement peuvent etre communiquees en cas d'urgence. A l'etape 416, le centre 16 assure la transmission, sans cryptage des informations contenues dans chacun des seuls evenements de la base 48 dont l'indicateur d'alerte est valide, et dont l'identifiant de ia premiere entite est l'identifiant associe au code d'acces d'alerte dans la base 49. Les informations transmises vent communiquees sans que l'identifiant de la premiere entite ne soit transmis. A l'etape 418, les informations transmises vent mises a disposition du service d'urgence, par exemple par affichage de ces informations sur l'ecran du posse d'interrogation 36. A l'etape 420, le journal des acces est mis a jour dans le centre 16 par enregistrement de la nature de ['information mise a disposition, la date d'acces fournie par le systeme ou toute autre information utile. On con,coit qu'avec un tel systeme de gestion d'informations, des in formations utiles au traitement du patient en cas d'urgence peuvent etre mi ses a disposition a tout service de secours, sans que l'identite du patient ne soit devoilee, et en permettant que seuies les informations necessaires pre alablement selectionnees avec ['accord du patient soit transmise au service de secours lors de son intervention. En outre, I'acces a ces informations est tres simple et est rendue pos sible meme si le service de secours n'est pas normalement habilite a inter venir sur le systeme et meme si le patient est inconscient. REVENDICATIONS 1.- Systeme de gestion dtinformations, chaque information concernant une premiere entite, le systeme comprenant: - au moins une base de donnees (48) pour le stockage: À desdites informations (52); À d'un identifiant de la premiere entite concernee par cheque in formation, chaque information etant associee a l'identifiant de la premiere entite concernee; et - au moins un posse d'interrogation (36) comprenant des moyens d'acces a la ou chaque base de donnees (48) pour la consultation desdites informations, caracterise en ce qutil comporte: - des moyens pour definir des informations d'alerte parmi lesdites in formations; - des moyens (49) pour associer un code d'acces d'urgence, aux in formations d'alerte concernant une meme premiere entite, le code d'acces d'urgence etant different de l'identifiant de la premiere entite; et en ce que lesdits moyens d'acces comportent des moyens d'entree du code d'acces d'urgence et des moyens pour, lors de ['entree du code d'acces d'urgence associe a l'identifiant d'une premiere entite, mettre a disposition les informations d'alerte concernant la premiere entite associee au code d'acces d'urgence, sans que l'identifiant de la premiere entite ne soit mis a disposition. 2. Systeme de gestion d'informations selon la revendication 1, carac terise en ce qu'il comprend: - des moyens (12) pour creer au moins un evenement regroupant, de maniere indissociable, dans une meme donnee elementaire (50): Ia ou chaque information (52) concernant la premiere entite; et I'identifiant (54) de la premiere entite; et - des moyens (12, 44, 48) de stockage definitif du contenu du ou de cheque evenement, chacun en tent que donnee elementaire (50) dans la ou cheque base de donnees (48). 3. Systeme de gestion d'informations, caracterise en ce que les moyens (12) pour definir des informations d'alerte parmi les informations component: - des moyens pour fixer, pour chaque information, un indicateur d'alerte (59) representatif de la definition des informations; - des moyens pour integrer dans la donnee elementaire corres pondant a l'evenement contenant ladite information, I'indicateur d'alerte (59) representatif de la definition des informations; et - des moyens pour integrer dans la donnee elementaire corres pondant a l'evenement contenant ladite information, I'indicateur d'alerte (59), et en ce que lesdits moyens pour mettre a disposition les informations d'alerte comportent des moyens d'analyse de l'indicateur d'alerte (59) contenu dans chaque evenement contenant l'identifiant de la premiere entite associee au code d'acces d'urgence, et les moyens pour mettre a disposi tion les informations d'alerte vent adaptes pour mettre a disposition la ou chaque information contenue dans l'evenement, si l'analyse de l'indicateur d'alerte montre que la ou cheque information est une information d'alerte. 4. Systeme de gestion d'informations selon l'une quelconque des re vendications precedentes, caracterise en ce qu'il comporte des moyens pour integrer dans chaque donnee elementaire correspondent a un evenement un identifiant d'une seconde entite ayant engendree ladite information. 5. Systeme de gestion d'informations selon l'une quelconque des re vendications, caracterise en ce que lesdits moyens pour associer un code d'acces diurgence, aux informations d'alerte concernant une meme premiere entite comportant une 1aase de donnees (49) etablissant une corres pondance entre chaque code d'acces d'urgence et un identifiant diune pre miere entite. 6. Systbme de gestion d'informations selon l'une quelconque des re vendications, caracterise en qu'il comporte des moyens de generation alea toire diun code d'acces d'urgence pour cheque nouvel identifiant d'une pre miere entite. 7. Procede de gestion d'informations, chaque information concernant une premiere entite dans un systeme comprenant: - au moins une base de donnees (48) pour le stockage: desdites informations (52); À d'un identifiant de la premiere entite concernee par chaque in formation, chaque information etant associee a l'identifiant de la premiere S entite; - au moins un posse d'interrogation (36) comprenant des moyens d'acces a la ou cheque base de donnees (48) pour la consultation desdites informations, et - des moyens pour definir des informations d'alerte parmi lesdites in formations, et dans loquel un code d'acces d'urgence est associe aux informations d'alerte concernant une meme premiere entite, le code d'acces d'urgence etant dif ferent de l'identifiant de la premiere entite, caracterise en ce qutil comprend ['entree depuis lesdits moyens d'acces, d'un code d'acces d'urgence, et, lors de ['entree audit code d'acces d'urgence associe a l'identifiant d'une premiere entite, la mise a disposition des informations d'alerte concernant la premiere entite associee au code d'acces d'urgence, sans que l'identifiant de la premiere entite ne soit mis a