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

[Luke Kenneth Casson Leighton]

On Wed, Aug 11, 2010 at 4:01 PM, Jim Busser <address@hidden> wrote:
>
> On 2010-08-03, at 10:51 PM, Jim Busser wrote:
>
>>> * parse this: #  dob AND case-insensitive lastnames AND 2-character
>>> wordmatch in firstnames AND gender [unless source data is missing or
>>> unknown]
>>
>> <snip>
>>
>>> i did say it's not quiiite as "simple" as it first seems...
>>
>> Very true.. a patient may have provided the practice with the name
>>
>>       Smith, Destny Elizabeth
>>       Sex F
>>       DOB 19850317
>>
>> however, when she attends the lab, the lab humans might input "Destiny" 
>> instead of "Destny" and may not bother to put in the full middle name and 
>> may accept to put in a variant depending what the patient exists is the name 
>> she "goes by":
>>
>> 1     Smith, Destiny
>> 2     Smith, Destiny E
>> 3     Smith, Destiny Elizabeth
>> 4     Smith, D Elizabeth
>> 5     Smith, Elizabeth
>> 6     Smith, Beth
>> 7     Smith, Destiny Beth
>> 8     Smith, D. Beth
>>
>> <snip>
>>
>> Using <snip>, 1-5 should all be accepted while 6,7,8 should not be accepted 
>> as matching.
>> -- Jim
>
> Um... given GNUmed already supports multiple names per person (thereby 
> supporting e.g. maiden names, other names changes and variants):

 ohh, wait - are you saying that there is a many-to-one relationship
between dem.names and dem.identity?  (to support "merge patient")?
so, the exact same "dem.identity" can be resolved via multiple names,
already?

 if so, that makes it an almost no-brainer to do fake-patient
removal/merging, as the code's already there.

> 1) will the lookup function recognize these multiple names per person?

 which lookup function?  the one i wrote last week?  i wasn't aware of
the many-to-one relationship thing, so what i wrote is likely to treat
"person with multiple aliases" as "multiple people", thus resulting in
non-unique match, but that's easily fixed.  in fact i'll take a look
and do it now.

> 2) @ Luke/Karsten -- if we did implement auto-creation (in the case where a 
> result was not auto-matchable to an existing patient) but it turned out that 
> the patient did exist only it was in a form not matchable by the incoming 
> data, would it be
>
> a) easily enough determinable which auto-created persons (not yet confirmed 
> to be actual distinct patients) newly existed and

 SELECT  * from dem.clin_ext_id_type, dem.identity where
dem.clin_ext_id_type.name = "lab autoimport fake person" WHERE
dem.clin_ext_id_type.fk_person = dem.identity.pk

 done.  dead easy.

> b) where a decision is made by the reviewing user, to do one of:
>        - proceed to complete this new entity's "transformation" into a 
> patient, or
>        - merge the new entity as an alias of an existing patient?

 by using the above query.  strictly speaking you shouldn't even have
to do the above query, because in the (proposed) clin.lab_request
dialog with the "big red button to resolve fakeness", you'd be
starting _from_ the "fake patient"'s name and using that to look up
"real" patients, rather than the other way round.

l.