gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values o


From: Busser, Jim
Subject: Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key
Date: Thu, 23 May 2013 06:09:34 +0000

On 2013-05-22, at 2:46 PM, Karsten Hilbert <address@hidden>  wrote:

> On Thu, May 16, 2013 at 05:21:47PM +0000, Jim Busser wrote:
> 
>> BTW  I have a related further idea / request / suggestion… I can put this 
>> into a Launchpad feature request, if desired…
>> 
>> Here is what had happened … sitting next to me had been the paper chart of a 
>> new patient who I had believed myself to have created yesterday. He is a 
>> patient whose name I did not retain very well… an eastern european name of 
>> the form
>> 
>>      Bond … ski, Walter (goes by Wally)
>> 
>> however the ergonomics of my workspace are poor -- I cannot have the 
>> computer and paper chart side by side -- and so, in the search box, I had 
>> mistyped
>> 
>>      Bod, Wal
>> 
>> and got no matches. Human error, yes, but one that risks to create problems 
>> in patient care, because I then went on to create a duplicate, relative to 
>> the patient who *already* existed, spelt
>> 
>>      Bond… Walter
>> 
>> Here is my idea … in the new patient creation window, before proceeding to 
>> commit the inputted data and create a new patient,
>> 
>> - can the middleware check whether the lastname, first initial, and date of 
>> birth already exist?
> 
> You do realize that this would not have prevented your above case ?


The above would, in fact, have prevented my error because my mis-spelling 
occurred only in my "search" … when I went to create the patient, I based my 
input on a set of printed paper information any not the name spelling that I 
had mis-remembered for the search.

However the other scenario exists, where a mis-spelling in the name results in 
the creation of a duplicate patient, which could have been prevented if the 
user was warned of an already-existing external ID.

This can help protect not only a keyboarding error, but also the case of fraud 
when sometimes patients use someone else's insurance number. The clinician can 
of course accept the duplicate external ID but at least it will be a conscious 
decision.

Members of a family could have the same account number. When this is the case, 
it is usually permissible for the workers in the praxis to know that other 
people in the same family exist in the praxis. So I do not picture a privacy 
problem when the staff is alerted that an external ID already exists.

If the concern exists that an external ID might be often re-used even for 
patients not in the same family (say, for some ad hoc categorization of 
patients) then it is possible that to warn every time could be excessive. 
However, a praxis will most usually select, as the external ID during patient 
creation, some other kind of entity like a Medicare or Insurance or Hospital 
number and since the notification still allows the doctor or staff the choice 
to continue patient creation anyway I think this is a good feature. *** This 
*** would have protected me if my mis-spelling of the patient's name was during 
the patient creation. 


> Is your suggestion deliberately intended to ignore gender ?

My suggestion did not consider to include or ignore gender except now I think 
it should be excluded. In the case where a DOB and name already exist, it is 
unlikely that in the same praxis you will have two identically-named persons 
where one is male and the other is female because most names are sex-specific 
and even when a given name can be used for either gender, the scenario is still 
(statistically) more likely one where the patient already exists, with the same 
name and DOB, and the about-to-be-created (pending) gender mismatch is a result 
of a wrong selection. Therefore, I would not accept a mismatch gender to 
suppress an alert … the original patient record could have a wrong gender that 
requires correction.

-- Jim


reply via email to

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