On Sun, Feb 13, 2005 at 01:52:01PM -0800, J Busser wrote: > At 8:30 PM +0100 2/13/05, Karsten Hilbert wrote: > staging table outside the schema (now included?), or did you import > directly into test_results on account of somehow "knowing" that the > fk constraints in test_type and test_org would be met? I suspect it would just throw an error if it can't match to a patient. (this is proably rarer than it would be in Australia) > Would it work thus: > > - staging table test_result_unmatched holds imported results > - matched results are further processed into test_result PROVIDED > - - corresponding code, coding system (and test_org?) must exist in > test_type > (or the importer includes extra code to write/import defaults > into test type, test_org and test_org's "identity") > - matched originals are then deleted from staging table > - unmatched results remain behind > - code to deal with unmatched results is run BUT > - - should it run on only batch most recently imported > or on all unmatched results? I'm not sure why we have to have a two-step process. The importer can insert directly into lab_result if it finds a match, and unmatched_results when it doesn't. The user then comes along later, and through the GUI provides a match manually, the result is parsed again and put in lab_result.
Ian _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
