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<https://maps.google.com/maps?q=Eftas%C3%A5sen+68,+0687+Oslo,+Norge&hl=en&ie=UTF8&sll=59.893855,10.785116&sspn=0.222842,0.585709&oq=eftas%C3%A5sen+68,+0687+Oslo,+&t=h&hnear=Eftas%C3%A5sen+68,+%C3%98stensj%C3%B8,+0687+Oslo,+Norway&z=16>


On 24 April 2013 07:56, John Ojo <jn...@yahoo.com> 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: jn...@yahoo.com <j...@corridor-sida.org>
> <http://www.corridor-sida.org/>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to     : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp

Reply via email to