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 3:17 PM, Luke Kenneth Casson Leighton wrote:

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

and

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

Two patients can correctly have the same name. This then depends on date of 
birth and / or another identified (health number) for differentiation. This is 
already supported.

If you are suggesting:

        Patient whom we knew as Peter Daniels
        has blood taken
        path lab returns
                John Smith

        who matches our "other'"John Smith
        you maybe even propose an in-common date of birth

        but Peter confirms
                I did go to the lab
                they did take 2 tubes of blood at that time
        
        the lab did not record a health number because I paid privately
        for reasons unexplained, the lab mis-entered me as "John Smith"
        coincidentally I have the same date of birth as "real" John Smith in 
the praxis

1) incompetence exists, but in Canada and maybe all countries which would run 
GNUmed, it should be possible to get the wrong name fixed upstream.
2) if the lab refused to fix it, you could persuade your praxis administrator, 
in GNUmed, to create alias

        Smith, John STUPID LAB ALIAS

A case of identical DOB, AND stupidly (or even coincidentally) matching names 
AND no disambiguating middle names AND with null PID {002, 003, 004} is 
possible but in the IMO extremely unlikely case that it would arise I think it 
should require the individual praxis to achieve a solution locally for that 
patient and, in the meantime, manually tolerate it including the possibility of 
redundant or updated test results requiring to be dealt with.

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

yes

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

it only breaks what might have been the permanence of the association. I should 
point out that, all along, GNUmed has figured on the encounter as serving an 
able-to-be-altered grouping function so I apologize that this maybe led to 
competing expectations.

While personally I might be happy with associating results with a clinical 
encounter only in the case where results had been manually-inputted, and 
instead using the "episode" as the grouping parameter, I see no need for a 
"victor" in this argumentation if the encounter dependency can in fact be 
removed. :-)

-- Jim