Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results)

[Ian Haywood]

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