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

[J Busser]

At 9:37 PM -0500 2/13/05, Ian Haywood wrote:
> I'm not sure why we have to have a two-step process. The importer
> can insert directly into lab_result if it finds a match, and
> unmatched_results when it doesn't. The user then comes along later, and
> through the GUI provides a match manually, the result is parsed 
> again and put in
> lab_result.

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. However I can 
easily imagine a small community lab (or a hospital lab) joining an 
established data clearinghouse to get medical results delivered. 
Alternatively your patient may newly attend a lab never previously 
attended by anybody in your medical practice so the corresponding 
test_org may not yet exist in your installation of gnumed. If by 
default, the importer (when it cannot find a match on test_org) 
creates a new test_org based on whatever test_org value 
(internal_name) is delivered in the fetched results, it will not be 
enough because test_org itself has an fk constraint from org and as a 
result the record should not be written because the owning org may 
not yet have been registered into gnumed.

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.

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?

>  > - matched results are further processed into test_result PROVIDED
> >  - - corresponding code, coding system (and test_org?) must exist in
> >  test_type
> >        (or the importer includes extra code to write/import defaults
> >         into test type, test_org and test_org's "identity")
> >  - matched originals are then deleted from staging table
> >  - unmatched results remain behind
> >  - code to deal with unmatched results is run BUT
> >  - - should it run on only batch most recently imported
> >        or on all unmatched results?