[EpiData-list] double entry verification : problem when entering numerical fields

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Fri Apr 10 09:29:26 CDT 2009


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&gid=64&Itemid=68
 

regards Jens Lauritsen
EpiData Association

epidata-list at 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?



More information about the EpiData-list mailing list