Naming conventions

This document describes overall naming conventions that should be applied, as far as possible, to the all content of the standard configuration packages.

Note: This has has not yet been applied to all content.

General naming rules

Numbers as part of names


Example of bad naming practice for a data element: Number of pregnant women who make first ANC visit.

If we review ANC visits 1 - 4, we could use:

As plain language this makes sense, however when combined in an ordered list (such as what would appear in DHIS2 analysis applications) with other data elements they will not be either in order or grouped together.

We can change the naming of these data elements to ensure the most important part of the name is what is determining the order of the data elements in an ordered list:

This will allow the items to appear together within a thematic area; they are also in order from first to last as is intended.

Naming for specific object types

Data Elements



Option sets

Generic/reusable option sets should have generic names as far as possible. For example, if an option set is needed for HIV test results with the options “Positive” and “Negative” it should be named “Positive/Negative” rather than “HIV test result” so that if can be reused. In cases where there is a chance that several objects could be confused or are similar but not the same, it should be made explicit, for example “TB treatment outcome”, “Malaria treatment result”.


Legends need a uniform naming, to be discussed.