- EpiData-list - University of Manitoba Mailing Lists

Out of the office
by epidata-list＠lists.umanitoba.ca 20 Aug '09

20 Aug '09

I will be out of the office starting 2009-08-19 and will not return until 2009-08-31. Though I will have access to email and will try to respond to correspondence, for urgent CFEP matters please contact Gisele Jolicoeur at 613-941-0709.

1 0

Trouble in export to SAS
by epidata-list＠lists.umanitoba.ca 20 Aug '09

20 Aug '09

Hello for my first post, In .recfile I had a numeric variable X like /_##_/ In SAS program I get .../... /INPUT X _1_/ etc... .../... that implies in the SAS table a variable like . (missing variable). On correcting with _/1-2/_, it works. Thanks for explanation. best regards, D

1 1

Status on EpiData developments (August 2009)
by epidata-list＠lists.umanitoba.ca 10 Aug '09

10 Aug '09

Dear all During the most recent year development has been focused on SPC methods in Analysis (SPC: Statistical Process Control graphs and analysis), but also directed towards the longer sustainability issue of converting all EpiData Software to Open-Source and a unified approach, including a new principle of translation (not put into practice yet). Such that regardless of variety (Entry, Analysis, EpiC) the same function will do the same. The other aspect is to run on several operating systems (linux, windows, Mac). A major break through in this respect was reached upon release of the first test version for Linux and Windows in May/June this year. In the near future (weeks/days) two aspects will become visible: a. Minor update of EpiData Analysis with key reported problems such as: Histograms (are essentially bar graphs until now), Parsing of varible names containing "if", Setting font size in graphs via dialogs b. Next step in the core project, where users can test the future "engine". The current and next release allows reading and writing of text files, including "intelligent" guessing of variable format. A new aspect is that decimal separator can be defined by the user. With a bit of luck also a Mac variant of the core module will appear in a few weeks (if no major problem shows up). The principle now is that known problems mainly are solved in the core project rather than a temporary solution in e.g. Analysis. The coming phases of development are expected to be: A - getting to the point where translation can be applied (the principle is visible - but not implemented fully at: epidata.info/asger3) - rewriting EpiC to use the core module - develop a batch testing principle for reading and writing files B - Inclusion of the new core in Analysis C - Development of a GCP/FDA part 11/EMEA (Good Clinical practice for US and EU officially approved data entry) compliant data-entry client. The GCP principles will follow guidelines as shown on the European Clinical Network research ECRIN - page and published by an international working group in which I was a member, see http://www.ecrin.org - publications and find: GCP-compliant data management in multinational clinical trials. ECRIN-2, Deliverable D10, Version 1, 15 September 2008. In between these aspects some further development of Analysis and other products (Entry and EpiC) will take place, but focus will be on getting it all together on the new core to ensure sustainable development. Actually the current year marks a decade since first relase of EpiData Software and the autumn might contain special activities to celebrate this. I should mention that the project as a whole could not have been completed without the efforts of donors, the user base, the critical input, the specific work of people involved (see www.epidata.dk/credit.htm) . In particular for the rewriting focused donations from a number of institutions mentioned on the www.epidata.dk/funding.htm page has been essential. Such that full time employed Torsten Christiansen has been extended beyond the first year to a full two year period. Without the skillful efforts of Torsten in the first year leading to funding for a second year the whole rewriting would not be possible. I could also add, that without the thorough programming efforts by Michael Bruus in Entry and EpiC in the first ten years the rewriting would also not be possible in a two year period. The coming year again seems to give the EpiData Society as a whole (users and developers) another fruitful season. Warm Regards to all Jens Lauritsen Coordinator and initiator of EpiData Project http://www.epidata.dk

1 0

Access violation
by epidata-list＠lists.umanitoba.ca 07 Aug '09

07 Aug '09

Hello, I created a data entry system for a project which includes five relational databases. When we open EpiData and choose "enter data" all of the screens open, but we get the following message: Access violation at address 00464077. Write of address 0000000C I will appreciate any help I can get on this issue. Thanks, Regina Harders

1 1

date field: check fails
by epidata-list＠lists.umanitoba.ca 07 Aug '09

07 Aug '09

Dear all, I'm just starting to use epidata entry so I have probably overlooked something. Any pointers are appreciated! I defined a date field as follows in the .qes file: DOB date of birth <dd/mm/yyyy> in the .rec file I added the following sanity check: DOB MUSTENTER AFTER ENTRY IF ((year(DOB) < 1900) OR (DOB > TODAY)) THEN HELP "This date is not allowed" TYPE=ERROR CLEAR DOB GOTO DOB ENDIF END END Most of the time the field behaves as I expect it to: dates in the future or far in the past are not allowed. However, the following typo gets accepted without triggering an error: 05/08/20001. Adding an extra trailing zero (05/08/200010) results in a prompt conversion to 05/08/3402, and the sanity check works again. Some experimentation seems to confirm that values between 20000 and 20099 are accepted as valid for year, bigger values trigger either my check or are converted to some weird value, again triggering the check. How can I prevent this from happening? thanks in advance, Peter version info: epidata v3.1 (270108), on windows XP.

1 4

Limit on number of .rec files that can be RELATEd
by epidata-list＠lists.umanitoba.ca 17 Jul '09

17 Jul '09

Dear EpiData users, It appears as if there is a limit of 30 .rec files that can be linked together in a relational structure for data entry using the RELATE command. Am I mistaken or is there any work around for this? I have 29 files linked to a single "master" file and I need to be able to relate 2 more files to this first file for data entry to work well. Thank you in advance, Emilie

1 1

Re: Negative integer
by epidata-list＠lists.umanitoba.ca 15 Jul '09

15 Jul '09

Thak you guys, setting the field to ## worked fine! Best regards, Abraço forte e que a força esteja com você, Pedro Brasil

1 0

negative integers in epidata entry
by epidata-list＠lists.umanitoba.ca 15 Jul '09

15 Jul '09

Dear EpiData friends, I have a qes like this days NUMBER OF DAYS WITHOUT MEDICINE IN THE PERIOD ## However the ones who filled the CRFs filled this with -1 if there was no information about this question. Now Im testin the entrys to start feeding the datasets and just realize that -1 is not a legal integer for field # I thought that converting this field from # to <A > would work and later in the analysis to encode this variable to integer. WOuld this work? any more elegant workaround? Best regards, Abraço forte e que a força esteja com você, Pedro Emmanuel

1 3

creating an identifiant from various variables + double data entry
by epidata-list＠lists.umanitoba.ca 10 Jul '09

10 Jul '09

Dear Jens, Thanks for your helpful comment on creating an identifiant from various variables and double data entry (see below). I just wanted to clarify a few things: 1) Does this mean that when using the 'Double Entry Verification' option (immediate comparison), this will not work if you have added any new variables into the .rec, or changed the order of the variables from the existing .rec? 2) If you use the other method of data verification (entering data into two seperate files and then validating duplicate files afterwards), is it possible to compare the old and new .rec files, even if a new variable has been added, or the order of the variables has been changed? Will using the 'validate duplicate files' option work if the new .rec file has the variables in a different order? Thanks so much for all your help, Nicki Bailey One aspect of this about unique identifiers is when users want to do double entry. The only double entry option in this situation is to enter the data twice and then compare afterwards, since the "immediate comparison" double entry mode is not available for combined field unique entries unless the records are entered in EXACTLY the same sequence as the first time. The problem for the user is, that the system is NOT giving correct warnings in the immediate double entry if the unique index is created in contrast to entered directly. > I would like the identifier to be automatically created in the .rec > file after entering 4 variables and as an aggregation of these 4 > variables. > For instance my identifier is > ID=region number+village number+household number+member in the > household number regards Jens Lauritsen EpiData Association

1 6

Is it possible to link the follow-up to the baseline using EpiData?
by epidata-list＠lists.umanitoba.ca 30 Jun '09

30 Jun '09

Dear all, I have a question about linking the follow-up round of a survey to the baseline which was data entered using EpiData. The follow-up is a new database that will be linked to the baseline during analysis. During data entry, I want to make sure that the IDs entered in the follow-up match those from the baseline in the household roster of the survey. No member that was in the household in the baseline should be missing, however new members can be added to the household. I have villageid, householdid, and personid, each of which is entered separately. I can then create a unique id which combines these to ID the unique individual. The baseline data was entered using double data entry where the data was compared dynamically (Menu Option: "Double Entry verification") and the follow-up will be done in the same manner. The survey is large and the data are entered on several different computers that are not networked. The only way I can think of to link the follow-up to the baseline in order to compare the IDs would be to do a mini double data entry after the first data entry of the household roster where I check only the IDs for the data and see what is in the follow-up that isn't in the baseline, but this seems like a poor solution. I would prefer to do something dynamic, which 1) doesn't allow the data entry clerk to move on to another household until they have entered all of the IDs from the baseline and 2) flashes a warning if there is an ID entered that does not match with the baseline. I don't think that EpiData has these capabilities. Please let me know if I am simply not educated enough in this software. Thank you for your help (and I apologize for this long posting). Emilie

1 3