[Health-dev] [bug #63626] Improvements for address management

[Mathias Behrle]

Follow-up Comment #2, bug #63626 (project health):

Hi Luis!

[comment #1 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


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63626>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/