Re: [Gnumed-devel] Managing users: restricting access within GNUmed

[Jim Busser]

On 6-Aug-09, at 6:43 AM, Karsten Hilbert wrote:

I am now wondering whether we should likewise extend is_confidential

into clin.episode, whereby an enclosing "health issue" by takes on

the confidentiality level of the episode.

JB: it is not ad hoc... it simply extends the granularity

of is_confidential e.g. how_confidential and could be useful

both within the stop-gap (or did you maybe actually mean

stop-gab)

the above question was, by the way, intended to be a joke (a confidentiality setting intended to deter people "gabbing" which means "gossiping"

It is not a solution for anything regarding access control.

In fact, its purpose is something different.

I can envision that per-episode confidentiality may be overly granular. Nevertheless, could

is_confidential

if combined with my proposed

how_confidential 

together define, at the row level, that

where is_confidential is TRUE and how_confidential is 1 --> grant access where current user = last modified by

e.g. small town patient did not wish her usual gp to know that part of her visit concerned a later-negative HIV or pregnancy test that was negative

where is_confidential is TRUE and how_confidential is 2 --> grant access where current-user = last modified by or = usual/most responsible clinician

where is_confidential is TRUE and how_confidential is 3 --> grant access where current-user = last modified by or = member of care team 

which could then inform the views from which EMR tree content could be prepared, since a view whose join included the confidentiality columns could presumably constrain access to the contents of the narrative columns, for rows marked as containing sensitive content?