On Mon, 2003-06-30 at 14:57, Tim Cook wrote: > For those healthcare providers not on the TORCH list I wanted to point > out this effort by Dr. Maynard. >> I want to ask about a barrier to initial impression of TORCH that >> I recall as a newcomer to TORCH and which is also a barrier to >> thorough testing of the modules. There are not enough realistic >> patient EMR entrees in the demo, nor enough with multiple >> encounters and completed encounters. > > If this effort is successful I will develop a method to export these > records into a file that can be used by other projects that need this > kind of data.
1) In the Febrl probabilistic record linkage suite (see http://febrl.sf.net) we have a little utility to synthesise names and addresses (with or without duplicates with random errors). It could readily be adapted to furnish alrge numbers of plausible sounding but fictitious patient identities, and teh technique could be extended to clinical as well as demographic data. I have just used it to generate 100,000 cases to do some initial stress-testing of the public health application on which we are working: user interfaces which were fine with 10 or 20 test cases suddenly don't seem so great with 100,000 cases...for things like TORCH or GnuMed, testing with 10,000 or 20,000 patients would not be unrealistic - and better to discover scalability problems (with the user interface as well as the underlying database and application technology) with dummy data than with real life data. 2) There are two ways to get such data into the application: import it directly into the underlying database, or automatically injecting it through the user interface, possibly using multiple workstations at once to simulate real-life load and to check for multi-user issues. For Web-based applications, the following looks like it may be useful - agian, we intend to investigate it for testing our public health app: http://wwwsearch.sourceforge.net/ClientForm/ 3) Shareable EHR/EMR test data requires a shareable format which captures the relationships between dta elements. XML is teh obviousl choice, but it would be nice if the format was more readily humna-readable and -writable. YAML (see http://yaml.org) might be a good choice. 4) Which raises the issue of the appropriate (as generic as possible) schema/data model for such test data. Are there candidate schema available - for example, what schema would be required by TORCH? -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0
signature.asc
Description: This is a digitally signed message part
