gnumed-devel
[Top][All Lists]
Advanced

[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.

reply via email to

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