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 <ptb3...@gmail.com>: > 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 > pros...@hispuganda.org <ptb3...@gmail.com> | pros...@dhis2.org | Skype: > prospertb > > On Mon, Oct 24, 2016 at 10:42 AM, Marc Garnica <marcgarnic...@gmail.com> > wrote: > >> Any ideas on that? >> >> Thanks a lot, >> Marc >> >> ---------- Forwarded message ---------- >> From: Marc Garnica <marcgarnic...@gmail.com> >> Date: 2016-10-21 17:03 GMT+02:00 >> Subject: Secundary geographical data needed for analysis >> To: dhis2-users@lists.launchpad.net >> >> >> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-users >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-users Post to : dhis2-users@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-users More help : https://help.launchpad.net/ListHelp
