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). Using a development environments ensure you can create as many iterations as required, without affecting any live users, creating conflict on the data. It also doesn’t matter how much orphan objects you leave behind - dev environments are refreshed frequently.

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.

See also

Deploying configurations to 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.

Testing

See Testing DHIS2 configurations and apps

Deploying

Once the testing has been finalised and approved by the product owner, you can proceed to its deployment. See H2 Deployment Guidelines - Environments

SOP versions