Based on the decisions the system should support (system scope); customization and adaptation of the platform will be needed for DHIS2 aggregate, tracker, and/or events. Each action will need special competence, and should be led by the DCT.
Assessment of the intended users and beneficiaries is needed, such as related to their information needs, and hardware and network needs.
An understanding of the larger architecture of the HIS (the "HIS ecosystem") is important; what other systems are there, and how should they interact with DHIS2? Consider what needs there will be for interoperability between electronic systems.
If there are needs that are not currently supported by DHIS2, an assessment of additional software development is necessary. These can be addressed locally by developing a custom web app or feed into the overall core platform development roadmap process organised by UiO.
Reporting units: implementing the different reporting units (service outlets) and hierarchies including grouping.
Data collection needs: Which indicators are needed, what data variables will go into their calculation, and how should this data be collected? Design data elements, disaggregation categories, data sets, and collection forms.
Information for action (indicators, dashboards, other outputs): what are the information products the various users will need? Tables, charts, maps, dashboards. Routines for dissemination and sharing.
User management: Create user roles and groups, routines for managing users, define access to features, and appropriate sharing of content.
DHIS2 governance document (roles by profile, how to change metadata and under what conditions).
There are many different options for hosting an online system, bith in terms of where to put the server (e.g. in-house vs. cloud) and who to manage the server (e.g. in-house vs. outsourced). Server and hosting alternatives needs to be critically examined with regards to capacity, infrastructural constraints, legal framework, security and confidentiality issues. These desicions may need to be revisited at least annualy as server complexity, data types (e.g. aggegate vs. patient) and local capacity may change over time.