dhis2-devs team mailing list archive

[Prosper BT <ptb3000@xxxxxxxxx>]

Thanks Marc

You explained well then I guess you have to implement both the Orgunit tree
for where then

For patient location, you may either use the new Orgunit data element type
if it happens that the same villages in the Orgunit tree are the same as
where the patients come from.

Alternatively they have to option sets

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 3:17 PM, Marc Garnica <marcgarnica13@xxxxxxxxx>
wrote:

> The fact is that we want 2 different geographical data. The one you are
> mentioning refers to "where the data comes from" which as you said we can
> easily specify it from the org unit tree.
>
> But then we also want also to have information as "where the patient comes
> from" which is different from the first one.
>
> So for example entering data at a level of a Village XXX, doesn't mean
> that the patient comes from Village XXX. It only means that the data (the
> medical registration or smth related) comes from the Village XXX. But it
> may be (mostly) that the patient doesn't come from Village XXX, he comes
> from from Village YYY. So the user has to specify this Village YYY in the
> form.
>
> Once the user specifies the village YYY in the form we want to be able to
> analyise and be able to fulfill the requirements I've sent before. We have
> these 3 options but none of them are specially accurate.
>
> I don't know if I have explained well, thanks a lot
> Marc
>
> 2016-10-24 13:55 GMT+02:00 Prosper BT <ptb3000@xxxxxxxxx>:
>
>> Thanks Marc for sharing the reporting requirements.
>>
>> Am not sure how many villages you have, but feasible workable solution
>> would be to create Villages as Orgunits and have data entered at that level.
>>
>> 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 2:03 PM, Marc Garnica <marcgarnica13@xxxxxxxxx>
>> wrote:
>>
>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>