Regarding the new versions 1.4 of Manager and EntryClient.
Many changes have been implemented since first public release last year:
Common: * 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
Entry: * Implemented a "Copy Record to Clipboard" function, with variable format string.
Manager: * New improved drag/drop implementation (multiselect, copy/paste, alignment) * Double Entry Preparation/Validation * Improved Study Information form. * New improved export form, with more export formats. (SPSS, SAS, CSV, DTA, DDI) * 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 a 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.
b 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.
2 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 http://snd.gu.se/ddi/validator
3 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
regards Jens Lauritsen Epidata Association