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

[Karsten Hilbert]

On Thu, Oct 27, 2005 at 06:46:44PM +1000, Ian Haywood wrote:

> > 1) Patient to whom it relates DOES already exist in the EMR, but the
> > result lacked sufficient, uniquely identifying info (Karsten pointed out
> In this case the result is basically useless. AFAICT this is quite rare.
I believe Jim is talking about lack of sufficient
information for automated matching where a sufficiently
intelligent human being can still find the match.

> > 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.
It might even be useful to generate a non-blocking warning
when "create new" is pressed before the matching assistant
has been employed.

> IMHO it would only be doctors who do "create new patient"
> (as they may know this is a new patient, for example they
> got a phone call)
That would be counter-productive in my/our (as in here)
workflow. IMO it should rather be made practice *policy*
whether creating new patients from unmatched lab results is
a staff task.

> > 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.
That's a good idea. As far as "numbers" go I would know a
way how to make that a configurable database constraint.

> > 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.
> We already have an unmatched_result table.
> IMHO we should just add a simple flag so seen but unmatchable results can be 
> hidden
> (and brought back as the need arises)
We now do that by means of incoming_data_unmatchable.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346