[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
privacy (was Re: Fwd: Re: [Gnumed-devel] GNUmed brochures)
From: |
J Busser |
Subject: |
privacy (was Re: Fwd: Re: [Gnumed-devel] GNUmed brochures) |
Date: |
Wed, 14 Dec 2005 23:46:54 -0800 |
At 2:23 PM +0100 12/14/05, Hilmar Berger wrote:
...So what is GNUmed ?...
GNUmed is building a
comprehensive scalable software solution for paperless medical
practice with emphasis on privacy protection...
^^^^^^^^^^^^^^^^^^^^^^^
I was thinking in particular about the "privacy" part
for I cannot recall much discussion of it. There exists in GNUmed some
information about user types, but not much about "information"
types.
I sit on a group that is trying to figure this out. Here are some
thoughts:
- a telephone number gives the ability to be harassed
- an address give the ability to be harassed, assaulted or
killed
(think here abused women, abortion providers, law &
security personnel)
- date of birth and other identifiers permit identity and
financial fraud
- patients' health and personal information, and identifiable
links to family and others, can subject these people to social attack
or disqualify them from things to which they may otherwise have been
entitled
So information may helpfully be divisible into three privacy
types, depending on whether privacy would be lost, and whether it
would put the patient or linked persons at any risk
e.g. psychological, financial, social, physical (including
identity theft)
Privacy types:
A- can be known to the public, without a loss of privacy *
B- "simple" loss of privacy: risk of injury is not
identifiable, beyond loss of "control"
C- "at risk" loss of privacy: risk of injury
identifiable
- C1 could be on a system/default basis and
- C2 could be where specifically upgraded or set by
patient request
* existence of something in the public domain can threaten
privacy, so may not be grounds to deny keeping it confidential
But patients can be at risk from a lack of information by
providers of care. So it is important to differentiate risk that is
deliberately carried by the patient (principle of informed consent)
from risk unwittingly carried by the patient when they did not intend
certain information to be withheld, or were uninformed of any risk of
withholding.
In terms of how to support this, I was thinking some combination
that each record could have a default "type" based on the
table in which it resides, but that each record type be modifiable on
an individual patient basis. Provider access could be defined by a
combination of
A + Provider role + Provider relationship/trust level
Provider role:
- this can identify appropriate tables and privacy levels, so a
pharmacist (if one worked in your clinic or was permitted access to
your GNUmed record) could identify medications and allergies unless
these were marked "C" for example by default or by patient
choice HIV medication could be shielded, except to people with extra
need-to-know or trust levels
Provider relationship /trust level:
- this could work in terms of whitelists and blacklists. Anyone
already on the whitelist could add another user to a patient's
whitelist. Patients may want a particular doctor in the practice to be
the only one to (normally) access "C" records and a family
member who works in the surgery/office should be blacklisted.
- Likewise if an employee of the surgery / office is also a
patient at the same location, all of the personnel except the main
doctor and the employee may be on the blacklist, or equivalent
behaviour may be programmed in for such people at a system or
patient-preference-based level. It is not to say that if the person's
preferred, main doctor were away, that no other doctor in the group
could access their "C" records if those were needed, but
this should at least trigger some audit log.
- Same is true of the workers accessing a co-worker's records. It
can be of no concern if a co-worker record is accessed for its phone
number on account of work-related communication. But examination of
"B" or "C" records should trigger an audit
log.
- An employee might input their own appointment and reason for
visit, and would presumably reside on their own whitelist avoiding
audits.
- A whitelist can also be used to manage the list of
"outside" doctors being seen by a patient. Some may carry an
ongoing relationship of trust with the patient, who would want them to
have access to all their records. But if a patient is being sent to an
endocrinologist it may not be necessary for the medical history export
to include treated syphilis, the opposite is true.
- privacy (was Re: Fwd: Re: [Gnumed-devel] GNUmed brochures),
J Busser <=