 In this presentation, we will go over the various data collection tools that are available within DHIS2. Some of the apps and tools for DHIS2 data entry include the web app for data entry, the Android application for data entry, SMS-based data entry, importing files through a manual import process, using the web API and setting up automated imports or interoperability, and tools for entering tracker data, both through the web as well as through an Android device. We'll start with describing the data entry web application. The data entry web application is a well-tested method of entering data into DHIS2. It allows for the most flexibility in terms of presenting data sets and forms through designing custom data sets. Custom data sets allow for you to really closely replicate your paper-based forms. We'll go to DHIS2 and show you an example. Here is an example of a custom form within DHIS2. These types of forms are quite different when compared to default and section-based forms. In a custom form, we can apply different color schemes, and a layout that much more closely reflects that out of the paper-based form that it is replicating. We can have different sections within the form itself. Note that we can also do this in section-based forms, and we will go over an example of this later on. And we can also have totals calculated automatically as we enter data. These types of custom forms allow you to create unique interfaces that more closely reflect the paper-based forms that users are familiar with. However, they are harder to maintain, as every time data elements are added, they need to be added manually within these custom forms. Unlike default and section-based data sets, custom forms are not updated automatically. This is a manual process, and one should keep that in mind when maintaining these types of data collection tools. We can also have forms that are created quickly and more easily maintained by using default or section-based forms. We've also seen these examples before. Let's just briefly review them. Here is an example of a default data set. In a default data set, data elements are displayed within the data entry application, according to the order that has been set up within data set maintenance. We will discuss this a little bit more later on. As data elements are added to this data set, they are automatically displayed within data entry. This makes this type of data set easy to maintain. We also have an example of a section-based data set. In this data set, you can see that there are individual sections, which the data elements belong to. We can define the individual sections through data set maintenance, and then the data elements that belong to those sections will appear within data entry. This is also quite easy to maintain, as we only have to add in those data elements, and then they will be automatically reflected in the data entry screen. In the web application, you can also have additions, such as validation rules and on-the-fly indicators. This can also work in offline mode when connectivity is challenging, and we will demonstrate this later on. We also have the Android Data Capture application. If data sets and forms are already set up, then this is easy to configure. The Android Data Capture app downloads instances of forms which are required to enter data from the server and stores them locally on the Android device. This means that data can be captured while being offline, and uploaded back to the server when connectivity is present. We will show an example of this later on. We also have SMS Data Entry. SMS Data Entry uses Gateway Service Providers in order to connect through to DHIS-2. We provided some links in the resources section, so you can read a little bit more about how SMS gateways work. SMS Data Entry uses a code system in order to get data into the system. Here is an example of a code that might be used to enter mortality data in DHIS-2. We will show an example of using an SMS code to get data into DHIS-2 later on. There are some pros and cons to using SMS phones. The nice thing about SMS phones is that coverage is essentially everywhere. As long as there is any mobile signal that allows you to send and receive text messages and phone calls, you can use SMS to send data to DHIS-2. It is also supported by all mobile phones. Regardless of which hardware you are using, SMS is supported. And feature phones that only support SMS typically have longer battery life compared to modern smartphones. There are some cons however. We saw an example of the code that would be used to enter SMS data into DHIS-2. SMS Data Entry is therefore error-prone. It is also hard to change this data. It has limited functionality as you can only see what you are typing through the SMS screen on the phone. It is also only suitable for forms that are not very long. Referring back to that code, imagine if you had to enter this for 30 different variables. This would become quite challenging as the user would have to ensure that every part of that code is correct. PDF Data Upload is another mechanism to get data into DHIS-2. You can generate a PDF document by data set. This allows you to enter this data completely offline. We will show an example of how this works in practice later on. There are some pros and cons to using PDF as well. PDF Data Entry is suited for using large forms. The data can be entered completely offline as you are entering data into a PDF file. This data can be sent via USB or email. There are some cons however. No data validation can be done through the use of PDF forms. It is also hard to maintain and modify the data after submission. Either you will have to send a new version of the PDF file to be imported, or you will have to inform a user who has access to the online system to change the data online. We also have various mechanisms to manually import data through DHIS-2. There are several examples where this might come in handy. You might have several instances of DHIS-2. These could refer to separate DHIS-2 databases that have been created for each individual health program. You could export data from those systems, and then import the data into some type of data repository, like a data warehouse. The functionality can also be used to import data produced by another system, or also to import legacy data which has been transformed into a format which DHIS-2 can understand. As an example, you can export data from one DHIS-2 system, for example the HIV system to another system, your health information data warehouse. Alternatively, you can also import legacy data. This is usually a one-time occurrence. There is some initial effort to transform that data into a format that is supported by DHIS-2, but once this is done, you will then have this data within DHIS-2 and be able to perform historical analysis. We can also use the web API to get data into DHIS-2. The API uses ADX format to import and export data. ADX stands for aggregated data exchange. We have provided some links in the resources section, so you can read more about this standard. ADX is an international standard developed and maintained by the Quality Research and Public Health Committee of the IHE. We can also use the web API to import data using CSV, XML, or JSON files, both manually as well as automatically. So let us quickly discuss this concept of automated data exchange. In DHIS-2, automated data exchange requires that metadata objects are matched correctly between different systems. This includes data elements, organization units, and other types of objects that have been created. While this might not be trivial to maintain, this allows you to build a data warehouse at various levels by automatically synchronizing items across various systems. Typically, rather than matching names, you will use some type of code to match these across the different systems. In the example shown here, we are looking at organization units that exist within training land. In system 1, we see the names as it would appear. In system 2, we can see that the names are a bit different. We're therefore using the unique identifier, which is equivalent in system 1 and system 2, to match these organization units. This allows for the systems to recognize that these organization units represent the same thing, even if their name is not exactly the same. The last method of data collection we will discuss is tracker. Tracker data is individual in nature. This is in contrast to the aggregated data that we have normally been discussing. This can come in two forms in DHIS2. This includes event data, which is typically anonymous in nature. What we mean here is that there is no name or any other identifiers attached to this particular data. A simple example could be a malaria program that registers each individual positive case without collecting any identifying information. We also have tracker data. This does require the registration of an individual, an item, or any other object we want to track through the system. Tracker data therefore does always have identifiers attached to the data. An example of this could be tracking a pregnant mother through pregnancy, antenatal care, and postnatal care. In order to do this, we will have to register some details about the mother so we can find her each time we want to track that set of health services. For both tracker and events, there are both web applications and Android applications. We will discuss tracker in a bit more detail in other sessions. We have discussed a number of different ways to collect data using DHIS2. Now we would like to demonstrate some of these options. The next sessions will demo these particular data collection tools. We will start by going through the web data entry application, followed by Android data entry, and end the session by demonstrating how PDF and manual uploads work. Let's go ahead and start with the web data entry application.