gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results)
Date: Mon, 14 Feb 2005 09:34:29 +0100
User-agent: Mutt/1.3.22.1i

> > > ...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".
Oh, I see the confusion. My importer imports results directly
into the real table. No staging table needed.

> Karsten, you mentioned with the German results you had "got gnumed 
> (nearly) working" perhaps only with sham data?
By now it is working with real data. It is just not deployed yet.

> You must have used a staging table outside the schema
No.

> 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?
Not on account of "somehow knowing" but on account of
"painstakingly checking" *during* ipmort.

> - staging table test_result_unmatched holds imported results
As you suggested I would not use the same table for staging
and for keeping unmatched results. If you really think you
need an extra staging table (I don't see why) we will add
that.

> - 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")
Well, some code needs to check this somewhere. So, an importer
can do this right away from the file to be imported.

> - - should it run on only batch most recently imported
>       or on all unmatched results?
unmatched results are, well, unmatched, which is the point of
the table, so, yes, it should run on all results in the table

Let's keep staging and unmatched separate.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]