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

[Jim Busser]

On 4-Aug-09, at 4:40 AM, Karsten Hilbert wrote:

This is probably "fairly" easy to accomplish, especially

since PostgreSQL 8.4 now offers column level access control.

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)

create/add?

gm-clinical

gm-clerical

ignore for now (as they do nothing) or deactivate in upgrade v11->v12 ?

gm-logins

gm-doctors

gm-staff_medical

gm-staff_office

gm-trainees_medical

gm-trainees_office

gm-public

b) withdraw access to the schemata blobs. and clin. from

   clerical users

would be done in an upgrade db script ?

- then see what happens

- re-design the schemata to conform to this split

blobs links documents to medical stays... presumably if some clerical staff help with the work of scanning (document archiving) they might need this? Maybe useful to anticipate  within the praxis individuals who, while not clinical, would assist with record input... a 'records clerk" ??

also the clerical person who helps with referrals may need some extra / partial documents access

- likely this will not be entirely possible

but not necessary, if table / column gives a better solution?

c) re-grant access to some tables in clin. and blobs. to clerical

maybe to sensibly allow clerical staff to know the status of a patient's *activity and location*:

encounter

encounter_type

hospital_stay

v_most_recent_encounters

v_pat_encounters

v_pat_encounters_journal

v_pat_hospital_stays

v_pat_hospital_stays_journal

v_waiting_list

waiting_list

move_waiting_list_entry( integer, integer )

trf... (are these triggers?)

- some re-organization of tables may be needed

- find out which columns of those tables are actually

  needed by analyzing the queries

d) withdraw table access from clerical and grant column access

- this may require some query rewriting

Note that this approach will make PostgreSQL 8.4 a

requirement for GNUmed.

Would this be a problem only if people are eager to use a future gnumed client (once it would depend on pg 8.4) with a server running less than Squeeze or equivalent?

http://veil.projects.postgresql.org/curdocs/main.html

Implementing this would, however, be a lot of work for what

PG 8.4 already offers natively. It can be a lot more

flexible though.

Sounds better to go native with the baby steps, and add something else only when there is a suitable combination of need and supportability?