dhis2-devs team mailing list archive

[Marc Garnica <marcgarnica13@xxxxxxxxx>]

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