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

[Ian Haywood]

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

signature.asc
Description: OpenPGP digital signature