dhis2-devs team mailing list archive

[Marc Garnica <marcgarnica13@xxxxxxxxx>]

The *two main requirements* are:

1.       To create a table with the aggregated number of cases/patients
coming from a village and the corresponding incidence rate.

2.       To create a map showing the number of cases/patient coming from
the different villages.


Thanks,

Marc

2016-10-24 12:52 GMT+02:00 Prosper BT <ptb3000@xxxxxxxxx>:

> Dear Marc,
>
> Can you share your analysis plan?
> How do you intend to analyze and present the data?
>
> Regards
>
> Prosper Behumbiize, MPH
> DHIS2 Implementation| HISP Uganda/University Of Oslo
> +256 752 751 776 | +256 776 139 139
> prosper@xxxxxxxxxxxxxx <ptb3000@xxxxxxxxx> | prosper@xxxxxxxxx | Skype:
> prospertb
>
> On Mon, Oct 24, 2016 at 10:42 AM, Marc Garnica <marcgarnica13@xxxxxxxxx>
> wrote:
>
>> Any ideas on that?
>>
>> Thanks a lot,
>> Marc
>>
>> ---------- Forwarded message ----------
>> From: Marc Garnica <marcgarnica13@xxxxxxxxx>
>> Date: 2016-10-21 17:03 GMT+02:00
>> Subject: Secundary geographical data needed for analysis
>> To: dhis2-users@xxxxxxxxxxxxxxxxxxx
>>
>>
>> Hi all,
>> First of all, thank you for the support and the new release, it really
>> has some nice new features that will help us a lot!. We want to share with
>> you a discussion we have been developing this week to see if you can give
>> us some advice.
>>
>> For every single data entry (individual with or without registration and
>> aggregated data) we always need at least one geographical data which refers
>> to where the data comes from. This is information can be selected in the
>> interface through the Org unit tree in the left.
>>
>>
>> But we sometimes need and additional geographical data referring to where
>> the patient comes from. In this case we add a data element to add this
>> data. This information is so important to create great analysis and reports
>> so we need to think well how we want to collect this geographical data.
>>
>>
>> The first option we did was just create a typed TEXT data element where
>> the user could enter manually the village where the patient came from. But
>> obviously, this was not correct enough because the user can write the same
>> village in more than one spelling way and also there was no feasible way to
>> use this data element as a dimension in the analysis so we were not able to
>> map the data in a map of villages or create a table with the cases by
>> village. So we need to formulate a new treatment
>>
>>
>> *POSSIBILITIES*
>>
>> *1.       **CAPTURE THE VILLAGE AS A SET OF COORDINATES*
>>
>> This options consists in create a data element with type COORDINATES and
>> add it to the form. With this options we can add a the geographical
>> information of where the patient comes from by providing the coordinates of
>> the village or even better (in new versions of DHIS2) we can click on the
>> map, search for the village in the search bar and capture the coordinates
>> of it visually.
>>
>> Nice feature but then the village information is only stored as a pair of
>> coordinates, there is no auxiliary information as for instance its name. In
>> the analytical point of view we can now show the cases in a map distributed
>> by village (which is nice) but we cannot create the desired table with the
>> cases by village.
>>
>> Another issue in this option is that for the end-user sometimes it will
>> be difficult to interact with the map and be able to capture the correct
>> village.
>>
>> *2.       **CAPTURE THE VILLAGE AS A ORGANISATION  UNIT*
>>
>> This option appeared once 2.25 DHIS2 version was released with a new
>> Organisation Unit Type for data elements. Using that, we can create a new
>> data element with type = Organisation unit to capture the information of
>> where the patient comes from.
>>
>> So in this option we can have a user with data capture permission only on
>> the Sierra Leona hierarchy of organisation units but able to select a
>> village for example in Benin hierarchy of organisation units.
>>
>> Even though the Organisation unit type data element is the more natural
>> way to specify where the patient comes from, we experienced some problems.
>> Firstly, we are not able to use this data as a dimension for aggregate
>> events information (for instance knowing how many events are registered
>> with a patient coming from X village). And secondly, this option will mean
>> to add all the villages included in our area of research which may lead to
>> memory problems in our server.
>>
>> *3.       **CAPTURE THE VILLAGE AS A RELATIONSHIP WITH THE PATIENT*
>>
>> The 3rd option is to use the “Relationship” implemented in Tracker
>> Capture App. This app can create links between different entities
>> registered in the system; originally it was created for tracking a pregnant
>> patient and then registers to the system her new child. But we could use
>> this relationship in another way just registering villages in the system
>> and then linking these registrations with the patient. This is a more
>> complex way to implement our needs and it needs a lot of research to know
>> if we will be able to show the relationship in a map and to creates tables
>> from them.
>>
>>
>>
>> As I said, thank you very much. We look forward to your answer.
>>
>>
>> Marc Garnica
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-users
>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-users
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>