[EpiData-list] Aspects of function in updated public release of Manager and EntryClient

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Wed May 29 02:55:54 CDT 2013

Regarding the new versions 1.4 of Manager and EntryClient.

Many changes have been implemented since first public release last year:

* Encrypted data in project files
* Expanded headings to support 5 sizes/types.
* Added printing of dataform
* Key Fields (Unique keys) - including display of status of key at 
record level

* Implemented a "Copy Record to Clipboard" function, with variable 
format string.

* New improved drag/drop implementation (multiselect, copy/paste, 
* Double Entry Preparation/Validation
* Improved Study Information form.
* New improved export form, with more export formats. (SPSS, SAS, CSV, 
* Expanded process toolbar

Obviously this is a remarked update and despite efforts to find and fix 
problems in the testing uploads some issues have arisen in latest days:

1 Double entry
In EpiData Entry (old software):
- two different double entry modes are implemented:
1. Compare values in second file with what was already entered in first 
file directly at entry
2. Compare two individually entered files

In EpiData Manager (New software):
- Only type two is implemented at this point.  Therefore you must (as 
explained by T.Christiansen just before this mail) first enter data in 
one file, then independently in the second. Following that compare the two.

   Validation has been extended with a new option such that a new field 
can be added at record level (each observation) with the result of the 
validation. When this field is added it makes sense to write a new file, 
e.g. bromar.1.doubleentry-verification.epx. You can then read that file 
into analysis and see which records are not validated. The values for 
the created variable are:
0 = Validated
1 = Record does not exist in duplicate file
2 = Failed due to different text
3 = Failed due to different values
4 = Duplicate key exists

But currently in v1.4.0.0  the file is always created following 
validation, and there can be a problem with the creation. This will be 
changed, such that only when the user indicates addition of the field 
the new file will be written and obviously also with the correct value.

  Aspects in relation to export:
    a. Export to SPSS or SAS:  the user is not informed of writing the 
csv file
    b. Export to DDI: the created xml is not correct in certain situations.

   Exported DDI meta data must validate correctly against the 
DDI-Alliance standard v3.1. - with an external tool such as documented 
on http://www.ddialliance.org/node/855 - The validator is found on 

A few other aspects, such as default naming of valuelabel sets, term for 
dataforms in reports and missing mentioning of cycle number

The problems mentioned (1b, 2 and 3) will be fixed and a new public 
update will be available later this week.

Regarding cycle number this is a new feature which the end user is not 
changing. Every time the project file is saved and there has been a 
change in either study information, structure or value label sets 
(metadata) or entered/edited observations/records the file will be saved 
with a new "cycle number". On export this is part of the name of the 
file. e.g. /home/jens/data/bromar_new.5.dta

We will gradually implement usage of the cycle number in documentation 
and verification of data in relation to in particular the implementation 
of Good Clinical Practice guideline demands of verification. The notion 
of a cycle comes from the DDI-alliance data-life cycle concept. You can 
read more about that on: http://www.ddialliance.org/ddi-at-work

Jens Lauritsen
Epidata Association

More information about the EpiData-list mailing list