[EpiData-list] Check commands, field naming and use of {} in paste as.

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Fri Feb 18 13:00:42 CST 2011

Neville Verlander posted three good design issue questions.
Some of this has been decided and other not yet settled completely, but 
we have an indication of what will be the situation:

1. Will there be a possibility to define properties for fields at the 
project or database level ? Exemplified by missing values and confirm field.

1a Regarding "confirm fields". Confirm as well as "entry mode" are 
single properties. For these we will consider an easy way of applying 
same definition for all fields.

1b The missing value implementation is now part of the value label 

The easy way to apply file wide properties such a missing value of 9999 
with the current implementation is:
a define a value label - say "miss9999" -with one numeric input marked 
as missing, e.g. 9999.
b apply that "valuelabel" to one field
c. add a range to that same field. e.g. 1 - 900
d. while the field is active (focused) press ctrl+c
e. move cursor to all other relevant fields one by one and press ctrl+v
     this will copy as well the range as the missing value definition to 
these other fields.

We will discuss internally how to allow for simplified definitions of 
missing value status properties for several fields. But most likely this 
will not be changed in version 1.

2. import of chk files.
The decision here is rather clear.
- all recfiles can be imported and all data will be secured
- for chk files containing labels in a block - these labels will be 
imported into the project, but not assigned to the fields
- for other chk commands there will be NO import

An easy way of securing import of data and maintaining all value labels 
attached to all fields is to do this:
a In EpiData Entry export the data to Stata format (any version)
b In the manager import or add structure from that file.

If other chk commands should be imported we would have to make a new chk 
file parser and interpreter. The time to do this is better spend on 
issues of future function.

3. Regarding "paste as qes" including aspects, such as first word or 
automatic field naming and the use of curly brackets {}:

"Paste as" functionality will be available in the Manager - obviously. 
For instance: say you have 10 questions of food items "did you eat 
....." in a questionnaire document, then you could just mark these as a 
block and in "edit" choose the "paste as integer" - in this way you can 
quickly create many items by pasting fields onto the form based on 
information on the clipboard.

However we expect to remove the "paste as qes" from the next test 
release, since there is an overall need of clarification and 
simplification. The extended definition contained in a qes file will be 
replaced by the possibility to define templates (see point 4 below):

Users wishing to continue the use of qes file and curly bracket 
principles will then have to:
a. Create rec files in EpiData Entry
b. Import the rec file into the manager.

The time we should spend on accepting paste as qes is far better used 
for other aspects of the revised software.

4. EpiData Template
A new extended definition for creation of xml structures has been 
developed and the first internal tests are now ongoing. The idea will 
be, that a complete datafile structure, including value label, range, 
and sections can be made from a "white space" separated flat file. The 
addition is a reflection and consequence of suggestion from the project 
collaborations with MSF (www.msf.org) and a specific outbreak toolbox 
project financed from the European Union ECDC office. More information 
on this will come later.


Jens Lauritsen
EpiData Association

More information about the EpiData-list mailing list