Types of discrepancies: (assuming the OCHA source is the source of truth)
I found 2 duplicate sectional communales in the address hierarchy list
I found 1 section communale with the wrong section communale code
There are 3 records where there are double spaces in the section communale name
Each section communale in the address hierarchy has an ordinal prefix (1ère for primary, 2ème for second, etc) 114 of the 572 section communales are not matching the section communale code. In this case; “2ème Desdunes^544-01” the ordinal number in the code should be 1ère because the 544-01 code contains the ordinal number 01. (I’m not sure how important this is to fix)
Finally, there are 29 records where the Address hierarchy section communale name is completely different from the OCHA section communale name when matched by section communale code.
Here’s the link to my working spreadsheet. All discrepancies are listed in the Discrepancies worksheet following the numbers in this post. All other sheets are source materials and working sheets.
Which of these 5 items should we change? Do you agree that the OCHA source material should be the source of truth? Is there another source?
Hmmm… will need to look into this further, though it certainly wouldn’t shock me if our list had errors.
Unfortunately, once we decide what we do want, we will have to figure out the best way to get there… there isn’t a key relationship between person address and the address hierarchy, rather the full text address from the hierarchy in stored in the person address fields for a person with that address. So, unfortunately, if we change the text name of a hierarchy entry, it will no long be able to match it up with an existing record. (There may be some ways we can handle this, we will just need to give it some thought).
I’m sure there are also reporting changes as well. The site codes followed by the carrot ^ must be used to link data to map shapefiles somewhere downstream.
Hi @mogoodrich, it might be worth it running those address discrepancies by Brittany. She spent a significant amount of time while in Haiti reconciling all those different sources for addresses. We thought that at the time, in 2013, we had the source of truth for addresses in Central Plateau. It is possible some addresses might have changed since then.
It’s also available in this workbook.
I know these changes have implications for the data that’s already in the field deployed systems in Haiti. Let me know if this is something you would like to pursue, or if I should create a mechanism in HaitiCore to load this address hierarchy only for the iSantéPlus deployment.
We will want our Haiti team to review it, but my gut feeling is that we will want to migrate to this new version (or some other common version we standardize on), but, you are right… we will need to figure out how to handle data that is already in the field. We could migrate our existing data, or (probably more likely) just leave it as-is and train data clerks to correct issues as they come up, but I’ll have to do a little exploration first as to how the UI reacts when it encounters a address no (longer) in the hierarchy.
What’s your timeframe on this? Our whole team is heading to Malawi for a PIH meeting next week, then followed by the OpenMRS conference the week after, so not sure if we will be able to figure out exactly the best approach in the next couple weeks. Can you leave this in your own branch for now?
We’re building the demo servers this weekend with the pilot starting next week. We’re going to move forward with version 11, but there’s no rush and we’re happy to contribute on a combined version 12. Have a safe trip. @nathaelf and @jmaxy will be in Malawi.
Great, thanks… where are you keeping the fork with your changes? I could follow the link to your commit, but couldn’t figure out where it was coming from.
