Convert Admin: Facilities to use DHIS2 org hierarchy

[gmcressman]

• [x] Retrieve all of this information from the DHIS2 org structure.
• [ ] Admin setting to select admin level that corresponds to "Facility"?
• [ ] Display only one admin level above "Facility" level? If there is such a level?
• [ ] No "Aliases" field in DHIS2 org unit doc structure. Display and use "Description" field instead?
• [ ] Use"phonenumber field in DHIS2 org unit doc structure.
• [ ] "Type" doesn't exist in this simple way in DHIS2. This is normally implemented as an organisationUnitGroupSets to which organisationUnitGroups belong. Admin setting to select organisationUnitGroupSets to be displayed on this page?
• [ ] Admin option to turn off the ability to [add | edit | delete] anything on this page. This is needed to preserve interoperability with DHIS2.

[mikeymckay]

I have been thinking and researching how best to handle shehias and facilities. While we could manage shehias separately, I think it would be better to include them in the main hierarchy definition. I also think that this is a general issue that DHIS doesn't handle well since it is focused on aggregated data, but it is a critical issue for Coconut Surveillance. My current solution is to add another level (level 5) called Shehia that includes all shehias. Their parent will refer to level 3 (district), so effectively skipping level 4. I think this is valid, if not recommended, DHIS2 practice:

"Skipping geographical levels when mapping the reality to the DHIS 2 organisation unit hierarchy can be difficult and can easily lead to resistance among certain stakeholders, but one should have in mind that there are actually ways of producing reports based on geographical levels that are not part of the organisational hierarchy in DHIS 2, as will be explained in the next section." http://dhis2.github.io/dhis2-docs/master/en/implementer/html/ch10.html

I have already added shehias to my local copy of the DHIS export, but I believe they will require some kind of import step back into DHIS2 in order to generate valid ids.

In addition to allowing us to keep all of our hierarchical data in one place and in sync with DHIS2, I believe this will also allow us to report directly into DHIS2 in an accurate manner: cases found at facilities will be assigned to level 4, while new cases found at households will be assigned to their shehia (level 5).

[gmcressman]

I just added the Zone level (Unguja, Pemba) to dhis2.zanzibar.ictedge.org. I exported all organizational meta-data and just uploaded that to the Slack channel. This produces the following levels:

1. Ministry of Health
2. Zone
3. Region
4. District
5. Facility

Facility ownership is handled by an Organizational Group Set.

Yes, the problem that I ran into, and which you helped me with, is that the parent of a Facility is a District, and the parent of a Shehia is a District. DHIS2 doesn't have a way to handle that cleanly. Shehia, then, as you say, could be handled internally by adding Level 6, with Level 4 as its parent. In DHIS2, this will result in facilities and shehias mixed together when looking at the children of District. There will be no way to distinguish between them on many DHIS2 displays. I ran into this when assigning ownership to facilities. It's a real pain in DHIS2.

[mikeymckay]

In most cases we will be dealing with an instance of DHIS2 that has already been setup and probably will not be amenable to changes. According to the documentation I sent before there is no strong recommendation to have the lowest level be facility or village. From your experience it sounds like you have always seen facility as the lowest level. From what you are saying within DHIS2, it doesn't seem like a good idea to add a level 6 whose parent is level 4. Is that correct? My current implementation assumes this kind of skipped level. Would adding another group to specify "facilities" help solve the problem? It does seem like a poor mapping to have levels that are geographical and then one level that represents a facility.

The alternative is for Coconut Surveillance to add an additional layer of hierarchy. This was our original plan, but once I started working on it, I thought it would probably be better to try and do it within the DHIS2 framework.

The other alternative is to just abandon using the DHIS framework internally and parse it into what Coconut has been using.

I guess I am now leaning towards the 3rd option. My reasoning is that a DHIS2 hierarchy could be implemented in all sorts of different ways. Coconut's requirements are more rigid, so to support what is out there, we will probably need to write some kind of mapping translation that will vary from instance to instance..

[gmcressman]

I have several thoughts about this:

Using the DHIS2 JSON org structure internally, rather than our own unique structure, could have benefits that we are not aware of yet. For example, it may make it much simpler for us to send data element metadata and values to DHIS2. Also, the DHIS2 org structure has worked in more than 30 countries. Their UI has some solvable issues, but the structure still works.

Here are org-related blueprints for DHIS2: https://blueprints.launchpad.net/dhis2?searchtext=org

I don't see one that matches what I think is needed, but I may not understand them.

Just FYI, here are DHIS2 bugs related to the org hierarchy (whew): https://bugs.launchpad.net/dhis2/+bugs?field.searchtext=org&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=&orderby=status&start=0

In addition to the Shehia level, we also need the Village level. So, the existing DHIS2 org hierarchy in Zanzibar may look like this:

Existing:

1. Ministry of Health
2. Zone => 1
3. Region => 2
4. District => 3
5. Facility =>4

Needed (we need to add):

6. Shehia => 4
7. Village => 6

I will try to verify the existing structure.

One option may be for us to provide a way to add levels (e.g. 6 and 7) in Coconut Surveillance to the existing DHIS2 structure, but limit the data elements that we can transmit to DHIS2 to the org level aggregates that match the DHIS2 org unit levels. In the case of Zanzibar, that would mean that they could analyze data in Coconut Surveillance at all 7 levels listed above, but only transmit aggregate data to DHIS2 for levels 1-5. If they were to add levels 6 and 7 to their DHIS2 instance, then that would enable them to transmit data aggregated at those levels from Coconut Surveillance.

[gmcressman]

Most of this appears to be done. Let's review the checklist on this issue and what remains to be done in the Analytics app.