[Gnumed-devel] unmatched results (was re: review)

[J Busser]

At 9:13 AM +0800 10/27/05, address@hidden wrote:
>  > there is no reviewed but unlinked results bay , for results that have
> >  arrived but no patient exists in the practice, so they end up clogging the
> >  results to be reviewed list over time.
> Maybe a "create patient from result" Obviously need to be careful 
> with this one
> (i.e. it first checks for close matches which the user then has to manually
> reject)

There had been a bit of previous discussion on this.

http://lists.gnu.org/archive/html/gnumed-devel/2005-05/msg00058.html
http://lists.gnu.org/archive/html/gnumed-devel/2005-02/msg00282.html

also Ian had pointed out that in AU there is potential for a lot of 
failed matches
and I interpreted those in many cases were actual patients within the practice
but where there was failure of sufficient, uniquely identifying info returned:
http://lists.gnu.org/archive/html/gnumed-devel/2005-05/msg00060.html

So possibilities for unmatched results are:

1) Patient to whom it relates DOES already exist in the EMR, but the 
result lacked sufficient, uniquely identifying info (Karsten pointed 
out it could be alias or identity-based with the failed match a 
consequence of a different last name or even just a variation in 
which the patient's proper first name is "Henry" whereas the patient 
customarily identifies themself as "Hank" or by a middle name of 
"Peter", I am not sure if it is proposed that in GNUmed this one 
person is wise to exist as

Smith, Henry
Smith, Hank
Smith, Peter

so that if there exists no unique link for what we might call 
"reconciliation" (i.e. no unique request number, and no unique person 
identifier like a public health insurance number) then the algorithm 
might match some combination of 4 out of 6 pieces among surname, 
given name, sex, date of birth, street of residence [or post code] 
and phone number. Ian had referred to Horst having a "super smart" 
algorithm. Alternatively I can outline some components of a 
probabilistic matching algorithm of which I am aware.

So inserted between the unmatched result and a "create new" button 
should be some form of matching assistant, to better help the 
clerical staff avoid creating a new person when the person already 
exists. Moreover one extra useful precaution inside a "create new" 
button would be to define any data elements can be defined locally as 
unique, say the public health number, to prevent sloppy fingers from 
creating someone when it can be known they ought not be created in 
duplicate.

2) Result unresolvable OR Patient DOES NOT already exist

The first of these is tricky as it seems unwise to create a "new 
patient" when you could neither be confident it is a real person 
distinct from all who exist already in GNUmed, nor could you later 
recognize the owner should they later walk into the office resulting 
in yet another patient to be created in GNUmed. I also agree with 
Karsten previously that no-one should want to have a pseudo-patient 
e.g. so-called Unmatch, Ursula to whom all residual results are 
attached for the purpose of cleaning out an inbox. Among such 
"clutter" maybe there is value for a user to be able to tag results 
as "limboed" and such results could thereafter be filtered out of the 
normal view. They could be recalled on  demand if a patient should 
come into the office, and ask about results that they insist were 
collected ---> if inspection of the tracking table shows nothing, the 
limbo "jail" could be inspected for the tests collected during a 
specifiable interval, further narrowable by test_type, maybe date of 
birth or approximate age, and sorted by last name which may have been 
misspelt.

When there *is* enough information to make clear it *is* a person 
distinct from anyone already in GNUmed I agree there's huge value to 
create them. It may be a person who is *supposed* to come for the the 
first time into the practice, and it is true they may or may not ever 
appear. It is also true that the result could have been sent/copied 
to a doctor in the practice in error (maybe the doctor also works at 
other offices or was misidentified). But either way, if the result 
*did* come to the office, then outside inquiries might later follow 
or there may be a responsibility to enter into a record that the 
mistake was dealt with (communicated) particularly in the event of an 
abnormal result where the patient might otherwise come to harm. In 
the simplest case where a result was normal, it would be of no 
consequence if the patient never came or that a normal result 
(received in error) went unactioned... such "patient" records could 
be allowed to exist without encounters. But in the case of abnormal 
results it is important to consider putting into the record (whether 
in the clinical section via soap, or into an administrative section) 
that the patient had been notified and/or the lab who had sent it in 
error had been notified.