Dear DHIS2 team,
A key property of the group set concept in DHIS2 is exclusivity. This is a serious limitation due to the fact that a health facility can belong more than one categories such as Cesarean Section, ORT, DOTS and so on. Could someone please explain the ways to address this issue?
Regards,
Chet Chaulagai
I think that a facility can have all of them as service areas with different datasets which are well assigned in DHIS so long as the datasets are put in DHIS. What the districts should do is to assign the different services to their facilities and a facility will have offering CS, ORT, DOTs and linked to also CUs .
regards
PEPELA WANJALA
MINISTRY OF HEALTH HEADQUARTERS
HEALTH INFORMATION SYSTEM
AFYA HOUSE, HIS LG 37
P.O BOX 30016, NAIROBI, KENYA
TEL: +254 (020) 2717077 EXT 45097
** CELL: +254 (0) 722375633 or 0202033363**
EMAIL: wanjala2p@yahoo.com
** hmis@health.go.ke**
From: Chet Chaulagai chaulagaichet@gmail.com
To: dhis2-devs@lists.launchpad.net
Sent: Saturday, August 6, 2011 11:40 PM
Subject: [Dhis2-devs] OrgUit groups and group sets
Dear DHIS2 team,
A key property of the group set concept in DHIS2 is exclusivity. This is a serious limitation due to the fact that a health facility can belong more than one categories such as Cesarean Section, ORT, DOTS and so on. Could someone please explain the ways to address this issue?
Regards,
Chet Chaulagai
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups or more general we can say health facility groups by considering at least one common attribute belongs to all facilities in that group, and criteria for selection could be anything like type of services offered (Cesarean Section Delivery, ORT, DOTS etc ) or geographical location or administrative regions etc. More precisely we can say, a group set in DHIS2 is always exclusive, which means that an orgunit (health facility) cannot be member of more than one such group in a group set. If you try otherwise you will get notified by the application and the action not allowed. It is possible to define whether a group set is compulsory or not, which will affect the completeness of the data when analyzing data using group sets. Compulsory means that ALL orgunits (health facility) must be member of a group in that group set.
Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela wanjala2p@yahoo.com wrote:
I think that a facility can have all of them as service areas with different datasets which are well assigned in DHIS so long as the datasets are put in DHIS. What the districts should do is to assign the different services to their facilities and a facility will have offering CS, ORT, DOTs and linked to also CUs .
regards
PEPELA WANJALA
MINISTRY OF HEALTH HEADQUARTERS
HEALTH INFORMATION SYSTEM
AFYA HOUSE, HIS LG 37
P.O BOX 30016, NAIROBI, KENYA
TEL: +254 (020) 2717077 EXT 45097
** CELL: +254 (0) 722375633 or 0202033363**
EMAIL: wanjala2p@yahoo.com
** hmis@health.go.ke**
From: Chet Chaulagai chaulagaichet@gmail.com
To: dhis2-devs@lists.launchpad.netSent: Saturday, August 6, 2011 11:40 PM
Subject: [Dhis2-devs] OrgUit groups and group sets
Dear DHIS2 team,
A key property of the group set concept in DHIS2 is exclusivity. This is a serious limitation due to the fact that a health facility can belong more than one categories such as Cesarean Section, ORT, DOTS and so on. Could someone please explain the ways to address this issue?
Regards,
Chet Chaulagai
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.netUnsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Regards,
Brajesh
Hi Brajesh,
Thank you very much for your clarification. As you said a health facility can be a member of only one group, this is the main limitation of this database. If I want to know the distribution of CS facilities or reporting coverage of CS facility, I would like to have all facilities offering CS services be grouped together. People interested in DOTS would like to do the same. The problem comes when one facility is providing the both services. You can place this facility either on DOTS or on CS category, not in both categories. This is the issue we need to address.
Regards,
Chet
On Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari brajesh2murari@gmail.com wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups or more general we can say health facility groups by considering at least one common attribute belongs to all facilities in that group, and criteria for selection could be anything like type of services offered (Cesarean Section Delivery, ORT, DOTS etc ) or geographical location or administrative regions etc. More precisely we can say, a group set in DHIS2 is always exclusive, which means that an orgunit (health facility) cannot be member of more than one such group in a group set. If you try otherwise you will get notified by the application and the action not allowed. It is possible to define whether a group set is compulsory or not, which will affect the completeness of the data when analyzing data using group sets. Compulsory means that ALL orgunits (health facility) must be member of a group in that group set.
Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela wanjala2p@yahoo.com wrote:
I think that a facility can have all of them as service areas with different datasets which are well assigned in DHIS so long as the datasets are put in DHIS. What the districts should do is to assign the different services to their facilities and a facility will have offering CS, ORT, DOTs and linked to also CUs .
regards
PEPELA WANJALA
MINISTRY OF HEALTH HEADQUARTERS
HEALTH INFORMATION SYSTEM
AFYA HOUSE, HIS LG 37
P.O BOX 30016, NAIROBI, KENYA
TEL: +254 (020) 2717077 EXT 45097
CELL: +254 (0) 722375633 or 0202033363
EMAIL: wanjala2p@yahoo.com
** hmis@health.go.ke**
From: Chet Chaulagai chaulagaichet@gmail.com
To: dhis2-devs@lists.launchpad.netSent: Saturday, August 6, 2011 11:40 PM
Subject: [Dhis2-devs] OrgUit groups and group sets
Dear DHIS2 team,
A key property of the group set concept in DHIS2 is exclusivity. This is a serious limitation due to the fact that a health facility can belong more than one categories such as Cesarean Section, ORT, DOTS and so on. Could someone please explain the ways to address this issue?
Regards,
Chet Chaulagai
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.netUnsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Regards,
Brajesh
Hi Chet
Hi Brajesh,
Thank you very much for your clarification. As you said a health facility
can be a member of only one group, this is the main limitation of this
database.
That's not my understanding. And if you read Brajesh carefully you
will see its not quite what he said.
An orgunit can be a member of any number of groups, including say DOTS and CS.
But the purpose of a groupset is to provide a dimension for the
orgunit. So you can't assign both of these groups to a single
groupset, say Service_Offered. Because if you think of a final report
table, Service_Offered would be a column name, the orgunit would be a
row and there's only one room for an answer at the intersection.
I'm guessing if you want see all of these services as columns for
analysis, you might want to create separate DOTS, CS etc groupsets.
Bob
On 9 August 2011 21:55, Chet Chaulagai <chaulagaichet@gmail.com> wrote:
If I want to know the distribution of CS facilities or reporting
coverage of CS facility, I would like to have all facilities offering CS
services be grouped together. People interested in DOTS would like to do the
same. The problem comes when one facility is providing the both services.
You can place this facility either on DOTS or on CS category, not in both
categories. This is the issue we need to address.
Regards,
ChetOn Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari <brajesh2murari@gmail.com> > wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups
or more general we can say health facility groups by considering at least
one common attribute belongs to all facilities in that group, and criteria
for selection could be anything like type of services offered (Cesarean
Section Delivery, ORT, DOTS etc ) or geographical location or administrative
regions etc. More precisely we can say, a group set in DHIS2 is always
exclusive, which means that an orgunit (health facility) cannot be member of
more than one such group in a group set. If you try otherwise you will get
notified by the application and the action not allowed. It is possible to
define whether a group set is compulsory or not, which will affect the
completeness of the data when analyzing data using group sets. Compulsory
means that ALL orgunits (health facility) must be member of a group in that
group set.Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela <wanjala2p@yahoo.com> >> wrote:
I think that a facility can have all of them as service areas with
different datasets which are well assigned in DHIS so long as the datasets
are put in DHIS. What the districts should do is to assign the different
services to their facilities and a facility will have offering CS, ORT, DOTs
and linked to also CUs .
regardsPEPELA WANJALA
MINISTRY OF HEALTH HEADQUARTERS
HEALTH INFORMATION SYSTEM
AFYA HOUSE, HIS LG 37
P.O BOX 30016, NAIROBI, KENYA
TEL: +254 (020) 2717077 EXT 45097
CELL: +254 (0) 722375633 or 0202033363
EMAIL: wanjala2p@yahoo.com
hmis@health.go.ke________________________________
From: Chet Chaulagai <chaulagaichet@gmail.com>
To: dhis2-devs@lists.launchpad.net
Sent: Saturday, August 6, 2011 11:40 PM
Subject: [Dhis2-devs] OrgUit groups and group setsDear DHIS2 team,
A key property of the group set concept in DHIS2 is exclusivity. This is
a serious limitation due to the fact that a health facility can belong more
than one categories such as Cesarean Section, ORT, DOTS and so on. Could
someone please explain the ways to address this issue?Regards,
Chet Chaulagai_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help--
Regards,
Brajesh_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
Hello Chet,
I think Mr. Wanjala answered properly.
Group capability in DHIS2 is not use for Service of Facility.
I know one facility has several services.
These services comes up as a dataset to be entered.
So, we assign these datasets along with services of the facilities,
properly.
Then we could get completeness report by dataset by organisation unit.
Regards,
Suzuki
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net] On Behalf
Of Chet Chaulagai
Sent: Tuesday, August 09, 2011 11:56 PM
To: Brajesh Murari
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group sets
Hi Brajesh,
Thank you very much for your clarification. As you said a health facility
can be a member of only one group, this is the main limitation of this
database. If I want to know the distribution of CS facilities or reporting
coverage of CS facility, I would like to have all facilities offering CS
services be grouped together. People interested in DOTS would like to do the
same. The problem comes when one facility is providing the both services.
You can place this facility either on DOTS or on CS category, not in both
categories. This is the issue we need to address.
Regards,
Chet
On Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari <brajesh2murari@gmail.com> wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups
or more general we can say health facility groups by considering at least
one common attribute belongs to all facilities in that group, and criteria
for selection could be anything like type of services offered (Cesarean
Section Delivery, ORT, DOTS etc ) or geographical location or administrative
regions etc. More precisely we can say, a group set in DHIS2 is always
exclusive, which means that an orgunit (health facility) cannot be member of
more than one such group in a group set. If you try otherwise you will get
notified by the application and the action not allowed. It is possible to
define whether a group set is compulsory or not, which will affect the
completeness of the data when analyzing data using group sets. Compulsory
means that ALL orgunits (health facility) must be member of a group in that
group set.
Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela <wanjala2p@yahoo.com> wrote:
I think that a facility can have all of them as service areas with different
datasets which are well assigned in DHIS so long as the datasets are put in
DHIS. What the districts should do is to assign the different services to
their facilities and a facility will have offering CS, ORT, DOTs and linked
to also CUs .
regards
PEPELA WANJALA
MINISTRY OF HEALTH HEADQUARTERS
HEALTH INFORMATION SYSTEM
AFYA HOUSE, HIS LG 37
P.O BOX 30016, NAIROBI, KENYA
TEL: +254 (020) 2717077 EXT 45097
<tel:%2B254%20%28020%29%202717077%20EXT%2045097>
CELL: +254 (0) 722375633 <tel:%2B254%20%280%29%20722375633> or 0202033363
EMAIL: wanjala2p@yahoo.com
hmis@health.go.ke
_____
Thanks everyone for health discussion
Dhis require upgrading to have service while registering new health facility using conventional naming. Regards
regards
On Wednesday, August 10, 2011, Shinichi Suzuki shin461@gmail.com wrote:
Hello Chet,
I think Mr. Wanjala answered properly.
Group capability in DHIS2 is not use for Service of Facility.
I know one facility has several services.
These services comes up as a dataset to be entered.
So, we assign these datasets along with services of the facilities, properly.
Then we could get completeness report by dataset by organisation unit.
Regards,
Suzuki
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net [mailto:dhis2-devs-bounces+shin461 <dhis2-devs-bounces%2Bshin461>=gmail.com@lists.launchpad.net] On Behalf Of Chet Chaulagai
Sent: Tuesday, August 09, 2011 11:56 PM
To: Brajesh Murari
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group sets
Hi Brajesh,
Thank you very much for your clarification. As you said a health facility can be a member of only one group, this is the main limitation of this database. If I want to know the distribution of CS facilities or reporting coverage of CS facility, I would like to have all facilities offering CS services be grouped together. People interested in DOTS would like to do the same. The problem comes when one facility is providing the both services. You can place this facility either on DOTS or on CS category, not in both categories. This is the issue we need to address.
Regards,
ChetOn Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari brajesh2murari@gmail.com wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups or more general we can say health facility groups by considering at least one common attribute belongs to all facilities in that group, and criteria for selection could be anything like type of services offered (Cesarean Section Delivery, ORT, DOTS etc ) or geographical location or administrative regions etc. More precisely we can say, a group set in DHIS2 is always exclusive, which means that an orgunit (health facility) cannot be member of more than one such group in a group set. If you try otherwise you will get notified by the application and the action not allowed. It is possible to define whether a group set is compulsory or not, which will affect the completeness of the data when analyzing data using group sets. Compulsory means that ALL orgunits (health facility) must be member of a group in that group set.
Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela wanjala2p@yahoo.com wrote:
I think that a facility can have all of them as service areas with different datasets which are well assigned in DHIS so long as the datasets are put in DHIS. What the districts should do is to assign the different services to their facilities and a facility will have offering CS, ORT, DOTs and linked to also CUs .
regards
PEPELA WANJALA
–
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338
Don’t Compromise The Quality! Don’t Risk It! apply Available Standards to Achieve Your/organizational Goal.
In fact, it is possible to assign an orgunit to two separate members
of an orgunit group set. If you create a group set "Services" you can
add the facility to multiple groups, but only through the Organisation
unit group management function, and not through the UI for the
organisation unit itself.
In this case, the "Services" groupset is not longer exclusive, meaning
that you might have a facility which belongs to both "DOTS" and "CS",
both of which belong to the "Services" group set.
The problem comes about in how DHIS2 generates the resource tables.
DHIS2 only takes one entry, and not both, so even though I may have
assigned a given orgunit to both "DOTS" and "CS", in the resource
tables, only "DOTS" appears under the "services" column.
This query will return a list of all groups a given orgunit belongs to
SELECT a.organisationunitid, a.name,c.* from organisationunit a
INNER JOIN orgunitgroupmembers b on a.organisationunitid = b.organisationunitid
INNER JOIN orgunitgroup c on b.orgunitgroupid = c.orgunitgroupid
If you assign an orgunit to multiple groups, there will be multiple
rows in this view, which would need to be carefully handled when
performing analyses in PivotTables, asit will lead duplication unless
the orgunit group column is separated into multiple columns or
seperate views are created for each orgunit group prior to feeding the
data to a PivotTable.
Regards,
Jason
On Wed, Aug 10, 2011 at 9:35 AM, samuel cheburet <samuelcheburet@gmail.com> wrote:
Thanks everyone for health discussion
Dhis require upgrading to have service while registering new health facility
using conventional naming. Regardsregards
On Wednesday, August 10, 2011, Shinichi Suzuki <shin461@gmail.com> wrote:
Hello Chet,
I think Mr. Wanjala answered properly.
Group capability in DHIS2 is not use for Service of Facility.
I know one facility has several services.
These services comes up as a dataset to be entered.
So, we assign these datasets along with services of the facilities,
properly.Then we could get completeness report by dataset by organisation unit.
Regards,
Suzuki
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461 <dhis2-devs-bounces%2Bshin461>=gmail.com@lists.launchpad.net]
On Behalf Of Chet Chaulagai
Sent: Tuesday, August 09, 2011 11:56 PM
To: Brajesh Murari
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group setsHi Brajesh,
Thank you very much for your clarification. As you said a health facility
can be a member of only one group, this is the main limitation of this
database. If I want to know the distribution of CS facilities or reporting
coverage of CS facility, I would like to have all facilities offering CS
services be grouped together. People interested in DOTS would like to do the
same. The problem comes when one facility is providing the both services.
You can place this facility either on DOTS or on CS category, not in both
categories. This is the issue we need to address.
Regards,
ChetOn Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari <brajesh2murari@gmail.com> >> wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups
or more general we can say health facility groups by considering at least
one common attribute belongs to all facilities in that group, and criteria
for selection could be anything like type of services offered (Cesarean
Section Delivery, ORT, DOTS etc ) or geographical location or administrative
regions etc. More precisely we can say, a group set in DHIS2 is always
exclusive, which means that an orgunit (health facility) cannot be member of
more than one such group in a group set. If you try otherwise you will get
notified by the application and the action not allowed. It is possible to
define whether a group set is compulsory or not, which will affect the
completeness of the data when analyzing data using group sets. Compulsory
means that ALL orgunits (health facility) must be member of a group in that
group set.Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela <wanjala2p@yahoo.com> >> wrote:
I think that a facility can have all of them as service areas with
different datasets which are well assigned in DHIS so long as the datasets
are put in DHIS. What the districts should do is to assign the different
services to their facilities and a facility will have offering CS, ORT, DOTs
and linked to also CUs .regards
PEPELA WANJALA
--
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338
Don't Compromise The Quality! Don't Risk It! apply Available Standards to
Achieve Your/organizational Goal._______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
In fact, it is possible to assign an orgunit to two separate members
of an orgunit group set. If you create a group set "Services" you can
add the facility to multiple groups, but only through the Organisation
unit group management function, and not through the UI for the
organisation unit itself.
Ah. That explains where these dodgy groupsets are coming from ....
On 10 August 2011 09:10, Jason Pickering <jason.p.pickering@gmail.com> wrote:
In this case, the "Services" groupset is not longer exclusive, meaning
that you might have a facility which belongs to both "DOTS" and "CS",
both of which belong to the "Services" group set.The problem comes about in how DHIS2 generates the resource tables.
DHIS2 only takes one entry, and not both, so even though I may have
assigned a given orgunit to both "DOTS" and "CS", in the resource
tables, only "DOTS" appears under the "services" column.This query will return a list of all groups a given orgunit belongs to
SELECT a.organisationunitid, a.name,c.* from organisationunit a
INNER JOIN orgunitgroupmembers b on a.organisationunitid = b.organisationunitid
INNER JOIN orgunitgroup c on b.orgunitgroupid = c.orgunitgroupidIf you assign an orgunit to multiple groups, there will be multiple
rows in this view, which would need to be carefully handled when
performing analyses in PivotTables, asit will lead duplication unless
the orgunit group column is separated into multiple columns or
seperate views are created for each orgunit group prior to feeding the
data to a PivotTable.Regards,
JasonOn Wed, Aug 10, 2011 at 9:35 AM, samuel cheburet > <samuelcheburet@gmail.com> wrote:
Thanks everyone for health discussion
Dhis require upgrading to have service while registering new health facility
using conventional naming. Regardsregards
On Wednesday, August 10, 2011, Shinichi Suzuki <shin461@gmail.com> wrote:
Hello Chet,
I think Mr. Wanjala answered properly.
Group capability in DHIS2 is not use for Service of Facility.
I know one facility has several services.
These services comes up as a dataset to be entered.
So, we assign these datasets along with services of the facilities,
properly.Then we could get completeness report by dataset by organisation unit.
Regards,
Suzuki
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461 <dhis2-devs-bounces%2Bshin461>=gmail.com@lists.launchpad.net]
On Behalf Of Chet Chaulagai
Sent: Tuesday, August 09, 2011 11:56 PM
To: Brajesh Murari
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group setsHi Brajesh,
Thank you very much for your clarification. As you said a health facility
can be a member of only one group, this is the main limitation of this
database. If I want to know the distribution of CS facilities or reporting
coverage of CS facility, I would like to have all facilities offering CS
services be grouped together. People interested in DOTS would like to do the
same. The problem comes when one facility is providing the both services.
You can place this facility either on DOTS or on CS category, not in both
categories. This is the issue we need to address.
Regards,
ChetOn Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari <brajesh2murari@gmail.com> >>> wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups
or more general we can say health facility groups by considering at least
one common attribute belongs to all facilities in that group, and criteria
for selection could be anything like type of services offered (Cesarean
Section Delivery, ORT, DOTS etc ) or geographical location or administrative
regions etc. More precisely we can say, a group set in DHIS2 is always
exclusive, which means that an orgunit (health facility) cannot be member of
more than one such group in a group set. If you try otherwise you will get
notified by the application and the action not allowed. It is possible to
define whether a group set is compulsory or not, which will affect the
completeness of the data when analyzing data using group sets. Compulsory
means that ALL orgunits (health facility) must be member of a group in that
group set.Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela <wanjala2p@yahoo.com> >>> wrote:
I think that a facility can have all of them as service areas with
different datasets which are well assigned in DHIS so long as the datasets
are put in DHIS. What the districts should do is to assign the different
services to their facilities and a facility will have offering CS, ORT, DOTs
and linked to also CUs .regards
PEPELA WANJALA
--
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338
Don't Compromise The Quality! Don't Risk It! apply Available Standards to
Achieve Your/organizational Goal._______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
Then this is a bug (thanks for mentioning it Jason). The intended design is to make all groupsets exclusive. I have been pushing for a better workflow in the UI for creating group sets and groups, and I really don’t see any need to create groups that are not member of any group set. If the workflow is group set → groups → assign orgunits it will be easier to enforce exclusiveness.
Orgunit groups are intended for aggregation and are therefore strictly organised in exclusive group sets (at least that is the idea). Right now such aggregation by groups (within each group set) is possible in pivot tables, and soon available also in report tables (see roadmap), and any non-exlusive groupset will cause duplication and confusion. This is not easily combined with a more free tagging functionality where multiple attributed are just added freely to an orgunit (e.g. multiple services).
As Suzuki mentioned, the reporting coverage is calculated automatically by DHIS in Completeness reports and this makes use of the assigned data sets per orgunit, not the groups.
We should perhaps look into how we can better support the concept of having multiple services linked to orguits, as there is not always a 1-1 link between data set and services (at least not a natural one), and as completeness is provided by data set this is sometimes a limitation. Still I see this as quite different from having “aggregation groups” and group sets, and I am not sure we can combine all this within the concept of orgunit groups.
The approach suggested by Jason is a hack and a workaround, and is not recommended practice (except maybe for a few experts like Jason who know exactly what they are doing, and my experience is that most people don’t…) since the risk of data duplication is so high.
To view geographical distribution of orgunits by services provided (and any other orgunit “categorisation”), e.g. to view all facilities that provide a service you can use the symbol layer in GIS, and for distribution in numbers and percentages you can use the orgunit distribution reports. These are both based on orgunit group sets, and the limitations listed before (only one group per orgunit per group set) are correct.
As Bob suggested you can create as many group sets as you like, e.g. create a group set “Emergency Obstetric Care” with groups ‘Basic’ and ‘Comprehensive’ and assign facilities to these two groups. Group sets do not have to be compulsory, so there is no need to assign e.g. facilities that are not providing the service, in this case obstetric care (so no need to have a group ‘None’). In GIS you can then select the Emergency Obstetric Care group set in the symbol layer and view locations of facilities with basic care and facilities with comprehensive care (with custom symbols for each group). It might seem tedious to create all these group sets, but the actual assigning of orgunits to groups, which is the main work here, will be the same.
Ola
On 10 August 2011 10:10, Jason Pickering jason.p.pickering@gmail.com wrote:
In fact, it is possible to assign an orgunit to two separate members
of an orgunit group set. If you create a group set “Services” you can
add the facility to multiple groups, but only through the Organisation
unit group management function, and not through the UI for the
organisation unit itself.
Ola
In this case, the “Services” groupset is not longer exclusive, meaning
that you might have a facility which belongs to both “DOTS” and “CS”,
both of which belong to the “Services” group set.
The problem comes about in how DHIS2 generates the resource tables.
DHIS2 only takes one entry, and not both, so even though I may have
assigned a given orgunit to both “DOTS” and “CS”, in the resource
tables, only “DOTS” appears under the “services” column.
This query will return a list of all groups a given orgunit belongs to
SELECT a.organisationunitid, a.name,c.* from organisationunit a
INNER JOIN orgunitgroupmembers b on a.organisationunitid = b.organisationunitid
INNER JOIN orgunitgroup c on b.orgunitgroupid = c.orgunitgroupid
If you assign an orgunit to multiple groups, there will be multiple
rows in this view, which would need to be carefully handled when
performing analyses in PivotTables, asit will lead duplication unless
the orgunit group column is separated into multiple columns or
seperate views are created for each orgunit group prior to feeding the
data to a PivotTable.
Regards,
Jason
On Wed, Aug 10, 2011 at 9:35 AM, samuel cheburet > > samuelcheburet@gmail.com wrote:
Thanks everyone for health discussion
Dhis require upgrading to have service while registering new health facility
using conventional naming. Regards
regards
On Wednesday, August 10, 2011, Shinichi Suzuki shin461@gmail.com wrote:
Hello Chet,
I think Mr. Wanjala answered properly.
Group capability in DHIS2 is not use for Service of Facility.
I know one facility has several services.
These services comes up as a dataset to be entered.
So, we assign these datasets along with services of the facilities,
properly.
Then we could get completeness report by dataset by organisation unit.
Regards,
Suzuki
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461 <dhis2-devs-bounces%2Bshin461>=gmail.com@lists.launchpad.net]
On Behalf Of Chet Chaulagai
Sent: Tuesday, August 09, 2011 11:56 PM
To: Brajesh Murari
Subject: Re: [Dhis2-devs] OrgUit groups and group sets
Hi Brajesh,
Thank you very much for your clarification. As you said a health facility
can be a member of only one group, this is the main limitation of this
database. If I want to know the distribution of CS facilities or reporting
coverage of CS facility, I would like to have all facilities offering CS
services be grouped together. People interested in DOTS would like to do the
same. The problem comes when one facility is providing the both services.
You can place this facility either on DOTS or on CS category, not in both
categories. This is the issue we need to address.
Regards,
Chet
On Tue, Aug 9, 2011 at 1:50 AM, Brajesh Murari brajesh2murari@gmail.com > > >> wrote:
Hi Chet,
In DHIS2, user have extensive space to make several kind of orgunit groups
or more general we can say health facility groups by considering at least
one common attribute belongs to all facilities in that group, and criteria
for selection could be anything like type of services offered (Cesarean
Section Delivery, ORT, DOTS etc ) or geographical location or administrative
regions etc. More precisely we can say, a group set in DHIS2 is always
exclusive, which means that an orgunit (health facility) cannot be member of
more than one such group in a group set. If you try otherwise you will get
notified by the application and the action not allowed. It is possible to
define whether a group set is compulsory or not, which will affect the
completeness of the data when analyzing data using group sets. Compulsory
means that ALL orgunits (health facility) must be member of a group in that
group set.
Regards,
Brajesh
On Mon, Aug 8, 2011 at 7:31 PM, wanjala pepela wanjala2p@yahoo.com > > >> wrote:
I think that a facility can have all of them as service areas with
different datasets which are well assigned in DHIS so long as the datasets
are put in DHIS. What the districts should do is to assign the different
services to their facilities and a facility will have offering CS, ORT, DOTs
and linked to also CUs .
regards
PEPELA WANJALA
–
Samuel Cheburet
Ministry Of Health
P.O. Box 20781
Nairobi, Kenya
Mobile- 0721624338
Don’t Compromise The Quality! Don’t Risk It! apply Available Standards to
Achieve Your/organizational Goal.
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devsMore help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Hi Ola,
I have been mulling this issue for a few days, and would like to
respond to a few things.
The approach suggested by Jason is a hack and a workaround, and is not
recommended practice (except maybe for a few experts like Jason who know
exactly what they are doing, and my experience is that most people don't...)
since the risk of data duplication is so high.
Actually, this is neither a hack or a workaround, but an unintended
feature of the UI/model. I am usually quite forward when it comes to
admitting when I hack DHIS. 
It is supported directly through the
UI, although the UI is inconsistent in places, since it is possible do
add an orgunit to multiple groups through the orgunit group editor,
but not possible through the orgunit editor.
What I failed to mention, and should have, is that assigning an
orgunit to multiple groups which belong to the same group set, will
result in a data integrity violation, which of course, should always
be checked to ensure that this type of situation does not happen.
I have been thinking about why this is actually an issue, and believe
it is actually the structure of the _orgunitgroupsetstructure resource
table. This table is crosstabbed by orgunit group set and therefore
assumes that the group membership is exclusive, at least the way it is
implemented currently. It is sounding more and more like group sets it
may not be, as I think we must sort of wiggle a bit when the
"Services" group set cannot contain "PMTCT" and "ART" and a single
facility can belong to both, depending on the services it offers.
Assuming that it did, the _orgunitgroupsetstructure table SHOULD (but
in fact does not, which I might regard as another bug) contain two
rows for this orgunit. However ,a _orgunitgroupstructure table could
be constructed, whereby orgunits are on the vertical axis, orgunit
groups in the horizontal (cross-tab) axis, with a boolean
representation (TRUE/FALSE) in order to indicate which orgunit group
the orgunit belongs to. This _orgunitgroupstructure table could then
be easily joined to the aggregated indicator/data value tables, and
would not result in a duplicated row, even if an orgunit belonged to
two separate orgunit groups.
I think we all agree that an orgunit can belong to more than one
orgunit groups, but I think the way the _orgunitgroupsetstructure
table has been traditionally used to join to the aggregated data, and
then to pull this into a PivotTable is the underlying problem. So, in
order to resolve that issue, orgunit group sets were made by default,
exclusive, when in fact they may not always be. There are examples
when they are, such as "Ownership".
Regards,
Jason
P.S. Bob, It is also beginning to feel as if orgunit groupsets may in
fact be concepts in disguise.
Hello Jason and Ola
I think Orgunit Groups keep exclusive and create "Service" witch allow
multiple.
Otherwise we will face confusion like as wrong usage or many erroneous.
Also, OrgUnit Group Edit function must be move under "Administration" to
protect data.
This function is very convenient but easy to corrupt data.
Best regards,
Shinichi
-----Original Message-----
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net] On Behalf
Of Jason Pickering
Sent: Friday, August 12, 2011 10:00 AM
To: Ola Hodne Titlestad
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group sets
Hi Ola,
I have been mulling this issue for a few days, and would like to respond to
a few things.
The approach suggested by Jason is a hack and a workaround, and is not
recommended practice (except maybe for a few experts like Jason who
know exactly what they are doing, and my experience is that most
people don't...) since the risk of data duplication is so high.
Actually, this is neither a hack or a workaround, but an unintended feature
of the UI/model. I am usually quite forward when it comes to admitting when
I hack DHIS. It is supported directly through the UI, although the UI is
inconsistent in places, since it is possible do add an orgunit to multiple
groups through the orgunit group editor, but not possible through the
orgunit editor.
What I failed to mention, and should have, is that assigning an orgunit to
multiple groups which belong to the same group set, will result in a data
integrity violation, which of course, should always be checked to ensure
that this type of situation does not happen.
I have been thinking about why this is actually an issue, and believe it is
actually the structure of the _orgunitgroupsetstructure resource table. This
table is crosstabbed by orgunit group set and therefore assumes that the
group membership is exclusive, at least the way it is implemented currently.
It is sounding more and more like group sets it may not be, as I think we
must sort of wiggle a bit when the "Services" group set cannot contain
"PMTCT" and "ART" and a single facility can belong to both, depending on the
services it offers.
Assuming that it did, the _orgunitgroupsetstructure table SHOULD (but in
fact does not, which I might regard as another bug) contain two rows for
this orgunit. However ,a _orgunitgroupstructure table could be constructed,
whereby orgunits are on the vertical axis, orgunit groups in the horizontal
(cross-tab) axis, with a boolean representation (TRUE/FALSE) in order to
indicate which orgunit group the orgunit belongs to. This
_orgunitgroupstructure table could then be easily joined to the aggregated
indicator/data value tables, and would not result in a duplicated row, even
if an orgunit belonged to two separate orgunit groups.
I think we all agree that an orgunit can belong to more than one orgunit
groups, but I think the way the _orgunitgroupsetstructure table has been
traditionally used to join to the aggregated data, and then to pull this
into a PivotTable is the underlying problem. So, in order to resolve that
issue, orgunit group sets were made by default, exclusive, when in fact they
may not always be. There are examples when they are, such as "Ownership".
Regards,
Jason
P.S. Bob, It is also beginning to feel as if orgunit groupsets may in fact
be concepts in disguise.
_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
Hi Shnichi,
I think in this case you are referring to OrgUnitGroup Sets. As others
have pointed out, a single orgunit can belong to any number of orgunit
groups. Making orgunit groups exclusive would imply that an orgunit
could never belong to more than one orgunit group.
I have sort of waffled back and forth on this issue, and I certainly
understand why in many cases group sets should be exclusive, as in
this case of "Ownership" or "Type", which by their nature are both
exclusive and compulsory. However, I am pretty convinced now of the
need for non-exclusive groups, even though it may be more
"inconvenient". I actually do not think it will be, but rather depends
on how the resource tables themselves are generated.
To illustrate this, another example which we have come across in
Nigeria is the "Implementing partner" group set. We may have multiple
IPs, each of which would be conducting some type of activity in
facilities. Each facility would need to be allocated to a particular
IP, but in some cases, there are multiple IPs which are conducting
different services.
This is not really an academic example, but rather a real one which
illustrates that orgunit groups sets are simply not always exclusive,
and they are not always services.
Regards,
Jason
On Fri, Aug 12, 2011 at 10:33 AM, Shinichi Suzuki <shin461@gmail.com> wrote:
Hello Jason and Ola
I think Orgunit Groups keep exclusive and create "Service" witch allow
multiple.
Otherwise we will face confusion like as wrong usage or many erroneous.
Also, OrgUnit Group Edit function must be move under "Administration" to
protect data.
This function is very convenient but easy to corrupt data.Best regards,
Shinichi-----Original Message-----
From: dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net
[mailto:dhis2-devs-bounces+shin461=gmail.com@lists.launchpad.net] On Behalf
Of Jason Pickering
Sent: Friday, August 12, 2011 10:00 AM
To: Ola Hodne Titlestad
Cc: dhis2-devs@lists.launchpad.net
Subject: Re: [Dhis2-devs] OrgUit groups and group setsHi Ola,
I have been mulling this issue for a few days, and would like to respond to
a few things.The approach suggested by Jason is a hack and a workaround, and is not
recommended practice (except maybe for a few experts like Jason who
know exactly what they are doing, and my experience is that most
people don't...) since the risk of data duplication is so high.Actually, this is neither a hack or a workaround, but an unintended feature
of the UI/model. I am usually quite forward when it comes to admitting when
I hack DHIS.
inconsistent in places, since it is possible do add an orgunit to multiple
groups through the orgunit group editor, but not possible through the
orgunit editor.What I failed to mention, and should have, is that assigning an orgunit to
multiple groups which belong to the same group set, will result in a data
integrity violation, which of course, should always be checked to ensure
that this type of situation does not happen.I have been thinking about why this is actually an issue, and believe it is
actually the structure of the _orgunitgroupsetstructure resource table. This
table is crosstabbed by orgunit group set and therefore assumes that the
group membership is exclusive, at least the way it is implemented currently.
It is sounding more and more like group sets it may not be, as I think we
must sort of wiggle a bit when the "Services" group set cannot contain
"PMTCT" and "ART" and a single facility can belong to both, depending on the
services it offers.
Assuming that it did, the _orgunitgroupsetstructure table SHOULD (but in
fact does not, which I might regard as another bug) contain two rows for
this orgunit. However ,a _orgunitgroupstructure table could be constructed,
whereby orgunits are on the vertical axis, orgunit groups in the horizontal
(cross-tab) axis, with a boolean representation (TRUE/FALSE) in order to
indicate which orgunit group the orgunit belongs to. This
_orgunitgroupstructure table could then be easily joined to the aggregated
indicator/data value tables, and would not result in a duplicated row, even
if an orgunit belonged to two separate orgunit groups.I think we all agree that an orgunit can belong to more than one orgunit
groups, but I think the way the _orgunitgroupsetstructure table has been
traditionally used to join to the aggregated data, and then to pull this
into a PivotTable is the underlying problem. So, in order to resolve that
issue, orgunit group sets were made by default, exclusive, when in fact they
may not always be. There are examples when they are, such as "Ownership".Regards,
JasonP.S. Bob, It is also beginning to feel as if orgunit groupsets may in fact
be concepts in disguise._______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
Hi Ola,
I have been mulling this issue for a few days, and would like to
respond to a few things.The approach suggested by Jason is a hack and a workaround, and is not
recommended practice (except maybe for a few experts like Jason who know
exactly what they are doing, and my experience is that most people don't...)
since the risk of data duplication is so high.Actually, this is neither a hack or a workaround, but an unintended
feature of the UI/model. I am usually quite forward when it comes to
admitting when I hack DHIS.
UI, although the UI is inconsistent in places, since it is possible do
add an orgunit to multiple groups through the orgunit group editor,
but not possible through the orgunit editor.What I failed to mention, and should have, is that assigning an
orgunit to multiple groups which belong to the same group set, will
result in a data integrity violation, which of course, should always
be checked to ensure that this type of situation does not happen.I have been thinking about why this is actually an issue, and believe
it is actually the structure of the _orgunitgroupsetstructure resource
table. This table is crosstabbed by orgunit group set and therefore
assumes that the group membership is exclusive, at least the way it is
implemented currently. It is sounding more and more like group sets it
may not be, as I think we must sort of wiggle a bit when the
"Services" group set cannot contain "PMTCT" and "ART" and a single
facility can belong to both, depending on the services it offers.
Assuming that it did, the _orgunitgroupsetstructure table SHOULD (but
in fact does not, which I might regard as another bug) contain two
rows for this orgunit. However ,a _orgunitgroupstructure table could
be constructed, whereby orgunits are on the vertical axis, orgunit
groups in the horizontal (cross-tab) axis, with a boolean
representation (TRUE/FALSE) in order to indicate which orgunit group
the orgunit belongs to. This _orgunitgroupstructure table could then
be easily joined to the aggregated indicator/data value tables, and
would not result in a duplicated row,
This is true. In some ways it feels we might have two colliding ideas
here. Intuitively it feels that orgunits should be able to be
assigned to any sort of group that a user deems is useful. And as you
point out, the UI supports that (I suspect this is legacy from
pre-groupset days). And that any group "could" be used as a column
(ie group could aslo be a concept name) of binary values which would
faciltate filtering.
But we also want to be able to categorize orgunits in non-binary terms
- the ownership example being a good one. We have successfully
mobilized the groupset idea to implement this - perhaps this could in
fact be implemented independently of the group idea ie. having a 1st
class coded dimension along the lines of a category.
Separating these two notions would meet all the requirements but
probably too much to consider when we have a model which does work at
present, albeit with caveats.
I wonder if Chet's problem is actually solved by NOT putting these
groups into a services groupset. After all, you only want to create a
groupset if you want to manufacture a coded dimension. It is not, as
the name might misleadingly imply, a general convenience for grouping
related groups. In which case there is no exclusivity concern.
Implying the added flexibility that groups can also be used as
concepts (column headers) in the resource table. This is probably
relatively simple sql - but would result in a very wide resource
table, The alternative workaround, for which gui already exists so
its a current workaround, is possibly my earlier suggestion of placing
such groups on their own into their own groupset for the purpose of
making an appearance in the resource table..
Bob
even if an orgunit belonged to
two separate orgunit groups.I think we all agree that an orgunit can belong to more than one
orgunit groups, but I think the way the _orgunitgroupsetstructure
table has been traditionally used to join to the aggregated data, and
then to pull this into a PivotTable is the underlying problem. So, in
order to resolve that issue, orgunit group sets were made by default,
exclusive, when in fact they may not always be. There are examples
when they are, such as "Ownership".Regards,
JasonP.S. Bob, It is also beginning to feel as if orgunit groupsets may in
fact be concepts in disguise.
True.
On 12 August 2011 07:59, Jason Pickering <jason.p.pickering@gmail.com> wrote:
_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help
Hi Bob,
I agree with your next point, to some extent.
But we also want to be able to categorize orgunits in non-binary terms
- the ownership example being a good one. We have successfully
mobilized the groupset idea to implement this - perhaps this could in
fact be implemented independently of the group idea ie. having a 1st
class coded dimension along the lines of a category.
However, thus my suggestion that the _orgunitgroupsetstructure should
ONLY contain exclusive group sets as columns. This is the only way it
makes any sense.
I wonder if Chet's problem is actually solved by NOT putting these
groups into a services groupset.
How would this be done? An orgunit group for each possible combination
of services, thereby ensuring exclusivity?
Sounds very painful and repitious when this should be able to be
accomplished through assignment to multiple orgunit groups.
This is probably
relatively simple sql - but would result in a very wide resource
table,
In fact, it would be require procedural code to produce the crosstab
(at least with Postgres) as is done with the resource tables. We have
no idea how many columns there would be prima facie. I am not sure
what "wide" actually means, and not sure it would be any "wider" than
creating a PMTCT orgunit group and a PMTCT orgunit group set and a ART
orgunit group and an ART orgunit groupset etc etc. Just seems
pointless when we know that in the case of services, implementing
partners, projects, programmes, etc we know there may be multiple
attributes associated with a particular orgunit.
The alternative workaround, for which gui already exists so
its a current workaround, is possibly my earlier suggestion of placing
such groups on their own into their own groupset for the purpose of
making an appearance in the resource table..
Yes, but this seems to be exactly the same as the proposed
_orgunitgroupstructure table which would require a separate exclusive
groupset for each possible group that the orgunit could belong to.
In a way, it sounds like we are debating the old issue with DHIS 1.4,
and exclusive and non-exclusive groupsets. I obviously do not know the
full history of why it was removed in both 1.4 and 2, but I am still
not convinced it was the right move.
Regards,
Jason
Hi,
Had a chat with Lars about this issue and we agreed that an OK solution that will meet most requirements here and also not require much development time will be to accept that orgunit groups can be used for both in group sets (exclusive only) AND for a more free tagging/categorisation purpose without group sets.
However, every group set must be exclusive, this way we know that we can aggregate data by each group in a group set which will be important when introduce group sets in report tables later this year, and this is also important for the group set resource table for pivots. This is the intended behavior today, but we need more strict control of group set exclusivity every time a group membership is added/edited.
For the “free” non-groupset groups it will be good if we can improve how we present orgunits in reports and on maps and make use of these group memberships (attributes) when listing information about an orgunit. E.g. when clicking on a point in the GIS all group memberships should be listed, and also improve orgunits distribution reports (reports module) to include filtered lists based on one or multiple groups, e.g. list all orgunits under a selected parent that is member of the group “CS”, or member of “PEPFAR” + “ART services” + “rural”. The result could then be a simple list of the orgunits meeting the criteria or aggregated numbers for each region etc.
I think this solution will provide the flexibility needed to cover all the mentioned use cases. The only drawback I can see for the “services provided” use case is that it will be impossible for DHIS to know which groups that actually represent a service, but that can be dealt with using naming conventions and custom report queries and views I think.
What do you guys think?
Ola
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo
Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
On 12 August 2011 14:02, Jason Pickering jason.p.pickering@gmail.com wrote:
Hi Bob,
I agree with your next point, to some extent.
But we also want to be able to categorize orgunits in non-binary terms
- the ownership example being a good one. We have successfully
mobilized the groupset idea to implement this - perhaps this could in
fact be implemented independently of the group idea ie. having a 1st
class coded dimension along the lines of a category.
However, thus my suggestion that the _orgunitgroupsetstructure should
ONLY contain exclusive group sets as columns. This is the only way it
makes any sense.
I wonder if Chet’s problem is actually solved by NOT putting these
groups into a services groupset.
How would this be done? An orgunit group for each possible combination
of services, thereby ensuring exclusivity?
Sounds very painful and repitious when this should be able to be
accomplished through assignment to multiple orgunit groups.
This is probably
relatively simple sql - but would result in a very wide resource
table,
In fact, it would be require procedural code to produce the crosstab
(at least with Postgres) as is done with the resource tables. We have
no idea how many columns there would be prima facie. I am not sure
what “wide” actually means, and not sure it would be any “wider” than
creating a PMTCT orgunit group and a PMTCT orgunit group set and a ART
orgunit group and an ART orgunit groupset etc etc. Just seems
pointless when we know that in the case of services, implementing
partners, projects, programmes, etc we know there may be multiple
attributes associated with a particular orgunit.
The alternative workaround, for which gui already exists so
its a current workaround, is possibly my earlier suggestion of placing
such groups on their own into their own groupset for the purpose of
making an appearance in the resource table…
Yes, but this seems to be exactly the same as the proposed
_orgunitgroupstructure table which would require a separate exclusive
groupset for each possible group that the orgunit could belong to.
In a way, it sounds like we are debating the old issue with DHIS 1.4,
and exclusive and non-exclusive groupsets. I obviously do not know the
full history of why it was removed in both 1.4 and 2, but I am still
not convinced it was the right move.
Regards,
Jason
Hi,
Had a chat with Lars about this issue and we agreed that an OK solution that will meet most requirements here and also not require much development time will be to accept that orgunit groups can be used for both in group sets (exclusive only) AND for a more free tagging/categorisation purpose without group sets.
Thats great and wounderful news…it seems, you are agreed that we should treet this issue as new enhancement for upcomming DHIS2 sprint relise rather than treating it as a architectual design bug anyway. This is a very good example for the modification/upgradation of a very spacial and rare use case design issue in DHIS2 which changes with respect to time with more fine grained refinment according to its new upgraded/modified usecase.
On Fri, Aug 12, 2011 at 6:48 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
However, every group set must be exclusive, this way we know that we can aggregate data by each group in a group set which will be important when introduce group sets in report tables later this year, and this is also important for the group set resource table for pivots. This is the intended behavior today, but we need more strict control of group set exclusivity every time a group membership is added/edited.
For the “free” non-groupset groups it will be good if we can improve how we present orgunits in reports and on maps and make use of these group memberships (attributes) when listing information about an orgunit. E.g. when clicking on a point in the GIS all group memberships should be listed, and also improve orgunits distribution reports (reports module) to include filtered lists based on one or multiple groups, e.g. list all orgunits under a selected parent that is member of the group “CS”, or member of “PEPFAR” + “ART services” + “rural”. The result could then be a simple list of the orgunits meeting the criteria or aggregated numbers for each region etc.
I think this solution will provide the flexibility needed to cover all the mentioned use cases. The only drawback I can see for the “services provided” use case is that it will be impossible for DHIS to know which groups that actually represent a service, but that can be dealt with using naming conventions and custom report queries and views I think.
What do you guys think?
Ola
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of OsloMobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
On 12 August 2011 14:02, Jason Pickering jason.p.pickering@gmail.com wrote:
Hi Bob,
I agree with your next point, to some extent.But we also want to be able to categorize orgunits in non-binary terms
- the ownership example being a good one. We have successfully
mobilized the groupset idea to implement this - perhaps this could infact be implemented independently of the group idea ie. having a 1st
class coded dimension along the lines of a category.
However, thus my suggestion that the _orgunitgroupsetstructure should
ONLY contain exclusive group sets as columns. This is the only way it
makes any sense.I wonder if Chet’s problem is actually solved by NOT putting these
groups into a services groupset.
How would this be done? An orgunit group for each possible combination
of services, thereby ensuring exclusivity?
Sounds very painful and repitious when this should be able to be
accomplished through assignment to multiple orgunit groups.This is probably
relatively simple sql - but would result in a very wide resource
table,
In fact, it would be require procedural code to produce the crosstab
(at least with Postgres) as is done with the resource tables. We haveno idea how many columns there would be prima facie. I am not sure
what “wide” actually means, and not sure it would be any “wider” than
creating a PMTCT orgunit group and a PMTCT orgunit group set and a ARTorgunit group and an ART orgunit groupset etc etc. Just seems
pointless when we know that in the case of services, implementing
partners, projects, programmes, etc we know there may be multiple
attributes associated with a particular orgunit.The alternative workaround, for which gui already exists so
its a current workaround, is possibly my earlier suggestion of placing
such groups on their own into their own groupset for the purpose ofmaking an appearance in the resource table…
Yes, but this seems to be exactly the same as the proposed
_orgunitgroupstructure table which would require a separate exclusive
groupset for each possible group that the orgunit could belong to.In a way, it sounds like we are debating the old issue with DHIS 1.4,
and exclusive and non-exclusive groupsets. I obviously do not know the
full history of why it was removed in both 1.4 and 2, but I am stillnot convinced it was the right move.
Regards,
Jason
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Regards,
Brajesh
Pardon.! there are some typographical mistakes in these following words in my recent reply on this mailing thread,
Thats, wounderful, treet, upcomming, relise, architectual, upgradation, refinment, usecase,
these should be like this,
That’s, wonderful, treat, upcoming, relies, architectural, up gradation, refinement, use case.
Thats great and wounderful news…it seems, you are agreed that we should treet this issue as new enhancement for upcomming DHIS2 sprint relise rather than treating it as a architectual design bug anyway. This is a very good example for the modification/upgradation of a very spacial and rare use case design issue in DHIS2 which changes with respect to time with more fine grained refinment according to its new upgraded/modified usecase.
Thats wounderful treet upcomming relise architectual upgradation refinment usecase.
On Wed, Aug 17, 2011 at 11:49 AM, Brajesh Murari brajesh2murari@gmail.com wrote:
On Fri, Aug 12, 2011 at 6:48 PM, Ola Hodne Titlestad olati@ifi.uio.no wrote:
Hi,
Had a chat with Lars about this issue and we agreed that an OK solution that will meet most requirements here and also not require much development time will be to accept that orgunit groups can be used for both in group sets (exclusive only) AND for a more free tagging/categorisation purpose without group sets.
Thats great and wounderful news…it seems, you are agreed that we should treet this issue as new enhancement for upcomming DHIS2 sprint relise rather than treating it as a architectual design bug anyway. This is a very good example for the modification/upgradation of a very spacial and rare use case design issue in DHIS2 which changes with respect to time with more fine grained refinment according to its new upgraded/modified usecase.
However, every group set must be exclusive, this way we know that we can aggregate data by each group in a group set which will be important when introduce group sets in report tables later this year, and this is also important for the group set resource table for pivots. This is the intended behavior today, but we need more strict control of group set exclusivity every time a group membership is added/edited.
For the “free” non-groupset groups it will be good if we can improve how we present orgunits in reports and on maps and make use of these group memberships (attributes) when listing information about an orgunit. E.g. when clicking on a point in the GIS all group memberships should be listed, and also improve orgunits distribution reports (reports module) to include filtered lists based on one or multiple groups, e.g. list all orgunits under a selected parent that is member of the group “CS”, or member of “PEPFAR” + “ART services” + “rural”. The result could then be a simple list of the orgunits meeting the criteria or aggregated numbers for each region etc.
I think this solution will provide the flexibility needed to cover all the mentioned use cases. The only drawback I can see for the “services provided” use case is that it will be impossible for DHIS to know which groups that actually represent a service, but that can be dealt with using naming conventions and custom report queries and views I think.
What do you guys think?
Ola
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of OsloMobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link
On 12 August 2011 14:02, Jason Pickering jason.p.pickering@gmail.com wrote:
Hi Bob,
I agree with your next point, to some extent.But we also want to be able to categorize orgunits in non-binary terms
- the ownership example being a good one. We have successfully
mobilized the groupset idea to implement this - perhaps this could infact be implemented independently of the group idea ie. having a 1st
class coded dimension along the lines of a category.
However, thus my suggestion that the _orgunitgroupsetstructure should
ONLY contain exclusive group sets as columns. This is the only way it
makes any sense.I wonder if Chet’s problem is actually solved by NOT putting these
groups into a services groupset.
How would this be done? An orgunit group for each possible combination
of services, thereby ensuring exclusivity?
Sounds very painful and repitious when this should be able to be
accomplished through assignment to multiple orgunit groups.This is probably
relatively simple sql - but would result in a very wide resource
table,
In fact, it would be require procedural code to produce the crosstab
(at least with Postgres) as is done with the resource tables. We haveno idea how many columns there would be prima facie. I am not sure
what “wide” actually means, and not sure it would be any “wider” than
creating a PMTCT orgunit group and a PMTCT orgunit group set and a ARTorgunit group and an ART orgunit groupset etc etc. Just seems
pointless when we know that in the case of services, implementing
partners, projects, programmes, etc we know there may be multiple
attributes associated with a particular orgunit.The alternative workaround, for which gui already exists so
its a current workaround, is possibly my earlier suggestion of placing
such groups on their own into their own groupset for the purpose ofmaking an appearance in the resource table…
Yes, but this seems to be exactly the same as the proposed
_orgunitgroupstructure table which would require a separate exclusive
groupset for each possible group that the orgunit could belong to.In a way, it sounds like we are debating the old issue with DHIS 1.4,
and exclusive and non-exclusive groupsets. I obviously do not know the
full history of why it was removed in both 1.4 and 2, but I am stillnot convinced it was the right move.
Regards,
Jason
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.netUnsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Regards,
Brajesh
–
Regards,
Brajesh