[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J Busser
Subject: [Gnumed-devel] unmatched results (was re: review)
Date: Thu, 27 Oct 2005 01:34:31 -0700

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

There had been a bit of previous discussion on this.

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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]