Thanks all, this makes things much clearer. I was loading data from a site survey into a new instance and it had type and owner, type I put in OrgUnit but I made a groupset for Owner. It will be easy to use the data in OrgUnit to make the Type groupset, I think one will suffice and the requiredness (requisitude?) will help. I appreciate all the examples.
···
From: Ola Hodne Titlestad [mailto:olatitle@gmail.com]
Sent: Tuesday, April 20, 2010 6:28 AM
To: Jason Pickering
Cc: Friedman, Roger (CDC/OID/NCHHSTP) (CTR); dhis2-users@lists.launchpad.net
Subject: Re: [Dhis2-users] Type
Hi,
Roger, to your point about “I already have Type in OrgUnit”, I must say I was actually surprised to find that Type field in the Orgunit object. Not sure why or when it was put there, but the main mechanism to analyse data by orgunits of different types are the orgunit group sets and groups. My advice would be to stay away from it.
DHIS 1.3 had a few static fields in the OrgUnit like Type, Ownership etc. but this quickly became a problem because different implementation sites required different ways of grouping orgunits. So the orgunit groups where introduced to provide more flexibility in tagging and categorising orgunits and later the group sets had to be introduced to control the way groups were used.
In order to make sure there were no duplicates in the pivot tables and other outputs filtered on groups the exclusive group sets were introduced to make sure an orgunit is only member of one of the groups that describe the topic/phenomena.
E.g. if you have rural and urban groups you do not want an orgunit to be member of both, and therefore you create a group set RuralUrban and add these two groups to it. Then you validate that each orgunit is only member of one of the groups in that group set. Optionally the group set can be compulsory as well, and then there is a validation that all orgunits are member of one and only one group in that group set.
These group sets then become useful dimensions to the data as you can easily pull them into pivot tables and other report and analysis tools. As Jason mentioned there are a few resource tables that help doing this, the organisationunitgroupsetstructure for orgunit group sets and two more for data elements and indicator group sets. These have to be populated through the UI options in Data Administration->Resource table. Have a look at the attached sql view that we use to more easily expose the data and the dimensions to e.g. Excel pivot tables. (if the attachment doesn’t come through I will send you in a separate email). The use of resource tables and views in combination works, but is a bit tricky right now (views needs to be dropped before updating the resource tables etc.), and needs some special attention. Read more about that here:
http://n2.nabble.com/Pivot-views-and-resource-tables-problem-when-updating-dropping-resource-tables-referenced-by-pivot-vs-td4461267.html#a4461267
For 2.0.5 we are looking into better functionality for automatically updating resource tables and built in view like the ones I have attached.
When it comes to one or more group sets for orgunit type I think both will work. In Sierra Leone we have used only one group set for type called Type, which is compulsory, and in there we have (Country, District,Chiefdom, Hospital, CHC, CHP, MCHP etc.), and the orgunit hierarchy is country-district-chiefdom-facility. What I found out is that we ended up only using this dimension when looking at data for the facility level since the other levels register very little data (and when looking at aggregated data for districts the facility type is no longer accessible anyway). So in practice we only use the types that describe different facilities and for that matter could have been a facility type group set. However, the advantage of having only one group set and making it compulsory is that we have an automated mechanisms to control that all new facilities actually are grouped by their type, and adding those upper levels to their groups is not that much work anyway.
We could possibly think of extending the compulsory functionality to be able to define a group set to be compulsory to a specific orgunit level only or only to leaf nodes?
Ola
Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897
Website: www.healthmetricsnetwork.org
Better Information. Better Decisions. Better Health.
On 20 April 2010 08:00, Jason Pickering jason.p.pickering@gmail.com wrote:
Hi Roger,
I am not 100% sure why or if this would be necessary. When you mean
“in order to use it for selection”, are you referring to selection in
a PivotTable view? A reference table
(_organisationunitgroupsetstructure) can be generated which will
provide the necessary data on the Group Set structure of
Organizational units. The other table (orgunitgroupmembers) and
(orgunitgroup) could be used in conjunction with this table to provide
different views and thus filters on the data. Both of these can be
used for different filtering/combination operations as needed in a
PivotTable view.
One of the key ideas behind groups sets, was the ability to combine
groups in different ways. One could them lump different orgunit
groups into a common set and then aggregate the data further in a view
or PivotTable (using the (_organisationunitgroupsetstructure) table.
So, if you have orgunitgroups (Urban Health Center, Rural Health
Center, Health Post, Hosptial Affiliated Health Center) these might be
grouped into a group set (Primary Health Care). You might have (First
level hospital, Second level hospital, Tertiary hospital, specialist
hospital) and group these into a group set (Hospital). This is my
understanding of the functionality at least. Of course, you would have
your compulsory group sets as well (Type, Ownership).
In our case here in Zambia, we have “subfacilities”, which function
essentially as wards within a facility. Examples are “Maternity”,
“OPD”, “Dental”,etc. These each belong to an orgunitgroupset
(Subfacility Type). So, I would say in your case yes, you would need
two separate group sets for facility type and activity type. Each of
these would be “non-compulsory” as they do not apply to all orgunits.
That is my recommendation, but Ola might have some views on this as well?
Regards,
Jason
On Mon, Apr 19, 2010 at 8:52 PM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR) rdf4@cdc.gov wrote:
Thanks, Jason.
I already have Type in OrgUnit and it breaks out as you suggest, it just occurred to me that I would have to replicate the information as a group set in order to use it for selection. I already have an Owner group set that works as you say. My level hierarchy is Country-Region-District-Subdistrict-Facility-Activity. In the OrgUnit.Type field, there are the first 4 levels and then multiple values at the facility (eg. hospital, clinic) and activity (eg. ANC clinic, ART clinic, lab, community-based C&T) level. So would you suggest a single Type groupset with all values or separate non-required groupsets for FacilityType and ActivityType?
Saludos, Roger
-----Original Message-----
From: Jason Pickering [mailto:jason.p.pickering@gmail.com]
Sent: Monday, April 19, 2010 1:30 PM
To: Friedman, Roger (CDC/OID/NCHHSTP) (CTR)
Cc: dhis2-users@lists.launchpad.net
Subject: Re: [Dhis2-users] Type
Hi Roger,
Typically, one would setup at least three groups 1) Type and 2)
Ownership and 3) Location. Often times type would be used to describe
National, Province, District, and then a facility type (Hospital,
Urban Health Center etc). Ownership would typically be Private,
Government, NGO, etc. Location would be something like Urban,
Peri-urban, Rural, Rural hard to reach, etc.
There are no hard and fast rules, but these are the ones that have
been used for sometime with both DHIS 1.4 and 2.
Regards,
Jason
On Mon, Apr 19, 2010 at 7:21 PM, Friedman, Roger (CDC/OID/NCHHSTP) > (CTR) rdf4@cdc.gov wrote:
Lists –
Is it good practice to set up a group that mirrors the values in
OrgUnit.Type?
Thanks, Roger
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp
–
–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190
–
–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190
Mailing list: https://launchpad.net/~dhis2-users
Post to : dhis2-users@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-users
More help : https://help.launchpad.net/ListHelp