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:40:44 +0100
User-agent: Mutt/1.3.22.1i

> I (think I) understand you, but remain unclear how foreign key 
> dependencies for test_type, test_org and test_org's "identity" would 
> work.
> 
> On surface, people may think it *should* not happen that a test_org 
> is encountered for the first time during an import.
I don't think that. I check for it. If it occurs the data is
not imported and the user is notified.

> Therefore results would need to be written into unmatched results 
> *not only* if the patient cannot be uniquely identified, but also if 
> the test_org cannot be identified.
Yes. My importer does not import such files.

One could store a "foreign key" to *_unmatched into
housekeeping_todo.cookie and work from there.

> And if a test_type does not yet exist for that test_org, is it 
> reasonable to just create a new test_type from the result under the 
> assumption (hope) that the test_org's coding system has not changed? 
Yes. Perhaps notify the user.

> But since the test_type table *could* contain more than one coding 
> system per test_org, we can't know from the test_type table which 
> coding system should be used for any new test_types from that 
> test_org. Ergo our schema should into the test_org table add the 
> field coding_system_default for the purpose of dictating what should 
> be used for all new test_types written by the importer?
Our labs don't use any coding system at all. Hence that is a
non-mandatory field in the schema.

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]