dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

Marc,

Please test it, I'm too snowed under right now. As far as I'm aware,
though, you CAN search and analyse tracker attribute values but not tracker
data element values. Same is the case for SMS/Email/message alerts, for
instance - you can reference attributes but not data element values.

Otherwise your understanding is correct - while you want a
residental/location geo-location (i.e. coordinates) that are as accurate as
possible, that geo-location cannot be easily used for analysis and
reporting. By immediately or subsequently linking a reasonably accurate
geolocation to a know spatial data set (sub-places, or villages, or suburbs
or whatever) with other relevant data for e.g. socio-economic determinants
of health, you can
- run frequency and clustering analysis and reports (how many cases in each
village, how many cases within x kilometres of an index case)
- run other types of integrated analysis combining routine DHIS data with
e.g. Census data.
Given the lack of formal physical/street addressing systems in most of
Africa, I don't think any single method would fit all cases. For instance,
in some cases the village name given by a patient might be completely
unknown / not existing in ANY source system and not know by the clinician
and/or data capturer. In such cases you either thumbsuck or you interview
the patient again...

Best regards
Calle

On 24 October 2016 at 15:43, Marc Garnica <marcgarnica13@xxxxxxxxx> wrote:

> Hi Calle,
>
> I really appreciate your explanation. The option 1 you mentioned, it's
> pretty close to the option we have to capture the village as coordinates,
> the only problem this option has is that villages are stored as only
> coordinates (even though they might have been searched in the map by name)
> and then we are able to create a  useful map reflecting the cases per
> village but we cannot create the tables with the number of cases per
> village) so the only thing that is missing is to be able to use the
> coordinates of a data entry added in the form as  row dimension in the
> Events Reports.
>
> Option 2 is also nice, but are you sure then that the attribute of a
> tracke entity can be used as a row dimension in the reports? I've not
> tested it yet.
>
> Thanks a lot,
>
> Marc
>
> 2016-10-24 15:31 GMT+02:00 Calle Hedberg <calle.hedberg@xxxxxxxxx>:
>
>> Marc,
>>
>> We have a more or less identical challenge for Disease Surveillance in
>> SA, where all disease notifications are case-based and the notification
>> includes the patient's residential address. From both an analytical and
>> outbreak perspective, such residential addresses must be geo-located so
>> that diseases can be tracked/analysed together with other socio-economic,
>> socio-cultural, and environment data. Based on available data sources, the
>> system has been set up to cater for several scenarios:
>>
>> 1.
>> The top prize would be that a lookup into an address database - and the
>> main one used in SA would be the official 14.8 million dwelling framework,
>> which covers around 90% of the residential dwellings (that database
>> contains geo-coordinates for each dwelling plus street addresses etc). If
>> we have the exact coordinates for the residence, all other spatial analysis
>> can be done. The CHALLENGE - and I've discussed this at length with the GIS
>> developers in Oslo - will be to add functionality to DHIS2 where you can
>> submit a set of address field values (street, street number, village name,
>> surburb, etc) to one or more postgis or web openAddress databases and get
>> one or more matches back, which you can then approve or select from (NOTE a
>> caveat: public address databases like openAddress is quite good for Europe
>> but pathetic for Africa, so we need to identify or develop local sources
>> with a similar setup).
>>
>> 2.
>> The second prize would be to have each residential address at least
>> located within another known Census-based spatial framework - this would be
>> similar the your situation with villages. In the SA case, the lowest and
>> most granular spatial layer available for census data is the SUB-PLACE
>> layer. The 22,104 sub-places in the country are in general equivalent to
>> suburbs, small towns, villages, and big farm areas. I have added the 22,104
>> sub-place names (with their census code in a parenthesis) as an option set
>> for the "Residential sub-place" tracker attribute. I also added provincial
>> prefixes to all those sub-place names, and we might later decide to use
>> both a combined province+district prefix. Selecting an option value is very
>> fast, and with the prefixes you have two options:
>> - the user can type the prefix(es) and get a much shorter list to choose
>> from
>> - the use can type (part of) a village name and get a very short list to
>> choose from.
>> Ideally this selection of the sub-place where the residence is located
>> should be an automatic postgis lookup if you already have exact
>> coordinates, or as I indicated above it should be a relatively generic
>> lookup using whatever street or other location names that have already been
>> entered.
>>
>> 3.
>> I would not add e.g. villages to the existing hierarchy (very messy, and
>> the hierarchy can then no longer be regarded as a "master facility list").
>> Creating a separate hierarchy for searching might be an option, but as I
>> indicated above you can in reality create a "hierarchical" option set by
>> using intelligent prefixes for option values. That's a lot easier.
>>
>> Best regards
>> Calle
>>
>> On 24 October 2016 at 14:55, Prosper BT <ptb3000@xxxxxxxxx> wrote:
>>
>>>
>>> ​Dear Team,
>>>
>>> Following up on the issues raised by Marc​, we just realized that with
>>> the new Orgunit Data Element type, we are not able to analyze by Orgunit
>>> values? We thinking this is a bug otherwise we need to aggregate by the
>>> Orgunits.
>>>
>>> You are not able to display the data element/attribute with Orgunit date
>>> element type in rows.
>>> This is key for IDSR as we need to know how labs are samples referred to
>>> for testing
>>>
>>> [image: Inline image 1]
>>>
>>>
>>> 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
>>>
>>> ---------- Forwarded message ----------
>>> From: Marc Garnica <marcgarnica13@xxxxxxxxx>
>>> Date: Mon, Oct 24, 2016 at 3:43 PM
>>> Subject: Re: [Dhis2-users] Fwd: Secundary geographical data needed for
>>> analysis
>>> To: Prosper BT <ptb3000@xxxxxxxxx>
>>>
>>>
>>> Exactly, what we would really like is to be able to create a table with
>>> a Village per row and saying how many patients come from that village and
>>> add the incidence rate also
>>>
>>> Thanks,
>>>
>>> Marc
>>>
>>> 2016-10-24 14:36 GMT+02:00 Prosper BT <ptb3000@xxxxxxxxx>:
>>>
>>>> You are right,
>>>>
>>>> Its restricts it to a filter see below, its cant be moved to rows.
>>>>
>>>> I guess its a bug we may need to report it
>>>>
>>>> [image: Inline image 1]
>>>>
>>>> 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:30 PM, Marc Garnica <marcgarnica13@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> But the orgunit data element type it's not available to use in the
>>>>> Events reports to create the desired table and it doesn't allow us to show
>>>>> in a map where the patients come from neither.
>>>>>
>>>>> Thanks,
>>>>> Marc
>>>>>
>>>>> 2016-10-24 14:23 GMT+02:00 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>> --
>>
>> *******************************************
>>
>> Calle Hedberg
>>
>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA
>>
>> Tel/fax (home): +27-21-685-6472
>>
>> Cell: +27-82-853-5352
>>
>> Iridium SatPhone: +8816-315-19119
>>
>> Email: calle.hedberg@xxxxxxxxx
>>
>> Skype: calle_hedberg
>>
>> *******************************************
>>
>>
>


-- 

*******************************************

Calle Hedberg

46D Alma Road, 7700 Rosebank, SOUTH AFRICA

Tel/fax (home): +27-21-685-6472

Cell: +27-82-853-5352

Iridium SatPhone: +8816-315-19119

Email: calle.hedberg@xxxxxxxxx

Skype: calle_hedberg

*******************************************