 I'm based with this Malawi as the DHS2 implementation lead. And over the next couple of slides, I will be taking you through the Malawi case study of the Open LMIAS and DHS2 integration. So when the MOHP embarked on the project for integrating the supply chain system and the DHS2. The main concept was trying to ensure that these two systems are interoperable. Prior to the inception of this project, the HMIS, which is operating on a DHS2 platform, was a standalone system. And also the supply chain system, which is operating on an Open LMIAS platform, is also a standalone system. During the inception phase, I think a discussion initially took place and trying to determine whether to directly integrate the two systems or to use an interoperability platform. And I think the preference at the time was to use the interoperability platform as a policy directive, so to say. So the main objective was to enable the integration and interchange of the supply chain data with the HMIS data and to develop a customized indicator and dashboard for the HIV TB Malaria and RHD programs. Additionally, we wanted to build the capacity of the DHS2 and the LMIAS team to be able to use the dashboards at various levels of the health care system and to make sure that whatever decisions are being made on the ground are informed by the outputs from this work. So from Malawi, the key stakeholders, there were quite a number of stakeholders. The MOH was the project owner and the coordination unit was the central monitoring and evaluation division. So we also had to interact a lot with the HTSS department, which is responsible for managing the logistics data. And of course, the University of Oslo through his Malawi were primarily responsible for facilitating and providing the technical requirements on the DHS2 end. And then the PSM was responsible for facilitating and supporting the technical requirements on the open LMIAS end. And then we also had the GUNICA data for action, which is a Bill and Melinda Gates project, which facilitated the interoperability of the two systems through developing what we call the interoperability layer or automated data exchange platform. So this was supported by the Global Fund. Quite a number of activities were undertaken in the process of integrating the two systems. This kicked off in 2018 October with a readiness assessment where all the stakeholders seemed to agree that probably wouldn't have been ready to start implementation until January. And then once the implementation kicked off, there was a stakeholder meeting that took place in March. And one of the outputs from that discussion was to make sure that we develop standard key performance indicators across the various programs that we're interested in implementing. And then beyond that, a process was undertaken to make sure that whatever indicators we had identified were mapped and documented accordingly. So whatever was coming from the other system had to be mapped as well as what was within THIs too. And then of course, the process of developing the interoperability layer and the master facility registry and just making sure that we have the automated data exchange platform started around June 2019 and was running concurrently with the other project activities. So we had another follow-up meeting to review the indicators. And then we came up with a final list of indicators by September 2019. And then we, because of the nature of the LMIS indicators, we needed to use predictors, which were only available for version 2.32. So we did undertake a process of upgrading our test instance to version 2.32. And then when it took a process of documenting. And whilst this was happening on the other end, on the open LMIS end, there was a development process on their API just to make sure that it's compliant with the data exchange platform. And then we started the user acceptance testing for integration in October 2019. And then we proceeded to finalize the configuration of the indicators that were dependent on the upgrade, primarily the ones that were relying on the predictors function. And then we considered the integration fully complete in December 2019 when we were successfully able to push data from the open LMIS into the DHS too. So some processes were undertaken to develop some change management procedures. And then migration of test, migration of the LMIS data to the test instance. We had the dashboards configured. And then we developed some training materials for an in-country TOT, which took place in March. And then we also proceeded to upgrade our production instance. And we've been replicating the work there. And the final process, which was supposed to be undertaken for this, was of course having the LMIS Academy as well as making sure that we are having district level trainings. But now the district level trainings have been postponed because of the season that we're in. And just to provide a bit of a background on the DHS2 setup for Malawi. So it is the main data collection and aggregation platform. But we do have other systems on the HIS landscape, such as the IRIS, the LMIS, and various ERMRs. So data is mainly collected through pay-per-tape methods at the facility level. And this only becomes electronic at the district level. So we do have the DHS2 mobile, which is rolled out in 13 districts. And basically, these are the districts that have a lot of hard-to-reach facilities. So we did migrate from the DHS1 to the web-based DHS2 in 2020. And this DHS2 server is hosted by the Ministry of Health. And of course, various partners provide support around the DHS2 work, including HIS Malawi and the Kuniga data for action. And as mentioned earlier, we are currently running on a DHS2 version 2.32. So in terms of the information flow, we do have five organization unit levels in DHS2. And this sort of replicates the MOH hierarchy. So at the lowest levels, we have the community level, which is mainly represented by the HSAs and the senior HSAs in the information flow. So they collect the information at that level, and then they push it forward to the facility level, where they are interacting with statistical clerks, as well as various health workers. And then as we move towards the district level, we'll find that there are more players at that level. We have the HMIS office hours, primarily responsible for entering the data into DHS2, where it's now becoming electronic, and we've got various program coordinators, as well as the district health management team. So above that, we have the zone level, where we have the zone health officer, as well as the zone M&E officers. And of course, at national level, we have the program managers, senior management within the Ministry of Health, various directors, and various officers within the ministry. In terms of the programs that are currently reporting in DHS2, I think we have good coverage. We have the child health data, reproductive health, the IDSARA, the HIV and AIDS, although there's also a platform that is running in country. We have the TB data, malaria, nutrition, non-communicable diseases, health education services. And now we do have the logistics data, and also we have the population data. So also to provide a background on the open LMIS and how it's operating in Malawi, as you're all aware, it's an open source platform. And it's mainly used for the electronic logistics management information system. So from Malawi, this replaced the supply chain manager software, which had been operating for 13 years. And in August 2017, we went live on the open LMIS. And it is currently rolled out in all of the 29 districts across 160 facilities, which are data capture sites. So the paper forms are available across over 700 facilities. However, we have 160 data capture sites for the open LMIS. So it's web-based, which means it's accessible anytime and anywhere. And it's mainly used to provide order information that is evidence-based and also to ensure that these are managed effectively. So the data that is currently being collected in the open LMIS includes the closing balance, which is also the stock on hand. And this is collected on the last day of the reporting preparation. And then they're also collecting the losses, damaged products or products that were discarded. And then we have the negative adjustment, which in most cases represents products that might have been sent to another facility or maybe products that were returned. So we also have the positive adjustment, which in most cases might represent the facility that was receiving stock from another facility. Or perhaps maybe an order request within the facility that was supposed to have been dispatched but was not collected. Then we also have the quantity used, which represents the dispensation, what was actually given to treatments. And then we have the stock out days. And then we have the quantity received, which the commodities that are coming in from the Central Medical Stores Trust or there might have been an intervention or a partner decided to donate some products to the facility. So we can see what the LMIS reporting formula looks like. And for every product, we have all of these data variables or data elements which are collected for the form. In terms of the process that the LMIS system follows, so basically the facilities will be responsible for generating the paper forms. And then the paper form is sent to the district or to another facility that then captures the LMIS reporting form into open LMIS. And then we have a district level, the authorization process for the LMIS forms. And in most cases, it is the pharmacy manager who authorizes this. And then this information goes through what we call the Drug and Therapeutic Committee, which is chaired by the district medical officer. And basically it's a committee that discusses issues concerning the district's ordering, how they're ordering the commodities as well as other issues related to commodities. And after it undergoes the scrutiny of this committee, it then goes to the DHOs where it is approved. And then this goes to the Central Medical Stores Trust. So at the Central Medical Stores Trust, they do extract this data from open LMIS and its process and then a dispatch of the commodities takes place going to the facilities where the facility now receives the orders. So just to highlight that the open LMIS and Central Medical Stores Trust are not integrated at the moment. And that is why they have to extract the orders from the open LMIS and then process them outside the system. And then moving on to the architecture that facilitated the integration of the two system, what we're looking at now is a diagram that depicts the processes that are required or the key elements or key components for the interoperability architecture. So the key components include the facility registry, which provides information about where the data will be going to. If we're talking DHOs two terms, then we could say that this is the where variable. And what happens there is that the mapping for the various organization units between the source system and the DHOs two has been outlined at the facility registry. And then we also have another key component, which is the product category. And then or you can call this a product catalog. And this provides the information about the different products and how they are mapped between the two systems. So if we talk about this in DHOs two terms as well, we could say this is the what variable. And then we have the interoperability layer itself, which is basically a mediator between the two systems and is coordinating what is going on between the two registers and making sure that the information that is coming through is in a format that is acceptable for the DHOs two. And then, of course, we have the DHOs two system, which is the final destination for all of this information. So the interoperability layer is built on an open health information mediator platform. And it's basically a middleware system that makes sure that different health information systems are able to talk to each other and exchange information. It's open source and it's configurable to a specific use case. Basically, the source system is required to be compliant to the platform in order to interact with the interoperability layer. And then just trying to understand what is going on on the interoperability layer. As I mentioned earlier, it's built on the open HIM architecture. And we have the open HIE component, which consists of business domain services and registry services, such as the terminology services layer, the client registry. And of interest to us in this case is the facility registry and the product registry. So the interoperability service layer manages the authentication process that takes place between the two systems, the entity mapping, and then just making sure that it's routing the request to the target system. And of course, an audit trail is available, detailing whether the transactions were successful or whether those transactions failed and need to be rerun. So the first step in the process is trying to make sure that on the DHS-2 front, we have created a client that would be used for the interoperability layer or the data exchange platform. And then we have also created the data elements for the open LMI system. And then the access to the API for fetching and posting data basically happens through the profiles. And then, as I mentioned earlier, authentication of transactions is taking place on the interoperability layer, the routing of requests, the error log, as well as the failed request rerun. But we also have to make sure that we have user profiles for the users on the external system. And this is what was used to push the data into the interoperability layer. So on the other side, we also have a system administrator who is in the meantime, checking and monitoring the transactions to see whether successfully gone through or failed to determine if there are any other interventions that need to happen. And then at the end of the day, we expect that the information that has been pushed through the interoperability layer should be visible within the DHS-2. So for the indicators, I'm going to focus on the malaria program. We did develop indicators for malaria, TB, HIV, as well as the Reproductive Health Department. But for this demonstration, I'm going to focus on the malaria indicators. So you'll notice that on this slide, we have some indicators that are highlighted in gray. And these are mainly the indicators that were created using predictors. Whilst the other indicators that are not highlighted in gray represent the indicators that were configured using the DHS-2 indicator app. So I'll just go over the list and how this was calculated. We had the consumption to issuance ratio, which was basically checking the quantity that is dispensed at the pharmacy against the quantity that is leaving the quantity that is dispensed at the dispensary against the quantity that is leaving the pharmacy for the dispensary. And then we have the caseload to consumption ratio, which is basically checking the malaria cases against the quantity that has been dispensed at the dispenser, the treatments that have gone to the clients. We also had an indicator which was comparing the malaria cases against the quantity of the commodities that were actually leaving the pharmacy for the dispenser. And then we had the caseload to stock-on-hand ratio, which was comparing the malaria cases that we have against the stock-on-hand, just trying to see if we are able to cover all the cases that we're having. Then we also have the average monthly consumption, which was checking the average quantity used for the last three months. And this is an indicator that was configured using predictors. Then we have the month of stock indicator, which basically checks the stock-on-hand against the average monthly consumption to determine how many months or how long the stock that we have will take us through. And then we had the stock available, which was just checking if the stock-on-hand is greater than zero. And then also whether the facilities were adequately stocked. And this was basically checking whether the month of stock is greater or equal to one or less than three. So these thresholds are defined by the various programs, and this differs from... So the thresholds from malaria are different from the thresholds for TB and HIV. Then we're also checking whether there were other health facilities that were overstocked, which is basically looking at the month of stock where it is greater than three months. And then checking also if we had facilities that were understocked, which is basically doing a count of facilities that had their month of stock being equal to less than one month. So in short, these are the indicators that we configured for the malaria program for the lack of modalities. And as a country, we have four desegregations for lack, which meant for each of those desegregations, we had to come up with indicators, this list of indicators. So in the configuration process, just to highlight that the average monthly consumption is what is configured first when you're coming up with the predictors. And then the output from the average monthly consumption then becomes your denominator for your month of stock calculation. And then also can be used for your stock status indicators. So going over the list again, just an extension of the previous slide, we also had indicators that were checking the cases that were tested using MRDTs against the MRDTs that were actually used from the pharmacy. And we're also checking the months of stock for the MRDT test kits and then looking at availability, adequately stocked, facilities that were over stocked, and then also facilities that were under stocked. And again, the indicators that are highlighted in gray represent those that were configured using predictors. So after defining our indicators, we did then configure them within DHRs too. And this is just one of the dashboards on the stock status. And we can see that using these visuals, we're gonna see later, we're gonna appreciate later when I go into the system, I'm gonna show you what this dashboard looks like and just try to zoom into the individual dashboard items so we can understand. But the most interesting thing is that we're able to make sure that our dashboards are able to guide the users and it's easy to use the outputs by making sure that we provide instructions for the dashboards. So we did create interpretations within the dashboards. And then one of the interesting outputs that we're able to see is a comparison of the different key ratios that the Malaria program was interested in looking at. So typically you'd expect all of the different items to be within the target line, which is one, but you do find that a number of items such as issuers to consumptions are going over the target line. And this created room for interesting discussions to take place to try and understand what is going on on the ground. Why is it that in some facilities, you will find that the caseload against the consumption is one to one. And in other cases, you will find that this is slightly below or this is slightly above. And what are the expectations for each of these different scenarios? And this is what allowed us to feed into our dashboard interpretations as we had those discussions, we're trying to understand, is it the practices on the ground? Are we taking more commodities from the pharmacies and just holding them at the dispensary? What exactly is going on? Are we reconciling our reports well? So it created avenues for a lot of discussions to take place. And then we also had interesting outputs, which we're also gonna see later. This is one of the stock status dashboard items where you are just trying to check how many facilities were stocked out, how many were under stocked, how many were adequately stocked, over stocked. And then we also have the outliers which are going into the category of invalid. And another interesting output from the dashboard was just trying to understand which one out of the different large dosages was stocked out in a particular period, was mostly stocked out. So for example, we can see here that the six by four dosage or commodity is the one that was mostly stocked out, representing 50 facilities, and then that represents 27% for that particular district. And then just to go over some of the lessons that were learned in this process, I think we go to understand that there was some development work required for the source system, just to make sure that the system is compliant to the data exchange platform, the interpretability layer. And the development process might have taken a bit more time and it's something that needs to be considered well as you're planning on your project lifespan. So it might be possible to configure this in a short space of time. It might also be that this might take longer than anticipated. So we also learned that there is need for the master health facility registry as well as the product registry to undergo regular maintenance and updates because you do have situations where facilities are being opened. Maybe not regularly, but it does happen where a new facility has been opened and maybe this has not reflected on the master health facility registry and you might come across a situation where as you're trying to push the payloads, you experience some failed files because of that. And then again also on the product registry as well, just to make sure that we had an experience in some cases where the product codes changed or some products were discontinued and some of them had been mapped to the indicators. And so you'd notice on the outputs that you were now getting blanks and just trying to investigate that you'd understand that, okay, some products had been changed or the codes had been changed, some had been discontinued. And so those updates also needed to be reflected on the product registry. And then again, we also went through a situation where the open randomized reporting form was updated. And this also meant that the placeholders, the placeholder data elements within the DHHS2 also had to be updated accordingly. And then there were also quite a number of indicators that were requiring data from other systems. Now by other systems, I mean, I don't mean the open LMIS, but another separate standalone system. So what this meant was that that information had to somehow find its way within DHHS2 for us to be able to configure this indicator. A typical example is the GeneXpert cartridge. And for the TB program, this is housed in a separate system. And we had to take a process to get that information into the HMIS just so we're able to configure the indicators and have some outputs from there. And then we also noticed after we had configured the indicators and just trying to understand the outputs and make comparisons with what's in the open LMIS that there was a slight variation between the open LMIS month of stock and average monthly consumption and the DHHS2 outputs for the month of stock and the average monthly consumption. And I think this was mainly something to do with the current month's data not being reflected within the DHHS2. And then another thing that we did learn in this process is that there are multiple scenarios. There are multiple explanations for why things are happening the way they are. For example, if you look at a consumption, caseload to consumption ratio, maybe going all the way to two, something that you expect to be one to one or maybe 1.2. But if it goes all the way to two, I mean, there are a lot of questions that the user is now faced with. Is there a drug-pulphurage? Are we just holding too much stock at the dispensary that we haven't accounted for? What exactly is happening there? So we learned in this process that there are a lot of explanations and some of the issues also boil down to the data collection processes on the ground and how we are consolidating our reporting tools. And now this brings me to the end of my presentation. I'm now going to stop sharing momentarily and maybe open the floor for some questions. And also maybe I would like to invite colleagues from Malawi who are present on the call, colleagues from the Ministry of Health or from the U.S. IDPSM or as well as from the Chronicle Project in case there's anything they would like to highlight or that I haven't reflected recording. Thank you. Okay, thank you so much, Mongani. Excellent presentation. I'm so glad that we were recording that so that we can continue to share that out and make it available presentation for everyone. At this point, please do ask your questions in the Slack. If you are also coming from Malawi and you would like to share some insights or elaborate on something further, please. Also, then you can raise your hand or can they raise your hand? Martin, how do we do this? If we want to unmute someone. Martin, I can't hear you. You're too quiet. Yes, it's possible to raise, click on yes, no and raise a hand. It may be hard to see, but right now I'm using the like for that and guessing that could be working. I might want to stop the recording before we do this part. So I'm gonna stop the recording now.