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

[J Busser]

At 8:30 PM +0100 2/13/05, Karsten Hilbert wrote:
>  > Or in fact, would people import fetched results into a staging table
> >  and should this table be part of the schema?
> This table was thought to *be* the staging table.

>  > ...we are really taking about the records that are
>  > "leftover" from the staging table after being unable to be matched?
> Well, sure, that's precisely the point. The importer imports
> and whatever it can't match to a patient is dumped into the
> *_unmatched table.

The above ambiguity is what I was looking to resolve. The same table 
cannot (?) be the one into which results are initially imported, if 
it is also to be the table that unmatched results are "dumped to".

Karsten, you mentioned with the German results you had "got gnumed 
(nearly) working" perhaps only with sham data? You must have used a 
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?

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?


> It *is* part of the schema already. I tried to set up the fields
> such that they might be a reasonable attempt at matching
> any test results.

and an excellent first start.