EpiData-list November 2014

epidata-list@lists.umanitoba.ca

1 participants
8 discussions

Re: EpiData-list Digest, Vol 132, Issue 7

by epidata-list＠lists.umanitoba.ca

Check for update would be a good idea However, it could be done as Check for update now, or Check for update in a week or next time when EpiData is launched. Kind regards Tieble On 22 November 2014 at 18:00, <epidata-list-request(a)lists.umanitoba.ca> wrote: > 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: automatic warning/information on versions ? > (epidata-list(a)lists.umanitoba.ca) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 22 Nov 2014 13:02:09 +0100 > From: epidata-list(a)lists.umanitoba.ca > Subject: Re: [EpiData-list] automatic warning/information on versions > ? > To: epidata-list(a)lists.umanitoba.ca > Message-ID: > < > CAGCnkGU66_DiM0mdvC0ruoaNuSUndFgMXdjQ5EgXGdYBQR6n4Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi Jens > > This option sound good for me :) > As ouy say, many users are not listening the list. > > Regards > Gilles > > > > > > > *Dr Gilles DESVE Epiconcept consultant Mobile : 33 (0)6 87 73 50 88 Fax : > 33 (0)9 72 12 20 81 * > > 2014-11-20 23:51 GMT+01:00 <epidata-list(a)lists.umanitoba.ca>: > > > I would like this option, Jens. It is very commonly used - along with a > > preference to NOT check for updates. > > Jamie > > > > On Nov 20, 2014, Jens wrote: > > > > > We could therefore consider to have the end user decide an option > saying > > "check for new version every x days" (e.g. x could be 7). Please give > > viewpoints and considerations on this. > > > > > > > _______________________________________________ > > EpiData-list mailing list > > EpiData-list(a)lists.umanitoba.ca > > http://lists.umanitoba.ca/mailman/listinfo/epidata-list > > > > > ------------------------------ > > ________________________________________ > EpiData-list(a)lists.umanitoba.ca > http://lists.umanitoba.ca/mailman/listinfo/epidata-list > > > End of EpiData-list Digest, Vol 132, Issue 7 > ******************************************** >

8 years, 10 months

automatic warning/information on versions ?

by epidata-list＠lists.umanitoba.ca

With development of the software new versions are released every time development has reached a certain point. It can be annoying to be informed very often about new releases from software, since this takes time and processor and sometimes also for users costly Internet connections. On the other hand we know that some users run into problems due to NOT having updated to a newer version in which a given problem was solved. We could therefore consider to have the end user decide an option saying "check for new version every x days" (e.g. x could be 7). Please give viewpoints and considerations on this. Also I noted today that some "semi-comercial" sites most likely running from the advertisements on that site offer download of the software . The webplace in question have been contacted by me. If we have automatic checking with reference to the true EpiData website, that problem would be minimized . Is this a desired option or does it work fine with the users getting information from this list in general ? . We know the list have about 700 persons "listening", but the number of actual users is very much larger and these other users do not easily know that there is a new version around. regards Jens Lauritsen EpiData Association

8 years, 10 months

Default behaviour in EntryClient during entryentry - and simplification

by epidata-list＠lists.umanitoba.ca

The next test build of Manager and EntryClient will be released rather soon, but not this week. The aspects we are working on - apart from securing stability - regards handling complex relational entry. To do so properly and with sufficient stability accross projects, operating systems and countries we need to be very focused on the niche in which EpiData Software is working. This demands some simplifications, which will be seen in the next test release: 1 backup after entry: Until now the backup files (e.g. Clinical_Example_2014-10-28_0.epz) would be placed in the "home" dir of the EntryClient user (e.g. for user jla = c:\documents and settings\jla\documents\EpiData\backup) . This resulted in a complex demand to handle a large number of combinations of operating systems and user rights. >From now on the backup file will be placed in a subfolder to the folder where EntryClient opens a given epx/epz file for entry. If the user want the backup placed in another folder this must be defined with a startup option. 2 Which status of addition/editing of records in EntryClient Aspects of this has been defined in preferences for EntryClient. >From now on EntryClient is assumed to be adding records to projects always. But obviously in such a way that if a given dataform has a key and that key is typed in, then the user will be informed and given the opportunity to jump to the relevant record. 3 For related systems the order of activation of "child" forms is part of the project epx file. Not a "preference" setting. This might seem a bit technical, but is needed in order to make sure that the software creates consistent data and also that we can complete the work within the funding of the project. Funding is always an issue for this and other development projects. Comments to this or other aspects of development are welcome. regards Jens Lauritsen EpiData Association

8 years, 10 months

Help

by epidata-list＠lists.umanitoba.ca

HI, I am very new to EpiData and am looking to use it for a Study which will require a relational database ie one study participant with multiple visits and tests Am I right in interpreting that only EpiData Classic Entry 3.1 is the only software that I can currently use. I have had a trial run using EpiData Manager 2.0.0.1 and it seems perfect for our study. Is it worth holding off setting up my database for the beta release of this version? When is it likely to be released? Kind regards, Emma Emma Jamieson ORCHID Study SouthWest Coordinator RCSWA - UWA Building 3, Edith Cowan University, Robertson Drive, PO Box 412, BUNBURY WA, 6230 Ph: +61 8 9722 0510 M: 0478 193 116 F: +61 8 9722 0555 -----Original Message----- From: epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] On Behalf Of epidata-list-request(a)lists.umanitoba.ca Sent: Friday, 7 November 2014 2:01 AM To: epidata-list(a)lists.umanitoba.ca Subject: EpiData-list Digest, Vol 132, Issue 3 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. Status testversions of 2.0 Manager and EntryClient (epidata-list(a)lists.umanitoba.ca) ---------------------------------------------------------------------- Message: 1 Date: Wed, 05 Nov 2014 21:13:16 +0100 From: epidata-list(a)lists.umanitoba.ca Subject: [EpiData-list] Status testversions of 2.0 Manager and EntryClient To: EpiData-list(a)lists.umanitoba.ca Message-ID: <545A84DC.30204(a)epidata.dk> Content-Type: text/plain; charset=utf-8; format=flowed The status and reported problems in the development of v2x of Manager and EntryClient is such that: a. Basically we find rather stable function with few access violations and remaining major problems b. We found reason to further change the xml structure contained in the epx file when dataforms are in a relational structure. This means that examples you have worked with in the testing of v2x might not work, when we release the next test build. c. A number of minor points have been found in various parts of the system. Mostly these were of text formulations, which had not taken the relational dataform aspect into consideration. I expect that the next test version will be moving from experimental level to pre-release level. This is an indication that we are approaching something which in the end will be applicable for true data entry and documentation. Further thoughts and reports of or examples of malfunction are highly appreciated. Jens Lauritsen EpiData Association, Denmark ------------------------------ ________________________________________ EpiData-list(a)lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list End of EpiData-list Digest, Vol 132, Issue 3 ********************************************

8 years, 10 months

Merging two rec files

by epidata-list＠lists.umanitoba.ca

Dear EpiData users and experts I am trying to merge two files with different number of records and fields! The first file (intake) contains 1433 records and there is 21 fields in each record. The second one contains 1301 records and and each record contains 31 fields. Each one of the 1301 record has a corresponding record in the first file (same code). I would like to merge the two files, based on the code, so that I have a third file with 1301 records and 52 fields. I tried to use the merge function in EpiData Entry, but it didn't work (the product was a file with only 47 fields instead of 52 ). I must say that some fields in the two files have the same name-can this be a reason for not merging these fields? Your help will be highly appreciated Best, MK

8 years, 10 months

Status testversions of 2.0 Manager and EntryClient

by epidata-list＠lists.umanitoba.ca

The status and reported problems in the development of v2x of Manager and EntryClient is such that: a. Basically we find rather stable function with few access violations and remaining major problems b. We found reason to further change the xml structure contained in the epx file when dataforms are in a relational structure. This means that examples you have worked with in the testing of v2x might not work, when we release the next test build. c. A number of minor points have been found in various parts of the system. Mostly these were of text formulations, which had not taken the relational dataform aspect into consideration. I expect that the next test version will be moving from experimental level to pre-release level. This is an indication that we are approaching something which in the end will be applicable for true data entry and documentation. Further thoughts and reports of or examples of malfunction are highly appreciated. Jens Lauritsen EpiData Association, Denmark

8 years, 10 months

Re: EpiData-list Digest, Vol 132, Issue 1

by epidata-list＠lists.umanitoba.ca

8 years, 11 months

Epola Contact tracing and risk assessment system

by epidata-list＠lists.umanitoba.ca

Hello List, As a District Medical Officer, I will have to prepare for Contact tracing and risk assessment/managing the follow-up of contacts if an unsuspected Ebola case should surface in my community. I have started to think of a call center / health care registration system in EpiData Manager with relate feature: One event/Index case, several contacts with contact details, and follow-up details of contacts. In the event that one of the contacts should develop symptoms, then the secondary case´s contacts will have to be traced. The design of the system certainly needs some consideration. This is a global concern, and I imagine several organizations probably already have made or have plans to develop such a system. EpiData´s share-friendly approach should be ideal under current circumstance. ECDC have already done so for food/waterborne outbreak investigation. 1. Anybody already made a system, wiling to share? 2. Any major Organization seeing the benefit of same-format reporting, and willing to support development of system/templates? 3. I assume that final release of ED 2.0 with relate feature is imminent. I therefore start to work on a functional but simple local system anyway, and will seek advice from the list as needed. Where I am right now, I struggle to carry the content of more than one unique key variable over from the parent to the child record. Any comments? Best regards, Vegard Hoegli District Medical Officer Skien, Norway

8 years, 11 months

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

EpiData-list November 2014