bugGNU Health - Bugs: bug #63627, Problematic restriction for...

 
 

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

bug #63627: Problematic restriction for editing parties from the patients view

Submitter:  Mathias Behrle <yangoon>
Submitted:  Fri 06 Jan 2023 07:43:42 PM UTC
   
 
Category:  Functionality Severity:  1 - Wish
Item Group:  None Status:  Works For Me
Privacy:  Public Assigned to:  meanmicio
Open/Closed:  Closed Release:  4.3.0
Module:  health Component:  Hospital Management

Sun 15 Jan 2023 12:08:16 PM UTC, comment #5: 

Hi Luis,

late best wishes for a happy 2023 and thank you for your explanation!

I think there is still room for improvement, please read my inline comments.

comment #3:

> Hi, Axel!
>
> Thanks for the feedback!
>
> I see two different things here:
>
> 1) Security and integrity


Just for the sake of understanding: for me there is often a misunderstanding of the term security, which is often confounded with access rights.

Security: Properties of an application to not allow break in or interfere with the application by technical means.

Access rights: Properties of an application to allow access to specified parts of the application in regular usage.

Integrity: Properties of an application to guarantee the integrity of data.


JFTR with respect to those definitions I would rename all folders in health modules named security to access_rights, because that is what they are meant for.

> 2) Role designation and tasks
>
> Just to be clear, you can always update the demographics from the person view at any point in time (provided the appropriate access rights).


Well, anyone with read access to the patient model using the GTK client can edit the party, because the party model is not locked down with any access permissions. I once proposed to define general access rights for all such models, but upstream denied with the argument, that it is a model that will be required to use in any scenario so it wouldn't make sense to limit access to it. I still see it differently and perhaps GH should implement access rights for the party model.

> About security (1), that is the main reason of the feature. GH can not permit person reassignment once the patient is created. This is a must. Failing that premise would be a disaster.


That's indeed integrity and I see your point.

I would solve the problem differently: Since there is a strict 1:1 relation between party and patient I would have modelled the patient model not as a separate model but implemented the patient fields (and methods etc.) directly on party. Display and access to different parts of the view could be implemented by view_attributes. This would remove the fuzz to care about the 1:1 relation and would improve the user experience when trying to edit patients.

What do you think?

> About groups and tasks designation (2), it's a good practice to separate navigation areas from a privacy and organizational / HR point of view. That is what happens in health institutions: Administrative / front desk team enter the demographic information, and the health professionals manage the medical and clinical data. Front desk personnel should not have access to the person medical history.


Front Desk has currently (menu and write) access to Patient related information and Parties (which is more than Doctors have...).

> I agree that in small and personal doctor offices, there is one person that does everything. But even in that scenario, the steps should be the same. First create the demographic info (party) and then the medical management. You can always update the demographics from the person view at any point in time.
>
> In the case that we would like to see and update the demographic (party) information directly from the patient view, instead of using the M2O field, we can create a direct access action ("Demographics") similarly to what we have for Prescriptions, encounters, etc.. I think that would the best approach and make (almost) everyone happy :)


Yes, at least for now there should be a relate for web client users.

Best
Mathias


Mathias Behrle <yangoon>
Tue 10 Jan 2023 04:41:35 PM UTC, comment #4: 

Closing the issue with the proposed solution.

If you need to edit the person demographics from the patient view, instead of opening the M2O field, right click on the person name and press "Edit" (provided you have the access rights for party).






Luis Falcon <meanmicio>
Group administrator
Mon 09 Jan 2023 10:28:24 AM UTC, comment #3: 

Hi, Axel!

Thanks for the feedback!

I see two different things here:

1) Security and integrity
2) Role designation and tasks

Just to be clear, you can always update the demographics from the person view at any point in time (provided the appropriate access rights).

About security (1), that is the main reason of the feature. GH can not permit person reassignment once the patient is created. This is a must. Failing that premise would be a disaster.

About groups and tasks designation (2), it's a good practice to separate navigation areas from a privacy and organizational / HR point of view. That is what happens in health institutions: Administrative / front desk team enter the demographic information, and the health professionals manage the medical and clinical data. Front desk personnel should not have access to the person medical history.

I agree that in small and personal doctor offices, there is one person that does everything. But even in that scenario, the steps should be the same. First create the demographic info (party) and then the medical management. You can always update the demographics from the person view at any point in time.

In the case that we would like to see and update the demographic (party) information directly from the patient view, instead of using the M2O field, we can create a direct access action ("Demographics") similarly to what we have for Prescriptions, encounters, etc.. I think that would the best approach and make (almost) everyone happy :)

Let me know your thoughts.

Cheers
Luis

Luis Falcon <meanmicio>
Group administrator
Mon 09 Jan 2023 09:26:06 AM UTC, comment #2: 

Hi Luis,
I reopened, as I don't feel the current setup reflects the real world process - or at least makes the real world process very difficult. (So it may work as designed, but design needs improvement)

When a new patient is registered at the service desk, there is often the need to adjust patient data after saving it - just think about the flaky date widget behind the DoB field.

Having the front desk disabled from editing a patient means, either the patient data remains inaccurate, a different organizational unit has to be informed to conduct the change, or the front desk needs authorisation for the party as well, and conduct the necessary changes in the party module.

It is clearly more lean and less error-prone if the change can be conducted from the patient registration directly.

Axel Braun <coogor>
Group Member
Sun 08 Jan 2023 08:36:29 PM UTC, comment #1: 

Hi, Mathias, and happy 2023!

I put this feature a while ago (around 2013) to avoid modification / reassignment of the patient's related person see task https://savannah.gnu.org/task/?12714)

In the beginning, at the moment that the person was filled in, the patient could not be modified, even before saving it. We then optimized so it will become read-only at the moment of saving the initial patient record.

https://hg.savannah.gnu.org/hgweb/health/rev/f40b604be2a9


Bests,
Luis





Luis Falcon <meanmicio>
Group administrator
Fri 06 Jan 2023 07:43:42 PM UTC, original submission:  

The field name on gnuhealth.patient relating to party has defined states={'readonly': Eval('id', 0) > 0}. I would like to hear what is the reason behind this restriction which means that new parties can be created for patients, but as soon as they are saved, they can no more be edited from the patients view. I have no idea why the correction of party data should not be possible directly from the patient view in the same way as creation of parties is allowed. I think removing this restriction will result in a substantially improved user experience.

Mathias Behrle <yangoon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-10 meanmicio StatusNeed Info Works For Me
        Open/ClosedOpen Closed
    2023-01-09 meanmicio StatusNone Need Info
    2023-01-09 meanmicio Severity3 - Normal 1 - Wish
        Release4.1.0 4.3.0
    2023-01-09 coogor StatusWorks For Me None
    2023-01-08 meanmicio StatusNone Works For Me
        Assigned toNone meanmicio
        ReleaseNone 4.1.0
        ComponentNone Hospital Management

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code