Re-use of category options

Support - Assistance technique
1

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

categories_test (242 KB)

2

Thanks Jason I totaly agree with you there is need to explore all options to reuse the cateories and even data elements. regards

···

On Wednesday, August 10, 2011, Jason Pickering jason.p.pickering@gmail.com wrote:

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across

categories. With a bit of SQL applied to the database, I was able to
“reuse” a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the

re-use of the “0-4” category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data

for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which

  1. is not properly enforced because the restriction of a category
    option to a single category seems to be rather easily evaded
    or 2) should be relaxed/improved to allow the re-use of category
    options between categories.

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has

been raised several times.

Best regards,
Jason

–
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.

3

Hi

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

1. Don't have time to look at your sample, but I believe you.
2. The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE. Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}. But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name). So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :frowning:

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC. This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all. As you say the model rather easily
allows this retreat. But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

···

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

_______________________________________________
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

4

I think what you are implying here is that category options should
actually be derived from concepts.

We would start off be defining a concept, such as "Age" with all
possible category options.

We could define multiple categories, with the concept of "Age" and the
only available options would be from the "Age" concept.

Totally agree with that "0-4" should not appear in both an "Age" and a
"Gender" concept. This seems to make no sense what so sever. But 0-4
appearing in multiple categories does seem to make a lot of sense.

Regards,
Jason

···

On Wed, Aug 10, 2011 at 10:13 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

1. Don't have time to look at your sample, but I believe you.
2. The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE. Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}. But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name). So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :frowning:

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC. This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all. As you say the model rather easily
allows this retreat. But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

_______________________________________________
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

5

I think what you are implying here is that category options should
actually be derived from concepts.

We would start off be defining a concept, such as "Age" with all
possible category options.

We could define multiple categories, with the concept of "Age" and the
only available options would be from the "Age" concept.

Exactly. Plus generic ones. There are categoryoptions such as None,
Unknown etc which will likely be required across concepts. And in the
pivot table views you make use of the concept rather than the category
as column heading - in which case all your age categories fold
together so you can compare under 1's regardless of which category
they derive from.

I had originally thought that categoryoptions don't need a concept -
they would simply derive that from the category they are assigned to.
But in retrospect, it is actually much simpler to also associate the
categoryoptions with a concept so they will have a natural affinity
with the correct categories.

···

On 10 August 2011 10:28, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Totally agree with that "0-4" should not appear in both an "Age" and a
"Gender" concept. This seems to make no sense what so sever. But 0-4
appearing in multiple categories does seem to make a lot of sense.

Regards,
Jason

On Wed, Aug 10, 2011 at 10:13 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

1. Don't have time to look at your sample, but I believe you.
2. The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE. Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}. But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name). So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :frowning:

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC. This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all. As you say the model rather easily
allows this retreat. But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

_______________________________________________
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

6

Yes, this would seem to work. Not sure of the amount of work involved
in it of course.

Ola and I had a long chat this morning, with some of it devoted to
this and he brought up the important issue of deletion/editing. It
would seem that the rules should be such that category options cannot
be deleted from a concept, if they belong to a category, just like
now, it is now possible to delete category options from a given
category.

Ola also raised the point of a sort of _conceptstructure resource
table, which would basically consist of a coalesced view of the
current _categorystructure table, whereby all categories which belong
to a particular concept, would appear in a single table, which I think
would provide the view needed for the pivot table. See the attached
screen shots for what might work in this regard, simply by coalescing
the two "Age" categories together.

Regards,
Jason

image

image

···

On Wed, Aug 10, 2011 at 12:07 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 10 August 2011 10:28, Jason Pickering <jason.p.pickering@gmail.com> wrote:

I think what you are implying here is that category options should
actually be derived from concepts.

We would start off be defining a concept, such as "Age" with all
possible category options.

We could define multiple categories, with the concept of "Age" and the
only available options would be from the "Age" concept.

Exactly. Plus generic ones. There are categoryoptions such as None,
Unknown etc which will likely be required across concepts. And in the
pivot table views you make use of the concept rather than the category
as column heading - in which case all your age categories fold
together so you can compare under 1's regardless of which category
they derive from.

I had originally thought that categoryoptions don't need a concept -
they would simply derive that from the category they are assigned to.
But in retrospect, it is actually much simpler to also associate the
categoryoptions with a concept so they will have a natural affinity
with the correct categories.

Totally agree with that "0-4" should not appear in both an "Age" and a
"Gender" concept. This seems to make no sense what so sever. But 0-4
appearing in multiple categories does seem to make a lot of sense.

Regards,
Jason

On Wed, Aug 10, 2011 at 10:13 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

1. Don't have time to look at your sample, but I believe you.
2. The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE. Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}. But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name). So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :frowning:

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC. This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all. As you say the model rather easily
allows this retreat. But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

_______________________________________________
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

7

Yes, this would seem to work. Not sure of the amount of work involved
in it of course.

Ola and I had a long chat this morning, with some of it devoted to
this and he brought up the important issue of deletion/editing. It
would seem that the rules should be such that category options cannot
be deleted from a concept, if they belong to a category, just like
now, it is now possible to delete category options from a given
category.

Ola also raised the point of a sort of _conceptstructure resource
table, which would basically consist of a coalesced view of the
current _categorystructure table, whereby all categories which belong
to a particular concept, would appear in a single table, which I think
would provide the view needed for the pivot table. See the attached
screen shots for what might work in this regard, simply by coalescing
the two "Age" categories together.

Yes this is what I have been saying. At the point of analysis (the
pivot table dimensions) it is no longer of interest whether a figure
represents under ones captured in forms A, B or C in different
categories. Just the age is under 1.

The same logic also applies quite simply to other dimensions ie. those
derived from groupsets.

Imagine you have a number of dataelements wchich have been
disaggregated (using Mcdonalds categoryoptions) as Male and Female
under a Gender or Sex concept.

And you also have a bundle of "traditional" 1.4 style dataelements
where the sex is implicit in the name (Malaria_cases_male,
Malaria_cases_female). Then you would probably create a gender
groupset and group male and female dataelements this way. But ... if
your gender groupset could also implementing the Gender concept, then
this data would also be lined up in the same column as the
disaggregations from the categoryoptions. Whether the disaggregation
is done pre-hoc (mcdonalds) or post-hoc (groupsets) is not of interest
to one analyzing the pivot table.

Regards
Bob

···

On 10 August 2011 12:54, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Regards,
Jason

On Wed, Aug 10, 2011 at 12:07 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

On 10 August 2011 10:28, Jason Pickering <jason.p.pickering@gmail.com> wrote:

I think what you are implying here is that category options should
actually be derived from concepts.

We would start off be defining a concept, such as "Age" with all
possible category options.

We could define multiple categories, with the concept of "Age" and the
only available options would be from the "Age" concept.

Exactly. Plus generic ones. There are categoryoptions such as None,
Unknown etc which will likely be required across concepts. And in the
pivot table views you make use of the concept rather than the category
as column heading - in which case all your age categories fold
together so you can compare under 1's regardless of which category
they derive from.

I had originally thought that categoryoptions don't need a concept -
they would simply derive that from the category they are assigned to.
But in retrospect, it is actually much simpler to also associate the
categoryoptions with a concept so they will have a natural affinity
with the correct categories.

Totally agree with that "0-4" should not appear in both an "Age" and a
"Gender" concept. This seems to make no sense what so sever. But 0-4
appearing in multiple categories does seem to make a lot of sense.

Regards,
Jason

On Wed, Aug 10, 2011 at 10:13 AM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

Hi

On 10 August 2011 08:40, Jason Pickering <jason.p.pickering@gmail.com> wrote:

Dear DHIS2 devs,
While considering the email sent to the users list this morning (which
is a problem I have come up against several time) I wanted to
experiment with the possible re-use of category options across
categories. With a bit of SQL applied to the database, I was able to
"reuse" a category option between two separate categories. One age
group
was defined as 0-4, >5 and the other as 0-4,5-10, 11-15. Note the
re-use of the "0-4" category option between two seperate categories.
These two separate age categories were applied to a category
combination, and then applied to a dataset. I was able to enter data
for a test organisation unit and time period.

This leads me to beleive there is nothing wrong with the model, which
would not allow re-use of category options between categories, but
rather, it seems to be design issue which
1) is not properly enforced because the restriction of a category
option to a single category seems to be rather easily evaded
or 2) should be relaxed/improved to allow the re-use of category
options between categories.

1. Don't have time to look at your sample, but I believe you.
2. The approach I would like to see with re-use is to relax but not
completely collapse back to free-for-all. The sdmx approach, which I
believe is correct on this, is to assign a conceptname to a category.
eg AGE. Then you can have many different age categories with
different sets of (overlapping) categoryoptions, but they are all ages
ie. you should not be able to have a category with an option set like
{<1, 1-5, male, >5}. But you should be able to have two categories
like {<1, >=1} and {<1, 1-5, >5}.

There will also always be some generic cross-concept categoryoptions
which should be allowed in any category eg. 'None', 'Unknown' etc

Basically when I am composing an AGE category through the UI, I want
to see just the AGE related category options plus the generic ones.
Not a flat list of 200 categoryoptions.

A not insignificant fringe benefit of the conceptname in SDMX is that
it must also be an allowable XML attribute name (and thus most likely
a valid sql column name). So we avert manufacturing names which can
lead to PB&G and PB+G being reduced to the same thing (an earlier post
of yours).

But I've been saying this for some time and haven't got to doing
anything about it :frowning:

Agree the issue should be addressed urgently as users are finding all
sorts of "creative" ways of getting around the problem, including
making use of leading and trailing whitespace to differentiate between
categoryoptions which is really not good.

Perhaps a way forward is to give each categoryoption a conceptname
which defaults to GENERIC. This would allow it to be attached to any
category regardless of the category concept - thus reverting
effectively back to free for all. As you say the model rather easily
allows this retreat. But with a clear path back to sanity where we
can start to impose reasonable restrictions.

Cheers
Bob

Attached is the sample database (Postgres backup) which I created
during this experiment. Not sure by any means that everything works,
but it would be interesting to get comments on this issue, which has
been raised several times.

Best regards,
Jason

_______________________________________________
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

8

Hi,

agree that we need to improve on this. We have been discussing this a
lot and I think Bob describes very accurately how we are going to
implement it.

We already have quite a packed road map for the fall and I cannot
promise we will be able to accomplish this before 2.7 release in mid
Feb 2012, we will however try our best to get it done earlier.

I have written up a blueprint here, feel free to add to it:

https://blueprints.launchpad.net/dhis2/+spec/extend-category-and-groupsets-model-with-concepts

Regarding the method for re-using category options presented above, I
can only say it will confuse the system since it is mapped as a
one-to-many association and lead to undefined behavior, eg. removal of
categories will mess up other categories since category options are
assumed not be present in other categories; re-used category options
will be duplicated in lists and cause the import to crash etc.

Lars

9

Trying to ressurect this thread, as I am running into this issue again
of having the "same" category option in multiple categories. I am
still a bit befuddled why this restriction exists, but it looks like
it did not make into into 2.7. Any more thought around if and when it
might be implemented?

···

On Fri, Aug 12, 2011 at 3:07 PM, Lars Helge Øverland <larshelge@gmail.com> wrote:

Hi,

agree that we need to improve on this. We have been discussing this a
lot and I think Bob describes very accurately how we are going to
implement it.

We already have quite a packed road map for the fall and I cannot
promise we will be able to accomplish this before 2.7 release in mid
Feb 2012, we will however try our best to get it done earlier.

I have written up a blueprint here, feel free to add to it:

https://blueprints.launchpad.net/dhis2/+spec/extend-category-and-groupsets-model-with-concepts

Regarding the method for re-using category options presented above, I
can only say it will confuse the system since it is mapped as a
one-to-many association and lead to undefined behavior, eg. removal of
categories will mess up other categories since category options are
assumed not be present in other categories; re-used category options
will be duplicated in lists and cause the import to crash etc.

Lars

10

Hi, we have decided to make the category - category option
many-to-many again, which will make it possible to reuse options like
you suggested. It will be done for 2.10. Blueprint here:
https://blueprints.launchpad.net/dhis2/+spec/reuse-category-options

Lars