[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
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Busser, Jim, 2013/05/16
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Busser, Jim, 2013/05/16
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Karsten Hilbert, 2013/05/22
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key,
Busser, Jim <=
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Karsten Hilbert, 2013/05/23
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Busser, Jim, 2013/05/23
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Karsten Hilbert, 2013/05/23
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Karsten Hilbert, 2013/05/23
- Re: [Gnumed-devel] Possible failure of GNUmed to void duplicate values on a key, Busser, Jim, 2013/05/23