Once a categorycombo is created there is no way to add/remove a category/option into/from it.

Support - Assistance technique
1

Have been discussing this with Lars, and “not allowing to edit” is what we could come up at least for the time being.

We can think of allowing users to edit the members in the categorycombination - like adding/removing options or categories. But the question is what will be the consequence of doing this when data is already registered?

We can keep existing optioncombos, deal with all the internal complexities of extending/shrinking optioncombos by adding/removing options. Still the real challenge is what will happen to values previously registered? For example - assume the following

Malaria ( <5 ) = 50
Malaria ( >5 ) = 40

We have only one category Age with options <5 and >5. Next time you want to further break and come up with <5, 6-15, >15 or something like that - then what are we going to do with the values 50 and 40? Remove the values and record (rather collect) them again? Do we need to keep 50 and 40 for some reason (history?). If so how are we going to display them? because if we want to keep the old values and at the same time reflect the new changes - then we need to have a new set of optioncombos lined to the dataelement (in our case Malaria) so there is no way to refer to the old data because the dataelement is linked to the new optioncombo/categorycombo.

The way I see it by allowing adding/removing categories/options from categorycomobs/categories we will be inviting lots of complexities - so I think the best way is not to allow addition or removal.

Thank you

Abyot.

···

On Fri, Dec 4, 2009 at 3:13 PM, noreply@launchpad.net wrote:

revno: 1167

committer: Abyot Asalefew Gizaw abyota@gmail.com

branch nick: trunk

timestamp: Fri 2009-12-04 15:10:54 +0100

message:

Once a categorycombo is created there is no way to add/remove a category/option into/from it.

modified:

dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm

–

lp:dhis2

https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.

To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.

=== modified file ‘dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm’

— dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm 2009-10-20 12:49:32 +0000

+++ dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm 2009-12-04 14:10:54 +0000

@@ -37,7 +37,7 @@

   </tr>

   <tr>

            <td>

  •      <select size="15" id="availableList" name="availableList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'availableList' )">

  •      <select size="15" id="availableList" name="availableList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'availableList' )" disabled="disabled">


       #foreach ( $availableDataElementCategory in $allDataElementCategories )

         <option value="$availableDataElementCategory.id">$encoder.htmlEncode( $availableDataElementCategory.name )</option>

       #end

@@ -51,7 +51,7 @@

              <a href="#" onclick="moveDown('selectedList')"><img src="../images/move_down.png" border="0" alt=""></a>

     </td>

            <td>

  •      <select id="selectedList" name="selectedList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'selectedList' )">

  •      <select id="selectedList" name="selectedList" multiple="multiple" style="min-width:20em;height:20em">

       #foreach ( $dataElementCategory in $dataElementCategories )

         <option value="$dataElementCategory.id">$encoder.htmlEncode( $dataElementCategory.name )</option>

       #end

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

2

Hi,

I agree that it becomes very messy if the user can modify the categorycombo and thereby modifying the categoryoptioncombos directly linked to new values coming in.

Changes will happen over time, and often an annual revision of forms process is normal and there the dimensions to the data is likely to change. CategoryCombos is a way of navigating to the dimensional data we have in the system and changing these when there are data in the system will as you say make it difficult to both pull out data that has been stored with old version of a catcombo and do comparisons over time for data captured with new and old versions of a catcombo.

I suggest we make it possible to keep old versions of catcombos in the system as inactive in order to be able to look up historical data using catcombos, even though they are no longer actively used in data entry. The query to compare old and new will be complex, but still easier than not having a catcombo for your historical data at all. So I agree that we should lock catcombos for editing and deletion as soon as any of their catoptioncombos are used in a datavalue. As soon as there are no values attached to a catcombo it should be open for both edit and deletion.

There are however some use cases where it is very cumbersome not to be able to edit or delete catcombos and their categories and options. So when there are no values we should not lock this down I think. This will make the startup process easier, when you do a lot of trial and error on the metadata side before starting to collect data, and it will enable pruning of old stuff that you no longer need if you’re cleaning up an existing system.

Ola

···

2009/12/4 Abyot Gizaw abyota@gmail.com

Have been discussing this with Lars, and “not allowing to edit” is what we could come up at least for the time being.

We can think of allowing users to edit the members in the categorycombination - like adding/removing options or categories. But the question is what will be the consequence of doing this when data is already registered?

We can keep existing optioncombos, deal with all the internal complexities of extending/shrinking optioncombos by adding/removing options. Still the real challenge is what will happen to values previously registered? For example - assume the following

Malaria ( <5 ) = 50
Malaria ( >5 ) = 40

We have only one category Age with options <5 and >5. Next time you want to further break and come up with <5, 6-15, >15 or something like that - then what are we going to do with the values 50 and 40? Remove the values and record (rather collect) them again? Do we need to keep 50 and 40 for some reason (history?). If so how are we going to display them? because if we want to keep the old values and at the same time reflect the new changes - then we need to have a new set of optioncombos lined to the dataelement (in our case Malaria) so there is no way to refer to the old data because the dataelement is linked to the new optioncombo/categorycombo.

The way I see it by allowing adding/removing categories/options from categorycomobs/categories we will be inviting lots of complexities - so I think the best way is not to allow addition or removal.

Thank you

Abyot.

3

I got your point Abyot that we need to show the old data with old category options

But if there is another sistuation like I used to presented some weeks ago.

In the ICD 10 report

There are many data elements (about 300).

After collecting data some time, then the report add more column (which we will define new category options), these category options are not nested or nest any other category option (this can be understand as language and meaning) and we will continue collect data values with the old category options and new category options in the same data elements.

If there is not addition for category options, then how can I solve this problem?

It’s would be painful to

  • create new categories with new category options and new category combination and assign those to many data elements

If there is the solution that I can create new category with completely new categoy options, and then combine the old category with the new category to new category combination and assign to those 300 data elements again. But I don’t think this combination won’t mess up the structure of colums which we need to display in the report.

Please find enclosed the attached file to see the report.

···

–

Thuy
HISP Vietnam
+84902079126

4

Sorry, I forgot attach the file

image

···

–

Thuy
HISP Vietnam
+84902079126

5

Seem no one care about my idea.

Anyway, let time prove this.

And now, I have to create many dataelements with same same names for solve Vietnam problems. When DHIS2 improve this function, then we will see what to do that time.

···

–

Thuy
HISP Vietnam
+84902079126

6

Hi Thuy,

I think I understand your problem and I had a look at your report. Could you please translate the columnn headings for me, it’s been to long since I was in Vietnam. Still, from what I see in the columns and the few words I remember it seems the table represents one of those cases where there is no total for the row that sums up all the fields, I mean for every data element (disease) there is no total that is the sum of all the categoryoptioncombos (fields from both green and red).

As you say the new fields (green in your report) are not mixed with the old (the red), so in fact they should be two different categorycombos. CategoryCombos should represent a hierarchy where the total at the top/root should make sense. In your case it seems the total of green and red is not a real total that makes sense to use. The built-in logic of indicators, validation rules, report tables etc. in DHIS is very much built around data element totals, so having a data element total that does not make sense makes it difficult for you to make good use of the rest of the system. Then you end up with custom forms + tailored (developer) made reports in excel and that’s it, which might work of course, but a pitty thinking of all the other functionality you miss out on.

Any chance you could modify either the green or red so that they actually became the same? As far as I can see your are collecting both new cases and deaths for both clinics (green) and hospitals (red), but the agre breakups are different for the two. You collect children under 15 years total and <5 for red, but only children (no age specified) for green, is that correct? If it would be possible to collect <15 and <5 also in the green part it would be a lot easier for you.

The fact that you already have data for the red part and now want to start collecting for the green part as well, makes it more complicated. If you can make green and red the same then you could keep all the data with some tweaking and continue with another categorycomo with green+red, but if you need to keep them as they are in your report I would consider splitting up into 2 categprycombos and two data elements in stead.

If I was to design datasets based on this report without having to think about the data already in the system, a fresh start if you like, I would create two data element per disease (ICD code), 1) “ + Phong Kham)”, and 2) “ + Benh Nhan dieu tri”. And then I would create two categorycombos, one for the green and one for the red, and then assign data elements with the Phong Kham name to the green and data elements with the Benh Nhan name to the red. That would give you two datasets.

You could later design reports that would give you the exact same table, and with some changes to data entry forms (as in my previous suggestion to allow multiple datasets to 1 form) you could also create a custom form that would look like your report.

That probably didn’t help much…

Just note that having categorycombos that doesn’t make sense to add up as a total will not be very useful, except for allowing you to design the data entry form you need.

Another general comment would be to try to think of your paper forms as your outputs (reports) and not necessarily your inputs. Your DHIS data entry forms are your inputs and that they do not have to be exactly the same (although that is what the user will ask you for). If you need some of these data in other outputs, like an indicator to view on a map or in a chart, or another summary report, or in a pivot table, then you might have problems getting what you need because of the way you have designed your datasets, data elements, and dimensions.

If we can improve the data set + data entry forms model in DHIS 2 a bit to allow for multiple data sets (categorycombos) in one form, then we are much more free to design appropriate datasets (data elements with dimensions) that makes sense for data analysis and still be able to meet the users needs of having to make data entry forms look exactly like the paper forms.

With the current constraints of the 1-1 relationship between form and dataset we are struggling to make good use of the multidimensional model (because we put everything in one categorycombo to mimic the forms) for anything but data entry, unfortunately.

Ola

···

2009/12/4 Thuy Nguyen thuy.hispvietnam@gmail.com

I got your point Abyot that we need to show the old data with old category options
But if there is another sistuation like I used to presented some weeks ago.

In the ICD 10 report

There are many data elements (about 300).

After collecting data some time, then the report add more column (which we will define new category options), these category options are not nested or nest any other category option (this can be understand as language and meaning) and we will continue collect data values with the old category options and new category options in the same data elements.

If there is not addition for category options, then how can I solve this problem?

It’s would be painful to

  • create new categories with new category options and new category combination and assign those to many data elements

If there is the solution that I can create new category with completely new categoy options, and then combine the old category with the new category to new category combination and assign to those 300 data elements again. But I don’t think this combination won’t mess up the structure of colums which we need to display in the report.

Please find enclosed the attached file to see the report.

–

Thuy
HISP Vietnam
+84902079126

hI THUY

7

Hi Ola,

Thanks a lot for your replying.

First of all, I’d like to explain what I have done for that report. And how I use it in enter data and generate that report.

  1. About category and category combination

Because the previous DHIS has category combination defination by group of disease or somewhat total of many categoy options as you described. But this only useful in the perfect report which has only 1 total on the top of columns and its child are with same names.

That’s why my report can’t use this way. But still there is a solution by use what DHIS has. By creating each column is a category option. All of these category options will be group into 1 category. And this only 1 category would be included into 1 category combination. Last, this category combination would be assign to data element.

So if there is any addition of column. I just need to add 1 more category option. And this solve my problem. Although this is not the main rule of the developer who developed the category function.

  1. How to use these date elements to gather data.

Ofcouse the default data entry form wouldn’t look well.

So I design data entry form as the user report. then import these dataelement combinded with above category combination.

  1. Generate this report.

Because each data element can link to only 1 data element combination, so you gave an idea to create 2 data elements and link to other category combinations.

And reason why we can’t create 2 data elements with the name like +Categorycombination1 , and +Categorycombination2

As in the excel report module.

There is the category type, and org unit type. We can generate the list of data element names, list of data values (which are combination between data element and category options) automatically.

And creating 2 data elements for these 2 category combinations would make the report look very funny with list of dataelements has same same names

So I just have a require to have addition new category options to category. People should know the rule to use, and avoid make the system mess up. And others can use it by different ways to serve their purposes. Just like the tailor make a curtain for putting on the window , but some other users buy it and have right to use it as blanket on the bed.

Anyway, I edited that report(adding new category options) by using the previous version of DHIS2. and then use data base in the new version. I just want to mention the sistuation may appear again in the future.

Again thanks for your replying and long email.

Hi Thuy,

I think I understand your problem and I had a look at your report. Could you please translate the columnn headings for me, it’s been to long since I was in Vietnam. Still, from what I see in the columns and the few words I remember it seems the table represents one of those cases where there is no total for the row that sums up all the fields, I mean for every data element (disease) there is no total that is the sum of all the categoryoptioncombos (fields from both green and red).

As you say the new fields (green in your report) are not mixed with the old (the red), so in fact they should be two different categorycombos. CategoryCombos should represent a hierarchy where the total at the top/root should make sense. In your case it seems the total of green and red is not a real total that makes sense to use. The built-in logic of indicators, validation rules, report tables etc. in DHIS is very much built around data element totals, so having a data element total that does not make sense makes it difficult for you to make good use of the rest of the system. Then you end up with custom forms + tailored (developer) made reports in excel and that’s it, which might work of course, but a pitty thinking of all the other functionality you miss out on.

Any chance you could modify either the green or red so that they actually became the same? As far as I can see your are collecting both new cases and deaths for both clinics (green) and hospitals (red), but the agre breakups are different for the two. You collect children under 15 years total and <5 for red, but only children (no age specified) for green, is that correct? If it would be possible to collect <15 and <5 also in the green part it would be a lot easier for you.

The fact that you already have data for the red part and now want to start collecting for the green part as well, makes it more complicated. If you can make green and red the same then you could keep all the data with some tweaking and continue with another categorycomo with green+red, but if you need to keep them as they are in your report I would consider splitting up into 2 categprycombos and two data elements in stead.

Yes I want to keep green+red together when enter data and generate as well.

If I was to design datasets based on this report without having to think about the data already in the system, a fresh start if you like, I would create two data element per disease (ICD code), 1) “ + Phong Kham)”, and 2) “ + Benh Nhan dieu tri”. And then I would create two categorycombos, one for the green and one for the red, and then assign data elements with the Phong Kham name to the green and data elements with the Benh Nhan name to the red. That would give you two datasets.

No. It would be difficult for generate report later. Special in using Excel report module.

···

On Mon, Dec 7, 2009 at 3:59 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

You could later design reports that would give you the exact same table, and with some changes to data entry forms (as in my previous suggestion to allow multiple datasets to 1 form) you could also create a custom form that would look like your report.

That probably didn’t help much…

Just note that having categorycombos that doesn’t make sense to add up as a total will not be very useful, except for allowing you to design the data entry form you need.

Another general comment would be to try to think of your paper forms as your outputs (reports) and not necessarily your inputs. Your DHIS data entry forms are your inputs and that they do not have to be exactly the same (although that is what the user will ask you for). If you need some of these data in other outputs, like an indicator to view on a map or in a chart, or another summary report, or in a pivot table, then you might have problems getting what you need because of the way you have designed your datasets, data elements, and dimensions.

If we can improve the data set + data entry forms model in DHIS 2 a bit to allow for multiple data sets (categorycombos) in one form, then we are much more free to design appropriate datasets (data elements with dimensions) that makes sense for data analysis and still be able to meet the users needs of having to make data entry forms look exactly like the paper forms.

With the current constraints of the 1-1 relationship between form and dataset we are struggling to make good use of the multidimensional model (because we put everything in one categorycombo to mimic the forms) for anything but data entry, unfortunately.

Ola

–

Thuy
HISP Vietnam
+84902079126

8

Hi Thuy,
I am very curious about this mail, but unfortunately, cannot really
follow very well. Could you let us know what the translations are? I
think it would make a lot more sense to those of us that do not speak
Vietnamese, and we might be able to provide some more guidance.

Regards,
Jason

···

On Mon, Dec 7, 2009 at 12:09 PM, Thuy Nguyen <thuy.hispvietnam@gmail.com> wrote:

Hi Ola,
Thanks a lot for your replying.
First of all, I'd like to explain what I have done for that report. And how
I use it in enter data and generate that report.
1. About category and category combination
Because the previous DHIS has category combination defination by group of
disease or somewhat total of many categoy options as you described. But this
only useful in the perfect report which has only 1 total on the top of
columns and its child are with same names.
That's why my report can't use this way. But still there is a solution by
use what DHIS has. By creating each column is a category option. All of
these category options will be group into 1 category. And this only 1
category would be included into 1 category combination. Last, this category
combination would be assign to data element.
So if there is any addition of column. I just need to add 1 more category
option. And this solve my problem. Although this is not the main rule of the
developer who developed the category function.
2. How to use these date elements to gather data.
Ofcouse the default data entry form wouldn't look well.
So I design data entry form as the user report. then import these
dataelement combinded with above category combination.
3. Generate this report.
Because each data element can link to only 1 data element combination, so
you gave an idea to create 2 data elements and link to other category
combinations.
And reason why we can't create 2 data elements with the name like
<dataelement>+Categorycombination1 , and <dataelement>+Categorycombination2
As in the excel report module.
There is the category type, and org unit type. We can generate the list of
data element names, list of data values (which are combination between data
element and category options) automatically.
And creating 2 data elements for these 2 category combinations would make
the report look very funny with list of dataelements has same same names
So I just have a require to have addition new category options to category.
People should know the rule to use, and avoid make the system mess up. And
others can use it by different ways to serve their purposes. Just like the
tailor make a curtain for putting on the window , but some other users buy
it and have right to use it as blanket on the bed.
Anyway, I edited that report(adding new category options) by using the
previous version of DHIS2. and then use data base in the new version. I
just want to mention the sistuation may appear again in the future.
Again thanks for your replying and long email.

On Mon, Dec 7, 2009 at 3:59 PM, Ola Hodne Titlestad <olatitle@gmail.com> > wrote:

Hi Thuy,

I think I understand your problem and I had a look at your report. Could
you please translate the columnn headings for me, it's been to long since I
was in Vietnam. Still, from what I see in the columns and the few words I
remember it seems the table represents one of those cases where there is no
total for the row that sums up all the fields, I mean for every data element
(disease) there is no total that is the sum of all the categoryoptioncombos
(fields from both green and red).

As you say the new fields (green in your report) are not mixed with the
old (the red), so in fact they should be two different categorycombos.
CategoryCombos should represent a hierarchy where the total at the top/root
should make sense. In your case it seems the total of green and red is not a
real total that makes sense to use. The built-in logic of indicators,
validation rules, report tables etc. in DHIS is very much built around data
element totals, so having a data element total that does not make sense
makes it difficult for you to make good use of the rest of the system. Then
you end up with custom forms + tailored (developer) made reports in excel
and that's it, which might work of course, but a pitty thinking of all the
other functionality you miss out on.

Any chance you could modify either the green or red so that they actually
became the same? As far as I can see your are collecting both new cases and
deaths for both clinics (green) and hospitals (red), but the agre breakups
are different for the two. You collect children under 15 years total and <5
for red, but only children (no age specified) for green, is that correct? If
it would be possible to collect <15 and <5 also in the green part it would
be a lot easier for you.

The fact that you already have data for the red part and now want to start
collecting for the green part as well, makes it more complicated. If you can
make green and red the same then you could keep all the data with some
tweaking and continue with another categorycomo with green+red, but if you
need to keep them as they are in your report I would consider splitting up
into 2 categprycombos and two data elements in stead.

Yes I want to keep green+red together when enter data and generate as well.

If I was to design datasets based on this report without having to think
about the data already in the system, a fresh start if you like, I would
create two data element per disease (ICD code), 1) "<disease name> + Phong
Kham)", and 2) "<disease name> + Benh Nhan dieu tri". And then I would
create two categorycombos, one for the green and one for the red, and then
assign data elements with the Phong Kham name to the green and data elements
with the Benh Nhan name to the red. That would give you two datasets.

No. It would be difficult for generate report later. Special in using Excel
report module.

You could later design reports that would give you the exact same table,
and with some changes to data entry forms (as in my previous suggestion to
allow multiple datasets to 1 form) you could also create a custom form that
would look like your report.

That probably didn't help much...

Just note that having categorycombos that doesn't make sense to add up as
a total will not be very useful, except for allowing you to design the data
entry form you need.

Another general comment would be to try to think of your paper forms as
your outputs (reports) and not necessarily your inputs. Your DHIS data entry
forms are your inputs and that they do not have to be exactly the same
(although that is what the user will ask you for). If you need some of these
data in other outputs, like an indicator to view on a map or in a chart, or
another summary report, or in a pivot table, then you might have problems
getting what you need because of the way you have designed your datasets,
data elements, and dimensions.

If we can improve the data set + data entry forms model in DHIS 2 a bit to
allow for multiple data sets (categorycombos) in one form, then we are much
more free to design appropriate datasets (data elements with dimensions)
that makes sense for data analysis and still be able to meet the users needs
of having to make data entry forms look exactly like the paper forms.

With the current constraints of the 1-1 relationship between form and
dataset we are struggling to make good use of the multidimensional model
(because we put everything in one categorycombo to mimic the forms) for
anything but data entry, unfortunately.

Ola

--
--
Thuy
HISP Vietnam
+84902079126

_______________________________________________
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

9

Hi Jason,

I had attached the file with translation.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera

  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers

  • Ỉa chảy do Shigella - Shigellosis

  • Lỵ amip - Amoebiasis

  • …
    Data element group names are

  • Chapter I : Certain infectious and parasistic dieases

  • Chapter II : Neoplasms

  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total
  2. Clinics - Children
  3. Clinics - Death
  4. Patients - Total - Infection
  5. Patients - Total - Death
  6. Patients - Children < 15 - Infection - Total
  7. Patients - Children < 15 - Infection - 0-4
  8. Patients - Children < 15 - Death - Total
  9. Patients - Children < 15 - Death - 0-4
    II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

image

···

–

Thuy
HISP Vietnam
+84902079126

10

Hi Thuy,

Interesting. Just another question? You do not record data for each clinic?

So, if I understand this correctly there is a category “clinics”, which refers to the number of clinics which have a specific condition?

So, you could have 10 clinics with 10 cases each, for a total of 100 cases, or 1 clinic with a 100 cases for a total of 100 cases as well?

Regards,
Jason

···

On Mon, Dec 7, 2009 at 1:42 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Hi Jason,
I had attached the file with translation.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera
  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers
  • Ỉa chảy do Shigella - Shigellosis
  • Lỵ amip - Amoebiasis
  • …
    Data element group names are
  • Chapter I : Certain infectious and parasistic dieases
  • Chapter II : Neoplasms
  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total
  2. Clinics - Children
  3. Clinics - Death
  4. Patients - Total - Infection
  5. Patients - Total - Death
  6. Patients - Children < 15 - Infection - Total
  7. Patients - Children < 15 - Infection - 0-4
  8. Patients - Children < 15 - Death - Total
  9. Patients - Children < 15 - Death - 0-4
    II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

–

Thuy
HISP Vietnam
+84902079126

11

Hi Thuy,

Interesting. Just another question? You do not record data for each clinic?

So, if I understand this correctly there is a category “clinics”, which refers to the number of clinics which have a specific condition?

So, you could have 10 clinics with 10 cases each, for a total of 100 cases, or 1 clinic with a 100 cases for a total of 100 cases as well?

Regards,
Jason

Hi Jason,
I had attached the file with translation.

Thanks Thuy,

some questions inline.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera
  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers
  • Ỉa chảy do Shigella - Shigellosis
  • Lỵ amip - Amoebiasis
  • …
    Data element group names are
  • Chapter I : Certain infectious and parasistic dieases
  • Chapter II : Neoplasms
  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total

infections + deaths?

  1. Clinics - Children

how old are these children?

  1. Clinics - Death
  2. Patients - Total - Infection
  3. Patients - Total - Death
  4. Patients - Children < 15 - Infection - Total
  5. Patients - Children < 15 - Infection - 0-4

so these are children under 5 years?

  1. Patients - Children < 15 - Death - Total
  2. Patients - Children < 15 - Death - 0-4

What do you do if someone asks to know the total of infections for Cholera for both clinics and (in) patients?

Or say, want to know the total of cholera infections for children under 5 years?

CategoryCombos and categories, when used wisely can give such sub totals automatically and make it available in a data analysis tools that a doctor or health worker with some training could manage. Even better, could give you all those options broken down by categories such as Age, Place, TypeOfVisit or what have you. Your outputs (reports, charts, maps, pivot tables) become very dependent on programmer skills and are very hard coded, which is fine for static excel reports, but not much more.

I can see that you are getting your data entry form and static excel report this way, but I would not recommend this approach to anyone that is trying to use DHIS as a data analysis tool. This approach limits the functions of DHIS to a hard coded reporting tool, which might be what is needed in Vietnam right now, but in a year or two you might be asked to provide other outputs and then you are stuck with this very static and hard coded design which will make it very difficult for you to respond to new requirements and needs.

That’s my opinion anyway.

Ola

···

2009/12/7 Jason Pickering jason.p.pickering@gmail.com

On Mon, Dec 7, 2009 at 1:42 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

–

Thuy
HISP Vietnam
+84902079126

12

Hi there,
I have chatted with Thuy about this, and want to try and distill out what the issue here is. My understanding is as follows, but this may not be 100% so Thuy,please review carefully. Data is being collected in terms of totals and groups of interest. So,

  1. Patients - Total - Infection(Date element type) refers to the total number of patients for a particular syndrome.
  2. Patients - Children < 15 - Infection - Total(Date element type) refers to the total number of patients for a particular syndrome under 15.
  3. Patients - Children < 15 - Infection - 0-4(Date element type) refers to the total number of patients for a particular syndrome under 4.
    So, in this case, there are three categories (wait a second and let me explain, as I know you are going to say, no, there are only two, under 15 and 0-4). In Viet Nam’s case, they are not recording the component parts of a particular total. As the category combos have been implemented to date, there are implicit rules about how the category options relate to each other.

So, Patient-Total-Infection= Over 15 + Children < 15 (but in this case the left hand side of the equation is recorded, along with the Children Under 15). The over 15 age group can be derived of course.

Likewise, Patient-Total-Infection= Over 15 (not recorded explicity) + (15->4 + 4->0). Similarly, the 15-4 age group is not explicitly recorded but rather can be derived from the different parts.

I am not sure I really understand the complete issue here, but I think I do understand this part, and want to use it to begin possibly another long thread on the the categories/dimensions issue. (Yeah, oh no). The issue for me here is that in Thuy’s example the total is actually being recorded, along with two groups of interest that are important for reporting. It seems not a bad approach really, as you can simply count up the totals for a particular syndrome, and then search for all under 4s, instead of having to look at each entry in the patient register and figure out what their age group is. I will not debate about the merits of this approach, but I can understand why it is used, as it responds to user needs and may even result in some efficiency during the tally process perhaps. This is not the issue I want to raise here but may deserve some consideration in a seperate thread about best practice.

The issue for me is that in the current categorycombos implementations, it is assumed that you collect the component parts. So, in order to get it right in DHIS, we would need to collect (Over 15, 15-4 and Under 4) and allow the application to calculate the total. Instead, in Viet Nam they collect the total, Under 15 (equivalent to the sum of 15-0) and Under 4, which of course, can be used to derive the categories above.

I see this as implicitly constraining, as it makes assumptions about how the workflow actually takes place. Categories need flexible internal rules about how 1) Aggregation to a total takes place and 2) which elements are actually input. If Thuy would create four category combos, it would seem to solve the problem.

  1. A total category, which would be input rather than calculated (Under 15 + Over 15)

  2. Over 15, which would not be input but could be calculated from other parts

  3. Under 15, which would be input but which is essentially a subtotal within the category combination (15-4 + Under 4)

  4. 15-4, which would not be input but could be calculated from other parts

  5. Under 4, which would be input, but which is not a subtotal.

It seems reasonable to me. Perhaps unusual for the forms I am used to seeing, but I am not convinced at this point that it would result in any difference than collecting (Over 15, 15.4 and Under 4). Three data values are entered, but are composed differently than what the categorycombo functionality assumes should be input.

I think this highlights the fact that we need 1) more flexible rules for what gets input versus calcuated and 2) not to assume that the total itself will not be entered.

I am still not sure about all of the issues that Thuy raises, but I wanted to try and express this very clearly for the benefit of the list.

Regards,
Jason

···

On Mon, Dec 7, 2009 at 2:19 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/12/7 Jason Pickering jason.p.pickering@gmail.com

Hi Thuy,

Interesting. Just another question? You do not record data for each clinic?

So, if I understand this correctly there is a category “clinics”, which refers to the number of clinics which have a specific condition?

So, you could have 10 clinics with 10 cases each, for a total of 100 cases, or 1 clinic with a 100 cases for a total of 100 cases as well?

Regards,
Jason

On Mon, Dec 7, 2009 at 1:42 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Hi Jason,
I had attached the file with translation.

Thanks Thuy,

some questions inline.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera
  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers
  • Ỉa chảy do Shigella - Shigellosis
  • Lỵ amip - Amoebiasis
  • …
    Data element group names are
  • Chapter I : Certain infectious and parasistic dieases
  • Chapter II : Neoplasms
  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total

infections + deaths?

  1. Clinics - Children

how old are these children?

  1. Clinics - Death
  2. Patients - Total - Infection
  3. Patients - Total - Death
  4. Patients - Children < 15 - Infection - Total
  5. Patients - Children < 15 - Infection - 0-4

so these are children under 5 years?

  1. Patients - Children < 15 - Death - Total
  2. Patients - Children < 15 - Death - 0-4

What do you do if someone asks to know the total of infections for Cholera for both clinics and (in) patients?

Or say, want to know the total of cholera infections for children under 5 years?

CategoryCombos and categories, when used wisely can give such sub totals automatically and make it available in a data analysis tools that a doctor or health worker with some training could manage. Even better, could give you all those options broken down by categories such as Age, Place, TypeOfVisit or what have you. Your outputs (reports, charts, maps, pivot tables) become very dependent on programmer skills and are very hard coded, which is fine for static excel reports, but not much more.

I can see that you are getting your data entry form and static excel report this way, but I would not recommend this approach to anyone that is trying to use DHIS as a data analysis tool. This approach limits the functions of DHIS to a hard coded reporting tool, which might be what is needed in Vietnam right now, but in a year or two you might be asked to provide other outputs and then you are stuck with this very static and hard coded design which will make it very difficult for you to respond to new requirements and needs.

That’s my opinion anyway.

Ola

II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

–

Thuy
HISP Vietnam
+84902079126

13

hei,

Thanks all for the contribution to this topic discussion about DAEL cat/com(category/combination) because it helps me a lot for understanding this concept/usage :slight_smile:

First of all, I’d like to mention about the relation of this topic to Vietnam case with DHIS2:

We use DAELcat/com for reducing the DAELs when desinging dataset, data-entry, outputs like report, etc.
Why? because it’s the needs from the reality of the field here, as Thuy tried to explain (and also Jason saw that, thanks for your patience and curiousity) in the report forms data is collected/showed/viewed/analysed (maybe… this belongs to health people, the health system with changing and ununified health reports) that way: raw data and aggregated data sometimes also in the same input/output.

Localization/Customization everywhere is the same with issues, differences. A design for somewhere at first and then being generalized to “for no where or everywhere” (in the meaning of generalization). As far as I’ve been involved with HISP so far, I’ve seen this point.

The fact that we develop a system for global but local could customize for using to their own needs, of course life is not easy as the ideal way of the intentional design!

Second, Excel reporting is not our end-up or approach as Ola maybe misunderstood but that’s our current one based on the field and the status of implementation.

For some people involed with the case of Vietnam, back to the very first day with DHIS1.3/1.4 and DHIS2.0 in 2006 and until now, there’s been many things happened in the field of Vietnam case: ups and downs, of course. And our mainly customized usages of DHIS2 since last year have been DAEL, Dataset, Data-entry and Report. Later on, if these go well/smoothly and data is entered completely, the needs of the other functionalities of data-analysis, presentation, etc. would happen of course .

And the plan for Patient-record (customized from the global) for the Reproductive Health Care Center where the local Vietnam team located is counted.
In some how, I can say that THE GAME WITH DHIS2 in Vietnam just STARTED :slight_smile: and we’re MOVING on!

And the mission of the local team is making use of DHIS2 for local use but following the status of the field.
Customization is complicated, time-comsuming and it requires flexibilities.

Summary, it’d be great if you guys can understand our case in Vietnam and our developer, Thuy for the previous emails.

Any comments?
THANK YOU!

···

On Mon, Dec 7, 2009 at 9:32 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi there,
I have chatted with Thuy about this, and want to try and distill out what the issue here is. My understanding is as follows, but this may not be 100% so Thuy,please review carefully. Data is being collected in terms of totals and groups of interest. So,

  1. Patients - Total - Infection(Date element type) refers to the total number of patients for a particular syndrome.
  2. Patients - Children < 15 - Infection - Total(Date element type) refers to the total number of patients for a particular syndrome under 15.
  3. Patients - Children < 15 - Infection - 0-4(Date element type) refers to the total number of patients for a particular syndrome under 4.
    So, in this case, there are three categories (wait a second and let me explain, as I know you are going to say, no, there are only two, under 15 and 0-4). In Viet Nam’s case, they are not recording the component parts of a particular total. As the category combos have been implemented to date, there are implicit rules about how the category options relate to each other.

So, Patient-Total-Infection= Over 15 + Children < 15 (but in this case the left hand side of the equation is recorded, along with the Children Under 15). The over 15 age group can be derived of course.

Likewise, Patient-Total-Infection= Over 15 (not recorded explicity) + (15->4 + 4->0). Similarly, the 15-4 age group is not explicitly recorded but rather can be derived from the different parts.

I am not sure I really understand the complete issue here, but I think I do understand this part, and want to use it to begin possibly another long thread on the the categories/dimensions issue. (Yeah, oh no). The issue for me here is that in Thuy’s example the total is actually being recorded, along with two groups of interest that are important for reporting. It seems not a bad approach really, as you can simply count up the totals for a particular syndrome, and then search for all under 4s, instead of having to look at each entry in the patient register and figure out what their age group is. I will not debate about the merits of this approach, but I can understand why it is used, as it responds to user needs and may even result in some efficiency during the tally process perhaps. This is not the issue I want to raise here but may deserve some consideration in a seperate thread about best practice.

The issue for me is that in the current categorycombos implementations, it is assumed that you collect the component parts. So, in order to get it right in DHIS, we would need to collect (Over 15, 15-4 and Under 4) and allow the application to calculate the total. Instead, in Viet Nam they collect the total, Under 15 (equivalent to the sum of 15-0) and Under 4, which of course, can be used to derive the categories above.

I see this as implicitly constraining, as it makes assumptions about how the workflow actually takes place. Categories need flexible internal rules about how 1) Aggregation to a total takes place and 2) which elements are actually input. If Thuy would create four category combos, it would seem to solve the problem.

  1. A total category, which would be input rather than calculated (Under 15 + Over 15)

  2. Over 15, which would not be input but could be calculated from other parts

  3. Under 15, which would be input but which is essentially a subtotal within the category combination (15-4 + Under 4)

  4. 15-4, which would not be input but could be calculated from other parts

  5. Under 4, which would be input, but which is not a subtotal.

It seems reasonable to me. Perhaps unusual for the forms I am used to seeing, but I am not convinced at this point that it would result in any difference than collecting (Over 15, 15.4 and Under 4). Three data values are entered, but are composed differently than what the categorycombo functionality assumes should be input.

I think this highlights the fact that we need 1) more flexible rules for what gets input versus calcuated and 2) not to assume that the total itself will not be entered.

I am still not sure about all of the issues that Thuy raises, but I wanted to try and express this very clearly for the benefit of the list.

Regards,
Jason

On Mon, Dec 7, 2009 at 2:19 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/12/7 Jason Pickering jason.p.pickering@gmail.com

Hi Thuy,

Interesting. Just another question? You do not record data for each clinic?

So, if I understand this correctly there is a category “clinics”, which refers to the number of clinics which have a specific condition?

So, you could have 10 clinics with 10 cases each, for a total of 100 cases, or 1 clinic with a 100 cases for a total of 100 cases as well?

Regards,
Jason

On Mon, Dec 7, 2009 at 1:42 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Hi Jason,
I had attached the file with translation.

Thanks Thuy,

some questions inline.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera
  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers
  • Ỉa chảy do Shigella - Shigellosis
  • Lỵ amip - Amoebiasis
  • …
    Data element group names are
  • Chapter I : Certain infectious and parasistic dieases
  • Chapter II : Neoplasms
  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total

infections + deaths?

  1. Clinics - Children

how old are these children?

  1. Clinics - Death
  2. Patients - Total - Infection
  3. Patients - Total - Death
  4. Patients - Children < 15 - Infection - Total
  5. Patients - Children < 15 - Infection - 0-4

so these are children under 5 years?

  1. Patients - Children < 15 - Death - Total
  2. Patients - Children < 15 - Death - 0-4

What do you do if someone asks to know the total of infections for Cholera for both clinics and (in) patients?

Or say, want to know the total of cholera infections for children under 5 years?

CategoryCombos and categories, when used wisely can give such sub totals automatically and make it available in a data analysis tools that a doctor or health worker with some training could manage. Even better, could give you all those options broken down by categories such as Age, Place, TypeOfVisit or what have you. Your outputs (reports, charts, maps, pivot tables) become very dependent on programmer skills and are very hard coded, which is fine for static excel reports, but not much more.

I can see that you are getting your data entry form and static excel report this way, but I would not recommend this approach to anyone that is trying to use DHIS as a data analysis tool. This approach limits the functions of DHIS to a hard coded reporting tool, which might be what is needed in Vietnam right now, but in a year or two you might be asked to provide other outputs and then you are stuck with this very static and hard coded design which will make it very difficult for you to respond to new requirements and needs.

That’s my opinion anyway.

Ola

II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

–

Thuy
HISP Vietnam
+84902079126

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

–

Best regards,
Kim Anh Vo

+84.906612246
kavo@ifi.uio.no
Coordinator of HISP Vietnam
Master of Information Systems

at the University of Oslo

join facebook at www.facebook.com join LinkedIn at www.linkedin.com

14

hei,

Hi Kim Anh,

thanks for your explanations. See my comments further down.

Thanks all for the contribution to this topic discussion about DAEL cat/com(category/combination) because it helps me a lot for understanding this concept/usage :slight_smile:

First of all, I’d like to mention about the relation of this topic to Vietnam case with DHIS2:

We use DAELcat/com for reducing the DAELs when desinging dataset, data-entry, outputs like report, etc.
Why? because it’s the needs from the reality of the field here, as Thuy tried to explain (and also Jason saw that, thanks for your patience and curiousity) in the report forms data is collected/showed/viewed/analysed (maybe… this belongs to health people, the health system with changing and ununified health reports) that way: raw data and aggregated data sometimes also in the same input/output.

Localization/Customization everywhere is the same with issues, differences. A design for somewhere at first and then being generalized to “for no where or everywhere” (in the meaning of generalization). As far as I’ve been involved with HISP so far, I’ve seen this point.

The fact that we develop a system for global but local could customize for using to their own needs, of course life is not easy as the ideal way of the intentional design!

I totally agree that there is no solution that meets all needs, but at the same time there are some design principles and best practices on designing DHIS databases that have been accumulated and learned from many countries over a long time. I understand that there is a lot of pressure on the reporting requirements from your users and I have seen a lot of them myself. It is not easy to support these and I think you guys have done a great job in coming up with new reporting functionality like the Excel reporting. That said, I think it is still possible to support those reports AND design the data elements and categories in a a more flexible way that will make it easier for you when you start looking more at data analysis and other kinds of reports. The category combo for the morbidity and mortality form (ICD 10 based) allows you to more easily design the data entry form and the fixed report (which is the same as the form), but it lock you down and makes it a lot harder to do other things with that data later, that is my point. And I have seen similar requirements in other places (although Vietnam definetely has some of the hardest reporting format requirements) and know that it is possible to design your datasets in a more structured way that can both support your forms and fixed reports as well as open up for more possibilities in data analysis. It is probably a harder first step than the approach you have taken now, but it will be worth it in the long run. And I don’t think it’s too late to redesign some of these data sets, you could to it gradually.

Second, Excel reporting is not our end-up or approach as Ola maybe misunderstood but that’s our current one based on the field and the status of implementation.

For some people involed with the case of Vietnam, back to the very first day with DHIS1.3/1.4 and DHIS2.0 in 2006 and until now, there’s been many things happened in the field of Vietnam case: ups and downs, of course. And our mainly customized usages of DHIS2 since last year have been DAEL, Dataset, Data-entry and Report. Later on, if these go well/smoothly and data is entered completely, the needs of the other functionalities of data-analysis, presentation, etc. would happen of course .
But here is where you will be in trouble, because your datasets, data elements and categories do not support the next step, the more advanced data analysis and presentation. And when designing your database you should think of these requirements as well and not only focus on the data entry forms and fixed reports, that is my main advis.

And the plan for Patient-record (customized from the global) for the Reproductive Health Care Center where the local Vietnam team located is counted.
In some how, I can say that THE GAME WITH DHIS2 in Vietnam just STARTED :slight_smile: and we’re MOVING on!

And the mission of the local team is making use of DHIS2 for local use but following the status of the field.
Customization is complicated, time-comsuming and it requires flexibilities.

I understand, and think you are doing a great job in trying to solve very difficult problems. I hope that we all can help you make that process easier, that is how I see the role of the HISP community, to share best practices from country to country. Many countries are struggling with the design of datasets and dimensions right now, and it is not an easy job at all, so we need to work together on this and share our problems and solutions.

Ola

···

2009/12/8 Kim Anh Thi Vo catakim@gmail.com

Summary, it’d be great if you guys can understand our case in Vietnam and our developer, Thuy for the previous emails.

Any comments?
THANK YOU!

On Mon, Dec 7, 2009 at 9:32 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi there,
I have chatted with Thuy about this, and want to try and distill out what the issue here is. My understanding is as follows, but this may not be 100% so Thuy,please review carefully. Data is being collected in terms of totals and groups of interest. So,

  1. Patients - Total - Infection(Date element type) refers to the total number of patients for a particular syndrome.
  2. Patients - Children < 15 - Infection - Total(Date element type) refers to the total number of patients for a particular syndrome under 15.
  3. Patients - Children < 15 - Infection - 0-4(Date element type) refers to the total number of patients for a particular syndrome under 4.
    So, in this case, there are three categories (wait a second and let me explain, as I know you are going to say, no, there are only two, under 15 and 0-4). In Viet Nam’s case, they are not recording the component parts of a particular total. As the category combos have been implemented to date, there are implicit rules about how the category options relate to each other.

So, Patient-Total-Infection= Over 15 + Children < 15 (but in this case the left hand side of the equation is recorded, along with the Children Under 15). The over 15 age group can be derived of course.

Likewise, Patient-Total-Infection= Over 15 (not recorded explicity) + (15->4 + 4->0). Similarly, the 15-4 age group is not explicitly recorded but rather can be derived from the different parts.

I am not sure I really understand the complete issue here, but I think I do understand this part, and want to use it to begin possibly another long thread on the the categories/dimensions issue. (Yeah, oh no). The issue for me here is that in Thuy’s example the total is actually being recorded, along with two groups of interest that are important for reporting. It seems not a bad approach really, as you can simply count up the totals for a particular syndrome, and then search for all under 4s, instead of having to look at each entry in the patient register and figure out what their age group is. I will not debate about the merits of this approach, but I can understand why it is used, as it responds to user needs and may even result in some efficiency during the tally process perhaps. This is not the issue I want to raise here but may deserve some consideration in a seperate thread about best practice.

The issue for me is that in the current categorycombos implementations, it is assumed that you collect the component parts. So, in order to get it right in DHIS, we would need to collect (Over 15, 15-4 and Under 4) and allow the application to calculate the total. Instead, in Viet Nam they collect the total, Under 15 (equivalent to the sum of 15-0) and Under 4, which of course, can be used to derive the categories above.

I see this as implicitly constraining, as it makes assumptions about how the workflow actually takes place. Categories need flexible internal rules about how 1) Aggregation to a total takes place and 2) which elements are actually input. If Thuy would create four category combos, it would seem to solve the problem.

  1. A total category, which would be input rather than calculated (Under 15 + Over 15)

  2. Over 15, which would not be input but could be calculated from other parts

  3. Under 15, which would be input but which is essentially a subtotal within the category combination (15-4 + Under 4)

  4. 15-4, which would not be input but could be calculated from other parts

  5. Under 4, which would be input, but which is not a subtotal.

It seems reasonable to me. Perhaps unusual for the forms I am used to seeing, but I am not convinced at this point that it would result in any difference than collecting (Over 15, 15.4 and Under 4). Three data values are entered, but are composed differently than what the categorycombo functionality assumes should be input.

I think this highlights the fact that we need 1) more flexible rules for what gets input versus calcuated and 2) not to assume that the total itself will not be entered.

I am still not sure about all of the issues that Thuy raises, but I wanted to try and express this very clearly for the benefit of the list.

Regards,
Jason

On Mon, Dec 7, 2009 at 2:19 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/12/7 Jason Pickering jason.p.pickering@gmail.com

Hi Thuy,

Interesting. Just another question? You do not record data for each clinic?

So, if I understand this correctly there is a category “clinics”, which refers to the number of clinics which have a specific condition?

So, you could have 10 clinics with 10 cases each, for a total of 100 cases, or 1 clinic with a 100 cases for a total of 100 cases as well?

Regards,
Jason

On Mon, Dec 7, 2009 at 1:42 PM, Thuy Nguyen thuy.hispvietnam@gmail.com wrote:

Hi Jason,
I had attached the file with translation.

Thanks Thuy,

some questions inline.

I. What I had done for this report in the DHIS2

Data elements are deseases’ names:

  • Tả - Cholera
  • Thương hàn, phó thương hàn -Typhoid and paratyphoid fevers
  • Ỉa chảy do Shigella - Shigellosis
  • Lỵ amip - Amoebiasis
  • …
    Data element group names are
  • Chapter I : Certain infectious and parasistic dieases
  • Chapter II : Neoplasms
  • …
    ICDX are data elements’ codes

Category combination is : CategoryCombination_B09T. This category combination has category is : Category_B09T. This category includes 9 category options listed below

  1. Clinics - Total

infections + deaths?

  1. Clinics - Children

how old are these children?

  1. Clinics - Death
  2. Patients - Total - Infection
  3. Patients - Total - Death
  4. Patients - Children < 15 - Infection - Total
  5. Patients - Children < 15 - Infection - 0-4

so these are children under 5 years?

  1. Patients - Children < 15 - Death - Total
  2. Patients - Children < 15 - Death - 0-4

What do you do if someone asks to know the total of infections for Cholera for both clinics and (in) patients?

Or say, want to know the total of cholera infections for children under 5 years?

CategoryCombos and categories, when used wisely can give such sub totals automatically and make it available in a data analysis tools that a doctor or health worker with some training could manage. Even better, could give you all those options broken down by categories such as Age, Place, TypeOfVisit or what have you. Your outputs (reports, charts, maps, pivot tables) become very dependent on programmer skills and are very hard coded, which is fine for static excel reports, but not much more.

I can see that you are getting your data entry form and static excel report this way, but I would not recommend this approach to anyone that is trying to use DHIS as a data analysis tool. This approach limits the functions of DHIS to a hard coded reporting tool, which might be what is needed in Vietnam right now, but in a year or two you might be asked to provide other outputs and then you are stuck with this very static and hard coded design which will make it very difficult for you to respond to new requirements and needs.

That’s my opinion anyway.

Ola

II What I had done in for generate this report in Excel Report module

The report items are :

  1. Serial (This will list all of Số TT - No. column)
  2. Diseases by categories (This are data element name item type, this list of data element names and data element groupnames would be generated automatically)
  3. ICDX code (Data element code type)
  4. Clinics - Total (Date element type)
  5. Clinics - Children (Date element type)
  6. Clinics - Death(Date element type)
  7. Patients - Total - Infection(Date element type)
  8. Patients - Total - Death(Date element type)
  9. Patients - Children < 15 - Infection - Total(Date element type)
  10. Patients - Children < 15 - Infection - 0-4(Date element type)
  11. Patients - Children < 15 - Death - Total(Date element type)
  12. Patients - Children < 15 - Death - 0-4(Date element type)
    All of those items are defined the position of the start cells in the excel files (refer to the excel user manual excel report document)

And this report would be generate automatically.

So if there is any category option added, example Hospital.

In the design data entry form stage. I just put some elements of the new columns into the existing data entry form.

In the designing report stage, I will create the 13th item named Hospital. and the report would generate that option beside others. And data elements list still list same with the old ones. Not list other data elements names.

I hope you get me.

–

Thuy
HISP Vietnam
+84902079126

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

–

Best regards,
Kim Anh Vo

+84.906612246
kavo@ifi.uio.no
Coordinator of HISP Vietnam

Master of Information Systems

at the University of Oslo

join facebook at www.facebook.com join LinkedIn at www.linkedin.com

15

I hate to flog a dead horse, but here I go again. What about at least being able eto add new category options to existing categories? I can sort of understand why it should not be possible to delete category options (since they may have data attached to them) but there would seem to be little harm (unless I am missing something) with adding new category options.

Regards,
Jason

···

The way I see it by allowing adding/removing categories/options from categorycomobs/categories we will be inviting lots of complexities - so I think the best way is not to allow addition or removal.

Thank you

Abyot.

On Fri, Dec 4, 2009 at 3:13 PM, noreply@launchpad.net wrote:

revno: 1167

committer: Abyot Asalefew Gizaw abyota@gmail.com

branch nick: trunk

timestamp: Fri 2009-12-04 15:10:54 +0100

message:

Once a categorycombo is created there is no way to add/remove a category/option into/from it.

modified:

dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm

–

lp:dhis2

https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.

To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription.

=== modified file ‘dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm’

— dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm 2009-10-20 12:49:32 +0000

+++ dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-datadictionary/src/main/webapp/dhis-web-maintenance-datadictionary/multidimensional/updateDataElementCategoryComboForm.vm 2009-12-04 14:10:54 +0000

@@ -37,7 +37,7 @@

   </tr>

   <tr>

            <td>

  •      <select size="15" id="availableList" name="availableList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'availableList' )">

  •      <select size="15" id="availableList" name="availableList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'availableList' )" disabled="disabled">



       #foreach ( $availableDataElementCategory in $allDataElementCategories )

         <option value="$availableDataElementCategory.id">$encoder.htmlEncode( $availableDataElementCategory.name )</option>

       #end

@@ -51,7 +51,7 @@

              <a href="#" onclick="moveDown('selectedList')"><img src="../images/move_down.png" border="0" alt=""></a>

     </td>

            <td>

  •      <select id="selectedList" name="selectedList" multiple="multiple" style="min-width:20em;height:20em" ondblclick="move( 'selectedList' )">

  •      <select id="selectedList" name="selectedList" multiple="multiple" style="min-width:20em;height:20em">

       #foreach ( $dataElementCategory in $dataElementCategories )

         <option value="$dataElementCategory.id">$encoder.htmlEncode( $dataElementCategory.name )</option>

       #end

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

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

–
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260974901293

16

I think it might be possible although complicated. The issue is that we pre-populate category option combos when creating a category combination. So in that case we need to analyse and see what new category option combos need to be generated. Go ahead with a blueprint and we will think more about it…

···

On Wed, Mar 16, 2011 at 1:32 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

I hate to flog a dead horse, but here I go again. What about at least being able eto add new category options to existing categories? I can sort of understand why it should not be possible to delete category options (since they may have data attached to them) but there would seem to be little harm (unless I am missing something) with adding new category options.