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/
