Follow-up Comment #5, bug #63627 (project health):
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 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
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63627>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
