 In this section of the presentation, we'll cover what exactly the DHIS2 platform is. From a technical perspective, the DHIS2 platform is a free open source software and is primarily used for the collection management and analysis and use of data and information in the health domain and increasingly in domains beyond the health sector, so education, agriculture, land use and management, project management, and even some enterprise deployments. DHIS2 is a modular and layered architecture. Essentially what that means is that there is a generic core. This generic core represents a suite of about 30 applications that the University of Oslo develops. It's probably best to think about DHIS2 maybe as a smartphone. On your cell phone, when you first buy it, you see that you have several applications that come with the cell phone itself. So these are things like sending, receiving SMS, making telephone calls, maybe some other just configuration applications. And DHIS2 is the same way. So when you download DHIS2 for the first time, you'll see that it comes with about these 30 what we call core applications. And these 30 core applications are for things like data entry, data analysis, and really the base functionalities that we see are necessary for DHIS2 to serve as an HMIS. On top of these core applications, there exists a broad ecosystem of third party developed applications. So applications that are developed outside of the University of Oslo. We'll come back to those and give some examples of those later. This application ecosystem, the core plus the third party developed ones are all resting on top of a data warehouse. This data warehouse is what is storing all the data and the applications are going in and adding new data or pulling out data for analytics. There are currently about 90 applications that have been developed outside of the University of Oslo that are available on the DHIS2 app hub. The DHIS2 app hub is a place where people can share the applications they've developed and then anyone can come and use those applications in their own DHIS2 instances. You can kind of think of it as like a Google Play Store for DHIS2. Of course, you can look at demos of DHIS2 on play.dhis2.org. That's where you're able to go in and play with data, look at all the various applications that are available, download new applications and see how exactly they work. You can see on play.dhis2.org that we have three versions of DHIS2 at all times. The most recent release and the two previous releases after that. That's our policy is to support three versions of DHIS2 continuously. One of the key components of the DHIS2 platform is the org unit hierarchy. This really forms the backbone of DHIS2. Essentially the org unit hierarchy is the organizational structure of the database which corresponds to the structure of the Ministry of Health or the project or organization that is using DHIS2. Very often times you can think of the org unit hierarchy being the exact same as the Ministry of Health hierarchy. For example, facility level, district level, provincial or regional level, national level. And then you have under each one of those levels all of its component parts. So you have all of your facilities under one district. You have all of your districts under one province. You have all of your provinces under one region and you have all of your regions under one nation. You can subdivide these org units as what we call them into various different groups. So each health facility is an org unit. Each district is an org unit. Each province is an org unit. The nation is one org unit. And each one of those org units has multiple children as you go back down the hierarchy. And you can reorganize and reclassify these org units into different kinds of groupings. For example, all of the health facilities that are public or all the health facilities that are private, you could turn those into different groups, even though they may not be in the same district or province. In many countries, DHIS2 serves the de facto master facility list. So again, this is just the list of all of the facilities and attributes or qualities of those facilities within the Ministry of Health hierarchy. But in the top picture here, you can see something what we call an org unit profile. And so this is looking in the Maps app, which is a generic DHIS2 analytics app that you're able to build thematic maps in. You can click on here a facility and you can see on the right side of the screen an org unit profile open. So you see the facility name, you see a picture of facility, and then you see some key attributes of that facility. These attributes that you see listed here like facility ownership, facility type, code, these are all configurable. So if you want to show different things here, you can. But the point is that at a quick glance, you're able to see some key stats and information about each facility as you're moving around and clicking on them. One of the newest additions to DHIS2 is the ability to make catchment areas for health facilities. You see that in the bottom picture here. We have used an external software called Crosscut to actually draw health facility catchment areas. And then we import those health facility catchment areas into DHIS2. So DHIS2, you're not able to draw the health facility catchment areas in the DHIS2 itself. You have to use external providers like Crosscut or Grid3. The way that Crosscut and Grid3 draw their health facility catchment areas is a semi-automated process where they factor in many variables. For example, population, density, distribution, road quality and access, land cover, geographic features like mountains, rivers, streams. All of these factor into drawing a health facility catchment area, as well as road condition walking time. And that catchment area should indicate where the people living in these various areas will go to for clinical services. Of course, it may not be 100% accurate each time. In the Crosscut application, you're able to go in and modify the catchment areas to be exactly what you see on the ground. But it is typically a good starting place to draw the catchment areas in Crosscut or Grid3 and then import those over to DHIS2. In this section, we're going to cover the various data models in DHIS2. Previously, we talked about the three different data types that you can enter into an HMIS. Here, we're going to go in a little bit more detail about these three different data types and present them from a more technical data model perspective. So starting on the left side of the screen, the first one is aggregate data. Again, aggregate data is coming in routinely. These are examples of facility monthly reporting forms. They give us not terribly granular data, meaning that we're not able to see individual patients, but we're able to see aggregation of patient counts routinely month after month, maybe week after week continuously. The next one in the middle of the screen is event data. And again, event data is ad hoc data from a single event that happens in time. One event is not related to any other event. There's no longitudinal record of events. One event happens, unique data for it, and then maybe another event happens somewhere else, but that event is unrelated to the first event. We see event data being used for many different types of public health campaigns. For example, outreach, mass vaccination sites, mass male circumcision events, clinical visits even. So if health officer, district health officers going around and doing facility site assessments at different health clinics, they might record those as event data. We also see many educational events, educational events happening in schools, educational events happening with mothers groups, traditional leaders. And you want to, say, capture the number of participants that came to these events, the number of people trained, some of the outputs or outcomes of these events. The next one is what we call tracking. And here, again, we're looking at monitoring a patient or any kind of tracked entity over time through a series of predefined stages. So we can think of tracking a pregnant woman through her antinatal care visits. We can think of tracking a newborn child through immunization. We can also track things that are not people. VHS2 is a very flexible platform, and you can define a track entity to be whatever you want. So, for example, we can track equipment through a series of routine checks. We can even track drugs. So we can track drug shipments from warehouse to district to facility. We can track things like boreholes or schools or villages, households, basically anything that has a predefined, fairly specific set of stages that it goes through. And these stages can repeat indefinitely. So, for example, tracking an HIV patient, we expect, once an HIV patient goes through testing and begins treatment, that they will never end treatment. So that treatment stage repeats indefinitely. So these three types of data, aggregate event and tracker data, all feed into the data warehouse that I mentioned earlier. This data warehouse then produces various types of analytics. So we can produce maps, pivot tables, and charts. And we can put all of these onto dashboards. We can do combinations of aggregate data, event data, and tracker data on all of our various different analytics. So we can make, say, one pivot table that includes some aggregate data, some data from events, and some data from tracker at the same time so that we can maybe do some data triangulation or find more detailed insights as we layer these different data types on top of each other. One important thing to mention is that we have seen a necessity for making a distinction between aggregate tracker data versus individual data. Many countries have requirements to have aggregated values at some frequency, maybe monthly, weekly, quarterly, maybe annually. But we also see many countries trying to go to more individual-based data. So we want to monitor all pregnant women. We want to monitor all patients in treatment and care as individuals to make sure that they're receiving adequate care. So what happens? We need to make sure they were able to capture that tracker data and then convert that tracker data into aggregated data that's available on our routine reports. What we actually have in DHS-2 is the ability to capture individual-level data aggregated via various program indicators and then automatically push that into an aggregated data value that is then able to be summarized in a periodic report. One of the core applications that the University of Oslo maintains is what we call the Android Capture App. The Android Capture App allows for data entry via mobile phones, specifically Android devices. In the Capture App, you can enter both aggregate event and tracker data. And that's what you see here represented. You see on the far left of the screen entering aggregated data. In the middle, you see an example of entering some event data. You can also see that the Capture App on Android supports some workflow guidance. For example, we have icons here. We have, on the right side of the screen, entering some tracker data. And again, you see we have various icons, colors. As a user goes through this, they may see some notifications, tips, as they're going through the data entry process. We also have many apps for data analysis, both on mobile devices as well as on the PC or through web browsers. So the Android Capture application that I mentioned previously has some native analytic functionality. So that's what you see on the left side of the screen here. You see some charts that are being produced in the Capture App based upon the data that has been entered on that device. Then, if a user wants to see their standard DHIS2 dashboards, we see the picture on the right of the screen where a user is able to log onto DHIS2 through their mobile web browser. And then they're able to navigate to a dashboard. You'll see that in this example, the dashboard is rendered to be optimized for a mobile screen. Once the user is at the dashboard, the user can save the dashboard to be visible offline. So that way, if the user is going out to a health facility that is offline, but they want to be able to review data with that health facility once they get there, they can, before they get to the health facility, while they still have mobile connection, they're able to go to the dashboard, they're able to save that dashboard to be visible offline. And then once they get to the health facility and they no longer have mobile connection, they can still visualize that data, they can still analyze the data on the dashboard and share that insight with people at the health facility, for example. So here, just to overview, we have, in the Android capture app, native analytics that are based upon the data being entered into that capture app. We also have access to users through any web browser, mobile or on a PC, access to their dashboards. And again, those dashboards can be saved to be visible offline.