Re: [Gnumed-devel] chart accesses

[Karsten Hilbert]

On Mon, Jan 14, 2008 at 10:39:04PM -0800, James Busser wrote:

> When a front desk staff searches and selects a patient, even though the 
> involvement of the front desk staff in the clinical record might be 
> minimal, does the clinical record class get instantiated?
Yes, because

a) if there's a list of search results to chose from it
   displays a "last seen" field

b) upon selecting a single patient the client will display
   allergy data in the upper right corner

> I agree that the backend cannot "magically" know or should it want to 
> record all accesses, for example there may be automated queries or other 
> processes that may "call" the data. The middleware or clients could be 
> programmed to cause the read-access logs to get recorded.
Several such access logs are created anyway:

- UNIX system access logs
- PostgreSQL server connect logs
- GNUmed encounters

Among those suspicious access pattern can be detected.

> If a patient with high-sensitivity status wished to be known within the 
> practice only by a pseudonym except that their doctor would know the 
> patient's real name, is it possible for this real name to exist among the 
> identities, but to be excluded from the searches and from display in 
> searches, except to persons in the surgery/clinic/practice with special 
> permissions (even for that patient). Maybe this is a GNUmed 2.x 
> functionality.
No, it would be a security risk.

Spetsnaz knowledge has it that to be covert means to "*not*
be special" rather than to *be* "not special". IOW I would
strongly advise against storing real names and to operate
under a *credible* fake identity. Somehow marking patient
records to be excluded from search creates the very
possibility to single them out by that very attribute. Some
social engineering or clever incident creation will then
lead to identification of a person. Say, I filtered out 20
possible records for a given person. If I really needed to
know which one is the one I'm after I'd create an incident
to make the person trip over or whatever and observe said
patient records for which is getting bruise treatment added
to them.

> In the meantime, if the "true identity" information is to remain protected, 
> must it be kept out of the identities list and, if so, where would the real 
> name best be stored... maybe as a health issue "Identity protection"?
It'd have to simply not be there.

> Last question for now about protecting information within the practice: 
> there are situations where by convenience --- or by necessity where options 
> are limited --- workers within a surgery/praxis get their care from one of 
> the doctors within the group, some insulation (protection) against others 
> accessing their record is desired, especially if they had anything 
> sensitive relating to mental health or sexuality / pregnancy.  So that even 
> if their name existed "in the clear" among patients in the praxis, they 
> would desire some kind of "protection" against anyone other than their 
> designated doctor to be able to access their record.
Most definitely so.

> Can we easily enough manage something for this in GNUmed?
We have started to take steps towards that by using
PostgreSQL groups to control access to tables in the
database. The next step will be when we add the designation
of a "primary doctor within practice" to the patient record.
This will enable us to further restrict access to "treatment
teams".

That concept is, however, hard to define in a GP
environment. In my practice there's many patients which
(consentingly) see whichever doctor is available ATM. And
even for patients seeing a certain doctor over time there's
still some ambiguity with the nurses:


We usually have 3-4 doctor in during the day. Theoretically,
there's one designated practice nurse per doctor per shift.
In practice, the nurses switch and delegate as the workflow
dictates.

I have been thinking of solving things like this:

- at the start of a shift have staff sign on to the shift
  within GNUmed
- at the end of a shift have staff sign off
- this just records "nurse X is on duty 7-16 2008-15-01"
- the practice nurse of a given doctor is assigned to
  that doctor for that shift

- assign patients to doctors when they are taken to
  the exam room to see a certain doctor

- when the designated nurse *first* accesses a patient
  assigned to "her" doctor said doctor acknowledges
  her to be on his treatment team for the shift
  - this happens once per shift
  - it will readily support switches of designated
    nurses

- when a non-designated nurse accesses a certain
  patient for the first time during the shift the
  patient's doctor agrees to have her access the
  chart (agree is: click "ok")
  - access is granted to this patient only
    for this shift
  - the option to make her a designated nurse
    to this doctor is given
  - in that case she becomes a nurse with access
    to all patients of that doctor for the
        shift just like above
  - this means, her previous designation for the
    shift is voided

All this can be done technically.

There is one big problem which is fairly impractical to
solve: It is difficult to know exactly who is currently
using an authenticated session. IOW - how does GNUmed know
when to invoke the above mechanisms ? Sure, it's easy to
know at client login time but common practice shows that
machines and applications stay logged on all day once up and
running.

One solution is to

- make users wear an RFID chip taped to a finger
- have an ultra-short range RFID reader built into
  the keyboard
- on detecting a user within range of the keyboard
  reader invoke the above mechanisms
- of course, the most recent user will be cached and
  once the system knows the state of a given user/RFID chip
  it needn't interrupt the workflow even if users change at
  a keyboard

I'd be happy to be informed of better, less invasive,
controlling solutions.

Our current commercial EMR solves things like so:

At client logon a password is asked of the user (our
practice uses, of course, one password for all users of all
machines so it's more of a what-may-I-do rather than a
who-am-I password ;-)   It then asks the users to select his
identity (by a single letter) from a list whenever the
progress note editor is entered. Now,

1) in that identity selector I can chose any identity I care
   without further authentication

2) as long as I don't leave the progress note editor anyone
   can edit anything under the currently chosen identity

The only reason 1) works fairly OK among us doctors is that
out of professional respect for each other we don't fake
each other's identities. Nurses routinely enter Subjective
under my identity which I then read, perhaps change and
mentally sign off to stay.

There's nothing stopping anyone from entering anything under
my identity without me ever knowing.

A bit of a technical control for that might be to make the
system alert me of any data entered under my identity
outside of my shifts - which I would then need to sign in
and out of with a reasonably secure mechanism - but that can
be solved and is useful anyways.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346