...

The process of designing and building a DHIS2 configuration (aggregated or tracker) is iterative. As these iterations are revised, there is significant level of change across iterations: items are discarded, elements are renamed, or configurations are abandoned in re-started (deleting objects in DHIS2 is a very difficult process).

Before you start

Requirements doc pack (LINK): a comprehensive pack includes a nice summary, details about the actors, data collection flow, security considerations. More importantly, it MUST include a D2A, psi’s framework for analytic requirements for any product.

Design and Build

As in most system designs, this is an iterative process on which varios prototypes are build based on the initial requirements, and then revised based on the varios stakeholders feedback revisions. You should used templates that allow you to partially automate your builds, in particular data elements and options/option sets (see DHIS2 metadata import options)

Environments

The process of design and development must be done in a designated development server, and never on a production server. This gives you the freedom to build as many iterations as required, discard data/objects without having to delete them, or abandon them as required, without ‘littering’ the production environment - dev is a safe space to experiment and iterate.

See also

Deploying configurations to production

SOP versions