WO2003107150A1 - Systeme de gestion d'informations pour situation d'urgence - Google Patents

Systeme de gestion d'informations pour situation d'urgence Download PDF

Info

Publication number
WO2003107150A1
WO2003107150A1 PCT/FR2003/001665 FR0301665W WO03107150A1 WO 2003107150 A1 WO2003107150 A1 WO 2003107150A1 FR 0301665 W FR0301665 W FR 0301665W WO 03107150 A1 WO03107150 A1 WO 03107150A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
entity
identifier
alert
access code
Prior art date
Application number
PCT/FR2003/001665
Other languages
English (en)
Inventor
Dominique Vadrot
Martine Verdoux
Original Assignee
Patient On Line
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Patient On Line filed Critical Patient On Line
Priority to IL16560703A priority Critical patent/IL165607A0/xx
Priority to AU2003251109A priority patent/AU2003251109B2/en
Priority to MXPA04012499A priority patent/MXPA04012499A/es
Priority to CA002489317A priority patent/CA2489317C/fr
Priority to EP03759996A priority patent/EP1530751A1/fr
Publication of WO2003107150A1 publication Critical patent/WO2003107150A1/fr

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

Definitions

  • the present invention relates to an information management system, and in particular to medical information management, each information item relating to a first entity, the system comprising:
  • At least one interrogation station comprising means of access to the or each database for consulting said information.
  • This information may for example be medical information concerning a patient.
  • This medical information is generated by one or more medical practitioners subject to ethical obligations. In particular, these ethical obligations require practitioners to respect professional secrecy, so that practitioners are prohibited from making this information accessible without the authorization of the patient concerned and the patient must be able to access information concerning him.
  • the object of the invention is an information management system making it possible to make useful information accessible, even when the person concerned by his information is not aware, while ensuring compliance with the ethical obligations.
  • the subject of the invention is an information management system of the aforementioned type, characterized in that it comprises:
  • said access means comprise means for entering the emergency access code and means for, upon entry of the emergency access code associated with the identifier of a first entity, make available the alert information concerning the first entity associated with the emergency access code, without the identifier of the first entity being made available.
  • the information management system includes one or more of the following characteristics:
  • • means for integrating into the elementary data corresponding to the event containing said information, the alert indicator representative of the definition of the information; and • means for integrating into the elementary data corresponding to the event containing said information, the alert indicator, and said means for making available the alert information include means for analyzing the indicator d alert contained in each event containing the identifier of the first entity associated with the emergency access code, and the means for making available the alert information are suitable for making available the or each item of information contained in the event, if analysis of the alert indicator shows that the or each item of information is alert information;
  • the system comprises means for integrating into each elementary data item corresponding to an event an identifier of a second entity having generated said information;
  • said means for associating an emergency access code with alert information concerning the same first entity comprising a database establishing a correspondence between each emergency access code and an identifier of a first entity;
  • the system includes means for random generation of an emergency access code for each new identifier of a first entity.
  • the invention also relates to a method for managing information, each information item relating to a first entity in a system comprising:
  • At least one interrogation station comprising means of access to the or each database for consulting said information
  • FIG. 1 is a schematic view of an information management system according to the invention
  • FIG. 2 is a schematic view illustrating the format of an elementary data used by the information management system of Figure 1;
  • FIG. 3 is a flow diagram of the main algorithm implemented in the system.
  • FIG. 4 is a flowchart of the emergency consultation algorithm of the system according to the invention.
  • the information management system 10 is illustrated diagrammatically in FIG. 1. This comprises, on the one hand, a set of user stations designated by the general reference 12, each connected to a collective network 14 of transmission of information such as the Internet network and, on the other hand, a center 16 for storage and management of information.
  • the information management system 10 is intended, in the example considered, for the management of medical information relating to identified patients. This information is generated by medical practitioners such as doctors, radiologists or biologists in charge of an analysis laboratory.
  • the management system is adapted to allow the final storage of information in the storage center 16, without this information being able to be subsequently modified.
  • it is consents, associated with this information, at least one identifier of the patient concerned, as well as an identifier of the practitioner who generated the information.
  • the system makes it possible to give access to information stored from the patient identifier only to the patient concerned and to the practitioner who generated the information, as well as, possibly, after agreement of the patient, to other practitioners.
  • the system allows access to certain stored information about a patient by people with an emergency access code. The information is then made available in a reduced number, and without the identifier of the patient concerned by this information being made available.
  • Each entity involved in the system whether a patient or a practitioner, is equipped with or has access to a user station 12.
  • a first user station 12A equips the general practitioner's office and a user station 12B equips a patient's home.
  • a medical imaging laboratory is equipped with a user station 12C.
  • Each user station 12A, 12B, 12C comprises a microcomputer 20 equipped with a suitable Internet browser. It is connected by an interface adapted to the network 14.
  • Each user station includes means 22 for collecting input data such as a keyboard or a data conversion module. From the keyboard, medical information can be entered, an identifier of a patient such as his name, as well as an identifier of the practitioner who produced the information.
  • Each user station 12 is adapted to implement, from information processing means 24, software means of access to the center 16 for storage and management of information.
  • each user station 12A, 12B, 12C comprises software means for creating an event grouping inseparably in the same elementary data, information collected concerning a patient, an identifier of the patient and an identifier of the practitioner.
  • These means of creating an event are advantageously downloaded from the center 16 and for example consist of a page from the center 16 and for example consist of a page in HTML format (Hyper Text Markup Language) forming a dialogue interface.
  • HTML format Hyper Text Markup Language
  • Some of these user stations comprise, in addition to the microcomputer 20, an interface 30 for connecting the microcomputer to an installation 32 for medical imaging or for collecting medical information capable of producing digital images or information in a predefined format such as the DICOM Hprim HL7 format.
  • this digital image or information includes an identifier of the patient concerned.
  • the user station also implements a software module 34 capable of analyzing the digital image produced by the installation 32 and of extracting therefrom an identifier of the patient concerned.
  • the system includes interrogation stations 36 connected to the center 16 for storing and managing information through the network 14.
  • Each interrogation station 36 is constituted by any microcomputer 20 equipped with a adapted internet browser. These interrogation stations do not have to be identified initially by the information storage and management center 16.
  • Each interrogation station 36 includes means for entering an emergency access code, such as a keyboard 37, or a smart card reader 38, as well as a device for providing information. such as a screen or printer 39.
  • the information storage and management center 16 includes a set of servers 40 for managing access to the center 16.
  • This set of servers 40 notably includes an authentication server 40A suitable, as known per se, for identifying the origin of a request addressed to the server center. It further comprises one or more servers 40B suitable for managing the exchange of executable files and HTML pages according to the HTTP protocol between the storage and management center 16 and the user stations.
  • the or each server 40B comprises a software module suitable for downloading in each user station requesting HTML pages constituting user interfaces allowing access to the stored information, as well as the saving of new information.
  • This set of servers 40 is connected di- directly to network 14 through a first security barrier 42 (firewalls).
  • the set of access management servers 40 is further connected to a set of event management servers 44 through a second security barrier 46 (firewalls).
  • the set of servers 44 is suitable for implementing a software module 44A for transcribing digital images received in different formats, in particular in DICOM format, into the same format, for example the XML format.
  • the set of servers 44 is further capable of implementing a software module 44B for managing the storage of events in a storage unit 48 and for managing access to these events.
  • This storage unit 48 is intended for the permanent storage of one or more databases, the elementary data of which consist of events defined by the user stations and comprising in particular the information to be saved.
  • an additional storage unit 49 is connected to the set of servers 44.
  • This storage unit is intended for the permanent storage of a database in which is stored, for each identifier of a patient affected by information, an associated emergency access code.
  • the emergency access code is randomly defined by the management module 44B for each new patient managed by the system.
  • the code is different from the patient's identifier such as his name.
  • the emergency access code is written on a card given to the patient.
  • This card also contains the IP address of the information storage and management center 16.
  • the emergency access code is stored in a memory card which can be read in a card reader of a computer.
  • This card also carries the IP address of the center 16.
  • FIG. 2 is shown schematically the structure of an elementary data item stored in the database 48. This corresponds to an event.
  • Each event includes at least one piece of information proper 52.
  • This information is made up, for example, of digital data corresponding to the result of an analysis or of a text corresponding to the opinion of a practitioner on the clinical state of a patient.
  • Information can also consist of a file linked to the event such as a document in HTML format or an image file in DIBCOM format or an attachment in an office format.
  • each event includes an identifier 54 of a first entity. This identifier designates the patient concerned by the information 52. Likewise, the event includes an identifier 56 of a second entity. This identifier designates the practitioner who produced the information.
  • each event includes a list 58 of the identifiers of additional entities that can have access to the information.
  • each event includes an alert indicator consisting of a Boulean indicator indicating in its first (valid) state that the information contained in the event constitutes alert information that can be communicated in the event of an emergency, and in its second state (not valid), that the information contained in the event must not be communicated in an emergency.
  • alert indicator consisting of a Boulean indicator indicating in its first (valid) state that the information contained in the event constitutes alert information that can be communicated in the event of an emergency, and in its second state (not valid), that the information contained in the event must not be communicated in an emergency.
  • the algorithm of Figure 3 is then implemented.
  • the user station 12 can consist, for the simplest operations, only of a microcomputer connected to the Internet network to using a browser of any suitable type.
  • the set of servers 40 of the storage center 16 After connection of the user station, in step 100, the set of servers 40 of the storage center 16 returns a dialog interface in HTML format to the user station 12, in step 102.
  • the center 16 proceeds through the dialogue interface implemented by the user station to authenticate the user. Depending on the identifier entered by the user, checks of the actions authorized for this are carried out, in step 106, and a check of the user's access rights is carried out, in step 108 .
  • the user is then free to carry out several operations according to the actions authorized to him. It proceeds, from the interface made available to it, in step 110, to the choice of an operation to be carried out.
  • the practitioner user can also modify the rights of access to the information stored by authorizing a new practitioner to access information concerning a patient.
  • the branch 110C of the organization chart is then implemented.
  • the user can also take cognizance only of information stored in the storage center by implementing branch 110E of the flowchart.
  • the algorithm differs according to whether the medical information which the practitioner wishes to enter can be automatically associated with a patient constituting a first entity, or whether the connection to the patient must be carried out manually . This choice is made in step 111.
  • the information is entered by the practitioner, for example on the keyboard, in step 112.
  • An identification of the patient concerned is entered, in step 114, in particular by selecting a patient identifier from a list of patient identifiers or by typing on the keyboard.
  • step 122 the information containing the identifier of the patient concerned is entered, in step 122, for example through the interface 30.
  • This information is for example made up of a medical image in DICOM format.
  • the software module 36 performs an analysis of the image and a recognition of the patient's identifier in the transmitted image.
  • step 130 the practitioner defines the list of identifiers of the additional entities authorized to access the information contained in the event. This step consists in defining the list 58 of the identifiers of the practitioners authorized to access.
  • step 131 the practitioner defines the alert indicator by specifying whether or not the information contained in the event can be made accessible in the event of an emergency according to a procedure described in the following description.
  • step 132 the practitioner validates, by entering a signature code, all of the elements constituting the event, namely the medical information proper, the identifier of the patient concerned, his own identifier .the list of identifiers of additional entities authorized to access, and the alert indicator.
  • the elements constituting the event can no longer be modified and the event can only be completed.
  • the user station 12 ensures the creation of an elementary data item taking up the different elements of the event.
  • This elementary data is encrypted by any suitable method and is addressed by the dialogue interface to the center 16 for storing and managing information.
  • the elementary data is processed by the event management servers 44, in step 136. If the elementary data contains digital images in formats different from the XML format, these images are automatically converted to XML format, in step 138, and the elementary data is supplemented by image data in XML format in addition to the image data in another format.
  • the elementary data thus reprocessed is permanently saved in the storage unit 48, in step 140.
  • step 110B When the user wishes to complete an event by adding additional information, the steps of the branch 110B are implemented after step 110.
  • step 150 the event to be completed is selected.
  • the elementary data corresponding to the selected event is transmitted by the center 16 to the user station, in step 152.
  • the elementary data is only transmitted if the identifier of the user is included in the event in question, either the patient concerned, the practitioner providing the information or an additional practitioner whose identifier appears in list 58.
  • the additional information is entered in step 154, either manually from the keyboard or by resuming an already existing file. In the latter case, the additional information constitutes a new attached file.
  • step 156 the user validates the addition of the information by entering a signature code.
  • the additional information is added in step 158 to form new elementary data constituting the modified event.
  • the date and the identifier of the user who added the information, as well as a link to the information are added to the basic data to track changes.
  • the new elementary data thus constituted is then processed in accordance with steps 136 and following.
  • the event whose accesses are at complete is selected in step 200.
  • the elementary data corresponding to the selected event is then transmitted to the user station in step 202.
  • the elementary data is only transmitted if the identifier of the user is included in the event in question, whether it be the patient concerned, the practitioner providing the information or an additional practitioner whose identifier appears in the list 58.
  • step 204 the user selects or enters one or more additional identifiers of users authorized to access the information, then validates, in step 206, the new identifiers.
  • the additional identifiers are added to the elementary data constituting the event in step 208.
  • the date and the identifier of the user who added the new identifiers, as well as a link with the new identifiers are added in the elementary data to ensure a follow-up of the modifications. Steps 136 and following are then again implemented.
  • step 110D of the algorithm is implemented.
  • step 210 the event whose alert indicator is to be modified is selected.
  • the elementary data corresponding to the selected event is transmitted to the user station 12 in step 212, provided that the user identifier is included in the event in question because it is the patient concerned, the practitioner providing the information or an additional practitioner whose identifier appears in list 58.
  • step 214 the user changes the state of the alert indicator, for example by validation on the screen of a predefined area. If the practitioner wishes to make this information accessible in an emergency, he ensures that the information itself does not contain data allowing the patient to be identified as his name. The modified event is then validated then in step 216.
  • the new value of the alert indicator is added to the elementary data constituting the event in step 218.
  • the date and the identifier of the user who modified the alert indicator are added to the basic data to follow up on the modifications.
  • Steps 136 and following are then again implemented.
  • the steps of the branch 110E are implemented.
  • step 250 a request is formulated by the user from the user station. This is taken into account by the event management servers 44, in step 252. Depending on the access rights contained in the event in question in the request, and according to the rights of the user, the content of the elementary data is transmitted from the storage center 16 to the user station 12, in step 254.
  • the elementary data is only transmitted if the identifier of the user is included in the event at issue in the request, ie whether it is the patient concerned, the practitioner at the origin information or an additional practitioner whose identifier appears in list 58.
  • the information is then made available to the user in step 256, for example by display, or else by saving the content of the elementary data on the hard disk of the user station.
  • an access log is updated in the center 16 to record the user identifier, the nature of the information made available, the access date provided by the system and any other useful information.
  • the patient whose information is stored in the system, carries the card on which appears the IP address of the center 16 for managing and storing information on the network 14, as well as the emergency access code associated with the patient.
  • the algorithm of FIG. 4 is implemented.
  • the patient can provide any interlocutor with the card he is carrying to enable his interlocutor to '' access certain alert information that the patient has previously selected by placing or placing the alert indicators associated with this information in a valid predetermined state.
  • the emergency services can seize the card carried by the patient and carry out themselves the collection of emergency information.
  • the emergency service connects to the information storage and management center 16 using the IP address mentioned on the card carried by the patient.
  • This connection can be made from any computer connected to the network 14 and having a suitable internet browser. This computer then forms an interrogation station 36.
  • the center 16 After connection, the center 16 ensures in step 404 the loading into the interrogation station 36 of a user interface.
  • the emergency service is invited to enter the patient's own emergency access code. This emergency access code being completely independent of the patient identifier, the patient identifier is not necessary for entering the alert code.
  • the software module 44B for managing access to stored events determines in step 408 whether or not the emergency access code is associated with a known identifier, by interrogating the database hosted in the storage unit 49 .
  • step 406 is again implemented.
  • the information storage and management center 16 determines in step 410 the identifier of the patient concerned.
  • the software module 44B for managing events searches, among the stored events, for events containing the identifier of the first entity. Among these events found, it analyzes in step 414 the alert indicator associated with each event. It selects among the events those whose alert indicators are in a valid state indicating that the information contained in the event can be communicated in the event of an emergency.
  • step 416 the center 16 ensures the transmission, without encryption of the information contained in each of the only events of the base 48 whose alert indicator is valid, and whose identifier of the first entity is the identifier associated with the alert access code in the base 49.
  • the information transmitted is communicated without the identifier of the first entity being transmitted.
  • step 418 the information transmitted is made available to the emergency service, for example by displaying this information on the screen of the interrogation station 36.
  • step 420 the access log is set to update in the center 16 by recording the nature of the information made available, the date of access provided by the system or any other useful information.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Theoretical Computer Science (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Bioethics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Alarm Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ce système comprend :- au moins une base de données (48) pour le stockage : desdites informations ; d'un identifiant de la première entité concernée par chaque in-formation ; et- au moins un poste d'interrogation (36) comprenant des moyens d'accès à; la base de données (48),- des moyens pour définir des informations d'alerte parmi les informations ; - des moyens (49) pour associer un code d'accès d'urgence aux informations d'alerte.Les moyens d'accès comportent des moyens d'entrée du code d'accès d'urgence et des moyens pour mettre à disposition les informations d'alerte concernant une première entité sans que l'identifiant de la première entité ne soit mis à disposition.

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 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.
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éontologiques. 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 particulier, 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. A cet effet, l'invention a pour objet un système de gestion d'informations du type précité, 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.
Suivant des modes particuliers de réalisation, le système de gestion d'informations comporte l'une ou plusieurs des caractéristiques suivantes :
- il comprend :
• des moyens pour créer au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire :
• la ou chaque information concernant la première entité ; et
• l'identifiant de la première entité ; et
• des moyens de stockage définitif du contenu du ou de chaque événement, chacun en tant que donnée élémentaire dans la ou chaque base de données ; - 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 correspondant à 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 donnée élémentaire correspondant à un événement un identifiant d'une seconde 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 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'informations, 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 qu'il comprend l'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é, la 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. 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 dessins, sur lesquels :
- la figure 1 est une vue schématique d'un système de gestion d'informations 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 œuvre 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 consente, 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 à partir de l'identifiant du patient seulement au patient concerné et au praticien 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 microordinateur 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 notamment 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, depuis des moyens de traitement d'informations 24, des moyens logiciels d'accè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 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'informations 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 à extraire 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 stockage 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 ensemble 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 utilisateurs permettant l'accès aux informations stockées, ainsi que la sauvegarde 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 (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 serveurs 44 est propre à mettre en œuvre un module logiciel 44A de transcription 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 permanente 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émorisation 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 correspond à 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ériques 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 document 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 premiè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 :
- un titre ;
- 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 œuvre. 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'aide d'un navigateur de tout type adapté. Après connexion du poste d'utilisateur, à 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 œ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 110A 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 110B 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 informations concernant un patient. La branche 110C de l'organigramme est alors mise en œuvre.
Lorsque le praticien souhaite modifier l'indicateur d'alerte d'un événement, la branche 110D de l'algorithme est mise en œuvre.
L'utilisateur peut également prendre seulement connaissance d'informations stockées dans le centre de stockage par mise en œuvre 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 souhaite 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'identifiants 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- 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 procè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 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 description.
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'interface de dialogue au centre 16 de stockage et de gestion des informations. 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 œuvre 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 praticien à l'origine de l'information ou d'un praticien supplémentaire dont l'identifiant 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 attaché.
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 à corn- 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 plusieurs identifiants supplémentaires d'utilisateurs habilités à accéder à l'information 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 œuvre.
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 à disposition cette information, la branche 110D de l'algorithme est mise en œuvre. 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électionné 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 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. 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. 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 œ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 110E sont mises en œuvre.
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'utilisateur, 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 œuvre. 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 indicateurs d'alerte associés à ces informations dans un état valide prédéterminé.
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 mentionné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 œuvre.
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 recherche, 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 ê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. 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. 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 informations 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é à intervenir sur le système et même si le patient est inconscient.

Claims

REVENDICATIONS 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 : • 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é 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.
2. Système de gestion d'informations selon la revendication 1 , carac- térisé en ce qu'il comprend :
- 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) :
• la ou chaque information (52) concernant la première entité ; et
• l'identifiant (54) de la première entité ; et - 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).
3. Système de gestion d'informations, 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 correspon- dant à 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 à disposi- tion 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.
4. Système de gestion d'informations selon l'une quelconque des revendications précédentes, 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.
5. Système de gestion d'informations selon l'une quelconque des revendications, 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é.
6. Système de gestion d'informations selon l'une quelconque des revendications, caractérisé en qu'il comporte des moyens de génération aléa- toire d'un code d'accès d'urgence pour chaque nouvel identifiant d'une première entité.
7. 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 in- formations, 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 qu'il comprend l'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é, la 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.
PCT/FR2003/001665 2002-06-18 2003-06-03 Systeme de gestion d'informations pour situation d'urgence WO2003107150A1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
IL16560703A IL165607A0 (en) 2002-06-18 2003-06-03 Data management system for emergency situation
AU2003251109A AU2003251109B2 (en) 2002-06-18 2003-06-03 Data management system for emergency situation
MXPA04012499A MXPA04012499A (es) 2002-06-18 2003-06-03 Sistema de manejo de informacion para situacion de urgencia.
CA002489317A CA2489317C (fr) 2002-06-18 2003-06-03 Systeme de gestion d'informations pour situation d'urgence
EP03759996A EP1530751A1 (fr) 2002-06-18 2003-06-03 Systeme de gestion d'informations pour situation d'urgence

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2003107150A1 true WO2003107150A1 (fr) 2003-12-24

Family

ID=29595353

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/001665 WO2003107150A1 (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)

* Cited by examiner, † Cited by third party
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
US10231077B2 (en) 2007-07-03 2019-03-12 Eingot Llc Records access and management
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
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.
US9686356B2 (en) 2014-08-12 2017-06-20 Eingot Llc Zero-knowledge environment based social networking engine
US10601960B2 (en) 2018-02-14 2020-03-24 Eingot Llc Zero-knowledge environment based networking engine

Citations (5)

* Cited by examiner, † Cited by third party
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.
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
WO2001063538A1 (fr) * 2000-02-22 2001-08-30 Carekey.Com, Inc. Procede et systeme de transmission d'informations medicales
WO2001069514A2 (fr) * 2000-03-15 2001-09-20 Emedicalfiles, Inc. Systeme de gestion d'informations medicales heberge par le web

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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

Patent Citations (5)

* Cited by examiner, † Cited by third party
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.
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
WO2001063538A1 (fr) * 2000-02-22 2001-08-30 Carekey.Com, Inc. Procede et systeme de transmission d'informations medicales
WO2001069514A2 (fr) * 2000-03-15 2001-09-20 Emedicalfiles, Inc. Systeme de gestion d'informations medicales heberge par le web

Also Published As

Publication number Publication date
EP1530751A1 (fr) 2005-05-18
AU2003251109B2 (en) 2009-10-01
CA2489317C (fr) 2009-04-14
US7587384B2 (en) 2009-09-08
CN1662866A (zh) 2005-08-31
MXPA04012499A (es) 2005-02-17
FR2841073A1 (fr) 2003-12-19
AU2003251109A1 (en) 2003-12-31
CA2489317A1 (fr) 2003-12-24
US20030233342A1 (en) 2003-12-18
FR2841073B1 (fr) 2007-03-30
IL165607A0 (en) 2006-01-15
CN100377023C (zh) 2008-03-26

Similar Documents

Publication Publication Date Title
US8725699B2 (en) Decision support response systems and methods
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
US20050055560A1 (en) Portable storage device for storing and accessing personal data
WO2002059821A2 (fr) Procede et appareil de localisation et d'echange d'informations cliniques
EP1011223A1 (fr) Procédé de création et gestion d'au moins une clé cryptographique et système pour sa mise en oeuvre
CA2489317C (fr) Systeme de gestion d'informations pour situation d'urgence
US7085927B1 (en) Secure data report preparation and delivery
WO2020165531A1 (fr) Systèmes informatiques et procédés d'assistance au remplissage de formulaires en ligne
CA2484160C (fr) Systeme de gestion d'informations
JP7187283B2 (ja) データ管理システム
EP2733631A1 (fr) Système pour la tracabilité automatique des dispositifs médicaux
CA2484156C (fr) Systeme de gestion d'informations integrees dans un protocole
US20060178998A1 (en) Personal electronic web health log
Eichelberg et al. A distributed patient identification protocol based on control numbers with semantic annotation
WO2006056667A1 (fr) Certificat de cle publique pour le transport d'information confidentielle
Edwards et al. Mixed Method Investigation of Parental Social Licence for Operational Data Linkage for Service Intervention, 2020-2022
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
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2003759996

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 165607

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 2003251109

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2489317

Country of ref document: CA

Ref document number: PA/a/2004/012499

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 2823/CHENP/2004

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 20038141000

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003759996

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP