bugGNU Health - Bugs: bug #63626, Improvements for address management

 
 

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

bug #63626: Improvements for address management

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

Sun 15 Jan 2023 12:41:22 PM UTC, comment #2: 

Hi Luis!

comment #1:

> Hi, Mathias!
>
> From our Wikibook GNU health chapter on DU, (https://en.wikibooks.org/wiki/GNU_Health/Domiciliary_Units), a Domiciliary Unit (DU) represents a human dwelling. It is composed of intra (domiciliary) and extra (peridomiciliary) spaces. The DU is a physical entity that denotes the place where one or more people live regularly.
>
> So, the DU is much more than just an address, and although they can complement each other, they are two different entities. The address is just one attribute from the many that the DU model. For example, the DU can not be a PO box.


Well, at the end you want to know where (and possibly how) the person/patient lives and can be contacted. It could be under a bridge and they could be travelling just using a post box etc. etc..

party.address and gnuhealth.du have so many fields in common that for me applies the same as in https://savannah.gnu.org/bugs/index.php?63627#comment5 for parties/patients. party.address should be extended to add the features of the domiciliary unit. It would reduce the place to manage those person related data to one canonical place and make superflouus the error prone synchronization of redundant models.

> We integrate the country and subdivision concept of the address in DU. Both the GNU Health DU and the Tryton address models have been there for many years. The Tryton address model has gone through quite a few changes throughout the versions, and we try to keep the compatibility without breaking the GH functionality.
>
> The DU needs to have a unique code. Many countries uniquely identify each property with a cadastral code, and can be incorporated to GH. In scenarios, where there is no formal identification of the DU / property, we could generate some ID when the field is left empty. I see this task more related to the localization effort for each country.


I wouldn't make the field generally required, but readonly when declared as an official cadastral code. I think most important and user friendly is a sensible rec_name for facile identification and search.

> The DU assignment to the person denotes the main residence. I agree we could think about using a O2M approach for multiple residences, and evaluate pros and cons (for instance, today the DU shows in realtime all the inhabitants at any given time of that residence). Currently, additional addresses can be entered in the person demographics, as addresses.


I currently see nothing that couldn't be implemented as extension of the party.address model.

Best,
Mathias

Mathias Behrle <yangoon>
Mon 09 Jan 2023 11:40:43 AM UTC, comment #1: 

Hi, Mathias!

From our Wikibook GNU health chapter on DU, (https://en.wikibooks.org/wiki/GNU_Health/Domiciliary_Units), a Domiciliary Unit (DU) represents a human dwelling. It is composed of intra (domiciliary) and extra (peridomiciliary) spaces. The DU is a physical entity that denotes the place where one or more people live regularly.

So, the DU is much more than just an address, and although they can complement each other, they are two different entities. The address is just one attribute from the many that the DU model. For example, the DU can not be a PO box.

We integrate the country and subdivision concept of the address in DU. Both the GNU Health DU and the Tryton address models have been there for many years. The Tryton address model has gone through quite a few changes throughout the versions, and we try to keep the compatibility without breaking the GH functionality.

The DU needs to have a unique code. Many countries uniquely identify each property with a cadastral code, and can be incorporated to GH. In scenarios, where there is no formal identification of the DU / property, we could generate some ID when the field is left empty. I see this task more related to the localization effort for each country.

The DU assignment to the person denotes the main residence. I agree we could think about using a O2M approach for multiple residences, and evaluate pros and cons (for instance, today the DU shows in realtime all the inhabitants at any given time of that residence). Currently, additional addresses can be entered in the person demographics, as addresses.

Let me know your thoughts.

Bests
Luis

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

GNUHealth has the concept of 'Domiciliary Unit' which is more a less an extension of party.address. For me there are some issues with the concept.

- gnuhealth.du duplicates the main fields of party.address which is unfortunate from the POV of database normalization
- gnuhealth.du lives in parallel with party.address, but without sync or relation of the two models. This may lead to quite unexpected results for the user, because if a party.address is added 'Main address' remains empty or shows something different.
- gnuhealth.du has exactly one required field: 'code'. It is painful and error prone to fill in this field with some meaningful and standardized data. I think this field could be removed and instead of 'code' a meaningful rec_name of the model could be constructed.
- It is only possible to define one DU per party. There are many cases where people live in several DUs.

I think gnuhealth.du would basically be better modelled as an extension of party.address, thus profiting from all features of the address model (like autocompletion of address data etc.) and reducing two models into one. This would also save the need of synchronization between the two parallel models which is currently missing.

What do you think?

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 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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-09 meanmicio Severity3 - Normal 1 - Wish
        StatusNone Need Info
        Assigned toNone meanmicio
        ReleaseNone 4.3.0
        ComponentNone Hospital Management

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code