Can I have more than one Level 1 Org Unit in a single DHIS2 instance?

Implementation - Implémentation
1

Hi!

I hope I have put this question in the correct category.

Is it possible to have more than one Level 1 Org Unit in the same DHIS2 instance? If so, how do I do it?

Thanks!
Simon.

2

Hi Simon
Yes, it’s possible to have more than one root org unit. Here are the steps to create it:

  1. Import a new org unit without an ID for the parent.
  2. With user account that has ALL authority (superuser), login to the system and edit the account, assign the org unit for data entry.
    Once you have done step 2, you will be able to use the same account to assign the org unit to other accounts.
    Best regards,
    JM
2 Likes
3

Thanks @swoodworth for your question, and thanks @juan for the answer! :pray:

Interesting, @swoodworth, that you mention this and because we’re in the Implementation - Implémentation category it might be a good idea to mention the use case. Is this a good practice? Does it affect analytics? :+1:

2 Likes
4

@Gassim the use case is as follows: We’re building an eRegistry in the Northern Zone of Tanzania. I’m assembling an org unit hierarchy that reflects healthcare structures in Tanzania. But I’d like a separate hierarchy because part of the project involves users outside Tanzania assesing the program we develop to facilitate mobile data entry.

As Tanzania is divided into Zones at the highest level, would a better solution be to create a “Survey Zone” and confine those users there?

1 Like
5

I would take precautions if I were you. From what I have gathered, which I could be wrong, is that you want the program to be used within the Tanzanian hierarchy and other hierarchies.

As @Gassim pointed out, you need to consider what the implications are when you are at a point of analyzing your data. It might not be a good practice if you expect to analyze the data across all hierarchies.

3 Likes
6

I would also be very careful about creating multiple roots. The organization unit hierarchy is primarily a geographic hierarchy,and things can get very tricky down the road when you start mixing the projects organizationsl structure with district boundaries .

I would strongly encourage you to use a single root,even if in the context of your program,it does not actually exist.

3 Likes
7

Also for the part about external assessors,this may be able to be better accomplished with the use of an attribute option combo. It’s hard to know with out knowing more about your use case,but my gut feeling is that creating a split or parallel hierarchy may lead to issues in the long term.

2 Likes
8

Many thanks for all the useful responses. As the bottom level organisational unit is a Dispensary, I have created one called “Survey Dispensary” and I have restricted survey users outside the country to entering data against that unit only. This seems to be working well. I will of course have to exclude it from reporting later.

1 Like
9

Hi Simon,
Yeah that approach could work but not sure it’s the best way. It becomes a bit more complex to exclude this data since by default all data is aggregated in the organization unit dimension .

I might have considered to create a separate dataset,which basically would contain all data elements of the original dataset used by facility users, but with distinct data element names, perhaps with “External” appended to the original name. The external users would have access to that dataset,while the facility users would have access only to the original one.

The advantage here is that the data would never be aggregated together. It would also be easy to create indicators to compare facility values with external values.

I suspect the maintenance of another branch of the hierarchy will be more burdensome over time as well as creating problems with the aggregation of data.

Best regards,
Jason

1 Like