dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/12/8 Kim Anh Thi Vo <catakim@xxxxxxxxx>

> 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 :)
>
> 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 :)
> 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
----------

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@xxxxxxxxx> 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
>> 6) 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@xxxxxxxxx>wrote:
>>
>>> 2009/12/7 Jason Pickering <jason.p.pickering@xxxxxxxxx>
>>>
>>> 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@xxxxxxxxx
>>>> > 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.
>>>>>    6. Clinics - Children (Date element type)
>>>>>    7. Clinics - Death(Date element type)
>>>>>    8. Patients - Total - Infection(Date element type)
>>>>>    9. Patients - Total - Death(Date element type)
>>>>>    10. Patients -  Children < 15 - Infection - Total(Date element
>>>>>    type)
>>>>>    11. Patients -  Children < 15 - Infection - 0-4(Date element type)
>>>>>    12. Patients -  Children < 15 - Death - Total(Date element type)
>>>>>    13. 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<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> --
> Best regards,
> Kim Anh Vo
>
> +84.906612246
> kavo@xxxxxxxxxx
> 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
>