FR2835635A1

FR2835635A1 - Procede de realisation d'etudes destine a un systeme collaboratif en reseau

Info

Publication number: FR2835635A1
Application number: FR0201397A
Authority: FR
Inventors: Dominique Delmas
Original assignee: SIGNCLINIC SARL E
Current assignee: SIGNCLINIC SARL E
Priority date: 2002-02-06
Filing date: 2002-02-06
Publication date: 2003-08-08
Anticipated expiration: 2022-02-06
Also published as: AU2003222868A1; WO2003067501A1; FR2835635B1; EP1474769A1

Abstract

Le procédé de réalisation d'études, destiné à un système collaboratif comportant, en réseau, un site central, au moins une entité Sponsor/ Architecte, au moins une entité Investigateur apte à être concernée par l'étude, au moins une entité Moniteur, le procédé comprenant les étapes d'élaboration d'une étude et de modification éventuelle de l'étude par le Sponsor/ Architecte, de stockage par le site central de l'étude et des données saisies, de manière non connectée de préférence, par l'investigateur, de distribution à l'investigateur de l'étude, de monitorage, revue de données et/ ou d'audit par le Moniteur et de clôture de l'étude par le Sponsor/ Architecte.

Description

L'invention concerne la réalisation électronique d'études, notamment d'études cliniques.

Par"études", on entend aussi bien les études proprement dites que l'analyse, la recherche et, plus généralement, la conduite de projet.

Dans le domaine par exemple des études cliniques appliquées à l'industrie pharmaceutique, le suivi et la constitution des dossiers d'études s'effectuent, pour une très large majorité, de manière traditionnelle, sous forme papier. Seules à ce jour environ 5 à 8% des études cliniques s'effectuent de manière électronique. Cette réalisation électronique a pour avantage de réduire les coûts de traitement des données recueillies, de monitorage, d'accroître la qualité des études en obtenant des résultats plus sensibles et d'obtenir un gain de temps d'environ de 10 à 20 % dans le déroulement global d'une étude clinique.

Le document WO 99/63473 présente un exemple d'une telle réalisation électronique dans le domaine des études cliniques. Cette dernière s'effectue exclusivement de manière dite"on-line" (en ligne), c'est-à-dire que l'utilisateur, que ce soit un Moniteur ou un Investigateur, doit être connecté au serveur central pour pouvoir utiliser le système électronique d'études cliniques.

D'autre part, notamment dans le cadre d'une utilisation"off-line", du fait de la multitude d'environnement de systèmes d'exploitation (OS pour Operating System selon le terme anglo-saxon) et de

types de plate-formes pouvant exister chez chacun des utilisateurs, le système électronique doit être adapté à chacun des cas de configuration.

De ces faits, de nombreux inconvénients surgissent l) le fait de devoir être connecté au serveur central conduit à des temps de réponse plus ou moins long de la part de ce dernier selon sa charge et selon la charge du réseau par lequel transitent les différentes informations ;
2) la multitude de configurations existantes de plate-formes Investigateur conduit à une lourdeur et des risques d'aléas dans la gestion et les mises à jour des différentes versions du système électronique, c'est- à-dire qu'il est nécessaire d'avoir une version logicielle spécifique pour une configuration matérielle donnée.

D'autre part, au niveau des centres d'investigation et en particulier pour les hôpitaux et les cliniques, l'intégration d'un tel système électronique dans un environnement informatique souvent complexe, très contrôlé et très protégé, est relativement difficile, sachant que les protocoles de communication avec l'extérieur considérés comme à risque, tel que le FTP (File Transfer Protocol ou Protocole de Transfert de Fichier) sont proscrits et souvent inhibés par l'administrateur de réseau. Ceci a pour inconvénient de rendre difficile la communication avec le serveur central d'études qui est situé généralement en un site distant, en aval des pare-feux (firewalls en langage

anglo-saxon) qui protègent les réseaux internes des hôpitaux et des cliniques.

Un but de l'invention est de fournir un procédé de réalisation d'études s'amendant des inconvénients dus au travail en mode"on line", tout en assurant fiabilité, performance et robustesse lors de l'exploitation.

Pour cela, on prévoit, selon l'invention, un procédé de réalisation d'au moins une étude, destiné à être mis en oeuvre par un système collaboratif comportant, en réseau, un site central, au moins une entité Sponsor/ Architecte, au moins une entité Investigateur apte à être concernée par l'étude, au moins une entité Moniteur, le procédé comprenant les étapes de : a) élaboration des éléments de l'étude par l'entité
Sponsor/Architecte, b) décision de lancement de l'étude par l'entité
Sponsor/Architecte, c) modification éventuelle en cours d'étude par l'entité Sponsor/Architecte de l'un ou de plusieurs éléments de l'étude, d) stockage des éléments de l'étude par le site central comportant des premiers moyens de mémorisation à cet effet, après transmission desdits éléments par l'entité Sponsor/Architecte au site central, e) distribution des éléments appropriés de l'étude par le site central à l'entité Investigateur, f) saisie par des moyens de saisie de l'entité
Investigateur des données de l'étude et mémorisation en local de ces données sur des moyens de mémorisation de l'entité Investigateur

sans que cette dernière soit connectée au reste du système collaboratif, g) transmission des données de l'étude au site central par Identité Investigateur, stockage de ces données dans une base de données sur des deuxièmes moyens de stockage sur le site central, et synchronisation de ces données entre le site central et l'entité Investigateur, h) monitorage, revue de données et/ou audit de l'étude par l'entité Moniteur soit auprès du site central, soit auprès de l'entité
Investigateur sans que cette dernière soit connectée au reste du système collaboratif, et, i) clôture de l'étude au niveau de l'entité
Investigateur par l'entité Sponsor/Architecte, via le site central.

Ainsi, les étapes effectuées de manière locale au sein d'une entité peuvent se dérouler sans que ladite entité soit connectée au reste du système collaboratif, et en particulier l'entité Investigateur. Ainsi, la saisie des données d'étude est-elle plus rapide et plus efficace, possible 24 heures sur 24, car elle reste indépendante des conditions d'accès et de l'état du réseau la reliant aux autres entités, et en particulier le site central.

Avantageusement, le procédé présente au moins l'une des caractéristiques suivantes : les moyens de saisie et les moyens de mémorisation des données de l'étude par l'entité Investigateur sont agencés de sorte à être utilisables

dans une grande variété d'environnements matériel et logiciel ; les moyens de saisie et les moyens de mémorisation des données de l'étude par l'entité Investigateur sont agencés de sorte à permettre une utilisation parallèle sans interférence d'autres procédés que celui dédié à l'étude, et sans interférence entre les moyens de l'étude et ces autres procédés, ainsi qu'une utilisation de manière indifférente selon un mode mono ou multiposte et une sécurisation rigoureuse aux plans physique et/ou logiciel ; - les données mémorisées par l'entité Investigateur ont été collectées par des moyens de saisie autonomes connectable à l'entité Investigateur ; - les données saisies et mémorisées au niveau de l'entité Investigateur ne sont prises en compte au niveau du site central qu'accompagnées d'un certificat numérique valide authentifiant une signature électronique d'un utilisateur autorisé qualifié de l'entité Investigateur et une non répudiation par cet utilisateur desdites données ; - chacune des données prises en compte au niveau du site central, authentifiée par la signature électronique à laquelle elle est associée, fait l'objet d'une étape de vérification d'intégrité à des fins d'exploitation, d'audit et de stockage ; - le stockage par le site central des données saisies est agencé de sorte à préserver un lien insécable entre lesdites données et le certificat valide, authentifiant la signature associée aux dites données ; - le certificat valide authentifiant la signature associée aux dites données est stocké de manière

consultable par les moyens de mémorisation de l'entité Investigateur ; - les transmissions et distribution de données et/ou d'éléments d'étude s'effectuent dans un format XML, et le stockage sur le site central s'effectue dans un format XML natif dans la base de données, notamment la base de données étant en XML natif ; - des modifications et/ou des additions d'éléments de l'étude en cours d'étude sont effectuées de façon dynamique sans interruption ni restructuration de la base de données ; - les données saisies et mémorisées sont aptes à être enrichies dynamiquement ; - le système collaboratif comportant une entité exploitation de données, le procédé comprend un étape d'exploitation de tout ou partie des données stockées par le site central par l'entité exploitation de données ; - lors de la saisie des données par l'entité Investigateur, si une donnée saisie est non transmissible au site central, elle est mémorisée sur des moyens de stockages amovibles de l'entité Investigateur ; et, - le procédé est agencé de sorte à être appliqué à des études et des recherches cliniques et épidémiologiques.

D'autres caractéristiques et avantages apparaîtront lors de la description suivante d'un mode de réalisation de l'invention. Aux dessins annexés :
La figure 1 est une représentation schématique de l'interaction entre les différents éléments

constituant un système collaboratif selon l'invention,
La figure 2 est une vue schématique de la constitution du site central de la figure 1,
La figure 3 est une vue schématique de l'agencement d'un dispositif dénommé"boite noire"d'une entité Investigateur de la figure
1,
La figure 4 est une représentation schématique d'interaction entre la boite noire et un réseau local formant l'entité Investigateur de la figure 1,
Les figure 5a, 5b et 6 est un exemple d'organisation d'une étude mise en oeuvre sur l'entité Investigateur.

En référence à la figure 1, nous allons décrire un système collaboratif destiné à la réalisation d'études, notamment d'études cliniques. Ce système collaboratif comprend quatre entités fonctionnelles de base :
Une première entité, appelée Sponsor/Architecte permettant le paramétrage d'une étude ainsi que son pilotage, de la création de cette étude à sa clôture,
Une entité, appelée site central qui est un serveur d'applications et de bases de données aptes à stocker des données selon un format prédéfini, de préférence XML natif, (XML : extensible Markup
Language selon le terme anglo-saxon, ou Langage de
Balises Extensible),
Une entité, appelée Investigateur, apte à permettre la saisie et le monitorage de données de manière dite"off-line" (hors ligne), leur synchronisation

croisée avec la base de données centrale située sur le site central et le stockage en local de ces mêmes données,
Une entité Moniteur apte à réaliser le monitorage ainsi que l'audit de l'étude de façon distante à partir d'un poste Moniteur, via un client web installé sur le site central ou sur l'entité
Investigateur,
L'entité Sponsor/Architecte a pour rôle principal de permettre la conception d'un dossier de suivi destiné à une campagne de mesure d'un certain nombre de paramètres qui constitue une étude. L'Architecte, utilisateur de l'entité Sponsor/Architecte (le concepteur) peut générer l'ensemble des écrans (forme visualisable des formulaires électroniques) nécessaires à cette campagne de mesures, implémenter l'ensemble des paramètres spécifiques à une étude, constituer et mettre à jour un annuaire des utilisateurs du système et gérer leurs privilèges et générer ainsi l'application permettant la gestion de ces écrans et la saisie des données dans ces écrans selon les privilèges d'accès, ainsi que générer la base de données correspondante apte à enregistrer les données de saisie. La conception des écrans est réalisée en récupérant le plus d'éléments possibles déjà générés lors d'anciennes campagnes de mesures ou bien à partir de bibliothèques d'études, d'écrans ou encore de bibliothèques de composants comme des champs de saisie. Les moyens de l'entité Sponsor/ Architecte permettent également à l'Architecte (utilisateur de l'entité Sponsor/Architecte) de tester l'application ainsi générée dans des conditions d'utilisation identiques à celles des entités

Investigateurs et entité Moniteur, décrites ultérieurement.

Ainsi, la conception d'une campagne de mesure, allant du design de l'étude au paramétrage de l'étude en passant par les tests de contrôle, est réalisable en quelques jours (de l'ordre de cinq jours environ). L'ensemble du dossier de suivi ainsi réalisé est stocké pour d'éventuelles réutilisations de tout ou partie lors de la création de dossiers de suivi ultérieurs.

La conception d'un dossier de suivi pour une campagne de mesure se compose des étapes suivantes : l) l'élaboration de la structure du dossier, la mise en place des privilèges des différents intervenants de la campagne que sont les utilisateurs de l'entité
Sponsor/Architecte, les Investigateurs et leurs adjoints ainsi que les Moniteurs,
2) la mise en place, sur le site central, des éléments liés à la sécurité des différentes données qui vont être utilisées et rassemblées lors de la campagne (ce sont par exemple les clés pour signature, les clés pour le cryptage des données ainsi que le droit d'accès aux données),
3) les tests de contrôle avant et après l'exécution des différentes étapes de la campagne qui sont réalisées par l'entité Sponsor/Architecte via le site central.

Lors de l'élaboration de la structure du dossier d'une campagne de mesures, l'entité Sponsor/Architecte est apte à générer des formulaires qui vont constituer ledit dossier en utilisant ou en y incorporant des éléments de paramétrages, des éléments de contrôle de

saisie des informations dans les différents champs de données, des éléments d'ordonnancement, des traitements permettant un suivi et un compte-rendu, des applications spécialisées associées, ainsi que des jeux d'informations destinées à l'utilisateur des formulaires comme du texte, des images fixes ou animées, du son ou encore des dessins vectoriels ou non.

De manière générale, un formulaire comprend de manière préférentielle : - une liste de champs invoqués, leur définition et leur attribut, les spécifications sur les types de données, éventuellement des algorithmes d'auto-contrôle pour aider à la saisie, les éléments de sécurité, etc.... des"feuilles de style"qui définissent la présentation globale du formulaire à l'écran et l'interface de saisie des informations, - des possibilités pour attacher, lors de la saisie de données, des documents numérisés comme, pour le cas des études cliniques, un compte rendu médical, un électrocardiogramme, des clichés radiographiques à rayon X, des photographies, etc....

D'autre part, l'entité Sponsor/Architecte peut effectuer d'éventuelles modifications, en cours de campagne, dans la structure du dossier de campagne de mesures.

L'ensemble des éléments constituant un dossier de campagne de mesures pour la réalisation d'une étude forme une ou plusieurs applications qui sont aptes à être distribuées aux entités Investigateurs.

En référence aux figures 3 et 4, nous allons maintenant décrire en détail l'entité Investigateur du système collaboratif de la figure 1. En particulier, la figure 4 représente un exemple de la structure d'une entité Investigateur. Dans cet exemple, l'entité Investigateur comprend un poste Investigateur qui est connecté d'une part au réseau local d'une entité Investigateur, encore appelé centre d'investigation, et d'autre part au réseau Internet pour pouvoir joindre ou être joint par les autres unités du système collaboratif de l'invention. Le réseau local du centre d'investigation est ici composé de quatre postes dits postes utilisateurs. Cependant, le nombre de postes utilisateurs n'est pas limité en nombre. D'autre part, le centre d'investigation peut se composer d'un seul poste utilisateur directement relié au poste Investigateur.

La fonctionnalité principale du poste Investigateur est la collecte des données par l'intermédiaire de l'application et de l'ensemble des écrans de formulaires élaborés lors de la constitution du dossier de suivi pour la campagne de mesures par l'Architecte. Cette collecte de données s'effectue alors que le poste Investigateur n'est pas obligatoirement connecté à l'une des autres unités constitutives du système collaboratif, en particulier avec le site central. La seule connexion obligatoire qui soit réalisée est une connexion, de préférence, limitée dans le temps avec le site central de manière à synchroniser de façon croisée les données enregistrées et signées sur le poste Investigateur dans la base de données présente dans le site central.

Les communications avec le site central sont cryptées et sécurisées à l'aide d'un jeu de clés privées/clés publiques, les clés de chaque Investigateur étant différentes. La saisie des informations peut être effectuée par différents opérateurs, le responsable de la campagne de tests sur le centre d'investigation est le seul à valider et à signer électroniquement les données saisies à l'aide d'un certificat de signature qui est, de manière préférentielle, un certificat de type X. 509. Pour un même centre d'investigations, plusieurs responsables de campagne peuvent être nommés mais un formulaire de données saisies ne peut être signé que par un seul responsable pour une version donnée de ce formulaire.

Le poste Investigateur se présente comme illustré à la figure 3, sous la forme d'un dispositif appelé"boîte noire". Cette"boîte noire"comprend un processeur associé à de la mémoire active (RAM) ainsi qu'à une mémoire de stockage qui peut se présenter sous la forme préférentielle d'un disque dur ou bien d'une carte mémoire dites"flash"connue en soi. De plus, cette boite noire présente des moyens de connexion vers l'extérieur de manière à être reliée au réseau local d'un centre d'investigation ainsi qu'aux autres entités formant le système collaboratif de l'invention de manière préférentielle par l'intermédiaire du réseau Internet. Cependant, il est envisageable que la connexion aux autres éléments du système collaboratif de l'invention se déroule à l'aide du réseau téléphonique (RTC, RNIS ou xDSL/ADSL) à l'aide d'un modem, ou encore à l'aide d'un GSM, d'une liaison satellite, ou de tout autre moyen de communication mobile. Enfin, la boite

noire comporte un lecteur de carte à puce apte à permettre l'identification du ou des utilisateurs de la boite noire possédant une carte à puce lisible par ledit lecteur. Préférentiellement, une carte à puce est nécessaire pour ouvrir l'application et permettre l'authentification des utilisateurs par login et mot de passe. Préférentiellement, une deuxième carte à puce, à des fins de signature, est nécessaire afin de permettre à chacun des responsables de signer les données des formulaires. Cependant, la carte à puce utilisée à des fins de signature peut contenir les éléments nécessaires à l'ouverture des applications contenue dans la boite noire et de l'authentification des utilisateurs. Il est à noter que la carte à puce permettant l'ouverture des applications de la boite noire peut contenir en outre des paramètres permettant de configurer la boite noire de manière à l'intégrer au sein d'un réseau, en particulier d'un réseau local de l'entité Investigateur.

Enfin, dans l'exemple des études cliniques, l'identité des patients peut être stockée sur une carte à puce, permettant ainsi de visualiser le nom des patients au niveau de l'entité locale, mais de ne pas faire remonter cette identité au niveau du site central.

Au niveau logiciel, la boite noire présente une première couche, dite de base, formée par un système d'exploitation. De préférence le système d'exploitation est un système de type UNIX, plus précisément le système d'exploitation peut être le système d'exploitation LINUX ou Windows NT.

La boîte noire comprend en outre des moyens logiciels de pilotage du lecteur de carte à puce

comprenant des fonctions de lecture et d'écriture sur la puce des cartes à puce aptes à y être insérées. La boîte noire comporte en outre des moyens de gestion des connexions vers l'extérieur. Ces connexions extérieures peuvent être des ports RJ45 aptes à relier la boite noire avec un réseau local ou Internet, des ports séries, des ports USB, ainsi qu'un modem. Les moyens de gestion de la connexion vers l'extérieur sont capables d'utiliser la plupart des protocoles de communication courants. En ce qui concerne une connexion à un réseau local et/ou sur le réseau Internet, le protocole de communication préférentiellement utilisé est le TCP/IP (Tranmission Control Protocol/Internet Protocol ce qui signifie Protocole de Contrôle de Transmission/Protocole Internet).

La boîte noire comprend aussi une couche logiciel formant des moyens de gestion des accès sécurisés. Ces moyens de gestion d'accès sécurisés permettent, notamment de vérifier si un utilisateur venant à se connecter à la boîte noire est un utilisateur autorisé. Si ce dernier est un utilisateur autorisé, les moyens de gestion d'accès établissent les permissions d'utilisation des applications enregistrées d'une part, les droits d'accès en lecture et en écriture sur la base de données enregistrées en local d'une part, ainsi que les autorisations de signature des documents et la gestion de la sécurité des transmissions des données vers le site central lors de la synchronisation des données comportant des étapes de cryptage et de scellement de ces données avant transmission et stockage. La boite noire contient en plus, des

composants de sécurité tel que un pare-feu, un antivirus...

La boite noire présente aussi des moyens formant serveur tel qu'un serveur WEB apte à permettre l'accès aux applications formant l'étude à réaliser sur les différents postes du réseau local et, d'autre part, permettre l'accès aux entités Sponsor/Architecte et Moniteur du système collaboratif de l'invention. Ces moyens de serveur comprennent aussi un serveur dit FTP (File Transfer Protocol ou Protocole de transfert de Fichier) qui permet la transmission de données sous forme de fichiers lors de la synchronisation des données avec le site central, et/ou lors de la télédistribution des applications aptes à réaliser une étude.

Enfin la boite noire comprend la ou les applications formant la ou les études en cours ou à réaliser par le centre d'investigation ainsi que les bases de données rassemblant l'ensemble des mesures effectuées lors de ces études.

Il est à noter que la boite noire ne comprend ni écran ni clavier apte à réaliser une interface homme/machine traditionnelle telle que nous la connaissons pour un poste de travail traditionnel. La seule possibilité de communication avec la boite noire se réalise à travers les moyens de connexion vers l'extérieur. De ce fait, la saisie des données lors d'une campagne de mesure réalisée sur un centre d'investigation s'effectue sur les postes utilisateurs propres au centre d'investigation qui peuvent être mis en réseau de manière locale, réseau auquel est connecté

la boite noire. Cela permet de contrôler parfaitement les accès qui sont réalisés sur les données et les applications contenues dans la boite noire, et ainsi en assurer leur sécurité. La seule interface homme/machine que présente la boite noire est constituée d'un bouton on/off permettant la mise sous tension de ladite boite noire, d'une diode luminescence de couleur verte préférentiellement indiquant que le fonctionnement de la boite noire, une fois mise sous tension, est correcte, et d'un lecteur de carte à puce permettant de vérifier l'identité du ou des utilisateurs.

Une telle structure de la boite noire présente les avantages suivants : - Utilisation hors ligne de l'application, c'est-à- dire que la boite noire pour enregistrer les données d'une campagne de test n'a pas besoin d'être connectée aux autres unités constituant le système collaboratif de l'invention, - L'étude est mise en place de manière"plug and play" (branchez et utilisez) sans nécessiter d'administration en local : ainsi les études sont mises en place à distance sans recourir à une présence physique d'un administrateur quelconque au centre d'investigation. Dans le même ordre d'idée, la conduite de l'étude sur le centre d'investigation s'effectue, elle aussi, sans administration locale.

L'ensemble des écrans et de l'application constituant le dossier de suivi d'une étude ainsi que les modifications éventuelles ultérieures sont simplement télédistribuées sur les différentes boites noires des entités Investigateurs,

- Enfin, au sein d'un centre d'investigation, la saisie des données peut se faire sur un poste utilisateur unique directement relié à une boite noire ou de manière multiposte sur un réseau local sur lequel est connectée une boite noire, fonctionnant alors comme un serveur.

Un autre avantage d'intégrer la boite noire au réseau local d'un centre d'investigation est de pouvoir interfacer les applications des études avec la base de données des patients du centre. Cela permet de synchroniser les données communes entre la base de données des patients et celles de la boite noire.

D'autre part, cela évite à l'Investigateur de saisir deux fois certaines données : une fois pour les besoins de l'étude, une seconde fois pour la base de données des patients. Cependant, aucune information confidentielle, comme le nom des patients, n'est transmise aux autres entités du système collaboratif de l'invention.

Il est à noter qu'au sein du centre d'investigation, les postes utilisateurs connectés à la boite noire peuvent être très hétérogènes : ce peut être des postes de type PC (Personal Computer ou Ordinateur Personnel) fonctionnant sous des systèmes d'exploitation comme Microsoft Windows (marque déposée) ou LINUX, des stations UNIX, des ordinateurs APPLE (marques déposées), ou encore des assistants personnels numériques (ou PDA selon l'acronyme anglo-saxon Personal Digital Assistant).

D'autre part, la boite noire peut être protégée de toutes intrusions intempestives physiques non

autorisées. En effet, si un tiers essaie d'ouvrir le boîtier de la boite noire, l'ensemble des informations enregistrées dans la mémoire de stockage est irrémédiablement effacé. De plus, il est possible de prévoir des moyens de destruction physique des différents éléments composant l'intérieur de la boite noire. De tels moyens peuvent être notamment un capteur d'ouverture de la boîte associé à des moyens d'effacement physiques des données sensibles de la boite noire.

Dans une variante de réalisation de la boîte noire, cette dernière est réalisée sous forme d'une ou plusieurs cartes micro-électroniques directement insérées au sein du poste utilisateur.

Dans une autre variante de réalisation de la boite noire, destinée pour des utilisateurs mobiles ou itinérants, la boite noire est incluse dans un ordinateur portable, de type PC par exemple, ou dans un PDA évolué, type"tablette mobile". Les informations saisies avec ces moyens autonomes sont transmises directement au site central via un réseau ou à un autre poste investigateur éventuellement.

Nous allons maintenant expliquer brièvement le fonctionnement de la boite noire. La boite noire est livrée au centre d'investigation pré installée et pré configurée. Les couches logiciels formant le système d'exploitation, les moyens de gestion du lecteur de carte à puce, les moyens de gestion de la connexion vers l'extérieur, les moyens de gestion des accès sécurisés ainsi que les moyens formant serveur sont installés dans

la boite noire configurés pour être intégrée au réseau local du centre d'investigation. Lorsqu'il désire utiliser la boite noire, l'utilisateur connecte son poste à la boite noire via le port série ou le port USB ou le port RJ45 pour accès au réseau. L'utilisateur a accès aux applications à travers les moyens formant serveur, et plus particulièrement aux moyens formant serveur web en utilisant un navigateur standard et connu en soi tel que"Netscape Communicator"ou"Internet Explorer" (qui sont des marques déposées). Avant de pouvoir lancer les applications, l'utilisateur doit s'identifier auprès de la boite noire. Pour cela, de manière préférentielle, il insère sa carte à puce dans le lecteur de carte à puce permettant ainsi de valider ses accès au contenu de la boite noire à l'aide d'une identification et d'un code d'accès associé à la carte à puce qu'il utilise. Si toutes les vérifications de sécurité sont correctes, l'utilisateur peut faire fonctionner les applications associées à une étude.

En référence aux figures 5a, 5b et 6, nous allons décrire un exemple de fonctionnement d'une application pour la réalisation d'une étude clinique au niveau de l'entité Investigateur.

L'application fonctionne selon deux modes : - un mode dit responsable illustré en figure 5a, et - un mode dit opérateur illustré en figure 6b.

Le mode responsable se différentie du mode opérateur par la possibilité de signature d'un formulaire (notamment le CRForm ou Case Report Form

selon le terme anglo-saxon, ou Formulaire de Rapport de Cas) de manière non répudiable.

Dans un premier temps, l'utilisateur (responsable ou opérateur) arrive sur une page d'accueil de l'espace de travail. Le passage par ce formulaire est indispensable pour toute action car il sert à identifier et authentifier auprès de la boite noire de l'utilisateur. L'utilisateur est invité à indiquer son "login" (Identifiant de connexion) et son mot de passe ; il valide cet écran à l'aide d'un bouton, par exemple. De manière préférentielle, ce formulaire de connexion contient le choix de la langue d'interface. Le formulaire est ensuite transmis de manière sécurisée à la boite noire. Au niveau de cette dernière, le mot de passe est chiffré en clé injective et cette clé est comparée à celle stockée dans une base de données locale du poste Investigateur
Une fois connecté, l'utilisateur est face à un menu composé en fonction de ses droits. Le menu lui donne accès aux différents modules de l'application. A partir de ce point, comme illustré en figure 6, l'écran se compose de deux parties. Le menu apparaît sous forme d'une barre sur le haut de l'écran. L'affichage du module sélectionné se fait dans la partie principale de l'écran, qui est elle-même divisée en 3 espaces : Sous le menu, une partie est dédiée à la visualisation de la navigation. Un menu fonctionnel est situé à gauche et l'espace de travail proprement-dit, à droite.

Un module"Synchronisation"permet à un utilisateur autorisé de l'entité Investigateur de faire un téléchargement vers le site central des données signées

en local et, depuis ce dernier vers l'entité Investigateur, du chargement et des différentes mises à jour des applications et des données mises à jour sur le site central et destinées à la boite noire
L'utilisateur est averti de la tâche en cours. Il est à noter qu'à la fin des différentes opérations, une page peut expliquer à l'utilisateur s'il est nécessaire de redémarrer la boite noire pour prendre en compte les différentes modifications.

L'ensemble des échanges est réalisé préférentiellement de manière sécurisée.

Un module (non représenté) permet la gestion spécifique et sécurisée de certains éléments ou données particulières, en liaison avec l'ensemble des formulaires qui y sont associées. Ainsi, dans le cadre des études cliniques, certaines données très spécifiques peuvent être considérées comme des données hautement confidentielles nécessitant un traitement selon un procédé particulier. C'est le cas notamment de l'identité complète des patients, que, selon un paramétrage effectué au niveau de l'entité Sponsor/Architecte, on veut voir apparaître sur les écrans des postes d'utilisateur de l'entité Investigateur, mais qui ne doit pas être transmise au site central, et préférentiellement ne pas être stockée dans l'entité Investigateur. Dans ces conditions, ces données hautement confidentielles peuvent être stockées sur la carte à puce de l'utilisateur, et l'appel à ce procédé spécifique nécessite la présence de la carte à puce de l'utilisateur. Si la carte n'est pas présente dans le lecteur, une page est affichée, lui demandant de

l'insérer puis de composer son code secret associé à sa carte.

Ainsi, ce procédé permet d'ajouter/supprimer/mettre à jour des informations hautement confidentielles, et qui sont stockées sur la carte à puce. Il est à noter, que tout autre moyen de stockage amovible peut être utilisé, comme un disque dur amovible, des cartes mémoires type CompactFlash, etc..

Dans la cadre des études cliniques, ce procédé spécifique est destiné à ajouter/mettre à jour la liste des patients. Un patient est défini, notamment par : - UID (champ généré par l'application constituant un identifiant unique) - Nom - Prénom - Adresse - Date de naissance - Sexe
L'écran se compose d'une liste à gauche contenant les patients déjà définis. Une ligne contient l'UID, le nom, le prénom. Chaque UID nom de patient est un lien vers la fiche d'édition des données de ce patient.

Lorsque l'utilisateur clique dessus, les données sont affichées dans un formulaire sur la partie droite de l'écran. Cet écran permet de visualiser et de modifier les données d'un patient.

La liste est suivie d'un bouton Ajoute permettant d'ajouter un nouveau patient. Lorsque l'Investigateur clique sur ce bouton, le formulaire de droite est présenté vierge.

Tous les échanges relatifs à ce module sont transmis de manière sécurisée.

L'UID du patient est calculé en fonction des données saisies par un hachage.

L'UID sert de clé dans la base de données locale des patients.

Les données patients nominatives sont stockées sur la carte à puce.

Un autre module non représenté est dédié à la gestion des opérateurs de l'entité Investigateur. Il n'est accessible que par le responsable. Il permet à ce dernier d'ajouter/supprimer ou de geler les droits/ mettre à jour la liste des opérateurs ayant le droit de se connecter à la boite noire. Un opérateur est défini notamment par : - un Nom - un Prénom - un Login - un Mot de passe
Lorsqu'un opérateur est ajouté à cette liste, il obtient le droit de se connecter à la boite noire.

Lorsqu'il est supprimé ou que ses droits sont gelés, il perd le droit de se connecter à la boite noire, et ceci préférentiellement après que le responsable ait signé le formulaire gestion des opérateurs . Les données d'un opérateur ne peuvent être modifiées ou supprimées uniquement que si cet opérateur ne s'est jamais connecté. En effet, le nom de l'opérateur est utilisé lors d'audits ultérieurs.

L'écran se compose d'une liste à gauche contenant les opérateurs déjà définis. Une ligne contient le nom, le prénom, le login (qui doit être unique). Chaque nom

est un lien vers la fiche d'édition des données de cet opérateur. Lorsque l'Investigateur clique sur un de ces lignes, les données sont affichées dans un formulaire sur la partie droite de l'écran. Cet écran permet de visualiser les données d'un opérateur. Ces données peuvent être modifiées uniquement si l'opérateur ne s'est jamais connecté.

Les noms des opérateurs qui ne se sont jamais connectés sont suivis d'un bouton Supprime permettant de supprimer leurs données de connexion. Un écran de validation est présenté lors d'une demande de suppression. Lorsque les données d'un opérateur sont supprimées, le formulaire de droite est vidé.

La liste est suivie d'un bouton Ajoute permettant d'ajouter un nouvel opérateur. Lorsque le responsable clique sur ce bouton, le formulaire de droite est présenté vierge.

Pour la saisie du mot de passe, le formulaire présente deux champs de type mot de passe (sans écho à l'écran).

Lorsqu'on visualise les données d'un opérateur, le mot de passe n'est pas affiché. Les deux champs Mot de passe sont vides. Si le responsable modifie les données de l'opérateur sans remplir ces champs, le mot de passe n'est pas modifié. Cet écran peut servir au responsable pour changer le mot de passe d'un opérateur qui l'a oublié.

Les données du formulaire sont transmises de manière sécurisées. Le login doit être unique.

Lors de la publication du formulaire, le navigateur vérifie à l'aide d'un script (en langage java de manière préférentielle) que les deux champs'mot de passe'ont le même contenu.

Un module"sélection du patient"permet de naviguer dans les dossiers des patients. Il présente la liste des patients avec les informations suivantes : - un Etat du CRForm (icône) - un ID (identifiant du patient) - une Date d'inclusion
L'objet de ce module est la sélection d'un patient.

L'écran est composé d'une liste des patients.

Chaque patient ID est un lien hypertexte déclenchant la sélection de ce patient.

De là, deux possibilités s'offrent à l'utilisateur.

Soit, il sélectionne et ajoute un nouveau" formulaire ou un groupe de formulaires", qui ne sont pas planifiés. C'est le cas, par exemple de la sélection et de l'ajout d'un formulaire'adverse event' (effet indésirable). Ce formulaire est alors qualifié par un nom et une date. L'écran est composé d'un formulaire permettant de saisir le nom et la date de l''adverse event'à créer.

Au fur et à mesure que l'utilisateur progresse dans l'application, son parcours est visualisé sous la barre de menu. A ce stade, on affiche : nom du patient, nouvel 'adverse event'. A l'aide d'un script, on vérifie que la date est correcte, qu'elle n'est pas antérieure à la date d'inclusion ni à la date du dernier'adverse event' (s'il y en a) et qu'elle n'est pas postérieure à la date de fin de l'étude.

Soit, il sélectionne une visite, parmi la liste des visites associées au patient sélectionné avec l'iconographie associée. Cette liste est composée des

visites prévues et de formulaires correspondants à des événements tels que"adverse events", qui ont déjà été préalablement documentés. L'utilisateur peut sélectionner l'un de ces éléments.

L'écran est composé de la liste des visites. Chaque nom de visite est un lien hypertexte déclenchant la sélection de cette visite. Sous la liste des adverses events, un bouton Nouvel adverse event permet d'ajouter un nouvel'adverse event'.

Au fur et à mesure que l'utilisateur progresse dans l'application, son parcours est visualisé sous la barre de menu. A ce stade, on affiche : le nom du patient sélectionné.

De là, un module présente une liste des CRForms pour le patient choisi et pour la visite choisie. Chaque CRForm est précédé de son icône d'état. L'utilisateur a la possibilité d'en sélectionner un afin de visualiser ses composants. Le responsable a la possibilité de signer un CRForm comme nous le verrons ci-après.

L'écran présente une liste de CRForms sur la gauche. Chaque CRForm (précédé de son icône d'état) est un lien hypertexte permettant d'afficher le contenu du formulaire sur la partie droite de l'écran.

Au fur et à mesure que l'utilisateur progresse dans l'application, son parcours est visualisé sous la barre de menu. A ce stade, on affiche : nom du patient Il nom de la visite.

Si l'utilisateur est un responsable, chaque CRForm est suivi d'un bouton Signe lui permettant de signer de manière non répudiable le CRForm. Le CRForm est affiché dans son intégralité sous une forme qui permet

de le rendre'certifiable'. La carte à puce est requise pour cette opération et elle nécessite la saisie d'un code pin ainsi que la présentation des mentions contractuelles liées à la signature électronique. En cliquant sur le bouton Signe , on affiche une boite de dialogue permettant la saisie du code pin et on affiche le document correspondant au CRForm dans une nouvelle fenêtre avec un bouton signe en bas.

Une fois que l'utilisateur a sélectionné un CRForm, un module"Sélection d'un composant" lui présente une liste des composants associés au CRForm sélectionné.

Pour chacun de ces composants, on affiche un icône d'état, un nom du composant, un nombre de questions (encore appelées queries dans le cadre des études cliniques), la présence éventuelle d'un ou plusieurs commentaires, et un état de vérification des données sources (si nécessaire).

L'utilisateur est face aux différents objets du formulaire sélectionné. Il peut saisir des valeurs ou les modifier. Préférentiellement, ces informations sont enregistrées au fur et à mesure dans la boite noire. Si l'objet fait l'objet de questions, l'utilisateur a la possibilité d'entrer dans un module commentaires pour y répondre ; l'utilisateur peut également ajouter un commentaire sans question préalable. Pour les données ayant un historique, l'utilisateur peut visualiser un audit les concernant.

L'écran est le même que précédemment décrit.

L'utilisateur est face à un formulaire composé de groupes d'objets (un composant est un groupe d'objets).

Un objet est un (ou un groupe d') élément (s) de formulaire : zones de texte, cases à cocher, listes

(éventuellement à choix multiple), listes déroulantes, boutons d'options.

Au fur et à mesure que l'utilisateur progresse dans l'application, son parcours est visualisé sous la barre de menu. A ce stade, on affiche : nom du patient Il nom de la visite Il nom du CRForm.

L'état de modification d'un objet est associé à une case à cocher affichée, par exemple à gauche du nom de l'objet. Lorsque l'utilisateur modifie la donnée, il signale sa modification à la boite noire en cochant cette case. Il ne s'agit ni de la validation ni de la signature : il s'agit simplement d'un état de modification. Si la case d'un objet est cochée et que l'utilisateur modifie la donnée associée, la case est automatiquement décochée.

L'état de travail est automatiquement sauvegardé sur la boite noire. A chaque coche (état de modification), l'ensemble de la page est sauvegardé en l'état.

Dans le cadre des études cliniques, des icônes d'état du composants sont présents à gauche du nom du composants, par exemple : Une icône pour un composant vierge Une icône pour un composant saisi, mais non signé Une icône pour un composant saisi, et signé Une icône pour un composant saisi, signé et validé par l'entité Moniteur Une icône pour un composant saisi, signé avec une question émise par l'entité Moniteur Une icône pour un composant saisi, signé, validé puis gelé par l'entité moniteur.

Lors de modifications d'un composant déjà signé, l'icône reprend la valeur de l'icône : donnée saisie, mais pas signée. En parallèle, toute modification, quel que soit l'état du composant est mentionné dans l'historique.

La valeur de l'état du composant le moins avancé se retrouve au niveau du CRForm, au niveau de la Visite (ou sous partie), au niveau du patient, et du centre Investigateur. L'état le moins avancé est relatif à l'action à entreprendre par l'utilisateur.

D'autres modules sont également disponibles, tels que la gestion des documents contractuels de l'étude, la gestion de formulaires patients, par exemple pour les études cliniques, le partage de données avec une autre entité Investigateur distante, la gestion d'indicateur d'études, la gestion de calendrier relatifs à des événements à suivre (par exemple, la gestion des visites patients dans le cadre des études cliniques),...

En référence à la figure 2, nous allons maintenant décrire le site central. Le site central a pour vocation, au sein du système collaboratif formant l'invention, de centraliser l'ensemble des données résultant d'une étude donnée, l'ensemble des études déjà réalisé, ou en cours de réalisation ou à réaliser ainsi que le ou les applications associées à chacune de ces études et ce dans toutes leurs versions (si plusieurs versions existent pour une même étude). Le site central est relié au réseau externe, de préférence le réseau Internet, à travers un premier pare-feu. Les pare-feu ont pour rôle de protéger le ou les postes et/ou réseaux auxquels il est connecté, de toute intrusion externe non

autorisée. Derrière ce premier pare-feu, le site central comprend d'une part un serveur WEB et d'autre part un serveur annuaire.

Le serveur WEB va permettre l'accès aux applications d'un serveur d'applications ainsi qu'aux données stockées ou archivées sur un serveur de données par le site central. Le serveur annuaire, quant à lui, va regrouper l'ensemble des utilisateurs du système collaboratif ainsi que leurs droits d'accès et privilèges au niveau des applications et des données enregistrées. Le serveur annuaire est associé à travers un second pare-feu à un serveur de sécurité qui gère l'ensemble des protections liées à chacune des applications et des données en fonction des utilisateurs enregistrés dans l'annuaire. Il est à noter que le serveur d'application est directement lié au serveur de données et que le serveur WEB a accès au serveur d'application à travers un troisième pare-feu.

L'ensemble des trois pare-feu apporte au site central une sécurité maximale permettant d'assurer une intégrité optimale de l'ensemble des applications d'étude et des données d'étude archivées. D'autre part, le site central est apte à télé-distribuer les applications associées à une étude donnée vers les différentes boites noires installées dans les centres d'investigation concernés par l'étude donnée, selon les informations de télédistribution fournies par le Sponsor/Architecte. De la même manière le site central gère la mise à jour éventuelle de ces applications. Ces processus de distribution sont entièrement automatisés et sont déclenchés par l'unité Sponsor/Architecte du système collaboratif selon l'invention.

En outre le site central permet à l'unité Moniteur de monitorer et/ou d'auditer l'ensemble des données d'une étude déterminée, à travers un client web spécifique.

Enfin, le site central permet un export des données archivées d'une étude donnée en vue de réaliser :
1) des traitements statistiques sur les données recueillies dans le but, par exemple dans le cadre d'une étude clinique, de pouvoir déposer un dossier pour obtenir une AMM (autorisation de mise sur le marché) ;
2) des exports de tout ou partie des données centralisées, avec les preuves de signatures pour archivage, audit ou pour constituer et/ou alimenter des bases de données spécifiques (par exemple, dans le cadre d'études cliniques, une base de données de pharmacovigilance regroupant les effets indésirables tout au long de la vie d'un produit, avant autorisation de mise sur le marché et après). Cet export est réalisé soit par l'administrateur du site central, soit par le sponsor de l'étude qui a demandé la réalisation de l'étude concernée, au moyen éventuellement d'une autre entité exploitation de données , mettant en jeux préférentiellement plusieurs procédés permettant d'optimiser l'intégration de l'invention aux systèmes informatiques du sponsor et/ou une migration vers de nouveaux outils.

La dernière unité du système collaboratif selon l'invention est le Moniteur. Cet élément est constitué d'un poste standard tel qu'un ordinateur personnel (PC) ou un ordinateur Apple (iMac par exemple) ou une station de travail fonctionnant sous UNIX, équipé d'un

navigateur WEB de type standard connu en soi (Netscape ou Internet Explorer par exemple). A l'aide de ce navigateur, le Moniteur va pouvoir monitorer et/ou auditer une étude donnée soit sur le site central soit directement sur les boites noires installées dans les centres d'investigation en passant soit par le serveur WEB du site central soit par les moyens formant serveur WEB de la boite noire, tous deux comprenant un client WEB permettant un tel monitoring ou un tel audit.

L'authentification du Moniteur sur le site central est effectuée préférentiellement selon le procédé de la PKI (Public Key Infrastructure ou Infrastructure à clef publique), mettant en jeu ou non l'utilisation d'une boite noire.

Le fait que les données du patient soient stockées localement selon des procédures sécurisées, que les données soient signées par les personnes autorisées, et qu'une opération de synchronisation ait eu lieu entre le site central et les postes Investigateur cautionnent le fait que les informations stockées en central soient une copie intègre et conforme des données stockées en local.

Les données patients sont donc signées (toutes modification est contre-signée et datée), et accessibles et visibles en l'état à tout moment sur site local et sur site central. La preuve de la signature des données (non répudiation et intégrité des données) est de ce fait conservé par la personne engageant sa responsabilité, et et le sponsor de l'étude qui est autorisé à exploiter ces données. C'est en cela, que le système collaboratif selon l'invention est un système collaboratif autorisant la gestion de données sources de façon électronique à 100 %..

L'ensemble des communications et/ou des transferts de données entre les différents éléments formant le système collaboratif selon l'invention s'effectue de manière cryptée et sécurisée. Un moyen préféré pour réaliser ce cryptage et cette sécurisation est l'utilisation du protocole SSL (Secure Sockets Layers, Couches de Sockets Sécurisés). Le fonctionnement d'un tel protocole s'effectue de la manière suivante : a) Le client envoie au serveur son numéro de version SSL, ses prédispositions quant au chiffrement et d'autres informations nécessaires à la communication. b) Le serveur renvoie au client les mêmes informations avec son propre certificat. Si le client formule une requête concernant une ressource nécessitant une authentification du client, le serveur lui envoie un message à crypter et demande le propre certificat client. c) Le client utilise les informations envoyées par le serveur afin de l'authentifier. Si le serveur ne peut pas être authentifié, l'utilisateur est prévenu du problème et informé qu'une connexion authentifiée et chiffrée ne peut pas être établie avec le serveur. d) En utilisant les données générées par le protocole d'accord précité, le client crée le secret temporaire de session, chiffre ce dernier avec la clé publique du serveur qui a été obtenue par le certificat serveur et envoie l'ensemble de ces informations au serveur.

e) Si le serveur a demandé une authentification client, le client signe avec sa clé privée le message envoyé par le serveur, il est à noter que cette clé est seulement connue du client et du serveur. Par conséquent, le client envoie alors au serveur les données signées, son certificat ainsi que le secret temporaire chiffré. f) Le serveur essaie d'authentifier le client.

Lorsque ceci n'est pas possible, la cession se termine. Si le client est authentifié avec succès, le serveur utilise sa clé privée pour déchiffrer le secret temporaire puis génère le secret maître. g) Les deux parties utilisent le secret maître pour générer les clés de session, clés symétriques utilisées pour chiffrer et déchiffrer l'information échangée pendant la session SSL et pour vérifier son intégrité. h) Le client envoie un message au serveur l'informant que les futurs message envoyés seront cryptés avec les clés de session. Il envoie ensuite un message chiffré de séparation indiquant que la partie client de l'accord est terminée. i) Le serveur suit le même processus pour indiquer que la partie serveur de l'accord est terminée. j) L'accord SSL est maintenant complet et la session SSL peut réellement commencer. Le client et le serveur utilisent les clés de session pour chiffrer et déchiffrer les données qu'ils envoient l'un à l'autre et pour valider leur intégrité.

Il est à noter que chaque transaction utilise une clé de session différente. En effet, si une personne parvient à déchiffrer une transaction et qu'elle désire en déchiffrer une autre, cela lui demandera autant de temps et d'effort pour la transaction suivante que pour la première.

Notons que le fait de déchiffrer une transaction ne signifie pas que la clé secrète du serveur a été percée. De manière préférentielle, le protocole SSL utilisé entre les différents éléments du système collaboratif selon l'invention utilise des clés de chiffrement de
128 bits ou plus.

D'autre part, il est à noter que la signature électronique des différents documents échangés essentiellement entre l'entité Investigateur et le site central suit, de manière préférentielle, les recommandations de la directive européenne sur la signature électronique de 1999, de la loi française et du décret d'application pour la signature électronique de 2000 et 2001, du"security and electronic signature standard"aux Etats-Unis, de la CNIL ainsi que de la directive de la Communauté Européenne sur la protection des données.

La signature électronique des formulaires, selon l'invention, comporte préférentiellement deux éléments : - la"signature électronique"proprement dite (le procédé), et -"la preuve" (le certificat)
Le système interactif décrit utilise, de manière préférentielle, une"architecture de sécurité à clé publique" (PKI pour Public Keys Infrastructure selon le

terme anglo-saxon). Cette architecture, connu en soi, comporte les éléments suivants :

* une politique de sécurité clairement définie, * une autorité de certification permettant de délivrer un certificat de la clé publique du signataire.

* une autorité d'enregistrement permettant l'enregistrement du signataire, de la période de validité, de la révocation. Il peut y avoir une délégation de l'autorité d'enregistrement. En d'autres termes, le sponsor de l'étude (par exemple l'Industrie Pharmaceutique, pour les études cliniques) peut avoir la délégation d'enregistrement des signataires, * un système de distribution des certificats, * un annuaire des clés, * des applications compatibles PKI : les moyens techniques de génération des clés cryptographiques et d'implémentation des algorithmes, ainsi que le support de la clé privée du signataire font partie de la PKI.

Les données signées avec leur preuve sont stockées en deux endroits : en local sur le site de chaque entité Investigateur (stockage local) et sur le site central (stockage et archivage). Ceci constitue un élément de fiabilité important de la procédure de signature.

Le dispositif de calcul de la signature et de sa vérification (SSCD (Secure Signature Creation Device

selon le terme anglo-saxon)) effectue ce calcul en conformité avec la législation en vigueur. Ainsi, - -t-, '] t.-4- 1- T - .-. . . -C'- ;-t-.- tt < *r'/r\

working document"de mars 2001 (CEN I/SSS WS/E/SIGN N 137) qui utilise les"Critères Communs"comme référence pour établir la confiance dans l'aspect technique du procédé. Ces Critères Communs sont des normes internationales d'évaluation de la Sécurité des Systèmes d'information. Ils expriment : - des exigences en terme fonctionnel (ex : longueur des clefs à utiliser sur telle ou telle méthode cryptographique) ; les exigences fonctionnelles sont choisies en fonction des objectifs de sécurité pour le produit ou le système concerné, - des exigences d'assurance : elles expriment les conditions à vérifier pour que la sécurité du produit ou du système évalué soit efficace et conforme aux exigences fonctionnelles retenues.

8 niveaux d'assurance sont décrits : de 0 à 7 ; les niveaux 5 à 7 sont peu utilisés à ce jour. Un niveau "EAL 4"est utilisé de préférence pour obtenir une bonne confiance dans un produit ou un système, sans faire appel à des techniques d'implémentation spécifiques pour la sécurité.

Les éléments du SSCD sont préférentiellement :
1) le Composant de calcul de la signature
La preuve devrait porter au minimum sur les éléments suivants : - Données utiles - Identification du signataire - Heure/date - Politique de signature qui exprime la politique organisationnelle et peut être exprimé par un Numéro. Ce Numéro fait référence aux éléments techniques et à la politique d'organisation

- Certificat de la clé publique (associée à la clé secrète/privée du signataire).

Une fois calculée, la preuve est logiquement indissociable de ces éléments.

La preuve est calculée en deux opérations successives : i. un hachage : cette opération produit une Empreinte des éléments sur lesquels porte la preuve, ii. Chiffrement asymétrique (à l'aide de la clé secrète du signataire) de l'empreinte
C'est l'ensemble de ces deux opérations qui produit la preuve.

2) le Composant de vérification de la signature
Ce composant n'appartint pas à proprement parler au SSDC. Cependant, il est nécessaire de le prévoir dans l'architecture afin : de contrôler qu'une preuve obtenue est correcte, en fin d'acte de signature, en vue de détecter au plus tôt une erreur conduisant à un acte impossible à vérifier. de vérifier ultérieurement en cas de besoin l'authenticité d'un acte de signature (Toutefois, pour ce second point, les moyens de vérification peuvent être externes à la plate-forme décrite).

La vérification d'une signature s'effectue en trois opérations :
1. Calcul de l'empreinte des éléments sur lesquels ont porté la preuve, par hachage
2. Déchiffrement de la preuve, par algorithme asymétrique, en utilisant la clé publique du

signataire (celle qui se trouve dans le certificat de clé publique),
3. Comparaison du résultat de ces deux opérations.

Les autres éléments techniques liés à la signature au sein du système collaboratif selon l'invention sont la carte à puce qui doit être compatible préférentiellement avec le niveau de sécurité recommandé (a priori EAL4) et le lecteur de carte qui doit également être compatible préférentiellement avec le niveau de sécurité visé (EAL 4).

D'autre part, l'ensemble du système collaboratif selon l'invention est préférentiellement construit entièrement en XML natif : les données des applications d'études, la structure des bases de données de l'entité Investigateur et du site central, données générées par les applications de l'entité Sponsor/Architecte. Cela a pour avantage : - de ne pas avoir de"mapping" (selon le terme anglo-saxon consacré ou mappage) nécessaire à aucun moment des étapes relatives au processus d'élaboration, d'implémentation, distribution de l'étude, de collecte et de stockage/archivage des données, assurant de ce fait une interopérabilité immédiate, de garder une flexibilité au système collaboratif autorisant des modifications immédiates (sans intervention) sur le moyen de stockage des données.

- d'avoir une flexibilité et une très grande facilité pour être en conformité avec les schémas de données propres au domaine d'application des études (du

CDISC-Clinical Data Interchange Standards Consortiumqui sont en cours d'élaboration et en cours d'évolution, en ce qui concernent les études cliniques. Cette même remarque vaut pour la mise en conformité avec les standards HL7 concernant les données médicales hospitalières.)
Dans le domaine des études cliniques en particulier l'ensemble de la plate-forme collaborative répond aux contraintes réglementaires précitées ainsi qu'aux contraintes réglementaires propres aux études cliniques représentées par le FDA (Food and Drug Administration) 21 CFR part 11, le guide de la FDA d'avril 1999 sur les systèmes informatisés utilisés lors d'études cliniques et, en ce qui concerne la signature électronique et la sécurité, le FDA 45 CFR ainsi que les GCP de ICH (International Committee of Harmonization) (GCP signifiant Good Clinical Practices ou Bonnes Pratiques Cliniques).

Il est à noter que ce système collaboratif peut être utilisé pour des études dans d'autres domaines que celui illustré du monde pharmaceutique et des études cliniques, comme par exemple le domaine des assurances ou bien encore dans des domaines tels que les sites industriels à haut risque de type SEVESO (sans que ces deux exemples soient limitatifs).

Bien entendu, on pourra apporter à l'invention de nombreuses modifications sans pour autant sortir du cadre de celle-ci.

Par exemple, l'identification et l'authentification d'un utilisateur peuvent être effectuées ou complétées

en utilisant des moyens de mesures de paramètres biologiques dudit utilisateur (biométrie) comme les empreintes digitales, rétiniennes, vocales, etc....

Claims

Investigateur des données de l'étude et mémorisation en local de ces données sur des moyens de mémorisation de l'entité Investigateur sans que cette dernière soit connectée au reste du système collaboratif, g) transmission des données de l'étude au site central par Identité Investigateur, stockage de ces données dans une base de données sur des

Sponsor/Architecte, c) modification éventuelle en cours d'étude par l'entité Sponsor/Architecte de l'un ou des éléments de l'étude, d) stockage des éléments de l'étude par le site central comportant des premiers moyens de mémorisation à cet effet, après transmission desdits éléments par l'entité Sponsor/Architecte au site central, e) distribution des éléments appropriés de l'étude par le site central à l'entité Investigateur, f) saisie par des moyens de saisie de l'entité

Sponsor/Architecte, b) décision de lancement de l'étude par l'entité

REVENDICATIONS 1. Procédé de réalisation d'au moins une étude, destiné à être mis en oeuvre par un système collaboratif comportant, en réseau, un site central, au moins une entité Sponsor/Architecte, au moins une entité Investigateur apte à être concernée par l'étude, au moins une entité Moniteur, le procédé comprenant les étapes de : a) élaboration des éléments de l'étude par l'entité

<Desc/Clms Page number 43>

Investigateur par l'entité Sponsor/Architecte, via le site central.

Investigateur sans que cette dernière soit connectée au reste du système collaboratif, et, i) clôture de l'étude au niveau de l'entité

deuxièmes moyens de stockage sur le site central, et synchronisation croisée de ces données entre le site central et l'entité Investigateur, h) monitorage, revue de données et/ou audit de l'étude par l'entité Moniteur soit auprès du site central, soit auprès de l'entité
2. Procédé selon la revendication 1, caractérisé en ce que les moyens de saisie et les moyens de mémorisation des données de l'étude par l'entité

Investigateur sont agencés de sorte à être utilisables sur une grande variété d'environnements matériel et logiciel.
3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les moyens de saisie et les moyens de mémorisation des données de l'étude par l'entité

Investigateur sont agencés de sorte à permettre une utilisation parallèle sans interférence d'autres procédés que celui dédié à l'étude et sans interférence entre les moyens de l'étude et ces autres procédés, ainsi qu'une utilisation de manière indifférente selon un mode mono ou multiposte et une sécurisation aux plans physique et/ou logiciel.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que les données mémorisées par

<Desc/Clms Page number 44>

Investigateur.

l'entité Investigateur ont été collectées par des moyens de saisie autonomes connectable à l'entité
5. Procédé selon l'une des revendications l à 4, caractérisé en ce que les données saisies et mémorisées au niveau de l'entité Investigateur ne sont prises en compte au niveau du site central qu'accompagnées d'un certificat numérique valide authentifiant une signature électronique d'un utilisateur autorisé qualifié de l'entité

Investigateur et une non répudiation par cet utilisateur desdites données.
6. Procédé selon la revendication 5, caractérisé en ce que chacune des données prises en compte au niveau du site central, authentifiée par la signature électronique à laquelle elle est associée, fait l'objet d'une étape de vérification d'intégrité à des fins d'exploitation, d'audit et de stockage.
7. Procédé selon l'une des revendications 5 à 6, caractérisé en ce que le stockage par le site central des données saisies est agencé de sorte à préserver un lien insécable entre lesdites données et le certificat valide authentifiant la signature associée aux dites données.
8. Procédé selon la revendication 7, caractérisé en ce que le certificat valide authentifiant la signature associée aux dites données est stocké de manière consultable par les moyens de mémorisation de l'entité Investigateur.

<Desc/Clms Page number 45>
9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que les transmissions et distribution de données et/ou d'éléments d'étude s'effectuent dans un format XML, et que le stockage sur le site central s'effectue dans un format XML natif dans la base de données, notamment la base de données étant en XML natif.
10. Procédé selon la revendication 1 à 9, caractérisé en ce que des modifications et/ou des additions d'éléments de l'étude en cours d'étude sont effectuées de façon dynamique sans interruption ni restructuration de la base de données.
11. Procédé selon l'une des revendications 9 à 10, caractérisé en ce que les données saisies et mémorisées sont aptes à être enrichies dynamiquement.
12. Procédé selon l'une des revendications 1 à 11, caractérisé en ce que, le système collaboratif comportant une entité exploitation de données, le procédé comprend une étape d'exploitation de tout ou partie des données stockées par le site central par l'entité exploitation de données.
13. Procédé selon l'une des revendications 1 à 12, caractérisé en ce que, lors de la saisie des données par l'entité Investigateur, si une donnée saisie est non transmissible au site central, elle est mémorisée sur des moyens de stockage amovibles de l'entité

Investigateur.

<Desc/Clms Page number 46>
14. Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il est agencé de sorte à s'appliquer à des études et des recherches cliniques et épidémiologiques.