dhis2-devs team mailing list archive

[John Ojo <jnojo@xxxxxxxxx>]

Hi Ola,

I have set up the tracker system, have enrolled ten (10) participants and entered data for each of them. The data entered is based on the personal attributes for each participant as well as data elements created to capture details of each training event.

I tried to see a report of these trainings for the participants by selecting Tabular Report in the Individual Records module but this always draws a (white) blank page. The text in the address box of the page reads: http://localhost:8082/dhis-web-caseentry/app/index.html.

Please, is there something I need to do before I can see the tabular reports?

Thank you.

John


________________________________
 From: John Ojo <jnojo@xxxxxxxxx>
To: Ola Hodne Titlestad <olati@xxxxxxxxxx> 
Cc: dhis1-users <dhis2-users@xxxxxxxxxxxxxxxxxxx>; DHIS developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx> 
Sent: Wednesday, April 24, 2013 9:58 AM
Subject: Re: [Dhis2-users] [Dhis2-devs] Help with Tracker
 


Sorry Ola, I missed out the question you posed:


"I'd like to know a bit more about the kind of functionality
you want out of this system, the outputs, how you will use the data. That can
help you choose how to structure the transactional data (stages, data elements,
option sets, attributes etc, orgunits)."
 
You are right. My aim is to monitor the training of multiple
health workers over time and get information of what training they have been
through and where and when this took place.

John
 

________________________________
 From: Ola Hodne Titlestad <olati@xxxxxxxxxx>
To: John Ojo <jnojo@xxxxxxxxx> 
Cc: dhis1-users <dhis2-users@xxxxxxxxxxxxxxxxxxx>; DHIS developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx> 
Sent: Wednesday, April 24, 2013 9:24 AM
Subject: Re: [Dhis2-devs] Help with Tracker
 


Hi John,

Very good questions.

First I'd like to recommend reading the documentation and use case descriptions for Tracker here:
http://dhis2.org/tracker

That can help to better understand how Tracker can be implemented to support various use cases.
Your case is not there, but it is a bit similar to use case 4.

I'd like to know a bit more about the kind of functionality you want out of this system, the outputs, how you will use the data.
That can help you choose how to structure the transactional data (stages, data elements, option sets, attributes etc, orgunits).

It sounds like your major use case is to monitor the training of multiple health workers over time and get information of what training they have been through and where and when this took place.

For that use case I think you are right in picking the multiple event with registration type of program. You want to follow individuals over time and add more data at different points in time, and for this you'll need to register persons and store the training data as multiple events (program stage instances in the data model).

The next question is how you organise the data collection. What data will be collected for the different types of training events? It sounds almost like you could use the same data entry form for all of them since you are collecting "type of training / level", "first time or repeat", "location". Since you will capture the same type of data for all training events you don't need more than one program stage ("event type") for this program. BUt you'll need to repeat this stage for every training a person goes through, so you need to make this stage a repeatable stage. There is a property/option called "Repeatable" in the "Add/Edit Program Stage" UI that you need to enable. Then you need to define the data elements you will collect and for those data elements that need pre-defined values (e.g. "first time", "repeat") you need to define option sets and options (in Maintenance->Data Administration->Option Set).

The type of training could be a data element, maybe with the name "Level of capacity building" or "Training component", and you link it to an Option Set "training levels" with options "Capacity building 1", "Capacity building 2" etc. If all these are known when you set up the system then fine. If you need to add more later you can always add a new option to that option set. Be careful in editing existing options when you already have started collecting data since these options are stored directly as values (strings) in the patientdatavalue table and not as a code referencing the option value, so editing might give you inconsistent data (unless you update existing data values as well...).

You can follow a similar approach for the "repeat/first time" data element and option set.

For the date of the training event I would use the date captured for the program stage instance (the event). A program stage instance will always have a report date, which is the date we use when doing aggregation queries on the transactional data. So no need to create a data element for the date/time dimension. 

Location is more of a discussion point. Obviously you can store the location of an event as part of the orgunit that stores the data. Every event will have an organisation unit attached to it, so from there you'll get location. If you have events that take place outside your orgunit hierarchy then you have a few options. You can capture geo coordinates of the events by enabling the property "Capture coordinates" in the Add/Edit Program Stage UI. That would give you exact locations of each event and the possibility of showing these on a map (not yet supported in the DHIS 2 GIS module, but will come later). You could of course also create data elements and option sets for locations, if you have a short list of locations. The country I would definitely do through the orgunit hierarchy. If the health workers are organised under local administrative office (e.g. provinces, districts) you could add these as orgunits as well. But the training might take place
 outside these offices of course.
Depending on how you'll use this location data in your data analysis and how your health workers are organised geographically you can find the best approach among the three location possibilities; 1) orgunits, 2) event coordinates, and 3) data elements.

The Program's "Incidence date description" is used when you enrol a person into the program. It is the start date of the program, so in your case it could be "Enrolment date" or "Date of first training", depending on what dates you want to store.

In Program Stage there are many properties related to how the stages/events are scheduled. You can try the different options and see how it plays out when you enrol a person or complete data entry for a stage. In your case I assume that you would like to create a stage (a training event) when you enrol a person into the program. So you can tick "Auto-generate event". If you used "Date of first training" as incidence date" then the scheduled date for your first training event should be that same date, so you leave "Scheduled days from start" to '0'.
This will create a training event automatically when you enrol a new person and with the date you put for incidence date.

If you want to always schedule a new training event after finishing data entry for the previous you can tick "Display generate event box after completed", and if not you untick that option.

Description of report date. The first thing the user must fill in during data entry is the date of the event. Exactly what that date refers to various from use case to use case so we have made it configurable. This field is a label that will be displayed in the data entry screen to replace "Report Date". I would use "Date of training" or "Start date of training" in your case. 
 
Regarding person attributes and demographics I think it is entirely up to you and your data needs to decide what you need. If you don't need more than the default then no need to add anything, and if you need more you create new attributes. The rule here is that the attributes to not change for every training event, they are stable. If you want to capture data for a variable that changes for every event then it should rather be collected as a data element and not as a person attribute. Person attributes are filled in on enrolment. and they can be updated in the person dashboard.

Hope this was useful. Let us know if you have any other questions. When you get this program up and running it would be good to add it as a new use case description on http://dhis2.org/tracker so that others can learn from it as well.

Ola
---------
  


----------------------------------
Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University
 of Oslo

Mobile: +47 48069736
Home address: Eftasåsen 68, 
0687 Oslo, Norway. Googlemaps link


On 24 April 2013 07:56, John Ojo <jnojo@xxxxxxxxx> wrote:

Hello All,
>
>
>This is my first time to use the DHIS2 Tracker and would
appreciate your kind support to help me move quickly.
>I have read chapter 24 of the DHIS2 manual and things are still not very clear yet in my head.
>
>
>I want to use DHIS2 version 2.11 to track certain health
workers. These health workers live in different countries and provide health
services in the country in which they live. My project provides capacity
building to the health workers from time to time depending on when a need for capacity
building is identified (the periodicity of the capacity building events therefore,
does not follow predefined regular intervals such as we may have in for e.g.
ANC visits or immunization programs).
>
>
>The capacity building activities are: CapBuild_1, CapBuild_2,
CapBuild_3, CapBuild_4, CapBuild_5, etc.
>
>
>Now, for each health worker, I want to be able to track (i.e.
a list showing):
>All the capacity building activities received by the health
worker and each capacity building activity showing when (i.e. the date) the
capacity building activity took place, what capacity building was given (i.e. whether CapBuild_1,
CapBuild_2, CapBuild_3, etc.), where (i.e. country and town) the capacity
building took place and whether that capacity building was first time or a
repeat for the health worker.
>
>
>Please I will need help with the following:
>
>
>1.     1. What category options (option set) would be
appropriate for me to create in this scenario?
> 
>2.      2. What data elements would I need to create to be
able to capture the capacity building activity data?
> 
>3.      3. Apart from biodata information (e.g. name, age,
sex, ID number) of each health worker, what additional demographic information
should I create as attributes for the health worker?
> 
>4.      4. I have decided to set up the program as “Multiple
events with registration”. Is this appropriate for my scenario? What would be
an appropriate “Description of incident date”?
> 
>5.      5. What are the possible “Different Stages” that would
be most appropriate that I should create for my scenario?
> 
>6.      6. When creating the Different Stages of the Program,
what would be most appropriate for the following:
> 
>a.       Name:
>b.      Schedule days from start:
>c.       Auto-generate event
>d.      Description of report date
> 
>7.   7. Please what should I do next after creating the
different stages?
>
>
>Thanking you in advance for your time in helping me with this
very long list of questions.
>
>
>Best regards,
>John
> 
>John Ojo MD, FMCPH
>
>Pretoria, South Africa.
>
>Mobile: +27 795 469 129
>Skype:  Johnojo
>Email: jnojo@xxxxxxxxx
>
>_______________________________________________
>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
>
>



_______________________________________________
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