CA2489317C - Systeme de gestion d'informations pour situation d'urgence - Google Patents
Systeme de gestion d'informations pour situation d'urgence Download PDFInfo
- Publication number
- CA2489317C CA2489317C CA002489317A CA2489317A CA2489317C CA 2489317 C CA2489317 C CA 2489317C CA 002489317 A CA002489317 A CA 002489317A CA 2489317 A CA2489317 A CA 2489317A CA 2489317 C CA2489317 C CA 2489317C
- Authority
- CA
- Canada
- Prior art keywords
- information
- entity
- identifier
- event
- access
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/60—ICT specially adapted for the handling or processing of medical references relating to pathologies
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Theoretical Computer Science (AREA)
- Bioethics (AREA)
- Public Health (AREA)
- Primary Health Care (AREA)
- Epidemiology (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Alarm Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Ce systme comprend :- au moins une base de donnes (48) pour le stockage : desdites informations ; d'un identifiant de la premire entit concerne par chaque in-formation ; et- au moins un poste d'interrogation (36) comprenant des moyens d'accs
; la base de donnes (48),- des moyens pour dfinir des informations d'alerte parmi les informations ; - des moyens (49) pour associ er un code d'accs d'urgence aux informations d'alerte.Les moyens d'accs comportent des moyens d'entre du code d'accs d'urgence et des moyens pour mettre
disposition les informations d'alerte concernant une premire entit sans que l'identifiant de la premire entit ne soit mis
disposition.</SDO AB>
Description
Système de gestion d'informations pour situation d'urgence 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é, le système comprenant :
- au moins une base de données pour le stockage :
= desdites informations ;
= d'un identifiant de la première entité concernée par chaque in-formation, chaque information étant associée à l'identifiant de la première entité concernée ; et - au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations.
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 particulier, ces obligations déontologiques 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 concerné
et le patient doit pouvoir accéder aux informations le concernant.
Les obligations déontologiques des praticiens rendent difficiles l'exploitation des données concernant le patient en cas d'urgence. En parti-culier, si le patient est victime d'un malaise sur le voie publique, les services d'urgence prenant en charge le patient ne peuvent accéder directement aux informations médicales concernant le patient, dans la mesure où ce service d'urgence n'a pas été préalablement autorisé à accéder à ces informations et que le patient n'est pas nécessairement facilement identifiable notamment s'il est inconscient.
L'invention a pour but un système de gestion d'informations permet-tant de rendre accessible des informations utiles, même lorsque la personne concernée par ses informations n'est pas consciente, tout en garantissant le respect des obligations déontologiques.
- au moins une base de données pour le stockage :
= desdites informations ;
= d'un identifiant de la première entité concernée par chaque in-formation, chaque information étant associée à l'identifiant de la première entité concernée ; et - au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations.
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 particulier, ces obligations déontologiques 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 concerné
et le patient doit pouvoir accéder aux informations le concernant.
Les obligations déontologiques des praticiens rendent difficiles l'exploitation des données concernant le patient en cas d'urgence. En parti-culier, si le patient est victime d'un malaise sur le voie publique, les services d'urgence prenant en charge le patient ne peuvent accéder directement aux informations médicales concernant le patient, dans la mesure où ce service d'urgence n'a pas été préalablement autorisé à accéder à ces informations et que le patient n'est pas nécessairement facilement identifiable notamment s'il est inconscient.
L'invention a pour but un système de gestion d'informations permet-tant de rendre accessible des informations utiles, même lorsque la personne concernée par ses informations n'est pas consciente, tout en garantissant le respect des obligations déontologiques.
2 A cet effet, l'invention a pour objet un système de gestion d'information et notamment d'informations médicales comportant:
- au moins une base de données pour le stockage:
= desdites informations;
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité concernée; et - au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations, caractérisé en ce qu'il comporte:
- des moyens pour définir des informations d'alerte parmi lesdites informations;
- des moyens pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité; et en ce que lesdits moyens d'accès comportent des moyens d'entrée du code d'accès d'urgence et des moyens pour, lors de l'entrée du code d'accès d'urgence associé à l'identifiant d'une première entité, mettre à disposition les informations d'alerte concernant la première entité associée au code d'accès d'urgence, sans que l'identifiant de la première entité ne soit mis à
disposition, et en ce que le système comprend des moyens pour créer au moins un évènement regroupant des éléments, de manière indissociable, dans une même donnée élémentaire, lesdits éléments comprenant:
= la ou chaque information concernant la première entité;
= l'identifiant de la première entité; et = l'identifiant de la seconde entité, - des moyens pour valider ledit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- au moins une base de données pour le stockage:
= desdites informations;
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité concernée; et - au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations, caractérisé en ce qu'il comporte:
- des moyens pour définir des informations d'alerte parmi lesdites informations;
- des moyens pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité; et en ce que lesdits moyens d'accès comportent des moyens d'entrée du code d'accès d'urgence et des moyens pour, lors de l'entrée du code d'accès d'urgence associé à l'identifiant d'une première entité, mettre à disposition les informations d'alerte concernant la première entité associée au code d'accès d'urgence, sans que l'identifiant de la première entité ne soit mis à
disposition, et en ce que le système comprend des moyens pour créer au moins un évènement regroupant des éléments, de manière indissociable, dans une même donnée élémentaire, lesdits éléments comprenant:
= la ou chaque information concernant la première entité;
= l'identifiant de la première entité; et = l'identifiant de la seconde entité, - des moyens pour valider ledit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
3 - des moyens de stockage définitif du contenu du ou de chaque évènement, chacun en tant que donnée élémentaire (50) dans la ou chaque base de données, et en ce que lesdits moyens d'accès comportent des moyens pour permettre l'accès à ladite information comprise dans ladite donnée élémentaire de cet évènement seulement par une entité parmi la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant ladite information.
Suivant un mode particulier de réalisation, les moyens pour définir des informations d'alerte parmi les informations comportent:
= des moyens pour fixer, pour chaque information, un indicateur d'alerte représentatif de la définition des informations ;
= des moyens pour intégrer dans la donnée élémentaire corres-pondant à l'évènement contenant ladite information, l'indicateur d'alerte représentatif de la définition des informations ; et = des moyens pour intégrer dans la donnée élémentaire corres-pondant à l'évènement contenant ladite information, l'indicateur d'alerte, et lesdits moyens pour mettre à disposition les informations d'alerte compor-tent des moyens d'analyse de l'indicateur d'alerte contenu dans chaque évènement contenant l'identifiant de la première entité associée au code d'accès d'urgence, et les moyens pour mettre à disposition les informations d'alerte sont adaptés pour mettre à disposition la ou chaque information contenue dans l'évènement, si l'analyse de l'indicateur d'alerte montre que la ou chaque information est une information d'alerte ;
- le système comporte des moyens pour intégrer dans chaque don-née élémentaire correspondant à un évènement un identifiant d'une se-conde entité ayant engendrée ladite information ;
- lesdits moyens pour associer un code d'accès d'urgence, aux infor-mations d'alerte concernant une même première entité comportant une base
Suivant un mode particulier de réalisation, les moyens pour définir des informations d'alerte parmi les informations comportent:
= des moyens pour fixer, pour chaque information, un indicateur d'alerte représentatif de la définition des informations ;
= des moyens pour intégrer dans la donnée élémentaire corres-pondant à l'évènement contenant ladite information, l'indicateur d'alerte représentatif de la définition des informations ; et = des moyens pour intégrer dans la donnée élémentaire corres-pondant à l'évènement contenant ladite information, l'indicateur d'alerte, et lesdits moyens pour mettre à disposition les informations d'alerte compor-tent des moyens d'analyse de l'indicateur d'alerte contenu dans chaque évènement contenant l'identifiant de la première entité associée au code d'accès d'urgence, et les moyens pour mettre à disposition les informations d'alerte sont adaptés pour mettre à disposition la ou chaque information contenue dans l'évènement, si l'analyse de l'indicateur d'alerte montre que la ou chaque information est une information d'alerte ;
- le système comporte des moyens pour intégrer dans chaque don-née élémentaire correspondant à un évènement un identifiant d'une se-conde entité ayant engendrée ladite information ;
- lesdits moyens pour associer un code d'accès d'urgence, aux infor-mations d'alerte concernant une même première entité comportant une base
4 de données établissant une correspondance entre chaque code d'accès d'urgence et un identifiant d'une première entité ; et - le système comporte des moyens de génération aléatoire d'un code d'accès d'urgence pour chaque nouvel identifiant d'une première entité.
L'invention a également pour objet un procédé de gestions d'informa-tions, chaque information concernant une première entité dans un système comprenant :
- au moins une base de données pour le stockage:
= desdites informations;
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité;
- au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations, et - des moyens pour définir des informations d'alerte parmi lesdites informations, et dans lequel un code d'accès d'urgence est associé aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité, caractérisé en ce que le procédé comprend: une étape d'entrée depuis lesdits moyens d'accès, d'un code d'accès d'urgence, et, lors de l'entrée dudit code d'accès d'urgence associé à l'identifiant d'une première entité, une étape de mise à disposition des informations d'alerte concernant la première entité
associée au code d'accès d'urgence, sans que l'identifiant de la première entité
ne soit mis à disposition;
- une étape de création d'au moins un évènement regroupant, de manière indissociable, dans une même donnée élémentaire lesdits éléments de:
= la ou chaque information concernant la première entité;
= l'identifiant de la première entité; et = l'identifiant de la seconde entité, - une étape de validation dudit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière = CA 02489317 2008-03-27 4a indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- une étape de stockage définitif du contenu de chaque évènement validé, en tant que donnée élémentaire dans la ou chaque base de données, caractérisé en ce que l'accès à une information comprise dans une donnée élémentaire depuis un poste utilisateur n'est permis que par la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant l'information.
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-formations selon l'invention ;
- la figure 2 est une vue schématique illustrant le format d'une donnée élémentaire utilisé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 oeu-vre dans le système, et - la figure 4 est un organigramme de l'algorithme de consultation d'urgence du 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 conservé, 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 à par-tir de l'identifiant du patient seulement au patient concerné et au praticien
L'invention a également pour objet un procédé de gestions d'informa-tions, chaque information concernant une première entité dans un système comprenant :
- au moins une base de données pour le stockage:
= desdites informations;
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité;
- au moins un poste d'interrogation comprenant des moyens d'accès à la ou chaque base de données pour la consultation desdites informations, et - des moyens pour définir des informations d'alerte parmi lesdites informations, et dans lequel un code d'accès d'urgence est associé aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité, caractérisé en ce que le procédé comprend: une étape d'entrée depuis lesdits moyens d'accès, d'un code d'accès d'urgence, et, lors de l'entrée dudit code d'accès d'urgence associé à l'identifiant d'une première entité, une étape de mise à disposition des informations d'alerte concernant la première entité
associée au code d'accès d'urgence, sans que l'identifiant de la première entité
ne soit mis à disposition;
- une étape de création d'au moins un évènement regroupant, de manière indissociable, dans une même donnée élémentaire lesdits éléments de:
= la ou chaque information concernant la première entité;
= l'identifiant de la première entité; et = l'identifiant de la seconde entité, - une étape de validation dudit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière = CA 02489317 2008-03-27 4a indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- une étape de stockage définitif du contenu de chaque évènement validé, en tant que donnée élémentaire dans la ou chaque base de données, caractérisé en ce que l'accès à une information comprise dans une donnée élémentaire depuis un poste utilisateur n'est permis que par la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant l'information.
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-formations selon l'invention ;
- la figure 2 est une vue schématique illustrant le format d'une donnée élémentaire utilisé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 oeu-vre dans le système, et - la figure 4 est un organigramme de l'algorithme de consultation d'urgence du 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 conservé, 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 à par-tir de l'identifiant du patient seulement au patient concerné et au praticien
5 ayant engendré l'information, ainsi que, éventuellement, après accord du patient, à d'autres praticiens.
En outre, le système permet l'accès à certaines informations stockées concernant un patient par des personnes disposant d'un code d'accès d'urgence. Les informations sont alors mises à disposition en nombre réduit, et sans que l'identifiant du patient concerné par ces informations ne soit mis à disposition.
Chaque entité intervenant 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é. Il 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 oeuvre, 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 12A, 12B, 12C 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 centre 16 et sont par exemple constitués d'une page
En outre, le système permet l'accès à certaines informations stockées concernant un patient par des personnes disposant d'un code d'accès d'urgence. Les informations sont alors mises à disposition en nombre réduit, et sans que l'identifiant du patient concerné par ces informations ne soit mis à disposition.
Chaque entité intervenant 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é. Il 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 oeuvre, 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 12A, 12B, 12C 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 centre 16 et sont par exemple constitués d'une page
6 depuis le centre 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 oeuvre 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é.
En outre, le système comporte des postes d'interrogation 36 reliés au centre 16 de stockage et de gestion des informations au travers du réseau 14. Chaque poste d'interrogation 36 est constitué par n'importe quel micro-ordinateur 20 équipé d'un navigateur internet adapté. Ces postes d'interrogation n'ont pas à être identifiés initialement par le centre de stoc-kage et de gestion des informations 16.
Chaque poste d'interrogation 36 comporte des moyens d'entrée d'un code d'accès d'urgence, tels qu'un clavier 37, ou un lecteur de carte à puce 38 ainsi qu'un périphérique de mise à disposition d'informations tel qu'un écran ou une imprimante 39.
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 40A adapté, comme connu en soi, pour identifier l'origine d'une requête adressée au centre serveur. Il comporte en outre un ou plusieurs serveurs 40B 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-
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 oeuvre 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é.
En outre, le système comporte des postes d'interrogation 36 reliés au centre 16 de stockage et de gestion des informations au travers du réseau 14. Chaque poste d'interrogation 36 est constitué par n'importe quel micro-ordinateur 20 équipé d'un navigateur internet adapté. Ces postes d'interrogation n'ont pas à être identifiés initialement par le centre de stoc-kage et de gestion des informations 16.
Chaque poste d'interrogation 36 comporte des moyens d'entrée d'un code d'accès d'urgence, tels qu'un clavier 37, ou un lecteur de carte à puce 38 ainsi qu'un périphérique de mise à disposition d'informations tel qu'un écran ou une imprimante 39.
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 40A adapté, comme connu en soi, pour identifier l'origine d'une requête adressée au centre serveur. Il comporte en outre un ou plusieurs serveurs 40B 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-
7 rectement au réseau 14 au travers d'une première barrière de sécurité 42 (firewalls).
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 oruvre 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 oeuvre 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 données 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.
En outre, une unité supplémentaire 49 de stockage est reliée à
l'ensemble de serveurs 44. Cette unité de stockage est destinée à la mémo-risation permanente d'une base de données dans laquelle est stocké, pour chaque identifiant d'un patient concerné par des informations, un code d'accès d'urgence associé.
Le code d'accès d'urgence est défini aléatoirement par le module de gestion 44B pour chaque nouveau patient géré par le système. Le code est différent de l'identifiant du patient tel que son nom.
Le code d'accès d'urgence est inscrit sur une carte remise au patient.
Sur cette carte figure également l'adresse IP du centre 16 de stockage et de gestion des informations.
En variante, le code d'accès d'urgence est mémorisé dans une carte à mémoire pouvant être lu dans un lecteur de carte d'un ordinateur. Cette carte porte également l'adresse IP du centre 16.
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.
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 oruvre 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 oeuvre 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 données 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.
En outre, une unité supplémentaire 49 de stockage est reliée à
l'ensemble de serveurs 44. Cette unité de stockage est destinée à la mémo-risation permanente d'une base de données dans laquelle est stocké, pour chaque identifiant d'un patient concerné par des informations, un code d'accès d'urgence associé.
Le code d'accès d'urgence est défini aléatoirement par le module de gestion 44B pour chaque nouveau patient géré par le système. Le code est différent de l'identifiant du patient tel que son nom.
Le code d'accès d'urgence est inscrit sur une carte remise au patient.
Sur cette carte figure également l'adresse IP du centre 16 de stockage et de gestion des informations.
En variante, le code d'accès d'urgence est mémorisé dans une carte à mémoire pouvant être lu dans un lecteur de carte d'un ordinateur. Cette carte porte également l'adresse IP du centre 16.
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.
8 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 52. De même, l'é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 :
- untitre;
- une date de création et/ou de compléments de l'évènement ; et - une liste de mots clés.
En outre, chaque évènement comporte un indicateur d'alerte consti-tué d'un indicateur bouléen indiquant dans son premier état (valide) que les informations contenues dans l'évènement constituent des informations d'alerte pouvant être communiquées en cas d'urgence, et dans son deuxième état (non valide), que les informations contenues dans l'évènement ne doivent pas être communiquées en cas d'urgence.
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, la modification de l'indicateur d'alerte d'une information ou la consultation d'une information, l'utilisateur se connecte depuis un poste d'utilisateur 12 au centre de stoc-kage 16.
L'algorithme de la figure 3 est alors mis en oruvre.
Le poste d'utilisateur 12 peut être constitué, pour les opérations les plus simples, seulement d'un micro-ordinateur relié au réseau Internet à
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 52. De même, l'é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 :
- untitre;
- une date de création et/ou de compléments de l'évènement ; et - une liste de mots clés.
En outre, chaque évènement comporte un indicateur d'alerte consti-tué d'un indicateur bouléen indiquant dans son premier état (valide) que les informations contenues dans l'évènement constituent des informations d'alerte pouvant être communiquées en cas d'urgence, et dans son deuxième état (non valide), que les informations contenues dans l'évènement ne doivent pas être communiquées en cas d'urgence.
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, la modification de l'indicateur d'alerte d'une information ou la consultation d'une information, l'utilisateur se connecte depuis un poste d'utilisateur 12 au centre de stoc-kage 16.
L'algorithme de la figure 3 est alors mis en oruvre.
Le poste d'utilisateur 12 peut être constitué, pour les opérations les plus simples, seulement d'un micro-ordinateur relié au réseau Internet à
9 l'aide d'un navigateur de tout type adapté. Après connexion du poste d'utili-sateur, à l'étape 100, l'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 oeuvre 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 110A de l'organigramme est alors mise en ceuvre.
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 110B de l'organigramme est alors mise en oeuvre.
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 osuvre.
Lorsque le praticien souhaite modifier l'indicateur d'alerte d'un évè-nement, la branche 110D de l'algorithme est mise en oruvre.
L'utilisateur peut également prendre seulement connaissance d'infor-mations stockées dans le centre de stockage par mise en ceuvre de la bran-che 110E de l'organigramme.
Lorsque un praticien souhaite entrer une nouvelle information dans le centre 16, l'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é, l'information est entrée par le praticien, par exemple au clavier, à
l'é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 12C, la reconnaissance de l'identifiant du patient concerné peut se faire au-5 tomatiquement lors de l'entrée de l'information. Ainsi, l'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
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 110A de l'organigramme est alors mise en ceuvre.
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 110B de l'organigramme est alors mise en oeuvre.
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 osuvre.
Lorsque le praticien souhaite modifier l'indicateur d'alerte d'un évè-nement, la branche 110D de l'algorithme est mise en oruvre.
L'utilisateur peut également prendre seulement connaissance d'infor-mations stockées dans le centre de stockage par mise en ceuvre de la bran-che 110E de l'organigramme.
Lorsque un praticien souhaite entrer une nouvelle information dans le centre 16, l'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é, l'information est entrée par le praticien, par exemple au clavier, à
l'é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 12C, la reconnaissance de l'identifiant du patient concerné peut se faire au-5 tomatiquement lors de l'entrée de l'information. Ainsi, l'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
10 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 l'évènement. Cette étape consiste à définir la liste 58 des identifiants des praticiens autorisés à accéder.
A l'étape 131, le praticien définit l'indicateur d'alerte en précisant si l'information contenue dans l'évènement peut ou non être rendue accessible en cas d'urgence suivant une procédure décrite dans la suite de la descrip-tion.
Si le praticien souhaite rendre cette information accessible en cas d'urgence, il s'assure que l'information en elle-même ne contient pas de données permettant d'identifier le patient comme son nom.
A l'étape 132, le praticien valide, par saisie d'un code de signature, l'ensemble des éléments constituant l'évènement, à savoir l'information mé-dicale proprement dite, l'identifiant du patient concerné, son propre identi-fiant,la liste des identifiants des entités supplémentaires autorisées à accé-der, et l'indicateur d'alerte. 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 l'étape 130, le praticien définit la liste des identifiants des entités supplémentaires autorisées à accéder aux informations contenues dans l'évènement. Cette étape consiste à définir la liste 58 des identifiants des praticiens autorisés à accéder.
A l'étape 131, le praticien définit l'indicateur d'alerte en précisant si l'information contenue dans l'évènement peut ou non être rendue accessible en cas d'urgence suivant une procédure décrite dans la suite de la descrip-tion.
Si le praticien souhaite rendre cette information accessible en cas d'urgence, il s'assure que l'information en elle-même ne contient pas de données permettant d'identifier le patient comme son nom.
A l'étape 132, le praticien valide, par saisie d'un code de signature, l'ensemble des éléments constituant l'évènement, à savoir l'information mé-dicale proprement dite, l'identifiant du patient concerné, son propre identi-fiant,la liste des identifiants des entités supplémentaires autorisées à accé-der, et l'indicateur d'alerte. 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.
11 A sa réception, la donnée élé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 ceuvre après l'étape 110.
A l'étape 150, l'évènement à compléter est sélectionné.
La donnée élémentaire correspondant à l'évènement 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, l'information supplémentaire constitue un nouveau fichier atta-ché.
A l'étape 156, l'utilisateur valide l'ajout de l'information par entrée d'un code de signature.
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 assurer 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, l'évènement dont les accès sont à com-
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 ceuvre après l'étape 110.
A l'étape 150, l'évènement à compléter est sélectionné.
La donnée élémentaire correspondant à l'évènement 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, l'information supplémentaire constitue un nouveau fichier atta-ché.
A l'étape 156, l'utilisateur valide l'ajout de l'information par entrée d'un code de signature.
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 assurer 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, l'évènement dont les accès sont à com-
12 pléter est sélectionné à l'étape 200. La donnée élémentaire correspondant à
l'é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'identifiant figure dans la liste 58.
A l'étape 204, l'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'utilisateur 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 ceuvre.
Lorsque l'utilisateur, et notamment le praticien souhaite modifier l'indicateur d'alerte associé à une information, afin de rendre accessible cette information en cas d'urgence, ou au contraire ne pas mettre à disposi-tion cette information, la branche 110D de l'algorithme est mise en oruvre.
A l'étape 210 l'évènement dont l'indicateur d'alerte doit être modifié
est sélectionné. La donnée élémentaire correspondant à l'évènement sélec-tionné est transmise au poste utilisateur 12 à l'étape 212, sous réserve que l'identifiant de l'utilisateur soit compris dans l'évènement en cause parce qu'il s'agit du patient concerné, du praticien à l'origine de l'information ou d'un praticien supplémentaire dont l'identificateur figure dans la liste 58.
A l'étape 214, l'utilisateur change l'état de l'indicateur d'alerte, par exemple par validation à l'écran d'une zone prédéfinie. Si le praticien sou-haite rendre cette information accessible en cas d'urgence, il s'assure que l'information en elle-même ne contient pas de données permettant d'identifier le patient comme son nom. L'évènement modifié est alors validé
ensuite à l'étape 216.
La nouvelle valeur de l'indicateur d'alerte est ajoutée dans la donnée élémentaire constituant l'évènement à l'étape 218.
l'é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'identifiant figure dans la liste 58.
A l'étape 204, l'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'utilisateur 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 ceuvre.
Lorsque l'utilisateur, et notamment le praticien souhaite modifier l'indicateur d'alerte associé à une information, afin de rendre accessible cette information en cas d'urgence, ou au contraire ne pas mettre à disposi-tion cette information, la branche 110D de l'algorithme est mise en oruvre.
A l'étape 210 l'évènement dont l'indicateur d'alerte doit être modifié
est sélectionné. La donnée élémentaire correspondant à l'évènement sélec-tionné est transmise au poste utilisateur 12 à l'étape 212, sous réserve que l'identifiant de l'utilisateur soit compris dans l'évènement en cause parce qu'il s'agit du patient concerné, du praticien à l'origine de l'information ou d'un praticien supplémentaire dont l'identificateur figure dans la liste 58.
A l'étape 214, l'utilisateur change l'état de l'indicateur d'alerte, par exemple par validation à l'écran d'une zone prédéfinie. Si le praticien sou-haite rendre cette information accessible en cas d'urgence, il s'assure que l'information en elle-même ne contient pas de données permettant d'identifier le patient comme son nom. L'évènement modifié est alors validé
ensuite à l'étape 216.
La nouvelle valeur de l'indicateur d'alerte est ajoutée dans la donnée élémentaire constituant l'évènement à l'étape 218.
13 En outre, la date et l'identifiant de l'utilisateur ayant modifié
l'indicateur d'alerte 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 oeuvre.
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 110E
sont mises en oeuvre.
A l'étape 250, une requête 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 stockage 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 utile.
Afin de permettre que des informations nécessaires en cas d'urgence puissent être rendues accessibles aux services de secours, que ceux-ci soient des praticiens de santé ou non, le patient, dont les informations sont stockées dans le système, porte sur lui la carte sur laquelle figure l'adresse IP du centre 16 de gestion et de stockage d'informations sur le réseau 14, ainsi que le code d'accès d'urgence associé au patient.
Pour permettre l'accès aux informations d'alerte, l'algorithme de la figure 4 est mise en oruvre.
l'indicateur d'alerte 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 oeuvre.
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 110E
sont mises en oeuvre.
A l'étape 250, une requête 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 stockage 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 utile.
Afin de permettre que des informations nécessaires en cas d'urgence puissent être rendues accessibles aux services de secours, que ceux-ci soient des praticiens de santé ou non, le patient, dont les informations sont stockées dans le système, porte sur lui la carte sur laquelle figure l'adresse IP du centre 16 de gestion et de stockage d'informations sur le réseau 14, ainsi que le code d'accès d'urgence associé au patient.
Pour permettre l'accès aux informations d'alerte, l'algorithme de la figure 4 est mise en oruvre.
14 Lorsque le patient nécessite des soins médicaux, alors que celui-ci n'est pas chez un praticien habilité à accéder aux informations, le patient peut fournir à n'importe quel interlocuteur la carte qu'il porte sur lui pour permettre à son interlocuteur d'accéder à certaines informations d'alerte que le patient a préalablement sélectionnées en plaçant ou faisant placer les in-dicateurs d'alerte associés à ces informations dans un état valide prédéter-miné.
Au cas où le patient est inanimé, les services de secours peuvent se saisir de la carte portée par le patient et effectuer eux-mêmes le recueil des informations d'urgence.
A cet effet, à l'étape 402, le service de secours se connecte au centre 16 de stockage et de gestion des informations grâce à l'adresse IP mention-née sur la carte portée par le patient. Cette connexion peut être effectuée depuis n'importe quel ordinateur connecté au réseau 14 et disposant d'un navigateur internet adapté. Cet ordinateur forme alors un poste d'interrogation 36.
Après connexion, le centre 16 assure à l'étape 404 le chargement dans le poste d'interrogation 36 d'une interface d'utilisateur. A l'étape 406, le service de secours est invité à entrer le code d'accès d'urgence propre au patient. Ce code d'accès d'urgence étant totalement indépendant de l'identifiant du patient, l'identifiant du patient n'est pas nécessaire pour l'entrée du code d'alerte.
Le module logiciel 44B de gestion des accès aux évènements stockés détermine à l'étape 408 si le code d'accès d'urgence est ou non associé à
un identifiant connu, par interrogation de la base de données hébergée dans l'unité de stockage 49.
Si le code d'accès d'alerte est inconnu, l'étape 406 est à nouveau mise en ceuvre.
En revanche, si le code d'accès d'alerte est connu, le centre 16 de stockage et de gestion des informations détermine à l'étape 410 l'identifiant du patient concerné.
A l'étape 412, le module logiciel 44B de gestion des évènements re-cherche, parmi les évènements stockés, les évènements contenant l'identifiant de la première entité. Parmi ces évènements trouvés, il analyse à
l'étape 414 l'indicateur d'alerte associé à chaque évènement. Il sélectionne parmi les évènements ceux dont les indicateurs d'alerte sont dans un état valide indiquant que les informations contenues dans l'évènement peuvent 5 être communiquées en cas d'urgence.
A l'étape 416, le centre 16 assure la transmission, sans cryptage des informations contenues dans chacun des seuls évènements de la base 48 dont l'indicateur d'alerte est valide, et dont l'identifiant de la première entité
est l'identifiant associé au code d'accès d'alerte dans la base 49.
10 Les informations transmises sont communiquées sans que l'identifiant de la première entité ne soit transmis.
A l'étape 418, les informations transmises sont mises à disposition du service d'urgence, par exemple par affichage de ces informations sur l'écran du poste d'interrogation 36.
Au cas où le patient est inanimé, les services de secours peuvent se saisir de la carte portée par le patient et effectuer eux-mêmes le recueil des informations d'urgence.
A cet effet, à l'étape 402, le service de secours se connecte au centre 16 de stockage et de gestion des informations grâce à l'adresse IP mention-née sur la carte portée par le patient. Cette connexion peut être effectuée depuis n'importe quel ordinateur connecté au réseau 14 et disposant d'un navigateur internet adapté. Cet ordinateur forme alors un poste d'interrogation 36.
Après connexion, le centre 16 assure à l'étape 404 le chargement dans le poste d'interrogation 36 d'une interface d'utilisateur. A l'étape 406, le service de secours est invité à entrer le code d'accès d'urgence propre au patient. Ce code d'accès d'urgence étant totalement indépendant de l'identifiant du patient, l'identifiant du patient n'est pas nécessaire pour l'entrée du code d'alerte.
Le module logiciel 44B de gestion des accès aux évènements stockés détermine à l'étape 408 si le code d'accès d'urgence est ou non associé à
un identifiant connu, par interrogation de la base de données hébergée dans l'unité de stockage 49.
Si le code d'accès d'alerte est inconnu, l'étape 406 est à nouveau mise en ceuvre.
En revanche, si le code d'accès d'alerte est connu, le centre 16 de stockage et de gestion des informations détermine à l'étape 410 l'identifiant du patient concerné.
A l'étape 412, le module logiciel 44B de gestion des évènements re-cherche, parmi les évènements stockés, les évènements contenant l'identifiant de la première entité. Parmi ces évènements trouvés, il analyse à
l'étape 414 l'indicateur d'alerte associé à chaque évènement. Il sélectionne parmi les évènements ceux dont les indicateurs d'alerte sont dans un état valide indiquant que les informations contenues dans l'évènement peuvent 5 être communiquées en cas d'urgence.
A l'étape 416, le centre 16 assure la transmission, sans cryptage des informations contenues dans chacun des seuls évènements de la base 48 dont l'indicateur d'alerte est valide, et dont l'identifiant de la première entité
est l'identifiant associé au code d'accès d'alerte dans la base 49.
10 Les informations transmises sont communiquées sans que l'identifiant de la première entité ne soit transmis.
A l'étape 418, les informations transmises sont mises à disposition du service d'urgence, par exemple par affichage de ces informations sur l'écran du poste d'interrogation 36.
15 A l'étape 420, le journal des accès est mis à jour dans le centre 16 par enregistrement de la nature de l'information mise à disposition, la date d'accès fournie par le système ou toute autre information utile.
On conçoit qu'avec un tel système de gestion d'informations, des in-formations utiles au traitement du patient en cas d'urgence peuvent être mi-ses à disposition à tout service de secours, sans que l'identité du patient ne soit dévoilée, et en permettant que seules les informations nécessaires pré-alablement sélectionnées avec l'accord du patient soit transmise au service de secours lors de son intervention.
En outre, l'accès à ces informations est très simple et est rendue pos-sible même si le service de secours n'est pas normalement habilité à inter-venir sur le système et même si le patient est inconscient.
On conçoit qu'avec un tel système de gestion d'informations, des in-formations utiles au traitement du patient en cas d'urgence peuvent être mi-ses à disposition à tout service de secours, sans que l'identité du patient ne soit dévoilée, et en permettant que seules les informations nécessaires pré-alablement sélectionnées avec l'accord du patient soit transmise au service de secours lors de son intervention.
En outre, l'accès à ces informations est très simple et est rendue pos-sible même si le service de secours n'est pas normalement habilité à inter-venir sur le système et même si le patient est inconscient.
Claims (6)
1. Système de gestion d'informations, chaque information concernant une première entité, le système comprenant:
- au moins une base de données (48) pour le stockage:
.cndot. desdites informations (52);
.cndot. d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité concernée; et - au moins un poste d'interrogation (36) comprenant des moyens d'accès à la ou chaque base de données (48) pour la consultation desdites informations, caractérisé en ce qu'il comporte:
- des moyens pour définir des informations d'alerte parmi lesdites informations;
- des moyens (49) pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité; et en ce que lesdits moyens d'accès comportent des moyens d'entrée du code d'accès d'urgence et des moyens pour, lors de l'entrée du code d'accès d'urgence associé à l'identifiant d'une première entité, mettre à disposition les informations d'alerte concernant la première entité associée au code d'accès d'urgence, sans que l'identifiant de la première entité ne soit mis à
disposition, et en ce que le système comprend des moyens (12) pour créer au moins un évènement regroupant des éléments, de manière indissociable, dans une même donnée élémentaire (50), lesdits éléments comprenant:
.cndot. la ou chaque information (52) concernant la première entité;
.cndot. l'identifiant (54) de la première entité; et .cndot. l'identifiant (56) de la seconde entité, - des moyens pour valider ledit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- des moyens (12, 44, 48) de stockage définitif du contenu du ou de chaque évènement, chacun en tant que donnée élémentaire (50) dans la ou chaque base de données (48), et en ce que lesdits moyens (12, 14, 40, 44) d'accès comportent des moyens pour permettre l'accès à ladite information comprise dans ladite donnée élémentaire de cet évènement seulement par une entité parmi la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant ladite information.
- au moins une base de données (48) pour le stockage:
.cndot. desdites informations (52);
.cndot. d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité concernée; et - au moins un poste d'interrogation (36) comprenant des moyens d'accès à la ou chaque base de données (48) pour la consultation desdites informations, caractérisé en ce qu'il comporte:
- des moyens pour définir des informations d'alerte parmi lesdites informations;
- des moyens (49) pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité; et en ce que lesdits moyens d'accès comportent des moyens d'entrée du code d'accès d'urgence et des moyens pour, lors de l'entrée du code d'accès d'urgence associé à l'identifiant d'une première entité, mettre à disposition les informations d'alerte concernant la première entité associée au code d'accès d'urgence, sans que l'identifiant de la première entité ne soit mis à
disposition, et en ce que le système comprend des moyens (12) pour créer au moins un évènement regroupant des éléments, de manière indissociable, dans une même donnée élémentaire (50), lesdits éléments comprenant:
.cndot. la ou chaque information (52) concernant la première entité;
.cndot. l'identifiant (54) de la première entité; et .cndot. l'identifiant (56) de la seconde entité, - des moyens pour valider ledit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- des moyens (12, 44, 48) de stockage définitif du contenu du ou de chaque évènement, chacun en tant que donnée élémentaire (50) dans la ou chaque base de données (48), et en ce que lesdits moyens (12, 14, 40, 44) d'accès comportent des moyens pour permettre l'accès à ladite information comprise dans ladite donnée élémentaire de cet évènement seulement par une entité parmi la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant ladite information.
2. Système de gestion d'informations selon la revendication 1, caractérisé
en ce que les moyens (12) pour définir des informations d'alerte parmi les informations comportent:
- des moyens pour fixer, pour chaque information, un indicateur d'alerte (59) représentatif de la définition des informations;
- des moyens pour intégrer dans la donnée élémentaire correspondant à
l'évènement contenant ladite information, l'indicateur d'alerte (59) représentatif de la définition des informations; et - des moyens pour intégrer dans la donnée élémentaire correspondant à
l'évènement contenant ladite information, l'indicateur d'alerte (59), et en ce que lesdits moyens pour mettre à disposition les informations d'alerte comportent des moyens d'analyse de l'indicateur d'alerte (59) contenu dans chaque évènement contenant l'identifiant de la première entité associée au code d'accès d'urgence, et les moyens pour mettre à disposition les informations d'alerte sont adaptés pour mettre à disposition la ou chaque information contenue dans l'évènement, si l'analyse de l'indicateur d'alerte montre que la ou chaque information est une information d'alerte.
en ce que les moyens (12) pour définir des informations d'alerte parmi les informations comportent:
- des moyens pour fixer, pour chaque information, un indicateur d'alerte (59) représentatif de la définition des informations;
- des moyens pour intégrer dans la donnée élémentaire correspondant à
l'évènement contenant ladite information, l'indicateur d'alerte (59) représentatif de la définition des informations; et - des moyens pour intégrer dans la donnée élémentaire correspondant à
l'évènement contenant ladite information, l'indicateur d'alerte (59), et en ce que lesdits moyens pour mettre à disposition les informations d'alerte comportent des moyens d'analyse de l'indicateur d'alerte (59) contenu dans chaque évènement contenant l'identifiant de la première entité associée au code d'accès d'urgence, et les moyens pour mettre à disposition les informations d'alerte sont adaptés pour mettre à disposition la ou chaque information contenue dans l'évènement, si l'analyse de l'indicateur d'alerte montre que la ou chaque information est une information d'alerte.
3. Système de gestion d'informations selon la revendication 1, caractérisé
en ce qu'il comporte des moyens pour intégrer dans chaque donnée élémentaire correspondant à un évènement un identifiant d'une seconde entité ayant engendrée ladite information.
en ce qu'il comporte des moyens pour intégrer dans chaque donnée élémentaire correspondant à un évènement un identifiant d'une seconde entité ayant engendrée ladite information.
4. Système de gestion d'informations selon la revendication 1, caractérisé
en ce que lesdits moyens pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité comportant une base de données (49) établissant une correspondance entre chaque code d'accès d'urgence et un identifiant d'une première entité.
en ce que lesdits moyens pour associer un code d'accès d'urgence, aux informations d'alerte concernant une même première entité comportant une base de données (49) établissant une correspondance entre chaque code d'accès d'urgence et un identifiant d'une première entité.
5. Système de gestion d'informations selon l'une quelconque des revendications 1 à 4, caractérisé en qu'il comporte des moyens de génération aléatoire d'un code d'accès d'urgence pour chaque nouvel identifiant d'une première entité.
6. Procédé de gestion d'informations, chaque information concernant une première entité dans un système comprenant:
- au moins une base de données (48) pour le stockage:
= desdites informations (52);
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité;
- au moins un poste d'interrogation (36) comprenant des moyens d'accès à la ou chaque base de données (48) pour la consultation desdites informations, et - des moyens pour définir des informations d'alerte parmi lesdites informations, et dans lequel un code d'accès d'urgence est associé aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité, caractérisé en ce que le procédé comprend: une étape d'entrée depuis lesdits moyens d'accès, d'un code d'accès d'urgence, et, lors de l'entrée dudit code d'accès d'urgence associé à l'identifiant d'une première entité, une étape de mise à disposition des informations d'alerte concernant la première entité
associée au code d'accès d'urgence, sans que l'identifiant de la première entité
ne soit mis à disposition;
- une étape de création d'au moins un évènement regroupant, de manière indissociable, dans une même donnée élémentaire (50) lesdits éléments de:
= la ou chaque information (52) concernant la première entité;
= l'identifiant (54) de la première entité; et = l'identifiant (56) de la seconde entité, - une étape de validation dudit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- une étape de stockage définitif du contenu de chaque évènement validé, en tant que donnée élémentaire dans la ou chaque base de données (48), caractérisé en ce que l'accès à une information comprise dans une donnée élémentaire depuis un poste utilisateur (12) n'est permis que par la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant l'information.
- au moins une base de données (48) pour le stockage:
= desdites informations (52);
= d'un identifiant de la première entité concernée par chaque information, chaque information étant associée à l'identifiant de la première entité;
- au moins un poste d'interrogation (36) comprenant des moyens d'accès à la ou chaque base de données (48) pour la consultation desdites informations, et - des moyens pour définir des informations d'alerte parmi lesdites informations, et dans lequel un code d'accès d'urgence est associé aux informations d'alerte concernant une même première entité, le code d'accès d'urgence étant différent de l'identifiant de la première entité, caractérisé en ce que le procédé comprend: une étape d'entrée depuis lesdits moyens d'accès, d'un code d'accès d'urgence, et, lors de l'entrée dudit code d'accès d'urgence associé à l'identifiant d'une première entité, une étape de mise à disposition des informations d'alerte concernant la première entité
associée au code d'accès d'urgence, sans que l'identifiant de la première entité
ne soit mis à disposition;
- une étape de création d'au moins un évènement regroupant, de manière indissociable, dans une même donnée élémentaire (50) lesdits éléments de:
= la ou chaque information (52) concernant la première entité;
= l'identifiant (54) de la première entité; et = l'identifiant (56) de la seconde entité, - une étape de validation dudit évènement par ladite seconde entité de telle sorte que lesdits éléments constituant l'évènement, regroupés de manière indissociable, ne sont plus modifiables et l'évènement peut seulement être complété par l'ajout d'informations supplémentaires constituant de nouveaux éléments de l'évènement;
- une étape de stockage définitif du contenu de chaque évènement validé, en tant que donnée élémentaire dans la ou chaque base de données (48), caractérisé en ce que l'accès à une information comprise dans une donnée élémentaire depuis un poste utilisateur (12) n'est permis que par la première et la seconde entités, et tel qu'habilité par la première et la seconde entités, ladite habilitation étant comprise dans la donnée élémentaire contenant l'information.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR02/07499 | 2002-06-18 | ||
| FR0207499A FR2841073B1 (fr) | 2002-06-18 | 2002-06-18 | Systeme de gestion d'informations pour situation d'urgence |
| PCT/FR2003/001665 WO2003107150A1 (fr) | 2002-06-18 | 2003-06-03 | Systeme de gestion d'informations pour situation d'urgence |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2489317A1 CA2489317A1 (fr) | 2003-12-24 |
| CA2489317C true CA2489317C (fr) | 2009-04-14 |
Family
ID=29595353
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002489317A Expired - Fee Related CA2489317C (fr) | 2002-06-18 | 2003-06-03 | Systeme de gestion d'informations pour situation d'urgence |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US7587384B2 (fr) |
| EP (1) | EP1530751A1 (fr) |
| CN (1) | CN100377023C (fr) |
| AU (1) | AU2003251109B2 (fr) |
| CA (1) | CA2489317C (fr) |
| FR (1) | FR2841073B1 (fr) |
| IL (1) | IL165607A0 (fr) |
| MX (1) | MXPA04012499A (fr) |
| WO (1) | WO2003107150A1 (fr) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7779456B2 (en) * | 2005-04-27 | 2010-08-17 | Gary M Dennis | System and method for enhanced protection and control over the use of identity |
| US8281370B2 (en) * | 2006-11-27 | 2012-10-02 | Therap Services LLP | Managing secure sharing of private information across security domains |
| US10586290B2 (en) * | 2012-11-13 | 2020-03-10 | Therap Services, Llc | Integrated HIPAA-compliant computer security system for authorizing, documenting, verifying, billing and adjudicating long term services and supports, including individual budgeting |
| US9619616B2 (en) | 2007-07-03 | 2017-04-11 | Eingot Llc | Records access and management |
| US8600776B2 (en) | 2007-07-03 | 2013-12-03 | Eingot Llc | Records access and management |
| US10231077B2 (en) | 2007-07-03 | 2019-03-12 | Eingot Llc | Records access and management |
| TR201902868T4 (tr) | 2011-02-01 | 2019-03-21 | Koninklijke Philips Nv | Acil durumlarda kişisel sağlık kayıtlarına güvenli erişim. |
| EP3767896A1 (fr) | 2014-08-12 | 2021-01-20 | Eingot LLC | Environnement sans apport d'information, basé sur un moteur de réseautage social |
| US10601960B2 (en) | 2018-02-14 | 2020-03-24 | Eingot Llc | Zero-knowledge environment based networking engine |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2704336A1 (fr) * | 1993-04-22 | 1994-10-28 | Zemmour Jean Claude | Serveur d'informations médicales pour tout service d'urgence concernant des sujets à risque en cas d'accident. |
| US5924074A (en) * | 1996-09-27 | 1999-07-13 | Azron Incorporated | Electronic medical records system |
| US6775670B2 (en) * | 1998-05-29 | 2004-08-10 | Luc Bessette | Method and apparatus for the management of data files |
| US6073106A (en) * | 1998-10-30 | 2000-06-06 | Nehdc, Inc. | Method of managing and controlling access to personal information |
| WO2001055949A1 (fr) * | 2000-01-28 | 2001-08-02 | Medlook Nv | Systeme et procede de gestion de fichiers medicaux en ligne |
| US6463417B1 (en) * | 2000-02-22 | 2002-10-08 | Carekey.Com, Inc. | Method and system for distributing health information |
| WO2001069514A2 (fr) * | 2000-03-15 | 2001-09-20 | Emedicalfiles, Inc. | Systeme de gestion d'informations medicales heberge par le web |
| JP2002024386A (ja) * | 2000-07-04 | 2002-01-25 | Sony Corp | 情報通信システム |
| AU2001276991A1 (en) * | 2000-07-20 | 2002-02-05 | J. Alexander Marchosky | Patient-controlled automated medical record, diagnosis, and treatment system andmethod |
| US20020082870A1 (en) * | 2000-11-20 | 2002-06-27 | Mark Penny | System and method for processing patient medical information |
| US20030074564A1 (en) * | 2001-10-11 | 2003-04-17 | Peterson Robert L. | Encryption system for allowing immediate universal access to medical records while maintaining complete patient control over privacy |
-
2002
- 2002-06-18 FR FR0207499A patent/FR2841073B1/fr not_active Expired - Fee Related
-
2003
- 2003-06-03 WO PCT/FR2003/001665 patent/WO2003107150A1/fr not_active Application Discontinuation
- 2003-06-03 AU AU2003251109A patent/AU2003251109B2/en not_active Ceased
- 2003-06-03 CN CNB038141000A patent/CN100377023C/zh not_active Expired - Fee Related
- 2003-06-03 EP EP03759996A patent/EP1530751A1/fr not_active Withdrawn
- 2003-06-03 IL IL16560703A patent/IL165607A0/xx not_active IP Right Cessation
- 2003-06-03 MX MXPA04012499A patent/MXPA04012499A/es active IP Right Grant
- 2003-06-03 CA CA002489317A patent/CA2489317C/fr not_active Expired - Fee Related
- 2003-06-09 US US10/456,561 patent/US7587384B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| AU2003251109A1 (en) | 2003-12-31 |
| CN100377023C (zh) | 2008-03-26 |
| US20030233342A1 (en) | 2003-12-18 |
| CN1662866A (zh) | 2005-08-31 |
| US7587384B2 (en) | 2009-09-08 |
| AU2003251109B2 (en) | 2009-10-01 |
| WO2003107150A1 (fr) | 2003-12-24 |
| MXPA04012499A (es) | 2005-02-17 |
| FR2841073A1 (fr) | 2003-12-19 |
| EP1530751A1 (fr) | 2005-05-18 |
| CA2489317A1 (fr) | 2003-12-24 |
| IL165607A0 (en) | 2006-01-15 |
| FR2841073B1 (fr) | 2007-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8725699B2 (en) | Decision support response systems and methods | |
| US8977572B2 (en) | Systems and methods for patient-controlled, encrypted, consolidated medical records | |
| US7797546B2 (en) | Portable storage device for storing and accessing personal data | |
| EP1834268A2 (fr) | Serveur, procede et reseau d'intermediation pour la consultation et le referencement d'informations medicales | |
| EP1849118B1 (fr) | Système et procédé d'anonymisation de données personnelles sensibles et procédé d'obtention de telles données | |
| US20040111622A1 (en) | Method of and system for controlling access to personal information records | |
| WO2002059821A2 (fr) | Procede et appareil de localisation et d'echange d'informations cliniques | |
| US20190327311A1 (en) | Secure access to individual information | |
| CA2489317C (fr) | Systeme de gestion d'informations pour situation d'urgence | |
| EP1011223A1 (fr) | Procédé de création et gestion d'au moins une clé cryptographique et système pour sa mise en oeuvre | |
| KR101298548B1 (ko) | 개인용 치아 병력 관리 시스템 및 치아 병력 관리 방법 | |
| JP2023101763A (ja) | データ管理システムおよびデータ管理方法 | |
| JP2007179500A (ja) | 匿名化識別情報生成システム、及び、プログラム。 | |
| KR102354826B1 (ko) | 치과용 임상사진 관리 시스템 및 그 방법 | |
| CA2484160C (fr) | Systeme de gestion d'informations | |
| EP2733631A1 (fr) | Système pour la tracabilité automatique des dispositifs médicaux | |
| US20060178998A1 (en) | Personal electronic web health log | |
| CA2484156C (fr) | Systeme de gestion d'informations integrees dans un protocole | |
| JP7187283B2 (ja) | データ管理システム | |
| FR2995431A1 (fr) | Procede d'acces et de partage d'un dossier medical | |
| WO2006056667A1 (fr) | Certificat de cle publique pour le transport d'information confidentielle | |
| CA2709919A1 (fr) | Systeme de connexion securise permettant a un usager l'utilisation des services par internet d'un centre de services et methodes correspondantes | |
| JP2005050278A (ja) | 情報管理システム及び情報管理プログラム | |
| FR2820529A1 (fr) | Systeme et procede de base de donnees virtuelle distribuee et securisee |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20150603 |