EP1500027A1 - Systeme de gestion d informations integrees dans un protocol e - Google Patents

Systeme de gestion d informations integrees dans un protocol e

Info

Publication number
EP1500027A1
EP1500027A1 EP03740681A EP03740681A EP1500027A1 EP 1500027 A1 EP1500027 A1 EP 1500027A1 EP 03740681 A EP03740681 A EP 03740681A EP 03740681 A EP03740681 A EP 03740681A EP 1500027 A1 EP1500027 A1 EP 1500027A1
Authority
EP
European Patent Office
Prior art keywords
information
event
entity
protocol
identifier
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.)
Withdrawn
Application number
EP03740681A
Other languages
German (de)
English (en)
Inventor
Dominique Vadrot
Martine Verdoux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Patient On Line
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
Publication of EP1500027A1 publication Critical patent/EP1500027A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • 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
    • 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

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 and having been generated by a second entity, the system comprising:
  • At least one user station comprising means for collecting at least one item of information relating to the first entity.
  • This information can 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 information management systems currently known implement relational databases in which are stored, on the one hand, all the information to be managed by the system, and, on the other hand, patient identifiers concerned and / or the practitioner who generated this information.
  • relational databases the database is organized according to the relationships that exist between elementary data.
  • information concerning a patient, the identity of this patient or the identity of the practitioner who generated this information is considered as elementary data and links translating the existing relationships between the elementary data are stored in the database.
  • This type of database is convenient since it makes it possible to modify the links existing between the elementary data, which makes it possible to apply quer new treatments to existing elements. This reduces the redundancy of the elementary data contained in the database.
  • This protocol specifies a sequence of operations to be carried out according to the results obtained during previous operations.
  • the subsequent operations to be carried out are defined according to criteria specific to the protocol, these criteria relating to the results of the previous operations.
  • the object of the invention is to propose a device enabling practitioners to easily and reliably implement complex protocols, and in particular medical protocols.
  • the subject of the invention is an information management system of the aforementioned type, characterized in that it comprises:
  • the information management system includes one or more of the following characteristics:
  • Said means of automatic creation, according to the specifications of said protocol, of at least one event corresponding to a subsequent operation to be carried out are suitable for the creation of an incomplete event
  • the system includes means for completing the or each incomplete event , by at least a second entity from a user station, by adding at least one piece of information in the or each event before its final storage;
  • It includes means for automatic search among the elementary data stored in the or each database, elementary data containing information to be analyzed by the analysis means according to the criteria specific to said protocol;
  • - It includes means for archiving events used during the implementation of said protocol; and - Said means for automatically creating at least one event include means for automatically adding in said event the identifier of the first entity concerned by the or each item of information.
  • the invention also relates to a method for managing information, each information item relating to a first entity and having been generated by a second entity, the system comprising at least one database for storing said information and at least one user station comprising means for collecting at least one item of information relating to the first entity, the method comprising a step of collecting, from a user station, at least one item of information relating to the first entity; characterized in that it comprises:
  • 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 according to the invention.
  • FIG. 4 is a schematic view of an alternative embodiment of the information management system according to the invention.
  • FIG. 5 is a flowchart of the management algorithm by protocol implemented in 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 and, on the other hand, a center 16 for storing and managing 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.
  • at least one identifier of the patient concerned is stored, associated with this information, as well as an identifier of the practitioner who generated the information.
  • the system makes it possible to give access to stored information only to the patient concerned and to the practitioner who generated the information, as well as, possibly, after the patient's agreement, to other practitioners.
  • Each entity involved in the system whether a patient or a practitioner, is equipped or has access to a user station 12.
  • a first user station 12A equips the office of a general practitioner and a user station 12B equips the home of a patient.
  • 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 12 includes software means for creating an event which inseparably groups together in the same elementary data, information collected concerning a patient, an identifier of the patient and an identifier of the practitioner.
  • event creation means are advantageously downloaded from the center 16 and for example consist of a page in HTML format (Hyper Text Markup Language) forming a dialogue interface.
  • 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 suitable for analyzing the digital image produced by the installation 32 and for extracting therefrom an identifier of the patient concerned.
  • 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 adapted, as known per se, to identify 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 directly connected to the 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 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.
  • Figure 2 is shown schematically the structure of an elementary data stored in the database 48. This corresponds to an event.
  • Each event includes at least information proper 52.
  • This information consists for example of digital data corresponding to the result of an analysis or of a text corresponding to a practitioner's opinion on the clinical state of a patient.
  • Information can also be constituted by a file attached to the event such as a document ment 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.
  • user For adding information to the storage center, supplementing pre-existing information with additional information, modifying access rights to information or consulting information, user connects from a user station 12 to the storage center 16.
  • the algorithm of Figure 3 is then implemented.
  • the user station can consist, for the simplest operations, only of a microcomputer connected to the Internet 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 on the actions authorized for this are carried out in step 106, and a check on the user's access rights is carried out in step 108 The user is then free to carry out several operations depending on 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. This can be the entry of new information into the storage center 16.
  • the branch 110A of the organization chart is then implemented.
  • 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.
  • Branch 11 OC of the organization chart is then implemented.
  • the user can also take cognizance only of information stored in the storage center by implementing branch 110D of the organization chart.
  • 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 performed 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 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 and the list of identifiers of additional entities authorized to access.
  • the elements constituting the event can no longer be modified and the event can only be completed.
  • step 134 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 this last 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 with the information are added in the elementary data to ensure a follow-up of the modifications.
  • the new elementary data thus constituted is then processed in accordance with steps 136 and following.
  • the event whose accesses are to be completed 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 user identifier is included in the event in question, whether it is the patient concerned, the practitioner providing the information or an additional practitioner whose identifier appears in the list 58.
  • 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 in 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 monitor changes. Steps 136 and following are then again implemented.
  • a request is formulated by the user from the user station. This is taken into account by the management servers of events 44, in step 252.
  • the content of the elementary data is transmitted from the storage center 16 at the user station 12, at 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 providing the 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.
  • step 258 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 information management system illustrated in FIG. 4 takes up the characteristics of the management system illustrated in FIG. 1.
  • the information storage and management center 16 includes an additional storage unit 402 in which a set of medical protocols is permanently stored.
  • Each protocol specifies a sequence of successive operations to be carried out by a practitioner in the case of the diagnosis and / or treatment of a patient, or in the case of an epidemiological study or a study on the effects of a treatment .
  • each protocol defines its own decision-making criteria relating to the information collected during operations earlier.
  • the subsequent operations of the protocol are chosen from a set of possible operations according to the criteria specific to the protocol.
  • the set of servers 44 for managing events, and more particularly the software module 44B for managing the storage of events is suitable for the implementation of a protocol management algorithm.
  • the protocol management algorithm is illustrated in Figure 5.
  • This algorithm is implemented over a long period of time corresponding to the entire duration of the protocol implementation.
  • the protocol can be implemented over a period ranging from one week to several months.
  • step 502 the user, namely a practitioner, selects a protocol to be applied from a user station.
  • the user uses a user interface downloaded from the storage and management center 16. This interface allows the selection of the protocol from among the protocols stored in the storage unit 402.
  • the following example concerns a diagnostic or treatment protocol for a patient.
  • Additional information such as the patient, on which the protocol is applied, is entered in step 502.
  • step 504 the software module 44B performs a search for existing events that can be exploited by the protocol. These existing events are sought in the storage unit 48 from the elementary data comprising the identifier of the first entity selected in step 502.
  • Each of the events that can be exploited is attached to the protocol, in step 506, so that the information that it contains is taken into account by the protocol.
  • step 508 the software module 44B performs an analysis of the information contained in the events associated with step 106. This analysis of the information is carried out by application of criteria specific to the selected protocol. In step 510, a test is carried out to determine whether the protocol is completed or not.
  • the software module 44B creates, in step 512, one or more events.
  • Each event created corresponds to a subsequent operation of the protocol to be performed.
  • the events created depend on the result of the analysis made of the information contained in the previous events corresponding to previous operations of the protocol.
  • the information contained in the event then consists either of the result of the analysis, or of a report made by the practitioner who practiced the therapeutic act.
  • the incomplete event created automatically in step 512 contains for example only the patient identifier, an identifier of the current protocol, and the identifier of one or more entities authorized to access the information which will appear later in the event. Other information such as the creation date of the event can also be specified automatically as soon as the incomplete event is created.
  • the incomplete event is temporarily stored in storage unit 48.
  • the software module 44B advantageously ensures the sending of an alert to the practitioner concerned by the incomplete event, that is to say to the practitioner having to perform the associated operation.
  • Step 514 is optional and, in the absence of an alert, the practitioner in charge of a protocol operation for which the incomplete event has already been created accesses the incomplete event from a workstation. user after the patient has given the practitioner access to this incomplete event under the conditions described above.
  • the practitioner carrying out the operation provided for by the protocol ensures, in step 516, from a user station, the entry of the or each item of information in the corresponding initially incomplete event. This information entry is carried out either manually, or from an interface 30 for connecting the microcomputer to an imaging or medical information collection installation.
  • the practitioner proceeds to define the access rights by inputting the identifiers of the entities that can subsequently access the information entered.
  • step 520 the practitioner validates, by entering a signature code, all of the elements constituting the event, namely in particular the medical information proper, the identifier of the patient concerned already contained since the creation of the event, its own identifier and the list of identifiers of the additional entities authorized to access.
  • steps 522, 524, 526 and 528 are strictly identical to steps 134 to 140 of the algorithm illustrated in FIG. 3.
  • steps 522, 524, 526 and 528 consist in the creation of an elementary datum suitable for being stored, the processing of the elementary data and the possible conversion of an image contained therein and, finally, the saving of the elementary data in the storage unit 48.
  • steps 506 et seq. are again implemented.
  • the new event produced and saved is attached, in step 506, to the other events then a new analysis of the information contained in the different events, and in particular in the new saved event, is carried out in step 508 according to the protocol specific criteria. If the protocol is not completed, one or more new incomplete events are created in step 512 according to the specifications of the protocol initially selected.
  • the implementation of the algorithm of FIG. 5 allows a connection, within the framework of a protocol, of the already existing events and the automatic creation of new events corresponding to operations to be implemented later in the framework of the selected protocol.
  • the information from the different entities involved in the protocol is linked to each other and taken into account for the following operations to be implemented in the protocol.
  • each entity can be guided in its intervention by the creation of incomplete events.
  • the use made of the information communicated by each entity is also assisted by the analysis carried out in step 508 and the automatic creation of incomplete events which result therefrom, in step 512.
  • Such an information management system can be applied in fields other than the medical field and in particular in the legal field.
  • the second entity is a lawyer or counsel, the first entity being the client of the lawyer or counsel.
  • this management system can be applied for the management of complex projects.
  • the first entity is the project itself while the second entities are the various stakeholders on the project.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système de gestion d'informations, chaque information concernant une première entité et ayant été engendrée par une seconde entité. Il comporte: des moyens (12) pour créer au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire: une information concernant la première entité; un identifiant de la première entité; et un identifiant de la seconde entité; et des moyens (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser en fonction du résultat d'une analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres à un protocole prédéterminé.

Description

Système de gestion d'informations Intégrées dans un protocole
La présente invention concerne un système de gestion d'informations, et notamment d'informations médicales, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le système comprenant :
- au moins une base de données pour le stockage desdites informations ; et
- au moins un poste utilisateur comprenant des moyens de recueil d'au moins une information concernant la première entité. Dans de nombreux domaines, il est nécessaire de pouvoir assurer le stockage confidentiel et la consultation autorisée et contrôlée d'informations validées concernant une personne.
Ces informations peuvent être par exemple des informations médicales 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 systèmes de gestion d'informations connus actuellement mettent en œuvre des bases de données relationnelles dans lesquelles sont mémorisés, d'une part, l'ensemble des informations devant être gérées par le système, et, d'autre part, des identifiants du patient concerné et/ou du praticien ayant engendré ces informations. Dans les bases de données relationnelles, la base de données est organisée en fonction des relations qui existent entre les données élémentaires.
Ainsi, une information concernant un patient, l'identité de ce patient ou l'identité du praticien ayant engendré cette information est considérée comme une donnée élémentaire et des liens traduisant les relations existantes entre les données élémentaires sont mémorisés dans la base.
Ce type de bases de données est commode puisqu'il permet de modifier les liens existant entre les données élémentaires, ce qui permet d'appli- quer de nouveaux traitements à des éléments déjà existants. Cela réduit la redondance des données élémentaires contenues dans la base.
Toutefois, la gestion de la confidentialité nécessaire à la limitation de la consultation des informations, imposée notamment par la déontologie des personnes engendrant les informations est difficile à assurer, du fait de la multitude de liens qui peuvent être créés dans une telle base de données.
Par ailleurs, dans le domaine médical, les praticiens sont souvent amenés à appliquer un protocole médical. Ce protocole spécifie une séquence d'opérations à effectuer en fonction des résultats obtenus lors d'opé- rations antérieures. Les opérations ultérieures à réaliser sont définies en fonction de critères propres au protocole, ces critères portant sur les résultats des opérations antérieures.
Les protocoles applicables sont très nombreux. Ceux-ci sont accessibles aux praticiens dans des ouvrages de référence, ou dans des bases de données informatiques.
Du fait de leur grande variété, il est difficile aux praticiens de connaître de manière exhaustive chaque protocole et l'accès protocole dans un ouvrage de référence ou une base de données est consommateur de temps.
L'invention a pour but de proposer un dispositif permettant aux prati- ciens la mise en œuvre aisée et fiable de protocoles complexes, et notamment de protocoles médicaux.
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 créer au moins un événement regroupant, de ma- nière indissociable, dans une même donnée élémentaire :
• la ou chaque information concernant la première entité ;
• un identifiant de la première entité ; et
• un identifiant de la seconde entité,
- des moyens de stockage d'au moins un protocole, lequel protocole spécifie une séquence d'opérations successives à réaliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction de critères propres audit protocole ; - des moyens d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres à un protocole ;
- des moyens de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres audit protocole ; et
- des moyens de stockage définitif du contenu du ou de chaque évé- nement créé automatiquement, chacun en tant que donnée élémentaire dans la ou chaque base de données.
Suivant des modes particuliers de réalisation, le système de gestion d'informations comporte l'une ou plusieurs des caractéristiques suivantes :
- lesdits moyens de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser sont adaptés pour la création d'un événement incomplet, et le système comporte des moyens pour compléter le ou chaque événement incomplet, par au moins une seconde entité depuis un poste utilisateur, par ajout d'au moins une information dans le ou chaque événement avant son stockage définitif ;
- il comporte des moyens d'alerte d'au moins une seconde entité pour compléter un événement incomplet ;
- il comporte des moyens pour valider le ou chaque événement, par la ou chaque seconde entité, avant son stockage définitif ; - lesdits moyens d'analyse sont adaptés pour l'analyse de la ou chaque information contenue dans au moins deux événements antérieurs ;
- il comporte des moyens de recherche automatique parmi les données élémentaires stockées dans la ou chaque base de données, des données élémentaires contenant des informations devant être analysées par les moyens d'analyse en fonction des critères propres audit protocole ;
- il comporte des moyens d'archivage des événements utilisés lors de la mise en œuvre dudit protocole ; et - lesdits moyens de création automatique d'au moins un événement comportent des moyens d'ajout automatique dans ledit événement de l'identifiant de la première entité concernée par la ou chaque information.
L'invention a également pour objet un procédé de gestion d'informa- tions, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le système comprenant au moins une base de données pour le stockage desdites informations et au moins un poste utilisateur comprenant des moyens de recueil d'au moins une information concernant la première entité, le procédé comprenant une étape de recueil, depuis un poste utilisateur d'au moins une information concernant la première entité ; caractérisé en ce qu'il comporte :
- une étape de création d'au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire : • la ou chaque information concernant la première entité ;
• un identifiant de la première entité ; et
• un identifiant de la seconde entité,
- une étape d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction de critères propres audit proto- cole, lequel protocole spécifie une séquence d'opérations successives à réaliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction des critères propres audit protocole ;
- une étape de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres audit protocole ; et
- une étape de stockage définitif du contenu du ou de chaque événe- ment créé automatiquement, chacun en tant que donnée élémentaire dans la ou chaque base de données. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins, 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 œuvre dans le système selon l'invention ; - la figure 4 est une vue schématique d'une variante de réalisation du système de gestion d'informations selon l'invention ; et
- la figure 5 est un organigramme de l'algorithme de gestion par protocole mis en œuvre dans le système selon l'invention.
Le système de gestion d'informations 10 selon l'invention est illustré schématiquement sur la figure 1. Celui-ci comporte, d'une part, un ensemble de postes utilisateurs désignés par la référence générale 12, chacun relié à un réseau 14 collectif de transmission d'informations tel que le réseau Internet 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 seu- lement au patient concerné et au praticien ayant engendré l'information, ainsi que, éventuellement, après accord du patient, à d'autres praticiens.
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 interface adaptée au réseau 14. Chaque poste d'utilisateur comporte des moyens 22 de recueil de données d'entrée tels qu'un clavier ou un module de conversion de données. A partir du clavier, peuvent être entrés notam- ment une information médicale, un identifiant d'un patient tel que son nom, ainsi qu'un identifiant du praticien ayant produit l'information.
Chaque poste d'utilisateur 12 est adapté pour mettre en œuvre, 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 12 comporte des moyens logiciels pour créer un événement regroupant de manière indissociable dans une même donnée élémentaire, des informations recueillies concernant un patient, un identifiant du patient et un identifiant du praticien. Ces moyens de création d'un événement sont avantageusement téléchargés depuis le cen- tre 16 et sont par exemple constitués d'une page au format HTML (Hyper Text Markup Language) formant interface de dialogue.
Certains de ces postes d'utilisateur, comme le poste 12C, comportent, en plus du micro-ordinateur 20, une interface 30 de connexion du microordinateur à une installation 32 d'imagerie médicale ou de recueil d'informa- tions médicales apte à produire des images ou informations numériques sous un format prédéfini tel que le format DICOM Hprim HL7. Par nature, cette image ou information numérique comporte un identifiant du patient concerné. Le poste d'utilisateur met en œuvre en outre un module logiciel 34 propre à analyser l'image numérique produite par l'installation 32 et à ex- traire de celle-ci un identifiant du patient concerné.
Le centre de stockage et de gestion des informations 16 comporte un ensemble de serveurs 40 pour la gestion des accès au centre 16. Cet 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 comporte 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 seconde barrière de sécurité 46 (firewalls). En particulier, l'ensemble de ser- veurs 44 est propre à mettre en œuvre un module logiciel 44A de 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. 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é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 également ê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 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.
Pour l'ajout d'une information dans le centre de stockage, le complé- ment d'une information pré-existante par une information supplémentaire, la modification des droits d'accès à une information ou la consultation d'une information, l'utilisateur se connecte depuis un poste d'utilisateur 12 au centre de stockage 16.
L'algorithme de la figure 3 est alors mis en œuvre. Le poste d'utilisateur peut être constitué, pour les opérations les plus simples, seulement d'un micro-ordinateur relié au réseau Internet à l'aide d'un navigateur de tout type adapté. Après connexion du poste d'utilisateur, à l'étape 100, 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 fonction 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 11 OC de l'organigramme est alors 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 branche 110D 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'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 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 identifiant et la liste des identifiants des entités supplémentaires autorisées à accéder. A l'issue de cette étape, les éléments constituant l'événement ne peuvent plus être modifiés et l'événement peut seulement être complété.
A l'étape 134, le poste d'utilisateur 12 assure la création d'une donnée élémentaire reprenant les différents éléments de l'événement. Cette donnée élémentaire est cryptée par tout procédé adapté et est adressée par l'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'identi- fiant figure dans la liste 58.
L'information supplémentaire est entrée à l'étape 154, soit manuellement 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 asurer un suivi des modifications. La nouvelle donnée élémentaire ainsi constituée est ensuite traitée conformément aux étapes 136 et suivantes.
Lorsque l'utilisateur souhaite modifier un droit d'accès, celui-ci peut seulement ajouter de nouveaux identifiants d'utilisateur habilités à accéder à une information donnée. A cet effet, l'événement dont les accès sont à complé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 identifiants 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.
Pour la consultation des informations stockées dans le centre 16, et depuis n'importe quel poste d'utilisateur 12, les étapes de la branche 110D sont mises en œuvre.
A l'étape 250, une 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'identifiant 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.
On conçoit qu'avec un tel système de gestion d'informations, la fiabilité de l'accès aux informations est accrue, puisque l'information proprement dite est associée, dans une même donnée élémentaire, à un identifiant du patient concerné, un identifiant du praticien ayant engendré l'information et, éventuellement, des identifiants d'autres entités susceptibles d'accéder à l'information proprement dite.
Le système de gestion d'informations illustré sur la figure 4 reprend les caractéristiques du système de gestion illustré sur la figure 1.
Toutefois, il comporte en outre des moyens de gestion de protocoles médicaux.
A cet effet, le centre 16 de stockage et de gestion des informations comporte une unité de stockage supplémentaire 402 dans laquelle est mémorisé de manière permanente un ensemble de protocoles médicaux.
Chaque protocole spécifie une séquence d'opérations successives à réaliser par un praticien dans le cas du diagnostic et/ou du traitement d'un patient, ou dans le cas d'une étude épidémiologique ou d'une étude sur les effets d'un traitement. En particulier, chaque protocole définit des critères décisionnels propres portant sur les informations recueillies lors d'opérations antérieures. Les opérations ultérieures du protocole sont choisies parmi un ensemble d'opérations possibles en fonction des critères propres au protocole.
En outre, l'ensemble de serveurs 44 de gestion d'événements, et plus particulièrement le module logiciel 44B de gestion du stockage d'événements est adapté pour la mise en œuvre d'un algorithme de gestion des protocoles. L'algorithme de gestion des protocoles est illustré sur la figure 5.
Cet algorithme est mis en œuvre sur une longue période de temps correspondant à toute la durée de mise en œuvre du protocole. Dans le cas du diagnostic et/ou du traitement d'une maladie grave, le protocole peut être mis en œuvre sur une période allant d'une semaine à plusieurs mois.
A l'étape 502, l'utilisateur, à savoir un praticien sélectionne un protocole à appliquer depuis un poste d'utilisateur. A cet effet, l'utilisateur a recours à une interface utilisateur téléchargée depuis le centre de stockage et de gestion 16. Cette interface permet la sélection du protocole parmi les protocoles mémorisés dans l'unité de stockage 402.
L'exemple qui suit concerne un protocole de diagnostic ou de traitement d'un patient.
Les informations complémentaires, telles que le patient, sur lequel est appliqué le protocole, sont saisies à l'étape 502.
A l'étape 504, le module logiciel 44B effectue une recherche des événements existants pouvant être exploités par le protocole. Ces événements existants sont recherchés dans l'unité de stockage 48 parmi les données élémentaires comportant l'identifiant de la première entité sélectionnée à l'étape 502.
Chacun des événements pouvant être exploité est rattaché au protocole, à l'étape 506, afin que les informations qu'il contient soient prises en compte par le protocole.
A l'étape 508, le module logiciel 44B effectue une analyse des infor- mations contenues dans les événements rattachés à l'étape 106. Cette analyse des informations s'effectue par application des critères propres au protocole sélectionné. A l'étape 510, un test est effectué pour déterminer si le protocole est achevé ou non.
Tant que le protocole n'est pas achevé, le module logiciel 44B crée, à l'étape 512, un ou plusieurs événements. Chaque événement créé corres- pond à une opération ultérieure du protocole à réaliser. Les événements créés dépendent du résultat de l'analyse faite des informations contenues dans les événements antérieurs correspondant à des opérations antérieures du protocole.
Ces événements sont généralement incomplets puisque ceux-ci correspondent, par exemple, en fonction du protocole sélectionné, à un examen à effectuer sur le patient, ou à un acte thérapeutique devant être pratiqué sur le patient.
Les informations contenues dans l'événement consistent alors, soit au résultat de l'analyse, soit à un compte-rendu fait par le praticien ayant prati- que l'acte thérapeutique.
L'événement incomplet créé automatiquement à l'étape 512 contient par exemple seulement l'identifiant du patient, un identifiant du protocole en cours, et l'identifiant d'une ou plusieurs entité autorisées à accéder à l'information qui figurera ultérieurement dans l'événement . D'autres informations telles que la date de création de l'événement peuvent également être spécifiées automatiquement dès la création de l'événement incomplet.
L'événement incomplet est stocké de manière temporaire dans l'unité de stockage 48.
A l'étape 514, le module logiciel 44B assure avantageusement l'envoi d'une alerte auprès du praticien concerné par l'événement incomplet, c'est- à-dire auprès du praticien devant effectuer l'opération associée.
L'étape 514 est facultative et, en l'absence d'alerte, le praticien en charge d'une opération du protocole pour laquelle l'événement incomplet a déjà été créé accède à l'événement incomplet à partir d'un poste d'utilisateur après que le patient a donné accès au praticien à cet événement incomplet dans les conditions décrites précédemment.
Le praticien réalisant l'opération prévue par le protocole assure, à l'étape 516, depuis un poste utilisateur, l'entrée de la ou chaque information dans l'événement initialement incomplet correspondant. Cette entrée d'informations s'effectue soit manuellement, soit à partir d'une interface 30 de connexion du micro-ordinateur à une installation d'imagerie ou de recueil d'informations médicales. A l'étape 518, le praticien procède à la définition des droits d'accès par entrée des identifiants des entités pouvant ultérieurement accéder aux informations entrées.
A l'étape 520, le praticien valide, par saisie d'un code de signature, l'ensemble des éléments constituant l'événement, à savoir notamment l'in- formation médicale proprement dite, l'identifiant du patient concerné déjà contenu depuis la création de l'événement, son propre identifiant et la liste des identifiants des entités supplémentaires autorisées à accéder.
Les étapes suivantes 522, 524, 526 et 528 sont rigoureusement identiques aux étapes 134 à 140 de l'algorithme illustré sur la figure 3. En parti- culier, celles-ci consistent à la création d'une donnée élémentaire propre à être stockée, le traitement de la donnée élémentaire et l'éventuelle conversion d'une image contenue dans celle-ci et, enfin, la sauvegarde de la donnée élémentaire dans l'unité de stockage 48.
A l'issue de la sauvegarde de la donnée élémentaire correspondant à l'événement ainsi complété, les étapes 506 et suivantes sont à nouveau mises en œuvre.
En particulier, le nouvel événement produit et sauvegardé est rattaché, à l'étape 506, aux autres événements puis une nouvelle analyse des informations contenues dans les différents événements, et notamment dans le nouvel événement sauvegardé, est effectuée à l'étape 508 suivant les critères propres au protocole. Si le protocole n'est pas achevé, un ou plusieurs nouveaux événements incomplets sont créés à l'étape 512 suivant les spécifications du protocole initialement sélectionné.
On comprend que la mise en œuvre de l'algorithme de la figure 5 permet une liaison, dans le cadre d'un protocole, des événements existants déjà et la création automatique de nouveaux événements correspondant à des opérations devant être mises en œuvre ultérieurement dans le cadre du protocole sélectionné. Ainsi, les informations issues des différentes entités intervenant dans le protocole sont liées entre elles et prises en compte pour les opérations suivantes devant être mises en œuvre dans le protocole. Ainsi, chaque entité peut être guidée dans son intervention par la création d'événements in- complets. En outre, l'exploitation qui est faite des informations communiquées par chaque entité est également assistée par l'analyse effectuée à l'étape 508 et la création automatique d'événements incomplets qui en résultent, à l'étape 512.
Un tel système de gestion d'informations peut être appliqué dans d'autres domaines que le domaine médical et notamment dans le domaine juridique. Dans ce cas, la seconde entité est un avocat ou un conseil, la première entité étant le client de l'avocat ou du conseil.
De même, ce système de gestion peut être appliqué pour la gestion de projets complexes. Dans ce cas, la première entité est le projet lui-même alors que les secondes entités sont les différents intervenants sur le projet.

Claims

REVENDICATIONS 1.- Système de gestion d'informations, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le système comprenant : - au moins une base de données (48) pour le stockage desdites informations (52) ; et
- au moins un poste utilisateur (12) comprenant des moyens de recueil (12, 22, 34, 36) d'au moins une information (52) concernant la première entité ; caractérisé en ce qu'il comporte :
- des moyens (12) pour créer au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire (50) :
• la ou chaque information (52) concernant la première entité ;
• un identifiant (54) de la première entité ; et • un identifiant (56) de la seconde entité,
- des moyens (402) de stockage d'au moins un protocole, lequel protocole spécifie une séquence d'opérations successives à réaliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction de critères propres audit protocole ; - des moyens (44B) d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres à un protocole ;
- des moyens (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opéra- tion ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres audit protocole ; et
- des moyens (12, 44, 48) de stockage définitif du contenu du ou de chaque événement créé automatiquement, chacun en tant que donnée élé- mentaire (50) dans la ou chaque base de données (48).
2.- Système de gestion selon la revendication 1 , caractérisé en ce que lesdits moyens (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser sont adaptés pour la création d'un événement incomplet, et en ce qu'il comporte des moyens pour compléter le ou chaque événement incomplet, par au moins une seconde entité depuis un poste utilisateur, par ajout d'au moins une information dans le ou chaque événement avant son stockage définitif.
3.- Système de gestion selon la revendication 2, caractérisé en ce qu'il comporte des moyens d'alerte d'au moins une seconde entité pour compléter un événement incomplet.
4.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens pour valider le ou chaque événement, par la ou chaque seconde entité, avant son stockage définitif.
5.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens d'analyse sont adaptés pour l'analyse de la ou chaque information contenue dans au moins deux événements antérieurs.
6.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens de recherche automatique parmi les données élémentaires stockées dans la ou chaque base de données, des données élémentaires contenant des informations devant être analysées par les moyens d'analyse en fonction des critères propres audit protocole.
7.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens d'archivage des événements utilisés lors de la mise en œuvre dudit protocole.
8.- Système de gestion selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens de création automatique d'au moins un événement comportent des moyens d'ajout automatique dans ledit événement de l'identifiant de la première entité concernée par la ou chaque information.
9.- Procédé de gestion d'informations, chaque information concernant une première entité et ayant été engendrée par une seconde entité, le système comprenant au moins une base de données (48) pour le stockage desdites informations (52) et au moins un poste utilisateur (12) comprenant des moyens de recueil (12, 22, 34, 36) d'au moins une information (52) concernant la première entité, le procédé comprenant une étape de recueil, depuis un poste utilisateur (12) d'au moins une information (52) concernant la première entité ; caractérisé en ce qu'il comporte :
- une étape de création d'au moins un événement regroupant, de manière indissociable, dans une même donnée élémentaire (50) :
• la ou chaque information (52) concernant la première entité ; • un identifiant (54) de la première entité ; et
• un identifiant (56) de la seconde entité,
- une étape d'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction de critères propres audit protocole, lequel protocole spécifie une séquence d'opérations successives à ré- aliser, dont les opérations ultérieures dépendent des résultats obtenus aux opérations antérieures réalisées en fonction des critères propres audit protocole ;
- une étape (44B) de création automatique, suivant les spécifications dudit protocole, d'au moins un événement correspondant à une opération ultérieure à réaliser en fonction du résultat de l'analyse de la ou chaque information contenue dans au moins un événement antérieur en fonction des critères propres audit protocole ; et
- une étape de stockage définitif du contenu du ou de chaque événement créé automatiquement, chacun en tant que donnée élémentaire (50) dans la ou chaque base de données (48).
EP03740681A 2002-04-30 2003-04-29 Systeme de gestion d informations integrees dans un protocol e Withdrawn EP1500027A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0205468 2002-04-30
FR0205468A FR2839170B1 (fr) 2002-04-30 2002-04-30 Systeme de gestion d'informations integrees dans un protocole
PCT/FR2003/001349 WO2003094084A1 (fr) 2002-04-30 2003-04-29 Systeme de gestion d'informations integrees dans un protocole

Publications (1)

Publication Number Publication Date
EP1500027A1 true EP1500027A1 (fr) 2005-01-26

Family

ID=28800101

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03740681A Withdrawn EP1500027A1 (fr) 2002-04-30 2003-04-29 Systeme de gestion d informations integrees dans un protocol e

Country Status (9)

Country Link
US (1) US20040030699A1 (fr)
EP (1) EP1500027A1 (fr)
CN (1) CN1659572A (fr)
AU (1) AU2003265524B2 (fr)
CA (1) CA2484156C (fr)
FR (1) FR2839170B1 (fr)
IL (2) IL164862A0 (fr)
MX (1) MXPA04010601A (fr)
WO (1) WO2003094084A1 (fr)

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5845255A (en) * 1994-10-28 1998-12-01 Advanced Health Med-E-Systems Corporation Prescription management system
US5842175A (en) * 1995-04-28 1998-11-24 Therassist Software, Inc. Therapy system
JP3083465B2 (ja) * 1995-09-06 2000-09-04 フクダ電子株式会社 患者情報解析管理システム及び方法
US6426759B1 (en) * 1995-10-20 2002-07-30 Confer Software, Inc. Apparatus and method for managing changes of computerized medical protocols
US5786816A (en) * 1995-10-20 1998-07-28 Araxsys, Inc. Method and apparatus for graphical user interface-based and variable result healthcare plan
US6067523A (en) * 1997-07-03 2000-05-23 The Psychological Corporation System and method for reporting behavioral health care data
US6845370B2 (en) * 1998-11-12 2005-01-18 Accenture Llp Advanced information gathering for targeted activities
US6434572B2 (en) * 1998-11-25 2002-08-13 Ge Medical Technology Services, Inc. Medical diagnostic system management method and apparatus
US6338039B1 (en) * 1999-07-20 2002-01-08 Michael Lonski Method for automated collection of psychotherapy patient information and generating reports and treatment plans
US7047419B2 (en) * 1999-09-17 2006-05-16 Pen-One Inc. Data security system
US6941271B1 (en) * 2000-02-15 2005-09-06 James W. Soong Method for accessing component fields of a patient record by applying access rules determined by the patient
US6763344B1 (en) * 2000-04-14 2004-07-13 International Business Machines Corporation Method of and system for dynamically controlling access to data records
US20020016718A1 (en) * 2000-06-22 2002-02-07 Rothschild Peter A. Medical image management system and method
US6748400B2 (en) * 2000-06-22 2004-06-08 David F. Quick Data access system and method
US20020049615A1 (en) * 2000-10-25 2002-04-25 Huber Janet B. Automated disease management system
US20030028406A1 (en) * 2001-07-24 2003-02-06 Herz Frederick S. M. Database for pre-screening potentially litigious patients
US6484114B1 (en) * 2001-08-20 2002-11-19 Glimmerglass Networks, Inc. Method for calibrating a free-space-coupled fiber-optic transmission system
US8567393B2 (en) * 2001-11-01 2013-10-29 Scott Laboratories, Inc User interface for sedation and analgesia delivery systems and methods
US20030130872A1 (en) * 2001-11-27 2003-07-10 Carl Dvorak Methods and apparatus for managing and using inpatient healthcare information
US20060116908A1 (en) * 2002-07-30 2006-06-01 Dew Douglas K Web-based data entry system and method for generating medical records

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03094084A1 *

Also Published As

Publication number Publication date
AU2003265524A1 (en) 2003-11-17
FR2839170A1 (fr) 2003-10-31
FR2839170B1 (fr) 2004-12-17
CA2484156C (fr) 2009-07-21
CA2484156A1 (fr) 2003-11-13
US20040030699A1 (en) 2004-02-12
IL164862A (en) 2010-06-16
CN1659572A (zh) 2005-08-24
WO2003094084A1 (fr) 2003-11-13
MXPA04010601A (es) 2005-06-08
IL164862A0 (en) 2005-12-18
AU2003265524B2 (en) 2009-08-27

Similar Documents

Publication Publication Date Title
EP1834268A2 (fr) Serveur, procede et reseau d'intermediation pour la consultation et le referencement d'informations medicales
WO2002033933A1 (fr) Procede de controle d'acces a des adresses de sites internet
FR2813409A1 (fr) Procede et dispositif configuration d'un peripherique de traitement de documents electroniques dans un reseau de communication
US7085927B1 (en) Secure data report preparation and delivery
FR2980019A1 (fr) Procede d'acces et de partage d'un dossier informatique enrichi par des ressources multimedias personnalisees
CA2489317C (fr) Systeme de gestion d'informations pour situation d'urgence
WO2020165531A1 (fr) Systèmes informatiques et procédés d'assistance au remplissage de formulaires en ligne
WO2005111906A2 (fr) Systeme de generation automatique d'un message d'informations medicales
CA2484160C (fr) Systeme de gestion d'informations
CA2484156C (fr) Systeme de gestion d'informations integrees dans un protocole
EP0685802B1 (fr) Système d'information pour la consultation d'informations centralisées en provenance d'applications opérationnelles
EP2618285B1 (fr) Système de réseau informatique sécurisé pour la gestion de données personnelles
FR2865822A1 (fr) Dispositif de saisie, de consultation et de traitement de donnees, notamment medicales
EP1828933A1 (fr) Procede et systeme de gestion dynamique de connaissances
WO2006056667A1 (fr) Certificat de cle publique pour le transport d'information confidentielle
FR2793913A1 (fr) Systeme informatique muni d'un systeme expert
WO2003067501A1 (fr) Procede de realisation d'etudes destine a un systeme collaboratif en reseau
WO2002075546A2 (fr) Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur
CA2709919A1 (fr) Systeme de connexion securise permettant a un usager l'utilisation des services par internet d'un centre de services et methodes correspondantes
FR2783381A1 (fr) Commande et transfert de documents entre un serveur informatique et un utilisateur via un reseau de communication
WO2003023651A1 (fr) Procede d'annotation de documents informatiques, et systeme associe

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20041027

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

17Q First examination report despatched

Effective date: 20110111

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20141101