gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Ian Haywood
Subject: [Gnumed-devel] Re: unmatched results (was re: review)
Date: Thu, 27 Oct 2005 18:46:44 +1000
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)


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



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

> 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.
In Australia
        - there is no offical number which is guaranteed unique to any 
individual
(families can share a single number), plus an individual is identified to the 
State
by several numbers (I have 6)
        - no number which is common to all citizens. Foreigners, ncluding 
longterm residents
also often have no number also.
Babies often don't get registered until they first present to a doctor
(they are not registered at birth and frequently remain completely numberless
until 3-4 months of age, often older in isolated areas)

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

Presumably unmatched results which hang around for weeks and weeks will have to 
be discarded
(but remain in the audit tables, so they are never truly gone)

> 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.
we now have a "comment" field for this and other purposes.

Ian




reply via email to

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