Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message

[Jim Busser]

On 2010-08-13, at 2:31 PM, Luke Kenneth Casson Leighton wrote:

> * lab sends an update obsv.report, with _again_ the same damn
> completely wrong but manually-identifiable patient name.

but in the meantime we created an alias name to this patient :-)


> ... you see where this is going? :)  let me carry on anyway...
> 
> * gmHL7.py can't cope, but auto-creates a fake patient.
> * note that now we have, by implication, a new patient, a new
> encounter, and totally separate clin.lab_request and clin.test_result
> entries.
> * praxis admin goes "grr, stupid stupid lab", merges the fake patient
> _agaaaain_ and...

I will accept that in cases where no alias existed to auto-resolve the variant 
name, a single import could include results under two different names for the 
same person where an individual path lab had multiple requests whose results 
crossed in time or where a hospital and a community lab supplied results in the 
same time time interval.

> wark wark, what do we do now, with the lab requests and
> clin.test_results which we knowwwww are for the same patient, we
> knowww that the test result is an "update" and should override the
> previous results in the "real" patient's test results....

when a result had been provided under a stupid name, isn't the updated result 
also going to be provided with the same stupid name?

won't it be resolvable by fk_ added to test_result?


>> but agree that within any one import "run", there is no need (within each 
>> patient) to have a distinct encounter for each individual test result 
>> imported within the "run". To my view, multiple encounters per-patient of 
>> type
>> 
>>        automated data import
>> 
>> should be merged or (if manageable) not even created.
> 
> ok whew.
> 
>> I would also challenge the auto-attachment of daemon-imported test results 
>> to other than
>> 
>>        automated data import
>> 
>> because despite that some other human-interactive encounter (doctor visit) 
>> could have been recently created, we are making assumptions here whether the 
>> results even:
> 
>> Accordingly, I think any results that are imported by script ought to be 
>> linked to a single in-common (or optionally different) encounter type that 
>> is distinct from human-interactive encounters. Re-categorization 
>> (re-association) is to my view too prone to mal-prediction.
> 
> i'm glad that you said this, because it had me concerned too.
> however, you're going to have to take this up with karsten, who has
> been asking for the lab request (and clin.test_results) to be
> specifically added to the current_encounter (which cannot happen
> without destroying the OBR-OBX hierarchy as we know).

except we would be ok anyway once we would provide fk_ in test_result, right?


> if you can persuade karsten that it is beneficial to put all automated
> requests/data under their own encounters

I would more say it is clinically acceptable for the importer to limit itself 
to this...

> then there would be no need
> to add a fk_lab_request to clin.test_result: the current code, which
> uses encounters to preserve the OBR-OBX hierarchy, would suffice.

except that we still need fk_ in order that the result can be regrouped 
semantically (clinically) into the encounter to which it functionally or 
clinically related.

-- Jim