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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
