A couple of questions about the AH that is shipped with Haiti Core.
There is no reference to Haiti’s 42 arrondissements. It’s worth what it’s worth but Wikipedia (but also other sources) mentions that there is yet another layer in between départements and communes: the arrondissements.
Can anyone recall why those have not been included in the AH?
What exactly is localité habitation? Should this read like localité or habitation? Or is it a level that is well known and referred to locally as ‘localité habitation’?
address 3 ⊃ address 1 ⊃ address 2 It looks like the logical hierarchy was not followed in the choice of address fields numbering, see here. Is it because the one represented by address 3 was added later?
In order to achieve max. compliance with existing work in Haiti, should we stick to the same choices of address fields?
We chose not to use Arrondissements because it wasn’t a common level known to individuals who were entering data and it wasn’t captured in the original iSante.
The messages_fr.properties has it as Localité Habitation which is what iSantePlus prints in the UI. The PIH team uses themessages_ht.properties file which I think is Haitian Creole.
The Hierarchy goes Pays>Départment>Commune>Section communale>Localité Habitation>Adresse (in French). This is something iSante inhereted from PIH, so I don’t know the history. I recommend that you stick with these same versions. Also note that the addresshierarchy module is associated with haiticore, so you will get that as well.
Thanks @craigappl, everything good, the whole team is excited to be working on a large implementation in Northern Haiti!
In fact in French “localité habitation” doesn’t really mean anything (it’s just the association of two words that describe approaching concepts). I’m wondering whether it was just translated directly from the créole “localitie habitation”…
My actual question here is about the address fields that were mapped behind the scenes. There were chosen in disorder: address 3-1-2 (rather than 1-2-3). But that’s fine, we will use the same ones. That way at least our registration data will be directly compliant with the kind of data that is recorded in iSantéPlus.
Have you considered depending on and loading the Haiticore module in your implementation? The purpose was to make it so we could all just load in that module as a dependency of our configuration module and share the same core metadata.
Yes of course we did, and so far we have decided not to for a number of reasons.
Mekom has invested a lot in streamlining its delivery of OpenMRS/Bahmni across all its managed implementations. This is a vast subject and we hope -if we go to OMRS 2018- to show some of the end results to the community. But part of this end result leverages a certain way to package distributions with a fairly strict separation between modules and configuration.
Installing Haiti Core would contravene this pattern but that’s not a technical blocker (rather a philosophic one).
A clear cut reason of why we can’t just load Haiti Core as it is is because of the need to enable i18n support for metadata within Bahmni. Long story short (but I’m happy to expand on another thread on Ext I18N) this requires some quirks on how to manage names and descriptions on a whole host of metadata entities.
This would apply to all person attribute names (and descriptions), patient identifier type names (and descriptions)… etc.
As a middleground, we will attempt to remain as compliant as possible, going as far as keeping the same metadata UUIDs on our slightly modified versions of them. But simply just installing Haiti Core out of the box doesn’t seem possible at this point. I don’t like this situation, I certainly don’t like the fact that the first thing we do is diverge from a module that aimed to be a common ground in Haiti.
This is interesting. @mksd, let’s see if we can evolve things such that we can meet everyone’s needs. I wouldn’t assume that the haiticore module is stuck in it’s ways and can’t evolve if a better solution is found.
@mseaton we could showcase our progress when we are a bit further in a design call? I remember digging into PIH’s approach about i18n of metadata and it was quite witty. Furthermore I remember that I had come to the conclusion that it was possible for Ext I18N to handle both our design choice and PIH’s. But it’s not fresh anymore in my mind right now, I would need to get back to it again (and create a ticket).