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:11 PM, Jim Busser <address@hidden> wrote:
>
> On 2010-08-13, at 1:30 PM, Luke Kenneth Casson Leighton wrote:
>
>> the only thing that leaves me "uncomfortable" is the fact that the
>> encounters themselves are obviously going to have to be merged, too.
>> perhaps... perhaps it is enough that the clin.lab_request data and
>> clin.test_result is going to be moved away from one of them, and
>> merged into the other.
>
> I don't think they *have* to be merged

 ahh... think about this scenario:

 * lab sends in obsv.report with a completely wrong but
manually-identifiable patient name
 * gmHL7.py can't cope, but auto-creates a fake patient.
 * praxis admin goes "yep, we can cope with that" merges the fake
patient, then goes "hmm" and deletes the "incorrect" name, so as to
avoid confusion.
 * lab gets a "slapped wrist" communication, which they totally ignore
of course.
 * lab sends an update obsv.report, with _again_ the same damn
completely wrong but manually-identifiable patient name.

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

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


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

if you can persuade karsten that it is beneficial to put all automated
requests/data under their own encounters 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.

l.