[Top][All Lists]
[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
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), (continued)
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), Karsten Hilbert, 2005/02/15
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), J Busser, 2005/02/14
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), Karsten Hilbert, 2005/02/15
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), J Busser, 2005/02/15
- Re: [Gnumed-devel] unmatched [path] results, J Busser, 2005/02/15
- Re: [Gnumed-devel] unmatched [path] results, Karsten Hilbert, 2005/02/16
- [Gnumed-devel] housekeeping_todo (was: unmatched [path] results), J Busser, 2005/02/15
- [Gnumed-devel] Re: housekeeping_todo (was: unmatched [path] results), Karsten Hilbert, 2005/02/15
- [Gnumed-devel] logging (was: unmatched [path] results), J Busser, 2005/02/16
- Re: [Gnumed-devel] logging (was: unmatched [path] results), Karsten Hilbert, 2005/02/16
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results),
Karsten Hilbert <=
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), Karsten Hilbert, 2005/02/14
- Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results), Karsten Hilbert, 2005/02/14
Re: [Gnumed-devel] tracking status of "blob" style path results, Karsten Hilbert, 2005/02/07