EP1590758A1 - Procédé et syst me de traitement de données d'évaluation - Google Patents

Procédé et syst me de traitement de données d'évaluation

Info

Publication number
EP1590758A1
EP1590758A1 EP03782536A EP03782536A EP1590758A1 EP 1590758 A1 EP1590758 A1 EP 1590758A1 EP 03782536 A EP03782536 A EP 03782536A EP 03782536 A EP03782536 A EP 03782536A EP 1590758 A1 EP1590758 A1 EP 1590758A1
Authority
EP
European Patent Office
Prior art keywords
entity
data
events
function
initial state
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
EP03782536A
Other languages
German (de)
English (en)
Inventor
Alexandre Templier
Laurent Node-Langlois
Ilhem Cherrak
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.)
Surgiview SA
Original Assignee
Surgiview SA
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 Surgiview SA filed Critical Surgiview SA
Publication of EP1590758A1 publication Critical patent/EP1590758A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT 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/60ICT 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/63ICT 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 local operation
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • YGENERAL 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
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02ATECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Definitions

  • the present invention relates to a method and a system for processing evaluation data. It finds a particularly interesting application in any context where one wishes to analyze (evaluate) the effects of one or more actions on a population of entities of the same nature which can be in one or more initial states, the action or actions considered inducing a modification of this initial state and an evolution of this state over time.
  • the present invention relates in particular, but not exclusively, to the medical field in which a user such as a doctor for example, wishes to follow the evolution of the condition of a patient throughout one or more treatments.
  • the invention is of a broader scope, since it could be applied in particular to a system of evaluation of companies, the characteristics of which are liable to change over time as a function of certain internal and external actions.
  • An object of the present invention is to provide a module allowing the simple and rapid entry of information with complex structure via a specific interface.
  • Another object of the invention is to propose the use of this information in a simple and rapid manner.
  • Another object of the invention is to propose a data entry and processing module which can be adapted to numerous fields of application.
  • At least one of the aforementioned objectives is achieved with an evaluation data processing method comprising a data entry phase in which: a) at least one entity is created as a function of intrinsic characteristics of this entity, b) an initial state of said entity is created and filled in, c) an action is created and filled in according to the initial state, then d) creates and informs, during the evolution of the state of said entity and at determined times, resulting states, these resulting states being at least a function of the initial state and of the action.
  • Icons representing the Entities, states and actions thus created visually align on a chronological line. Clicking on one of these icons gives access to the corresponding data.
  • the method also includes a data exploitation phase in which statistical data are produced as a function of criteria determined by browsing the structure of at least one of the events a), b), c) and d) of the input phase .
  • the data relating to each entity is stored in a first "Information” database, while the structure of the events is contained in a second independent "Metabase” database.
  • the Metabase is a database containing the description (hierarchy, structure and contents) of the various objects and events. It does not contain any information related to the individual entities in themselves. It is only used to describe the structure of objects and events on which an input module and operating modules are based (sampling and analysis as described below).
  • the input module allows you to create the different events and display their respective structures based on the information it finds in the Metabase.
  • the data entered is then stored in the "Information" database.
  • the operating modules also use the Metabase to display the global and specific structure of the events, to allow the user to choose his criteria and variables for the operation.
  • the input and operation modules are entirely independent of the structure of the events studied, and therefore of the user's "profession". These modules constitute a generic interface.
  • the structure of events can change (addition or deletion of events or items to be entered): the modifications are then automatically reflected in the entry and processing modules.
  • the structure of each event can be of tree type.
  • the tree structure can be in the form of cascading files or in graphic form or in any other form.
  • the operation can include a sampling step in which a given sub-population of entities is selected.
  • the selection can be made by choosing at least one variable in the structure of at least one event a), b), c) or d), and by assigning a given constraint to this variable.
  • This constraint can be a value or a set of values, or the character "entered” or "not entered", making it possible to sample all the entities for which a specific variable has been entered or not.
  • Data mining can also include an analysis step in which data is produced statistics in the form of values, tables or graphs.
  • the sampling and the analysis are distinct, that is to say that one of the two functions can be performed without the other. We can also perform the analysis by choosing at least one variable in the structure of at least one event a), b), c) or d).
  • the events a), b), c) and d) are created in chronological order, in particular as the activity of the user progresses. Entering information is therefore logical and simplified.
  • the entry is carried out by means of intuitive graphical interfaces. It is also possible to have several successive interfaces detailing the elements entered.
  • the input mode can be via a keyboard, on a touch screen or even audibly via a microphone.
  • the structure of each event can be configured using the Metabase.
  • a system for processing evaluation data comprising input means for: a) creating at least one entity as a function of intrinsic characteristics of this entity, b) creating and informing a initial state of said entity, c) create and inform an action as a function of the initial state, then d) create and inform, during the evolution of the state of said entity and at determined times, of the resulting states , these resulting states being at least a function of the initial state and of the action.
  • the system also includes data processing means for developing statistical data according to criteria determined by browsing the structure of at least one of the events a), b), c) and d).
  • the data processing means comprise a sampling module for selecting a given sub-population of entities and an analysis module, preferably separate, for developing statistical data in the form of values, tables or graphics.
  • the input and exploitation means can consist of generic interfaces capable of exploring the structure of events.
  • Other advantages and characteristics of the invention will appear on examining the detailed description of a mode of implementation which is in no way limitative, and the attached drawings, in which:
  • FIG. 1 is a global schematic view of the environment in which a system according to the invention can be integrated;
  • FIG. 2 is a diagram illustrating the events included in the entry phase as well as the processing modules for the operation phase;
  • Figure 3 is a diagram illustrating the logical relationships between event structures;
  • FIG. 4 is a diagram illustrating the principle of an input interface according to the invention.
  • FIG. 5 is a diagram illustrating the principle of an input interface during a patient identification phase
  • FIG. 6 is a diagram illustrating the principle of an input interface during a preoperative examination of the patient
  • FIG. 7 is a diagram illustrating the principle of an intuitive graphic input interface during a pre-operative examination of the patient
  • FIG. 8 is a diagram illustrating the principle of an input interface during an intraoperative examination (surgery) of the patient
  • FIG. 9 is a diagram illustrating the principle of an operating interface during sampling
  • FIG. 10 is a diagram illustrating the principle of an operating interface during an analysis.
  • FIG. 11 is a diagram illustrating a processing mode of the sampling module and of the analysis module according to the invention.
  • FIG. 1 there is a system with a data server 3 called “Server”.
  • This data server brings together in an "Information” database, all of the information relating to each patient for whom medical monitoring is carried out by means of a method according to the invention.
  • the information can be entered by a doctor 1 in a microcomputer 2 and then transmitted to the server 3 for storage. They can then be shared with other institutions such as a clinic 4 or a hospital 5. Institutions 4 and 5 can also enter information in order to complete a patient's file.
  • the doctor and institutions 4 and 5 each have a microcomputer used for implementing the method according to the invention.
  • Each microcomputer comprises a "Metabase” database according to the invention in which the structure of various objects and events.
  • each microcomputer can contain both an "Information” database and a "Metabase” database.
  • Figures 2 and 3 we see the logical flow of data processing according to the invention.
  • FIG. 2 there is a microcomputer 6 allowing data entry and use according to the invention.
  • the microcomputer 6 contains an "Information” database and a configured “Metabase” database.
  • the user that is to say the doctor, to follow the evolution of the state of a patient, will create a set of events in chronological order, as and when his activity.
  • the first step is to identify or define the entity (the patient).
  • This step 7 can for example correspond to data such as the patient's first and last name, date of birth, file number, weight, height, profession, sports activities ... These elements are intrinsic characteristics of the patient.
  • the next step 8 concerns a pre-operative examination (diagnosis) during which the doctor examines the patient in order to define the pathology related to this patient.
  • the elements seized by the doctor can for example be a degenerative spine in the form of a herniated disc resulting in an inability to walk.
  • the doctor can then implement a treatment such as a surgical operation, taking medication, or others.
  • This treatment is a step 9 of intraoperative examination (therapeutic treatment).
  • the surgical operation can be carried out in clinic 4, and the information relating to this operation is therefore introduced during step 9.
  • Step 10 is a post-operative (follow-up) step during which the doctor performs several examinations at given times so as to check the evolution of the patient's condition. All the information obtained during these examinations is integrated into the "Information" database within the microcomputer 6.
  • Steps 7 to 10 therefore relate to the entry step. This information will be used to carry out samples 11 so as to select sub-populations within all of the entities. Analyzes 12 can also be performed to develop statistical data in the form of values, tables or graphs.
  • Each step 7, 8, 9 or 10 of the entry phase constitutes an event. These events follow a particular chronology as shown in FIG. 3.
  • the identification 7 of the patient therefore corresponds to a first step during which the entity E (the patient) is defined. This identification makes it possible to grasp the intrinsic characteristics of the entity E (fig. 3) regardless of its pathology. This pathology is determined during the pre-operative examination (diagnosis) 8 (fig. 2) corresponding in fact to the definition of an initial state.
  • To an entity E can correspond several initial states El, E2 and E3 for example (fig.3).
  • a given action can be applied such as for example a medical treatment or a surgical operation.
  • the actions Al-1, Al-2 or Al-3 can be applied.
  • an initial state can correspond to several actions.
  • to an action corresponds one and only one resulting state Ri-i.
  • a doctor examines a patient who has undergone medical treatment the patient's condition is the only condition observed at the time of this post-operative examination.
  • several post-operative (follow-up) exams can succeed each other by giving each a specific resulting state.
  • Figure 4 is an example of an input interface.
  • This interface includes an upper part comprising a first zone 13 for indicating some elements of identification of the patient such as for example the name, first name, date of birth and number of the corresponding file.
  • the upper part also includes a second zone 14 for the creation of preoperative, intraoperative and postoperative events; and a third general information zone 15 such as returning to a summary menu, launching printing or displaying images associated with the current event.
  • the input interface also includes an intermediate zone 16 illustrating the chronological line.
  • This historic zone 16 comprises several events arranged one after the other in chronological order.
  • the first element is the identification of entity E, of the patient.
  • the next event is the definition of an initial state E-1 carried out during a pre-operative examination (diagnosis).
  • the medical treatment or surgery applied to the patient during the intraoperative step 9 corresponds to an Al-1 action.
  • Three postoperative (follow-up) exams (Rl-l (l), Rl-1 (2), Rl-1 (3)) are successively arranged on the chronological line before the definition of a second initial state E-2.
  • This second initial state is followed by a second action A2-1 and by a resulting state R2-1 (1) corresponding to this second action.
  • the structure of this event is developed in a lower left zone 17.
  • the structure shown in area 17 is of the tree type. This type of structure can be the same for all events, but we can also have a given type of structure for each type of event.
  • the selected event includes sub- events or files, and each sub-event includes other sub-events or other files and so on.
  • Each file can be configured according to the user's wishes. That is to say that depending on the activity (medical or not) of the user, the latter can define the tree structure as well as the content of each file, sub-event and event.
  • the settings are made within the "Metabase". Any modification to the Metabase is automatically reflected in the input and processing modules.
  • the description of events contained in the Metabase includes in particular a hierarchy as represented in FIG. 3, and structures such as those represented in area 17 of FIG. 4.
  • the files notably include variables which will later be used for sampling and analysis. These variables are in fact fields containing or not information entered by the doctor. This information is entered via an input area 18 in different forms such as drop-down menus, multiple choice lists, manual input fields, automatically calculated fields, graphical interfaces ...
  • FIG. 5 is a view of an interface illustrating the entry of information during the identification of the patient.
  • Area 17 shows the detailed structure tree, and area 18 shows the type of data to be entered.
  • FIG. 6 is a view corresponding to a step 8 of pre-operative examination (diagnosis) during which the doctor firstly defines that it is a pathology of the "generative spine" type by means of graphic interfaces representing the human skeleton as well as the zoom of a part of this skeleton pointed by the doctor.
  • FIG. 7 is a view of the continuation of the preoperative examination (diagnosis) making it possible to define more precisely the type of the "generative spine". The doctor can thus define that it is a herniated disc and specify the exact location on the spine. This definition is carried out by means of intuitive interactive graphics, a sort of graphic tree structure, each part of the skeleton being configured.
  • Step 9 (fig. 2) of intraoperative examination involves a surgical operation for which an input interface is as shown in FIG. 8. In tree 17, there is a tree structure illustrating the sub-events and the index cards. The selected file contains the general characteristics of the surgical operation (therapeutic action), these characteristics being detailed in zone 18 of FIG. 8.
  • FIG. 9 shows an interface for defining a sampling.
  • the doctor selects one of the events displayed in the historical area 16.
  • the event corresponding to "patient identification” is selected, it is the first event.
  • zone 17 the tree structure corresponding to the patient identification event is displayed. It is the same structure as that represented in zone 17 of FIG. 5.
  • the doctor will go through the structure until selecting the desired variable, in this case the weight. He can then specify the constraint, for example a weight less than 50 kg. We have thus simply isolated a subpopulation of patients weighing less than 50 kg.
  • Several sampling criteria can also be combined according to logical operations (Boolean operations).
  • the patient sub-population thus selected can then be analyzed.
  • the doctor can launch either a pre-established analysis such as of elementary statistical type, bi-varied-regression diagram, evolution diagram, survival curve, non-parametric test (t or Chi-square) ..., or a new analysis that it will create by exploring the information available in the meta-base.
  • a pre-established analysis such as of elementary statistical type, bi-varied-regression diagram, evolution diagram, survival curve, non-parametric test (t or Chi-square) ..., or a new analysis that it will create by exploring the information available in the meta-base.
  • the doctor needs to define a variable. To do this, he first selects an event in the historic zone 16, in this case the pre-operative event (diagnosis) (fig. 10). In zone 17 of FIG. 10, the tree structure corresponding to the selected pre-operative event (diagnosis) is then displayed. We find the structure of area 17 in Figure 6. The doctor can then browse the structure until reaching the variable "main diagnosis”.
  • FIG. 11 is an overall diagram illustrating the information flows between the meta-base, the "Information” database, the events, the sampling module and the analysis module. These last two modules take the information from the. meta-base to perform their functions.
  • the analysis function may also require data from sampling to establish graphs in particular 19.
  • the dotted flows relate to the "METABASE” information flows, and the solid lines flow relate to the information entered and used. Events are created using data from both METABASE and the database "Information”. Likewise, the input and the exploitation take into account the two databases.

Abstract

Procédé et système de traitement de données d'évaluation. L'invention concerne un procédé de traitement de données d'évaluation comprenant une phase de saisie de données dans laquelle : a) on crée au moins une entité en fonction de caractéristiques intrinsèques de cette entité, on crée et renseigne un état initial de ladite entité, on crée et renseigne une action en fonction de l'état initial, puis d) on crée et renseigne, au cours de l'évolution de l'état de ladite entité et à des instants déterminés, des états résultants, ces états résultants étant au moins fonction de l'état initial et de l'action. Il comprend également une seconde phase d'exploitation de données dans laquelle on élabore des données statistiques en fonction de critères déterminés en parcourant la structure d'au moins un des événements a), b), c) et d) de la phase de saisie.

Description

" Procédé et système de traitement de données d' évaluation"
La présente invention se rapporte à un procédé et un système de traitement de données d'évaluation. Elle trouve une application particulièrement intéressante dans tout contexte où l'on souhaite analyser (évaluer) les effets d'une ou de plusieurs actions sur une population d'entités de même nature pouvant être dans un ou plusieurs états initiaux, l'action ou les actions considérées induisant une modification de cet état initial et une évolution de cet état dans le temps. La présente invention se rapporte en particulier, mais non exclusivement, au domaine médical dans lequel un utilisateur tel qu'un médecin par exemple, désire suivre l'évolution de l'état d'un patient tout au long d'un ou plusieurs traitements. Toutefois l'invention est d'un cadre plus large, puisqu'elle pourrait s'appliquer notamment à un système d'évaluation d'entreprises, dont les caractéristiques sont susceptibles d'évoluer dans le temps en fonction de certaines actions internes et externes.
Un but de la présente invention est de proposer un module permettant la saisie simple et rapide d'informations à structure complexe via une interface spécifique.
Un autre but de l'invention est de proposer l'exploitation de ces informations de manière simple et rapide. L' invention a encore pour but de proposer un module de saisie et de traitement de données pouvant s'adapter à de nombreux domaines d'application.
On atteint au moins l'un des objectifs pré-cités avec un procédé de traitement de données d'évaluation comprenant une phase de saisie de données dans laquelle : a) on crée au moins une entité en fonction de caractéristiques intrinsèques de cette entité, b) on crée et renseigne un état initial de ladite entité, c) on crée et renseigne une action en fonction de l'état initial, puis d) on crée et renseigne, au cours de l'évolution de l'état de ladite entité et à des instants déterminés, des états résultants, ces états résultants étant au moins fonction de l'état initial et de l'action. Des icônes, représentant les Entités, états et actions ainsi créées s'alignent visuellement sur une ligne chronologique. Le fait de cliquer sur l'un de ces icônes donne accès aux données correspondantes.
Le procédé comprend également une phase d'exploitation de données dans laquelle on élabore des données statistiques en fonction de critères déterminés en parcourant la structure d'au moins un des événements a), b) , c) et d) de la phase de saisie.
Avec un tel procédé l'exploitation de données est simplifiée puisque les critères sont obtenus de la même manière que les informations ont été saisies.
Selon une caractéristique avantageuse de l'invention, on stocke les données relatives à chaque entité dans une première base de données "Information", tandis que la structure des événements est contenue dans une seconde base de données "Métabase" indépendante.
En d'autres termes, la Métabase est une base de données contenant la description (hiérarchie, structure et contenus) des différents objets et événements. Elle ne contient aucune information liée aux entités individuelles en elles mêmes. Elle sert uniquement à décrire la structure des objets et événements sur laquelle s'appuient un module de saisie et des modules d'exploitation (échantillonnage et analyse tels que décrits plus loin) . Le module de saisie permet de créer les différents événements et d' afficher leurs structures respectives en fonction des informations qu'il trouve dans la Métabase. Les données saisies sont alors stockées dans la base de données "Information".
Les modules d'exploitation s'appuient également sur la Métabase pour afficher la structure globale et spécifique des événements, afin de permettre à l'utilisateur de choisir ses critères et ses variables pour l'exploitation. Ainsi, les modules de saisie et d'exploitation sont entièrement indépendants de la structure des événements étudiés, et donc du "métier" de l'utilisateur. Ces modules constituent une interface générique.
La structure des événements peut évoluer (ajout ou suppression d'événements ou d'items à saisir) : les modifications sont alors automatiquement répercutées dans les modules de saisie et d'exploitation.
Cette Métabase permet une exploitation et une évolutivité simplifiées du système selon l'invention. La structure de chaque événement peut être de type arborescent. L'arborescence peut être sous forme de fichiers en cascades ou sous forme graphique ou sous toute autre forme .
Selon l'invention, l'exploitation peut comporter une étape d'échantillonnage dans laquelle on sélectionne une sous-population d'entités donnée. En complément notamment de ce qui précède, on peut effectuer la sélection en choisissant au moins une variable dans la structure d'au moins un événement a) , b) , c) ou d) , et en affectant à cette variable une contrainte donnée. Cette contrainte peut être une valeur ou un ensemble de valeurs, ou le caractère "saisi" ou "non saisi", permettant d'échantillonner toutes les entités pour lesquelles une variable spécifique a été saisie ou non. L'exploitation de données peut également comporter une étape d'analyse dans laquelle on élabore des données statistiques sous forme de valeurs, tableaux ou graphiques. De préférence, l'échantillonnage et l'analyse sont distincts, c'est à dire qu'une des deux fonctions peut s'effectuer sans l'autre. On peut également effectuer l'analyse en choisissant au moins une variable dans la structure d'au moins un événement a), b) , c) ou d) .
Selon un mode de mise en œuvre de l'invention, les événements a) , b) , c) et d) sont crées dans un ordre chronologique, notamment au fur et à mesure de l'activité de l'utilisateur. La saisie des informations est ainsi logique et simplifiée.
De préférence, on effectue la saisie au moyen d' interfaces graphiques intuitives. On peut aussi disposer plusieurs interfaces successives détaillant les éléments saisis.
A titre d'exemple, le mode de saisie peut être via un clavier, sur écran tactile ou encore de façon sonore via un micro.
Pour que l'invention puisse s'appliquer à de nombreux domaines, la structure de chaque événement peut être paramétrable par le biais de la Métabase.
Suivant un autre aspect de l'invention, il est proposé un système de traitement de données d'évaluation comprenant des moyens de saisie pour : a) créer au moins une entité en fonction de caractéristiques intrinsèques de cette entité, b) créer et renseigner un état initial de ladite entité, c) créer et renseigner une action en fonction de l'état initial, puis d) créer et renseigner, au cours de l'évolution de l'état de ladite entité et à des instants déterminés, des états résultants, ces états résultants étant au moins fonction de l'état initial et de l'action. Le système comprend également des moyens d'exploitation de données pour élaborer des données statistiques en fonction de critères déterminés en parcourant la structure d'au moins un des événements a), b) , c) et d) .
Selon l'invention, les moyens d'exploitation de données comportent un module d'échantillonnage pour sélectionner une sous-population d'entités donnée et un module d'analyse, de préférence distinct, pour élaborer des données statistiques sous forme de valeurs, tableaux ou graphiques .
Avantageusement, les moyens de saisie et d'exploitation peuvent consister en des interfaces génériques capables d'explorer la structure des événements. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en œuvre nullement limitatif, et des dessins annexés, sur lesquels :
La figure 1 est une vue schématique globale de l'environnement dans lequel peut s'intégrer un système selon l'invention ;
La figure 2 est un schéma illustrant les événements compris dans la phase de saisie ainsi que les modules de traitement pour la phase d' exploitation ; La figure 3 est un schéma illustrant les relations logiques entre les structures d' événements ;
La figure 4 est un schéma illustrant le principe d'une interface de saisie selon l'invention ;
La figure 5 est un schéma illustrant le principe d'une interface de saisie lors d'une phase d'identification du patient;
La figure 6 est un schéma illustrant le principe d'une interface de saisie lors d'un examen pré-opératoire du patient; La figure 7 est un schéma illustrant le principe d'une interface de saisie graphique intuitive lors d'un examen pré-opératoire du patient;
La figure 8 est un schéma illustrant le principe d'une interface de saisie lors d'un examen per-opératoire (une chirurgie) du patient;
La figure 9 est un schéma illustrant le principe d'une interface d'exploitation lors d'un échantillonnage;
La figure 10 est un schéma illustrant le principe d'une interface d'exploitation lors d'une analyse; et
La figure 11 est un schéma illustrant un mode de traitement du module d'échantillonnage et du module d'analyse selon l'invention.
Bien que l'invention n'y soit pas limitée, on va maintenant d'écrire un procédé de saisie et d'exploitation d'informations médicales. Un médecin désire répertorier et analyser l'ensemble de données relatives à ses patients. Il désire également suivre l'évolution de l'état de chaque patient. Sur la figure 1 on distingue un système doté d'un serveur de données 3 appelé "Serveur". Ce serveur de données rassemble dans une base de données "Information", l'ensemble des informations relatives à chaque patient pour lequel le suivi médical est réalisé au moyen d'un procédé selon l'invention. Les informations peuvent être saisies par un médecin 1 au sein d'un micro ordinateur 2 puis transmises vers le serveur 3 pour stockage. Elles peuvent alors être partagées avec d'autres institutions telles qu'une clinique 4 ou un hôpital 5. Les institutions 4 et 5 peuvent également saisir des informations de façon à compléter le dossier d'un patient.
Le médecin et les institutions 4 et 5 possèdent chacun un micro-ordinateur utilisé pour la mise en œuvre du procédé selon l'invention. Chaque micro-ordinateur comporte une base de données "Métabase" selon l'invention dans laquelle est décrite la structure de différents objets et événe ents. Toutefois, conformément à la figure 2 par exemple, chaque micro-ordinateur peut contenir à la fois une base de données "Information" et une base de données "Métabase". Sur les figures 2 et 3, on voit le cheminement logique du traitement de données selon l'invention.
D'une façon générale, sur la figure 2 on distingue, un micro ordinateur 6 permettant la saisie et l'exploitation de données selon l'invention. Le micro-ordinateur 6 contient une base de données "Information" et une base de données "Métabase" paramétrée. L'utilisateur, c'est-à-dire le médecin, pour suivre l'évolution de l'état d'un patient, va créer un ensemble d'événements dans l'ordre chronologique, au fur et à mesure de son activité. La première étape consiste en l'identification ou la définition de l'entité (le patient). Cette étape 7 peut par exemple correspondre aux données telles que le nom et prénom du patient, la date de naissance, un numéro de fichier, le poids, la taille, la profession, les activités sportives... Ces éléments sont des caractéristiques intrinsèques au patient.
L'étape 8 suivante concerne un examen pré-operatoire (diagnostic) au cours duquel le médecin examine le patient de façon à définir la pathologie liée à ce patient. Les éléments saisis par le médecin peuvent être par exemple un rachis dégénératif sous forme d'une hernie discale ayant comme conséquence une incapacité à la marche. Pour enrayer cette pathologie, le médecin peut ensuite mettre en œuvre un traitement tel qu'une opération chirurgicale, une prise de médicaments, ou autres. Ce traitement est une étape 9 d'examen per-opératoire (traitement thérapeutique). Comme décrit sur la figure 1, l'opération chirurgicale peut s'effectuer au sein de la clinique 4, et les informations relatives à cette opération sont donc introduites au cours de l'étape 9. L' étape 10 est une étape post-opératoire (de suivi) au cours de laquelle le médecin effectue plusieurs examens à des instants donnés de façon à vérifier l'évolution de l'état du patient. L'ensemble des informations obtenues au cours de ces examens sont intégrées dans la base de données "Information" au sein du micro ordinateur 6.
Les étapes 7 à 10 concernent donc l'étape de saisie. Ces informations vont être exploitées pour réaliser des échantillonnages 11 de façon à sélectionner des sous- population au sein de l'ensemble des entités. On peut également réaliser des analyses 12 pour élaborer des données statistiques sous forme de valeurs, tableaux ou graphiques.
Chaque étape 7, 8, 9 ou 10 de la phase de saisie constitue un événement. Ces événements obéissent à une chronologie particulière telle que représentée sur la figure 3. L'identification 7 du patient correspond donc à une première étape au cours de laquelle on définit l'entité E (le patient) . Cette identification permet de saisir les caractéristiques intrinsèques de l'entité E (fig.3) indépendamment de sa pathologie. Cette pathologie est déterminée au cours de l'examen pré-opératoire (diagnostic) 8 (fig.2) correspondant en fait à la définition d'un état initial. A une entité E peut correspondre plusieurs états initiaux El, E2 et E3 par exemple (fig.3).
A chaque état initial, on peut appliquer une action donnée telle que par exemple un traitement médical ou une opération chirurgicale. A l'état initial El, peuvent être appliquées les actions Al-1, Al-2 ou Al-3. Ainsi, à un état initial peut correspondre plusieurs actions. Par contre, à une action correspond un et un seul état résultant Ri-i. En effet, lorsqu'un médecin examine un patient ayant suivi un traitement médical, l'état du patient est l'unique état observé au moment de cet examen post-opératoire. Bien entendu plusieurs examens post-opératoires (de suivi) peuvent se succéder en donnant chacun un état résultant spécifique.
La figure 4 est un exemple d'une interface de saisie. Cette interface comprend une partie supérieure comportant une première zone 13 pour indiquer quelques éléments d' identification du patient tels que par exemple le nom, prénom, date de naissance et numéro du fichier correspondant. La partie supérieure comprend également une seconde zone 14 pour la création d'événements pré- opératoire, per-opératoire et post-opératoire ; et une troisième zone 15 d'information générale telle que le retour à un menu sommaire, le lancement d'impression ou l'affichage d'images associées à l'événement en cours.
L'interface de saisie comprend également une zone intermédiaire 16 illustrant la ligne chronologique. Cette zone historique 16 comporte plusieurs événements disposés les uns à la suite des autres de façon chronologique. Le premier élément est l'identification de l'entité E, du patient. L'événement suivant est la définition d'un état initial E-l réalisé au cours d'un examen pré-opératoire (diagnostic) . Le traitement médical ou la chirurgie appliquée au patient au cours de l'étape per-opératoire 9 correspond à une action Al-1. Trois examens postopératoires (de suivi) (Rl-l(l), Rl-1(2), Rl-1(3)) sont successivement disposés sur la ligne chronologique avant la définition d'un second état initial E-2. Ce second état initial est suivi d'une seconde action A2-1 et d'un état résultant R2-1 (1) correspondant à cette seconde action.
En sélectionnant un des événements disposés dans la zone historique 16, la structure de cet événement est développée dans une zone 17 inférieure gauche. La structure représentée sur la zone 17 est de type arborescent. Ce type de structure peut être le même pour tous les événements, mais on peut aussi avoir un type de structure donné pour chaque type d'événement. Dans la structure arborescente de la zone 17, l'événement sélectionné comporte des sous- événements ou des fiches, et chaque sous-événement comporte encore d'autres sous événements ou d'autres fiches et ainsi de suite. Chaque fiche est paramétrable selon la volonté de l'utilisateur. C'est à dire qu'en fonction de l'activité (médicale ou non) de l'utilisateur, ce dernier peut définir l'arborescence ainsi que le contenu de chaque fichier, sous-événement et événement. Le paramétrage est opéré au sein de la "Métabase". Toute modification de la Métabase est automatiquement répercutée dans les modules de saisie et d'exploitation. A titre d'exemple, la description d'événements contenue dans la Métabase comprend notamment une hiérarchie telle que représentée sur la figure 3, et des structures telles que celles représentées dans la zone 17 de la figure 4. Les fiches comprennent notamment des variables qui serviront par la suite pour l'échantillonnage et l'analyse. Ces variables sont en fait des champs contenant ou non des informations saisies par le médecin. Ces informations sont introduites via une zone de saisie 18 sous différentes formes telles que des menus déroulants, des listes a choix multiples, des champs de saisie manuelle, des champs calculés automatiquement, des interfaces graphiques...
La figure 5 est une vue d'une interface illustrant la saisie d'information lors de l'identification du patient. La zone 17 montre l'arborescence détaillée de la structure, et la zone 18 montre le type de données à saisir.
La figure 6 est une vue correspondant à une étape 8 d'examen pré-opératoire (diagnostic) au cours duquel le médecin définit dans un premier temps qu'il s'agit d'une pathologie de type "rachis génératif" au moyen d'interfaces graphiques représentant le squelette humain ainsi que le zoom d'une partie de ce squelette pointée par le médecin. La figure 7 est une vue de la suite de l'examen préopératoire (diagnostic) permettant de définir de façon plus précise le type du "rachis génératif". Le médecin peut ainsi définir qu'il s'agit d'une hernie discale et spécifier l'endroit exact sur la colonne vertébrale. Cette définition est réalisée au moyen de graphiques interactifs intuitifs, une sorte d'arborescence graphique, chaque partie du squelette étant paramétrée. L'étape 9 (fig.2) d'examen per-opératoire fait intervenir une opération chirurgicale pour laquelle une interface de saisie est telle que représentée sur la figure 8. On distingue dans la zone 17 une structure arborescente illustrant les sous-événements et les fiches. La fiche sélectionnée contient les caractéristiques générales de l'opération chirurgicale (action thérapeutique), ces caractéristiques étant détaillées dans la zone 18 de la figure 8.
De la même manière, les informations relatives à chaque examen post-opératoire (de suivi) peuvent être saisies dans la base de données "Information".
Les informations saisies peuvent ensuite être manipulées de façon à sélectionner par exemple une sous population de patients au moyen d'un échantillonnage (figure 9) . Sur la figure 9 est représentée une interface pour la définition d'un échantillonnage. La zone historique
16 comporte plusieurs événements. Pour effectuer l'échantillonnage, le médecin doit spécifier d'une part la ou les variables à prendre en compte ainsi que les contraintes à appliquer sur cette variable.
Avantageusement, pour sélectionner la variable à prendre en compte, le médecin sélectionne un des événements affichés sur la zone historique 16. Sur la figure 9, l'événement correspondant à "l'identification du patient" est sélectionné, il s'agit du premier événement. Ainsi, sur la zone 17 s'affiche la structure arborescente correspondant à l'événement d'identification du patient. C'est la même structure que celle représentée dans la zone 17 de la figure 5. Le médecin va parcourir la structure jusqu'à sélectionner la variable désirée, en l'espèce le poids. Il peut ensuite spécifier la contrainte, par exemple un poids inférieur à 50 kg. On a ainsi simplement isolé une sous- population de patients ayant un poids inférieur à 50 Kg. Plusieurs critères d' échantillonnage peuvent également être combinés suivant des opérations logiques (opérations booléennes) .
Une fois l'échantillonnage réalisé, la sous-population de patients ainsi sélectionnée peut alors être analysée.
Le médecin peut lancer soit une analyse pré-établie telle que de type statistique élémentaire, diagramme bi- varié-régression, diagramme d'évolution, courbe de survie, test non paramétrique (t ou Khi 2)..., soit une nouvelle analyse qu' il va créer en explorant les informations disponibles dans la méta-base.
Pour créer la nouvelle analyse, le médecin a besoin de définir une variable. Pour ce faire, il sélectionne d'abord un événement dans la zone historique 16, en l'espèce l'événement pré-opératoire (diagnostic) (fig.10). Sur la zone 17 de la figure 10 s'affiche alors la structure arborescente correspondant à l'événement pré-opératoire (diagnostic) sélectionné. On retrouve la structure de la zone 17 de la figure 6. Le médecin peut alors parcourir la structure jusqu'à atteindre la variable "diagnostique principal" .
La figure 11 est un schéma d'ensemble illustrant les flux d'informations entre la méta-base, la base de données "Information", les événements, le module d'échantillonnage et le module d'analyse. Ces deux derniers modules prélèvent les informations dans la . méta-base pour réaliser leurs fonctions. La fonction d'analyse peut en outre nécessiter des données provenant de l'échantillonnage pour établir notamment des graphes 19. Les flux en pointillés concernent les flux d'information "METABASE", et les flux en traits pleins concernent les informations saisies et exploitées. Les événements sont créés au moyen de données provenant à la fois de la METABASE et de la base de données "Information" . De même, la saisie et l'exploitation prennent en compte les deux bases de données.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

Claims

REVENDICATIO S
1. Procédé de traitement de données d'évaluation comprenant une phase de saisie de données dans laquelle : a) on crée au moins une entité en fonction de caractéristiques intrinsèques de cette entité, b) on crée et renseigne un état initial de ladite entité, c) on crée et renseigne une action en fonction de l'état initial, puis d) on crée et renseigne, au cours de l'évolution de l'état de ladite entité et à des instants déterminés, des états résultants, ces états résultants étant au moins fonction de l'état initial et de l'action; une seconde phase d'exploitation de données dans laquelle on élabore des données statistiques en fonction de critères déterminés en parcourant la structure d'au moins un des événements a), b) , c) et d) de la phase de saisie.
2. Procédé selon la revendication 1, caractérisé en ce qu'on stocke les données relatives à chaque entité dans une première base de données "Information", tandis que la structure des événements est contenue dans une seconde base de données "Métabase" indépendante.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'exploitation comporte une étape d'échantillonnage dans laquelle on sélectionne une sous-population d'entités donnée.
4. Procédé selon la revendication 3, caractérisé en ce qu'on effectue la sélection en choisissant au moins une variable dans la structure d'au moins un événement a), b) , c) ou d) , et en affectant à cette variable une contrainte donnée .
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'exploitation comporte une étape d'analyse dans laquelle on élabore des données statistiques sous forme de valeurs, tableaux ou graphiques.
6. Procédé selon la revendication 5, caractérisé en ce qu'on effectue l'analyse en choisissant au moins une variable dans la structure d'au moins un événement a), b) , c) ou d) .
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les événements a) , b) , c) et d) sont créés dans un ordre chronologique.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on effectue la saisie au moyen d'interfaces graphiques intuitives.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la structure de chaque événement est paramétrable par le biais de la métabase.
10. Système de traitement de données d'évaluation comprenant des moyens de saisie pour : a) créer au moins une entité en fonction de caractéristiques intrinsèques de cette entité, b) créer et renseigner un état initial de ladite entité, c) créer et renseigner une action en fonction de l'état initial, puis d) créer et renseigner, au cours de l'évolution de l'état de ladite entité et à des instants déterminés, des états résultants, ces états résultants étant au moins fonction de l'état initial et de l'action; et des moyens d'exploitation de données pour élaborer des données statistiques en fonction de critères déterminés en parcourant la structure d'au moins un des événements a), b) , c) et d) .
11. Système selon la revendication 10, caractérisé en ce qu'il comprend une première base de données "Information" pour stocker les données relatives à chaque entité et une seconde base de données "Métabase" indépendante contenant la structure des événements.
12. Système selon la revendication 10 ou 11, caractérisé en ce que les moyens d'exploitation de données comportent un module d'échantillonnage pour sélectionner une sous- population d'entités donnée et un module d'analyse pour élaborer des données statistiques sous forme de valeurs, tableaux ou graphiques .
13. Système selon la revendication 11 ou 12, caractérisé en ce que les moyens de saisie et d'exploitation consiste en des interfaces génériques capables d'explorer la structure des événements.
EP03782536A 2002-11-08 2003-11-07 Procédé et syst me de traitement de données d'évaluation Withdrawn EP1590758A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0214074A FR2847056B1 (fr) 2002-11-08 2002-11-08 Procede et systeme de traitement de donnees d'evaluation
FR0214074 2002-11-08
PCT/FR2003/003339 WO2004044813A1 (fr) 2002-11-08 2003-11-07 Procédé et système de traitement de données d'évaluation

Publications (1)

Publication Number Publication Date
EP1590758A1 true EP1590758A1 (fr) 2005-11-02

Family

ID=32116514

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03782536A Withdrawn EP1590758A1 (fr) 2002-11-08 2003-11-07 Procédé et syst me de traitement de données d'évaluation

Country Status (5)

Country Link
US (1) US20060036408A1 (fr)
EP (1) EP1590758A1 (fr)
AU (1) AU2003290172A1 (fr)
FR (1) FR2847056B1 (fr)
WO (1) WO2004044813A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8903794B2 (en) * 2010-02-05 2014-12-02 Microsoft Corporation Generating and presenting lateral concepts
US8983989B2 (en) * 2010-02-05 2015-03-17 Microsoft Technology Licensing, Llc Contextual queries
US8150859B2 (en) 2010-02-05 2012-04-03 Microsoft Corporation Semantic table of contents for search results
US20110231395A1 (en) * 2010-03-19 2011-09-22 Microsoft Corporation Presenting answers
US20110302149A1 (en) * 2010-06-07 2011-12-08 Microsoft Corporation Identifying dominant concepts across multiple sources
US11061918B2 (en) 2017-04-05 2021-07-13 Splunk Inc. Locating and categorizing data using inverted indexes
US11106713B2 (en) * 2017-04-05 2021-08-31 Splunk Inc. Sampling data using inverted indexes in response to grouping selection
US10853399B2 (en) 2017-04-05 2020-12-01 Splunk Inc. User interface search tool for locating and summarizing data

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230142B1 (en) * 1997-12-24 2001-05-08 Homeopt, Llc Health care data manipulation and analysis system
US6820235B1 (en) * 1998-06-05 2004-11-16 Phase Forward Inc. Clinical trial data management system and method
GB2354853A (en) * 1999-06-09 2001-04-04 Curapath Systems Inc Computer modelling of health care procedures
IL152740A0 (en) * 2000-05-31 2003-06-24 Fasttrack Systems Inc Clinical trials management system and method

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
FR2847056A1 (fr) 2004-05-14
WO2004044813A1 (fr) 2004-05-27
AU2003290172A1 (en) 2004-06-03
US20060036408A1 (en) 2006-02-16
FR2847056B1 (fr) 2006-03-03

Similar Documents

Publication Publication Date Title
Al Jarullah Decision tree discovery for the diagnosis of type II diabetes
US20080208624A1 (en) Methods and systems for providing clinical display and search of electronic medical record data from a variety of information systems
US20120066000A1 (en) Clinical decision support systems with external context
AU2006210141A1 (en) Knowledge discovery tool navigation
AU2006210142A1 (en) Knowledge discovery tool relationship generation
CN110709864A (zh) 人机回环交互式模型训练
US20200303071A1 (en) Implementation of machine-learning based query construction and pattern identification through visualization in user interfaces
Jasper et al. MouseTrace: A better mousetrap for catching decision processes
EP1590758A1 (fr) Procédé et syst me de traitement de données d'évaluation
WO2012093363A2 (fr) Accès intégré et interaction avec une multiplicité de modules d'analyse de données cliniques
EP2504756A1 (fr) Outil d'exploration et d'analyse de données cliniques
US20080270183A1 (en) Systems and methods for presentation of clinical evidence for diagnostic interpretation
Kavitha et al. Systematic view and impact of artificial intelligence in smart healthcare systems, principles, challenges and applications
WO2011163234A1 (fr) Affichage à facettes sélectionnables par cohorte
US8423553B2 (en) Graphically displaying a file system
FR2892840A1 (fr) Procede et systeme de generation d'un manuel technique.
Wietlisbach et al. Statistical approaches in the development of clinical practice guidelines from expert panels: the case of laminectomy in sciatica patients
WO2018229429A1 (fr) Dispositif de gestion patient
Ledieu et al. Clinical data analytics with time-related graphical user interfaces: Application to pharmacovigilance
JP5176617B2 (ja) メニュー画面表示プログラム、メニュー画面表示方法およびメニュー画面表示装置
JP5003004B2 (ja) バリアンス根本原因分析支援システム
US20130218593A1 (en) Usage of assigned treatment in clinical decision support systems
WO2013177422A1 (fr) Système de mise en ordre et d'agencement d'un ensemble de données
Munsaka et al. Visual analytics of safety and benefit-risk from clinical trial data
EP3686897A1 (fr) Procédé et unité de traitement de données de sélection d'un programme informatique d'évaluation du risque

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: 20050527

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

DAX Request for extension of the european patent (deleted)
RIN1 Information on inventor provided before grant (corrected)

Inventor name: CHERRAK, ILHEM

Inventor name: NODE-LANGLOIS, LAURENT

Inventor name: TEMPLIER, ALEXANDRE

17Q First examination report despatched

Effective date: 20090409

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: 20090603