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 "bl


From: Ian Haywood
Subject: Re: [Gnumed-devel] unmatched [path] results (was tracking status of "blob" style path results)
Date: Mon, 14 Feb 2005 18:15:11 +1100
User-agent: Mozilla Thunderbird 0.8 (X11/20041012)

J Busser wrote:

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.
I disagree here. If the patient matches we should import so it becomes 
available straightaway.
I think it is reasonable to create new test_org (and org) entries based on what 
info in in the results file.
(labs may mis-spell a patient's name, but if they can't get the their *own* 
name right,
we have bigger problems than duplicates in test_org ;-)
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? 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?
I'm lost here, Either 1 of two situations exist:
        - the results format has enough metadata to allow us to infer (HL7), or
specifies a priori (?? LDT), what coding system is being used, in which case, 
yes, we can create new test_types easily
by matching coding system and codes in test_type_unified
        - we don't (pretty strange format), in which case we can't import these 
results at all until
test_type is manually filled with the codes of the coding system for that 
test_org. Adding a default codng
system still requires manual intervention, being really no harder/easier than 
populating test_type, but adds
another layer of complexity.

Ian


Ian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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