[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Identity numbers
From: |
James Busser |
Subject: |
[Gnumed-devel] Identity numbers |
Date: |
Tue, 22 Jan 2008 08:40:59 -0800 |
(was linked improvement requests: "Register new person"" widget and
Patient details plugin)
On 22-Jan-08, at 8:25 AM, James Busser wrote:
This reminds me it is wise to avoid too easily creating a patient
when they already exist. As a general specialist who would use
GNUmed I may be more at risk, but there are GP offices that also
accept walk in business and so the information from a patient (or
someone phoning to refer the patient) about whether or when they
had been there before is unreliable.
It also reminds me the value of using a patient ID to check against
creating someone who already exists. These IDs will be any of the
following:
- public health system unique identifier, if one is locally in use
- private health insurer identifier... the patient may have more than
one kind of insurance, but is likely to use one in preference to the
others
- hospital or cancer treatment center chart numbers... these would
seldom be patients' preferred or primary identifier but without them
it can be very frustrating to try to track anything down for a
patient who has gotten care there so is sometimes worth putting into
one's EMR. And maybe of use in matching if these facilities send any
electronic reports.
In the case of more than one identity number per patient, I expect
there will be usefulness to set some kind of preferred or default
value (in the case of only one identity number it would automatically
be the default) and that value, at least (if not all of them) could
be used when protecting against duplicate patient entry.
The key should be a combination of ID_Type and Value, because two
different ID systems might end up having the same value.
I am not sure whether we should allow user over-ride to permit a
duplicate ID number. Previously in BC families used to have a public
insurance "account" numbers and family members would have "dependent"
numbers 00, 01 etc. However that could be accomodated in the Value as
xxxxxx-00, xxxxxx-01 which should still be unique. But maybe other
use cases will still require to allow duplicates. I kind of hate to
allow it because many front desk staff will happily proceed through
such a dialog and create a duplicate when they shouldn't. I will
defer to your wisdo
A default among the identity numbers would also be helpful to be
offered when preparing communication or requests for tests etc.,
while still permitting one of the others to be selected, say, if
dealing with one of the other insurers.