- EpiData-list - University of Manitoba Mailing Lists

Asymmetric limbs of Confidence Interval - clarification
by epidata-list＠lists.umanitoba.ca 16 Feb '11

16 Feb '11

Please see below the table generated in Epidata analysis and note the confidence interval in the first row HIV results Total 1539 108 7.0 (5.8-8.4) This is the proportion of HIV infected among a group of TB suspects which is 7% with 95% CI being 5.8 - 8.4. It can be deduced that the upper limb of confidence interval(which is 1.96 times Standard error) is 8.4 minus 7 = 1.4 Similarly, it can be deduced that the lower limb of confidence interval(which is 1.96 times Standard error) is 7 minus 5.8 = 1.2 *Query - why are the two limbs of the confidence interval different?* the same observation can be noted in all CIs noted above in the table. The asymmetry of limbs of CI are expected in case of non-linear measures like Odds Ratio, Relative risk, Hazard Ratio etc, but not in case of simple proportions. I am given to understand (from Dr Hans Reider, from whom I learnt Epidata) that EpiData Analysis is purported to follow the recommendations by the BMJ in the calculation of most confidence intervals and this would indeed suggest that the CI around a proportion should be symmetric on a linear scale. Would be grateful if you could clarify. Regards, Ajay -- ****************** Dr. M. V. Ajay Kumar WHO National Consultant - RNTCP Central TB Division, MOHFW 523'C' Wing, Nirman Bhavan, Maulana Azad Road, New Delhi - 110108 Mail - No. 353-C, J&K Pocket, Dilshad Garden, Delhi - 110095 Phone : +91-9311384574 Email : Kumaramv(a)rntcp.org;

1 2

Technical details of test release
by epidata-list＠lists.umanitoba.ca 15 Feb '11

15 Feb '11

Dear All Today we have released new test versions of EpiData EntryClient and EpiData Manager. This email is mainly technical and will give broad view of changes and additions to the two programs. Important aspect: flow of entry. On a normal entry of fields, the flow is defined as moving from field to field in a left-to-right, then down, manner – but at the same time following sections. Once inside a section this section will be completed before exiting. This should simulate a normal work flow working with schemes/registration forms. The flow of entry is followed if you leave the field in a "standard" way. Standard ways are: "The entire length of the field is filled" or by using one of the following keys: ”Arrow down”, ”Enter” or ”Tab”. These keys are "flow of entry keys" and should be used during data entry. To break the flow of entry (not recommended) : Either use "Arrow Up" key, the mouse or enter a legal value and then avoid saving the record. We note "not recommended" since a field could have some attributes set that defines another flow of entry, e.g. a jump. The programming is handled in three "parts": A common core, EntryClient and Manager. Any change to the Core module will affect the two other parts: *Changes for Core*: * Define jumpsfor a field. Changes the flow of entry (see above) and rules for resetting field data. (leave as is, blank, add defined missing) * Define Entry Mode for a field. The possible (mutually exclusive) attributes are: Default Entry, Must Enter or No Enter. * Define Confirm Entry. This will force a user to confirm the entry using a key (see below). * Define Show Value Label. Show category text for a given entered value next to the field (right side) (formerly known as comment legal show). * Various bug fixes, including incorrect import of dates from Stata files and definitions of "missing" status of a Value Label. Changes for both programs: * Added a check such that programs can only be started once (single instance). * The programs now check that the active project file has not been modified between saves. * Added short-cuts to the 9 most recent files: Ctrl + Shift + <number> * Shortcuts for Mac OS X have been changed to follow the native style of the OS. * Adapted setup and properties for the new options Changes for Manager: * Hides Work Process Toolbar when a project is active. * Assign jumpsto field. One or more jumps may be assigned to a field. * Added the ability to "copy & paste" field/heading/sections on the designer. - A section can be copied to the main section. - Copying a section will also copy fields/headings within that section. - Fields/Headings can be copied to/from sections (including main section). - Field attributes can be copied from one field to another of same type. * "Tab" key should now work as "change cell" key on the Value Label Editor. * Value Label Editor modified. * Flyspray bugfixes: 71, 72, 73 Changes for Entry: * AutoIncrement (Formerly IDNUM) fields can start at a defined value * User specified Colour for errors * Enhanced control of focus for active field. * Fixed several bugs - including loading of corrupt/invalid files Kind regards, Torsten Bonde Christiansen Jens Lauritsen EpiData Association.

1 1

re: Double Entry failed when AutoSearch is enabled, Does this bug fixed?
by epidata-list＠lists.umanitoba.ca 13 Feb '11

13 Feb '11

> On 2011-02-13 08:55,epidata-list at lists.umanitoba.ca <http://lists.umanitoba.ca/mailman/listinfo/epidata-list> wrote: > >/ Hi, I have struggled with a problem that: > />/ When I use the double entry real time verification, I can only do the > />/ verification on the first record, When I entering a second record, the > />/ verification is Disabled. > /Obviously this was not a pleasant experience for you. But the struggling > tells that you tried various ways - which is always a good thing. > Unfortunately there are not many things in project work and research > which works in a simple way - at least not the first time one tries. Thanks for your reply and a warn encouragement. > Only for files with a unique identifier that you YOURSELF enter during > the entry - and provided this field have the "Key unique" setup will the > verify during entry work. It is obvious that if there is no unique key - > then the software will have no way of knowing which record from the > first entry to compare with. Your logic of using "autosearch" is fine in > general, but is too complex in the double entry situation. Here are my considerations (sorry if I not fully understand your statement as my English is not quite good:-) ) Generally, there are two kind of "double check": 1, we entered two rec files separately and independently, then use the Menu->document->Validate duplicate files, this checking is "off-line mode". 2, I entered one rec file, and cread a _dbl.rec file by Menu->Tools->Prepare double entry verification. Then just opened the _dbl.rec file, and entering records, so this is "double entry verification in real time mode". So, when I want to do "double entry in real time", I must: 1, use Key unique feature on some/one field 2, do not use "autosearch" right? > As such I do not know of any bugs in relation to double entry and > verification, but some requirements/limitations (possibly not well > documented) are needed: > > A. If you use<idnum> fields in your system then: > make a copy (copy structure in tools menu) of your system and > INDEPENDENTLY enter data the second time. Following the second entry do > the validation in the documentation menu. > B. If you use a combined key for your "unique identifier": > e.g. mykey = idnum+var1+var2 > or mykey = string(idnum) + string(var1) + string(var2) > then do as in point A > C. If you are using a related file system > then do as in point A > D. based on your experience we can add : If using autosearch > then do as in point A The method A,B,C,D you give is all about the way in "off-line mode", right? I'd like to say that: I prefer "double entry in real time mode", as I think it is much convenient to do the verification while entering. Zhang Yuanhui China

1 0

Double Entry failed when AutoSearch is enabled, Does this bug fixed?
by epidata-list＠lists.umanitoba.ca 13 Feb '11

13 Feb '11

Hi, I have struggled with a problem that: When I use the double entry real time verification, I can only do the verification on the first record, When I entering a second record, the verification is Disabled. I have struggled this problems for nearly two days by trying to narrow the problem, then finally I found that if I remove the "autosearch" function on my ID field (which is the matching key on the double entry verification), then everything works fine. Finally, I search by keywords "autosearch double entry" on this maillist, and found there is an announcement by the official author in this post: (it was in year 2006) http://lists.umanitoba.ca/pipermail/epidata-list/2006q2/000430.html They said: ------------------------- Double Entry and Autosearch: Danger!....... ------------------------- Now, I'm using the latest official release version, which is v3.1 (28jan2008). I also check the mantis system, I don't find anything related to this bug. http://www.epidata.dk/php/mantis/view_all_bug_page.php So, Still, my question is: Does this bug fixed? It seems this bug still exists in the v3.1 (28jan2008). Thanks Zhang Yuanhui China

1 1

next test version ready
by epidata-list＠lists.umanitoba.ca 11 Feb '11

11 Feb '11

Dear all As announced previously a new test release will be available today. A follow-up mail on the technical issues of the new versions will come when upload of the new software has taken place. Address will as usual be http://www.epidata.dk/testing.php The main new as pects are implementation of jumps, mustenter and a revision of the interface, plus handling of a number of reported bugs and those found in our own testing. Questions in relation to this or comments can be given: a. general ones to this list b. bug reporting to flyspray or this list as usual. c. specific questions or information on further funding possibilities to info at epidata.dk. The mails will be read, but you receive an automail telling of "do not expect a response". The following week Torsten Christiansen and I will attend to an APHEO seminar in Canada. The use of the software in field settings is the prime driver for developments. Torsten Christiansen is responsible for the software architecture, design and programming in collaboration with me. Further information on the seminar, see: http://www.apheo.ca/index.php?pid=47#2011 regards Jens Lauritsen Initiator and Coordinator EpiData Assocation, Denmark

1 0

Can't enter to flyspray bug tracking
by epidata-list＠lists.umanitoba.ca 10 Feb '11

10 Feb '11

Hello: If someone can help me with this, I would appreciate it. Read below. ---------- Mensaje reenviado ---------- De: Omar Bautista González <omarbautistag(a)gmail.com> Fecha: 28 de enero de 2011 18:56 Asunto: Can't enter to flyspray bug tracking Para: info(a)epidata.dk, Manager <flyspray(a)epidata.dk> Hello: I'm testing the GNU/Linux of EpiData Manager and Entry. There are some things that I want to report and the mailing list is not the best instrument to do that. I tried to suscribe to http://www.epidata.info/flyspray/ at the 17 of january (2011). I also tried today without success. Maybe is because the project admin must approve my account. I'm not the best English speaker, but I'm learning to help and other reasons. I speak spanish. My user account is RadicalLibre. Regards, -- Omar Bautista González - Colaborador en autogestión comunitaria desde República Dominicana -- Omar Bautista González - Colaborador en autogestión comunitaria desde República Dominicana

1 2

Epidata Analysis and cluster sampling
by epidata-list＠lists.umanitoba.ca 08 Feb '11

08 Feb '11

Hello, I would like to know if there is a way to analyze our data from a vaccination coverage study, in which we used *cluster sampling*, using Epidata Analysis. As far as I know, Epidata Analysis by default gives proportions and confidence intervals assuming for simple random sampling. Thank you in advance, Dimitris Papamichail National School of Public Health, Greece -- ------------------------------------------------------------------------------ Δημήτρης Παπαμιχαήλ Dimitris Papamichail 213 2010 153 dpapamnos(a)gmail.com ------------------------------------------------------------------------------

1 1

next test version - and a question on principles of updating auto-date and auto-time fields
by epidata-list＠lists.umanitoba.ca 08 Feb '11

08 Feb '11

Dear all Developments are continuing and many new aspects will be available in the next test release of the Manager and EntryClient software, e.g.: - revised value label definitions - range - mustenter, confirm, noenter - show value labels after entry (formerly known as : type comment) - jumps which can be to: "skipnextfield", "end of section", "save record" and to a named field the fields bypassed can be reset to: "no change", "system missing", "highest defined missing value", "next to highest defined missing value". Release of the next test version is expected within a few days. More information will be shown at the time of release. With this implementation we are very close to the functionality needed by most users in terms of data-entry. On top of that functions for searching in data and documentation will come. One aspect which we would like some input on, is the following: In the current EpiData Entry for windows we have: auto-id (<idnum>) and today fields which are updated at the time of SAVING data. In the current Manager and EntryClient the Auto-data, and auto-time fields are getting a value upon creation of the record. Not at the time of saving first time or editing the record. Please indicate preference: a. We only need auto.date and auto-time fields having value at saving records b. We only need auto.date and auto-time fields having value at creation time c. It is preferable to have a combination of a and b, where the user specifies for a given field which of the two properties these fields should have. regards Jens Lauritsen EpiData Assocation

1 2

EpiData in Vietnam
by epidata-list＠lists.umanitoba.ca 26 Jan '11

26 Jan '11

I'll be running a course in Vietnam on questionnaire design and data management. As part of the course I'm thinking of adding a session on EpiData. Can anyone answer the following question: How do people in non-English speaking countries manage with EpiData? I don't mind the menus being in English because a translation of the menus into Vietnamese can be handed out to participants. What may be an issue is entering Vietnamese characters into the QES file and text fields. If Vietnamese characters are entered into the QES file, will they be displayed in the REC file? Also can field names contain Vietnamese characters or must these be English letters? Also, what is the forecast for the release of EpiData Manager and EpiData EntryClient in the completed stage, i.e. with checks and GCP in place? Regards, Suzanna Vidmar Senior Research Officer Clinical Epidemiology and Biostatistics Unit Murdoch Childrens Research Institute Royal Children's Hospital Flemington Road Parkville Victoria 3052 Australia telephone: +61 3 9345 6372 facsimile: +61 3 9345 6000 email: suzanna.vidmar(a)mcri.edu.au www.mcri.edu.au <http://www.mcri.edu.au/>

1 9

Testing GNU/Linux version
by epidata-list＠lists.umanitoba.ca 17 Jan '11

17 Jan '11

Hello: I'm now testing the linux version of EpiData Manager and EpiData Entry. The following suggestions would be useful: 1) When copy/paste of a text from an UPPERCASE field to a lowercase field it would be nice to automatically convert the text case on the destination corresponding field. 2) When importing from rec files the conversion don't reflect the rec created before on the stable version of EpiData. There are some differences between the names of the fields. Only a few labels appears and the ranges of inputs doesn't appears. 3) It would be great to finish the interface of the check commands and later the RELATE function for relational databases. 4) For future translations it would be good to build an interface, as stable EpiData has. Just with a file containing the translation in cuestion would be an easy alternative. Although, when EpiData will be released under Open or Free philosophy of source code, the translations can be done directly. I can help on a Spanish version on both scenarios. 5) As someone told on other moment an interface with other statistical analysis package would be great, as the R Statistical Computing. Also the new GPX or GPZ files will need interfaces to communicate with R, with the "foreign" package under R. Great job! Att. -- Omar Bautista González - Colaborador en autogestión comunitaria desde República Dominicana

1 0