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


You are not allowed to post comments on this tracker with your current authentification 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: FunctionalitySeverity: 3 - Normal
Item Group: NoneStatus: Need Info
Privacy: PublicAssigned to: Luis Falcon <meanmicio>
Open/Closed: OpenRelease: 1.4.2

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
  • -unavailable- added by meanmicio (Posted a comment)
  • -unavailable- added by cd_larsen (Submitted the item)

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

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 07 Feb 2012 01:22:41 AM UTCmeanmicioStatusNone=>Need Info
      Assigned toNone=>meanmicio

    Back to the top

    Powered by Savane 3.1-cleanup