Note: this SOP applies to both, new designs, as well as changes to active configurations that are active.

The process of design designing and building a DHIS2 configuration (aggregated or tracker) is iterative, blah. 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

Requirments document: detailing Requirements doc pack (LINK): a comprehensive pack includes a nice summary, details about the actors, purpose and data points envisioned for the required solutionD2A: Data for Action framework, which clearly delineates the expected outcomes in terms of charts/ tables, and in different dimensions that are expected to be available for data disaggregation and filteringdata 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, discussed and iterated, until a configuration contains sufficient detailsand 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. You should never do design of a new system, or changes to system that it is in production, 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