Re: [Health-dev] [bug #63627] Problematic restriction for editing parties from the patients view

[Dr. Axel Braun]

Hi Luis,

Am Montag, 9. Januar 2023, 11:28:24 CET schrieb Luis Falcon:
 
> 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).

Clear, I had stated that as well.
 
> 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.

I fully understand that the link patient-party has to remain. Nevertheless it 
should be possible to edit details of the party afterwards, ideally coming 
from the patient view.
 
And we may even take a step further - when creating a patient, the party 
should be created in the background, so this is transparent to the user. The 
user does not care about the model party-patient - when he looks for 'Jane 
Doe' (and other criteria like DoB) he can either pick the existing dataset, or 
create a new one. ONE, not two (party and patient)

> 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.

Yes, and this is not questioned

> 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.

Looks like that goes into the same direction :-)

Cheers
Axel