Dear Epidata Team,
First we have to thank you very much for the quality of your software.
We intend to use EpiData for a double entry verification. Unfortunately, we have found a problem when entering numerical fields. If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0.
This is a problem for us. In the framework of Clinical Trials, the operators have to enter exactly what is written on the CRF. A solution could be to define the field as a text one. But of course this allows to enter letters instead of digits, and that is not enough secure.
We also tried to associate a numerical range (000-999) to the text 3 characters field (in a .CHK file). With this kind of control, typing a11 is denied, but typing 1a1 is allowed...
Do you have an other solution or idea to solve this problem?
In your forum, you answered to somebody that this problem will be solved in the next version of EpiData. Have you already an idea of the availability date of this version?
Thank you very much in advance,
Valérie Conte
Currently I only see this solution - assuming you have your data for entering now:
1 Based on your first file go to tools and use "copy structure". 2 In the copy your system enter the data separately (without the simultaneous comparison). 3 Use Document->Validate duplicate files 4 for the errors that show up you can compare with the original recordings.
Just now the priority is to work on the long term sustainable changes, which leaves it quite uncertain how soon any detailed problem will be solved. (Notice the "how soon" - not "if").
Also in particular in regards to clinical trials there will be a complete "package" assisting clinicians to follow the Good Clinical Practice Guidelines. I participated in a working group within the ECRIN network (Http://www.ecrin.org/). The report defines how we see GCP defined in practice, - and EpiData Software will follow these guidelines. ECRIN is an industry INdependent researcher network.
ECRIN: European Clinical Research Infrastructures Network The report: GCP-compliant data management in multinational clinical trials. ECRIN-2, Deliverable D10, Version 1, 15 September 2008. is avaialable at: http://www.ecrin.org/index.php?option=com_docman&task=doc_download&g...
regards Jens Lauritsen EpiData Association
epidata-list@lists.umanitoba.ca wrote:
We intend to use EpiData for a double entry verification. Unfortunately, we have found a problem when entering numerical fields. If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0.
This is a problem for us. In the framework of Clinical Trials, the operators have to enter exactly what is written on the CRF. A solution could be to define the field as a text one. But of course this allows to enter letters instead of digits, and that is not enough secure.
We also tried to associate a numerical range (000-999) to the text 3 characters field (in a .CHK file). With this kind of control, typing a11 is denied, but typing 1a1 is allowed...
Do you have an other solution or idea to solve this problem?
Dear Valérie,
There is perhaps a way to get round your problem (and I think you looked in the right direction). Let's try this:
1- define a character field with 3 spaces ('fieldchar')
2- define a numeric field of 3 digits ('fieldnum')
3- in your check file, state that the numeric field is filled from the character field by simply writing something like:
FIELDNUM BEFORE ENTRY fieldnum=integer(fieldchar) goto nextvariable END END
4- in the checkfile for the 'nextvariable' field write:
NEXTVARIABLE BEFORE ENTRY IF (fieldnum <> integer(fieldchar)) THEN CLEAR fieldnum CLEAR fieldchar GOTO fieldchar ENDIF END END
In this case, when the operator enters a string of 3 numbers in the character field, everything is OK; when the second operator will enter another string of 3 number, the error message should be prompted. And if the operator enters a string of 3 characters amongst which one is not a number (even in the middle of the string), such as "1a1" in your example, the prompt will remain stuck in the fieldchar until a correct value is entered.
Of course, your fieldchar variable will not be of any use later on, but that shouldn't be a problem.
Hope this helps.. and have a nice Easter break!
Yves
Yves MARTIN-PREVEL, Epidemiologist, MD, MSc, PhD 'Nutripass' IRD (WHO Collaborating Center for Nutrition) UMR204 IRD/Montpellier1/Montpellier2/SupAgro Institut de Recherche pour le Développement (IRD) BP 64501 - 911, avenue d'Agropolis 34394 MONTPELLIER CEDEX 5 (France) yves.martin-prevel@ird.fr Tel: +33(0)4.67.41.61.70 - Fax: +33(0)4.67.41.61.57 https://www.mpl.ird.fr/ur106/index.htm http://www.cilss.bf/nusapps/
-----Message d'origine----- De : epidata-list-bounces@lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] De la part de epidata-list@lists.umanitoba.ca Envoyé : vendredi 10 avril 2009 16:29 À : epidata-list@lists.umanitoba.ca Objet : Re: [EpiData-list] double entry verification : problem when entering numerical fields
Currently I only see this solution - assuming you have your data for entering now:
1 Based on your first file go to tools and use "copy structure". 2 In the copy your system enter the data separately (without the simultaneous comparison). 3 Use Document->Validate duplicate files 4 for the errors that show up you can compare with the original recordings.
Just now the priority is to work on the long term sustainable changes, which leaves it quite uncertain how soon any detailed problem will be solved. (Notice the "how soon" - not "if").
Also in particular in regards to clinical trials there will be a complete "package" assisting clinicians to follow the Good Clinical Practice Guidelines. I participated in a working group within the ECRIN network (Http://www.ecrin.org/). The report defines how we see GCP defined in practice, - and EpiData Software will follow these guidelines. ECRIN is an industry INdependent researcher network.
ECRIN: European Clinical Research Infrastructures Network The report: GCP-compliant data management in multinational clinical trials. ECRIN-2, Deliverable D10, Version 1, 15 September 2008. is avaialable at: http://www.ecrin.org/index.php?option=com_docman&task=doc_download&g... emid=68
regards Jens Lauritsen EpiData Association
epidata-list@lists.umanitoba.ca wrote:
We intend to use EpiData for a double entry verification. Unfortunately, we have found a problem when entering numerical fields. If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0.
This is a problem for us. In the framework of Clinical Trials, the operators have to enter exactly what is written on the CRF. A solution could be to define the field as a text one. But of course this allows to enter letters instead of digits, and that is not enough secure.
We also tried to associate a numerical range (000-999) to the text 3 characters field (in a .CHK file). With this kind of control, typing a11 is denied, but typing 1a1 is allowed...
Do you have an other solution or idea to solve this problem?
_______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
Dear Valérie,
There is perhaps a way to get round your problem (and I think you looked in the right direction). Let's try this:
1- define a character field with 3 spaces ('fieldchar')
2- define a numeric field of 3 digits ('fieldnum')
3- in your check file, state that the numeric field is filled from the character field by simply writing something like:
FIELDNUM BEFORE ENTRY fieldnum=integer(fieldchar) goto nextvariable END END
4- in the checkfile for the 'nextvariable' field write:
NEXTVARIABLE BEFORE ENTRY IF (fieldnum <> integer(fieldchar)) THEN CLEAR fieldnum CLEAR fieldchar GOTO fieldchar ENDIF END END
In this case, when the operator enters a string of 3 numbers in the character field, everything is OK; when the second operator will enter another string of 3 number, the error message should be prompted. And if the operator enters a string of 3 characters amongst which one is not a number (even in the middle of the string), such as "1a1" in your example, the prompt will remain stuck in the fieldchar until a correct value is entered.
Of course, your fieldchar variable will not be of any use later on, but that shouldn't be a problem.
Hope this helps.. and have a nice Easter break!
Yves
Yves MARTIN-PREVEL, Epidemiologist, MD, MSc, PhD 'Nutripass' IRD (WHO Collaborating Center for Nutrition) UMR204 IRD/Montpellier1/Montpellier2/SupAgro Institut de Recherche pour le Développement (IRD) BP 64501 - 911, avenue d'Agropolis 34394 MONTPELLIER CEDEX 5 (France) yves.martin-prevel@ird.fr Tel: +33(0)4.67.41.61.70 - Fax: +33(0)4.67.41.61.57 https://www.mpl.ird.fr/ur106/index.htm http://www.cilss.bf/nusapps/
-----Message d'origine----- De : epidata-list-bounces@lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] De la part de epidata-list@lists.umanitoba.ca Envoyé : vendredi 10 avril 2009 16:29 À : epidata-list@lists.umanitoba.ca Objet : Re: [EpiData-list] double entry verification : problem when entering numerical fields
Currently I only see this solution - assuming you have your data for entering now:
1 Based on your first file go to tools and use "copy structure". 2 In the copy your system enter the data separately (without the simultaneous comparison). 3 Use Document->Validate duplicate files 4 for the errors that show up you can compare with the original recordings.
Just now the priority is to work on the long term sustainable changes, which leaves it quite uncertain how soon any detailed problem will be solved. (Notice the "how soon" - not "if").
Also in particular in regards to clinical trials there will be a complete "package" assisting clinicians to follow the Good Clinical Practice Guidelines. I participated in a working group within the ECRIN network (Http://www.ecrin.org/). The report defines how we see GCP defined in practice, - and EpiData Software will follow these guidelines. ECRIN is an industry INdependent researcher network.
ECRIN: European Clinical Research Infrastructures Network The report: GCP-compliant data management in multinational clinical trials. ECRIN-2, Deliverable D10, Version 1, 15 September 2008. is avaialable at: http://www.ecrin.org/index.php?option=com_docman&task=doc_download&g... emid=68
regards Jens Lauritsen EpiData Association
epidata-list@lists.umanitoba.ca wrote:
We intend to use EpiData for a double entry verification. Unfortunately, we have found a problem when entering numerical fields. If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0.
This is a problem for us. In the framework of Clinical Trials, the operators have to enter exactly what is written on the CRF. A solution could be to define the field as a text one. But of course this allows to enter letters instead of digits, and that is not enough secure.
We also tried to associate a numerical range (000-999) to the text 3 characters field (in a .CHK file). With this kind of control, typing a11 is denied, but typing 1a1 is allowed...
Do you have an other solution or idea to solve this problem?
_______________________________________________ EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
There are a couple of solutions posted already, but I want to point out that this problem of leading zeros has been around since punch cards and is something that could be avoided by starting such numbering with, for example 100 (if that fits with the maximum id number being 999) or coding the sequential ID within a sequence such as Site #, ID # (e.g. site 1 has ID numbers 1000-1999, etc).
Jamie
Valérie wrote:
If the keyboarder types 001 in a 3 digit numerical field, Epidata stores 1 (whitch is quite normal). But during the verification step, if they enter 001 again ... there is a message to remind them that there is a difference. Of course, the difference is between the stored value 1 et the first typed digit 0.
epidata-list@lists.umanitoba.ca
-
epidata-list＠lists.umanitoba.ca