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?