> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
