 What types of data do we have in an HMIS? Essentially, we have three main categories. First is aggregate data. Aggregated data is data that is compiled from clinical services or data that's captured over a period of time, and summed at the end of a certain frequency, say monthly, and that is the value that is submitted. We also have event data. Event data is more ad hoc. It's just a single event that happened, something like a vaccination outreach campaign, and one event doesn't affect another event, but we need to have data from all of the events that are happening. The third is what we call the DHIs to tracker. Tracker is the continuous monitoring of a tracked entity, what we call a DHIs to is a tracked entity. A tracked entity could be many different things. It could be a patient, could be a child, could be a mother. It could even be something that's not human. It could be a borehole, it could be a health facility, could be a household or a village. But anyways, you are monitoring this tracked entity over time through a series of predefined events, what we call a program. A good example of this is a patient tracked through an antenatal care program or an HIV program. In both these programs, we have predefined specific events that happen. For an HIV program, it's initial testing, counseling, and treatment, and then you have continuation of treatment. So monthly, quarterly, or bi-annually, an HIV patient will go in, have their CD4 count, as well as receive more medication. A sub-component of tracker is what we call e-registry. And e-registry is embracing the concept that patients are going through multiple health programs. So a mother who is in a antenatal care program may also be in a malaria program. She may also be in an HIV program. Her children who may be in multiple programs, they could be in an immunization program. They could be in a growth monitoring program. The point is that the e-registry is not program-centric, but it's more patient-centric. So it's treating an individual as engaged in multiple health programs and being able to have those programs interact. So for example, TB and HIV programs may have several dependencies. So if a person is TB positive and HIV positive, maybe the course of treatment changes for each. In that scenario, those programs need to speak to each other. You need to view the patient as a whole and not as separate isolated programs. And that's what e-registry does. Typically, this is more commonly referred to as electronic medical records. Let's take a deeper look at each one of these. So the first one is routine aggregated data. So again, routine aggregated data is just data that is captured in a summed format for a certain period or frequency of time. So the most common one is monthly facility reports. So the common scenario is that a health facility will fill out a monthly summary report, and then they will enter that into DHIS too. So you get the kinds of aggregated data that represent all of the patient seen, all the clinical services delivered, all of the drugs administered over the course of that month. Some features of the aggregate reporting in DHIS too are that we are easily able to see trends over time. The example you see in the bottom of the screen there. We also have regular collection of data, so a set frequency in which we expect to receive data. This helps with things like reporting rates, monitoring when reports haven't come in, making sure reports are sent in on time. We also have consistent indicators over time. So we're able to do things like year-over-year indicator analysis where we have good reliable data coming in from aggregate systems for many years, and we're able to look at long-term trend analysis. Maybe we are even also able to do some projection or forecasting analysis based upon those trends we see over time. Typically, aggregate data has better coverage within the hierarchy, and what we mean by that is that it is easier to capture aggregate data from all health facilities than it would be to, say, capture tracker data from all health facilities. Sending in aggregated data is simply just an easier process and easier to take to scale. So in most countries that are using DHIS too as an HMIS, we see the first thing that happens is that they take aggregate HMIS reporting to scale at community health worker facility and district level, and then follow that up with more individual patient-based data capture as certain health programs require it. Of course, you're also able to drill down and identify issues at local level. So depending upon where you're capturing data, you're able to go from, say, the highest country-level data all the way down to community health worker data if you have them represented in your hierarchy. You're easily able to compare regions or multiple localities against one another. You're able to triangulate with other data sources, for example, capturing commodity data, HR data, infrastructure data, and alongside all of your clinical or health data, and visualizing all of this together at one time. Oftentimes, as I mentioned, data is entered into DHIS-2 at facility or district level for aggregated data, and DHIS-2 supports a very broad range of robust data quality assurance tools for aggregated data. These are things like validation rule analysis, outlier alert and detection, year-over-year trend analysis. We, in fact, have an entire academy devoted on to just going through the various data quality features that are available for aggregated data. There are some limitations. So the biggest one is that there are no details about individuals. So aggregated data, you are not able to go down to the individual patient level. You're only able to see those aggregated values across all patients. So if you have a health program that requires specifically individual data, like adverse events from immunization, you're not going to be able to get that level of granularity with aggregated data. The next one we want to talk about is event data. And again, this is ad hoc singular events that are unrelated to one another. In DHIS-2, we're able to capture data from each one of these events. And again, a good example is a vaccination outreach campaign. Some of the features for event data are that we're actually able to see a lot of detail for individual events. We're able to capture events at point of care or service. We're able to capture several points about one event. And what we mean by that is probably best represented in the maps that you see at the bottom of the screen here. Here, we're able to see what we call cluster or heat maps of individual events. In this particular example, we're looking at malaria cases. Now, this is showing Sierra Leone, but I do just want to make a quick point that this is not real Sierra Leone data. It is fictitious data. But the point still remains that here, you're able to see for each individual event a dot. On the left, you're able to see those individual dots in kind of a heat map fashion. On the right, you're able to see them a little bit more clustered together at a fairly high level. Of course, as I zoom into both of these in DHS2, I would see more and more details. With the red dots, I would see each individual dot becoming more distinct. On the right, with the black dots, I would see those dots disaggregating into more smaller pieces or smaller counts of events until I see an individual dot representing a single event. Using these kinds of heat maps can be a very powerful tool for things like disease detection and analysis. Where are we seeing the most diseases? Different types of vital statistics and civil registration, for example, monitoring deaths that happen and capturing every death as an event in DHS2. And so we're able to build maps and different analyses based upon different causes of death and seeing those and how they're clustered and how different kinds of attributes and qualities of those events that allow us to inform health decisions, policies, outreach campaigns, various things to combat, different kinds of points that are showing in our data that need to be addressed. In event data, we also have workflow support. So aggregated data is relatively straightforward, as you saw in the previous slide, where you just enter your aggregated data into a form. Event data can be much, much more complex and subsequently provide a lot more support to individual health workers that are actually entering the data. So as they're going in and entering the data into the reporting form, the reporting form can be flashing up alerts and notifications about maybe some corrective behavior they need to do or some kind of action they need to take based upon the data that they've entered. It could also be alerting them to maybe potentially data entry or data quality problems that have been detected. It can be prompting them to take different kinds of actions based upon the data that's been entered. There's just a lot of flexibility in DHIS-2 to build in workflow support. One that's commonly referred to as skip logic. So as a person enters data into the reporting form, different questions are revealing themselves or being hidden based upon the answers to previous questions. So you're kind of guiding the workflow as they work through the reporting form. That is supported in event capture as well. Some limitations. So again, with event data, individual events cannot be followed over time. So we're talking about discrete ad hoc events. One event is not connected to another event. Another limitation is that oftentimes, the reporting burden is higher. So there's more data to report for events than what we see with aggregated data. If you're recording 20 events, then if you're using event capture, you're recording 20 different events and capturing data for each one of them. If you were reporting an aggregated form, then you're probably just reporting one form that aggregates the data across those 20 events. Typically, event data requires more devices and significantly more robust server infrastructure. So you're capturing data at lower levels, maybe at community or facility level, and you're capturing a lot more data. So that just means you need more powerful and higher spec servers and infrastructure to support that amount of data that's coming in. With event data, we also have more limited data quality functionalities, natively built into DHIs too. This is because event data can take all kinds of shapes and forms. So it's hard to do broad data quality functionality that applies to each kind of scenario in which you may be capturing event data. You still, of course, can do things like outlier detection, validation notifications. You can do these after the data has been entered or while the data is still being entered to help support the user. But we do have slightly more limited functionality for data quality or event data. The next one to talk about is Tracker. And again, Tracker is the continuous monitoring of a trite entity through a predefined program. And again, a trite entity can be anything you define it to be. It can be a person, a patient, a mother, a child. It can be a village, a household. And you define the specific program or series of events that that trite entity goes through. Some major features of Tracker is that you are able to follow the individual over time. Again, through a predefined workflow. So for example, an HIV patient going through a series of counseling testing and treating over time. You can follow that patient indefinitely. There is no end necessarily, but there is a very specific clinical workflow or workflow assigned to the program. You are able to create working lists for health workers. So the health workers, if they are receiving HIV patients one day, they're able to know these are the patients coming in. This is the status of each one of the patients. This is the kinds of clinical services the patient needs to receive. So there is support to the actual health workers with Tracker programs. Kind of on a similar vein to that, Tracker supports clinical facing analytics such as line lists and Android and in the analytics apps. So we're able to visualize data from individual patients over time. And that can be used at all levels. So at facility level to know which patients are coming in on which days or which patients are lost to follow up. For example, need to be followed up with or tracked down, get in communication with. And you can continuously go up the hierarchy. So a district could see all patients enrolled in their immunization campaigns. Or at national level, you could see the total number of patients that received a certain type of COVID vaccination and you're capturing every single patient in the HMIS and what kind of COVID vaccine they got. Another common one would be say adverse events from a vaccination or immunization campaign where you may see an adverse event at national level, but you need to drill down all the way to the very specific locality where that shot was administered, the patient who received that vaccine, and maybe even the tracking number, batch number for that vaccine. And Tracker allows you to do that. Go from all the way from national level and drill down into the single individual shot that was administered into a specific patient. Again, there is workflow support just like you have with event. So things like skip logic alerts notifications to aid the clinician or the person who's actually entering the data. And of course, we have many different kinds of automated notifications. So notifications that are going to the individual health worker who's putting in the data or providing the clinical service. Notifications that could go to the actual patient. Notifications that could go up to higher levels, really at any level in the hierarchy. So again, in the case of like an adverse event, an adverse event is detected by DHIs too at a lowest level. Then an automated alert could be fired off to people at district or national rapid response teams for them to follow up. There are of course limitations. So Tracker data is just in the sense of volume, a lot more data than we see with aggregate and event data. So this requires even more extensive infrastructure and server support. It also can be much more complex data to enter. And that requires additional training and support structures than just entering simple aggregated data. To be able to get national coverages out of Tracker data, you have to have 100% completion, which means that you need to actually reach every single patient with Tracker. This can be a difficult thing to do, especially in countries that are struggling with say, mobile connectivity or other kinds of infrastructure. Where oftentimes the Tracker data doesn't actually represent the entire patient load or target population. And so it can be difficult to extrapolate national outcome or impact indicators from Tracker data. And again, just like with event data, we have more limited data quality functionality for Tracker data as well. The last point to make here about the different types of data that can be entered into the HMIS is on E registries. And again, E registries is more akin to an electronic medical records where you're slightly disconnecting a patient from all of the health programs. You're looking at a patient more holistically than looking at each individual program. This is a relatively new frontier for DHIS-2. And the way in which we're categorizing this is more along the lines of a comprehensive registry for a patient. And a registry is different than necessarily electronic medical records. Often electronic medical records are captured at point of care, so at the individual patient to clinician interaction. Whereas a registry can be captured after point of care, maybe by a data entry clerk, maybe by a nurse in charge, maybe also by the clinician that actually received the patient. A patient registry is often derived off of some kind of paper record that was recorded instead of directly entering data as you're seeing the patient. In DHIS-2, we are trying to accommodate for both. So if the data is being entered at point of care as well as after point of care. In most of the countries that are using DHIS-2, we find that the best utility is that the data is entered after the point of care and not during direct patient to clinician interaction. And that data entry doesn't necessarily have to be done by the clinician. But at the end of the day, we want a single comprehensive patient record for that individual across all of the health programs that they're in, regardless of when the data was actually captured. So some key features is DHIS-2 can be used as a simple patient registry across multiple programs, as I mentioned, can include decision support for health workers. So as they're entering data, it can flag things, alert things, you know, BMI is outside the acceptable range of different kinds of alerts and notifications. Pending upon the health program that's being monitored. Some challenges with this are just like with Tracker, it requires extensive infrastructure and a lot of training and is really not a full-blown electronic medical records. And electronic medical records is something that's usually deployed at hospitals, health facilities with really large infrastructure, a lot of connectivity, and quite frankly, with users that have a lot of computer literacy or digital data entry skills, just very conversant and familiar with various electronic tools for data capture. And oftentimes in DHIS-2, countries that are using DHIS-2, we find that's not the case that we need comprehensive patient records at facilities that don't have good infrastructure, that don't have staff that are extremely computer or digitally literate. And eRegisteries is a pathway to provide that to them. Again, capturing data from common registries that are entering patient data anyways into DHIS-2. Now let's take a look at the national scale of an HMIS. And we like to show this diagram to illustrate a couple of key points. The first one is that every country wants their HMIS to be huge, to be national scale. Right, so you see scale is the bubble at the top here. Oftentimes, countries want their systems to also be very complex. They want to capture a lot of individual patient level data. They want to capture data very frequently. They want to have data capture from the lowest level community health workers all the way up to national level and capturing all kinds of health programs, a lot of data flowing in all the time. But most countries also want to have their system be very low cost. And the point to be made between scale complexity and low cost is that what we find is you can really only pick two. For example, if you want high scale and a very complex system, then it seems to be fairly impossible to come up with a low cost solution for that. If you want big scale and you want highly complex, again, you're going to need more server infrastructure. You're going to need more devices in the field. You're going to need more training for staff. Those things cost a lot of money. So if you want high scale and high complexity, you're going to have to have relatively high costs. Conversely, if you want low cost, then you need to go with lower scale or lower complexity. And ideally, there would be a world in which we have all three of these. There's a sweet spot where we have high scale, high complexity and low cost. But as we've seen that across the countries that have developed a national health management information system, we just see that you do have to make a compromise at some point. So it's either you pay a lot of money and get high scale and very complex or you're not able to pay as much money and you have to draw down the scale or decrease the complexity.