Brevet FR2839170A1 — publié le 20031031

moyens de communication. La présente invention concerne un système de gestion d'informations, et notamment d'informations médicales, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le système comprenant: - au moins une base de données pour le stockage desUites informa tions; et - au moins un poste utilisateur comprenant des moyens de recueil d'au moins une information concernant la première entité. Dans de nombreux domaines, il est nécessaire de pouvoir assurer le stockage confidentiel et la consultation autorisée et contrôlée d'informations validées concernant une personne. Ces informations peuvent être par exemple des informations médica les concernant un patient. Ces informations médicales sont engendrées par un ou plusieurs praticiens médicaux soumis à des obligations déontologi ques. En pa rticu l ier, ces obligations déontologiques imposent aux pratici ens le respect du secret professionnel, de sorte qu'il est interdit aux praticiens de rendre accessibles ces informations sans l'autorisation du patient concerné et le patient doit pouvoir accéder aux informations le concernant. Les systèmes de gestion d'informations connus actuellement mettent en _uvre des bases de données relationnelles dans lesquelles sont mémo risés, d'une part, I'ensemble des informations devant être gérées par le sys tème, et, d'autre part, des identifiants du patient concerné et/ou du praticien ayant engendré ces informations. Dans les bases de données relationnelles, la base de données est organisée en fon ction d es relations qu i existent e ntre l es d onnées élémen taires. Ainsi, une information concernant un patient, I'identité de ce patient ou l'identité du praticien ayant engendré cette information est considérce comme une donnée élémentaire et des liens traduisant les relations existan tes entre les données élémentaires sont mémorisés dans la base. Ce type de bases de données est commode puisqu'il permet de modi fier les liens existant entre les donnses élémentaires, ce qui permet d'appli quer de nouveaux traitements à des éléments déjà existants. Cela réduit la redondance des données élémentaires contenues dans la base. Toutefois, la gestion de la confidentialité nécessaire à la limitation de la consultation des informations, imposée notamment par la déontologie des personnes engendrant les informations est difficile à assurer, du fait de la multitude de liens qui peuvent être créés dans une telle base de données. Par ailleurs, dans le domaine médical, les praticiens sont souvent amenés à appliquer un protocoie médical. Ce protocole spécifie une sé quence d'opérations à effectuer en fonction des résultats obtenus lors d'opé rations antérieures. Les opérations ultérieures à réaliser sont définies en fonction de critères propres au protocole' ces critères portant sur les résul tats des opérations antérieures. Les protocoles applicables sont très nombreux. Ceux-ci sont accessi bles aux praticiens dans des ouvrages de référence, ou dans des bases de données informatiques. Du fait de leur grande variété, il est difficile aux praticiens de conna' tre de manière exhaustive chaque protocole et l'accès protocole dans un ouvrage de référence ou une base de données est consommateur de temps. L'invention a pour but de proposer un dispositif permettant aux prati ciens la mise en _uvre aisée et fiable de protocoles complexes, et notam ment de protocoles médicaux. A cet effet, I'invention a pour objet un système de gestion d'informa tions du type précité, caractérisé en ce qu'il comporte: - des moyens pour créer au moins un événement regroupant, de ma nière indissociable, dans une même donnée élémentaire: À Ia ou chaque information concernant la première entité; À un identifiant de la première entité; et À un identifiant de la seconde entité, - des moyens de stockage d'au moins un protocole, lequel protocole spécifie une séquence d'opérations successives à réaliser, dont les opéra tions ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction de critères propres audit protocole; - des moyens d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres à un pro tocole; - des moyens de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ulté rieure à réaliser en fonction du résultat de l'analyse de la ou chaque informa tion contenue dans au moins un événement antérieur en fonction des critè res propres audit protocole; et - des moyens de stockage définitif du contenu du ou de chaque évé nement créé automatiquement, chacun en tant que donnée élémentaire dans la ou chaque base de données. Suivant des modes particuliers de réalisation, le système de gestion d'informations comporte l'une ou plusieurs des caractéristiques suivantes: - lesdits moyens de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser sont adaptés pour la création d'un événement incomplet, et le système comporte des moyens pour compléter le ou chaque événe ment incomplet, par au moins une seconde entité depuis un poste utilisa teur, par ajout d'au moins une information dans le ou chaque événement avant son stockage définitif; - il comporte des moyens d'alerte d'au moins une seconde entité pour compléter un événement incomplet; - il comporte des moyens pour valider le ou chaque événement, par la ou chaque seconde entité, avant son stockage définitif; - lesdits moyens d'analyse sont adaptés pour l'analyse de la ou cha que information contenue dans au moins deux événements antérieurs; - il comporte des moyens de recherche automatique parmi les don nées élémentaires stockées dans la ou chaque base de données, des don nées élémentaires contenant des informations devant être analysées par les moyens d'analyse en fonction des critères propres audit protocole; - il comporte des moyens d'archivage des événements utilisés lors de la mise en _uvre dudit protocole; et - lesdits moyens de création automatique d'au moins un événement comportent des moyens d'ajout automatique dans ledit événement de l'iden tifiant de la première entité concernée par la ou chaque information. L'invention a également pour objet un procédé de gestion d'informa tions, chaque information concernant une première entité et ayant été en gendrée par une seconde entité, le système comprenant au moins une base de données pour le stockage desdites informations et au moins un poste utilisateur comprenant des moyens de recueil d'au moins une information concernant la première entité, le procédé comprenant une étape de recueil, depuis un poste utilisateur d'au moins une information concernant la première entité; caractérisé en ce qu'il comporte: - une étape de création d'au moins un événement regroupant, de ma nière indissociable, dans une même donnée élémentaire: À Ia ou chaque information concernant la première entité; À un identifiant de la première entité; et un identifiant de la seconde entité, - une étape d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction de critères propres audit proto cole, lequel protocole spécifie une séquence d'opérations successives à ré aliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction des critères propres audit pro tocole; - une étape de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ulté rieure à réaliser en fonction du résultat de l'analyse de la ou chaque infor mation contenue dans au moins un événement antérieur en fonction des critères propres audit protocole; et - une étape de stockage définitif du contenu du ou de chaque événe ment créé automatiquement, chacun en tant que donnée élémentaire dans la ou chaque base de données. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux des sins, sur lesquels: - la figure 1 est une vue schématique d'un système de gestion d'in s formations selon l'invention; - la figure 2 est une vue schématique illustrant le format d'une donnée élémentaire utiilsée par le système de gestion d'informations de la figure 1; - la figure 3 est un organigramme de l'algorithme principal mis en _u vre dans le système selon l'invention; - la figure 4 est une vue schématique d'une variante de réalisation du système de gestion d'informations selon l'invention; et la figure 5 est un organigramme de l'algorithme de gestion par pro tocole mis en _uvre dans le système selon l'invention. Le système de gestion d'informations 10 selon l'invention est illustré schématiquement sur la figure 1. Celui-ci comporte, d'une part, un ensemble de postes utilisateurs désignés par la référence générale 12, chacun relié à un réseau 14 collectif de transmission d'informations tel que le réseau Inter net et, d'autre part, un centre 16 de stockage et de gestion des informations. Le système de gestion d'informations 10 est destiné, dans l'exemple considéré, à la gestion d'informations médicales concernant des patients identifiés. Ces informations sont engendrées par des praticiens médicaux tels que des médecins, des radiologues ou des biologistes en charge d'un laboratoire d'analyses. En particulier, le système de gestion est adapté pour permettre le stockage définitif d'une information dans le centre 16 de stockage, sans que cette information ne puisse être ultérieurement modifiée. De plus, il est conseNé, associés à cette information, au moins un identifiant du patient concerné, ainsi qu'un identifiant du praticien ayant engendré l'information. Le système permet de donner accès à une information stockée seu lement au patient concerné et au praticien ayant engendré l'information, ain si que, éventuellement, après accord du patient, à d'autres praticiens. Chaque entité inteNenant dans le système, qu'il s'agisse d'un patient ou d'un praticien, est équipé ou a accès à un poste d'utilisateur 12. Ainsi, par exemple, un premier poste d'utilisateur 12A équipe le cabinet d'un médecin généraliste et un poste d'utilisateur 12B équipe le domicile d'un patient. De même, par exemple, un laboratoire d'imageries médicales est équipé d'un poste d'utilisateur 12C. Chaque poste d'utilisateur 12A, 12B, 12C comporte un micro ordinateur 20 équipé d'un navigateur Internet adapté. ll est relié par une in terface adaptée au réseau 14. Chaque poste d'utilisateur comporte des moyens 22 de recueil de données d'entrée tels qu'un clavier ou un module de conversion de données. A partir du clavier, peuvent être entrés notam ment une information médicale, un identifiant d'un patient tel que son nom, ainsi qu'un identifiant du praticien ayant produit l'information. Chaque poste d'utilisateur 12 est adapté pour mettre en _uvre, de puis des moyens de traitement d'informations 24, des moyens logiciels d'ac cès au centre 16 de stockage et de gestion des informations. Selon l'invention, chaque poste d'utilisateur 12 comporte des moyens logiciels pour créer un événement regroupant de manière indissociable dans une même donnée élémentaire, des informations recueillies concernant un patient, un identifiant du patient et un identifiant du praticien. Ces moyens de création d'un événement sont avantageusement téléchargés depuis le cen tre 16 et sont par exemple constitués d'une page au format HTML (Hyper Text Markup Language) formant interface de dialogue. Certains de ces postes d'utilisateur, comme le poste 12C, comportent, en plus du micro-ordinateur 20, une interface 30 de connexion du micro ordinateur à une installation 32 d'imagerie médicale ou de recueil d'informa tions médicales apte à produire des images ou informations numériques sous un format prédéfini tel que le format DICOM Hprim HL7. Par nature, cette image ou information numérique comporte un identifiant du patient concerné. Le poste d'utilisateur met en _uvre en outre un module logiciel 34 propre à analyser l'image numérique produite par l'installation 32 et à ex traire de celle-ci un identifiant du patient concerné. Le centre de stockage et de gestion des informations 16 comporte un ensemble de serveurs 40 pour la gestion des accès au centre 16. Cet en semble de serveurs 40 comporte notamment un serveur d'authentification A adapté, comme connu en soi, pour identifier l'origine d'une requête adressée au centre serveur. ll comporte en outre un ou plusieurs serveurs B propres à la gestion d'échange de fichiers exécutables et de pages HTML suivant le protocole HTTP entre le centre de stockage et de gestion 16 et les postes d'utilisateurs. En particulier, le ou chaque serveur 40B com porte un module logiciel propre à assurer le téléchargement dans chaque poste utilisateur demandeur de pages HTML constituant des interfaces utili sateurs permettant l'accès aux informations stockées, ainsi que la sauve garde de nouvelles informations. Cet ensemble de serveurs 40 est relié di rectement au réseau 14 au travers d'une première barrière de sécurité 42 (firowalls). L'ensemble des serveurs de gestion d'accès 40 est relié en outre à un ensemble de serveurs 44 de gestion d'évènements au travers d'une se conde barrière de sécurité 46 (firewalls). En particulier, l'ensemble de ser veurs 44 est propre à mettre en _uvre un module logiciel 44A de transcrip tion des images numériques reçues dans des formats différents notamment au format DICOM en un même format, par exemple le format XML. L'ensemble de serveurs 44 est propre en outre à mettre en _uvre un module logiciel 44B de gestion du stockage d'évènements dans une unité de stockage 48 et de gestion des accès à ces événements. Cette unité de stockage 48 est destinée à la mémorisation perma nente d'une ou plusieurs bases de donnces dont les données élémentaires sont constituées par des évènements définis par les postes utilisateurs et comportant notamment les informations à sauvegarder. Sur la figure 2 est représentée schématiquement la structure d'une donnée élémentaire stockée dans la base de données 48. Celle-ci corres pond à un événement. Chaque événement comporte au moins une information proprement dite 52. Cette information est constituée par exemple de données numéri ques correspondant au résultat d'une analyse ou d'un texte correspondant à l'avis d'un praticien sur l'état clinique d'un patient. Une information peut éga lement être constituée par un fichier rattaché à l'événement tel qu'un docu ment au format HTML ou un fichier image au format DIBCOM ou une pièce jointe dans un format bureautique. En outre, chaque événement comporte un identifiant 54 d'une pre mière entité. Cet identifiant désigne le patient concerné par les informations s 52. De même, I'événement comporte un identifiant 56 d'une seconde entité. Cet identifiant désigne le praticien ayant produit l'information. Avantageusement, chaque événement comporte une liste 58 des identifiants d'entités supplémentaires pouvant avoir accès aux informations. L'évènement comporte également avantageusement mais non obliga toirement d'autres informations à remplir par l'utilisateur telles que: - un titre; - une date de création eVou de compléments de l'événement; et - une liste de mots clés. Pour l'ajout d'une information dans le centre de stockage, le complé ment d'une information pré-existante par une information supplémentaire, la modification des droits d'accès à une information ou la consultation d'une information, I'utilisateur se connecte depuis un poste d'utilisateur 12 au cen tre de stockage 16. L'algorithme de la figure 3 est alors mis en _uvre. Le poste d'utilisateur peut être constitué, pour les opérations les plus simples, seulement d'un micro-ordinateur relié au réseau Internet à l'aide d'un navigateur de tout type adapté. Après connexion du poste d'utilisateur, à l'étape 100, I'ensemble de serveurs 40 du centre de stockage 16 retourne une interface de dialogue au format HTML au poste d'utilisateur 12, à l'étape 102. A l'étape 104, le centre 16 procède au travers de l'interface de dialogue mise en _uvre par le poste d'utilisateur à une authentification de l'utilisateur. En fonction de l'identifiant entré par l'utilisateur, des contrôles des actions autorisées à celui-ci sont effectués, à l'étape 106, et un contrôle des droits d'accès de l'utilisateur est réalisé, à l'étape 108. L'utilisateur est alors libre de procéder à plusieurs opérations en fonc tion des actions qui lui sont autorisées. Il procède, à partir de l'interface mise à sa disposition, à l'étape 110, au choix d'une opération à réaliser. Celle-ci peut être l'entrée d'une information nouvelle dans le centre de stockage 16. La branche 11OA de l'organigramme est alors mise en _uvre. Il peut s'agir également de l'ajout d'une information supplémentaire pour compléter une information déjà présente dans le centre de stockage 16. La branche 11OB de l'organigramme est alors mise en _uvre. L'utilisateur praticien peut également modifier les droits d'accès aux informations stockées en habilitant un nouveau praticien à accéder aux in formations concernant un patient. La branche 110C de l'organigramme est alors mise en _uvre. L'utilisateur peut également prendre seulement connaissance d'infor mations stockées dans le centre de stockage par mise en _uvre de la bran che 110D de l'organigramme. Lorsque un praticien souhaite entrer une nouvelle information dans le centre 16, I'algorithme diffère suivant que l'information médicale que sou haite entrer le praticien peut être associée automatiquement à un patient constituant une première entité, ou que la liaison au patient doit être réalisée manuellement. Ce choix est effectué à l'étape 111. Si l'information ne contient pas initialement l'identifiant du patient concerné, I'information est entrée par le praticien, par exemple au clavier, à I'étape 112. Une identification du patient concerné est saisie, à l'étape 114, notamment par sélection 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 poste d'utilisateur tel que le poste 1 2C, la reconnaissance de l'identifiant du patient concerné peut se faire au tomatiquement lors de l'entrée de l'information. Ainsi, I'information contenant l'identifiant du patient concerné est entrée, à l'étape 122, par exemple au travers de l'interface 30. Cette information est par exemple constituée d'une image médicale au format DICOM. A l'étape 124, le module logiciel 36 pro cède à une analyse de l'image et à une reconnaissance de l'identifiant du patient dans l'image transmise. A l'étape 130, le praticien définit la liste des identifiants des entités supplémentaires autorisées à accéder aux informations contenues dans I'événement. Cette étape consiste à définir la liste 58 des identifiants des praticiens autorisés à accéder. A l'étape 132, le praticien valide, par saisie d'un code de signature, I'ensemble des éléments constituant l'événement, à savoir l'information mé dicale proprement dite, I'identifiant du patient concerné, son propre identi fiant et la liste des identifiants des entités supplémentaires autorisées à ac céder. A l'issue de cette étape, les éléments constituant l'événement ne peuvent plus être modifiés et l'événement peut seulement être complété. A l'étape 134, le poste d'utilisateur 12 assure la création d'une donnée élémentaire reprenant les différents éléments de l'événement. Cette donnée élémentaire est cryptée par tout procédé adapté et est adressée par l'inter face de dialogue au centre 16 de stockage et de gestion des informations. A sa réception, la donnée éiémentaire est traitée par les serveurs de gestion d'évènements 44, à l'étape 136. Si la donnée élémentaire contient des images numériques dans des formats différents du format XML, ces images sont automatiquement converties au format XML, à l'étape 138, et la donnée élémentaire est complétée par des données images au format XML en plus des données images dans un autre format. La donnée élémentaire ainsi retraitée est sauvegardée définitivement dans l'unité de stockage 48, à l'étape 140. Lorsque l'utilisateur souhaite compléter un événement en ajoutant une information supplémentaire, les étapes de la branche 110B sont mises en _uvre après l'étape 110. A l'étape 150, I'événement à compléter est sélectionné. La don née élémenta ire correspond ant à l'évén ement sélectionné est transmise par le centre 16 au poste utilisateur, à l'étape 152. La donnée élémentaire n'est transmise que si l'identifiant de l'utilisateur est compris dans l'événement en cause, soit qu'il s'agisse du patient concerné, du prati cien à l'origine de l'information ou d'un praticien supplémentaire dont l'identi fiant figure dans la liste 58. L'information supplémentaire est entrée à l'étape 154, soit manuelle ment depuis le clavier, soit par reprise d'un fichier déjà existant. Dans ce dernier cas, I'information supplémentaire constitue un nouveau fichier atta ché. A l'étape 156, I'utilisateur valide l'ajout de l'information par entrée d'un code de signature. s L'information supplémentaire est ajoutée à l'étape 158 pour former une nouvelle donnée élémentaire constituant l'événement modifié. En outre, la date, et l'identifiant de l'utilisateur ayant ajouté l'information, ainsi qu'un lien avec l'information sont ajoutés dans la donnée élémentaire pour asurer un suivi des modifications. La nouvelle donnée élémentaire ainsi constituée est ensuite traitée conformément aux étapes 136 et suivantes. Lorsque l'utilisateur souhaite modifier un droit d'accès, celui-ci peut seulement ajouter de nouveaux identifiants d'utilisateur habilités à accéder à une information donnée. A cet effet, I'événement dont les accès sont à com pléter est sélection né à l'étape 200. La donnée élémentaire correspond ant à I'événement sélectionné est alors transmise au poste utilisateur à l'étape 202. La donnée élémentaire n'est transmise que si l'identifiant de l'utilisateur est compris dans l'événement en cause, soit qu'il s'agisse du patient concerné, du praticien à l'origine de l'information ou d'un praticien supplé mentaire dont l' ide ntifiant fig u re da ns la l iste 58. A l'étape 204, I'utilisateur sélectionne ou entre au clavier un ou plu sieurs identifiants supplémentaires d'utilisateurs habilités à accéder à l'in formation puis il valide, à l'étape 206, les nouveaux identifiants. Les identi fiants supplémentaires sont ajoutés dans la donnée élémentaire constituant l'événement à l'étape 208. En outre, la date, et l'identifiant de l'utiiisateur ayant ajouté les nouveaux identifiants, ainsi qu'un lien avec les nouveaux identifiants sont ajoutés dans la donnée élémentaire pour assurer un suivi des modifications. Les étapes 136 et suivantes sont alors à nouveau mises en _uvre. Pour la consultation des informations stockées dans le centre 16, et depuis n'importe quel poste d'utilisateur 12, les étapes de la branche 110D sont mises en _uvre. A l'étape 250, une requete est formulée par l'utilisateur depuis le poste d'utilisateur. Celle-ci est prise en compte par les serveurs de gestion des évènements 44, à l'étape 252. En fonction des droits d'accès contenus dans l'événement en cause dans la requête, et en fonction des droits de l'uti lisateur, le contenu de la donnée élémentaire est transmis du centre de stoc kage 16 au poste utilisateur 12, à l'étape 254. En particulier, la donnée élémentaire n'est transmise que si l'identi fiant de l'utilisateur est compris dans l'événement en cause dans la requête, soit qu'il s'agisse du patient concerné, du praticien à l'origine de l'information ou d'un praticien supplémentaire dont l'identifiant figure dans la liste 58. L'information est alors mise à disposition de l'utilisateur à l'étape 256, par exemple par affichage, ou bien par sauvegarde du contenu de la donnée élémentaire sur le disque dur du poste utilisateur. A l'étape 258, un journal des accès est mis à jour dans le centre 16 pour enregistrer l'identifiant de l'utilisateur, la nature de l'information mise à disposition, la date d'accès fournie par le système et toute autre information 1 5 utile. On conçoit qu'avec un tel système de gestion d'informations, la fiabili té de l'accès aux informations est accrue, puisque l'information proprement dite est associée, dans une même donnée élémentaire, à un identifiant du patient concerné, un identifiant du praticien ayant engendré l'information et, éventuellement, des identifiants d'autres entités susceptibles d'accéder à l'information proprement dite. Le système de gestion d'informations illustré sur la figure 4 reprend les caractéristiques du système de gestion illustré sur la figure 1. Toutefois, il comporte en outre des moyens de gestion de protocoles médicaux. A cet effet, le centre 16 de stockage et de gestion des informations comporte une unité de stockage supplémentaire 402 dans laquelle est mé morisé de manière permanente un ensemble de protocoles médicaux. Chaque protocole spécifie une séquence d'opérations successives à réaliser par un praticien dans le cas du diagnostic et/ou du traitement d'un patient, ou dans le cas d'une étude épidémiologique ou d'une étude sur ies effets d'un traitement. En particulier, chaque protocole définit des critères décisionnels propres portant sur les informations recueillies lors d'opérations antérieures. Les opérations ultérieures du protocole sont choisies parmi un ensemble d'opérations possibles en fonction des critères propres au proto cole. En outre, l'ensemble de serveurs 44 de gestion d'événements, et plus particulièrement le module logiciel 44B de gestion du stockage d'événe ments est adapté pour la mise en _uvre d'un algorithme de gestion des pro tocoles. L'algoritUme de gestion des protocoles est illustré sur la figure 5. Cet algorithme est mis en _uvre sur une longue période de temps correspondant à toute la durée de mise en _uvre du protocole. Dans le cas du diagnostic eVou du traitement d'une maladie grave, le protocole peut être mis en _uvre sur une période allant d'une semaine à plusieurs mois. A l'étape 502,1'utilisateur, à savoir un praticien sélectionne un proto cole à appliquer depuis un poste d'utilisateur. A cet effet, I'utilisateur a re cours à une interface utilisateur téléchargée depuis le centre de stockage et de gestion 16. Cette interface permet la sélection du protocoie parmi les pro tocoles mémorisés dans l'unité de stockage 402. L'exemple qui suit concerne un protocole de diagnostic ou de traite ment d'un patient. Les informations complémentaires, telles que le patient, sur lequel est appliqué le protocole, sont saisies à l'étape 502. A l'étape 504, le module logiciel 44B effectue une recherche des évé nements existants pouvant être exploités par le protocole. Ces événements existants sont recherchés dans l'unité de stockage 48 parmi les données élémentaires comportant l'identifiant de la première entité sélectionnée à I'étape 502. Chacun des événements pouvant être exploité est rattaché au proto cole, à l'étape 506, afin que les informations qu'il contient soient prises en compte par le protocole. A l'étape 508, le module logiciel 44B effectue une analyse des infor mations contenues dans les événements rattachés à l'étape 106. Cette ana lyse des informations s'effectue par application des critères propres au pro tocole sélectionné. A l'étape 510, un test est effectué pour déterminer si le protocole est achevé ou non. Tant que le protocole n'est pas achevé, le module logiciel 44B crée, à l'étape 512, un ou plusieurs événements. Chaque événement créé corres S pond à une opération ultérieure du protocole à réaliser. Les événements créés dépendent du résultat de l'analyse faite des informations contenues dans les événements antérieurs correspondant à des opérations antérieures du protocole. Ces événements sont généralement incomplets puisque ceux-ci correspondent, par exemple, en fonction du protocole sélectionné, à un examen à effectuer sur le patient, ou à un acte thérapeutique devant être pratiqué sur le patient. Les informations contenues dans l'événement consistent alors, soit au résultat de l'analyse, soit à un compte-rendu fait par le praticien ayant prati qué l'acte thérapeutique. L'événement incomplet créé automatiquement à l'étape 512 contient par exemple seulement l'identifiant du patient, un identifiant du protocole en cours, et l'identifiant d'une ou plusieurs entité autorisées à accéder à i'infor mation qui figurera ultérieurement dans l'événement. D'autres informations telles que la date de création de l'événement peuvent également être spéci fiées automatiquement dès la création de l'événement incomplet. L'événement incomplet est stocké de manière temporaire dans l'unité de stockage 48. A l'étape 514, le module logiciel 44B assure avantageusement l'envoi d'une aierte auprès du praticien concerné par l'événement incomplet, c'est à-dire auprès du praticien devant effectuer l'opération associée. L'étape 514 est facultative et, en l'absence d'alerte, le praticien en charge d'une opération du protocole pour laquelle l'événement incomplet a déjà été créé accède à l'événement incomplet à partir d'un poste d'utilisateur après que le patient a donné accès au praticien à cet événement incomplet dans les conditions décrites précédemment. Le praticien réalisant l'opération prévue par le protocoie assure, à l'étape 516, depuis un poste utilisateur, I'entrée de la ou chaque information dans l'événement initialement incomplet correspondant. Cette entrée d'in formations s'effectue soit manuellement, soit à partir d'une interface 30 de connexion du micro-ordinateur à une installation d'imagerie ou de recueil d'informations médicales. A l'étape 518, le praticien procède à la définition des droits d'accès par entrée des identifiants des entités pouvant ultérieurement accéder aux informations entrées. A l'étape 520, le praticien valide, par saisie d'un code de signature, I'ensemble des éléments constituant l'événement, à savoir notamment l'in formation médicale proprement dite, I'identifiant du patient concerné déjà contenu depuis la création de l'événement, son propre identifiant et la liste des identifiants des entités supplémentaires autorisées à accéder. Les étapes suivantes 522, 524, 526 et 528 sont rigoureusement iden tiques aux étapes 134 à 140 de l'algorithme illustré sur la figure 3. En parti culier, celles-ci consistent à la création d'une donnée élémentaire propre à être stockée, le traitement de la donnée élémentaire et l'éventuelle conver sion d'une image contenue dans celle-ci et, enfin, la sauvegarde de la don née élémentaire dans l'unité de stockage 48. A l'issue de la sauvegarde de la donnée élémentaire correspondant à I'événement ainsi complété, les étapes 506 et suivantes sont à nouveau mi ses en _uvre. En particulier, le nouvel événement produit et sauvegardé est ratta ché, à l'étape 506, aux autres événements puis une nouvelle analyse des informations contenues dans les différents événements, et notamment dans le nouvel événement sauvegardé, est effectuée à l'étape 508 suivant les critères propres au protocole. Si le protocole n'est pas achevé, un ou plu sieurs nouveaux événements incomplets sont créés à l'étape 512 suivant les spécifications du protocole initialement sélectionné. On comprend que la mise en _uvre de l'algorithme de la figure 5 permet une liaison, dans le cadre d'un protocole, des événements existants déjà et la création automatique de nouveaux événements correspondant à des opérations devant être mises en _uvre ultérieurement dans le cadre du protocole sélectionné. Ainsi, les informations issues des différentes entités intervenant dans le protocole sont liées entre elles et prises en compte pour les opérations suivantes devant être mises en _uvre dans le protocole. Ainsi, chaque enti té peut être guidée dans son intervention par la création d'événements in S complets. En outre, I'exploitation qui est faite des informations communi quées par chaque entité est également assistée par l'analyse effectuée à l'étape 508 et la création automatique d'événements incomplets qui en résul tent, à l'étape 512. Un tel système de gestion d'informations peut être appliqué dans d'autres domaines que le domaine médical et notamment dans le domaine juridique. Dans ce cas, la seconde entité est un avocat ou un conseil, la première entité étant le client de l'avocat ou du conseil. De même, ce système de gestion peut être appliqué pour la gestion de projets complexes. Dans ce cas, la première entité est le projet lui-même alors que les secondes entités sont les différents intervenants sur le projet. REVENDICATIONS 1.- Système de gestion d'informations, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le sys tème comprenant: - au moins une base de données (48) pour le stockage desUites in formations (52); et - au moins un poste utilisateur (12) comprenant des moyens de re cueil (12,22, 34, 36) d'au moins une information (52) concernant la première entité; caractérisé en ce qu'il comporte: - des moyens (12) pour créer au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire (50): À Ia ou chaque information (52) concernant la première entité; À un identifiant (54) de la première entité; et À un identifiant (56) de la seconde entité, - des moyens (402) de stockage d'au moins un protocole, lequel pro tocole spécifie une séquence d'opérations successives à réaliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations anté rieures réalisées en fonction de critères propres audit protocole; - des moyens (44B) d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres à un protocole; des moyens (44B) de création automatique, suivant les spécifica tions dudit protocole, d'au moins un événement correspondant à une opéra tion ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres audit protocole; et - des moyens (12, 44, 48) de stockage définitif du contenu du ou de chaque événement créé automatiquement, chacun en tant que donnée élé mentaire (50) dans la ou chaque base de donnces (48). 2.- Système de gestion selon la revendication 1, caractérisé en ce que lesdits moyens (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser sont adaptés pour la création d'un événement incomplet, et en ce qu'ii comporte des moyens pour compléter le ou chaque événement incomplet, par au moins une seconde entité depuis un poste utilisateur, par ajout d'au moins une information dans le ou chaque événement avant son S stockage définitif. 3.- Système de gestion selon la revendication 2, caractérisé en ce qu'il comporte des moyens d'alerte d'au moins une seconde entité pour compléter un événement incomplet. 4.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens pour valider le ou chaque événement, par la ou chaque seconde entité, avant son stockage définitif. 5.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens d'analyse sont adaptés pour l'analyse de la ou chaque information contenue dans au moins deux événements antérieurs. 6.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens de recherche au tomatique parmi les données élémentaires stockées dans la ou chaque base de données, des données élémentaires contenant des informations devant être analysées par les moyens d'analyse en fonction des critères propres audit protocole. 7.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens d'archivage des événements utilisés lors de la mise en _uvre dudit protocole. 8.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens de création automatique d'au moins un événement comportent des moyens d'ajout automatique dans led it événement de l'identifiant de ia première entité concernée par la ou chaque information. 9.- Procédé de gestion d'informations, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le sys tème comprenantau moins une base de données (48) pour le stockage desdites informations (52) et au moins un poste utilisateur (12) comprenant des moyens de recueil (12, 22, 34, 36) d'au moins une information (52) concernant la première entité, le procédé comprenant une étape de recueil, depuis un poste utilisateur (12) d'au moins une information (52) concernant la première entité; caractérisé en ce qu'il comporte: - une étape de création d'au moins un événement regroupant, de ma nière indissociable, dans une méme donnée élémentaire (50): À Ia ou chaque information (52) concernant la première entité; À un identifiant (54) de la première entité; et À un identifiant (56) de la seconde entité, - une étape d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction de critères propres audit proto cole, lequel protocole spécifie une séquence d'opérations successives à ré aliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction des critères propres audit pro tocole; - une étape (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque in formation contenue dans au moins un événement antérieur en fonction des critères propres audit protocole; et - une étape de stockage définitif du contenu du ou de chaque événe ment créé automatiquement, chacun en tant que donnée élémentaire (50)