WO2014092637A1

WO2014092637A1 - Clinical study design kit

Info

Publication number: WO2014092637A1
Application number: PCT/SE2013/051494
Authority: WO
Inventors: Ulf BERGKVIST; Suru DISSANAIKE
Original assignee: Transferbio Technology Ab
Priority date: 2012-12-14
Filing date: 2013-12-12
Publication date: 2014-06-19

Abstract

A clinical study design kit (10) comprises a processor (12), an input device (14), a memory (16) and software code (18). The software code is configured for enabling entering of input data (100) by the input device (14) into the processor (12). The input data comprises a clinical study notation (102), a communication address (104) for clinical study reply data, question definitions (106) and user definitions (108). The software code is further configured for supporting creation of a question identification for each question and an answer identification for each answer choice. The software code is further configured for partitioning the input data into an association data entity (30), a tag reader configuring data entity (40) and a questionnaire data entity (20). The questionnaire data entity is configured for creating a questionnaire (22) when being printed.

Description

W

1

CLINICAL STUDY DESIGN KIT

TECHNICAL FIELD

The present invention relates in general to devices and methods for clinical studies, medical studies or clinical trials, and in particular to a design kit and system for clinical trials, clinical studies or medical studies.

BACKGROUND

Before marketing approval for a new drug, a biologies device, a diagnostics device or a medical device can be obtained from the authorities, safety and efficacy data to support the claims for a new product is needed.

A product which has received a CE mark for devices or an "R"-symbol for drugs is a product with a marketing authority approval. A non-approved product which is under development is typically called investigational drug, product, medical device or diagnostics.

Clinical trials (investigations on human subjects/ patients) are typically performed in connection with investigational drugs, products, medical devices or diagnostics with the object of ascertaining its efficacy and safety.

Good Clinical Practice (GCP) is a standard for the design of a clinical trial providing assurance that the data and reported results are credible and accurate, and that the rights, integrity, and confidentiality of trial subjects/ patients are protected.

The terms clinical trial and clinical study are in the present disclosure used synonymously.

A Patient-Reported Outcome (PRO) is a questionnaire used in a clinical trial or a clinical setting, where the responses are collected directly from the patient. PRO is an umbrella term that covers a whole range of potential types of data but is used specifically to refer to self-reported data by the patient. PRO data may be collected via questionnaires completed by the patients themselves or via interviews. The latter will only qualify as a PRO where the interviewer is gaining the patient's views and not where the interviewer uses patient responses to make a professional assessment or judgment of the impact of the patient's condition. Thus, PROs are a means of gathering patient rather than clinical or other views on outcomes. An undisputable advantage of a paper based PRO is that it is very natural and intuitive. Everyone knows immediately how to fill in a form. Further, it will not cause stress and scare people off by any annoying and frightening technical gadgets. It is also a relatively cheap method as no equipment is needed at the patient's home. By the same token the paper based PRO suffers from some obvious disadvantages. There is no way to time stamp the data or follow up the daily progress. Quite often the patient will not fill in the answers on time. This jeopardizes the validity of the data. The problem is not identified until the patient visits the clinic and then it is too late to correct. Hence it is very difficult to obtain high compliance in a trial with paper based diaries. The method also allows ambiguous data e.g. the patient puts the mark in between two choices or scribbles on the paper. Finally, the direct cost benefit of using paper for patient assessment is partially counteracted by the cost of feeding in the result into a database manually or semi- manually.

An electronic Patient-Reported Outcome (ePRO) is a patient-reported outcome that is collected by electronic methods. ePRO methods are most commonly used in clinical trials, but they are also used elsewhere in health care. The known prior art solutions are currently using a number of methods for PRO.

The US patent 4,954,699 discloses a self-administrated survey questionnaire and method. A questionnaire has a plurality of survey questions and a plurality of selectable responses to the questions, associated with selectable bar codes. By reading the bar codes by means of a hand-held bar code reader, the answers can be stored in a memory of a computer connected to or integrated in the hand-held bar code reader.

The US patent 5,361,755 discloses a method and apparatus for medical monitoring, e.g. fetal monitoring. A manual contains clear text instructions as well as predefined codes in their correct sequential form. The instructions help an unskilled user to operate the monitor. A questionnaire may also be provided to enter answers to anamnesis data by e.g. scanning bar codes. These answers, together with vital signs data may be transmitted via telephone lines to a hospital.

The US patent 7, 162,527 B2 discloses an information communicating system using a bar code reader connected to an information transmitting apparatus. Input sheets are provided by facsimile transmission and the recorded bar codes are reported via an Internet connection. A password input sheet is provided by the facsimile transmission to authorize the access via Internet.

One of the oldest adapted non paper PRO was the Interactive Voice Response (IVR), which is a phone technology that allows a computer to detect touch tones using a normal phone call. The IVR system asks pre-recorded questions to which the patient can respond using the dial keys on the phone. IVR is a cheap and straight- forward technology for retrieving PRO data. The method is suitable for study protocols with just a few answers, but the longer the questionnaire the more difficult it will be for the patient to keep the concentration.

Smartphones, Personal Digital Assistants (PDAs), hand computers, tablet computers etc. have gained significant acceptance in the PRO systems in the last decade. The technology prevents the patients from cheating as the smartphone can register at which time a questionnaire has been answered. Smartphone technology provides very powerful technology, but the technology itself may also be a severe drawback. Some patients tend to be scared off by a smartphone as it is perceived too technical and often the screen causes readability problems. Another common problem is that the battery is discharged or the charging procedure is too complicated, at least for elderly people. Further, it is quite common with hardware problems like broken screen, battery contact failure, lost pointing pens etc.

Today web based PRO is widely accepted and is an economical way to retrieve PRO data. However, this technology also has some considerable disadvantages of which access is probably the biggest problem. To answer a questionnaire the patient must have access to a computer, which of course is a problem when being outside the home or the office. Even at home it may be difficult to get access. It is also a fact that not everyone has a PC today especially amongst elderly people. The rapid development of web technology also results in new version of web browsers and a very diverse use of web browser. It is well known that web applications behave similar in different browsers but rarely the same without custom adoption for a specific browser. Continued validation of a Web based PRO application and the additional support of a user's complete IT-environment adds significant additional costs for the web based PRO technology. Another problem is the time to get started. It may take quite some time before the patient can start to enter data. The patient has to turn on computer, logon, close other applications, start browser etc. Finally, using web technique as mentioned above will inevitably lead to a lot of unrelated support matters that has nothing to do with the application itself, like malfunctioning PCs, virus problems, operating system updates, outdated browsers, internet connection problems, WiFi issue etc.

The known prior art solutions have still some drawbacks. e-PRO systems are in general not very intuitive and natural. For example the user interface for patients and clinical staff must be more user-friendly to make them intrigued to use the e-PRO rather than scaring them off. Only limited training should be required, if any at all. To make the e-PRO user interfaces user-friendly requires typically a close collaboration between the sponsor of the clinical trial, the clinical staff and the software engineers. Furthermore, patients should not be able to enter ambiguous data, which also requires further considerations for both the clinical staff and the data management personnel. Besides communication difficulties between persons skilled in different arts, the process becomes typically time-consuming, expensive and increases the workload for the clinical staff. In general, workload for clinical staff and data management personnel should be kept to a minimum to decrease costs and to increase the willingness to participate in clinical trials.

In the published International Patent Application WO 2010/071802 A2, a system for performing clinical trials is disclosed. A system for monitoring a clinical trial and remotely evaluating the accuracy of data generated during the clinical trial is described.

It should be easy to change the study protocol during a trial with maintained traceability. If the questionnaire during the trial is found to be inappropriate, changes should be allowed to be entered during the trial. Again, this requires increased workload on all involved parties.

The system must e.g. conform to applicable regulatory standards such as Code of Federal Regulations (CFR) Title 21 part 11 , GCP and privacy policies in different countries, which in most cases is unknown for e.g. the software engineers.

SUMMARY

An object of the present invention is to provide devices enabling a clinical study approach that is flexible and safe and that reduces the workload for staff, data management personnel and still is user-friendly for a study manager and for a user. The above objects are achieved by devices and systems according to the enclosed patent claims. In general words, in a first aspect, a clinical study design kit comprises a processor, an input device connected to the processor and configured for enabling input of data to the processor, a memory connected to the processor and software code, stored in the memory. The software code is configured for, when being loaded into the processor, enabling entering of input data by the input device into the processor. The input data comprises at least a clinical study identification, a communication address for clinical study reply data, question definitions and user definitions. Each of the question definitions comprises text of the respective question, a question type indicator, and symbols of answer choices. The user definitions comprise information related to participating patients. The software code is further configured for, when being loaded into the processor, supporting creation of a question identification for each of the questions and an answer identification for each of the answer choices. The software code is further configured for, when being loaded into the processor, partitioning the input data into an association data entity, a tag reader configuring data entity and a questionnaire data entity. The association data entity comprises representations of the clinical study identification and the user definitions. The tag reader configuring data entity comprises a representation of the communication address for clinical study reply data. The association data entity and the tag reader configuring data entity are independent of the question definitions. The questionnaire data entity is configured for creating a questionnaire when being printed. The questionnaire presents the text of the questions, the symbol of the answer choices and an answer tag associated with a respective one of the answer choices. The answer tag represents at least the answer identification and the question identification of the respective question. The answer tag is interpretable by the tag reader.

In a second aspect, a system for a clinical study comprises the design kit according to the first aspect, a data collection node and at least one tag reader. The data collection node is accessible by the communication address for clinical study reply data. The data collection node comprises a clinical study data base. Each of the tag readers comprises an optical geometric pattern detector, a tag reader processor, a tag reader memory, a transmitter for communication and a tag reader software stored in the tag reader memory. The tag reader processor is connected to the optical geometric pattern detector. The tag reader memory is connected to the tag reader processor. The tag reader memory comprises configuration data. The transmitter for communication is connected to the tag reader processor. The tag reader software code is configured for, when being loaded into the tag reader processor, causing the optical geometric pattern detector to read the answer tag and the initialization study mode tag. Thereby, answer identifications and question identifications of read one of the answer tags are stored in the tag reader memory.

One advantage of the present invention is that the user of the solution is able to, for defining and conducting a clinical trial, create a questionnaire with the help of the clinical study design kit as well as programming the patient device without any third-party involvement. The invention relates to a data collection tool for clinical trials/ studies which adheres to GCP. Other advantages are further discussed in connection with the embodiments described below.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:

Fig. 1 is an overview of an embodiment of a system for a clinical study;

Fig. 2 is a schematic illustration of functionalities of an embodiment of a clinical study design kit;

Figs. 3A-C are examples of forms for entering input data into an embodiment of a clinical study design kit;

Figs. 4A-B are illustrations of embodiments of a wireless tag reader; Figs. 5A-D are examples of printed sheets used for wireless tag reader configuring and as questionnaire sheets for an embodiment of a system for a clinical study; and

Fig. 6 is a schematic illustration of an embodiment of a data collection node.

DETAILED DESCRIPTION

Throughout the drawings, the same reference numbers are used for similar or corresponding elements.

A user that participates in a clinical study has a certain relation to a medical clinic in some respect, and may therefore also be denoted as a "patient". In the present disclosure, the words "user" and "patients" are therefore basically used as synonyms for denoting the parties that are intended to respond to the questionnaire.

In order to keep the clinical study user-friendly, the approach was selected to be based on printed questions in a document. As discussed in the background section, an undisputable advantage of a paper based PRO is that it is very natural and intuitive. The patient immediately realizes where to find the appropriate information. The printed questionnaire does not cause any technically induced stress, such as may be present in different electronic systems. The questions are present in the document and will not disappear if any technical means is operated in any inappropriate manner.

The only deviation from the traditional questionnaire is that a tag reader is used for inputting the answers. However, tag readers are quite common today in many situations, from grocery stores to public communication systems. Furthermore, if the handling of the tag reader itself is reduced to only one type of operation, e.g. pressing a button or positioning the tag reader in a proper position, the handling is easy to instruct if not already obvious. However, such an ease in operation also requires that the data to be read is constituted in a way that does not further request any particular skills from the patient. This will be discussed more in detail further below.

A further request for the present development is that the workload for clinical staff and data management personnel should be kept to a minimum. The requirement together with the wish to have a flexible system is fulfilled by transferring the main responsibility for the actual production of the questionnaire document and the configuration of any tag reader closer to the study manager himself/ herself. This minimizes the need for consulting different people in the chain of developing or modifying of a clinical study.

One key point in the entire approach is the division of information between different parties and devices. The patient only has to be aware of the questions and the answer alternatives. This information is provided by the printed questionnaire. On the printed questionnaire, information representing answer alternatives and a clinical study identification are also provided, however, in a coded form as a tag. The patient is therefore unaware of that data. However, by using the tag reader, such information can anyway be extracted from the questionnaire.

The tag reader has therefore access to the answer alternatives and the clinical study identification. On the other hand, the tag reader is unaware of the meaning of the questions and the answers, since they only are provided as text and not in a form readable for the tag reader. The selected answer alternatives are thereby made a o^mous for any external party.

In order to secure the connection between the patient and the tag reader, the tag reader has preferably to be possible to identify and to associate with a particular patient. However, such an association is preferably only present for a party that needs to authorize the collected data, and is therefore not available for the patient or for the tag reader unit itself. However, in order to facilitate collection of data, the tag reader should have the ability to provide the collected data to the clinical study data base via a communication system, preferably a wireless communication system. For this purpose, the tag reader must have access to a communication address to which it should transmit the clinical study reply data. The so transmitted data does preferably comprise at least a clinical study identification, an identification of the tag reader unit and coded information representing answer alternatives. In other words, even if such data is eavesdropped, no information about the identity of the patient, the meaning of the questions and answers or the actual study title is available.

When the data transmitted from the tag reader is received by the collecting server, the authenticity is checked by comparing the identification of the tag reader unit with an association of the tag reader unit identity and a user identification number used in the identified study.

From this overview, it becomes apparent that partitioning of information and spreading of selected information portions to different parts of the system is of importance. This should be performed or at least managed by the study manager in order to maintain the flexibility. The request to have the clinical study setup user-friendly also for the study manager can be fulfilled by configuring a clinical study design kit to, in a structured manner, allow study data input, partitioning of the entered data into different data entities and facilitating a distribution of the data entities to different parties of the study. Such a partitioning of the data enables control over the collected data flow and ensures a maintained security against unauthorized access to the data. This is accomplished by separating the actual content, the safety and anonymity arrangements. By such a clinical study design kit, the creation and the realization of clinical studies are facilitated by all kinds of health care-givers, researchers, pharmaceutical organizations, medical device manufactures, non-profit organizations, academia etc., regardless of particular technical skills. W

1 1

In order to understand the different features and advantages of the present invention, a model of an embodiment of a system 1 for a clinical study is first described.

Fig. 1 illustrates study development using a Clinical Study Design Kit (CSDK) 10. The CSDK 10 comprises a processor 12, an input device 14 connected to the processor 12, a memory 16 connected to the processor 12 and software code 18, stored in the memory 16. The input device 14 is configured for enabling input of data to the processor 12. In one typical embodiment, the input device 14 is a keyboard 1 1. However, in alternative embodiments, other types of input devices 14 can be used, such as touch screens, scanners, mouse units etc. alone or in combination. Even the tag reader described further below may be used as part of the input device 14. The input device 14 can in particular embodiments also be a connection to an external data source, e.g. a portable memory unit.

When the software code 18 is loaded into the processor 12, the CSDK becomes a software tool by which the user defines the properties of the study, including but not limited to questionnaire, study protocol and subject information. This will be discussed more in detail further below.

In the present embodiment, the output of the CSDK 10 comprises a number of data entities. A questionnaire data entity 20, in this embodiment printed out from the CSDK 10 in the form of a printed study document or questionnaire 22 is provided with parts of the significant information stored as tags 24. In the present embodiment, the study document is printed on paper. However, in alternative embodiments, the questionnaire data entity 20 can be stored in an electronic format and be provided e.g. as data file, possibly stored in a portable memory or transferred electronically in any other way. The questionnaire data entity 20 is configured for creating a questionnaire when being printed. A tag 24 is a coded representation, in the form of an optical geometric pattern, of information used in a study including but not limited to questionnaire, study protocol and subject information, login information, server configuration, communication parameters. In the present embodiment, the tag 24 is a bar code 25. In one alternative embodiment, the tag 24 can be a matrix barcode e.g. a Quick Response Code. In further alternative embodiments, other types of optical geometric patterns are used, which are detectable by a sensor. The CSDK 10 also creates an association data entity 30, a tag reader configuring data entity 40. This will be further discussed below. The CSDK 10 preferably also stores project files 19 for keeping all study information and export files, called Study Definition Data 50, with appropriate excerpts from the project files 19 for use in external systems.

The system 1 for a clinical study comprises at least one tag reader 6. In preferred embodiments, the tag reader is a Wireless Tag Reader (WTR) 60. However, in alternative embodiments, also wired tag readers are possible to use. The WTR 60 is a mobile tag reader which has the ability to read tags. It can be used by several different user roles including but not limited to patient, investigator, clinic staff, monitor, auditor and sponsor. The typical use of the WTR 60 is as the reply collection unit of the patient. The WTR 60 behaviour will, as will be described further below, at least partially be determined by the tag it reads.

Before being used, the WTR 60 is configured to be used in a particular clinical study. This is performed by means of the tag reader configuring data entity 40. In the present embodiment, the tag reader configuring data entity 40 is provided as information and tags printed on a paper, creating a tag reader configuring sheet 42. By reading the tags by the WTR 60, necessary information for the particular study is obtained in the WTR 60. The WTR 60 is then ready to be used by a patient. The WTR 60 and typically also the questionnaire 20 is handed over to the patient, to be operated wherever there are communication possibilities appropriate for the tag reader. The answering operation is then typically performed in the patient's home. In alternative embodiments, the questionnaire 20 could be provided to the patient by other means, e.g. e-mailed as a text file to be printed out by the patient himself.

During the clinical study, the WTR 60 is used to record answers of the questionnaire. The patient or study subject uses the WTR 60 to read appropriate tags from the questionnaire 22. The WTR 60 of the present embodiment further comprises wireless communication equipment and a data communication channel is used to transmit the data to a Data Collection Node 70 (DCN). The WTR (60) has a built in communication capability using wireless communication technology. In other embodiments, where the tag reader is not wireless, the tag reader subsequently uses wired communication technology. Each WTR 60 has a unique identity number making it possible to distinguish between data transmitted from different WTRs 60. The data collection node is accessible by a communication address for clinical study reply data, as will be discussed further below.

DCN 70 is a server that collects information from the different WTRs 60. The DCN 70 uses the association data entity 30 to determine that the data is sent from a WTR 60 participating in the study. This is described more in detail below. The DCN 70 is in the present embodiment illustrated as a separate unit. The association data entity 30 therefore has to be communicated from the CSDK 10 to the DCN 70 in a safe way before the start of the study. In an alternative embodiment, the CSDK 10 and the DCN 70 are parts of the same units or at least of the same network, and the association data entity 30 is then made available internally. The received information is transmitted in a secure way and is then stored in a secure DCN database 72, i.e. a clinical study data base. The DCN 70 thus comprises specific information about the clinical study in the DCN database 72. Such information can be retrieved by authorized parties e.g. by a web browser 80 or similar equipment. The DCN 70 can also be further connected to auxiliary databases 90, e.g. comprising clinical data or monitoring data, which can be used for further evaluating the result of the study.

Fig. 2 illustrates schematically an embodiment of a clinical study design kit 10. The software code 18 is stored in the memory 16. When the software code is loaded into the processor 12, it is configured for enabling entering of input data 100 by the input device 14 into the processor 12. The input data 100 comprises at least a clinical study notation 102, a communication address 104 for clinical study reply data, question definitions 106 and user definitions 108. Typically, the input data 100 is provided by the clinical study manager, e.g. by typing on a keyboard.

The clinical study notation 102 is in this embodiment a name of the clinical study, easily interpretable by the clinical study manager. A study number generator 17 is configured for associating a clinical study identification 103 with the clinical study notation 102. The clinical study identification 103 thereby represents the clinical study notation 102 and is easily connected to the clinical study notation 102 if the association is available. However, for external parties, the clinical study identification 103 introduces an anonymization of the study. In alternative embodiments, also the clinical study identification 103 could be selected and entered by the clinical study manager, and only the association is made in the study number generator 17. The question definitions 106 comprise the information about the actual questions and answers in the questionnaire. The question definitions 106 can be divided into text of each question, a question type indicator, and symbols of answer choices. The question type could e.g. specify if the question allows multiple answers or not, or if the question is to be answered by a numeric answer or by a choice answer. The symbols of answer choices are typically alphanumeric signs, i.e. strings of numbers and/ or letters. However, also other types of symbols could be used, e.g. a happy face and a sad face. The question definitions 106 are preferably input in a form that is easily readable and understandable by a human, e.g. the study manager. In a typical embodiment, input data forms presented on a computer screen can be filled in by the study manager.

A question configuration generator 13 is adapted to utilize the input question definitions 106 for producing the main part of the questionnaire data entity 20. The question configuration generator 13 is typically part of the software code, and when being loaded into the processor, it supports creation of a question identification for each question and an answer identification for each answer choice, as described here below. An identification Q-ID of the question is produced by the generator 13. This identification is typically a number or an alphanumeric string and is unique for each question in the clinical study. Similarly, an identification A-ID of the answer choices is produced by the generator 13. This identification is typically a number or an alphanumeric string and is unique for each answer of a specific question. The identifications the question and the answer choices are provided to a tag generator 15, together with a representation of the question type indicator. The tag generator 15 converts the identification of each answer choice, together with the identification of the question and the question type indicator representation into data representing a tag that is readable for the WTR. One tag is produced for each answer choice, and each answer choice tag thereby comprises information about the answer choice identification of the associated answer choice as well as of the question identification and the question type indicator.

In an alternative embodiment, each of the identification of the answer choices inherently also comprises the identification of the question. This can be made by either including the question identification as a part of the answer choice identification or by making each answer choice in the entire clinical study unique, which means that the answer choice easily can be associated with a particular question. The identifications of the question and the answer choices are thereby provided to the tag generator in an integrated form. The tag generator 13 is also supplied with the clinical study identification 103. This clinical study identification 103 is converted into an initialization study mode tag. The initialization study mode tag comprises a coding of the representation of the clinical study notation, e.g. in form of the clinical study identification.

The text of each question, the symbols of answer choices and the tag associated with each answer choice tag are collected in the questionnaire data entity 20 together with a representation of the clinical study identification 103. This questionnaire data entity 20 is typically comprised in a data file and this questionnaire data entity 20 information is configured in such a way that it can create a printed questionnaire when being printed. Most text processing software of today typically has the possibilities to include tags in the printout of a text. The actual configuration of the data file will thus depend on the software with which the data file is supposed to be printed. However, the questionnaire data entity is configured for creating a questionnaire when being printed. The printed questionnaire presents the text of the questions, the symbol of the answer choices and the answer tag associated with the respective answer choice. The printed questionnaire also presents the initialization study mode tag.

The communication address 104 for clinical study reply data is an important piece of information for the WTR, but is not very essential for any other parts of the system. This piece of information is thus not necessary to be included in the actual questionnaire. Instead, it is preferably included in the tag reader configuring data entity 40. In some cases, where a DCN 70 is reachable by different addresses, it can be useful to have the same communication address 104 for clinical study reply data as presented to the WTR also to be present in the DCN 70. Therefore, in a preferred embodiment, the association data entity 30 also comprises such information. In one embodiment, where an identity of the WTR is programmable or changeable, also the identity of the WTR in question can be incorporated in the tag reader configuring data entity 40. However, in such an embodiment, printouts of the tag reader configuring data entity 40 are typically made separately for each WTR to be configured, which makes the configuring operations more complex.

In preferred embodiments, the tag reader configuring data entity 40 also comprises data facilitating the definition of a PIN number for the particular patient. This can be achieved e.g. by providing a tag which sets the WTR in a PIN code definition mode when being read, and then a set of numbers 0-9 accompanied by respective tags. The patient or an assistant to the patient can then select a PIN code by reading the tags associated with the numbers. The PIN code can then be used for authorize the patient when the WTR is to be used to produce answers to the questionnaire.

The communication address 104 for clinical study reply data is supplied to the tag generator 15. The tag generator 15 is configured for converting the communication address 104 for clinical study reply data into data representing one or several tags that are readable for the WTR. In analogy with the questionnaire data entity 20, the tags are provided to be included in the tag reader configuring data entity 40, which is typically comprised in a data file. The tag reader configuring data entity 40 information is configured in such a way that it can create a printed questionnaire when being printed. The tag reader configuring data entity 40 preferably also give rise to a printout of easily understandable labeling of the tags, and preferably also of simple instructions for the person that is supposed to configure the WTR. If a PIN code is to be used by the patient, also tags representing the PIN number choices are provided in the tag reader configuring data entity 40. In the above mentioned embodiment where the identity of the WTR is programmable or changeable, the WTR identity number is also coded into a tag, which is provided with the tag reader configuring data entity 40.

An association data entity 30 is also created. This association data entity 30 is typically a data file. The association data entity 30 comprises the user definitions 108. The user definitions comprise associated pairs of a user identification number and an identity of an associated WTR. The user definitions 108 therefore constitute an association means for converting a certain WTR identity into a certain patient, as identified by his/her identification number. The association data entity 30 also comprises a representation of the clinical study notation 102, typically the clinical study identification 103. As indicated further above, in particular embodiments also the communication address 104 for clinical study reply data can optionally be comprised in the association data entity 30. The association data entity 30 is distributed to the appropriate DCN 70, or if being components of a same computer or computer network, being made available for the DCN 70 to retrieve.

A clinical project file 19 stores all study information and export files, called Study Definition Data 50, are created with appropriate excerpts from the project files 19 for use in external systems.

In other words, the software code 18 is configured for, when being loaded into the processor 12, partitioning the input data 100 into an association data entity 30, a tag reader configuring data entity 40 and a questionnaire data entity 20. The association data entity 30 and the tag reader configuring data entity 40 are thus independent of the question definitions. Furthermore, the text of the questions and the symbol of the answers at the printed questionnaire are provided exclusively in a form uninterpretable by the WTR. Therefore, the WTR cannot distribute any information that directly reveals any information about the actual questions or answers. All information obtainable by the WTR is only in the form of identifications of questions and answers, typically numbers. On the contrary, the answer tag and the study identification tag are interpretable by the WTR.

A few examples of how the procedure may look like for different users of the system. In a first phase of creating a clinical study, a study manager is to define the questions and the answer alternatives that are requested for achieving the appropriate input for the object of the clinical study. The study manager is often a person skilled in the art of medicine, but typically not equally skilled in the field of computer science. The interface towards the study manager therefore has to be as simple as possible in a computer technique point of view. One possible embodiment for presenting the input data is to let the study manager fill in a number of forms on a computer screen.

Fig. 3A illustrates a typical design of a form used for this purpose. When a clinical study manager starts the CSDK, a screen will appear where the clinical study manager is asked to select an already defined clinical study or request a new. If the clinical study manager selects a new one, a form looking as in Fig. 3A may appear at the computer screen. The clinical study manager fills in the name of the clinical study, i.e. a clinical study notation, preferably with an easily understandable wording. In this particular example "Fast insulin administration" was typed in. In one embodiment, the CSDK replies on such a clinical study notation by assigning the clinical study a clinical study identification, possibly with a version number. In this particular example, the clinical study was given the identity CQ2A-1, where the last digit represents the version number. The rest of the form was filled in by the clinical study manager, for instance the communication address definitions for the communication with the intended DCN. In the present example, the communication address definitions were constituted by an IP number and an IP port. When the form is completed, the clinical study manager can select to save it as a draft, which enables the clinical study manager to make changes to the definitions without inducing a new version number, or save it as a final version, which will lock the version number. Any future change in the definitions will thereafter be given a new version number. Typically, a final version cannot be selected until the questions are defined. The clinical study manager can then request to go to the question definition form. In applications, where the DCN has only one communication port on which data is to be received, the communication address definitions can be entered into the CSDK once and then be valid for all clinical studies. In such a case, the communication address definitions could be supplied e.g. during the setup of the CSDK or by a separate menu.

An example of a question definition form is illustrated in Fig. 3B. A question No. 2 is defined. A question type is selected in a drop-down menu to be "single answer". This means that only one answer will be allowed to be entered by the WTR (without erasing the earlier entered one). Other examples of question definitions could be "multiple answers", "maximum multiple answers", "numerical input answer" etc. The appearance of the form is preferably modified in response to the selected question definition. In this example, the clinical study manager has furthermore defined that there will be four answer alternatives, whereby the form adapts and opens four fields of answer definitions. The text of the question and the four answers are then entered into the respective boxes. In some cases, a certain answer may imply a jump in the list of questions. If the answers are supposed to induce such a jump, this can be noted in the "next question" boxes. If no next question is defined, the CSDK will in this particular embodiment assume that the question next in number will be the appropriate one. When the entire form is completed, the clinical study manager can click on any of the buttons at the bottom of the screen to continue the question definitions, to return to the main definition menu, e.g. to save the final definition, or to indicate that the present question was the final question.

Fig. 3C illustrates a user definition form. In this form, pairs of user identification numbers and WTR identities can be entered. In this particular example, the form has the shape of a table, where one pair is entered in one row.

The user definitions comprise information related to participating patients. In an alternative embodiment, a user identification number may be scanned by each patient by using its tag reader and tags representing numbers. This user identification number can be communicated to the DCN, e.g. in connection with the communication of each bunch of scanned answers or at the configuration of the tag reader. Such user identification number may be used together with a tag reader identity number or as an alternative to the tag reader identity number.

When all definitions are ready, the final definitions are saved. This also initiates the creation of the association data entity, the tag reader configuring data entity and the questionnaire data entity. All the procedure to enter the necessary information about the clinical study can thus be performed without any exceptional skill in computer handling, and the procedures described above would be possible to perform by all clinical study managers without essentially any education or instruction about the present CSDK.

The WTR is the unit that is to be distributed to the patients together with the questionnaire. It is therefore preferable if the WTR unit can be designed in such a way that it is easy to handle, easy to understand and easy to operate. One embodiment of a WTR 60 is illustrated in Fig. 4A. The overall shape of the WTR is adapted to be easily grippable by a hand 61, even with a slightly dysfunctional hand. A screen 62 is provided to present different kinds of instructions and data display. An optical geometric pattern detector 64, in this embodiment a bar code reader 66 is mounted in the bottom of the WTR 60, and is operated by pressing the protruding parts 65 of the lower part of the casing against the paper on which the bar code to read is provided.

The optical geometric pattern detector 64 could in alternative embodiments comprise other types of readers, for instance 2D or matrix barcode readers. The optical geometric pattern detector 64 could also in alternative embodiments comprise image recorders connected to image analysers, programmed to extract information from the recorded geometric pattern. In another embodiment, the WTR 60 is instead designed as a handle with the optical geometric pattern detector 64 mounted at an upper front part. The optical geometric pattern detector 64 is directed towards the tag to be read and a read button is pressed.

In yet another embodiment, the WTR 60 is designed in a pen-shape, basically as digital pen. The tip of the pen is stroked over e.g. a bar pattern, whereby the pattern is read by the optical geometric pattern detector 64.

Anyone skilled in the art realizes that there are many more alternative designs for a WTR 60.

Fig. 4B illustrates schematically, in a block diagram, the functions of an embodiment of a WTR 60. The wireless tag reader 60 comprises an optical geometric pattern detector 64. The optical geometric pattern detector 64 of this particular embodiment is a bar code reader 66. However, in alternative the optical geometric pattern detector 64 can be any device capable of detecting characteristic optical features of a printed geometric pattern.

A tag reader processor 63 is connected to the optical geometric pattern detector 64. A tag reader memory 67 is connected to the tag reader processor 63. The tag reader memory 67 comprises configuration data 55 useful for detecting the tags. This configuration data 55 comprises parts of tag reader configuring data entity and is typically entered by a configuration operation, described further below. The WTR 60 further comprises a transmitter 68 for wireless communication, connected to the tag reader processor 63. In the present embodiment, the transmitter 68 comprises a SIM card of an ordinary mobile telephone and uses a conventional mobile telephone network to communicate. In alternative embodiments, however, other types of transmitters 68 can also be utilized. The WTR thus has a communication capability that enables the devices to send and receive information to and from a communication hub such as a server. In the tag reader memory 67 tag reader software code 56 is stored. This tag reader software code 56 is configured for, when being loaded into the tag reader processor 63, causing the optical geometric pattern detector 64 to read the answer tags and the initialization study mode tag. Answer identifications and question identifications of read answer tags are stored in the tag reader memory in an answer data entity 57.

In a preferred embodiment, the WTR also comprises a user interface 69, typically a screen. On the screen, useful information can be presented for the patient. This screen can be used as a complement to the patient instructions provided by the questionnaire. This is further discussed below.

In a preferred embodiment, the WTR also comprises a timer 58. When tags from the questionnaire are read, these data can thus be time stamped by reference to the timer 58, and the reading time can thus be saved together with the actual answer choices in the answer data entity 57.

Before a WTR is to be used by a patient, it has to be configured. Details about the communication, such as addresses, network identities etc. are often experienced as difficult to handle by a patient. Therefore, the WTR is preferably configured for handling all tasks regarding the communication without knowledge and actions from the patient. Therefore, the configuration typically has to comprise all necessary information about the communication. This is preferably available through the tag reader configuring data entity.

A person involved in the patient contact during the clinical study, e.g. a nurse, is provided with the WTR and a printout of the tag reader configuring data entity, a so called configuring sheet. One example of how such a printed tag reader configuring data entity, i.e. a tag reader configuring sheet 42, may look like is illustrated in Fig. 5A. The instructions how to perform the actual configuration is preferably provided at the same printout. The nurse reads the tags "A", "B" and "C", 201-203. The tag "A" is an initialization tag, which informs the WTR about that a configuration is to take place. The tag reader software code of the WTR erases possible earlier data, in particular concerning communication and PIN codes, if any. Tag "B" and tag "C" in this embodiment represents the communication address 104 for clinical study reply data and this information is decoded and stored in the WTR memory. In other words, the WTR is configured for setting the configuration data according to the tag reader configuring data entity. In the present embodiment, the WTR is then put into a state where a PIN code is to be entered, and in a preferred embodiment, a WTR screen announces that the WTR is ready to receive the PIN code. The nurse or the patient then reads, in this embodiment, four digits from the digit tags 204 in the printed tag reader configuring data entity, which by the WTR is interpreted as the PIN code of the patient. An OK tag 206 is read when the PIN code definition is over. A "clear" tag 207 can be read if the PIN number has been entered erroneously. The entered PIN code is preferably presented at the WTR screen, so that the nurse or patient can check that the PIN code is correctly defined. The configuration procedure is ended by reading the last finalizing tag 205, which informs the WTR that the configuration is ended. The WTR is now ready to be used by the patient. The tag reader configuring data entity is thus provided as a printable data entity, which when being printed creates a configuring sheet. The configuring sheet comprises at least one communication settings tag representing the communication address for clinical study reply data. The tag reader software code is further configured for, when being loaded into the tag reader processor, reading the communication settings tag or tags and storing a representation of the communication address for clinical study reply data in the configuration data in the tag reader memory. This entire configuration procedure is due to that the tag information is available at the configuring sheet, i.e. the printed tag reader configuring data entity, easily performed by any nurse, not particularly skilled in e.g. programming.

The WTR is now ready to use and the patient can bring it to the site where the questionnaire is to be answered, e.g. the home of the patient. A questionnaire that is a printed questionnaire data entity 20 is supplied to the patient. This is typically performed by simply handing over a file of printed sheets, e.g. either in person or by any mail delivery. However, the questionnaire could also be provided in an electronic form, e.g. as an enclosure to an e-mail, as a text file on an USB memory etc., whereby the patient himself / herself can print out the actual questionnaire.

An example of a first page of a questionnaire is illustrated in Fig. 5B. The first page of this embodiment starts with an initializing instruction and an initialization study mode tag 210. When the initialization study mode tag 210 is read by the WTR, a reading session is started. In other words, the tag reader software code is further configured for, when being loaded into the tag reader processor and when an initialization study mode tag being read, initializing a reading session. The initialization study mode tag 210 in this embodiment comprises information about the clinical study identification. In the present embodiment, the tag reader software code of the WTR is configured to request a PIN code. The patient enters the PIN code by reading the tags 204. When the OK tag is read, the WTR compares the entered PIN code with the PIN code stored in the configuration data in the tag reader memory. If the PIN codes agree, the actual questionnaire answering session starts and the patient is instructed to go to the first question page of the questionnaire.

An example of a question page of the questionnaire is illustrated in Fig. 5C. At the top, the question number is shown, and under the number, the actual question is printed in an easily understandable manner. Below the question, the different defined answer alternatives are shown. In this embodiment, this particular question is a single choice question with four alternative answers. These four answers are presented in plain text or as any other easily understandable symbols. In connection with each answer, a respective answer tag 215-218 is provided. The content of the actual answer tag represents at least the answer identification and the question identification of the question. Preferably, the answer tag also represents the clinical study identification, optionally including the version number.

When the patient has identified the answer that corresponds best to the present situation, the patient reads the corresponding tag by the WTR. The patient is unaware of the question and answer identifications, and the WTR is unaware of the actual content of the question and answers. In the present embodiment, the WTR also registers the time at which the reading is performed, i.e. provides a time stamp of the answer. The patient does not have to interfere with such time stamping. The read answer is stored in the answer data entity of the WTR together with the time stamp.

In an alternative time stamp embodiment, the time when the questionnaire is answered is entered by the patient himself. This is then preferably made by scanning tags corresponding to numbers or times or dates.

In a particular embodiment, as an additional protection against attempts to falsify replies of the clinical study, the content of the tags can be encrypted. The interpretation of tags is often performed according to standardized procedures, and it is possible to use some other tag reading equipment to extract the detailed information contained in the tags. By copying such information and sending it to the DCN pretending to be an authorized patient may ruin an entire clinical study. In order to mitigate such attempts, the information contained in the tags could be encrypted. Therefore in a preferable embodiment, the answer tag comprises an encryption of the answer identification and the question identification of the respective question. The tag reader software code is further configured for, when being loaded into the tag reader processor, decrypting detected answer tag to achieve the answer identification and the question identification.

In a preferred embodiment, in order to facilitate the navigation through the questionnaire, the answer tag further comprises information of an expected next question. In a question which may introduce branching of the question paths, a separate next question can be defined individually for each answer alternatives, as indicated above. Otherwise, the expected next tag is typically an answer tag connected to the next question in order. Also the initialization study mode tag preferably comprises information of an expected next tag. The tag reader software code is thus in this embodiment further configured for, when being loaded into the tag reader processor, reading an answer tag when it is identical to an answer tag of the expected next question. Corresponding information could also be provided on the WTR screen as information to the patient. For instance, when an answer has been read, the screen could display the number of the next question to be answered.

Fig. 5D is an example of a submit page of a questionnaire. When all questions have been answered, the patient is instructed to go to this submit page. By reading a submit tag 219, the patient approves that the answers are sent to the DCN. This ends the actions from the patient. The WTR now autonomously controls the submission of data. Such an answering session is possible to perform by almost any patient, even without any skill in any computer technology. The only instruction needed for the patient is how to perform a tag reading. All other necessary steps are taken by the WTR without the knowledge of the patient, due to the information contained in the tags.

When the WTR recognizes that the submit tag 219 has been read, it starts a communication procedure. The answer identifications and question identifications of the read answers, the identity of the WTR, and preferably also time stamps of the answers, that are stored in the tag reader memory are submitted to the DCN. The address for the communication is retrieved from the stored configuration data. Each WTR has a unique identity number. The tag reader software code is therefore preferably further configured for, when being loaded into the tag reader processor, submitting the identity number of a tag reader together with the answer identifications and question identifications of read answer tags; The submission takes place by utilizing the transmitter included in the WTR. The submitted data can in one embodiment be the plain information of the read tags, possibly suitably coded during the submission. In another embodiment, the WTR may compile the information. For instance, the WTR may check that the clinical study identification contained in the answers corresponds to the clinical study identification obtained by the initialization of the reply session. Since the clinical study identification preferably is included in all answer tags, such information can be removed and only submitted once, in order to save the amount of submitted data. In other words, the tag reader software code is further configured for, when being loaded into the tag reader processor, reading the submit tag and for submitting the answer identifications and question identifications of read answer tags being stored in the tag reader memory to the data collection node using the communication address for clinical study reply data.

Another quantity that could be of interest for the clinical study is the duration of the answering procedure. In one embodiment, the WTR comprises a time counting unit, which is started when an initialization study mode tag is scanned and stopped when the submit tag is scanned. The duration of the replying session can thus be reported to the DCN together with the answers.

The answers of the questionnaire is thus submitted from the WTR to the DCN using the communication address for clinical study reply data stored in the WTR configuration data. An embodiment of a DCN 70 is schematically illustrated in Fig. 6. The DCN 70 comprises a communication unit 71 for receiving data from different WTRs using the communication address for clinical study reply data. The DCN 70 further comprises a processor 73 connected to the communication unit 71 and software code 74 to be loaded into the processor 73. In this embodiment, the DCN 70 also comprises a copy of the association data entity 30. The software code 74 and the association data entity 30 are in this embodiment stored in a memory 75. In alternative embodiments, the DCN 70 may not comprise a copy of the association data entity 30 but may instead have access to the association data entity, stored elsewhere.

The DCN 70 includes answer identifications and question identifications of received submissions from WTRs in the secure DCN database 72, i.e. the clinical study data base. In this embodiment, the DCN 70 also checks that the answer identifications and question identifications are associated with the right clinical study. To this end, the received data is included in the clinical study data base only if it comes from a WTR that is participating in that particular study. The DCN 70 therefore compares the WTR identity number with the entries in the association data entity 30, and only if the WTR identity number is included in the association data entity 30, the received data is accepted. In other words, the DCN 70 is further configured for including answer identifications and question identifications of read answer tags received from a WTR into the clinical study data base only if the identity number of the WTR submitting the answer identifications and question identifications is included in the association data entity.

Another way to ensure that the received data is correct is to check the clinical study identification. Therefore, in one embodiment, the DCN 70 has at least access to the association data entity 30. The tag reader software code is further configured for submitting the clinical study identification obtained from the initialization study mode tag together with the answer identifications and question identifications of read answer tags. The DCN 70 is thereby further configured for including answer identifications and question identifications of read answer tags received from a WTR 60 into the secure DCN database 72 only if the clinical study identification received from the WTR 60 submitting the answer identifications and question identifications of read answer tags corresponds to the clinical study identification of the association data entity 30.

The DCN database 72 will thus continuously collect the answers from all WTRs used for the clinical study. The DCN data base 72 comprises all answers, preferably time stamped, in a coded form, i.e. represented by the answer identification and the question identification. Also the identity of the replying party is coded, either as the identity of the WTR or as the identification number of the patient associated with the WTR. This DCN data base 72 can, optionally in combination with the content from other data bases, be used by different actors in connection with the clinical study for continuously monitoring the outcome of the study. Strange replies may be followed up immediately and patients not answering in time may be reminded.

The development of the clinical study results may also give rise to different improvement ideas. For instance, it might be found that some questions are misunderstood by the patients or that the answer alternatives are inappropriate. In such cases, the clinical study definition can be changed or corrected. This typically results in a new version number of the clinical study. New questionnaires have to be distributed to the concerned patients, however, the entire process can continue to operate in the meantime. The version number of the clinical study will also be available together with the answer alternatives and the result can be adapted to the questionnaire version accordingly. All properties of the clinical study are stored in Study Definition Data database. The patient can at any time store a new version of the study definition in the Study Definition Data. The Study Definition Data stores the complete revision history and the study manager can at any time retrieve an older version of a study definition.

The present solutions disclosed above have several advantages compared to prior art e-PRO solutions. Most e-PRO solutions available today do not allow the clinic staff and pharmaceutical company personnel to access the system through a standard web browser. Special software is used and is tedious to learn. By the present system, all interactions with the technical parts of the system are performed by simple interfaces, requiring very limited knowledge in computer handling. The time to start up the e-PRO solution must be kept at a minimum both for subjects and the clinical staff. Many of the earlier e-PRO solutions have a long start-up time. The present system, however, allows a very short start-up time both for the patients and for the managing staff.

Clinic staff should be able to view patient entered data as soon it is entered so that they can monitor compliance and assist patients that are not responding. Many e-PRO systems of today do not offer this functionality. In the present system, the submission of the answers takes place immediately or at least as soon as possible after the completion of the reply and the submitted answers are immediately included in the DCN data base, where the clinical staff has access to it. The transferring time from the time when the patient accepts the submission to the time when the answers are available at the DCN data base may even be as short as a few seconds.

Since the DCN data base has the complete answer information, it is possible for clinic staff to monitor the result from each patient separately. It is also possible and relatively easy to tailor a web-view to highlight data of particular interest in a certain trial. This data may be derived from several patient answers.

Many prior art e-PRO system do not support that the subject entered data is time stamped to achieve documented compliance. In the present solution, time stamping is easily achieved if requested.

The embodiments described above are to be understood as a few illustrative examples of the present invention. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the scope of the present invention. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible. The scope of the present invention is, however, defined by the appended claims.

Claims

1. A clinical study design kit (10), comprising:

a processor (12), an input device (14) connected to said processor (12) and configured for enabling input of data to said processor (12), a memory (16) connected to said processor (12) and software code (18), stored in said memory (16);

said software code (18) being configured for, when being loaded into said processor (12), enabling entering of input data (100) by said input device (14) into said processor (12), said input data (100) comprising at least a clinical study notation (102), a communication address (104) for clinical study reply data, question definitions (106) and user definitions (108);

each said question definition (106) comprising text of the respective question, a question type indicator, and symbols of answer choices;

said user definitions (108) comprising information related to participating patients;

said software code ( 18) being further configured for, when being loaded into said processor (12), supporting creation of a question identification for each said question and an answer identification for each said answer choice; said software code (18) being further configured for, when being loaded into said processor (12), partitioning said input data (100) into an association data entity (30), a tag reader configuring data entity (40) and a questionnaire data entity (20);

said association data entity (30) comprising representations of said clinical study notation (102) and said user definitions (108);

said tag reader configuring data entity (40) comprising a representation of said communication address (104) for clinical study reply data;

said association data entity (30) and said tag reader configuring data entity (40) being independent of said question definitions (106);

said questionnaire data entity (20) being configured for creating a questionnaire (22) when being printed; said questionnaire (22) presenting said text of said questions, said symbol of said answer choices and an answer tag (215-218) associated with a respective said answer choice;

said answer tag (215-218) representing at least said answer identification and said question identification of the respective question; said answer tag (215-218) being an optical geometric pattern interpretable by a tag reader (6) .

2. The clinical study design kit according to claim 1, characterized in that said text of said questions and said symbol of said answers at said printed questionnaire (22) being provided exclusively in a form uninterpretable by said tag reader (6).

3. The clinical study design kit according to claim 1 or 2, characterized in that said questionnaire (22) further presents an initialization study mode tag (210) representing said clinical study notation, whereby said initialization study mode tag (210) being an optical geometric pattern interpretable by said tag reader (6) .

4. The clinical study design kit according to any of the claims 1 to 3, characterized in that each said user definition (108) comprises an associated pair of a user identification number and an identity number of a tag reader.

5. A system for a clinical study, comprising:

said clinical study design kit (10) according to any of the claims 1 to

4;

a data collection node (70), accessible by said communication address (104) for clinical study reply data;

said data collection node (70) comprising a clinical study data base (72); and

at least one tag reader (6);

each of said at least one tag reader (6) in turn comprising:

an optical geometric pattern detector (64); a tag reader processor (63) connected to said optical geometric pattern detector (64);

a tag reader memory (67) connected to said tag reader processor (63), said tag reader memory (63) comprising configuration data (55);

a transmitter (68) for communication, connected to said tag reader processor (63); and

tag reader software code (56) stored in said tag reader memory

(67);

said tag reader software code (56) being configured for, when being loaded into said tag reader processor (63), causing said optical geometric pattern detector (64) to read said answer tag (215-218) and said initialization study mode tag (210);

wherein answer identifications and question identifications of read said answer tags (215-218) being stored (57) in said tag reader memory (67).

6. The system for a clinical study, according to claim 5, characterized in that said tag reader (6) is a wireless tag reader (60).

7. The system for a clinical study, according to claim 5 or 6, characterized in that said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63) and when an initialization study mode tag being read, initializing a reading session.

8. The system for a clinical study, according to any of the claims 5 to 7, characterized in that said tag reader (6) being configured for setting said configuration data (55) according to said tag reader configuring data entity (40).

9. The system for a clinical study, according to claim 8, characterized in that

said tag reader configuring data entity (40) is provided as a printable data entity, which when being printed creates a configuring sheet; said configuring sheet comprises at least one communication settings tag (202, 203) representing said communication address (104) for clinical study reply data;

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), reading said at least one communication settings tag (202, 203) and storing a representation of said communication address (104) for clinical study reply data in said configuration data (55) in said tag reader memory (67).

10. The system for a clinical study, according to any of the claims 5 to 9, characterized in that

said questionnaire (22) further comprises a submit tag (219);

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), reading said submit tag (219) and for submitting said answer identifications and question identifications of read said answer tags (215-218) being stored in said tag reader memory (67) to said data collection node (70) using said communication address (104) for clinical study reply data.

1 1. The system for a clinical study, according to any of the claims 5 to

10, characterized in that

said answer tag (215-218) and said initialization study mode tag (210) further comprises information of an expected next question;

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), reading an answer tag when being identical to an answer tag of said expected next question.

12. The system for a clinical study, according to any of the claims 5 to

1 1, characterized in that

said answer tag comprises an encryption of said answer identification and said question identification of the respective question;

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), decrypting detected said answer tag to achieve said answer identification and said question identification.

13. The system for a clinical study, according to any of the claims 5 to

12, characterized in that

said data collection node (70) has access to said association data entity (30);

each tag reader (6) having a unique said identity number of a tag reader;

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), submitting said identity number of a tag reader together with said answer identifications and question identifications of read said answer tags;

said data collection node (70) being further configured for including answer identifications and question identifications of read said answer tags received from a tag reader (6) into said clinical study data base (72) only if the identity number of the tag reader (6) submitting the answer identifications and question identifications of read said answer tags is included in said association data entity (30).

14. The system for a clinical study, according to any of the claims 5 to

13, characterized in that

said data collection node (70) has access to said association data entity (30);

said tag reader software code (56) being further configured for, when being loaded into said tag reader processor (63), submitting said clinical study identification obtained from said initialization study mode tag (210) together with said answer identifications and question identifications of read said answer tags;

said data collection node (70) being further configured for including answer identifications and question identifications of read said answer tags received from a tag reader (6) into said clinical study data base (72) only if the clinical study identification received from the tag reader (6) submitting the answer identifications and question identifications of read said answer tags corresponds to said clinical study identification of said association data entity (30).