|
From: | Jim Busser |
Subject: | [Gnumed-devel] Managing users: restricting access within GNUmed |
Date: | Mon, 03 Aug 2009 19:27:32 -0700 |
On 3-Aug-09, at 5:13 PM, I was asked off-list by my blind-copy-ee:
To the best of my knowledge we have still to this point deployed only one level of care team (named gm-doctors) for all patients. The intention. as we are able, is to introduce fine-grained access control for arbitrarily defined care teams, as per While client version 0.5 is essentially frozen, Karsten might give an opinion whether it can be in 0.6 that we can implement a basic restriction of desk staff to things like - demographics - waiting list - inbox - archiving documents 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" and whether the database already supports more than one role per individual. We did not yet figure out the *second* (arguably thornier) kind of granularity asked about above, i.e. content restriction. We did foresee the need, and therefore already modified the table clin.health_issue to support boolean is_confidential (which is at the moment labeled within the GUI "is sensitive"). 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. I suppose that, once created, a health issue that is (or is not) confidential can have more than one episode, some but not all of which may be desired to be treated as confidential. Decisions would be needed as to whether in the EMR tree, and in the displays of content, to: - display the health issue names, but not the content - display neither the health issue names, nor the content Patients might be accorded a choice among privacy "directives", in which their confidential issues (and any enclosed episodes and rows), until the patient would alter their directive, can be visible - 1 = only ever to the authoring clinician - 2 = only ever to the authoring clinician PLUS the patient's most responsible physician (MRP) within the praxis, if this individual should be different - 3 = to the authoring clinician, PLUS any clinician who would attest a serious concern for the patient - 4 = to any clinician in the praxis A clinician with access to the confidential information may put it in a document, therefore it is essential to be able to likewise code a document as confidential. Clinician authors of such documents should not mix (and therefore "trap") ordinary clinical information uniquely into such a document... the non-confidential part would usefully exist in GNUmed outside the document that is at issue, whether in a progress note or as a separate document that could be included in and with (say) confidential outgoing correspondence. While I know that some may say "oh, is that not a lot of bother?" I have been doing a lot of privacy work and I think such capacities are both essential and would (eventually) make GNUmed a lot better than some of the stuff that is out there. |
[Prev in Thread] | Current Thread | [Next in Thread] |