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:olati...@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: titlest...@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.picker...@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) <r...@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.picker...@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) <r...@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 >> <https://launchpad.net/%7Edhis2-users> >> Post to : dhis2-users@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-users >> <https://launchpad.net/%7Edhis2-users> >> More help : https://help.launchpad.net/ListHelp >> > > > > -- > -- > Jason P. Pickering > email: jason.p.picker...@gmail.com > tel:+260968395190 > > > -- -- Jason P. Pickering email: jason.p.picker...@gmail.com tel:+260968395190 _______________________________________________ Mailing list: https://launchpad.net/~dhis2-users <https://launchpad.net/%7Edhis2-users> Post to : dhis2-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-users <https://launchpad.net/%7Edhis2-users> More help : https://help.launchpad.net/ListHelp
_______________________________________________ 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
