FR2901042A1 - 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 PDFInfo
- Publication number
- FR2901042A1 FR2901042A1 FR0604331A FR0604331A FR2901042A1 FR 2901042 A1 FR2901042 A1 FR 2901042A1 FR 0604331 A FR0604331 A FR 0604331A FR 0604331 A FR0604331 A FR 0604331A FR 2901042 A1 FR2901042 A1 FR 2901042A1
- Authority
- FR
- France
- Prior art keywords
- evaluation
- file
- data
- 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.)
- Granted
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
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
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 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 généralement en une étude 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. Une telle démarche d'évaluation peut également 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 . Les informations servant de base à ces opérations d'évaluation 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 peuvent également porter sur les soins médicaux et ou 1 chirurgicaux prodigués ou à prodiguer, ainsi que sur les différents produits qui peuvent être utilisés pour réaliser ces soins. Ces informations peuvent être 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 aux opérations d'évaluation. Les inconvénients que présentent le processus et les outils actuels seront également mis en évidence.
Selon le processus actuel, le médecin saisit sur un support informatique ou sur un support papier les informations collectées pendant l'acte de diagnostic ou de traitement du patient. A partir de ces informations, appelées données patient , un dossier patient est constitué et conservé au sein de la structure de soin pendant une durée légale et constitue un document médico-légal. Lorsqu'une opération d'évaluation est demandée, l'acteur de soins doit, à partir du dossier patient, ressaisir ou faire ressaisir les données patient requises soit sur un support papier, soit sur un support informatique d'une application fournie par le promoteur de l'opération d'évaluation. Dans ce dernier cas, l'acteur de soins doit se familiariser avec le nouvel outil informatique fourni par le promoteur. Les informations ainsi ressaisies sont désignées données d'évaluation et constituent des dossiers d'évaluations. Les données d'évaluations sont ensuite transmises par chacune des structures de soins participant à l'opération d'évaluation au promoteur. Les contraintes et réglementations strictes qui s'appliquent à l'utilisation des données médicale impliquent un retraitement obligatoire des données issues des dossiers patient avant toute exploitation par un promoteur.
Ces contraintes et réglementations exigent notamment la signature des personnes ajoutant ou modifiant ces données, que la traçabilité des données soit possible, et l' anonymisation des dossiers patient. 2 De plus, pour être pertinentes ces ressaisies nécessitent de faire vérifier la cohérence des données d'évaluation transmises au promoteur. Cette étape, appelée étape de contrôle, étape d'audit ou encore étape de monitoring, implique que des collaborateurs ou des prestataires du demandeur 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 reçues 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. Lorsque les données d'évaluations ont été vérifiées, elles peuvent être exploitées. Les processus actuels présentent de nombreux inconvénients qui 15 portent tant sur la saisie 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 à la recherche physique des dossiers et à la 20 ressaisie des données des dossiers patients pour constituer les dossiers d'évaluations. Ces contraintes s'avèrent particulièrement fastidieuses et limitent l'implication des l'acteur de soins , pourtant cruciale dans ce type d'opération d'évaluation clinique. 25 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 chez le promoteur. Ce décalage temporel provient du délai nécessaire à la ressaisie des données et à l'acheminement des données d'évaluation depuis le centre de soin jusqu'au promoteur dans le cas de saisie sur 30 support papier. Ce décalage temporel limite l'efficacité des opérations d'évaluation. 3 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 5 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. 10 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 15 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 20 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é aient leur dossier inclus dans l'opération d'évaluation. La condition de consécutivité exige que tous les patients 25 consécutifs présentant des critères définis fassent l'objet d'un traitement donné. Or, en pratique ces deux conditions ne sont pas forcement 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 30 produit, ou encore par disfonctionnement d'un mode opératoire. Dans la pratique, l'utilisation défectueuse d'un matériel sera bien souvent non incluse dans la base de donnée patient. Le promoteur n'aura donc aucun retour d'information suite à l'utilisation de ce matériel. Or, la difficulté à 4 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 oeuvre 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 ou méconnus. Outre les inconvénients précités liés à 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 s'accompagne donc d'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 5 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é 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 autorisant leur manipulation dans un contexte d'opération 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 6 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 7 recopie manuelle des codes barres et à une constitution progressive d'un catalogue interne. Cette pratique occasionne une grande perte de temps, présente un grand risque d'erreur, une difficulté de mise à jour et ne permet pas 5 d'assurer une traçabilité fiable des matériels médicaux. Or, les fabricants de matériels devraient 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. 10 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 15 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 20 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, 25 - validation de cette saisie depuis une application patient, - traitement automatique du dossier patient par l'application patient pour constituer un dossier source qui respecte une ou plusieurs exigences réglementaires, - enregistrement du dossier source dans une base de données 30 source déployée dans le centre de soins participant à l'opération d'évaluation, - comparaison des données du dossier source avec des critères d'inclusion fournis par le promoteur de l'opération d'évaluation, 8 - 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é-inclsuion 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 9 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 centrales 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, et d'inclusion 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 10 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 5 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 10 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 15 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 20 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, 25 - 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 30 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, 11 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 centrale 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 12 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. Ces exigences réglementaires exigent é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. 13 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: 14 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 (terme courant dans le milieu médical et qui correspond aux initiales du terme anglo-saxon- case report form ), 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 20 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. 25 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 30 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 15 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 5 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 à : 10 - 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. 15 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 20 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 25 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 30 seuls les investigateurs peuvent accéder au module local d'évaluation 120. 16 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 10 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 15 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. 20 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. 25 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 30 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 17 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 à 20 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 25 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, 30 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 18 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. 19 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 10 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. 15 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 20 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. 25 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 30 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 20 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 10 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 15 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 20 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 25 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 30 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. 21 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 10 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 15 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. 20 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 25 à 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 30 comportant 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 commune 601 22 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 5 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. 10 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. 15 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. 20 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 25 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. 30 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. 23 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 5 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 10 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 15 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 20 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 25 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 30 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 24 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.
25 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é. 26
Claims (8)
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 5 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 10 patient (115) pour constituer un dossier 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) participant à l'opération d'évaluation, 15 -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, 20 -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 25 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). 30
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. 27
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. 28. 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, et d'inclusion sont validées 25 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 30 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. 29. 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 10 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 15 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 20 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 25 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, 30 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é. 30
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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 |
| PCT/EP2007/054705 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 |
| 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 |
| 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 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| 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 (2)
| Publication Number | Publication Date |
|---|---|
| FR2901042A1 true FR2901042A1 (fr) | 2007-11-16 |
| FR2901042B1 FR2901042B1 (fr) | 2008-08-22 |
Family
ID=37596434
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0604331A Expired - Fee Related 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 |
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)
| 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)
| 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 |
-
2006
- 2006-05-15 FR FR0604331A patent/FR2901042B1/fr not_active Expired - Fee Related
-
2007
- 2007-05-15 US US12/300,994 patent/US20110270621A1/en not_active Abandoned
- 2007-05-15 EP EP07729154A patent/EP2024887A1/fr not_active Withdrawn
- 2007-05-15 WO PCT/EP2007/054705 patent/WO2007132006A1/fr active Application Filing
Patent Citations (3)
| 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 |
|---|---|
| US20110270621A1 (en) | 2011-11-03 |
| FR2901042B1 (fr) | 2008-08-22 |
| EP2024887A1 (fr) | 2009-02-18 |
| WO2007132006A1 (fr) | 2007-11-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20170076049A1 (en) | System for Electronically Recording and Sharing Medical Information | |
| US10169607B1 (en) | Individual centric personal data management process and method | |
| US20160103963A1 (en) | Method and system for smart healthcare management | |
| US20120215560A1 (en) | System and methods for facilitating computerized interactions with emrs | |
| FR2902553A1 (fr) | Systemes et procedes pour identifier et/ou evaluer des risques potentiels d'intolerance associes a une therapie medicale. | |
| FR2814832A1 (fr) | Sources d'informations biomedicales multiples integrees | |
| US20220148710A9 (en) | Methods, Systems and Computer Program Products for Retrospective Data Mining | |
| Fraser et al. | Adaptation of a web-based, open source electronic medical record system platform to support a large study of tuberculosis epidemiology | |
| 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 | |
| US20140058756A1 (en) | Methods and apparatus for responding to request for clinical information | |
| WO2016175649A1 (fr) | Système de facilitation de télé-santé et de télémédecine et procédé associé | |
| Ahmed et al. | Portable health clinic: A telehealthcare system for unreached communities | |
| Zeleke et al. | Data quality and cost-effectiveness analyses of electronic and paper-based interviewer-administered public health surveys: systematic review | |
| Hou et al. | National ADR monitoring system in China | |
| Deserno et al. | Integrated image data and medical record management for rare disease registries. A general framework and its instantiation to the German Calciphylaxis Registry | |
| FR2901042A1 (fr) | Systeme et procede de gestion de donnees relatives a un patient dans le cadre d'une operation d'evaluation | |
| Hazlehurst et al. | CER Hub: An informatics platform for conducting comparative effectiveness research using multi-institutional, heterogeneous, electronic clinical data | |
| Bazel et al. | Hospital information systems in malaysia: Current issues and blockchain technology as a solution | |
| CN112133393A (zh) | 医疗服务系统 | |
| KR102052066B1 (ko) | 블록체인을 활용한 원격 cro 시스템 및 그 방법 | |
| EP2733631A1 (fr) | Système pour la tracabilité automatique des dispositifs médicaux | |
| Katal et al. | Potential of blockchain in telemedicine | |
| McDonald et al. | Extracting data from a chemotherapy prescription platform for real-world oncology research in the UK: a pilot study | |
| CN115668178A (zh) | 用于追溯性数据挖掘的方法、系统和计算机程序产品 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20120131 |