 This presentation will be an introduction to DHIS-2 design principles. We will start by discussing the generic nature of DHIS-2. DHIS-2 is a generic open-source software, and because of this it supports a wide range of use cases. It is also highly configurable. This allows for local systems to be built to address local needs. Each implementation of DHIS-2 in a country is fully owned and governed by the country. This principle can also be applied to an organization. Each country or organization has a different system that is built on top of the platform. This includes the different inputs and outputs within each system, which might vary between different systems. One of the key advantages of using DHIS-2 is that you can set up the system without being a programmer. Some example tasks include adding in new facilities, specifying the data that you need to collect, defining the different types of indicators that need to be calculated, managing user access, configuring different types of outputs, and defining analysis and reporting along any number of categories and dimensions. We've discussed in a bit of detail how we can configure DHIS-2 to display different outputs. In this module we will be focusing more on the customization side. There are four key principles of DHIS-2 design, and we will discuss these in detail. The first principle is that all metadata can be added and modified through the user interface. The second principle is that a flexible data model supports different data sources to be integrated into one single data repository. Thirdly, data input does not equal data output. This means that we can collect data from a number of different tools, but our reports do not have to be a one-to-one match between the forms that we are collecting and the outputs that we create. We also try to support the use of indicator-driven data analysis. This means that we try to create calculated indicators on top of the raw data that we collect. Let's discuss these principles in a bit more detail. In the first principle we indicate that all metadata can be added and modified through the user interface. We've already discussed this concept that DHIS-2 is an open generic platform. What, when, who and how to collect information, which indicators to calculate, and the required reports that are needed need to be defined. This provides flexibility to cater for local needs and allows for interaction with local domain experts to ensure that expertise is reflected in the system. This also provides flexibility to make changes to the system over time. DHIS-2 is not a static system, but many changes can be made in order to meet new requirements. This empowers in-country administrators and super-users to take ownership of the system. We can see this demonstrated in the maintenance application. There are a number of different objects that we can manipulate through the user interface. This includes working with desegregations, adding in our data elements and data sets, creating the indicators that we want to be calculated, adding in the organization units, creating tracker-based programs, as well as a variety of other options that we can edit, both within the maintenance application as well as other parts of DHIS-2. The second principle that we introduced was that DHIS-2 has a flexible data model, which supports a single data repository. So DHIS-2 is not an application that is tailored or fixed to one particular health program. It's rather a tool that supports an integrated information system. We can use DHIS-2 essentially to build a data warehouse. The flexible data model allows for the ability to add new data sets through the user interface. In this way, we can support a wide range of integrated subsystems within one application. Data collection is facilitated through a variety of different methods. This includes web applications, mobile applications, SMS, manual file imports, or through interoperability from other external systems. This enables analysis and correlation of data across different structures within the health system. Diagrammatically, this is really what we are referring to. We have a number of different health programs. They have different data collection tools, different indicators, and different information that they collect. We want to take the data from all of these different programs and place them into an integrated repository. DHIS-2 serves the purpose of being this unified system for reporting, storage of data, consolidation of reports, and other functionality as required. Let's take a look at some of the programs that are available within Trainingland. We can see there is a mixture of different programs. This includes immunization, maternal and child health, antinatal care, surveillance, HIV, malaria, and other health programs. All of these programs can be within one DHIS-2 instance to allow for this integration to occur. The third principle that we discussed is that data input does not equal data output. Reports and data analysis, including all the indicators, are made up of individual data elements. They are not linked to any particular data entry form. The forms and data sets that we use can be thought of as a way to organize how we collect information. However, there does not need to be a one-to-one correlation between the format of the information we collect and the information that we output. The data elements that we collect can be combined into indicators or groups, and then can be compared across programs and forms in various output formats. Reports can be assembled in many different formats and are by no means linked to the design of their data collection form. Here's a diagram representing this in action. You can see that we have a couple different forms at the top. These all link together in the integrated data warehouse. The integrated data warehouse represents DHIS-2. We have a number of different data elements flowing into this data warehouse. They are not necessarily linked to their data collection form on their own. Because we create an integrated data warehouse where all this data is linked together, we can then create outputs that do not necessarily need to link to any of these data collection forms. The outputs can therefore be a combination of data elements from any of the forms that we are using. We can see this in the example indicators that have been created. All this information within the integrated data warehouse can be reviewed by any of the reporting tools that are available within DHIS-2. Let's quickly have a look at an example of this within training land. In this example, we have two data elements along with an indicator. The data elements include the BCG doses and the population of less than one year. Our indicator is BCG coverage. The BCG doses is taken from our routine summary data that's submitted through our health system. Our population of less than one year is taken from our census. This allows us to calculate our BCG coverage rate, even though this data is coming from different sources. The last principle that we discussed is that we want to support indicator-driven data analysis and reporting. So we know by now that data elements describe the raw data that's being collected within the system. Indicators are formulas based on those data elements. They are more powerful in data analysis as they allow for you to standardize different values and compare them across time and geography. Indicator formulas are completely defined through the user interface. Indicators are supported in all of the data analysis and reporting tools and their use is encouraged. We can still use the same indicator as we used in our previous example. If we look at the number of BCG doses in each district, while this does provide us with some information, it does not really tell us how many children still need to be immunized. However, if we look at the BCG coverage indicator, we can now see the relative performance in each particular district. This gives us more context regarding performance and allows us to infer some conclusions about the data itself. This ends this presentation on DHIS-2 design principles. We will be applying these principles through various sessions as we go through this module. Please let us know if you have any questions about these principles before proceeding to the next session.