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

[Luke Kenneth Casson Leighton]

On Fri, Aug 13, 2010 at 10:47 PM, Jim Busser <address@hidden> wrote:
> 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 :-)

 noooOo - re-read what i wrote: i said "the administrator *deleted*
the alias because it was totally totally wrong.  i.e. even completely
the wrong name, such that it was vital that the alias be deleted, but
the report was confirmed as being to the correct patient, perhaps by
phone calls verifying it, perhaps by the PID etc. etc.".

>
>> ... 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?

 yeehhhs, but as i explicitly said above, the decision was made, for
safety reasons, to delete that "stupid" name from the aliases, because
it was... ooo, i dunno... matching by complete chance against a
totally different patient.

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

 that's related to test_result, this is about identifying the
clin.lab_request.   the logic i've been told to follow requires the
patient to be identified, first.  i presume this is because it could
potentially be the case that the ORC 003 code, issued by the lab, is
not guaranteed to be unique.


>> 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?

 don't know (see below)

>> 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...

 yes.

>> 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.

 ah.. are you saying that you would, given that the proposed
fk_lab_request would preserve the OBR-OBX hierarchy (in
clin.test_result + clin.lab_request), that you would want to then
begin changing the encounter with which the lab_request and/or
test_result was associated?  perhaps move the test_results to
somewhere more appropriate?

 if so, that kinda breaks what's been discussed already about keeping
clin.lab_requests + clin.test_results associated with "automated lab
import" encounter/episode types!

 l.