Patent Description:
The marketing of a drug needs several preliminary test phases to reach the approval of the relative therapy. After biocompatibility tests effected in laboratory, a further and very important test phase comprises the successful overcoming of the so called "clinical trials". They are prospective biomedical or behavioral research studies on human subjects; are designed to answer specific questions about biomedical or behavioral interventions; and are aimed at inferring safety and efficacy data. The decision process of national regulatory authorities for releasing new drugs on the market comprise a thorough analysis of clinical trials results conducted by the pharmaceutical companies. Clinical trials comprise standardized steps to carry out. A multitude of data must be acquired for each step. The data collected must be gathered in the clinical trial file to which refer.

Such data are collected in various way and formats according to the experience of the medical practitioner. Besides his regular duties interacting with subjects under test, he has also the burden to properly take note and store relevant information for his task. In known solutions, case report forms (CRF) are used. A CRF is a paper or electronic questionnaire specifically used in clinical trial research. In practice is a form comprising a plurality of fields that the medical practitioner must fill in after observations on a subject under and/or questions to him.

Document <CIT> discloses a method for collecting and handling clinical trials data.

Document <CIT> discloses methods to activate a licensed software on a user device.

Documento <CIT> discloses methods to verify a license key for carrying out a software method by using an NFC tag.

The paper version of a CRF requires an amount of extra work for digitalizing data collected by the medical practitioner.

The electronic version of a CRF requires a computer properly configured. Often subjects under test are spread amongst different medical facilities. Often, a suitable technology equipment is not available in each medical facility. So for some subjects, the paper version of CRF must be used, and for some other the electronic one. Such situation impacts on the efficiency of the clinical trial as well as on the quality of data collected.

Furthermore, a clinical trial collects sensible data relating to health status of an individual. The electronic equipment used for generating a CRF may be not secure enough to ensure an adequate level of privacy.

Therefore, there is a need for a method and a system for collecting and handling clinical trials in a simple, safe and direct way.

According to the present invention, there is a method for collecting and handling clinical trials data, the method comprising the following steps:.

Wherein in the step B of authenticating said user comprises a preliminary phase of registration of a user, made once for each user, comprising the following steps:.

The present invention also relates to a system for collecting and handling clinical trials data comprising:.

The present invention will become more apparent from the following description of exemplary embodiments to be considered in conjunction with accompanying drawings wherein:.

The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.

According to the invention, there is a method for collecting and handling clinical trials data wherein is provided a user with a user equipment and a management server. Typically the user is a medical practitioner, the user equipment is a smartphone properly configured (as described in the following) or a tablet or customized mobile hardware for the purpose, and the management server is a server known as per se, but properly configured according the present invention (as described in the following).

In general, the management server generates a new case report form the first time a user access the management server and start a new study on a subject under test. Whilst the management server retrieves the case report form associated to the user in subsequent accesses to the management server.

The following possibilities are provided:
The user intends to update information already stored of a case report form. For example, he notes a wrongly transcribed parameter previously measured. It is important to differ if the value / eCRF form is already closed/frozen in the management system. If yes a change can only applied over raising an eQuery. The eQuery stores additional information why an information has changed and when and from whom. If the eCRF is not closed/frozen than an update of the clinicical data can be done anytime. He therefore updates the content of the information in the corresponding case report form.

The user is effecting a further survey on a subject and he has to insert the parameter just measured. The corresponding case report form is retrieved and the relative information are populated correspondingly. According to the present invention, a case report form generated and populated for the first time with corresponding information is considered "updated", the difference resides in that the case report form is not retrieved but newly generated.

The user wants to consult information of one or more subjects viewing their case report forms. The corresponding case report form is delivered and the user may navigate through the relative information with his smartphone.

<FIG> shows a block diagram of the of main steps of a method according the present invention. In particular such diagram is a portion of a more extended diagram representing steps of a method according to the present invention. Such method is implemented as an application for a smartphone.

The block <NUM> represents the run of the application: the user executes the application loaded into his smartphone. After executing the application, the application carries out a preliminary check of the device. In particular the device is checked if all the components involved in the functioning of the app are correctly working. As an example, according to the application will use the camera of the smartphone to complete the registration process, thus the good functioning of the camera is necessary: the check in the step <NUM> notifies the user if something does not work properly impairing the completion of the method.

Further checks are internet connectivity, microphone for voice recognition available, management server state.

After step <NUM>, there is the test step <NUM> that checks if a user is already registered at the management server, or such operation has not occurred yet. In case of negative result (the user is not register yet) the line NO is followed to arrive at the block <NUM>, where the registration process occurs. Details of such process are described in detail with reference to <FIG>.

After the registration is effected, or after the test <NUM> is positive (in this case the line YES is followed) the elaboration step <NUM> is reached. Such step <NUM> represents the authentication at the management server. In the authentication step is strictly connected to the registration step: for authenticating a user, credentials established during the registration process are checkedIf the authentication step <NUM> fails, the user will be redirected to the login and will not receive the case report forms associated to him on his smartphone. Other options may be provided as well as a proper exception management logic.

After being authenticated, the step <NUM> is reached: the user starts using the application. This step is reached receiving the case report form updated on his smartphone, the list of the last case report forms viewed, new case report forms associated to the user, ecc. Depending on the type of management server a user specific encryption of the data transfer will be used. At least SSL for the data transmission is used. The User will be asked here if he want to activate the voice recognition. If he disable the App starts without the Voice Recognition service and the user can use the App by touch and type events.

A symmetry check is carried out on the management server to ensure that the user has the updated case report forms on his smartphone when starts using the application.

At his first execution the user receives a plurality of case report forms associated to him. Such case report forms are partially empty: the data to acquire through the clinical trial are not populated yet.

After effecting clinical trials, the user populates data of the respective case report forms, such data are stored on the smartphone. The user may be out of reach of the Internet network for a long time, this, in principle, does not influence the functioning of the application: the user may keep going acquiring data. In this case, when the application is run at the step <NUM> the Internet connection is checked. If not available, the application will run in "offline mode" discarding the step <NUM>. The user may keep updating the information of case report form stored. An indicator may take account of the number of updates each case report form had. When the user starts the application and an Internet connection is available, the content stored on the smartphone is aligned with the content on the management server.

New clinical trials for new subjects may be assigned to a user. Starting the application the user receives the new case report forms associated.

After starting the application the user begin to use the application itself. Thus he may:.

After using the application, the user once has finished his observations close the application, as described in the block <NUM>. In one embodiment, such operation finishes off with the commit at the management server of the updated case report form, the management server may thus properly synchronize the content.

<FIG> shows a block diagrams of operations to register a new user.

As shown in the block <NUM> at the management server a unique license key is generated. Such key may be a pseudo-random code generated according proper rules. The block <NUM> is reached wherein the license key is represented as a bidimensional code (a QR code). The QR code typically stores information in form of an encrypted base64 string that represents UIDs of a new potential user in the management server.

At the management server, the QR code is associated to a user, as shown in the block <NUM>.

After associating the code to a user, the step <NUM> is reached wherein the QR code is physically assigned to a new user.

At the block <NUM>, the user with the QR code establishes a communication with the management server through his user equipment. In this operation, the management server detects a unique code of the smartphone of the user (for example the IMEI code or/and the MAC address).

At the block <NUM> is represented the step wherein the user decodes the license key coded in the QR code and transmits the relative information to the management server. Thus, at block <NUM> the management server receives the license key by the user.

If the operation at the block <NUM> is successful, the management server checks if the license key received corresponds to the license key generated. If this operation is successful, the user is registered.

Instead of QR codes for representing the license key, a NFC device is used. The coded license key at the step <NUM> is stored in a NFC device. This is a NFC Tag and can be delivered in form of a small chip or visit card. For NFC usage the mobile device must have a NFC sensor or be able to extend with an external NFC sensor. At the step <NUM>, the device NFC is assigned at the user. The user then retrieves the license key approximating his smartphone at the NFC device within its operative radius. The remaining operations are the same.

The registration process may comprise the further step of choosing a password by the user. At the end of registration process, the user is asked if he wants to choose a password. In this way a robust security check is carried out.

The information between the user equipment and the management server are exchanged as REST service calls.

<FIG> shows a block diagram of such an implementation.

At block <NUM> a REST data is received. Then the block <NUM> is reached. In this block such data is verified to assess if corresponds to a study model data or a subject data. If it is subject data branch 502a is followed and blocks from <NUM> to <NUM> are executed. In the block <NUM> the REST base subject data is retrieved. Then the block <NUM> is reached where such data is transformed in a local data entry object. Then the block <NUM> is reached where the data is applied to the corresponding model, for example the eCRF model. Then the test block <NUM> is reached where it is assessed if the data is changed. If the data is not changed the branch NO is followed, reaching the block <NUM> where the subject data is destroyed and it is not saved on the local device. Instead, if the data is changed, the branch YES is followed reaching the block <NUM> where the data are sent via REST to the provider. The blocks from <NUM> to <NUM> are executed if at the test block <NUM> it is verified that the REST data is a study model data, following the branch 502b for reaching the block <NUM> wherein the REST base study definition is retrieved. Then the block <NUM> is reached wherein the Study definition is transformed to provider domain, for example third party study model. The block <NUM> is then reached wherein the provider domain is transformed to CDISC ODM compatible domain. Then reaching the block <NUM> the study model is stored in the local database. This is only available if an offline mode is allowed. For online mode usage the model persist only in the memory of the mobile device and the information is lost after closing the application. The block <NUM>, the block <NUM> and the block <NUM> end to the block <NUM>.

The user may input the data when updating a case report form via voice commands. Voice commands are always additions to the standard touch events for navigating or inserting values with a virtual keyboard displays on the mobile device. Means if no VR is possible the standard Touch and Type event will work anyway. The user may give commands to the application, for example to navigate through case report forms, via voice commands as well.

At the management server a consistency check is carried out on the content of said one or more case report stored on the user equipment to synchronize with the content at said management server. In practice, when the management server has to synchronize the information of one or more case report form, check if the value stored are within acceptable ranges. For example, an acceptable range for the blood pressure may vary between <NUM>/<NUM> and <NUM>/<NUM> (systolic and diastolic values). Values outside this range may require a confirmation from the user before they are stored. Namely an on time eQuery.

The user equipment is typically a smartphone, or a tablet or customized mobile hardware for the purpose, the program is a computer program product conceived for mobile devices.

Further disclosed is a management server comprising at least a processing unit, memory means, data communication means and a program loaded in said memory means and adapted to be executed by said processing unit, said program when running configured to carry out the following steps:.

The program stored on and executed by the management server is further configured to carry out the following steps:.

The program stored on and executed by the management server is further configured to carry out a consistency check before synchronizing the content of the one or more updated case report form received with the corresponding one or more case report form associated to said user.

<FIG> shows a block diagram representing the life cycle of
a computer program product implementing the method according the present invention. The first block <NUM> verify whether a study list is loaded on the user equipment. If it is loaded, the branch Y is followed, the study model is checked as shown in the block <NUM>. If it is not loaded, the branch N is followed, the study model is retrieved as shown in the block <NUM>. After the block <NUM>, there is a further check, as shown in the block <NUM>, to verify if the study loaded is the last group of studies actually conducted. If the result of this check is positive, voice commands are generated to retrieve a certain study. If the result of the check is negative, the branch N is followed and the block <NUM> is reached again, the study model is retrieved. The study list is displayed through the user equipment as shown in the block <NUM>. On the basis of the selection made in the block <NUM>, the selected study is displayed through the user equipment, as shown in the block <NUM>. In one embodiment, the examination list of the selected visit is displayed, as shown in the block <NUM>. In one embodiment, the electronic CRF of examination list of the selected visit is displayed, as shown in the block <NUM>. At this point, the user (typically a medical practitioner) may affect the data entry on the basis of his observation, through the user equipment, as shown in the block <NUM>. The data collected are then saved, as shown in the block <NUM>.

<FIG> shows a block diagram representing the architecture of the present invention. In particular, activity is based on app navigation, not on fragments. Application class LaunchApp now maintains and manages the creation and destruction of services, control flow is solely based on decisions by the state-machine found in the PersonalAssistantService, i.e. the module represented in the block <NUM>.

Block <NUM> represents the launch of the application, namely the execution of the method according the present invention. Block <NUM> represents the login activity. Block <NUM> represents the Module Hub activity. Block <NUM> is the GeniusLingoBase Activity, block <NUM> is the Activity. Block <NUM> is the DataXChange Service. Block <NUM> is the Sphinx Service. Block <NUM> is the Personal Assistant Service. Block <NUM> is the Genius Lingo Base. Block <NUM> is the Application.

<FIG> shows a block diagram representing the flows executed in the context of the present invention. Block <NUM> represents the load of the modules pending. Block <NUM> represents the operation of showing the modules loaded. Block <NUM> represents the open study list pending. Block <NUM> represents the operation of showing the study list subsequent. The block <NUM> points back to the block <NUM> to show the modules loaded and point to the block <NUM> to open visit list pending. The block <NUM> represents the operation of showing the visit list selected. The block <NUM> represents the operation of opening of the examination list pending. The block <NUM> represents the operation of showing the examination list. The block <NUM> represents the operation of opening the ecrf pending. The block <NUM> represents the operation of entering text per voice. The block <NUM> may alternatively ends up in the block <NUM> to save data pending. Blocks <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may further end up in block <NUM> representing the logout pending. In turn the block <NUM> is reached, representing the user logged out. This is a standard workflow to iterate through the study model until data entry. The invention allows to adopt other workflow designs. Means the application is more dynamic. Further workflows are drug supply (e.g. new modul) or eQeuery or Annotation workflows within each step of <FIG>.

<FIG> shows a diagram regarding synchronization of a clinical trials data implementing a method according the present invention.

As shown in <FIG>, according to present invention further relates to a system for collecting and handling clinical trials data.

The network NW1 is typically a mobile network to which the user equipment is connected, the network NW2 is typically a fixed network to which the management server is connected.

Claim 1:
Method for collecting and handling clinical trials data wherein is provided a user associated to a user equipment and a management server comprising the following steps:
A - establishing a communication session between said user equipment and management server;
B - at said management server, authenticating said user;
C - at said management server, generating or retrieving one or more case report form associated to said user, said case report form comprising a plurality of information relative to a clinical trial;
D - delivering the one or more case report form generated or retrieved to said user via said user equipment,
E - at said user equipment, updating and/or viewing information of said one or more case report form,
F - at said user equipment, storing said one or more case report updated;
G - at said management server, synchronizing the content of said one or more case report form associated to said user with the content of the ones stored on the user equipment, characterized in that the step B of authenticating said user comprises a preliminary phase of registration of a user, made once for each user, comprising the following steps:
- at said management server, generating a unique license key,
- record said license number in a NFC tag,
- assigning said NFC tag to said user,
- establishing a communication between said user equipment and said management server,
- at said management server, detecting a unique identifier of said user equipment,
- via said user equipment retrieving the license key stored in said NFC tag,
- transmitting said license number to said management server,
- at said management server registering said user.