[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Health-dev] [bug #35461] Privilege Separation for Patiet Registration

From: Christoph H. Larsen
Subject: [Health-dev] [bug #35461] Privilege Separation for Patiet Registration
Date: Mon, 06 Feb 2012 17:47:36 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20100101 Firefox/5.0 Iceweasel/5.0


                 Summary: Privilege Separation for Patiet Registration
                 Project: GNU Health
            Submitted by: cd_larsen
            Submitted on: Mon 06 Feb 2012 05:47:35 PM GMT
                Category: Functionality
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: None



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!


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]