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

[James Busser]

> I did notice in the bootstrapper some groups getting defined (in
> monolithic) as
>       gm-logins
>       gm-doctors
>       gm-staff_medical
>       gm-staff_office
>       gm-trainees_medical
>       gm-trainees_office
>       gm-public
> 
> but am not sure whether the above are values that constitute
> "dem.staff_role"

No. They are database-level groups.

---------------
JB: thus the intent is to permit many-to-many mappings between the staff roles 
(the various operational duties, including clinical) which people need to do, 
to these database-level groups?
---------------


> and whether the database already supports more than
> one role per individual.

don't believe in application-side access controls being of
any real value.

---------------
JB: of value only to the extent that the individual using (or having access) to 
the client would not alter the client, or else use the individual's GNUmed 
username and password which I assume can give some access to the backend 
through other tools without knowing gm-dbo?
---------------


Essentially, there's two types of access control involved here:

1) access to *types* of data

Here it may initially be sufficient to split people in two
main groups...

The path to enabling this type of access control would be to

a) enable GNUmed to create clerical and clinical users
   (currently all users are clinically enabled)

b) withdraw / regrant / ... 

---------------
JB: such groups will call for a refactoring of the existing database-level 
groups? Meaning (I am guessing) the database-level groups do not yet do 
anything, but were created simply as a first stab to model what might be needed?
---------------


2) access to data *content* regardless of type

... Restriction shouldn't occur to a particular user but rather to a
to-be-defined care team. Such care teams need to be able to
be dynamic: Doctors may cover for each other. Today nurse A
will work with doctor X while tomorrow it will be nurse B.
Basically it would mean that a care team is "headed" by one
or temporarily potentially several doctors. Nurses and
possibly other clinical staff will need to be able to "sign
into" the care team on an as-needed basis -- perhaps
per-shift or some such.

---------------
JB: I am sensitive to the potential need for someone who was temporarily or in 
the short-term involved in care to potentially have some responsibility to be 
able to re-access a record, for example to verify or double-check details as 
may happen when new information or a question later arose. Possibly this is 
more an issue across different praxes, when it can be harder to make sure 
essential things happen, than within a praxis, where it should be more possible 
to assure that some responsibility is fulfilled.
---------------


As a stop-gab measure, however, we *can* put some controls
into the application

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

While I see the motivation this would just be a ad-hoc
measure and not really a solution.

---------------
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) application measure, or in the more-proper 
database-level controls
---------------