+

WO2003067501A1 - Procede de realisation d'etudes destine a un systeme collaboratif en reseau - Google Patents

Procede de realisation d'etudes destine a un systeme collaboratif en reseau Download PDF

Info

Publication number
WO2003067501A1
WO2003067501A1 PCT/FR2003/000322 FR0300322W WO03067501A1 WO 2003067501 A1 WO2003067501 A1 WO 2003067501A1 FR 0300322 W FR0300322 W FR 0300322W WO 03067501 A1 WO03067501 A1 WO 03067501A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
data
study
investigator
central site
Prior art date
Application number
PCT/FR2003/000322
Other languages
English (en)
Inventor
Dominique Delmas
Original Assignee
E-Signcollaborative
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by E-Signcollaborative filed Critical E-Signcollaborative
Priority to EP03718822A priority Critical patent/EP1474769A1/fr
Priority to AU2003222868A priority patent/AU2003222868A1/en
Publication of WO2003067501A1 publication Critical patent/WO2003067501A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • 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

Definitions

  • the invention relates to the electronic performance of studies, in particular clinical studies.
  • An object of the invention is to provide a method for carrying out studies amending the disadvantages due to working in "on-line” mode, while ensuring reliability, performance and robustness during operation.
  • a method of carrying out at least one study intended to be implemented by a collaborative system comprising, in a network, a central site, at least one Sponsor / Architect entity, at at least one Investigator entity able to be concerned by the study, at least one Monitor entity, the process comprising the steps of: a) preparation of the elements of the study by the Sponsor / Architect entity, b) decision to launch the study by the Sponsor / Architect entity, c) possible modification during the study by the Sponsor / Architect entity of one or more elements of the study, d) storage of the elements of the study by the central site comprising first storage means for this purpose, after transmission of said elements by the Sponsor / Architect entity to the central site, e) distribution of the appropriate elements of the study by the central site to the Investigator entity, f) seized by means ens of input of the Investigator entity of the study data and local storage of this data on means of memorizing the Investigator entity without the latter being connected to the rest of the collaborative system,
  • the steps performed locally within an entity can take place without said entity being connected to the rest of the collaborative system, and in particular the Investigator entity.
  • the input of study data is faster and more efficient, possible 24 hours a day, because it remains independent of the access conditions and the state of the network connecting it to other entities, and in particular the central site.
  • the method has at least one of the following characteristics: the means of input and the means of memorizing the data of the study by the Investigator entity are arranged so as to be usable in a wide variety of hardware and software environments; the means for inputting and storing the data of the study by the Investigator entity are arranged so as to allow parallel use without interference from other methods than that dedicated to the study, and without interference between the means of the study and these other processes, as well as indifferent use in a single or multi-user mode and rigorous physical and / or software security;
  • the data stored by the Investigator entity has been collected by autonomous input means connectable to the Investigator entity; - the data entered and stored at the level of the Investigator entity are only taken into account at the level of the central site accompanied by a valid digital certificate authenticating an electronic signature of an authorized authorized user of the Investigator entity and not repudiation by this user of said data;
  • each of the data taken into account at the central site, authenticated by the electronic signature with which it is associated, is subject to an integrity verification step for the purposes of operation, audit and storage ;
  • the storage by the central site of the data entered is arranged so as to preserve an unbreakable link between said data and the valid certificate, authenticating the signature associated with said data;
  • the transmissions and distribution of data and / or study elements are carried out in an XML format, and the storage on the central site is carried out in a native XML format in the database, in particular the database being in native XML;
  • the data entered and stored are capable of being enriched dynamically;
  • the collaborative system comprising a data exploitation entity, the method comprises a stage of exploitation of all or part of the data stored by the central site by the data exploitation entity; during data entry by the Investigator entity, if a data entry is not transferable to the central site, it is memorized on removable storage means of the entity
  • the process is arranged so as to be applied to clinical and epidemiological studies and research.
  • Figure 1 is a schematic representation of the interaction between the different elements constituting a collaborative system according to
  • Figure 2 is a schematic view of the constitution of the central site of Figure 1
  • - Figure 3 is a schematic view of the arrangement of a device called "black box" of an Investigator entity of the figure
  • FIG. 4 is a schematic representation of the interaction between the black box and a local network forming the Investigator entity of FIG. 1,
  • Figures 5a, 5b and 6 are an example of the organization of a study implemented on the Investigator entity.
  • This collaborative system includes four basic functional entities:
  • a first entity called Sponsor / Architect allowing the configuration of a study as well as its piloting, from the creation of this study to its closure, -
  • An entity called central site which is a server of suitable applications and databases to store data according to a predefined format, preferably native XML, (XML: extensible Markup Language according to the English term, or Extensible Markup Language),
  • a Monitor entity able to monitor and audit the study remotely from a Monitor station, via a web client installed on the central site or on the Investigator entity,
  • the main role of the Sponsor / Architect entity is to enable the design of a follow-up file intended for a campaign to measure a certain number of parameters which constitutes a study.
  • the Architect, user of the Sponsor / Architect entity (the designer) can generate all the screens (viewable form of the electronic forms) necessary for this measurement campaign, implement all the parameters specific to a study, constitute and update a directory of system users and manage their privileges and thus generate the application allowing the management of these screens and the entry of data in these screens according to access privileges, as well as generating the corresponding database capable of save the input data.
  • the design of the screens is carried out by recovering as many elements as possible already generated during old measurement campaigns or else from study libraries, screens or even libraries of components such as input fields.
  • the resources of the Sponsor / Architect entity also allow the Architect (user of the Sponsor / Architect entity) to test the application thus generated under conditions of use identical to those of the entities Investigators and Monitor entity, described later.
  • the design of a measurement campaign ranging from the design of the study to the configuration of the study through the control tests, is achievable in a few days (on the order of about five days).
  • the entire follow-up file thus produced is stored for possible re-use of all or part when creating subsequent follow-up files.
  • the design of a follow-up dossier for a measurement campaign consists of the following steps:
  • the Sponsor / Architect entity When developing the structure of the file for a measurement campaign, the Sponsor / Architect entity is able to generate forms which will constitute said file by using or incorporating configuration elements, control elements of entry of information in the various data fields, scheduling elements, processing allowing monitoring and reporting, associated specialized applications, as well as information sets intended for the user of forms such as text, still or moving images, sound or even vector or non-vector drawings.
  • a form preferably includes:
  • the Sponsor / Architect entity can make possible modifications, during the campaign, in the structure of the measurement campaign file.
  • Figure 4 shows an example of the structure of an Investigator entity.
  • the Investigator entity includes an Investigator station which is connected on the one hand to the local network of an Investigator entity, also called an investigation center, and on the other hand to the Internet to be able to join or be reached by the other units of the collaborative system of the invention.
  • the local network of the investigation center is here composed of four stations called user stations. However, the number of user stations is not limited in number.
  • the investigation center can consist of a single user station directly connected to the Investigator station.
  • the main functionality of the Investigator position is the collection of data through the application and all of the form screens developed during the creation of the monitoring file for the measurement campaign by the Architect. This data collection takes place when the Investigator workstation is not necessarily connected to one of the other constituent units of the collaborative system, in particular with the central site.
  • the only compulsory connection that is made is a connection, preferably, limited in time with the central site so as to cross synchronize the data recorded and signed on the Investigator station in the database present in the central site. Communications with the central site are encrypted and secure using a set of private keys / public keys, the keys of each Investigator being different.
  • the data entry can be carried out by different operators, the person in charge of the test campaign on the investigation center is the only one to validate and electronically sign the data entered using a signature certificate which is, of preferably, an X.509 type certificate.
  • a signature certificate which is, of preferably, an X.509 type certificate.
  • several campaign managers can be appointed but a data entry form can only be signed by a single manager for a given version of this form.
  • the Investigator workstation is presented as illustrated in Figure 3, in the form of a device called a "black box".
  • This "black box” includes a processor associated with active memory (RAM) as well as a storage memory which can be in the preferential form of a hard disk or of a memory card known as "flash" in itself.
  • this black box has means of connection to the outside so as to be connected to the local network of an investigation center as well as to the other entities forming the collaborative system of the invention preferably through the Internet network intermediary.
  • the box black includes a smart card reader capable of allowing the identification of the user (s) of the black box having a smart card readable by said reader.
  • a smart card is necessary to open the application and allow user authentication by login and password.
  • a second smart card, for signature purposes is necessary in order to allow each of the managers to sign the data on the forms.
  • the smart card used for signing purposes may contain the elements necessary to open the applications contained in the black box and to authenticate users. It should be noted that the smart card allowing the opening of the black box applications can also contain parameters making it possible to configure the black box so as to integrate it within a network, in particular a network. room of the Investigator entity.
  • the identity of patients can be stored on a smart card, thus making it possible to view the names of patients at the level of the local entity, but not to trace this identity to the level from the central site.
  • the black box has a first layer, called the base, formed by an operating system.
  • the operating system is a UNIX type system, more precisely the operating system can be the LINUX or Windows NT operating system.
  • the black box also includes software means for controlling the smart card reader. including functions for reading and writing chip cards capable of being inserted into the chip.
  • the black box also includes means for managing connections to the outside. These external connections can be RJ45 ports capable of connecting the black box with a local network or the Internet, serial ports, USB ports, as well as a modem.
  • the means for managing the connection to the outside are capable of using most of the current communication protocols.
  • the communication protocol preferentially used is TCP / IP (Tranmission Control Protocol / Internet Protocol which means Transmission Control Protocol / Internet Protocol).
  • the black box also includes a software layer forming means for managing secure accesses.
  • These secure access management means make it possible, in particular to check whether a user who comes to connect to the black box is an authorized user. If the latter is an authorized user, the access management means establish the permissions for using the applications registered on the one hand, the access rights for reading and writing on the database recorded locally from a share, as well as the authorizations to sign documents and the management of the security of data transmissions to the central site during the synchronization of data comprising encryption and sealing steps of this data before transmission and storage.
  • the black box also contains security components such as a firewall, antivirus ...
  • the black box also presents server-forming means such as a WEB server capable of allowing access to the applications forming the study to be carried out on the various stations of the local network and, on the other hand, allowing access to the Sponsor entities. / Architect and Monitor of the collaborative system of the invention.
  • server means also include a so-called FTP server (File Transfer Protocol) which allows the transmission of data in the form of files during the synchronization of the data with the central site, and / or during the cable distribution. applications suitable for carrying out a study.
  • FTP server File Transfer Protocol
  • the black box includes the application (s) forming the study (s) in progress or to be carried out by the investigation center as well as the databases gathering all the measurements made during these studies.
  • the black box does not include a screen or keyboard capable of achieving a traditional man / machine interface as we know it for a traditional workstation.
  • the only possibility of communication with the black box is through the connection means to the outside. Therefore, data entry during a measurement campaign carried out on an investigation center is carried out on user stations specific to the investigation center which can be networked locally, network to which is connected the black box. This makes it possible to perfectly control the accesses that are made to the data and applications contained in the black box, and thus to ensure their security.
  • the only human / machine interface presented by the black box consists of an on / off button allowing the powering of said black box, a luminescence diode of green color preferentially indicating that the functioning of the black box, once power up, is correct, and a smart card reader to verify the identity of the user (s).
  • Such a black box structure has the following advantages: - Offline use of the application, that is to say that the black box for recording the data of a test campaign does not need to be connected to the other units constituting the collaborative system of the invention, -
  • the study is set up in a "plug and play" way (plug in and use) without requiring local administration: thus the studies are set up remotely without resorting to the physical presence of any administrator at the investigation center. In the same vein, the study on the investigation center is also carried out without local administration.
  • Another advantage of integrating the black box into the local network of an investigation center is to be able to interface the study applications with the patient database of the center. This synchronizes the common data between the patient database and that of the black box. On the other hand, this saves the Investigator from entering certain data twice: once for the needs of the study, a second time for the patient database. However, no confidential information, such as the names of the patients, is transmitted to the other entities of the collaborative system of the invention.
  • the user workstations connected to the black box can be very heterogeneous: they can be PC type workstations (Personal Computer) operating under operating systems such as Microsoft Windows (registered trademark) or LINUX, UNIX stations, APPLE computers (registered trademarks), or even personal digital assistants (or PDA according to the acronym Personal Digital Assistant).
  • PC type workstations Personal Computer
  • operating systems such as Microsoft Windows (registered trademark) or LINUX
  • UNIX stations such as UNIX stations
  • APPLE computers registered trademarks
  • PDA personal digital assistants
  • the black box can be protected from any untimely physical intrusion not authorized.
  • a third party tries to open the box of the black box, all the information recorded in the storage memory is irretrievably erased.
  • means for physical destruction of the various elements making up the interior of the black box can in particular be a sensor for opening the box associated with means for physically erasing sensitive data from the black box.
  • the latter is produced in the form of one or more micro-electronic cards directly inserted within the user station.
  • the black box is included in a portable computer, of the PC type for example, or in an advanced PDA, of the "mobile tablet" type.
  • the information entered with these autonomous means is transmitted directly to the central site via a network or possibly to another investigative position.
  • the black box is delivered to the pre-installed and pre-configured investigation center.
  • the software layers forming the operating system, the means for managing the smart card reader, the means for managing the connection to the outside, the means for managing secure access as well as the means forming the server are installed in the black box configured to be integrated into the local network of the investigation center.
  • the user connects his workstation to the black box via the serial port or the USB port or the RJ45 port for network access.
  • the user has access to the applications through the server means, and more particularly to the web server means using a standard browser known per se such as "Netscape Communicator” or "Internet Explorer” (which are registered trademarks).
  • the user Before being able to launch the applications, the user must identify himself with the black box. To do this, preferably, he inserts his smart card into the smart card reader, thereby validating his access to the content of the black box using an identification and an access code associated with the smart card he uses. If all the security checks are correct, the user can run the applications associated with a study.
  • Responsible mode differs from operator mode by the possibility of signing a form (in particular CRForm or Case Report Form according to the Anglo-Saxon term, or Case Report Form) in a non-repudiable manner.
  • a form in particular CRForm or Case Report Form according to the Anglo-Saxon term, or Case Report Form
  • the user arrives at a home page in the workspace. Going through this form is essential for any action because it serves to identify and authenticate with the user's black box.
  • the user is invited to indicate his "login” and his password; it validates this screen using a button, for example.
  • this login form contains the choice of interface language.
  • the form is then transmitted securely to the black box.
  • the password is encrypted in an injective key and this key is compared with that stored in a local database of the Investigator station.
  • the user is faced with a menu composed according to his rights.
  • the menu gives him access to the various modules of the application. From this point, as illustrated in Figure 6, the screen consists of two parts.
  • the menu appears as a bar on the top of the screen.
  • the display of the selected module is done in the main part of the screen, which is itself divided into 3 spaces: Under the menu, a part is dedicated to viewing navigation.
  • a functional menu is located on the left and the workspace proper, on the right.
  • a "Synchronization” module allows an authorized user of the Investigator entity to upload signed data to the central site locally and, from the latter to the Investigator entity, the loading and various updates of the applications and updated data on the central site and intended for the black box The user is notified of the task in progress. It should be noted that at the end of the various operations, a page can explain to the user whether it is necessary to restart the black box to take into account the various modifications. All of the exchanges are preferably carried out in a secure manner.
  • a module allows specific and secure management of certain elements or particular data, in conjunction with all of the forms associated with it.
  • some very specific data can be considered as highly confidential data requiring processing according to a particular process. This is particularly the case for the complete identity of patients, who, according to a setting made at the level of the Sponsor / Architect entity, we want to appear on the screens of user stations of the Investigator entity, but which should not be transmitted to the central site, and preferably not be stored in the Investigator entity. Under these conditions, this highly confidential data can be stored on the user's smart card, and the call to this specific process requires the presence of the user's smart card. If the card is not present in the reader, a page is displayed, asking it to insert it then dial your secret code associated with your card.
  • this method makes it possible to add / delete / update highly confidential information, which is stored on the smart card.
  • any other removable storage means can be used, such as a removable hard disk, CompactFlash type memory cards, etc.
  • a patient is defined, in particular by:
  • the screen consists of a list on the left containing the patients already defined.
  • a line contains the UID, the name, the first name.
  • Each patient name UID is a link to this patient's data edit sheet. When the user clicks on it, the data is displayed in a form on the right side of the screen. This screen allows you to view and modify patient data.
  • the patient's UID is calculated based on the data entered by a hash.
  • the UID serves as a key in the local patient database.
  • the nominative patient data are stored on the smart card.
  • Another module is dedicated to the management of operators of the Investigator entity. It is only accessible by the manager. It allows the latter to add / delete or freeze rights / update the list of operators having the right to connect to the black box.
  • An operator is defined in particular by:
  • the screen consists of a list on the left containing the operators already defined.
  • a line contains the name, the first name, the login (which must be unique).
  • Each name is a link to the data edition sheet for this operator.
  • the Investigator clicks on one of these lines the data is displayed in a form on the right side of the screen. This screen allows you to view the data of an operator. This data can only be modified if the operator has never connected.
  • the form For entering the password, the form presents two password type fields (without echo on the screen).
  • the password When viewing operator data, the password is not displayed.
  • the two Password fields are empty. If the manager changes the operator's data without filling in these fields, the password is not changed. This screen can be used by the manager to change the password of an operator who has forgotten it.
  • the form data is transmitted securely.
  • the login must be unique.
  • the browser checks with a script (preferably in java language) that the two password fields have the same content.
  • a "patient selection” module allows you to navigate the patient files. It presents the list of patients with the following information: - a CRForm status (icon)
  • the object of this module is the selection of a patient.
  • the screen is made up of a list of patients.
  • Each patient ID is a hypertext link triggering the selection of this patient.
  • This list is made up of planned visits and forms corresponding to events such as "adverse events", which have already been previously documented. The user can select one of these items.
  • the screen is made up of the list of visits. Each visit name is a hypertext link triggering the selection of this visit. Under the list of adverse events, a button "New adverse event” allows you to add a new "adverse event”.
  • a module presents a list of CRForms for the chosen patient and for the chosen visit. Each CRForm is preceded by its status icon. The user has the possibility of selecting one in order to view its components. The manager has the possibility of signing a CRForm as we will see below.
  • the screen shows a list of CRForms on the left.
  • Each CRForm (preceded by its status icon) is a hypertext link allowing the content of the form to be displayed on the right side of the screen.
  • each CRForm is followed by a "Sign" button allowing him to sign the CRForm in a non-repudiable manner.
  • the CRForm is displayed in its entirety in a form that allows make the ⁇ certifiable.
  • the smart card is required for this operation and requires the entry of a pin code as well as the presentation of the contractual terms linked to the electronic signature.
  • a dialog box allowing entry of the pin code is displayed and the document corresponding to the CRForm is displayed in a new window with a "sign" button at the bottom.
  • a "Component selection” module presents him with a list of components associated with the selected CRForm. For each of these components, a status icon, a component name, a number of questions (also called “queries” in the context of clinical studies), the possible presence of one or more comments, and a status are displayed. verification of source data (if necessary).
  • the user is faced with the various objects of the selected form. He can enter values or modify them. Preferably, this information is recorded progressively in the black box. If the object is the subject of questions, the user can enter a comments module to answer them; the user can also add a comment without prior question. For data with history, the user can view an audit concerning them.
  • the screen is the same as previously described.
  • the user is faced with a form made up of groups of objects (a component is a group of objects).
  • An object is a (or group of) form element (s): text boxes, check boxes, lists (possibly multiple choice), drop - down lists, option buttons.
  • the modification status of an object is associated with a displayed check box, for example to the left of the object name.
  • a displayed check box for example to the left of the object name.
  • the user modifies the data, he signals his modification to the black box by checking this box. It is neither validation nor signature: it is simply a state of modification. If the box of an object is checked and the user modifies the associated data, the box is automatically unchecked.
  • An icon for a component entered, signed with a question sent by the Monitor entity An icon for a component entered, signed, validated and frozen by the monitor entity.
  • the icon takes on the value of the icon: data entered, but not signed. In parallel, any modification, whatever the state of the component is mentioned in the history.
  • the value of the state of the least advanced component is found at the level of the CRForm, at the level of the Visit (or under part), at the level of the patient, and of the Investigator center.
  • the “least advanced” state relates to the action to be taken by the user.
  • modules are also available, such as the management of contractual study documents, the management of patient forms, for example for clinical studies, the sharing of data with another remote Investigator entity, the management of indicator '' studies, calendar management for events to follow (for example, management of patient visits as part of clinical studies), ...
  • the central site within the collaborative system forming the invention, is to centralize all the data resulting from a given study, all the studies already carried out, or in the process of being carried out or to be carried out as well as the or the applications associated with each of these studies and this in all their versions (if several versions exist for the same study).
  • the central site is connected to the external network, preferably the Internet, through a first firewall.
  • the role of firewalls is to protect the workstation (s) and / or networks to which it is connected, from any external intrusion authorized. Behind this first firewall, the central site comprises on the one hand a WEB server and on the other hand a directory server.
  • the WEB server will allow access to the applications of an application server as well as to the data stored or archived on a data server by the central site.
  • the directory server for its part, will group together all of the users of the collaborative system as well as their access rights and privileges in terms of applications and recorded data.
  • the directory server is associated through a second firewall with a security server which manages all of the protections linked to each of the applications and data according to the users registered in the directory.
  • the application server is directly linked to the data server and that the WEB server has access to the application server through a third firewall. All three firewalls provide maximum security to the central site, ensuring optimal integrity of all study applications and archived study data.
  • the central site is capable of tele-distributing the applications associated with a given study to the various black boxes installed in the investigation centers concerned by the given study, according to the cable distribution information provided by the Sponsor / Architect .
  • the central site manages the possible update of these applications.
  • These distribution processes are fully automated and are triggered by the Sponsor / Architect unit of the collaborative system according to the invention.
  • the central site allows the Monitor unit to monitor and / or audit all of the data for a specific study, through a specific web client.
  • the last unit of the collaborative system according to the invention is the Monitor.
  • This element consists of a standard workstation such as a personal computer (PC) or an Apple computer (iMac for example) or a workstation running UNIX, equipped with a WEB browser of standard type known per se (Netscape or Internet Explorer for example).
  • the Monitor will be able to monitor and / or audit a given study either on the central site or directly on the black boxes installed in the investigation centers via either the WEB server of the central site or by the means forming the WEB server of the black box, both comprising a WEB client allowing such monitoring or such an audit.
  • the authentication of the Monitor on the central site is preferably carried out according to the PKI process
  • All communications and / or data transfers between the different elements forming the collaborative system according to the invention is carried out in an encrypted and secure manner.
  • a preferred means of achieving this encryption and this security is the use of the SSL protocol (Secure Sockets Layers).
  • SSL protocol Secure Sockets Layers
  • the operation of such a protocol is carried out as follows: a) The client sends the server its SSL version number, its predispositions for encryption and other information necessary for communication. b) The server returns the same information to the client with its own certificate. If the client makes a request for a resource requiring client authentication, the server sends him a message to encrypt and requests his own client certificate. c) The client uses the information sent by the server to authenticate it.
  • the client uses the data generated by the aforementioned agreement protocol to create the temporary session secret, encrypts the latter with the server's public key which was obtained by the server certificate and sends all of this information to server.
  • the server has requested client authentication, the client signs with the private key the message sent by the server, it should be noted that this key is only known to the client and the server. Consequently, the client then sends the signed data, its certificate and the encrypted temporary secret to the server.
  • the server tries to authenticate the client. When this is not possible, the assignment ends.
  • the server uses its private key to decrypt the temporary secret and then generates the master secret.
  • Both parties use the master secret to generate session keys, symmetric keys used to encrypt and decrypt the information exchanged during the SSL session and to check its integrity.
  • the client sends a message to the server informing it that future sent messages will be encrypted with session keys. It then sends an encrypted separation message indicating that the client part of the agreement has ended.
  • the server follows the same process to indicate that the server part of the agreement has ended, j)
  • the SSL agreement is now complete and the SSL session can actually start.
  • the client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate their integrity. Note that each transaction uses a different session key.
  • the SSL protocol used between the various elements of the collaborative system according to the invention uses encryption keys of 128 bits or more.
  • the electronic signature of the various documents exchanged essentially between the Investigator entity and the central site follows, in a preferential manner, the recommendations of the European directive on the electronic signature of 1999, of French law. and the implementing decree for the electronic signature of 2000 and 2001, the "security and electronic signature standard" in the United States, the CNIL as well as the European Community directive on data protection.
  • the electronic signature of the forms preferably comprises two elements: - the "electronic signature" proper (the process), and - “the proof” (the certificate)
  • the interactive system described preferably uses a "public key security architecture" (PKI for Public Keys Infrastructure according to the Anglo-Saxon term).
  • PKI Public Keys Infrastructure according to the Anglo-Saxon term.
  • This architecture known per se, includes the following elements:
  • a registration authority allowing the registration of the signatory, the period of validity, the revocation.
  • the sponsor of the study for example the Pharmaceutical Industry, for clinical studies
  • PKI compatible applications the technical means for generating cryptographic keys and implementing algorithms, as well as supporting the signer's private key are part of the PKI.
  • the signed data with their proof are stored in two places: locally on the site of each Investigator entity (local storage) and on the central site
  • SSCD Secure Signature Creation Device according to the English term
  • the functional requirements are chosen according to the safety objectives for the product or the system concerned,
  • EAL 4" level is preferably used to obtain good confidence in a product or system, without resorting to specific implementation techniques for security.
  • the elements of the SSCD are preferably: 1) the Component of calculation of the signature
  • the proof should relate at least to the following elements:
  • Time / date - Signature policy which expresses the organizational policy and can be expressed by a Number. This Number refers to technical elements and organizational policy - Certificate of the public key (associated with the secret / private key of the signatory).
  • the proof is logically inseparable from these elements.
  • the proof is calculated in two successive operations: i. a hash: this operation produces an "Imprint" of the elements to which the proof relates, ii. Asymmetric encryption (using the signatory's secret key) of the fingerprint It is the combination of these two operations that produces the proof.
  • This component does not, strictly speaking, belong to the SSDC. However, it is necessary to provide for it in the architecture in order to: check that a proof obtained is correct, at the end of the signing act, with a view to detecting as soon as possible an error leading to an act that is impossible to verify. to verify later, if necessary, the authenticity of a signing act (However, for this second point, the means of verification may be external to the platform described).
  • the verification of a signature is carried out in three operations:
  • the other technical elements linked to the signature within the collaborative system according to the invention are the smart card which must preferably be compatible with the recommended level of security (a priori EAL4) and the card reader which must also be preferably compatible with the targeted level of security (EAL 4).
  • the entire collaborative system according to the invention is preferably built entirely in native XML: the data of the study applications, the structure of the databases of the Investigator entity and of the central site, data generated by the applications of the Sponsor / Architect entity.
  • mapping (according to the term Anglo-Saxon devoted or mapping) necessary at any time of the stages relating to the process of preparation, implementation, distribution of the study, collection and storage / archiving data, thereby ensuring immediate interoperability, to keep flexibility in the collaborative system allowing immediate modifications (without intervention) on the data storage medium.
  • this collaborative system can be used for studies in other fields than that illustrated in the pharmaceutical world and clinical studies, such as for example the insurance field or even in fields such as high industrial sites. SEVESO type risk (without these two examples being limiting).
  • the identification and authentication of a user can be carried out or completed using means for measuring biological parameters of said user (biometrics) such as fingerprints, retinas, voices, etc.
  • biometrics such as fingerprints, retinas, voices, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Primary Health Care (AREA)
  • Operations Research (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Public Health (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

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

Procédé de réalisation d'études destiné à un système collaboratif en réseau
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 œuvre 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 l'entité 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 trans issible 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
1 ' 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 figures 5a, 5b et 6 sont un exemple d'organisation d'une étude mise en œuvre 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 :
1) 1 ' é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 1' 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 1 ' 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.
11 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 1 ' 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 βb.
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 à 1' é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 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 repudiable 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 > nom de la visite > 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 1 ' 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 messages 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 Création Device selon le terme anglo-saxon) ) effectue ce calcul en conformité avec la législation en vigueur. Ainsi, actuellement, la Loi européenne fait référence au "SSCD 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' appartient 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 1 ' 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 Consortium- qui 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) .
II 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 1 ' 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

REVENDICATIONS
1. Procédé de réalisation d'au moins une étude, destiné à être mis en œuvre 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 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é 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 l'entité 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 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é
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.
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 l'entité Investigateur ont été collectées par des moyens de saisie autonomes connectable à l'entité Investigateur .
5. Procédé selon l'une des revendications 1 à 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.
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 .
4. 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 .
PCT/FR2003/000322 2002-02-06 2003-02-03 Procede de realisation d'etudes destine a un systeme collaboratif en reseau WO2003067501A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP03718822A EP1474769A1 (fr) 2002-02-06 2003-02-03 Procede de realisation d etudes destine a un systeme collaboratif en reseau
AU2003222868A AU2003222868A1 (en) 2002-02-06 2003-02-03 Method for conducting studies for a networked collaborative system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0201397A FR2835635B1 (fr) 2002-02-06 2002-02-06 Procede de realisation d'etudes destine a un systeme collaboratif en reseau
FR02/01397 2002-02-06

Publications (1)

Publication Number Publication Date
WO2003067501A1 true WO2003067501A1 (fr) 2003-08-14

Family

ID=27619929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2003/000322 WO2003067501A1 (fr) 2002-02-06 2003-02-03 Procede de realisation d'etudes destine a un systeme collaboratif en reseau

Country Status (4)

Country Link
EP (1) EP1474769A1 (fr)
AU (1) AU2003222868A1 (fr)
FR (1) FR2835635B1 (fr)
WO (1) WO2003067501A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998039720A1 (fr) * 1997-03-03 1998-09-11 University Of Florida Procede et systeme de prescription et de distribution interactives de medicaments dans des etudes medicales
WO1998049647A1 (fr) * 1997-04-30 1998-11-05 Medical Science Systems Inc. Systeme integre d'information sur les maladies
EP0936566A2 (fr) * 1998-02-11 1999-08-18 Siemens Aktiengesellschaft Système de mise en oeuvre d'études medicales
WO1999063473A2 (fr) * 1998-06-05 1999-12-09 Phase Forward Inc. Systeme et procede de gestion de donnees d'essais cliniques
WO2001093178A2 (fr) * 2000-05-31 2001-12-06 Fasttrack Systems, Inc. Systeme et procede de gestion d'essais cliniques

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998039720A1 (fr) * 1997-03-03 1998-09-11 University Of Florida Procede et systeme de prescription et de distribution interactives de medicaments dans des etudes medicales
WO1998049647A1 (fr) * 1997-04-30 1998-11-05 Medical Science Systems Inc. Systeme integre d'information sur les maladies
EP0936566A2 (fr) * 1998-02-11 1999-08-18 Siemens Aktiengesellschaft Système de mise en oeuvre d'études medicales
WO1999063473A2 (fr) * 1998-06-05 1999-12-09 Phase Forward Inc. Systeme et procede de gestion de donnees d'essais cliniques
WO2001093178A2 (fr) * 2000-05-31 2001-12-06 Fasttrack Systems, Inc. Systeme et procede de gestion d'essais cliniques

Also Published As

Publication number Publication date
EP1474769A1 (fr) 2004-11-10
FR2835635A1 (fr) 2003-08-08
FR2835635B1 (fr) 2008-04-18
AU2003222868A1 (en) 2003-09-02

Similar Documents

Publication Publication Date Title
US7328276B2 (en) Computer oriented record administration system
US10467468B2 (en) System and method for identity proofing and knowledge based authentication
US10009332B2 (en) Method and apparatus for remote identity proofing service issuing trusted identities
EP2932431B1 (fr) Procede d'acces securise a des donnees medicales confidentielles, et support de stockage pour ledit procede
CN107111710B (zh) 用于基于安全和可靠标识的计算的方法和布置装置
CN108055352A (zh) 用于密钥链同步的系统和方法
EP1834268A2 (fr) Serveur, procede et reseau d'intermediation pour la consultation et le referencement d'informations medicales
ITRM20090267A1 (it) Metodo di controllo per la gestione e la diffusione controllata di informazioni riservate digitali contenute in supporti elettronici portatili.
US12093974B2 (en) Review engine with blockchain-based verification
CA2736360A1 (fr) Procede d'acces a des donnees nominatives, tel qu'un dossier medical personnalise, a partir d'un agent local de generation
JP2001325372A (ja) ヘルスケアデータ共有システム，ヘルスケアデータ共有方法およびヘルスケアデータ共有プログラム
WO2013034310A2 (fr) Procede d'acces et de partage d'un dossier medical
WO2015155479A1 (fr) Procedes, plateforme et systeme de collecte et de gestion de donnees vitales de patients pour etablissements de sante
EP3812945A1 (fr) Système ouvert et sécurisé de traitement de demande de signature électronique et procédé associe
US11545007B2 (en) Method, system, and device for selecting a winner of a raffle based on content from raffle tickets
KR101148678B1 (ko) 홈페이지와 문서 전달용 엠프린터를 이용한 전자 처방전 전달 방법 및 그 시스템
EP1474769A1 (fr) Procede de realisation d etudes destine a un systeme collaboratif en reseau
EP1843288A1 (fr) Sécurisation de transactions électroniques sur un réseau ouvert
WO2005111906A2 (fr) Systeme de generation automatique d'un message d'informations medicales
EP4079018A1 (fr) Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical
Das et al. Unleashing the Potentials of Blockchain Technology for Healthcare Industries
FR2995431A1 (fr) Procede d'acces et de partage d'un dossier medical
WO2018091806A1 (fr) Procédé et système pour le recueil du consentement éclairé d'un patient
EP3190530A1 (fr) Carte médicale duale de gestion administrative et de dossier médical et procédés associés
WO2022184726A1 (fr) Procédé pour permettre à des utilisateurs de déployer des contrats intelligents dans une chaîne de blocs au moyen d'une plateforme de déploiement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2003718822

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2003718822

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载