"Atomic" data validation rules

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

Regards,
Jason

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

···

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

Regards,

Jason

···

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

I like it. A couple of ideas:

  • I suggest that this be a new property of validation rules, rather than a third type in addition to “Validation” and “Surveillance”. It could be potentially useful for either of these two rule types.

  • When selecting this option, the user could choose from a list of category combos that then appears on the add validation rule screen. (We could even present a list of category combos that are actually used by data elements.) This list could be used to filter the data elements available when creating the left and right sides, to make sure they all have the same combos.

Cheers,

Jim

···

On Fri, May 23, 2014 at 3:55 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

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

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

Hi Jim
Yes, I think I agree with you, but a still a bit fuzzy how it could happen with the current UI. I think the user would have an option like “Apply this rule to common category combo options”, and they would then select a left side, and the right side would only show data elements with the same category combo. The user would not select individual data elements. An operator would need to be selected as well, obviously.

For the use case we are dealing with, it is always comparing two data elements, one which is typically a subset of another, which is quite common in HIV M&E. Number counselled <= Number tested <= Number positive <= Number receiving results.

Regards,

Jason

···

On Fri, May 23, 2014 at 1:44 PM, Jim Grace jimgrace@gmail.com wrote:

I like it. A couple of ideas:

  • I suggest that this be a new property of validation rules, rather than a third type in addition to “Validation” and “Surveillance”. It could be potentially useful for either of these two rule types.
  • When selecting this option, the user could choose from a list of category combos that then appears on the add validation rule screen. (We could even present a list of category combos that are actually used by data elements.) This list could be used to filter the data elements available when creating the left and right sides, to make sure they all have the same combos.

Cheers,

Jim

On Fri, May 23, 2014 at 3:55 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

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

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

Hi Jason,

Here’s my idea: Add one extra field to ValidationRule, a reference to DataElementCategoryCombo. If this is null, it means no change from the current validation rule. If it’s not null, it means that the validation rule should be applied to all option combos within the category combo, for any data element(s) reference in the left and right side expressions.

On the New Validation Rule screen, add an option right below “Rule type” that selects whether or not this will be a “template” rule. (Except don’t use the word “template” – too technical.) Maybe like what you said, or “Apply rule to category combinations” (by default “No”). If “Yes” is selected, another option pops into visibility just below to choose a category combination. Once this is chosen, it is used to filter the list of data elements that will be available to the editor in “Edit left side” and “Edit right side”. Perhaps the “Edit left side” and “Edit right side” buttons should then be disabled until a category combination is chosen. Otherwise the UI is left the same – just the addition of these two fields and the data element filter. The user is free to make any expressions they want, but the data elements used on the left and right side must all have the same category combo.

From the software point of view this could be done much more simply in a single dropdown of category option combos; it’s a matter of the art of UI design to make this all somewhat intelligible to the user. The semantics would be that if you choose a combo, the data elements will be restricted to those having the combo and the rule will be multiplied by every combo option value. Using our pop-up contextual help feature on this screen (as well as in many other areas of the product) would assist usability a lot!

At validation rule execution time, some pre-processing is done in ValidationRunContext.java (to avoid processing things that are common to a validation run for each org unit / period). We could add an extra private method to this class that we could take each validation rule with a category option combo, and “multiply” it to make an in-memory validation rule (not persisted) for each category combo. This would be done by taking the left and right side expressions, looking for the data element tags inside the expression, and adding each category option combo, respectively, onto each data element tag. Then the validation run could proceed without any further modification.

Let me know what you think. I’m also happy to do the implementation if that makes sense; I’m familiar with the code and it should be pretty quick.

Cheers,

Jim

···

On Fri, May 23, 2014 at 9:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Jim
Yes, I think I agree with you, but a still a bit fuzzy how it could happen with the current UI. I think the user would have an option like “Apply this rule to common category combo options”, and they would then select a left side, and the right side would only show data elements with the same category combo. The user would not select individual data elements. An operator would need to be selected as well, obviously.

For the use case we are dealing with, it is always comparing two data elements, one which is typically a subset of another, which is quite common in HIV M&E. Number counselled <= Number tested <= Number positive <= Number receiving results.

Regards,

Jason

On Fri, May 23, 2014 at 1:44 PM, Jim Grace jimgrace@gmail.com wrote:

I like it. A couple of ideas:

  • I suggest that this be a new property of validation rules, rather than a third type in addition to “Validation” and “Surveillance”. It could be potentially useful for either of these two rule types.
  • When selecting this option, the user could choose from a list of category combos that then appears on the add validation rule screen. (We could even present a list of category combos that are actually used by data elements.) This list could be used to filter the data elements available when creating the left and right sides, to make sure they all have the same combos.

Cheers,

Jim

On Fri, May 23, 2014 at 3:55 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

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

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

I’m liking the simpler option of just adding one dropdown with category combinations, called something like “Repeat validation rule using”. The default dropdown selection could be something like “[ Use validation rule as is ]” or “[ Don’t repeat rule ]”. The following choices are the option combos: “Age”, “Sex”, “Age/Sex”, or whatever.

···

On Fri, May 23, 2014 at 2:07 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Jason,

Here’s my idea: Add one extra field to ValidationRule, a reference to DataElementCategoryCombo. If this is null, it means no change from the current validation rule. If it’s not null, it means that the validation rule should be applied to all option combos within the category combo, for any data element(s) reference in the left and right side expressions.

On the New Validation Rule screen, add an option right below “Rule type” that selects whether or not this will be a “template” rule. (Except don’t use the word “template” – too technical.) Maybe like what you said, or “Apply rule to category combinations” (by default “No”). If “Yes” is selected, another option pops into visibility just below to choose a category combination. Once this is chosen, it is used to filter the list of data elements that will be available to the editor in “Edit left side” and “Edit right side”. Perhaps the “Edit left side” and “Edit right side” buttons should then be disabled until a category combination is chosen. Otherwise the UI is left the same – just the addition of these two fields and the data element filter. The user is free to make any expressions they want, but the data elements used on the left and right side must all have the same category combo.

From the software point of view this could be done much more simply in a single dropdown of category option combos; it’s a matter of the art of UI design to make this all somewhat intelligible to the user. The semantics would be that if you choose a combo, the data elements will be restricted to those having the combo and the rule will be multiplied by every combo option value. Using our pop-up contextual help feature on this screen (as well as in many other areas of the product) would assist usability a lot!

At validation rule execution time, some pre-processing is done in ValidationRunContext.java (to avoid processing things that are common to a validation run for each org unit / period). We could add an extra private method to this class that we could take each validation rule with a category option combo, and “multiply” it to make an in-memory validation rule (not persisted) for each category combo. This would be done by taking the left and right side expressions, looking for the data element tags inside the expression, and adding each category option combo, respectively, onto each data element tag. Then the validation run could proceed without any further modification.

Let me know what you think. I’m also happy to do the implementation if that makes sense; I’m familiar with the code and it should be pretty quick.

Cheers,

Jim

On Fri, May 23, 2014 at 9:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Jim
Yes, I think I agree with you, but a still a bit fuzzy how it could happen with the current UI. I think the user would have an option like “Apply this rule to common category combo options”, and they would then select a left side, and the right side would only show data elements with the same category combo. The user would not select individual data elements. An operator would need to be selected as well, obviously.

For the use case we are dealing with, it is always comparing two data elements, one which is typically a subset of another, which is quite common in HIV M&E. Number counselled <= Number tested <= Number positive <= Number receiving results.

Regards,

Jason

On Fri, May 23, 2014 at 1:44 PM, Jim Grace jimgrace@gmail.com wrote:

I like it. A couple of ideas:

  • I suggest that this be a new property of validation rules, rather than a third type in addition to “Validation” and “Surveillance”. It could be potentially useful for either of these two rule types.
  • When selecting this option, the user could choose from a list of category combos that then appears on the add validation rule screen. (We could even present a list of category combos that are actually used by data elements.) This list could be used to filter the data elements available when creating the left and right sides, to make sure they all have the same combos.

Cheers,

Jim

On Fri, May 23, 2014 at 3:55 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

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

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

Hi Jim,

I also like the simpler option better (surprise). If the default option clearly states that there is no change then we are not forcing the users who do not need this feature to even understand it.

regards,

Lars

···

On Fri, May 23, 2014 at 11:05 PM, Jim Grace jimgrace@gmail.com wrote:

I’m liking the simpler option of just adding one dropdown with category combinations, called something like “Repeat validation rule using”. The default dropdown selection could be something like “[ Use validation rule as is ]” or “[ Don’t repeat rule ]”. The following choices are the option combos: “Age”, “Sex”, “Age/Sex”, or whatever.

On Fri, May 23, 2014 at 2:07 PM, Jim Grace jimgrace@gmail.com wrote:

Hi Jason,

Here’s my idea: Add one extra field to ValidationRule, a reference to DataElementCategoryCombo. If this is null, it means no change from the current validation rule. If it’s not null, it means that the validation rule should be applied to all option combos within the category combo, for any data element(s) reference in the left and right side expressions.

On the New Validation Rule screen, add an option right below “Rule type” that selects whether or not this will be a “template” rule. (Except don’t use the word “template” – too technical.) Maybe like what you said, or “Apply rule to category combinations” (by default “No”). If “Yes” is selected, another option pops into visibility just below to choose a category combination. Once this is chosen, it is used to filter the list of data elements that will be available to the editor in “Edit left side” and “Edit right side”. Perhaps the “Edit left side” and “Edit right side” buttons should then be disabled until a category combination is chosen. Otherwise the UI is left the same – just the addition of these two fields and the data element filter. The user is free to make any expressions they want, but the data elements used on the left and right side must all have the same category combo.

From the software point of view this could be done much more simply in a single dropdown of category option combos; it’s a matter of the art of UI design to make this all somewhat intelligible to the user. The semantics would be that if you choose a combo, the data elements will be restricted to those having the combo and the rule will be multiplied by every combo option value. Using our pop-up contextual help feature on this screen (as well as in many other areas of the product) would assist usability a lot!

At validation rule execution time, some pre-processing is done in ValidationRunContext.java (to avoid processing things that are common to a validation run for each org unit / period). We could add an extra private method to this class that we could take each validation rule with a category option combo, and “multiply” it to make an in-memory validation rule (not persisted) for each category combo. This would be done by taking the left and right side expressions, looking for the data element tags inside the expression, and adding each category option combo, respectively, onto each data element tag. Then the validation run could proceed without any further modification.

Let me know what you think. I’m also happy to do the implementation if that makes sense; I’m familiar with the code and it should be pretty quick.

Cheers,

Jim

On Fri, May 23, 2014 at 9:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Jim
Yes, I think I agree with you, but a still a bit fuzzy how it could happen with the current UI. I think the user would have an option like “Apply this rule to common category combo options”, and they would then select a left side, and the right side would only show data elements with the same category combo. The user would not select individual data elements. An operator would need to be selected as well, obviously.

For the use case we are dealing with, it is always comparing two data elements, one which is typically a subset of another, which is quite common in HIV M&E. Number counselled <= Number tested <= Number positive <= Number receiving results.

Regards,

Jason

On Fri, May 23, 2014 at 1:44 PM, Jim Grace jimgrace@gmail.com wrote:

I like it. A couple of ideas:

  • I suggest that this be a new property of validation rules, rather than a third type in addition to “Validation” and “Surveillance”. It could be potentially useful for either of these two rule types.
  • When selecting this option, the user could choose from a list of category combos that then appears on the add validation rule screen. (We could even present a list of category combos that are actually used by data elements.) This list could be used to filter the data elements available when creating the left and right sides, to make sure they all have the same combos.

Cheers,

Jim

On Fri, May 23, 2014 at 3:55 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Lars,
Finally got around to creating the blueprint here

https://blueprints.launchpad.net/dhis2/+spec/atomic-validation-rules

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

On Wed, Jan 15, 2014 at 6:36 PM, Lars Helge Øverland larshelge@gmail.com wrote:

Hi Jason,

yes I think this makes sense. One could make a special kind of validation rule, with a constraint that all data elements on the left and right side expressions share the same category combination, and then tell the system to validate each and every category option combination. Feel free to write a blueprint.

regards,

Lars

On Tue, Jan 14, 2014 at 3:52 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,
I came up against an issue today when looking at implementing a legacy database in DHIS2. In the old system, there are about 75 rules. The rules in the past have been applied at the atomic level, meaning that each and every data element category combination value is compared with a counter part. As an example.

Number of persons currently receiving ART (including pregnant women)

is greater than or equal to

Number of individuals NEWLY initiating ART (including pregnant women)

Each of these data elements are disaggregated by Gender and three age groups, and the validation rules need to be applied to each respective category combination options (not the totals).

Although I do not know exactly how many rules we would need to to this, it is surely at least several hundred. I have not really come up against this before, and need to see if anyone has expericience with how the system behaves with “large” numbers of rules.

I think it would be good to think about how to we could make the rules be applied within category combo options , without having to explicitly define each and every rule. Thoughts?

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

I also like the simpler option better (surprise).

WITYWS.

If the default option clearly states that there is no change then we are
not forcing the users who do not need this feature to even understand it.

Good. I think this will be a neat feature. The only challenges will be the
users understanding it. Will give my best shot a the the UI and the
documentation to facilitate this. :wink:

Sounds good to me as well and think it will be very useful.

Another feature we should probably think about as well, is extending this type of thing to indicators. We have forms where we need these validation rules, but also it would be neat to have indicators be also able to be defined by the pattern of the common category combos. As an example, consider below:

Number of people who tested HIV negative (by Male/Female + Age groups)

···

On Sun, May 25, 2014 at 9:47 PM, Jim Grace jimgrace@gmail.com wrote:

I also like the simpler option better (surprise).

WITYWS.

If the default option clearly states that there is no change then we are not forcing the users who do not need this feature to even understand it.

Good. I think this will be a neat feature. The only challenges will be the users understanding it. Will give my best shot a the the UI and the documentation to facilitate this. :wink: