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

[Karsten Hilbert]

On Wed, Aug 05, 2009 at 08:06:55AM -0700, Jim Busser wrote:

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

They were intended to be used to type-of-data access control
at the database level. We can drop gm-trainees*.
gm-staff_medical was intended to be non-doctors. We can drop
that too and maybe re-introduce it later when needed.
gm-staff_office is what might rather be gm-clerical.

> I 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?

That's right.

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

We can also just add a group gm-clerical. The group
gm-doctors pretty much is gm-clinical.

> Meaning (I am guessing) the
> database-level groups do not yet do anything,

gm-logins defines which users can login and which don't

gm-public is used for permissions common to
all groups of people

> but were created as a first stab to model what might be
> needed?

yes

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

Well, such access can always be regranted on such occasions.


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

no

> application measure, or in the more-proper
> database-level controls

It is not a solution for anything regarding access control.
In fact, its purpose is something different.

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