Rule of thumb: program stages

Hi all,

Is there a rule that I can use for determining the number of program stages a tracker should have?

I have seen many trackers in the DHIS 2 demo, but my question has always been: how to know how many stages a tracker must have? I know that there are different scenarios/ use cases, but there may be line of reasoning, thinking, etc. we need to always follow.

Can anyone help to answer my question?


Hi @dmbantu

Each program stage has a main focus on a particular thing so if two program stages will have the same outcome then they probably need to be one program stage. The question is very general and like you said there are different scenarios/use cases but the line of reasoning could be the outcome of a program stage. If we first need to collect data before sending the patient for lab tests then the collection stage will be a program stage and after that lab tests will be in a separate program stage.

Maybe look for words such as before/after

1 Like

Hi @dmbantu

Excellent question!

This is a central challenge in designing DHIS2 Tracker systems, and is the core question addressed in the Tracker Design Guide, which I suggest you read through for a fuller answer.

But to quickly summarize:

  • There is no strict rule on “number of program stages”. Rather, when structuring program stages you need to evaluate the content (what data elements should be asked together?), frequency (are data elements asked multiple times, and should they be presented in a repeatable stage?), and sequencing (does one stage need to come before another, and if so, how strictly should we enforce this workflow?).
  • The most important yet often-overlooked consideration is aligning the program stage structure with your analytics requirements. Will you need to produce a program indicator from across multiple stages? Or across multiple events within the same repeatable program stage? Producing enrollment-type program indicators derived from data elements in repeatable stages sometimes presents challenges.
  • From the perspective of a health care worker entering data, they should be able to enter all services provided at a single patient encounter within the same program stage. Moving between stages is normally a unnecessary burden, unless different users enter data for distinct services, or unless additional data only becomes available later (e.g. test results, new visit to facility, etc).
  • From a maintenance and analytics perspective, it is generally easiest to use the fewest program stages, but you should keep in mind the constraints described above. The guide also includes some different scenarios, including using program rules to create a skip logic for sections and/or program stages.

PS – In addition to the Play demos, I recommend you explore the HMIS demo which includes working examples of all the DHIS2 Tracker metadata packages. These programs are more recently designed than the Sierra Leone demo trackers, and more directly align with realistic use cases.


Hi @brian,

I am so happy with the summary you have provided regarding program stages. I will read the tracker design guide through as you suggest and explore the HMIS demo.

Is it possible to have the Tracker Design Guide in PDF format? I want to print it.