WO2007132006A1 - Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation - Google Patents

Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation Download PDF

Info

Publication number
WO2007132006A1
WO2007132006A1 PCT/EP2007/054705 EP2007054705W WO2007132006A1 WO 2007132006 A1 WO2007132006 A1 WO 2007132006A1 EP 2007054705 W EP2007054705 W EP 2007054705W WO 2007132006 A1 WO2007132006 A1 WO 2007132006A1
Authority
WO
WIPO (PCT)
Prior art keywords
evaluation
data
file
patient
source
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.)
Ceased
Application number
PCT/EP2007/054705
Other languages
English (en)
Inventor
Nicolas Glatt
Antoine Angenieux
Thomas Glatt
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.)
CLINIGRID
Original Assignee
CLINIGRID
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 CLINIGRID filed Critical CLINIGRID
Priority to US12/300,994 priority Critical patent/US20110270621A1/en
Priority to EP07729154A priority patent/EP2024887A1/fr
Publication of WO2007132006A1 publication Critical patent/WO2007132006A1/fr
Anticipated expiration legal-status Critical
Ceased 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/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Definitions

  • the invention relates to methods and systems for managing medical data or in connection with medical practice and managing the transmission of such data to third parties.
  • Such methods and management systems are known for example to allow the doctor to enter for each patient on a computer or paper support the information collected during the diagnostic or therapeutic act.
  • patient data contribute to a patient record.
  • This patient file is kept in the care facility for a legal period and is a forensic document.
  • An evaluation or control procedure consists of a generally prospective study, carried out in one or more health care structures, and aims to test the tolerance and / or efficacy and / or the correct use of medical devices, drugs or method of care.
  • This study is structured around a protocol that is defined for each study: - the question to which the study must provide an answer,
  • CRF term common in the medical community and which corresponds to the initials of the Anglo-Saxon word “case report form”
  • evaluation operation the follow-up steps of the patients included in the operation and the information that must be collected during these follow-ups.
  • Such an evaluation process may be intended to serve as a basis for a scientific, economic or regulatory research study. All of these steps are referred to hereinafter as the "evaluation operation".
  • caregivers agree to provide the sponsor with information on selected patients.
  • Each of these patients signs a consent that authorizes the transmission of their data, on condition of anonymity, to a sponsor.
  • This information is very diverse in nature and includes data on demographic characteristics, epidemiological, physical, physiological, pathological, or mental aspects of a patient.
  • This information also relates to the medical or surgical care provided or to be provided, as well as the different products that can be used to perform such care.
  • the care provider When including a patient in an evaluation operation, the care provider proceeds to the creation of a CRF.
  • This FIU is provided by the promoter of the evaluation operation to the care providers, either on paper or on a computer support.
  • the care provider must make a copy of the information contained in the patient's forensic file.
  • the information thus collected is designated evaluation data and constitutes the data of the evaluation files.
  • the care provider must therefore, from the patient file: check that the "patient" data correspond to the inclusion and exclusion criteria set by the sponsor, re-enter data collected during the diagnostic or therapeutic procedure, monitor patients at a frequency defined by the protocol of the evaluation operation, ensure that the evaluation file is updated by reporting any events that occurred during the follow-up period.
  • constraints and regulations that apply to the use of medical data involve special treatment. These constraints and regulations require, among other things, that the signature of the care provider (s) having entered or modified data in the evaluation file be affixed to these data, that the traceability of the data provided be possible, and that the data transmitted be anonymous.
  • Assessment data from each health facility participating in the assessment operation is centralized and consolidated in a database.
  • This stage implies that the sponsor's staff or service providers move to each of the care facilities.
  • the current process causes a time lag between the capture of patient data and the availability of evaluable data that can be used by the sponsor.
  • This time lag is due to the time required to re-enter the data, to the routing (if the medium is the paper) and to the control of the evaluation data. This time lag limits the effectiveness of evaluation operations.
  • control of the transmitted data is in practice essential to ensure the relevance of the exploitation of the data received by the promoter.
  • this phase of control represents a significant loss of time, a significant need for staff, and induces a substantial financial burden.
  • the main purpose of evaluation operations is, for a given period, - collect data from all files that meet a group of well-defined target criteria (studies),
  • the promoter centralises and exploits evaluation data from several structures for a defined period.
  • the relevance of the results of these operations is based on the conditions of completeness and consecutivity.
  • the condition of completeness implies that all patients who have undergone a given treatment are included in the evaluation operation.
  • condition of consecutivity requires that all consecutive patients with defined criteria undergo a given treatment and are therefore included in the evaluation operation.
  • the re-entry of the patient data is accompanied by a reprocessing to make these data conform to the requirements and regulations (requirement of anonymisation for example).
  • This reprocessing can therefore be accompanied by error since it does not consist of a simple duplication of all the data.
  • the promoter of an evaluation operation defines a certain number of criteria that a patient file must present in order for the data contained therein to be included in the evaluation operation.
  • the re-entry of the information therefore imposes a verification of the concordance of the criteria with the data of each patient record.
  • the current processes do not guarantee sufficient security adapted to the sensitivity of the information entered. This lack of security concerns as much the possibilities of access to information as the possibilities of modification of this information. Indeed, the current processes do not offer means of controlling the identity of people wishing to access data or wishing to add or modify data.
  • the term material within the meaning of the present invention, includes all drugs, products and medical and surgical diagnostic and treatment materials.
  • the manufacturer can not differentiate between lost hardware, defective hardware, unsuccessful hardware, and mistakenly deserterized hardware. But from a point of view feedback from the material, as from a financial point of view, this information is very important. In practice, the promoter of an evaluation operation tries to obtain this information during the on-site visit of one of their representatives.
  • Hardware identification is based on specific systems for each hardware vendor. These systems are numerous and are not subject to any international standardization. In general, the identification of medical devices is managed within each health facility, not by unit, but by type and batch of equipment.
  • the invention aims to improve the current processes and systems for managing information relating to the diagnostic or therapeutic management of a patient in a medical environment and transmitting information relating to this care to third parties.
  • the invention relates to a set of applications for optimizing the management of this information.
  • the present invention provides a method for managing data relating to a patient in the context of an evaluation operation conducted in at least one care center, comprising the steps of:
  • the management method according to the invention may furthermore optionally have at least one of the following characteristics:
  • the validation of the pre-inclusion is carried out during the validation of the seizure, the validation of the pre-inclusion is carried out after the validation of the seizure,
  • the validation of the pre-inclusion also entails a step of reprocessing the potential evaluation file comprising in particular an anonymisation of this file, the comparison between the inclusion criteria provided by the promoter of the evaluation operation and the data in the source folder is done by a person or by a search engine,
  • the management method comprises a step of modifying or adding data in the evaluation file (CRF), a validation step of the completion and an automatic recording of the evaluation file (CRF) thus modified,
  • - the validation of the entry, and / or the validation of the pre-inclusion, and / or the validation of the inclusion, and / or the validation of the completion includes a step of access control of the person carrying out the validation, and a step of collecting and recording information allowing the traceability of the validation
  • the evaluation file (CRF) is sent to a central evaluation database which is accessed by the promoter of the evaluation operation
  • the central evaluation database collecting the evaluation files (CRF) relating to this evaluation operation in each of the health centers,
  • a modification of the evaluation file automatically entails a synchronized modification of the evaluation file (CRF) contained in the central evaluation database, - data contained in the source files are transmitted to a hardware module allowing inventory management of materials,
  • the data contained in the source files are compared with the data relating to the material, these data being contained in a material module, and it is verified that each patient presenting the inclusion criteria has been the subject of a treatment associated with these criteria in order to fulfill the condition of consecutivity.
  • the invention further relates to a system for managing data relating to a patient in the context of an evaluation operation carried out in at least one health center, comprising
  • a patient module comprising: o at least one patient data entry terminal for forming a patient file, o a patient application enabling the validation of this input, the patient application performing an automatic processing of the patient file to constitute a source file that respects one or several regulatory requirements,
  • a source database deployed in the health center participating in the evaluation operation and in which the source file is recorded
  • FIG. a data management system according to a first exemplary embodiment
  • FIG. 2 is a diagram of a data management system according to second exemplary embodiment
  • FIG. 1 there is illustrated the data management system 1 according to an exemplary embodiment.
  • This management system 1 comprises in particular a patient module 110 for entering data relating to a patient, a local evaluation module 120 for data from the patient module 110 into an evaluation operation, and a data synchronization module 130 between 110 and 120, these three modules being deployed in each of the care centers.
  • the system also includes three modules common to all health centers: a central evaluation module 400 for centralizing the data of the local evaluation module 120 of each of the care centers 100, 200, 300.
  • a server module central 600 ensuring the management of messages between the various modules of the system, - a hardware module 500 managing information relating to equipment, drugs and generally products used for the diagnosis and treatment of patients.
  • the management system 1 of the information is subsequently described following the main flow of the data.
  • Patient module 110 for entering data relating to a patient
  • a local evaluation module 120 for data from the patient module 110 into an evaluation operation
  • a data synchronization module 130 between 110 and 120, these three modules being deployed in each of the care centers.
  • the system also includes three modules common to all health centers:
  • the patient module 110 comprises one or more seizure terminals 112, 113, 114. These seizure terminals 112, 113, 114 are located in an operating room, or a room in a care center.
  • the patient module 110 also comprises a patient application 115.
  • the patient application 115 checks the identity of the person wishing to validate the entry. This check can be done using a password or a biometric check. The person whose identity is verified and who is authorized to enter data can then validate the seizure. This person, usually a doctor or a medical person, is subsequently designated as an authorized person.
  • the patient application 115 then performs data processing. This process transforms input data to meet a number of regulatory requirements. These regulatory requirements require, for example, that each data entry be validated by means of a signature affixed by the authorized person.
  • the patient module 110 comprises means enabling the opposition of a signature, for example electronically or by the use of a professional health card.
  • These regulatory requirements also require that perfect traceability can be established for each addition or modification of data. Such traceability includes in particular the identity of the authorized person, the date of the seizure, the object of the seizure etc.
  • the data entered and reprocessed are of a source character and will retain this source character regardless of the subsequent treatments that will be applied to them.
  • source data all of these data relating to a patient is designated source folder and the set of source data contained in the source folders constitutes a database called source database.
  • This patient database 10 is part of the patient module 110 and is located in the care center 100.
  • This source database communicates with another database belonging to the local evaluation module 120 and which is also located in the health center 100. This other database is called the local evaluation database 20. Module Local evaluation 120.
  • the inclusion of a patient in an evaluation operation means that data relating to that patient will be used as part of the evaluation operation.
  • the promoter of an evaluation operation defines a certain number of criteria called inclusion criteria that the data of a patient file will have to present in order for it to be included in the evaluation operation.
  • file inclusion is also used to signify that patient data is collected for the purpose of being exploited as part of an evaluation operation.
  • the local evaluation module 120 includes a local evaluation application 121 and a local evaluation database 20.
  • the local evaluation application 120 makes it possible to receive a request to initialize an evaluation operation.
  • a request to initialize an evaluation operation contains all the information necessary for the conduct of an evaluation operation in accordance with the promoter's requirements and the regulatory recommendations. Thus, such a request notably comprises the following information:
  • evaluation files or CRFs the forms specific to the evaluation operation, hereinafter referred to as evaluation files or CRFs, and the control and coherence rules applied to these forms
  • the patient module 110 allows the pre-inclusion, in an evaluation operation, of a source folder directly from the patient application 115 without any re-entry when: entering the information relating to the clinical state of the patient, to the diagnostic or therapeutic act performed via the terminals 112, 113, 114.
  • the authorized person decides whether or not a source file should be included in a given evaluation operation. This choice of the authorized person generally results from a comparison between the inclusion criteria defined in the request provided by the promoter and the data present in the source file.
  • the pre-inclusion is performed at the level of the local evaluation module 120.
  • the comparison of the inclusion criteria and the source data can be established automatically by the local evaluation application 121.
  • the possibilities of performing the pre-inclusion from the patient module 110 and from the evaluation module 120 are both represented in FIGS. 1 and 2.
  • the validation of the pre-inclusion can be subordinated to the control of the authorization of this person, and may also be subject to affixing by an electronic signature.
  • This pre-inclusion consists of: - Automatically duplicate a source folder to create a copy of the source folder,
  • This pre-inclusion treatment consists, for example, in anonymizing the entire copy of the source file in order to delete any information related to the legal personality of the patient whose data constitutes the source file.
  • Other treatments may be provided such as the addition of information relating to the pre-inclusion step, to allow traceability of this step. This information can be entered manually or can be added automatically when validating the entry.
  • This potential evaluation file is contained in the local evaluation database 20.
  • Security means substantially identical to the means ensuring the security of access to the patient application 115 and the source database can control access to the local evaluation application 121 and the local database of evaluation 20. Thus, only the investigators can access the local evaluation module 120.
  • Validation of the inclusion is subject to the apposition by the investigator of an electronic signature. This apposition is carried out by the investigator in the application 121.
  • the data contained in the potential evaluation file whose inclusion is validated are then exported to the forms specific to the evaluation operation, and constitute an evaluation file, also designated CRF thereafter. This CRF is then registered in the local evaluation database 20.
  • the potential assessment file and the CRF are recorded in separate databases and located in the health center. As soon as a CRF is registered in the local evaluation database 20, the information contained in this CRF is made accessible to the promoter of the evaluation operation. The details of CRF transmission from the health center to the sponsor are explained later.
  • the local evaluation application 121 When a file is included, the local evaluation application 121 then shows whether all the data required by the promoter in the request is present in this FIU.
  • the evaluation application 121 allows the investigator, if necessary, and according to the protocol-specific management rules of the evaluation operation, to complete, or modify, the data of the CRF during the duration of the operation. devaluation. These changes will be made by the investigator in different ways depending on the origin of the data.
  • the investigator must modify the source of the data from the application 115. This modification will lead to the generation of a request for compliance of the patient record data with the CRF data. .
  • the local evaluation database 20 therefore includes both potential evaluation records that require validation by the investigator, and CRFs.
  • a FIU complies with both the regulatory requirements and those defined by the sponsor, both from the point of view of the data it contains and from the point of view of the presentation of these data.
  • a request provided by a promoter is specific to an evaluation operation, therefore, a CRF included on the basis of such a request is also specific to an evaluation operation.
  • the automatic processing of the data entered in source data and the automatic duplication of the source data to constitute a potential evaluation file makes it possible not to have to reenter the information contained in a source file.
  • the management system 1 therefore allows substantial time savings and cost reductions related to the re-entry of information and their necessary control.
  • the promoter is thus assured of having reliable data to carry out his evaluation operation.
  • the control of the data can then be limited to the data not present in the source folder.
  • Approved persons also have a unique evaluation application to manage all evaluation operations in which they participate. This helps to reduce the time required for the investigator to take control of the solution and limits the resources required for the sponsor to ensure the transfer of competence.
  • the data used as a basis for setting up FIUs are source data, which by definition comply with the regulatory requirements related to the manipulation of these data. It is possible to manipulate these data at any time since this source character is kept over time.
  • the management system 1 makes it possible to carry out an evaluation operation a posteriori, that is to say to carry out an evaluation operation from data entered prior to the initialization of this same operation.
  • the management system 1 also comprises a multicriteria search engine associated with the patient database 10.
  • the search engine makes it possible to receive search instructions that are established by the investigator when a search operation is performed. ex-post evaluation is requested. It is also planned that the promoter wishing to initiate an evaluation operation may directly launch such a search. The launch of this research by the sponsor is subject to the legal agreement of the investigator. Obtaining this agreement may be controlled by appropriate control means, such as access codes, etc.
  • the search engine identifies all source folders that match the criteria defined in the query. The search engine then delivers as a result the list of all these source files.
  • the investigator determines which records he wishes to include in the evaluation operation.
  • the evaluation application generates as many CRFs as selected source files in the search result, these CRFs containing the data contained in the selected source folders. These FIUs are recorded in the evaluation database 20.
  • the management system 1 makes it possible to perform this type of evaluation operation a posteriori since the search engine searches for data that has a source character and that it is therefore possible to manipulate.
  • the systems and processes of the prior art do not make it possible to carry out evaluation operations a posteriori since they do not propose a database that collects all the files seized and whose data have a character source.
  • inclusion in an evaluation operation may be performed by the investigator directly from the patient module
  • the CRF is created directly by the evaluation module 120 without a validation distinct from the pre-inclusion being imposed on the operator.
  • This variant brings simplicity, time saving, and flexibility of use for the creation of a CRF.
  • the central server module 600 enables the management of messages between the care centers 100, 200, 300 and the central evaluation module 400.
  • This central evaluation module 400 is a web application, comprising central evaluation applications 411, 412, 413. Each of these central evaluation applications 411, 412, 413 is respectively associated with a central evaluation database 421, 422, 423.
  • the central evaluation module 400 also comprises, for each of the central evaluation applications 411, 412, 413, a client application 641, 642, 643.
  • the role of a client application 641, 642, 643, is to establish communication between the central evaluation application with which it is associated and the different modules of the management system 1.
  • the central server module 400 enables the collection of the CRFs of all the health centers 100, 200, 300 participating in evaluation operations.
  • Each of the central evaluation databases 421, 422, 423 is specific to a particular evaluation operation, and contains the CRFs of all care centers that are specific to that evaluation operation.
  • the central evaluation module 400 contains as many central evaluation applications 411, 412, 413, and as many central evaluation databases 421, 422, 423, as there are evaluation operations.
  • FIG. 1 thus shows three central evaluation applications 411, 412, 413, each associated with a central evaluation database 421, 422, 423, each of these central databases gathering the CRFs relating to a specific evaluation operation.
  • the promoter of an operation accesses the CRFs contained in the central evaluation database corresponding to the evaluation operation he initiated. This access is controlled by means of appropriate devices such as access codes.
  • the central server module 600 comprises a central server application 610 which is an application dedicated to the management of messages between the care centers 100, 200, 300 and the modules 400 and 500.
  • This message management application ensures the conformity of exchanges made within the system with legal recommendations and obligations.
  • This application manages, for example, the encoding and securing of the information flows between the various applications of the system, the non-repudiation of the information, and in general any process necessary to implement to ensure the users of the system a conformity with the legislation in force.
  • the central server application 610 manages the information flows and their routing to the various modules of the system.
  • the modules 110, 120, 400 and 500 each comprise a client application, respectively referenced 603, 602, 650, 641, 642, 643.
  • the central server module 600 allows communication between the various modules 110, 120, 400, 500, via their respective client application 603, 602, 650, 641, 642, 643.
  • the module 600 can provide synchronous or asynchronous management of the messages sent by the modules 110, 120, 400 and 500 according to the needs of the users.
  • the client application 602 associated with the local evaluation application 121 contained in the local evaluation module 120 establishes, for example secure communication with the central server application 610.
  • the client application 602 When a CRF is created, the client application 602 sends a message to the client applications 641, 642 or 643 which is dedicated to the evaluation operation for which the CRF has been generated.
  • the central evaluation database associated with this client application collects the newly created CRF.
  • the modules 110 and 120 comprise a common client application 601.
  • This common client application 601 communicates between the central server application 610 of the central server module 600 and the applications 115, on the other hand.
  • the client applications 602, 603 do not communicate directly with the central server application 610.
  • the central evaluation module 400 comprises a client application 640 which provides the communication between the central server application 610 of the central server module 600, and the client applications 641, 642, on the other hand. 643.
  • the client applications 641, 642, 643 do not communicate directly with the central server application 610.
  • the management system 1 also includes a synchronization application 130 dedicated to controlling the synchronization of data between the patient's file and the CRF within the care center 100.
  • the source data is modified according to the conditions required to assume a source character
  • an application makes it possible to synchronize the data of the source files and the data of the CRFs.
  • the data of this CRF are synchronized with those of the CRF contained in the central database.
  • This synchronization of data makes it possible to ensure real-time compliance between the data entered by the authorized person and the data used by the promoter.
  • Auditing of data by an auditor is thus limited to data not present in the patient record.
  • This data synchronization therefore leads to a substantial reduction in data control costs.
  • this data synchronization allows promoters to have useful information as soon as they are entered by the authorized person.
  • Hardware module 500
  • the management system 1 of the information relating to a patient in a medical environment makes it possible to improve the traceability, and to facilitate the mission materovigilance of health care providers and the precise management of material deposits.
  • Hardware manufacturers have a tool dedicated to the management of material depots. This tool, referred to as the hardware module 500, is associated with the application at the central server module 600. It includes one or more hardware client applications and one or more hardware databases (not shown).
  • This catalog is a product repository that respects the product description nomenclature specific to each manufacturer.
  • the hardware manufacturer can create a new reference in his repository, modify a reference or archive a reference.
  • the hardware module 500 establishes a connection with all the care structures equipped with the patient application 115, via the client application 603 (or 601 in the case of the configuration of example 2) and transmits the updates to realized in the different catalogs.
  • the equipment is equipped with a bar code, or a radio frequency label arranged by the manufacturer in coherence with its catalog.
  • Each material is identified when it is introduced into the stock of the health center 100, when it leaves the stock and when it is used. In some cases, it may be expected to identify the equipment at one of the steps of out of stock or use.
  • This tracking of each of the materials provides a very accurate knowledge of the stock of equipment.
  • the patient application 115 establishes a connection with the hardware module 500 and transmits the information relating to this input, exit or use.
  • the manufacturers, users of the hardware module 500 can thus check the stock status of each of the health centers.
  • the information that the patient application 115 transmits to the hardware module 500 is not however limited to the stock level.
  • the patient application 115 transmits to the hardware module 500 other information on the state of each of the materials, such as information on the expiry date of these materials.
  • an alert is transmitted by the patient application 115 to the hardware module 500 when the expiration date of a material expires.
  • material information All the information concerning the materials and in particular the coming into stock, the out of stock, the use, the nature, the expiry date, the instructions and precautions are hereinafter referred to as material information.
  • the patient application 115 makes it possible to declare that a material has been damaged, has not been used successfully or has been de-sterilized by mistake. This information is used to initiate materiovigilance procedures, and to provide manufacturers with accurate data to make improvements to this type of equipment.
  • the system makes it possible to fulfill the conditions of completeness and consecutivity necessary for the relevance of an evaluation operation.
  • the promoter has the information relating to the use of this material thanks to the hardware module 500. Indeed, and as indicated previously the tracking of a given material is possible from the hardware module 500. Thus, even if the information relating to the treatment suffered by the patient is not included in the evaluation operation, the information relating to the equipment used during this treatment makes it possible to detect the omission of the inclusion relating to the treatment. Any omission of inclusion can therefore be detected and corrected.
  • the number of care centers involved in an evaluation operation managed by the system according to the invention is not limited to three as in the example mentioned.

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)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Biomedical Technology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Procédé de gestion de données relatives à un patient dans le cadre d'une opération d'évaluation menée dans au moins un centre de soins (100), caractérisé en ce qu'il comprend les étapes de saisie de données relatives à un patient depuis au moins un terminal de saisie (112) pour constituer un dossier patient, de validation de cette saisie depuis une application patient (115), de traitement automatique du dossier patient par l'application patient (115) pour constituer un dossier source qui respecte une ou plusieurs exigences réglementaires, d'enregistrement du dossier source dans une base de données source (10) déployée dans le centre de soins (100) participant à l'opération d'évaluation, de comparaison des données du dossier source avec des critères d'inclusion fournis par le promoteur de l'opération d'évaluation, de pré-inclusion du dossier source selon laquelle notamment on duplique automatiquement le dossier source pour constituer un dossier d'évaluation potentiel, d'enregistrement du dossier d'évaluation potentiel dans une base de données locale d'évaluation (20) déployée dans le centre de soins (100), d'inclusion du dossier d'évaluation potentiel depuis une application locale d'évaluation (121), la validation de cette étape d'inclusion entraînant l'exportation des données du dossier d'évaluation potentiel pour constituer un dossier d'évaluation CRF respectant des exigences du promoteur, d'enregistrement du dossier d'évaluation CRF dans une base de données (10) déployée dans le centre de soins (100).

Description

Système et procédé de gestion de données relatives à un patient dans le cadre d'une opération d'évaluation
L'invention concerne les procédés et les systèmes de gestion de données médicales ou en rapport avec la pratique médicale et de gestion des transmissions de ces données à des tiers.
De tel procédés et systèmes de gestion sont connus par exemple pour permettre au médecin de saisir pour chaque patient sur un support informatique ou sur un support papier les informations collectées pendant l'acte diagnostique ou thérapeutique.
Ces données portent tant sur l'état clinique du patient, les motifs de l'examen, que sur les actes diagnostiques et/ou thérapeutiques réalisé par l'acteur de soin.
L'ensemble des ces données, appelées « données patient », contribue à un dossier patient.
Ce dossier patient est conservé au sein de la structure de soin pendant une durée légale et constitue un document médico-légal.
Ce processus est commun à l'ensemble des patients examinés ou traités par l'acteur de soin. De tel procédés et systèmes de gestion sont connus par exemple pour permettre d'effectuer auprès des médecins et/ou des paramédicaux des opérations d'évaluation ou de contrôle, d'assurer la mission de matériovigilance et de pharmacovigilance et de traçabilité des matériels et produits nécessaires aux démarches de diagnostic et de traitement de patients. Les médecins et/ou paramédicaux sont désignés ci après par le terme « acteurs de soins ».
Une démarche d'évaluation ou de contrôle consiste en une étude généralement prospective, réalisée dans une ou plusieurs structure de soins, et vise à tester la tolérance et/ou l'efficacité et/ou la bonne utilisation de matériels médicaux, de médicaments ou de méthode de soins.
Cette étude est structurée autour d'un protocole qui définie pour chaque étude : - la question à laquelle l'étude doit apporter une réponse,
- les conditions d'inclusion et d'exclusion des patients.
- un ensemble de formulaires structurés permettant le recueil des données nécessaires à l'élaboration de la réponse. Ce recueil est désigné ci après par CRF (terme courant dans le milieu médical et qui correspond aux initiales du terme anglo-saxon-« case report form »).
- les étapes de suivis des patients inclus dans l'opération et les informations qui doivent être collectées pendant ces suivis. Une telle démarche d'évaluation peut avoir pour objectif de servir de base à une étude de recherche scientifique, économique ou réglementaire. L'ensemble de ces démarches est désigné ci après par le terme « opération d'évaluation ».
Les personnes qui requièrent de telles opérations d'évaluation peuvent donc être des personnes du corps médical, des chercheurs, des chefs de projet, des gestionnaires de centres soins, ou encore des industriels dont l'activité est en rapport avec la conception ou la distribution de produits médicaux, chirurgicaux etc. Ces personnes appartiennent par exemple à des organismes de tutelles, des associations de patients, des compagnies d'assurance, des sociétés savantes, des entreprises etc. Toutes personnes organisant une opération d'évaluation est désignée ci après par le terme « promoteur ».
Dans le cadre d'une opération d'évaluation, les acteurs de soin acceptent de transmettre au promoteur des informations sur des patients sélectionnés.
Chacun de ces patients signe un consentement qui autorise la transmission de ses données, sous couvert de l'anonymat, à un promoteur.
On parle pour chaque patient d'une « inclusion » dans l'opération d'évaluation.
Ces informations sont de nature très diverses et comprennent des données relatives aux caractéristiques démographiques, épidémiologiques, physiques, physiologiques, pathologiques, ou mentales d'un patient.
Ces informations portent également sur les soins médicaux et ou chirurgicaux prodigués ou à prodiguer, ainsi que sur les différents produits qui peuvent être utilisés pour réaliser ces soins.
Ces informations sont particulièrement sensibles, personnelles et confidentielles. Leur exploitation est donc soumise à de nombreuses contraintes et fait l'objet de réglementations spécifiques.
Le processus et les outils actuels de gestion de ces informations vont maintenant être décrits, en explicitant les contraintes inhérentes à la gestion d'une opération d'évaluation. Les inconvénients que présentent le processus et les outils actuels seront également mis en évidence.
Lorsqu'un acteur de soin participe à une opération d'évaluation, ce dernier accepte de transmettre au promoteur tout ou partie des données du dossier patient.
Lors de l'inclusion d'un patient dans une opération d'évaluation, l'acteur de soin procède à la création d'un CRF.
Ce CRF est fourni par le promoteur de l'opération d'évaluation aux acteurs de soins soit sur un support papier, soit sur un support informatique.
Une fois le CRF créé pour un patient, l'acteur de soin doit procéder à une copie dans ce dernier des informations contenues dans le dossier médico-légal du patient. Les informations ainsi ressaisies sont désignées données d'évaluation et constituent les données des dossiers d'évaluations.
Ainsi, pour chaque dossier d'évaluation, l'acteur de soin doit donc, à partir du dossier patient: contrôler que les données « patient » correspondent aux critères d'inclusion et d'exclusion fixé par le promoteur, procéder à une nouvelle saisie des données recueillies pendant l'acte diagnostique ou thérapeutique, assurer un suivi des patients à une fréquence définie par le protocole de l'opération d'évaluation, assurer la mise à jour du dossier d'évaluation par la déclaration d'éventuels événements survenus pendant la période de suivi.
De plus, les contraintes et réglementations strictes qui s'appliquent à l'utilisation des données médicales impliquent un traitement particulier. Ces contraintes et réglementations exigent notamment que la signature de ou des acteurs de soin ayant saisi ou modifié une donnée du dossier d'évaluation soit apposée à ces données, que la traçabilité des données fournies soit possible, et que les données transmises soient anonymes.
Les données d'évaluations de chaque structure de soins participant à l'opération d'évaluation sont centralisées et consolidées dans une base de données.
De plus, pour être pertinentes les données d'évaluation fournies par les acteurs de soin doivent faire l'objet d'un contrôle de cohérence.
Cette étape, appelée étape de contrôle, étape d'audit ou encore étape de monitoring, implique que des collaborateurs ou des prestataires du promoteur se déplacent dans chacune des structures de soins.
Ces collaborateurs ou prestataires contrôlent, alors tout ou partie des données d'évaluation en comparant les données contenues dans le dossier d'évaluation à exploiter par le promoteur avec les données patient contenues dans les dossiers patient. Le contrôle porte tant sur l'exactitude des données reportées que sur l'existence de données patient non ressaisies dans les dossiers d'évaluation. Cette étape impose donc le déplacement dans chaque centre d'une personne formée spécifiquement et habilitée au contrôle de données médicales et la préparation par l'acteur de santé des dossiers patients nécessaires à cette étape de contrôle.
Lorsque les données d'évaluations ont été vérifiées, elles peuvent être exploitées statistiquement pour permettre de répondre à la question énoncée par le protocole. Les processus actuels présentent de nombreux inconvénients qui portent tant sur la capture des donnés d'évaluation, sur le contrôle de ces données, que sur leur exploitation. Quelques soient les motivations d'un acteur de soins pour participer à une telle opération, il est contraint de s'imposer, ou du moins d'allouer les ressources nécessaires à une ressaisie des informations du dossier patient dans le dossier d'évaluation, à l'application des recommandations réglementaires, à la mise à jour du dossier d'évaluation par les informations ajoutées dans le dossier patient, ou provenant de confrères pendant la durée de l'opération d'évaluation et à la recherche physique des dossiers patient...
Ces contraintes s'avèrent particulièrement fastidieuses et limitent l'implication des acteurs de soins, pourtant cruciale, dans ce type d'opération d'évaluation clinique.
De plus, le processus actuel occasionne un décalage temporel entre la saisie des données patient et la disponibilité des données d'évaluation exploitable par le promoteur.
Ce décalage temporel provient du délai nécessaire à la ressaisie des données, à leur acheminement (si le support est le papier) et au contrôle des données d'évaluation. Ce décalage temporel limite l'efficacité des opérations d'évaluation.
En outre, le contrôle des données transmises est en pratique indispensable pour s'assurer de la pertinence de l'exploitation des données reçues par le promoteur. Pour le promoteur, cette phase de contrôle représente une perte de temps importante, un besoin en personnel non négligeable, et induit une charge financière substantielle.
Par ailleurs, les inconvénients des processus actuels limitent sensiblement la pertinence des résultats issus de l'exploitation des données d'évaluation.
Les opérations d'évaluation ont principalement pour but, pendant une période donnée, - soit de recueillir les données de tous les dossiers répondant à un groupe des critères visés bien définis (études),
- soit de donner une vision réelle et complète du terrain pour un critère unique (utilisation d'un matériel etc.). Afin de mener ce type d'opérations d'évaluation, le promoteur centralise et exploite les donnés d'évaluation provenant de plusieurs structures pendant une période définie. La pertinence des résultats de ces opérations repose sur les conditions de complétude et de consécutivité. La condition de complétude implique que tous les patients ayant fait l'objet d'un traitement donné soient inclus dans l'opération d'évaluation.
La condition de consécutivité exige que tous les patients consécutifs présentant des critères définis fassent l'objet d'un traitement donné et soient donc inclus dans l'opération d'évaluation.
Or, en pratique ces deux conditions ne sont pas forcément respectées. En effet, il s'avère bien souvent que certaines données ne soient pas incluses notamment par oubli de saisie, par anomalie d'un produit, ou encore par dysfonctionnement d'un mode opératoire. Dans la pratique, l'utilisation défectueuse d'un matériel pendant l'acte diagnostique ou thérapeutique entraîne l'absence inclusion du patient par l'acteur de soin. Le promoteur n'aura donc aucun retour d'information suite à l'utilisation de ce matériel. Or, la difficulté à utiliser un matériel, peut représenter une information très importante pour un promoteur. Une telle information peut, par exemple, amener un promoteur à améliorer un produit de manière à réduire son taux d'utilisation défectueuse, et permet de manière plus générale de suivre précisément le niveau des stocks de matériels. Chaque information, même celles relatives aux échecs de mise en œuvre d'un matériel, d'un produit ou d'une méthode, contribue à l'amélioration des conditions de soins et devraient, à ce titre, être exploitées dans le cadre d'une opération d'évaluation. Ainsi, l'étape de saisie des processus actuels ne permet pas de garantir le respect des conditions de complétude et de consécutivité.
De manière générale, les processus actuels ne permettent pas de vérifier aisément que tous les dossiers patients dont les données répondent aux critères visés par le promoteur ont été effectivement enregistrés et ressaisis, certains dossiers étant oubliés, omis ou méconnus.
Outre les inconvénients précités liés à la sélection, à la saisie, à la transmission et à l'exploitation des données, les processus et les outils actuels de gestion des informations cliniques présentent d'autres limites.
Comme évoqué précédemment, la ressaisie des données patient s'accompagne d'un retraitement pour rendre ces données conformes aux exigences et réglementations (exigence d'anonymisation par exemple). Ce retraitement peut donc s'accompagner d'erreur puisqu'il ne consiste pas en une simple duplication de l'ensemble des données.
Le promoteur d'une opération d'évaluation définie un certain nombre de critères que doit présenter un dossier patient pour que les données qu'il comporte soient incluses dans l'opération d'évaluation.
La ressaisie des informations impose donc une vérification de la concordance des critères avec les données de chaque dossier patient.
Cette vérification nécessite un effort supplémentaire de la part de l'acteur de soins, induit une charge de travail supplémentaire, et représente un risque d'erreur non négligeable.
Les processus actuels présentent donc des inconvénients liés au retraitement des données patients, qu'il est nécessaire d'effectuer pour une mise en conformité avec les règlements ou avec les exigences du promoteur.
Par ailleurs, les processus actuels ne garantissent pas, une sécurité suffisante et adaptée à la sensibilité des informations saisies. Ce manque de sécurité concerne autant les possibilité d'accès aux informations que les possibilités de modification de ces informations. En effet, les processus actuels ne proposent pas de moyens de contrôle de l'identité des personnes désirant accéder à des données ou souhaitant ajouter ou modifier des données.
Ces processus ne permettent pas non plus une traçabilité automatisée des données ajoutées ou modifiées.
De plus, sur les formulaires papier la signature qui doit accompagner tout entrée ou modification de donnée peut être aisément imitée.
La sécurité des processus actuels apparaît donc comme limitée. En outre, les processus actuels ne permettent pas d'effectuer d'opération d'évaluation à posteriori, c'est dire de mener une opération d'évaluation à partir de données saisies préalablement au lancement de l'étude. En effet une opération d'évaluation à posteriori nécessiterait de rechercher parmi les dossiers patients préalablement saisis, ceux dont les données satisfont les critères d'inclusions définis par le promoteur.
Or, une telle recherche se base sur les données patient et n'est à ce titre pas autorisée puisque ces données patient ne respectent pas les réglementations spécifiques à la gestion des opérations d'évaluation.
Ces processus de transmission de donnée entre une structure de soin et des tiers présentent également des inconvénients liés à la gestion des dépôts de matériel. Le terme matériel, au sens de la présente invention, comprend l'ensemble des médicaments, produits et matériels médicaux et chirurgicaux de diagnostic et de traitement.
L'évolution constante des matériels médicaux s'accompagne de manière générale d'une augmentation substantielle de leur prix unitaire.
Cette augmentation des prix a des conséquences importantes sur leur distribution, ainsi, de nombreux fabricants de matériels ne vendent pas leurs matériels aux structures de soin lors de la livraison dans cette structure, mais en restent propriétaire jusqu'à leur consommation effective.
Les fabricants mettent donc en dépôt, à disposition de la structure de soins une quantité définie de matériel. Chaque matériel n'est facturé à la structure de soins qu'après son utilisation effective. La croissance des prix, et le moment auquel intervient le transfert de propriété imposent une gestion précise des dépôts de matériels. Cette gestion exige notamment que le fabricant dispose dans les meilleurs délais d'informations relatives aux stocks de matériels non utilisés et utilisés, pour assurer le renouvellement des stocks et lancer la facturation des matériels consommés.
Actuellement cette information transite au sein de la structure de soins soit par l'économat, soit par la pharmacie centrale de cette structure et n'est transmise que secondairement au fabriquant selon des délais propres à chaque structure.
De plus, le fabricant ne peut pas différencier un matériel perdu, d'un matériel défectueux, d'un matériel utilisé sans succès ou déstérilisé par erreur. Or d'un point de vue retour d'expérience sur le matériel, comme d'un point de vue financier, ces informations sont très importantes. En pratique, le promoteur d'une opération d'évaluation tente d'obtenir ces informations lors de la visite sur site d'un de leur représentant.
L'identification des matériels est basée sur des systèmes spécifiques à chaque fournisseur de matériel. Ces systèmes sont nombreux et ne font l'objet d'aucune standardisation internationale. En règle générale, l'identification des matériels médicaux est gérée au sein de chaque structure de soin, non pas par unité, mais par type et par lot de matériel.
Ainsi, il est par exemple procédé à une saisie manuelle des caractéristiques des matériels (fabricant, dénomination, etc.), à une recopie manuelle des codes barres et à une constitution progressive d'un catalogue interne.
Cette pratique occasionne une grande perte de temps, elle présente un grand risque d'erreur, une difficulté de mise à jour et ne permet pas d'assurer une traçabilité fiable des matériels médicaux.
Or, les fabricants de matériels devraient et devront permettre aux médecins d'identifier leur matériel de manière unique afin qu'ils puissent réaliser dans les meilleures conditions leur mission de traçabilité et de matériovigilance.
Ainsi, les processus actuels présentent de nombreux inconvénients concernant tant la saisie des données, que leur transmission, que leur exploitation ou encore que la gestion des dépôts de matériels médicaux.
L'invention vise à améliorer les processus et les systèmes actuels de gestions des informations relatives à la prise en charge diagnostique ou thérapeutique d'un patient en milieu médical et de transmission des informations relatives à cette prise en charge à des tiers. L'invention a pour objet un ensemble d'applications permettant d'optimiser la gestion de ces informations.
Pour atteindre ces objectifs, il est prévu dans le cadre de la présente invention un procédé de gestion de données relatives à un patient dans le cadre d'une opération d'évaluation menée dans au moins un centre de soins, comprenant les étapes de:
- saisie de données relatives à un patient depuis au moins un terminal de saisie pour constituer un dossier patient,
- validation de cette saisie depuis une application patient,
- traitement automatique du dossier patient par l'application patient pour constituer un dossier patient source qui respecte une ou plusieurs exigences réglementaires,
- enregistrement du dossier patient source dans une base de données source déployée dans le centre de soins,
- comparaison des données du dossier source avec des critères d'inclusion fournis par le promoteur de l'opération d'évaluation,
- pré-inclusion du dossier source selon laquelle notamment on duplique automatiquement le dossier source pour constituer un dossier d'évaluation potentiel,
- enregistrement du dossier d'évaluation potentiel dans une base de données locale d'évaluation déployée dans le centre de soins,
- inclusion du dossier d'évaluation potentiel depuis une application locale d'évaluation, la validation de cette étape d'inclusion entraînant l'exportation des données du dossier d'évaluation potentiel pour constituer un dossier d'évaluation (CRF) respectant des exigences du promoteur,
- enregistrement du dossier d'évaluation (CRF) dans une base de données déployée dans le centre de soins. Le procédé de gestion selon l'invention pourra en outre présenter facultativement au moins l'une des caractéristiques suivantes :
- la validation de la pré-inclusion est effectuée lors de la validation de la saisie, la validation de la pré-inclusion est effectuée postérieurement à la validation de la saisie,
- la validation de la pré-inclusion entraîne également une étape de retraitement du dossier d'évaluation potentiel comprenant notamment une anonymisation de ce dossier, la comparaison entre les critères d'inclusion fournis par le promoteur de l'opération d'évaluation et les données présentes dans le dossier source est effectuée par une personne ou par un moteur de recherche,
- le procédé de gestion comporte une étape de modification ou d'ajout de données dans le dossier d'évaluation (CRF), une étape de validation de la complétion et un enregistrement automatique du dossier d'évaluation (CRF) ainsi modifié,
- la validation de la saisie, et/ou la validation de la pré-inclusion, et/ou la validation de l'inclusion, et/ou la validation de la complétion, comporte une étape de contrôle d'accès de la personne effectuant la validation, et une étape de collecte et d'enregistrement d'informations permettant la traçabilité de la validation,
- le dossier d'évaluation (CRF) est transmis à une base de données centrale d'évaluation à laquelle accède le promoteur de l'opération d'évaluation,
- plusieurs centres de soins participent à l'opération d'évaluation, la base de données centrale d'évaluation collectant les dossiers d'évaluation (CRF) relatifs à cette opération d'évaluation dans chacun des centres de soins,
- une modification du dossier source entraîne automatiquement une modification synchronisée du dossier d'évaluation potentiel,
- une modification du dossier d'évaluation (CRF) entraîne automatiquement une modification synchronisée du dossier d'évaluation (CRF) contenu dans la base de donnée centrale d'évaluation, - des données contenues dans les dossiers source sont transmises à un module matériel permettant la gestion des stocks de matériels,
- les étapes de saisie des données dans le dossier patient source et d'inclusion dans une opération d'évaluation sont validées simultanément par une seule opération depuis le module patient.
- on compare des donnés contenues dans les dossiers source avec les données relatives au matériel, ces données étant contenues dans un module matériel, et on vérifie que des données matériel de matériels utilisés sont inclues dans un dossier d'évaluation (CRF) de manière à remplir la condition de complétude.
- on compare des donnés contenues dans les dossiers source avec les données relatives au matériel, ces données étant contenues dans un module matériel, et on vérifie que chaque patient présentant les critères d'inclusion ait fait l'objet d'un traitement associé à ces critères, de manière à remplir la condition de consécutivité.
L'invention a en outre pour objet un système de gestion de données relatives à un patient dans le cadre d'une opération d'évaluation menée dans au moins un centre de soins, comprenant
- un module patient comportant : o au moins un terminal de saisie de données relatives à un patient pour former un dossier patient, o une application patient permettant la validation de cette saisie, l'application patient effectuant un traitement automatique du dossier patient pour constituer un dossier source qui respecte une ou plusieurs exigences réglementaires,
- une base de données source, déployée dans le centre de soins participant à l'opération d'évaluation et dans laquelle le dossier source est enregistré,
- des moyens de duplication automatique du dossier source pour constituer un dossier d'évaluation potentiel,
- une base de données locale d'évaluation, déployée dans le centre de soins et dans laquelle le dossier d'évaluation potentiel est enregistré,
- une application locale d'évaluation exportant des données du dossier d'évaluation potentiel pour constituer un dossier d'évaluation (CRF) respectant des exigences du promoteur,
- une base de données, déployée dans le centre de soins et dans laquelle le dossier d'évaluation (CRF) est enregistré.
D'autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre, et en regard des dessins annexés, donnés à titre d'exemple non limitatifs et sur lesquels: La figure 1 est un schéma d'un système de gestion de données selon premier exemple de réalisation,
La figure 2 est un schéma d'un système de gestion de données selon deuxième exemple de réalisation,
En référence à la figure 1, on a illustré le système de gestion 1 de données selon un exemple de réalisation.
Ce système de gestion 1 comporte notamment un module patient 110 permettant la saisie des données relatives à un patient, un module local d'évaluation 120 des données issues du module patient 110 dans une opération d'évaluation, et un module de synchronisation 130 des données entre 110 et 120, ces trois modules étant déployés dans chacun des centres de soins. Le système comprend également trois modules communs à tous les centres de soins : - un module central d'évaluation 400 permettant de centraliser les données du module local d'évaluation 120 de chacun des centres de soins 100, 200, 300. - un module serveur central 600 assurant la gestion des messages entre les différents modules du système, - un module matériel 500 gérant les informations relatives aux matériels, médicaments et de manière générale aux produits utilisés pour le diagnostique et le traitement des patients. Le système de gestion 1 des informations est par la suite décrit en suivant le flux principal des données. Module patient 110.
Le module patient 110 comporte un ou plusieurs terminaux de saisie 112, 113, 114. Ces terminaux de saisie 112, 113, 114, sont localisés dans une salle d'opération, ou un local d'un centre de soins
100. Ces terminaux permettent de saisir des données relatives à un patient. Ils offrent des moyens variés de saisie :
- saisie manuelle au moyen d'un clavier d'ordinateur, d'une tablette numérique,
- saisie par lecture d'un code barre disposé sur un produit ou sur un patient, - saisie automatique réalisée par recopie d'information provenant du système d'information hospitalier de la structure de soin (numéro, code barre, puce...),
- saisie automatique réalisée par un équipement de soins prélevant des données directement sur le patient.
Ces saisies sont effectuées sur des formulaires standardisés d'actes de diagnostique ou de traitement dispensés au patient. L'ensemble des données relatives à un patient contenues dans ces formulaires constitue un dossier patient.
Le module patient 110 comporte également une application patient 115. Préalablement ou suite à la saisie, l'application patient 115 contrôle l'identité de la personne désirant valider la saisie. Ce contrôle peut être effectué à l'aide d'un mot de passe ou par un contrôle biométrique. La personne dont l'identité est vérifiée et qui se voit autoriser une saisie des données peut alors procéder à la validation de la saisie. Cette personne, généralement un médecin ou une personne du corps médical, est désignée par la suite personne habilitée.
L'application patient 115 effectue ensuite un traitement des données. Ce traitement permet de transformer les données saisie afin qu'elles respectent un certain nombre d'exigences réglementaires. Ces exigences réglementaires imposent par exemple que chaque saisie de données soit validée au moyen d'une signature apposée par la personne habilitée. Le module patient 110 comporte à cet effet des moyens permettant l'opposition d'une signature, par voie électronique par exemple ou par l'utilisation d'une carte de santé professionnelle. Ces exigences réglementaires imposent également qu'une traçabilité parfaite puisse être établie pour chaque ajout ou modification de données. Une telle traçabilité inclut notamment l'identité de la personne habilitée, la date de la saisie, l'objet de la saisie etc.
Les données saisies ainsi retraitées revêtent un caractère source et conserveront ce caractère source quels que soient les traitements ultérieurs qui leurs seront appliquées.
Ces données sont désignées par la suite données source, l'ensemble des ces données relatives à un patient est désigné dossier source et l'ensemble des données source contenues dans les dossiers source constitue une base de données appelée base de donnée source.
Cette base de données patient 10 fait partie du module patient 110 et est localisée dans le centre de soins 100. Cette base de donnée source communique avec une autre base de données appartenant au module local d'évaluation 120 et qui est elle aussi localisée dans le centre de soins 100. Cette autre base de donnée est appelée base de données locale d'évaluation 20. Module local d'évaluation 120.
L'inclusion d'un patient dans une opération d'évaluation signifie que des donnés relatives à ce patient seront utilisées dans le cadre de l'opération d'évaluation.
Le promoteur d'une opération d'évaluation définit un certains nombres de critères appelés critères d'inclusion, que devront présenter les données d'un dossier patient pour que celui-ci soit inclus dans l'opération d'évaluation.
Par commodité de langage on emploie également l'expression inclusion de dossier, pour signifier que les données d'un patient sont collectées dans le but d'être exploitées dans le cadre d'une opération d'évaluation.
Le module local d'évaluation 120 comporte une application locale d'évaluation 121 et une base de données locale d'évaluation 20.
L'application locale d'évaluation 120 permet de recevoir une requête d'initialisation d'une opération d'évaluation. Une requête d'initialisation d'une opération d'évaluation contient toutes les indications nécessaires au déroulement d'une opération d'évaluation conformément aux exigences du promoteur et aux recommandations réglementaires. Ainsi une telle requête comprend notamment les informations suivantes:
- la liste des personnes habilitées à procéder à l'inclusion, la complétion, la signature des données d'évaluation. Ces personnes sont par la suite désignées investigateurs,
- l'objectif médical, scientifique ou industriel recherché par l'opération d'évaluation, les critères qu'un patient doit présenter pour être inclus dans une étude. Ces critères correspondent à des données issues de diagnostiques, à des soins ou traitement effectués, ou encore à toute autre donnée pouvant figurer dans un dossier source
- les formulaires spécifiques à l'opération d'évaluation, désignés par la suite dossiers d'évaluation ou CRF, et les règles de contrôle et de cohérence appliquées à ces formulaires,
- les détails du protocole à respecter pour :
• prélever les données auprès du patient
• saisir ces données sur un formulaire
• compléter le formulaire avec d'autres données Le module patient 110 permet de réaliser la pré-inclusion, dans une opération d'évaluation, d'un dossier source directement depuis l'application patient 115 sans aucune ressaisie lors : de la saisie des informations relatives à l'état clinique du patient, à l'acte diagnostique ou thérapeutique effectuée par l'intermédiaire des terminaux 112, 113, 114.
- de la consultation ultérieure du dossier patient.
La personne habilitée, en fonction de la requête reçue par le module d'évaluation 120, décide si un dossier source doit ou non être inclus dans une opération d'évaluation donnée. Ce choix de la personne habilitée résulte généralement d'une comparaison entre les critères d'inclusion définis dans la requête fournie par le promoteur et les données présentes dans le dossier source.
Selon une variante, la pré-inclusion est effectuée au niveau du module local d'évaluation 120. Dans ce cas, la comparaison des critères d'inclusion et des données source peut être établie automatiquement par l'application locale d'évaluation 121.
Les possibilités d'effectuer la pré-inclusion depuis le module patient 110 et depuis le module d'évaluation 120 sont toutes deux représentées sur les figures 1 et 2. La validation de la pré-inclusion peut être subordonnée au contrôle de l'habilitation de cette personne, et peut également être soumise à l'apposition par d'une signature électronique.
Cette pré-inclusion consiste à : - dupliquer de manière automatique un dossier source afin de créer une copie du dossier source,
- faire subir un traitement d'inclusion à cette copie,
- enregistrer cette copie dans la base de donnés locale d'évaluation 20.
Ce traitement de pré-inclusion consiste par exemple en une anonymisation de l'ensemble de la copie du dossier source afin de supprimer toute information liée à la personnalité juridique du patient dont les données constituent le dossier source. D'autres traitements peuvent être prévus comme par exemple l'adjonction d'informations relatives à l'étape de pré-inclusion, afin de permettre une traçabilité de cette étape. Ces informations peuvent êtres saisies manuellement ou peuvent être ajoutée automatiquement lors de la validation de la saisie.
La copie d'un dossier source par des moyens de duplication est par la suite appelée dossier d'évaluation potentiel. Ce dossier d'évaluation potentiel est contenu dans la base de données locale d'évaluation 20.
Des moyens de sécurités sensiblement identiques aux moyens assurant la sécurité d'accès à l'application patient 115 et la base de donnée source permettent de contrôler l'accès à l'application locale d'évaluation 121 et à la base de données locale d'évaluation 20. Ainsi seuls les investigateurs peuvent accéder au module local d'évaluation 120.
La validation de l'inclusion est soumise à l'apposition par l'investigateur d'une signature électronique. Cette apposition est réalisée par l'investigateur dans l'application 121.
Les données contenues dans le dossier d'évaluation potentiel dont l'inclusion est validée sont alors exportées vers les formulaires spécifiques à l'opération d'évaluation, et constituent un dossier d'évaluation, également désigné CRF par la suite. Ce CRF est alors enregistré dans la base de données locale d'évaluation 20.
Dans un autre exemple de réalisation, le dossier d'évaluation potentiel et le CRF sont enregistrés dans des bases de données distinctes et localisées dans le centre de soins. Dès qu'un CRF est enregistré dans la base de données locale d'évaluation 20, les informations contenues dans ce CRF sont rendues accessibles au promoteur de l'opération d'évaluation. Les détails de la transmission du CRF depuis le centre de soins jusqu'au promoteur sont explicités par la suite.
Lorsqu'un dossier est inclus, l'application locale d'évaluation 121 fait alors apparaître si toutes les données requises par le promoteur dans la requête sont présentes dans ce CRF.
L'application d'évaluation 121 permet à l'investigateur, si besoin est, et selon les règles de gestion spécifiques au protocole de l'opération d'évaluation, de compléter, ou modifier les données du CRF pendant la durée de l'opération d'évaluation. Ces modifications seront réalisées par l'investigateur de différentes manières selon l'origine de la donnée.
Si la donnée provient du dossier patient, l'investigateur doit modifier la source de la donnée depuis l'application 115. Cette modification donnera lieu à la génération d'une demande de mise en conformité de la donnée du dossier patient avec la donnée du CRF.
Si la donnée n'est pas présente dans le dossier patient, cette modification est réalisée par l'investigateur depuis l'application 121. Toute modification d'un CRF est régie par des règles de gestion strictes qui visent à assurer une traçabilité complète de la donnée, par exemple l'apposition de la signature de l'investigateur, la génération d'une trace de modification et le motif de cette modification. Cette traçabilité est disponible depuis les modules 120 et 400. L'inclusion et la complétion de CRF sont sécurisées par des moyens de sécurisation adaptés (contrôle d'accès etc.).
La base de données locale d'évaluation 20 comporte donc à la fois des dossiers d'évaluation potentiels qui nécessitent une validation par l'investigateur, et des CRF. Un CRF respecte à la fois les exigences réglementaires et celles définies par le promoteur, autant du point de vue des données qu'il contient, que du point de vue de la présentation de ces données. Une requête fournie par un promoteur est spécifique d'une opération d'évaluation, par conséquent, un CRF inclus sur la base d'une telle requête est également spécifique d'une opération d'évaluation.
Le traitement automatique des données saisies en données source et la duplication automatique des données source pour constituer un dossier d'évaluation potentiel permet de ne pas avoir à ressaisir les informations contenues dans un dossier source.
Le système de gestion 1 permet donc des gains substantiels de temps et des réductions de coûts liés à la ressaisie des informations et à leur nécessaire contrôle.
La complétion d'un CRF est également facilitée, et les risques liés à des erreurs ou des oublis de retranscription sont également écartés.
Le promoteur est ainsi assuré de disposer des données fiables pour mener son opération d'évaluation. Le contrôle des données peut alors être limité aux seules données non présentes dans le dossier source.
La saisie et la duplication automatique de données source, en plus de permettre un gain de temps substantiel, une diminution des risques d'erreur, soulagent les personnes habilitées d'une contrainte importante, et les rends pas conséquent plus enclin à s'impliquer dans ce type d'opération d'évaluation.
Les personnes habilitées disposent également d'une application d'évaluation 121 unique pour gérer l'ensemble des opérations d'évaluation auxquelles elles participent. Cela contribue à réduire le temps nécessaire à la prise en main de la solution par l'investigateur et limite les ressources nécessaires au promoteur pour assurer le transfert de compétence.
De plus les données servant de base à la constitution des CRF sont des données sources, qui respectent par définition les exigences réglementaires liées à la manipulation de ces données. Il est possible de manipuler ces données à n'importe quel moment puisque ce caractère source est conservé au cours du temps. Ainsi, le système de gestion 1 permet d'effectuer une opération d'évaluation à posteriori, c'est à dire de mener une opération d'évaluation à partir de données saisies préalablement à l'initialisation de cette même opération.
Selon une variante, le système de gestion 1 comporte également un moteur de recherche multicritères associé à la base de données patient 10. Le moteur de recherche, permet de recevoir des instructions de recherche qui sont établies par l'investigateur lorsqu'une opération d'évaluation à posteriori est demandée. Il est également prévu, que le promoteur désirant initialiser une opération d'évaluation, puisse directement lancer une telle recherche. Le lancement de cette recherche par le promoteur est subordonné à l'accord légal de l'investigateur. L'obtention de cet accord peut être contrôlé par des moyens de contrôle appropriés, tels que des codes d'accès etc.
Le moteur de recherche identifie tous les dossiers sources qui correspondent aux critères définis dans la requête. Le moteur de recherche délivre alors comme résultat la liste de tous ces dossiers source.
L'investigateur détermine ensuite les dossiers qu'il désire inclure dans l'opération d'évaluation. L'application d'évaluation génère autant de CRF que de dossiers source sélectionnés dans le résultat de la recherche, ces CRF contenant les données contenues dans les dossiers source sélectionnés. Ces CRF sont enregistrés dans la base de donnée d'évaluation 20.
Le système de gestion 1 permet de réaliser ce type d'opération d'évaluation à posteriori puisque le moteur de recherche effectue sa recherche sur des données qui revêtent un caractère source et qu'il est donc possible de manipuler. Les systèmes et processus de l'art antérieur quant à eux, ne permettent pas d'effectuer des opérations d'évaluation à posteriori puisque ils ne proposent pas de base de données qui rassemblent l'ensemble des dossiers saisis et dont les données revêtent un caractère source.
L'utilisation de formulaires standardisés pour la saisie des données patient permet d'obtenir une gestion efficace de ces informations, quels que soient les protocoles des différents promoteurs. Les conditions d'accès sécurisées et les informations de traçabilité permettent entre autre de respecter les exigences médico-légales relatives à ces données.
Selon une variante, l'inclusion dans une opération d'évaluation peut être réalisée par l'investigateur directement depuis le module patient
110 au moment de la constitution du dossier source. Une seule est même personne effectuant alors d'une seule opération à la fois la validation de la saisie, et la validation de l'inclusion. Dans ce cas, le CRF est crée directement par le module d'évaluation 120 sans qu'une validation distincte de la pré-inclusion ne soit imposée à l'opérateur.
Cette variante apporte notamment simplicité, gain de temps, et souplesse d'utilisation pour la création d'un CRF.
Module central d'évaluation 400.
Le module serveur 600 central permet la gestion des messages entre les centres de soins 100, 200, 300 et le module central d'évaluation 400.
Lorsqu'un CRF est crée, il est alors transmis depuis la base de données locale d'évaluation 20 au module centrale d'évaluation 400 par l'intermédiaire de l'application 600. Ce module central d'évaluation 400 est une application web, comprenant des applications centrales d'évaluation 411, 412, 413. Chacune de ces applications centrales d'évaluation 411, 412, 413 est respectivement associée à une base de données centrale d'évaluation 421, 422, 423.
Le module central d'évaluation 400 comporte également, pour chacune des applications centrales d'évaluation 411, 412, 413, une application client 641, 642, 643. Le rôle d'une application client 641, 642, 643, est d'établir une communication entre l'application centrale d'évaluation à laquelle elle est associée et les différents modules du système de gestion 1. Le module serveur central 400 permet la collecte des CRF de l'ensemble des centres de soins 100, 200, 300 participant à des opérations d'évaluation. Chacune des bases de données centrales d'évaluation 421, 422, 423, est spécifique à une opération d'évaluation particulière, et contient les CRF de tous les centres de soins qui sont spécifiques à cette opération d'évaluation. Ainsi le module central d'évaluation 400 contient autant d'applications centrales d'évaluation 411, 412, 413, et autant de bases de données centrales d'évaluation 421, 422, 423, qu'il existe d'opérations d'évaluation.
Le schéma de la figure 1 fait ainsi apparaître trois applications centrales d'évaluation 411, 412, 413, chacune associée à une base de donnée centrale d'évaluation 421, 422, 423, chacune de ces bases de données centrales rassemblant les CRF relatifs à une opération d'évaluation spécifique.
Le promoteur d'une opération accède aux CRF contenus dans la base de données centrale d'évaluation correspondante à l'opération d'évaluation qu'il a initiée. Cet accès est contrôlé au moyen de dispositifs appropriés tels que des codes d'accès.
Module serveur central 600.
La transmission des données entre les différents modules est plus particulièrement détaillée dans cette partie. Le module serveur central 600 comprend une application serveur centrale 610 qui est une application dédiée à la gestion des messages entre les centres de soins 100, 200, 300 et les modules 400 et 500.
Cette application de gestion de message assure la conformité des échanges réalisés au sein du système avec les recommandations et obligations légales.
Cette application gère par exemple l'encodage et la sécurisation des flux d'information entre les différentes applications du système, la non répudiation des informations, et de manière générale tout procédé nécessaire à mettre en oeuvre pour assurer aux utilisateurs du système une conformité avec les législations en vigueur.
L'application serveur central 610 gère les flux d'information et leur acheminement vers les différents modules du système. Les modules 110, 120, 400 et 500 comportent chacun une application client, respectivement référencée 603, 602, 650, 641, 642, 643.
Le module serveur central 600 permet la communication entre les différents modules 110, 120, 400, 500, via leur application client respective 603, 602, 650, 641, 642, 643.
Le module 600 peut assurer une gestion synchrone ou asynchrone des messages émis par les modules 110, 120, 400 et 500 en fonction des besoins des utilisateurs. Ainsi, de manière synchrone ou asynchrone, l'application client 602 associée à l'application locale d'évaluation 121 contenue dans le module local d'évaluation 120 établit, par exemple une communication sécurisée avec l'application serveur central 610.
Lorsqu'un CRF est créé, l'application client 602 envoie un message à l'applications client 641, 642 ou 643 qui est dédiée à l'opération d'évaluation pour laquelle le CRF a été généré.
La base de données centrale d'évaluation associée à cette application client collecte le CRF nouvellement créé.
En référence à la figure 2, un exemple de système de gestion 1 présentant une autre configuration de gestion des messages est proposé.
Dans cet exemple, les modules 110 et 120 comportent une application client commune 601. Cette application client 601 commune assure la communication entre d'une part l'application serveur centrale 610 du module serveur central 600, et d'autre part les applications 115,
121 et bases de données 10, 20 des modules 110 et 120.
Ainsi, les applications client 602, 603 ne communiquent pas directement avec l'application serveur centrale 610.
Dans ce même exemple, le module central d'évaluation 400 comporte une application client 640 qui assure la communication entre d'une part l'application serveur central 610 du module serveur central 600, et d'autre part les applications client 641, 642, 643. Ainsi, les applications client 641, 642, 643 ne communiquent pas directement avec l'application serveur central 610.
Il peut bien évidement être envisagé d'autres configurations de structures de gestion des messages, et notamment des structures comportant l'une seulement des applications client 601 ou 640. Synchronisation des données.
Le système de gestion 1 comprend également une application de synchronisation 130 dédiée au contrôle de la synchronisation d'une donnée entre le dossier du patient et le CRF au sein du centre de soin 100.
Ainsi, lorsque, suite à une nouvelle saisie de données, les données sources sont modifiées en respectant les conditions exigées pour revêtir un caractère source, une application permet de synchroniser les données des dossiers source et les données des CRF. De même lorsqu'un CRF est modifié et que cette modification est validée par l'investigateur, les données de ce CRF sont synchronisées avec celles du CRF contenu dans la base de données centrale.
Cette synchronisation des données permet d'assurer une conformité en temps réel entre les données saisies par la personne habilitée et les données exploitées par le promoteur.
Le contrôle des données par un auditeur est ainsi limité aux données non présentes dans le dossier patient.
Cette synchronisation des données induit par conséquent une diminution substantielle des coûts liés au contrôle des données. De plus cette synchronisation des données permet aux promoteurs de disposer des informations utiles dès la saisie de celles-ci par la personne habilitée.
En effet, les délais nécessaires au contrôle et à l'acheminement des données sont considérablement réduits. Module matériel 500.
Le système de gestion 1 des informations relatives à un patient en milieu médical permet d'améliorer la traçabilité, et de faciliter la mission de matériovigilance des acteurs de soins et la gestion précise des dépôts de matériels.
Les fabricants de matériels disposent d'un outil dédié à la gestion des dépôts de matériels. Cet outil, désigné module matériel 500 est associé à l'application au module serveur central 600. Il comprend une ou plusieurs applications client matériel et une ou plusieurs bases de données matériel (non représentés).
Le système permet à chaque fabricant de créer un catalogue de matériels. Ce catalogue est un référentiel de produits qui respecte les nomenclatures de description des produits spécifiques à chaque fabricant.
Le fabricant de matériel, en tant qu'utilisateur peut au sein de son référentiel créer une nouvelle référence, modifier une référence ou encore archiver une référence.
Le module matériel 500, établit une connexion avec l'ensemble des structures de soins équipées de l'application patient 115, via l'application client 603 (ou 601 dans le cas de la configuration de l'exemple 2) et transmet les mises à jour réalisées dans les différents catalogues.
Les matériels sont équipés d'un code barre, ou d'une étiquette radio fréquences disposé par le fabricant en cohérence avec son catalogue.
Chaque matériel est identifié lors de son introduction dans le stock du centre de soins 100, lors de sa sortie du stock et lors de son utilisation. Dans certains cas, il peut être prévu de n'identifier le matériel qu'à l'une des étapes de sortie de stock ou d'utilisation.
Ce suivi de chacun des matériels permet de disposer d'une connaissance très précise du stock de matériel. Lors de chaque entrée en stock, sortie de stock ou utilisation d'un matériel, l'application patient 115 établit une connexion avec le module matériel 500 et lui transmet les informations relatives à cette entrée, sortie ou utilisation. Les fabricants, utilisateurs du module matériel 500, peuvent ainsi consulter l'état du stock de chacun des centres de soins.
Les informations que l'application patient 115 transmet au module matériel 500 ne se limitent cependant pas au niveau de stock. Ainsi, l'application patient 115 transmet au module matériel 500 d'autres informations sur l'état de chacun des matériels, comme par exemple des informations relatives à la date de péremption de ces matériels. Ainsi, il peut être prévu qu'une alerte soit transmise par l'application patient 115 au module matériel 500 lorsque la date de péremption d'un matériel arrive à échéance.
Les fabricants disposent ainsi des moyens de contrôle en temps réel de la gestion des dépôts.
L'ensemble des informations concernant les matériels et notamment l'entrée en stock, la sortie de stock, l'utilisation, la nature, la date de péremption, les instructions et précautions sont désignées par la suite informations relatives au matériel.
De plus, l'application patient 115 permet de déclarer qu'un matériel a été endommagé, n'a pas était utilisé avec succès ou a été déstérilisé par erreur. Ces informations permettent d'initialiser des procédures de matériovigilance, et de fournir aux fabricants des données précises pour apporter des améliorations à ce type de matériel.
Cette meilleure gestion des stocks induit une production, un approvisionnement, et des échéances de facturation plus précises se traduisant in fine par des améliorations sensibles de la qualité des services offerts et de la rentabilité financière.
En plus des avantages précités, le système permet de remplir, les conditions de complétude et de consécutivité nécessaires à la pertinence d'une opération d'évaluation.
En effet, une recherche basée sur les critères d'inclusion définis par le promoteur permet d'identifier tous les patients répondant à ces critères d'inclusions. Le traitement prévu par le protocole sera appliqué pour chacun de ces patients. La vérification de la condition de consécutivité est ainsi assurée. Par ailleurs, lorsqu'un patient a fait l'objet d'un traitement particulier effectué avec un matériel donné, le promoteur dispose de l'information relative à l'utilisation de ce matériel grâce au module matériel 500. En effet, et comme indiqué précédemment le suivi d'un matériel donné est possible depuis le module matériel 500. Ainsi, même si l'information relative au traitement subi par le patient n'est pas incluse dans l'opération d'évaluation, l'information relative au matériel utilisé lors de ce traitement permet de détecter l'omission de l'inclusion relative au traitement. Toute omission d'inclusion peut par conséquent être détectée et corrigée. Il peut être prévu que la détection de l'omission d'une inclusion soit accompagnée d'une alerte. La condition de complétude est alors respectée et permet de vérifier la notion « d'étude en intention d'utilisation » ou de réaliser des « registres de non inclusion ». La présente invention n'est pas limitée aux modes de réalisation décrits ci-dessus, mais s'étend à tout mode de réalisation conforme à son esprit.
En particulier le nombre de centre de soins impliqués dans une opération d'évaluation gérée par le système selon l'invention n'est pas limité à trois comme dans l'exemple mentionné.

Claims

REVENDICATIONS
1. Procédé de gestion de données relatives à un patient dans le cadre d'une opération d'évaluation menée dans au moins un centre de soins (100), caractérisé en ce qu'il comprend les étapes de:
- saisie de données relatives à un patient depuis au moins un terminal de saisie (112) pour constituer un dossier patient,
- validation de cette saisie depuis une application patient (115),
- traitement automatique du dossier patient par l'application patient (115) pour constituer un dossier patient source qui respecte une ou plusieurs exigences réglementaires,
- enregistrement du dossier source dans une base de données source (10) déployée dans le centre de soins (100),
- comparaison des données du dossier source avec des critères d'inclusion fournis par le promoteur de l'opération d'évaluation,
- pré-inclusion du dossier source selon laquelle notamment on duplique automatiquement le dossier source pour constituer un dossier d'évaluation potentiel,
- enregistrement du dossier d'évaluation potentiel dans une base de données locale d'évaluation (20) déployée dans le centre de soins (100),
- inclusion du dossier d'évaluation potentiel depuis une application locale d'évaluation (121), la validation de cette étape d'inclusion entraînant l'exportation des données du dossier d'évaluation potentiel pour constituer un dossier d'évaluation (CRF) respectant des exigences du promoteur,
- enregistrement du dossier d'évaluation (CRF) dans une base de données (10) déployée dans le centre de soins (100).
2. Procédé selon la revendication précédente, caractérisé en ce que la validation de la pré-inclusion est effectuée lors de la validation de la saisie.
3. Procédé selon la revendication 1, caractérisé en ce que la validation de la pré-inclusion est effectuée postérieurement à la validation de la saisie.
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la validation de la pré-inclusion entraîne également une étape de retraitement du dossier d'évaluation potentiel comprenant notamment une anonymisation de ce dossier.
5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la comparaison entre les critères d'inclusion fournis par le promoteur de l'opération d'évaluation et les données présentes dans le dossier source est effectuée par une personne ou par un moteur de recherche.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de modification ou d'ajout de données dans le dossier d'évaluation (CRF), une étape de validation de la complétion et un enregistrement automatique du dossier d'évaluation (CRF) ainsi modifié.
7. Procédé selon la revendication précédente, caractérisé en ce que la validation de la saisie, et/ou la validation de la pré-inclusion, et/ou la validation de l'inclusion, et/ou la validation de la complétion, comporte une étape de contrôle d'accès de la personne effectuant la validation, et une étape de collecte et d'enregistrement d'informations permettant la traçabilité de la validation.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le dossier d'évaluation (CRF) est transmis à une base de données centrale d'évaluation (421) à laquelle accède le promoteur de l'opération d'évaluation.
9. Procédé selon l'une quelconque des revendications précédentes, dans lequel plusieurs centres de soins (100, 200, 300) participent à l'opération d'évaluation, la base de données centrales d'évaluation (421, 422, 423) collectant les dossiers d'évaluation (CRF) relatifs à cette opération d'évaluation dans chacun des centres de soins (100, 200, 300).
10. Procédé selon l'une quelconque des revendications précédentes, dans lequel une modification du dossier source entraîne automatiquement une modification synchronisée du dossier d'évaluation potentiel.
11. Procédé selon l'une quelconque des revendications 8 à 10, dans lequel une modification du dossier d'évaluation (CRF) entraîne automatiquement une modification synchronisée du dossier d'évaluation (CRF) contenu dans la base de donnée centrale d'évaluation (421).
12. Procédé selon l'une quelconque des revendications précédentes, dans lequel des données contenues dans les dossiers source sont transmises à un module matériel (500) permettant la gestion des stocks de matériels.
13. Procédé selon l'une quelconque des revendications précédentes, dans lequel les étapes de saisie des données dans le dossier patient source et d'inclusion dans une opération d'évaluation sont validées simultanément par une seule opération depuis le module patient (110).
14. Procédé selon l'une quelconque des revendications précédentes, dans lequel on compare des donnés contenues dans les dossiers source avec les données relatives au matériel, ces données étant contenues dans un module matériel (500), et on vérifie que des données matériel de matériels utilisés sont inclues dans un dossier d'évaluation (CRF) de manière à remplir la condition de complétude.
15. Procédé selon l'une quelconque des revendications précédentes, dans lequel on compare des donnés contenues dans les dossiers source avec les données relatives au matériel, ces données étant contenues dans un module matériel (500), et on vérifie que chaque patient présentant les critères d'inclusion ait fait l'objet d'un traitement associé à ces critères, de manière à remplir la condition de consécutivité.
16. Système de gestion (1) de données relatives à un patient dans le cadre d'une opération d'évaluation menée dans au moins un centre de soins (100), caractérisé en ce qu'il comprend :
- un module patient (115) comportant : o au moins un terminal (112) de saisie de données relatives à un patient pour former un dossier patient, o une application patient (115) permettant la validation de cette saisie, l'application patient (115) effectuant un traitement automatique du dossier patient pour constituer un dossier source qui respecte une ou plusieurs exigences réglementaires, - une base de données source (10), déployée dans le centre de soins (100) participant à l'opération d'évaluation et dans laquelle le dossier source est enregistré,
- des moyens de duplication automatique du dossier source pour constituer un dossier d'évaluation potentiel, - une base de données locale d'évaluation (10), déployée dans le centre de soins (100) et dans laquelle le dossier d'évaluation potentiel est enregistré,
- une application locale d'évaluation (121) exportant des données du dossier d'évaluation potentiel pour constituer un dossier d'évaluation (CRF) respectant des exigences du promoteur,
- une base de données (20), déployée dans le centre de soins (100) et dans laquelle le dossier d'évaluation (CRF) est enregistré.
PCT/EP2007/054705 2006-05-15 2007-05-15 Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation Ceased WO2007132006A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/300,994 US20110270621A1 (en) 2006-05-15 2007-05-15 Patient-related data management system and method within the scope of an evaluation operation
EP07729154A EP2024887A1 (fr) 2006-05-15 2007-05-15 Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0604331 2006-05-15
FR0604331A FR2901042B1 (fr) 2006-05-15 2006-05-15 Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation

Publications (1)

Publication Number Publication Date
WO2007132006A1 true WO2007132006A1 (fr) 2007-11-22

Family

ID=37596434

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/054705 Ceased WO2007132006A1 (fr) 2006-05-15 2007-05-15 Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation

Country Status (4)

Country Link
US (1) US20110270621A1 (fr)
EP (1) EP2024887A1 (fr)
FR (1) FR2901042B1 (fr)
WO (1) WO2007132006A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010141957A2 (fr) * 2009-06-05 2010-12-09 Duhamel James B Système de surveillance et de gestion de la compliance à un traitement de l'apnée obstructive du sommeil au moyen d'une thérapie avec appareillage oral et procédé pour le mettre en œuvre
US20110078097A1 (en) * 2009-09-25 2011-03-31 Microsoft Corporation Shared face training data
US20110230731A1 (en) * 2010-03-22 2011-09-22 General Electric Company Method, device and computer program product for determining an indicator of general clinical state
CN116153450B (zh) * 2023-04-13 2023-06-27 合肥科颖医药科技有限公司 基于智能分析的访视内容数据比对方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003040879A2 (fr) * 2001-11-02 2003-05-15 Siemens Medical Solutions Usa, Inc. Exploration de donnees relatives a des patients comprenant une analyse fondee sur la population
US20040078228A1 (en) * 2002-05-31 2004-04-22 Fitzgerald David System for monitoring healthcare patient encounter related information
WO2005015451A1 (fr) * 2003-08-12 2005-02-17 Lms Medical Systems Ltd. Procede et appareil permettant d'evaluer les differences entre des fournisseurs de services de sante

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003040879A2 (fr) * 2001-11-02 2003-05-15 Siemens Medical Solutions Usa, Inc. Exploration de donnees relatives a des patients comprenant une analyse fondee sur la population
US20040078228A1 (en) * 2002-05-31 2004-04-22 Fitzgerald David System for monitoring healthcare patient encounter related information
WO2005015451A1 (fr) * 2003-08-12 2005-02-17 Lms Medical Systems Ltd. Procede et appareil permettant d'evaluer les differences entre des fournisseurs de services de sante

Also Published As

Publication number Publication date
EP2024887A1 (fr) 2009-02-18
US20110270621A1 (en) 2011-11-03
FR2901042A1 (fr) 2007-11-16
FR2901042B1 (fr) 2008-08-22

Similar Documents

Publication Publication Date Title
Reich et al. OHDSI Standardized Vocabularies—a large-scale centralized reference ontology for international data harmonization
Subrahmanya et al. The role of data science in healthcare advancements: applications, benefits, and future prospects
US20240331844A1 (en) Methods, Systems and Computer Program Products for Retrospective Data Mining
Banerjee et al. Patient-reported outcome measures in safety event reporting: PROSPER consortium guidance
EP1994484B1 (fr) Plate-forme pour l'échange interfonctionnel de données de soins de santé
US8180654B2 (en) Method and system for creating, assembling, managing, utilizing, and securely storing portable personal medical records
US20020111833A1 (en) Method and apparatus for requesting and retrieving de-identified medical information
US20010037216A1 (en) Pharmacy benefits management method and apparatus
US20230385450A1 (en) Human-centric health record system and related methods
Proper et al. Impact of clinical pharmacists in the emergency department of an A ustralian public hospital: A before and after study
FR2902553A1 (fr) Systemes et procedes pour identifier et/ou evaluer des risques potentiels d'intolerance associes a une therapie medicale.
WO2021237345A1 (fr) Système de dossiers médicaux centré sur l'humain et procédés associés
US20170061103A1 (en) System For Operating A Clinical Trial
WO2016175649A1 (fr) Système de facilitation de télé-santé et de télémédecine et procédé associé
Veldhuizen et al. Effect of COVID-19 on smoking cessation outcomes in a large primary care treatment programme: an observational study
Van De Garde et al. Pharmacotherapy within a learning healthcare system: rationale for the Dutch Santeon Farmadatabase
US20100036679A1 (en) Methods And Apparatus For Responding To Request For Clinical Information
KR102052066B1 (ko) 블록체인을 활용한 원격 cro 시스템 및 그 방법
EP2024887A1 (fr) Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation
Ng et al. Concordance of a decision algorithm and multidisciplinary team meetings for patients with liver cancer—a study protocol for a randomized controlled trial
Higashi et al. Harmonizing qualitative data across multiple health systems to identify quality improvement interventions: A methodological framework using PROSPR II cervical research center data as exemplar
Tazare et al. Sharing is caring? International society for Pharmacoepidemiology review and recommendations for sharing programming code
Hochreiter-Hufford et al. Real-world data to support post-market safety and performance of embolization coils: evidence generation from a medical device manufacturer and data institute partnership
Pencina et al. Deriving real-world insights from real-world data: biostatistics to the rescue
CN112133393A (zh) 医疗服务系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07729154

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2007729154

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12300994

Country of ref document: US