July 2007 - EpiData-list - University of Manitoba Mailing Lists

Data entry only setup for EpIData Entry
by epidata-list＠lists.umanitoba.ca 20 Jul '07

20 Jul '07

Re: Is it possible to start Epidata Entry with "Enter data" For a system like that I suggest to add to the chk file the following: after file backup ..... see below quit end with the above, EpiData Entry will quit completely after performing a backup. Further on the backup: (copied from the help file) The syntax of the backup command is: BACKUP distination-directory or BACKUP distination-directory [ZIP zip-file-name [DATE]] or BACKUP distination-directory [ENCRYPT name-of-encrypted-zip-file password [DATE]] I usually prefer BACKUP distination-directory ZIP zip-file-name DATE Regards Jens Lauritsen EpiData Association

1 0

Re: EpiData-list Digest, Vol 45, Issue 6
by epidata-list＠lists.umanitoba.ca 19 Jul '07

19 Jul '07

Thanks for the help Jamie, it works just fine; I like the notoolbars option. -----Original Message----- From: epidata-list-request(a)lists.umanitoba.ca To: epidata-list(a)lists.umanitoba.ca Sent: Wed, 18 Jul 2007 7:01 pm Subject: EpiData-list Digest, Vol 45, Issue 6 Send EpiData-list mailing list submissions to epidata-list(a)lists.umanitoba.ca To subscribe or unsubscribe via the World Wide Web, visit http://lists.umanitoba.ca/mailman/listinfo/epidata-list or, via email, send a message with subject or body 'help' to epidata-list-request(a)lists.umanitoba.ca You can reach the person managing the list at epidata-list-owner(a)lists.umanitoba.ca When replying, please edit your Subject line so it is more specific than "Re: Contents of EpiData-list digest..." EpiData-list mailing list ___________________________________ Today's Topics: 1. Re: Is it possible to start Epidata Entry with "Enter data" (epidata-list(a)lists.umanitoba.ca) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Jul 2007 22:06:28 -0400 From: epidata-list(a)lists.umanitoba.ca Subject: Re: [EpiData-list] Is it possible to start Epidata Entry with "Enter data" To: epidata-list(a)lists.umanitoba.ca Message-ID: <469D75A4.5020506(a)sympatico.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed You can get most of this by doing the following: Make sure the Windows Toolbars option is to hide toolbars during entry (this is the default) Create a shortcut that has the command line "c:\program files\epidata\epidata.exe" "c:\data\file.rec" You can put "/notoolbars" on the end of that, but it may be better to set the options that way. Users can still turn on the other toolbars, but why would they? Everything needed for entry is there. Jamie > I would like to know if it is possible to force a data entry clerk to click on a short cut (which we can create and place on desktop) that would allow the user to only enter data without having access to the other data entry functions (e.g. check, data documentation, etc). This is to prevent the data entry person from chnaging anything with the data entry forms during the entry process. > > Shuaib > ------------------------------ ________________________________________ EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list End of EpiData-list Digest, Vol 45, Issue 6 ******************************************* ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

1 0

Is it possible to start Epidata Entry with "Enter data"
by epidata-list＠lists.umanitoba.ca 17 Jul '07

17 Jul '07

Dear Epidata Users, I would like to know if it is possible to force a data entry clerk to click on a short cut (which we can create and place on desktop) that would allow the user to only enter data without having access to the other data entry functions (e.g. check, data documentation, etc). This is to prevent the data entry person from chnaging anything with the data entry forms during the entry process. Many thanks Shuaib ________________________________________________________________________ AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.

1 1

RR in TABLES command
by epidata-list＠lists.umanitoba.ca 12 Jul '07

12 Jul '07

Regarding Pedro Arias' question Couldn't the default display for TABLES VAR1 VAR2 be NN at the 'a' cell, and YY for TABLES VAR1 VAR2 /RR ? best regards, Fúlvio ----- Mensagem original ---- De: "epidata-list-request(a)lists.umanitoba.ca" <epidata-list-request(a)lists.umanitoba.ca> Para: epidata-list(a)lists.umanitoba.ca Enviadas: Quarta-feira, 11 de Julho de 2007 18:00:51 Assunto: EpiData-list Digest, Vol 45, Issue 3 Dear all, I have a general question regarding the layout for the output of the TABLES command. In version 2 (112) the default option for TABLES is sorted in ascending order. That means that when using boolean fields TABLES will display N,N in the top left cell of a 2 x 2 table, because internally NO=0 and Yes=1. (Jens, is that correct?) When asking for RR (TABLES VAR1 VAR2 /RR) what we get is the RR of being N in the outcome if you are N in the exposure. Which is clearly the inverse of what we usually are looking for. But because most of the statistical/epidemiological software dispay the table in the other way (Y,Y on the top left cell) EpiData can misslead the users with its results. (obviously users should read the table, but...). And we have /SD as option to change that My question is: Should EPiData follow the general rule of displaying YY in the too left cell?. (and therefore calculating the RR that usually we are interested in) Jens has a point saying that if we change that when we are not interested in RR but only in the numbers and %, most of the program follow the rule of sorting the values in ascending order and that if we want to follow this rule we will need an EPITABLE command (in version 2 he is trying to get ride of innecesary commands). I think we alreday have the EPITABLE command, it is TABLES V1 V2 /RR I would appreciate if can comment on that. Version 2 is almost ready, but i think this is an important issue. Hope my explantion and question is clear. Thanks a lot, Pedro Arias EpiData Spanish cotranslator I am checking the entry in some files using the double entry verification. The data are from a family study so the unique identifying information is a family ID (4 digits), an individual ID (2 digits), and informant ID (in some cases, people will be reporting on others. Each data record, then, is uniquely identified by these 8 digits. I created a key for the entry check file as follows: rhinf RANGE 1 99 MUSTENTER after entry rhukey=famid*10000+indid*100+rhinf end END rhukey noenter key unique end This works fine to prevent entering the same record twice. I'm trying to use the variable rhukey as the match variable in the double entry program. I have intentionally entered non-matching data, but Epidata doesn't recognize any discrepancies. Is there a problem with a key that is created in the dbl file as well as in the original file? Thanks. Richard Herrell NIMH --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! I prefer the current method as there is no doubt about what the syntax means (lower values in top left unless you specify /SD) and the /SD switch provides a means of inverting the order. Many people code variables as 1=Yes 2=No, which gives a proper RR without the /SD switch. Many others use 0=No 1=Yes, which requires /SD. Since EpiData internally treats Booleans False as 0 and True as 1, the current approach allows programming that does not require exceptions. User help and guides should point this out. The TAB output clearly identifies the meaning of the RR, which is something a number of us requested. This is something that came into later versions of EpiInfo to help the user avoid misunderstanding. So no need for EPITABLE - just use TAB OUTCOME EXPOSURE /RR /SD Jamie > My question is: Should EPiData follow the general rule of displaying YY in > the too left cell?. (and therefore calculating the RR that usually we are > interested in) > > Jens has a point saying that if we change that when we are not interested > in RR but only in the numbers and %, most of the program follow the rule > of sorting the values in ascending order and that if we want to follow > this rule we will need an EPITABLE command (in version 2 he is trying to > get ride of innecesary commands). I think we alreday have the EPITABLE > command, it is TABLES V1 V2 /RR > ________________________________________ EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list ____________________________________________________________________________________ Novo Yahoo! Cadê? - Experimente uma nova busca. http://yahoo.com.br/oqueeuganhocomisso

1 0

Standard tables layout
by epidata-list＠lists.umanitoba.ca 10 Jul '07

10 Jul '07

Dear all, I have a general question regarding the layout for the output of the TABLES command. In version 2 (112) the default option for TABLES is sorted in ascending order. That means that when using boolean fields TABLES will display N,N in the top left cell of a 2 x 2 table, because internally NO=0 and Yes=1. (Jens, is that correct?) When asking for RR (TABLES VAR1 VAR2 /RR) what we get is the RR of being N in the outcome if you are N in the exposure. Which is clearly the inverse of what we usually are looking for. But because most of the statistical/epidemiological software dispay the table in the other way (Y,Y on the top left cell) EpiData can misslead the users with its results. (obviously users should read the table, but...). And we have /SD as option to change that My question is: Should EPiData follow the general rule of displaying YY in the too left cell?. (and therefore calculating the RR that usually we are interested in) Jens has a point saying that if we change that when we are not interested in RR but only in the numbers and %, most of the program follow the rule of sorting the values in ascending order and that if we want to follow this rule we will need an EPITABLE command (in version 2 he is trying to get ride of innecesary commands). I think we alreday have the EPITABLE command, it is TABLES V1 V2 /RR I would appreciate if can comment on that. Version 2 is almost ready, but i think this is an important issue. Hope my explantion and question is clear. Thanks a lot, Pedro Arias EpiData Spanish cotranslator

1 2

Longitudinal data validity checks
by epidata-list＠lists.umanitoba.ca 09 Jul '07

09 Jul '07

One very efficient approach for overview of consistency. E.g. counts of id numbers at various times is to use the "count by id" function in document menu of EpiData Entry. (or for batch procedures with EpiC). The idea is to count in different files how many times a unique identifier was found:. Example output: Count of records based on field ID Selected files: File 1 = key.rec File 2 = data\idkey.rec 120 different values for ID found Files ID 1 2 --------------------- 0 1 1 1 6 6 2 6 6 The key variable could as here be a simple integer, but could also be a string, e.g. of the type: 0-1 0-2 0-3 constructed as a combination of the id (here 0) and the time of visit (here either 1 2 or 3). In the check file: id mustenter end timevar comment legal 1 "Initial visit" 2 "6 months follow-up" 3 "2 year follow up" end mustenter after entry idkey = string(id) + "-" + string(timevar) end end idkey key unique noenter end ......................................... Notice that the "key unique" status for idkey is checked at creation of the contents, that is in the "after entry" block of the time variable. regards Jens Lauritsen EpiData Association

1 0

consistency checks on longitudinal data
by epidata-list＠lists.umanitoba.ca 09 Jul '07

09 Jul '07

Hello all, I'm setting up a multi-centre longitudinal study where data will be entered by health care workers with very little experience of research or possibly of computers. Every two weeks they will be visited by researchers. The data will be entered long, ie with one record for each time point. I need the data entry to be very simple, and the researchers will run consistency checks to find problems. Some things I want to do are: 1) check for duplicates on a few fields ( of course there is a unique ID - this would be to pick up duplicate data with different IDs) 2) check number of time points per patient ID 3) check dates are within range 4) check that date for time point 2 comes after date for time point 1 for the same patient ID I have used EpiData for entry for a few years but I haven't used Analysis. I would be glad of any advice. Thanks, Vicky Simms -- Vicky Simms Research Associate Palliative Care, Policy and Rehabilitation King's College London

1 1