bugGNU Health - Bugs: bug #35461, Privilege Separation for Patiet...


You are not allowed to post comments on this tracker with your current authentication level.

bug #35461: Privilege Separation for Patiet Registration

Submitted by:  Christoph H. Larsen <cd_larsen>
Submitted on:  Mon 06 Feb 2012 05:47:35 PM UTC  
Category:  Functionality Severity:  3 - Normal
Item Group:  None Status:  Ready For Test
Privacy:  Public Assigned to:  Luis Falcon <meanmicio>
Open/Closed:  Closed Release:  2.9.0
Module:  health

( Jump to the original submission)

Fri 29 May 2015 12:53:23 AM UTC, comment #9: 

Hiya Luis!

Sorry about late response, I've been traveling and the internet was expensive and heavily-restricted there.

I think the recent commits to restrict all the gyneco, socio, and lifestyle fields from the frontdesk user by default should address the main concern. Previously, the default installation for the frontdesk user was able to see the patient medical history, specifically gyneco, socio, and lifestyle fields. That seemed unintended. Hehe.



PS: I did give the suggested solution (separate models) an attempt but the only relationship that makes sense is a 1-1 (somewhat ugly). You'd also have to redo the patient view considering the view-model restrictions.

Chris Zimmerman <teffalump>
Project Member
Mon 18 May 2015 10:45:49 AM UTC, comment #8: 

Hi, Chris !

The idea is that the frontdesk user will have access to the person demographics, appointments and not to the patient medical history.

On the other hand, the standard role for a health professional, allows a comprehensive view of the person (socio-bio-psycho) status and history. That is the intended functionality.

The main patient view integrates most of them, but many tabs / fields are actually coming from different models / modules (lifestyle, socio-economics, pathologies, medications, ob-gyn, genetics, surgeries, ... ). Each of them have their access control rules on each field.

I do agree with you that there is room for improvement, and that we should focus on optimizing it for the 3.0 release.

Thanks a lot, and let us know your thoughts.


Luis Falcon <meanmicio>
Project AdministratorIn charge of this item.
Sun 17 May 2015 06:50:09 PM UTC, comment #7: 

What I meant, and I believe what Christoph was saying, is that its easier, if you have many fields, to put them on a single model instead of individually defining the access rights. I'll close this and we can reopen if need be.

Chris Zimmerman <teffalump>
Project Member
Sat 16 May 2015 09:53:13 PM UTC, comment #6: 

You don't need to have a separate model, Tryton will do the job if you configure field access rights.

C├ędric Krier <cedk>
Sat 16 May 2015 06:53:01 PM UTC, comment #5: 

I made a task - https://savannah.gnu.org/task/?13590 - about hiding unused gui elements. The last commits hide all the sensitive fields from the default frontdesk user. Other than that, the only thing more for this issue would probably be to truly separate a safe subset of patient info. That is, have the fields as a separate model, like Christoph suggested. Any thoughts?

Chris Zimmerman <teffalump>
Project Member
Wed 29 Apr 2015 03:50:59 AM UTC, comment #4: 

I've restricted access to all the Gyneco, Socio, and Lifestyle fields from the Frontdesk group. I suppose we could still move all those fields to separate models. However, I don't know if that'll happen anytime soon. I do see the usefulness of defining a 'safe' subset of the patient info for any of the purely administrative users.

Chris Zimmerman <teffalump>
Project Member
Wed 29 Apr 2015 02:36:37 AM UTC, comment #3: 

I just pushed a commit restrict (i.e, hide) frontdesk access to all the gyneco fields by default. I'll next move to the Lifestyle and Socio and restrict those. Then, the default Frontdesk user will have more realistic access rights.

Chris Zimmerman <teffalump>
Project Member
Mon 27 Apr 2015 09:18:15 PM UTC, comment #2: 

What I'm understanding from this report is a goal of access rights and clear divisions of users. From what I've seen on the development of the PUID (vs SSN) and synchro, many of these concerns have been taken care of.

The demo_frontdesk user demonstrates these issues pretty well. Creating a patient (and party at same time) is quite easy and there are no problems I can find. The demo_frontdesk user has limited access to patient info, which can be further restricted by the access rights on fields.

There is the issue of similar fields not existing on a separate model. In general, this seems a difficult localization issue to handle. The access rights are there to handle varied environments.

I agree that there is the cosmetic annoyance of tabs/icons/etc. still existing with no access to those models/fields. I'm looking into how to hide the pages when the models are hidden. The cosmetic issue is, I believe, the only operable work that needs to be done for this. Moving to In Progress and I'll do some looking into hiding the pages.

Chris Zimmerman <teffalump>
Project Member
Tue 07 Feb 2012 01:22:41 AM UTC, comment #1: 

Hi Chris

Let me just copy / paste my comments on the mailing list and we'll take it from there :-)

I think that this deserves a bit of explanation on my side. At any center, the patient will have two codes

1) SSN : Any state unique ID that identifies that patient (SSN is probably the most used, but any other stated issued ID will work)
2) Health Center Patient ID : Specific for each health center.

The one that is "universal" for all the health centers would be SSN or equivalent. On the patient's clinical record, that is the number to export and to show. You can now retrieve a patient in the patient model from either the Patient ID or the SSN.

So, on this topic... from the GNU Health point of view, the SSN is _very_ important, and the Health Center patient ID is important to the center itself, but it has limited value outside the center.

Now, different health centers and even different scenarios work differently. For instance :

a) Some centers will fill in the patient general information at the front desk. This is :
- Gender
- Date of Birth
- Marital Status
- Insurance type
- And at this point, the internal Patient ID is generated.

b) Other centers and scenarios will ask limited (or even none) information before the health professional gets to see it
- Public hospitals
- Emergency departments
- Small offices
- Single practitioner

Actually, the "b" scenario is the most common. In many cases, because there is no health informatics and everything is on paper. What you see in this cases is somebody at the front desk that writes down basic patient info and then send the patient to the doctor room, where she or he starts the interview from zero.

So, in case "b", the health center patient ID and the SSN are generated / retrieved at the same time.

So, when is the patient actually created ? Again 2 approaches show up :

a) Administration department view : A person becomes a patient at the moment that she / he signs up for an appointment at that specific health center. We have to remember that the attribute of "person" exists at the party level, so, for example, all the family members or contacts of an specific patient can exist at GNU Health, but not necesarily are patients.

b) Clinical approach: The patient is actually a patient after the first evaluation / encounter with a health professional (doctor, nurse... ). This is/was the GNU Health approach, but of course, can be modified.


I think once we define the first part, implementing the access to the Patient ID will be OK.


Luis Falcon <meanmicio>
Project AdministratorIn charge of this item.
Mon 06 Feb 2012 05:47:35 PM UTC, original submission:  

Dear Crowd,
Not uncommonly, patient registration is done by non-medical personnel that should not have any insight into the medical details. GNU Health offers, in principle 2 approaches to achieve this:
(1) Use the "Party" facility to create patient core data (addresses, etc.) Disadvantage: There is no way to create ptent IDs, and: The registration staff has to activate - manually - the is_patient field, and may inadvertently activate other flags. As the Party facility will be used by others (accounting, procurement, etc), privilege separation becomes an added problem, which is not helped by the not entirely simplistic way, how Tryton manages rules: There is not clear and easy AND function to check for the validity of two rules at the same time, unless youcreate different groups - awkward.
(2) Alternatively, we can enter patent core data in the "Patients" facility. What is good about it is that Paitent IDs are automagically created, and that some, but not all medical details can be hidden away via existing models. However, some tabs are not linked to any models, namely: Obstetrics & Gynaecology, Lifestyle, Socioeconomics. Therefore, at present we have to disable access to each and every compromising field. Once we have models for those missing  entities in place, disabling access will be as easy as doing it now for the Surgery tab. One added request for cosmetics: It would be nice, if disabled tabs would actually disappear, instead of sitting on the screen, empty, and without any content. This should also hold true for sub-tabs.
Any ideas? Thanks a lot!

Christoph H. Larsen <cd_larsen>


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by cedk (Posted a comment)
  • -email is unavailable- added by teffalump (Posted a comment)
  • -email is unavailable- added by meanmicio (Posted a comment)
  • -email is unavailable- added by cd_larsen (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-17 teffalump StatusIn Progress => Ready For Test
        Open/ClosedOpen => Closed
    2015-04-27 teffalump StatusNeed Info => In Progress
        Release1.4.2 => 2.9.0
        Module => health
    2012-02-07 meanmicio StatusNone => Need Info
        Assigned toNone => meanmicio
        ReleaseNone => 1.4.2

    Back to the top

    Powered by Savane 3.7