Organisation unit maintenance¶

Organisation units and the organisation unit hierarchy is one of the foundational elements of the DHIS2 metadata and data model. They encapsulate geographical contexts like health facilities or schools and administrative areas, forming a single hierarchical structure that underpins every data value, tracked entity and tracker event. Organisation units are a key element of access control in DHIS2, as every user is linked to one or more organisation unit that controls what data they can see and/or edit. Organisation units are also a key element of any interoperability between DHIS2 and other systems, such as Electronic Medical Record systems, logistics platforms etc. In some cases, DHIS2 serves as the main source of truth for organisation units within a national architecture, whilst in other cases, there might be a dedicated facility registry from which DHIS2 should receive organisation unit updates.

Because of their importance, it is key to make good initial design of the organisation unit hierarchy and to make sure there is a clear governance structure and SOPs in place for management and maintenance of organisation units. This section is focused on topics related to the maintenance of organisation units over time.

Maintaining organisation unit groups and group sets¶

Organisation unit groups and group sets is a widely used and powerful feature of DHIS2 that can make available additional analytical dimension to any data. Common examples of this are Ownership (public, private, faith-based), Type (health centre, district hospital, tertiary hospital) and Urban/Rural, but any type of categorisation of organisation units could in theory be configured. When organisation unit group sets are used as data dimensions, this puts extra emphasis on maintenance of the groups that are part of the group sets. Specifically, to make sure that the numbers produced by analytics is correct, an organisation unit must not be member of more than one group in a group set, and any organisation unit that should be included in a disaggregation must be included in one group.

As an example, consider an organisation unit group set Ownership with three organisation unit groups Public, Private and Faith-based. If facility A is added to both the Private and Faith-based organisation unit groups, any analysis done using Ownership as a data dimension will not accurately reflect the data from facility A (data from that facility would end up in only one of the categories). If facility B is not added to any of the three groups, data from that facility would be left out whenever data is analysed with the Ownership dimension.

In summary, therefore, membership in organisation unit groups must be properly set up and maintained over time for these data dimensions to function as intended and produce correct results. It's important that SOPs on creation and modification of organisation units provide clear guidance on how to categorise organisation unit and what groups they should be added to. However, there is also a need to be able to monitor assignment to organisation unit groups in bulk. This can be done through the Data integrity function of the Data administration app, which includes several integrity checks related to organisation unit groups and group sets.

Managing changes to administrative areas¶

Over time, it is not uncommon that there are changes to the administrative boundaries of a country, e.g. the splitting or merging of districts or provinces. Some aspects of this does not require much work in terms of DHIS2 configuration. Notably, since data is primarily collected at the lowest level of the organisation unit hierarchy (e.g. health facilities or schools), the data will be correctly summed up in the hierarchy as facilities are moved between e.g. districts.

However, a downside to this is that once the changes to the organisation unit hierarchy has been made, it is no longer possible to analyse the aggregated numbers according to how they were before the change, which can be important if when looking at data from previous periods and/or other data sources. For example, if "District A" was split into "District A.1" and "District A.2" from January 2025 and DHIS2 is updated to reflect this, it might still be useful to be able to analyse the data for 2024 using "District A". This can be relevant for example if comparing the data to another data source, or analysing data related to reports and analysis done using the previous hierarchy. DHIS2 can be configured to support analysis of data using both the current and previous versions of the administrative hierarchy through the use of organisation unit groups and group sets:

• an organisation unit group set can be created to represent the administrative hierarchy at a certain point in time, e.g. "Districts before 2025". This should be enabled as a Data dimension
• an organisation unit group is created for each administrative unit at a certain point in time, e.g. "District A", "District B"
• every health facility or school is added to the group representing the administrative unit they were part of at that time.

After updating analytics, "Districts before 2025" will be available as a new data dimension in the DHIS2 analysis tools, and even as the administrative organisation units changes and facilities are moved between them, data can be analysed using the previous hierarchy. One limitation of this approach is that any indicators relying on data available only at the administrative level that is changed will not work (e.g. if district population estimates as used for coverage indicators).

While data from the lowest level (facilities) can be managed in a relatively straightforward way, any data collected at the administrative level must be dealt with separately. For example, if annual data on human resources is associated with a district, this data will not be accurate if the district is split and the DHIS2 organisation unit is reused for one of the new districts. Depending on the type of data and the changes to the administrative boundaries, this could be managed in different ways, for example trying to retroactively update the data, or producing a summary in an excel file and making that available as a DHIS2 file resource that users can access.

Of particular importance when it comes to data associated with administrative organisation units is denominator data such as population estimates, which is in many cases only available at e.g. district level and above. If the administrative organisation units in DHIS2 is changed but denominator data is not immediately available for the new administrative units, this can severely impede the analysis of data - by causing any indicators using these denominators not to be available at all, or worse, showing wrong numbers. Ideally, denominator data is made available for the new administrative units for the current and future periods, but when possible also retroactively to the last few periods to facilitate looking at trends over time.

Geographical coordinates are also a key consideration when making changes to administrative boundaries. If updated geographical coordinates are not available when changes to the administrative boundaries are applied in DHIS2, spatial analysis in the Maps application will not work or show wrong outputs. It is therefore strongly advised that if at all possible, shape files for the new boundaries are obtained and imported at the same time as changes to the administrative boundaries are made.

Shrnutí¶

• Most routine and case-based data will not be directly affected by changes to administrative areas/organisation units, since this is associated with the lowest-level organisation units (facilities, schools etc)
• Organisation unit groups and group sets can be used to make analysis of data based on previous/alternative administrative boundaries possible, with some limitations.
• Denominator data (e.g. population estimates) and geographical coordinates for the updated administrative areas should as far as possible be obtained before changes are made to organisation units in DHIS2, to avoid breaking analysis functionality.

Decentralising organisation unit management¶

The number of organisation units within a DHIS2 implementation varies greatly, but it is normal to have several thousand organisation units - up to tens of thousand in some cases. Managing these over time, including the correct assignment of data sets/tracker programmes and organisation unit group memberships can be challenging for a centralised (e.g. national) team of administrators.

To facilitate this, it is important that a mechanism is established for users at sub-national level, such as in the districts or health facilities, to request changes and updates to be made by the core DHIS2 team. This can be handled in different ways, e.g. using the DHIS2 messaging functionality, WhatsApp, mail, a google form etc - but it is critical that the process of requesting changes is well known for users.

A alternative solution to this is to decentralise the organisation unit management task to administrators at sub-national level more directly, e.g. provinces and districts. A system setting allows data set and programme assignment to be managed by users who only have edit rights to organisation units. While this is possible via the API, however, there is no way to achieve this through the Maintenance app unless the sub-national administrators are also given metadata edit rights to data sets/programmes, which is generally undesirable. This approach would thus require the development of a simple user interface (i.e. custom app) for decentralised admins to use.

Multiple organisation unit hierarchies¶

DHIS2 only supports a single organisation unit hierarchy in a tree structure, with a single root. Each organisation unit must have exactly one parent organisation unit, and users always see and have access to all organisation units in the branch of the hierarchy they have access to. For example, a user assigned to a province (level 2 in the hierarchy) will always have access to all districts (level 3) and facilities (level 4) within that province.

Sometimes, there's a need to collect or analyse data with a different reporting hierarchy; for example, the Ministry of Health might have a separate structure of health district than the administrative district used in general within the government, and there needs to be a way to aggregate and analyse data using both structures. Or there might be a need to include villages as data collection points, but without a clear relationship between villages and facilities.

Introducing additional or alternative hierarchy levels for analysis can often be achieved through the use of organisation unit groups and group sets. Using the example of separate health districts and administrative districts, the health districts could be configured as part of the organisation unit hierarchy, whilst the administrative districts could be configured as an organisation unit group set.

When a different hierarchy is needed for data collection at the lowest level which conflicts with the main hierarchy, it might be necessary to set up a separate instance of DHIS2 and include those organisation units there:

• Main instance: Country => Province => District = Health facility
• Alternative instance: Country => Province => District => Village

This introduces some additional overhead both in terms of infrastructure needs and system administration, but it might be a better approach than creating a combined hierarchy than can confuse end users and cause problems e.g. for analytics (both villages and facilities included by default in all reports etc).

If setting up a separate instance with an alternative hierarchy, there are some measures that can be taken to streamline the use of the system for end users. First, if the same users need to access both systems (i.e. a user should enter data both for facilities and villages), DHIS2 supports single sign-on through OIDC, so that users can move between the systems without logging in multiple times. An example tutorial of setting up DHIS2 with Okta as identify plaform is available here.

Secondly, the aggregate data exchange service can be used to routinely move data between instances so that integrated data analysis can be done within one instance. Continuing the example of villages and health facilities, data collected at the village level in one instance could be aggregated up to district level and then pushed to the instance with health facilities, so that any related data could be analysed in an integrated way.

Synchronising organisation units across DHIS2 instances¶

Many organisations implementing DHIS2 will need to deploy more than one production instance of DHIS2. Reasons for this might include performance (i.e. managing instance with high resource demands separately), privacy (i.e. limiting users in instance with sensitive data) or governance (i.e. different departments or units owning/managing the instance). However, it is common that most of these instances should use the same organisation unit hierarchy. While the different parallel hierarchies can be maintained manually by a team of administrators, given good routines that are followed closely, it can be advantageous to automate the synchronisation of organisation units between DHIS2 instances. This involves identifying one DHIS2 instance to act as the master organisation unit (facility) registry and setting up tools that ensures changes to organisation units in the master instance is replicated in other instances.

Organisation unit synchronisation functionality is not built into DHIS2 itself, but a reference implementation of organisation unit synchronisation using camel is available. While not ready to use directly out of the box, this provides a good starting point for implementing organisation unit synchronisation. There are also other tools developed in the DHIS2 community with some of the same functionality, such as the MFL Integrator tool developed by HISP Uganda.