dhis2-devs team mailing list archive

[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
>
>