 Welcome to the session on what is an HMIS, Health Management Information System, and how it is used. In this session, we have several learning objectives. The first one is to understand the primary purpose of a Health Management Information System. We also want to be able to describe the architecture of an HMIS. We want to be able to identify the various reporting levels within an HMIS, to understand the types of data captured in an HMIS, and we want to understand the core functionalities of DHIS2 as it functions as an HMIS. First, we're going to start with the HMIS principles. So what is an HMIS? An HMIS is a Health Management Information System whereby health data are recorded, stored, retrieved, and processed to improve decision-making. In this picture, we see the extent to which the DHIS2 software is used as an HMIS, currently as of 2022. It is at national scale in 68 countries, 22 Indian states, and it's currently piloting in an additional six countries. You can see the scale of growth as DHIS2 serving as an HMIS from 2006 to 2022. Today, DHIS2 serving as an HMIS covers about 2.3 billion people worldwide. A key component of an HMIS is data quality. Data quality should be monitored routinely as the production of high-quality statistics depends on the assessment of data quality and the actions taken to improve it. Additionally, an HMIS is crucial for evidence-based decision-making and policy to inform decisions making during planning, implementation, and evaluation of health programs, and for the appropriate use of resources at all levels of the health system. What are some characteristics of a strong HMIS? A few of these are key leadership roles and responsibilities throughout the entire organization of the health system. Individuals should know what their role and responsibilities are associated with the HMIS at various different points throughout the planning cycle at all levels within the Ministry of Health. This includes data entry, data cleaning, data quality, and data use. A well-defined HMIS also has a clear strategy or plan, a long-term sustainability. An HMIS also has standard operating procedures. These standard operating procedures, again, inform the users of the HMIS when they should do what within it. So these may be standard operating procedures for different users at lowest levels for data capture. These could be standard operating procedures for highest level users for planning and policymaking. But we find it is very important throughout every touch point within the HMIS that users have a clear understanding through standard operating procedures, how they should interact with it. In DHIS2, there's many ways to communicate standard operating procedures. You can actually embed those standard operating procedures into the dashboards, into the analytics that users are interacting with within DHIS2. You can also build in standard operating procedures into the data capture itself. So for example, certain data quality standard operating procedures or processes to ensure data quality can actually be built into the data entry forms so that users are reminded of the standard operating procedures as they're actually entering data. Characteristics of a strong HMIS also include health indicators. And it's important to note that health indicators is a very broad categorization. Definition of a health indicator varies depending upon, of course, who you ask. Certain groups will appreciate that a health indicator is any data point captured within a health system. Others may consider health indicators to just be those calculated values that are derived off of base data elements that are captured. The point to be made is that the list of key health indicators should be well understood and agreed to. Of course, indicators do change over time as clinical practices, workflows change and adapt. However, it is important to keep in mind that indicators should remain relatively constant and great effort should be made to make sure that indicators are well understood and available to all users within the system that need to interact with them. Another characteristic is that the architecture of the HMIS should be adaptable and include all data sources. So of course, again, clinical practices change, there are new regimes, there are new processes put in place and the HMIS needs to be able to adapt, evolve as the health system changes. We find that a static HMIS or one that's overly rigid ultimately will hamper provision of clinical services. It won't allow users to be able to enter or extract the data that they need. So DHIS 2 as a platform is built to be highly adaptable and customizable as your requirements for your HMIS change over time. Finally, the last key characteristics on this slide is that data collection tools and methods are well-defined. Kind of going back to our standard operating procedures that the standard operating procedures are referring to the well-defined data collection tools and methods and that users that are using these are well trained on them. Some additional characteristics of a strong HMIS is that it covers all health programs, including key health inputs. So typically when we think about health data, we're thinking about clinical data, clinical service delivery data that's coming from maybe health facilities, district health offices. But what we also need to have is an expanded perspective that there are other health inputs that are critically important to delivering adequate clinical services. For example, HR data, human resources data, logistics data, finances data, the HMIS should be the central data repository for all of these key data points, not just clinical service delivery data and disease surveillance data, but also all of those inputs to actually addressing those. For example, HR, logistics, and finance. We find that if you don't have one of these critical components within your HMIS, it becomes very difficult to actually do triangulation activities where you identify where are the limitations to your clinical service delivery that you need to actually improve. If you're only collecting health program data, then what you will see is maybe one health program or one area in your country is performing inadequately. But of course, to provide adequate health programs requires many other data sources. If you don't have those data sources to visualize what's the bottleneck, what is causing the deficiency in performance, then you won't know where to address. Some additional characteristics of a strong HMIS is that it includes population statistics and population survey data. It is extremely important that HMIS has the most updated and reliable population data. Many of those key indicators are based upon population statistics. So we think about things like national coverage rates, reporting rates. These are based upon a denominator that is usually a population. If we don't have updated population statistics or reliable population statistics, then we find that we're not able to calculate some of those key impact indicators, like coverage rates. And third bullet point here is that the HMIS is not operating as the only information system in the country. There are of course more specialized and upstream tools that the HMIS must be interoperable with. For example, DHIS-2 is not specifically designed to be used for warehouse management, but a key component of any supply chain system that is making sure to minimize stock outs and deliver commodities to health facilities when they need them at adequate amounts. A robust strong warehouse management information system is required so that warehouse knows when to distribute, what to distribute, and where to distribute commodities. Again, DHIS-2 is not designed to be this kind of system. This is a very specialized system. However, there are other software and platforms that are specifically for warehouse management that can communicate shared data with DHIS-2. Another common way in which we see HMIS being required for interoperability is through specialized tools for data capture at the lowest levels. So for example, workflow support tools for community health workers, where a community health worker is interacting with patients and there's specific applications that have clinical regimes built into those to help guide the workflow of the community health workers. This is a functionality that is available in DHIS-2. However, we do find that around the world, there are many other application specialized tools for this. The important point is that at the end of the day, those tools that are capturing that data at the lowest, most granular level should also be able to feed into the HMIS. Of course, at the end of the day, all that data at the lowest level is feeding into some of your key indicators that you're looking at in the HMIS. The final point here is that we must have robust procedures to share data regularly with all stakeholders. What we mean by this is that users of the HMIS must feel that they get more out of the HMIS than what they have to put in. If the HMIS is just continuously a burden to a user, something like an obligation that they feel they have to do, then the use of it will diminish over time. The HMIS should be a living breathing system that is giving back to the user in the form of analytics, insights, supporting decision-making, more than is what requiring the user to put into it. Feedback, automated feedback alerts and notifications is a core functionality of DHIS-2, one that we'll cover in other sessions, but we need to ensure that the users throughout the entire hierarchy, meaning that all the way from the Minister of Health down to the lowest-level community health worker are receiving feedback based upon the health programs that they're monitoring, the clinical services that they're providing, so that they are getting critical information that helps support their jobs. Some additional characteristics of a strong HMIS is that it has robust procedures to assess data quality at all levels. Data quality is everyone's problem, and the HMIS needs to produce data quality analytics support to all users at all levels, meaning that everyone at each level has some responsibility for data quality, and that the HMIS is supporting that responsibility, whether it's checking data at the lowest level at data entry, or is doing high-level quarterly outlier reports and analysis at national level. Every single point along the HMIS, from the lowest level to the highest level, should have data quality procedures built into it, and those functionalities that are required or those analyses that are required to perform those at each level supported as well. An additional characteristic of a strong HMIS is that it has a means to define HMIS performance and adaption to changing data needs. So how are you able to tell if your HMIS is actually doing what you wanted to do? And of course, what we wanted to do is to help support decision-making, policy planning at all levels. How do we know if it's doing that? We need to have some kind of routine way to assess the performance of the HMIS to support the processes that you have established its role in. For example, how do you know if an HMIS is being used to help guide monthly district health planning sessions? We need to have a way to assess this. We need to have a way to appreciate when the HMIS is not performing well in its role, in its stated role, and we need to be able to change it. Once changes are made, we also need to be able to communicate those changes to the end users so that they're able to adapt their work practices to the changed HMIS. We find that many HMISs over time are not changed enough that work practices evolve, but the HMIS is stuck in place. Again, if it's stuck in place, not flexible, not evolving or changing, then it becomes less relevant. It becomes less useful. If it becomes less useful and used, that typically means that health data is not being used for decision-making as we would like. So to be able to tell when the HMIS is not performing as we intended, and we need to be able to change it and then communicate those changes so that the end users are able to adopt those new practices. The third bullet point here and something that's extremely important but often overlooked is that the HMIS is ultimately a data warehouse. It is a piece of software and that software must have adequate server infrastructure and technical staff to support it. In the DHIS2 user manual, we have guidance on the minimal requirements for deploying DHIS2 at very large scale as an HMIS. So what's the minimal server requirements that you have? What kind of technical staff do you need to have to be able to support that? These are very specialized individuals and equipment. It's not something that most people are going to be able to just pick up and learn overnight. It requires a lot of advanced training to be able to adequately set up server infrastructure and maintain that infrastructure over time. The final bullet point here is that a strong HMIS should have a mobile device management system if mobile phones for reporting or data analysis are deployed. And what we mean by that is that you need to be able to track the usage, availability of all of the devices that are being used to either feed data into the HMIS or are being used to analyze data out of the HMIS. We've often see that many countries put in great expense to buy mobile phones for facility health workers or maybe community health workers for district health officers. And you need to be able to ensure the longevity and management of those devices. So there is specific software called mobile device management systems that you can install on these devices that help you manage and see if those devices are online, if they're being used, if you have any problems with them, you're also able to make sure that they're functioning adequately. We find that HMISs that do not have mobile device management systems are often having to replace mobile devices more frequently than those that do.