 Okay. Hello, everyone. Once again, my name is Daisy Kusima. I am with his Puganda. And as his Puganda today, we shall be presenting the use case on National Health Facility Quality of Care Assessment Program, commonly known as the HFQAP tool. His Puganda worked with Ministry of Health Standards, Compliance and Patient Protection Department, as well as the Ministry of Health Division of Health Information and partners like MacCary University School of Public Health to customize the HFQAP tool using the DHIS II tracker. The tool itself, the HFQAP tool itself was developed based on systematic review of the Yellow Star Program, the Service Availability and Readiness Assessment, also known as the SARA tool and the Health Facility Assessment Tool. The tool has a total of 110 service delivery standards, and the assessment provides, allows supervisors to evaluate whether the health facility is compliant against each standard. So these standards are grouped into 10 modules of which examples are the health financing module, the human resource module, the leadership and governance module, to mention, but a few. So based on these modules, like I said, standards are grouped into 10 modules and percentage achievement is able to be calculated from each of these modules, and then the modules scores are able to be summed to get the facility score. The main objective of this tool is to provide regular information on quality of care and the functionality for both public and private not-for-profit facilities. This helps to contribute to continuous quality improvement. With this tool, we are able to generate information on status of service delivery. We are able to generate the level of performance for health facilities based on the different service delivery standards, and we're also able to determine the performance of health facilities based on their star ratings. So previously, before customization using DHIS to aggregate, data from this tool was being captured using, sorry, before customization into DHIS to tracker, the data was being captured using DHIS to aggregate. So what would happen is that the data would be collected from the health facility during the assessment, it would be collected on a paper tool, and then it would be entered into the system, either at district or national level. This presented challenges with data analysis, given that some of the data captured is categorical in nature. So in order to analyze the data, what the Ministry of Health would do is to download the data using the API and then do further analysis using external analysis tools like Excel, Stata and others. This also presented a challenge in providing health facilities with the information on their performance in real time. So they would have to wait for this analysis to be done so that they could then know how they are performing or the results of the assessment. So the Ministry of Health realized a need to do this analysis using the inbuilt DHIS to analytic tools. That's the decision to move it to DHIS to tracker. So currently, data is being captured using a DHIS to tracker based program. The DHIS to Android capture app is being used. And what happens is that the assessors go to the facilities to conduct this assessment with tablets that have this DHIS to Android capture app on there. So they are able to conduct the assessment as they're entering the data into the system. And as such, they're able to get the module scores since the module scores are calculated during the assessment, as we shall see when we're looking at the DHIS to features used. We are also able to calculate the star scores using the indicators within DHIS to, and one is able to pull the analysis from pivot tables, data visualizer and more. This has also brought the ability for further and deeper analysis to be done using event reports, seeing as users are able to get into the event reports, get to a particular standard, and see the areas of weakness that they need to improve on and also able to see their strengths. This has also helped in continuous quality improvement. So the DHIS to features that this system leverages on. First of all, it's the DHIS to tracker program. What's happening is that the system is a DHIS to tracker program. Like I said, the tool is based on multiple 10 modules. And these modules have been customized as program stages in DHIS to tracker, as we are able to see within this image here. So every module is captured as a program stage, and one is able to go ahead and enter this data in there. I've also made use of the DHIS to Android capture app. Like I mentioned, it is the one that data is entered is used, it is the one that is used to enter data at the facilities during the assessment. We have met use of the program rules within DHIS to to ensure that we are capturing data that is of good quality. So we had we have different scenarios that different standards that apply to different health facility levels. For example, you find that a particular standard applies to a health center for but does not apply to a health center to. For example, maternal health that is not really done at health center twos. So as such, we made use of the program rules to ensure that when an assessment is being done, if one is at a health center to their only seeing questions that are applicable to a health center to. We also made use of the skip. Sorry, those were the skip logics. And then we also made use of the assigned value program action, because there are some questions whose response is determined by a response given to a previous question. So to ensure that quality data is captured, we assigned values based on whatever question was answered before. We made use of program indicators to calculate scores, which were displayed in real time for feedback given to health facilities. So module scores as seen here in this image, the module scores are calculated and displayed within the assessment dashboard. They're also viewable from the, they're also viewable from the the DHS 200 capture up. So that made it possible for the assessors to be able to give feedback to the health facilities during the assessment, other than having to wait for later for the health facilities to know their performance on the assessment. So we made use of the aggregate indicators to calculate scores for facilities, districts and regional comparisons. So with the aggregate indicators, we, since we had program indicators for the module and standard scores, we use the aggregate indicators to come up with a star scores for the different facilities. We use the event reports, we use the event reports as Aliya mentioned for partners and the ministry and district level to be able to deep dive into the data and identify where there is need for improvement. This is all helpful in the continuous quality improvement of care within the health facilities. Finally, we have the DHS to dashboards, which are accessible to all users. The dashboards are able to display the performance of the different facilities. We have one dashboard here that shows the module scores and the star performance by the different facilities. We're able to see the facilities that are in red, we're able to see facilities that are in yellow and those that are in green. So this is points the facilities to which areas they need to improve on. It also points the district to the areas that as a district they would need to improve on, and therefore helps in decision making. We're also able to see performance by the different standards on our dashboards. This tool is being used countrywide, it's being used by all districts in the country to assess public and private not for profit health facilities currently. We have 131 users ranging from Ministry of Health all the way down to the districts. Then there are also different types of assessment that are captured within the system. We have assessments that are held at ministry level, and those are ministry led. So those are able to be captured. Then we have assessments that are led by the district. For example, if a district decides they would need to do an assessment and find out how they're doing as a district, how they're performing as a district. We have partner led health facility assessments, these assessments by the partners most times are focusing on a particular module. For example, if a partner is supporting the human resource of health facilities, they're able to get into the system and do an assessment only just that one module. And then we also have the health facility self assessments whereby a facility wants to assess itself and see its performance. So here we have an image of the data entry screen at the point of registering an assessment where we have an assessment type where we are able to capture whether it is a national assessment, a self assessment or a modular assessment. So how was this rolled out. First of all, this whole process started from the Tracker Academy in 2019 that was held in Chigali. So what happened is that there were participants from the Ministry of Health division of health information department from the Ministry of Health staff the department, as well as partners. During one of the sessions who are asked to as a country sit down and discuss on one tool that we could customize in DHIS to Tracker. So the participants from the SCAP department shared with us this HFQAP tool shared with us the challenges that they were facing with the tool. And therefore, we agreed that it would be best that we customize it in DHIS to Tracker. So we had a need for the Ministry as a whole the SCAP department as a whole to agree which they did. And we began our joint customization workshops in July 2020. So, we're able to see an image of one of the joint customization workshops there. In these workshops, we had to sit down again, look at the tool again, look at the key indicators that the SCAP department would like to have pulled out of the system, and then agree on whether event or Tracker based program would be the best of which we agreed that Tracker would be the best since it was a it's a really, really big tool, and it would be difficult to have as just a single event. And also we went ahead to look at the indicators, agree which one would have as a program indicator, which one would have as an aggregate indicator, agree on what would have on our dashboards, and then of course started on the customization work. After this, after the customization work was done, we did field testing. So this field testing was aimed at trying out the tool within a facility, seeing what the assessment process would go like while using the Android capture app, and then also making the system refinements based on the feedback there. So this field testing was done by the customization team, one of the members of the team is here. It was done by the customization team we picked nearby facilities, like I mentioned different standards apply to different health facility levels. So we had to ensure that we picked different facilities that are of different facility levels, and we went out there and did a mock assessment with some of the health workers. And with this we were able to get an idea of what the user experience would be like in the field with the tool, and also get ideas on what we needed to improve in the tool. In November 2020 a team was selected to pilot this, this tool, and the pilot was conducted in the West Nile region of Uganda, and it was covered 363 facilities. And on the feedback given changes were made to the system to improve it as well. Then in July 2021 we had a training for a team that was going to go out for a ministry lead assessment. This assessment was covering 1086 health facilities across the country. Now during the pilot and this large assessment, there was continuous support given to the assessment teams by the customization team, as well as the Ministry of Health IT team which had been trained in use of the system and as well pulling out of data from the system. So this support we created WhatsApp groups where people were able to share any challenges first, and of course there were also phone calls to support them. Of course we also had a manual or brief SOP that was created for these field teams to go out with that they could refer to in case they faced any challenges. So this is a picture from one of the assessments. There were two major challenges first. One of them is the Android app performance. Like I mentioned we developed, we customized program indicators, but some of the modules had a large, large number of questions and that's a large number of data elements. So as such you would find that the program indicator is really really complex and therefore there's going to be some processing issues with generating the figure coming from it. An example of these indicators is this one here. We are able to see the number of data elements that are being used in the calculation of this indicator. So this was the problem also the number of program rules. So this was the problem especially when it came to the health supplies, medicines and equipment module, which has about 500 data elements. What would happen is during the assessment, when the when assessors would get to that module, the app would either crash, or it would either crash or the tablet would slow down. So what we are trying to do or what we are planning to do for this is to split that big module into three program stages, so that the processing burden is cut across the different program stages rather than being on just one program stage. The other challenge faced is that since assessors were assessing more than one facility, there are times that they would move from one facility to another and forget to ensure that the modules when they're entering the modules data, the right facility is selected. For such you would have some modules being attached to different facilities than what their data is for. For example, you have an enrolling facility as maybe Mokono Health Center for, but then you're seeing the module score is being attached to a different health facility. So with that we had to emphasize in the trainings that at the point of entering modules, users have to be careful and ensure that they have checked that the right, the right facility is selected. We also generated a Python script that would ensure that all the modules or events are attached to that enrollment facility so it would just switch all events to their enrollment facility. So moving forward, SCAP department together with districts and partners will continue to use the tool to conduct assessments and provide system improvement feedback. We also hope to incorporate private health facility assessment needs. Private health facilities have some assessment needs that are unique to them and do not apply to public facilities and private not for profit facilities. There is equipment that is that private facilities are able to have that public facilities do not have or they have differences in their, their human resource. They have differences in their financing channels. So as such, we have to find a way to incorporate their assessment needs within the system so that it can be used across all facilities regardless of whether they are private facilities or public facilities. We also digitize client exit interviews into the system. We hope to cascade training in information and data use from the district to health facility teams and other users of the system. We really, really hope that facilities can be able to master the system and be able to use it for their quality improvement use the data from the system for their quality improvement. As I previously mentioned, they are able to get into event reports and see the areas where they need to improve. It would be good if their capacity is built so that they can continuously use the system and aim to improve their quality of care. Daisy. Yes, please. One minute remaining. Sorry. Okay, sorry. So the last point is that we hope to train and empower the SCAP department team to manage the system and then hand it over to them. This is a ministry of system of, it is a ministry of health system. So we really hope to empower the SCAP department train them, get them to be comfortable with the system, get them to know how they can make use of the data in the system, how they can do their analysis. And then finally hand it over to them so that they can run the show. I think that's mostly it from his Uganda. We thank you for your time. Thank you for listening. And we welcome any questions, comments and suggestions. Thank you. Thank you very much Daisy for this wonderful presentation from his Uganda. Due to the time limitations which we have, we encourage participants to use the Slack channel to post any questions which you have. The facilitators will try their level best to kind of respond in the Slack in real time while we are conducting this session. So please feel free to post your questions on the Slack. Next is a presentation from his Rwanda, our colleague, Jean Paul will present the use case. Welcome Jean Paul. I think Jean Paul needs to be co-host in order to share his screen. Can someone take care of that? Hello everyone. Yes, please, someone can help me. Thank you very much. Thank you very much. This is Jean Paul from his Rwanda. It's my pleasure to be on this platform to share with you. Thank you all about how his Rwanda in partnership with the Ministry of Health contributed for COVID-19 cases and lesbos by developing and implementing the COVID-19 tracker. We shared with you what was the gap and what was the proposed solution and how the solution tried to contribute for case evidence and the lesbos and what was the result and what is the way forward. And of course by discussing also a bit about the challenges and the descendants from the process of implementing these COVID-19 cases. Rwanda Countries, the government of Rwanda was fully involved in the implementation of different solutions so that it can contribute to the service and lesbos and fight against the COVID-19 from the citizens of Rwanda. And before the pandemic, there were no tangible systems which can help to be used in service and response. Of course we have had a system which used to correct that for immediate disease but it was not ready to solve all issues related to the pandemic due to its complexity. So the MOH with the support from the Rwanda has developed the COVID instances and up to now we are still collaborating to see how we can provide support for enhancement required for the two instances both for COVID-19, Soviet system and a test for vaccination. Maybe looking a bit on the structure of coordination here in Rwanda for all activities related to the service and response regarding COVID-19. The country put in place the national coordination structure and you will see on this structure that there is a unit of service where there is a data management. And of course data management was very complicated using paper-based system. Using this paper-based system and also considering the COVID preparedness and the response here in Rwanda is structured in this way. Where the first activity and the first place for here is to detect the suspected cases on time and those who are suspected, they are tested. And being tested, either those who are suspected they are put in isolation or in the county and after being tested they become confirmed or negative. And for those who are confirmed they are put in treatment center or even this time those without symptoms they remain at home. And also from those confirmed cases they are contact tracing and after contact tracing they are tested, they are followed up within four hours. Those with symptoms they are put in quarantine, those without symptoms we end up they follow up. So considering these steps to care about the suspected cases and using also paper-based systems towards not is that's why here this is the manual process with paper forms from the food. You see at the time when we are using the paper-based system those who were supposed to go to the field for testing they went with this paper for information correction. You see these are laboratory tools and on these sample correction tools they were supposed to develop a kind of unique code manual which was not really very easy. So this is the case investigation form used for the paper-based system and filling this case investigation form it takes like between 10 and 15 minutes which was not very easy due to the queue of persons to be tested. So manual testing through different challenges like very long process without unnecessary difficult process during specimen process. It was also hard to trace agent samples or specific samples due to the manual work involved manual process of lab ID and this also involved some deprecations. There were a list of deprecating lab ID and from that you may even issue testing results from the wrong person. So that's one of the challenges from the manual testing. Lays of results and clients were not happy. Module to lab take from sample correction to results. These are some of the challenges. So from that is Pirwanda but collaborating with the MSO we are supposed to find solutions and that's why from the above challenges identified. We are going to develop COVID-19 case-based surveillance system with the following. These are some of the features. This system has the capacity or feature of printing out results. We have also passenger cater form to facilitate people from outside or those who want to go upload they may fill that form online and reaching to the airport they are tested without delay. We have also feature SMS and emails notification for registration and issuing results. There is a certificate photo where after being tested someone can get a certificate of testing results without delaying just by downloading. Then there is a safe registration form just to reduce time and lines and testing sites. We have also an Android app scanning travel certificate because it was necessary to enable verification features so that when someone is tested and reaching to the airport is to verify the information. If the information are similar to those in the system. So there is also an integrated online payment of lab tests for arrivals so that when you reach the airport you can pay easily using online payment methods. So these are the different features in the system and these system features are designed considering the fiscal reality on the field. Where the system has the clinical exam and the diagnosis module, lab request module, sample request, sample processing, lab results, lab confirmed cases, lab COVID-19 tests and rapid tests, hospitalization and health outcome. So this system has considered all process occurred on the field. So these are some of the photos on the fields which are considered as output and the results developed while we wanted to end up the problem related to the paper based systems. So here are three sample corrections. Here are RBC and MOH staff who are collecting samples on the field. These are the clinicians and these are the clients. And this is how the sample, the workstations is where activities are to receive samples from the clients checking the lab codes. So here this system is generating automatically the lab codes which are here a unique, special unique ID. Then confirm that sample are of good quality, no rejections. So here in the system there is a modular for sample exception. This is also how sample are processed and after processing the sample in the laboratory, they have also to fill sample processing information in the system. This is how unique ID generated by the system is put on the lab sample correction space tool so that they will be able to identify clients without any confusion. And this is how the team in charge of entering the results in the system are working. And after entering the results in the system, a client will receive, is receiving the SMS and this SMS will lead them to download to the link where they are able to download the certificate of their test. And you can see that they are allowed to put their phone number and unique ID so that they can download their test results. And this is the test results and you can see here that there is an option QR code so that this QR code has to be verified to see through the information. I'll see that one in the system. You see that here there is a scan, the way to scan a certificate for travelers at the airport. And then this is the dashboard to monitor the testing figures. So these are the sum of system implementation and achievements. And to achieve all these, the government has put in place the National J-Task Force, which includes also the test science unit. So they are package implemented country-wide and the capacity to try to conduct the capacity building both for the users and the leaders involved in the service system. The government distributed around 500 tablets and 200 smartphones across the country, facilitate data collection. We have had more than eight PCR lab testing sites integrated system and the paper-based system used before. And this SMS and email notification was really helped a lot to communicate with the entire population of the country. The integrated online payment of lab tests also for arrivals has facilitated time management in the airport, like the entry points. Certificate port also managed and helped the population to man their time by downloading themselves the certificate. And the Android app for scanning the travel certificate helped with the authentication of information in the airport. So general challenge of using this system for the side of users, each and every app that's required, we need to update the users and they had to reach each and every users. But we wanted to use online channels like social medias to inform all users at the same time. The high number of data entry credits during the mass testing was also a niche but we managed by using different public staffs to intervene during the data entry credits during the mass, during the data entry sessions during the mass testing. Then some challenges using Android apps basically were identified, like a budget for internet vendors, like an agent on application complication requires users data collection to be informed. And the Android app is mainly for capture data users can't have a quick dashboard for their work. All those these are the challenges identified and these are the lessons learned using the Android apps specifically. Actually, we have seen that the HS200 it simplifies the process and speed up the services. Then the offline use of Android app is very useful in many areas. And the speed and portability of those tablets, it was also an asset for us. And the lab specimen processing tracing agent samples, it was very easy and it was improved by using this Android app. Power battery or autonomy of 12 hours for those used tablets was very helpful for us. All those are the identified lessons learned during the implementation of this Android app or during the COVID-19 testing. I just want to share with you also the other instance of the HS2 vaccine registry where during the vaccination of this COVID, it was not easy to use the PIPA-based system. That's why in partnership with the Ministry of Health, we decided to develop the instance to be used. The steps here, it was for the deployment we started by configuring the metadata and we tested and upgraded the version. Then the rollout, then after it's approved, we prepared the site so that they can start using this instance. And after that, this is how it was on the field. At each and every site, you have one minute remaining, sorry. Yes, yes. So at each and every site, the workflow of vaccination, there's a client started by reaching the site and even the ESP1 that participated to help the users. You see that data entry team here, they send the client and they send the SMS to the client. After the client receives the SMS, he go for vaccination room. After being vaccinated in observation room for around 15 minutes and he receives the SMS and certificates by downloading himself or herself. These are the vaccination sites, how it is. Then this is after receiving the SMS, download the certificate. This is the certificate and the QR code for authenticating the data in the certificate. These are the teams participated to make all those happen. And the way forward, we are aiming to integrate both the two instances, the one for testing and the data for vaccination to put in one integrated system. Thank you very much. That was the presentation and I welcome your comments and your questions. Thank you very much. Thank you very much. Here's Rwanda for a very good and enlightening presentation, especially on these times of COVID pandemic, how you have digitalized your solution and to help in these difficult times. Now, as I said before, our time is a little bit limited and we, we, if you have any questions, please use Slack. I've started to see some questions from participants on the Slack. The facilitators will be responding to this question shortly. Now, let me invite Tiwong Amanda from his Malawi for his presentation. Thanks, Alfred. So good afternoon everyone. I trust you're able to see my screen. So I'll be talking about the National Agriculture Management Information System for Malawi, so abbreviated as SNAMIS. So essentially that's like the web landing page for the system. In terms of what I'm going to talk about, so just look at the background leading to the development of the system, system features, issues around implementation and challenges faced and how some were tackled and then future plans. So in Malawi, so this work was done under the Ministry of Agriculture. So with the Ministry of Agriculture, as frontline workers, you have now what are called extension workers. So extension workers work at community level. So like an household level to provide advice on agriculture or households and also collect different kinds of data at household level. So these processes are largely paper based. And also when you compare the level of digitalization within the Ministry of Agriculture and other government entities such as the Ministry of Health, the Ministry seems to be lagging behind in terms of digitalization. But in its planning, the Ministry of Agriculture has seen the enhancement of the monitoring systems as a key component to the drive for commercialization of agriculture. So under this then it was seen that there's need to develop a consolidated digital management information system that provides a platform for all work processes under the Ministry. I think before we also had sort of like standalone small systems, some of which have been discontinued. So under this current vision for the development of an integrated system, the Ministry wants a configurable system that can expand beyond single use cases. And also the other key thing here was to have data entry and use at the lowest point of service delivery. So because the Ministry was looking for a tool that people could use as they go about delivering their work. So truck rendered itself better than the aggregate component. So when you look at, for example, the first use case for implementation within the Ministry of Health was the aggregate use case. But because of the target audience for the Ministry of Agriculture, so the focus was on trucker. And just as a guide, so as of now we have like a total of over 23,000 reporting system, I mean reporting units within the system. So like offices, service areas. So service areas are demarcations in terms of where these extension workers provide their services. So at the lowest level you have what are called blocks and blocks are organized into sections and extension planning areas and then districts and so on and so forth. So we also have markets so for the collection of agricultural statistics such as market information on commodities. And then also weather stations for the reporting of weather and climate data. And then the landing sites and sorghum for fishers and so on and so forth. So with this work, it's been organized in phases. So there've been two phases of development so far starting from 2018. So focusing on that first was called the agricultural market information system. So the agricultural market information system mainly focuses on monitoring market information for agricultural products. So they have five service forms for that I think you see that in a short while. And then there's also what's called the agricultural production estimates survey. So each year the country performs agricultural production estimates so on crops, fisheries, and livestock dynamics. So this is just to forecast what's the outlook in terms of food security is going to be. So this is done in several rounds. And then from there the national project whether it's going to be food sufficient or the some interventions that are necessary. And then we also have service areas for animal health so daily monitoring of animal health and outbreaks. And then there's also a form for rapid food situation assessment at a household level just to see whether the household is okay or they will need some emergency food intervention. And then the other component is on fisheries. So covering all areas on fisheries management. And then there's also weather data reporting. So because as you know, agriculture is weather and climate sensitive so that's essential. And also in terms of the work that's been performed, there's been a development of your portal. So accessibility of the collected data was deemed critical so hence prioritization of the world. And besides the requested for system features and survey forms. We've also in the process I think come up with various custom apps to improve on the development processes. So, for example, with that greater production estimate several one key thing is to do households and block sampling for the purposes of running this survey. So for that we developed an app that does that automatically. And then for various purposes of user account management. So for example, we have some user groups or management of user password and so on and so forth. We also develop some custom app to expedite some processes. And one key thing is that in the development of the various tools that I've talked about. We were implementing a survey protocols or service delivery protocols. So to do that. That meant that we needed to configure for example, program skip logic to guide the behavior of the app based on user input. And within tracker to do that you have to use program rules. And for the program rule expressions you have to create a program of rule variables which are maps to the tracker data elements. So this can be quite cumbersome because within the system generally do one variable at a time. So what we did was to develop an app for mass creation of program rule variables. So you can create for example the program variables for a particular server form with a single click for example. And then another process is that also when you're organizing the forms you have to organize let's say sections into themes. And that can also be quite cumbersome. So we developed an app for that so that again many sort of processes in a single screen. And also to help some supervisors to preview collected data so we did some small up for tracker data previewing. And then there was also some up for the processing Excel files in terms of managing the input of historical data. And one challenge that was also first was that in the development and testing of things we generated a lot of test data which they were cleaning up after. So the manual deletion of this data was proving to be time consuming so there was also some small up developed in terms of data cleanup. Alright so in terms of what's been implemented in the system I think also one thing is besides the key modules. This software has developed I mean has helped in terms of consolidating key data like for all the reporting units because in some cases the ministry didn't have data for all the reporting units in one place. But with the development of the system now the data on reporting units is in one place so for the over 23,000 units that I talked about. And now also then the development and roll out of the gradual market information system in 12 districts and also done. The implementation of historical data and for this farming season, some districts have started implementation of the agricultural production estimate service so that season started last month. So still getting us some feedback from the field. And there's also the portal which I'll show you in a short while. So there's been a numerous technical and end user training sessions so mainly to develop technical capacity on the choice to and ready processes within the means of agriculture. Because this is the first wide implementation of the choice to. Okay. So, right so. The system development and integration guide is meant to guide the ministry in terms of considering new efforts for systems development. So then, next we have just a series of some screenshots for the system so as I said you have a landing portal for the system so this is the landing page. So what's here one can access the library so the library is meant to house all the key documents within the ministry such as policies and reports. And that's a link for Namis then gets them to the main system. So for the statistics and analytics those lead to a dashboard for key statistics and also a page where people can do their own analytics within the system and then you have a page for news and also a directory for key. So here's a sample screen for the for the portal. So essentially what this displays is that it displays some configured dashboards within the system that have been shared for the public to get access to the data. And for the tools developed. So as I said you have the greater market information system tools. So what you can do an agricultural input market service or looking at the prices of agricultural inputs. You also have the food crops and meat products with the market service or for all these Amis service. And you might as go to markets to get that sort of information, then there's also a household register so for getting households dynamics so to your right you have those two screens on like what sort of data is collected for a household. And then we also have various forms for monitoring livestock dynamics so everything about livestock that's a household make it. So these are just expansions of what's been collected for the livestock forms as a sample some functionality provided by the system. Like this form a one and six collect everything that's the household won't possibly keep and then let's say based on what sort of livestock the household keeps, then you can get to specific forms like that one got population and dynamics to get further details on that all fits on cattle or whatever the animals as you can see on the extreme left, you can then go ahead and collect the sort of data. So I think for developing the system functionality. One key thing was to leverage existing systems, I think like the tracker and the Android capture, because that saved a lot of development time, but it also leveraged a lot of other custom apps like the extended user management up from the, the DHS to up store. So for the implementation the implementation of the modules is being done in a first manner, because this is a time to write system but and everything can be implemented at once. So as I said we first implemented the graduate market information system components and then with this rainy season, we implementing the agricultural production estimate surveys. And this is also been done in a first manner across districts so like that's a graduate market information system was implemented in 12 districts and then it will be gradually scaled to other districts. So in terms of challenges, I think some key things were to the level of the DHS to technical capacity of this being the first system within the use of agriculture, but what has been done is we've had several workshops in terms of developing technical capacity for IT staff as well as developing a capacity for end users. And also this being a national system one key thing is trying to align funding cycles to make sure that system is scaled to all the districts in country. And also in a context where you have multiple implementation partners as donors funding initiatives. There's also the challenge of trying to align prior efforts that may be doing the same thing but the good thing is that also agriculture thing for digitalization is in the early stages. That's in a way the manager at this stage. So another challenge has been backfixing timelines within the main DHS to component versus local terms sensitivity. So, and it's sample is that the release of the new vision, I think like the form names were not displaying so we're about to roll out an implementation. So that's in a way delayed our rollout but at least we were able to link up with the global team and that was eventually resolved. And then the DHS 200 capture our performance can be an issue at times so things are heavy as was the case with his began the app does crash at times and also in some cases it forces you to choose in terms of the usability of things where you can like as to how many rules program rules you should have to make the app dynamic or which is likely to affect performance or what you should leave out which may in turn affect usability. And then another thing that we've noticed is that terminology of the DHS 200 capture in as much as it's meant to be generic but leans a bit more towards the health domain so I think we've engaged with the global team on that as well to change some things in due course. And another key challenge has been the quality of available documentation, especially on tracker and program indicators so you tend to spend a lot of time trying to figure things out. So I think that's an area for possible collaboration and improvement of things. And in terms of future plans and ongoing efforts so we working on continuing to roll out an expansion of the modules that have been developed, and also to further developed technical capacity, and to mobilize funding for further development, as well as to strengthen system development, governance structure so that we don't have duplication of efforts, and then also to facilitate linkage across ministries because the expertise across ministries and so lessons can be also learned from what other ministries have done and the ministries can also collaborate on something so for example, in health, the frontline workers collected on households in agriculture the frontline workers also collecting data on households and this is pretty much very similar data so there could be some cheap or real improvement operations. So Zicoment, thank you for your attention. Thank you to Onger for the nice presentation. Participant as usual please post your questions on the Slack the channel is questions. You can just post there and then you can tag also a particular facilitator who you want to who you're aiming your question to. Now the next presenter will be Wesley from his Kenya. He'll be presenting various case. Wesley, welcome. I hope I can be able to look at sharing a screen and it can be able to see. So my name is Wesley and I'll be able to make a presentation on how we're using the trucker in Kenya to do a rapid mortality survey for purposes of reporting the excess mortality that we've been able to see especially with the advent of COVID. Let me hope everyone can hear me and the screen is visible. So, just a little background of information is that in Kenya the Department of Civil Registration is mandated with the task of registering all the bats and deaths that apply in Kenya, as per according to all of our laws act 149 of the decision is done on the basis of where the death has occurred such that the death that occurs at health facility is able to be captured and reported within the health facility and that that happens within the community someone was there at home. The data that would be able to be reported in a different system which is basically living on the provincial administration. As it is at the moment in Kenya, it's important to note that we are experiencing a very, so we're experiencing we're experiencing a very low reporting rate of death. That is the reporting of all deaths as for now, our coverage in 2018 was only 42%. We went down in 2019 to 38 and in 2020, we went way below, which is at 37.1. So this significant variation in county specific coverage is is also something to note that Nairobi, which is our capital city, as one of the highest reporting rates, whereas the other counties like Sierra and Cajedo are very, very, very low. Important to note that as we look at this, the reporting of deaths is one of the key things that is envisioned in the SDG targets for which the SDG expects us to at least to be able to register at least 80% of deaths occurring within our country. And clearly, as a country, we are very far from this. And that is why we had to mandate or to develop a tool that would be able to be used by health workers in health facility so that at least we could transition ourselves to 100% reporting for facility deaths as we keep working on the challenges of what happens at community death. So the rationale of why this particular thing was is that we need to inform decision makers about the full magnitude of the health consequences of COVID-19. I think most of you are aware of the COVID-19 and the number of deaths that have been appearing. So we need to tell the policymakers, for example, for the people coming to the hospital, are we seeing excess deaths? And this is by done by ensuring, first of all, we're able to capture all the deaths that are happening. And once we transition into the system, we'll be able to compare with the retrospective data for the deaths that were occurring before COVID and be able to determine or a certain are we experiencing any excess deaths at this particular moment. So it enables the capturing of mortality data in real-time manner, which is mainly daily to enable monitoring of population trends and inform public health measures. And it help us as a system as well to build capacity in the civil registration system. And the effort is to ensure maximum benefit of routine data system to policy. Our broad objective when we were rolling this particular app within the KHS truck instance is to do was to rapidly generate timely quality data during the COVID-19 pandemic with the aim of strengthening death and cause of death notification and registration in Kenya. I think most of you will be aware that by the time the blue show had released the ICD-11 code for COVID, most of the COVID deaths have already been reported and largely or by mistake or by default a good number of them had been allowed to come in. And be reported as just deaths due to pneumonia or any of those particular areas. So other objectives for this particular area is that we needed to streamline timely reporting of mortality notification from health facility level to improve our coverage of completeness of death and cause of death as I'll be able to show you through the forms that we have developed within the system. We do realize that a number of deaths will be able to be reported but because of death, the sequencing of the death was an issue and we needed to develop something that could be able to capture this very, very fast as we move ahead. We also needed to determine the excess mortality as I said earlier and actually showcase synergy and integration of existing mortality surveillance because as I've clearly stated, working in the Ministry of Health, our common date is not the registration of deaths and birth and death but you will agree with me that by unfortunately it means those two events largely occur in the health facility depending on the health seeking behavior of our population. So this being a pilot thing as a surveillance, we need to select a number of counties within Kenya where we could quickly go in and be able to deliver this particular deployment of the KHS to be able to report. So we had a number of factors we had to consider before we could pick up on our facility. We looked at COVID-19 high burden, that is to mean that for example, for this pilot which we've been able to roll out, we looked at counties which are having a high COVID burden based on the PCR reports we were collecting on the country. We also captured data on the counties that were on border counties and I think our neighbors Kenya, our neighbors to Kenya who are Tanzania and Uganda. Those who are the main interest for us because the other ones of the northern frontiers were not kin. So Kenya, Uganda and Tanzania being our immediate neighbor. Those are the areas we're looking at so that we'll be able to pick you in case there's any excess there because different countries had employed different trustees towards working towards COVID. I think that covers the port of entry. Low mortality reporting we also looked at those counties that were really reporting very low levels. So we could deploy this particular thing in the health facility and see how well or how well the health facilities will be able to change their kind of reporting and we'll be able to get more data about the deaths that are happening in those particular areas. We also looked at regional representation. Remember, our country is a little bit big. So we wanted to get a test of the different regions that we have. And most importantly, we also picked counties that have a functional community unit. I don't know if you're aware, but in Kenya we are running a health community based health provision whereby the community is the first point of contact for health services before someone is referred to a primary level of care and then they either escalated up depending on what is the condition they've had. And lastly, the country is piloting something called universal health care. So those counties were picked in those manner to ensure that they be able to get them. If you're familiar with Kenya probably later you can be able to look at these counties and the areas we picked was Nairobi because of the COVID-19 button, but in point of entry, Mombasa for the same same reason. This year, it's a border county and it's a point of entry, Kajiyado, Machakos, which was to give a regional representation and it's a very good established community units and the USA county. And lastly, Sierra, which is a regional representation and also a border county because it does border the Lake Victoria on the other side, which also touches on Uganda. We should probably go to the first instance and be able to show you what is it that we deployed in the system. So the deployment of the app in the system is that we develop an app, and it's important to know that as WHO has made it a recommendation for health, that by the end of by 2022, we should start reporting mobility using the ICD-11. This platform gave us a very, very good avenue to be able to roll out the ICD-11 and be able to see how our facilities and those within our areas will be able to do our reporting and engage with those data reporting. So once you land on our site, this is where you'll be able to go. And the next thing is that the trucker instance that we've been using, I think it was a viewer familiar with the event-based reporting, which is a program within the KDHIS-2 module. It runs on that and once someone has been able to log in, this is what they'll be able to see. On the left, they'll be able to pick the landing page, which would clearly give you a site. It's important for me to mention that our reporting units for this particular was held facility. So we have the Kenyan hierarchy, which arranges our facility according to our administrative units, where we have Kenya. And within Kenya, we have something called counties. And within the counties, we have sub-counties. And within sub-counties, we have what I think the next slide will be able to give you what I'm talking about. In Kenya, we have Kenya. A good example is that Baringo County. And within Baringo County, we would have something called a sub-county, which is Baringo Central sub-county. And then within the sub-county, we would have a chair known as WOD. And within the WOD is where the facilities are laid. So a good example of what you're all seeing on the screen is that this is a classical case of somebody working in Baringo County referral. What they'll be able to get in. Important to remind those who are familiar with these use cases that depending on the user role, we'll be able to limit you to only the particular area which you're working. So that, for example, if you're working in Baringo County referral, when you land on this page, you'll only be able to enter data for Baringo. And that is something that we find very positive because the user role helps you ensure that data quality is adhered very well at data collection point. This is probably how it looks at. And the important thing, I think, as you can see the screen, is you'll be able to look at the add event. And once you click the add event to be able to take you through the system and give you how you'll be able to report a particular death. So this is how immediately an event was captured. We as a system have ensured to reduce data errors. You can see the first row on the system to be able to quickly pick all your events. That is your basic events details that is, for example, this is an event being reported on the 11th, 10th, 11th, 10th of November. And it's from Baringo County, the Baringo sub county and the Baringo County referral hospital. This area auto populates. So there is no need for someone to be able to enter them. Then this again, the various things for those who work in data, but ensure that data being collected, at least quality aspects are being considered very prior to it. So on the first part, this is mainly the picking of the demographic. So the things that we're able to keep pick what the data notification. Let us remember. Finally, I did not mention that when a death occurs in Kenya, there is a form known as a debt, D1, a debt notification form, and one is filled up. Part of that data is what will be able to be transferred here. But not only that what is in the form, but also what exists within the patient file to be able to inform the part of course of death. This would basically be the screen where we were able to pick our demographic data, the county, the sub county, the usual residents and all the sex and everything that go with it. Yes or no, I cannot. If you realize in the area rich in sex in Kenya we've had a lot of activism and to now health is being required to collect our data both for male female and the unisex thing that's a good one you can pick from us. Then the next thing to look at is we are collecting data of the medical data and a beautiful thing to notice is that the preceding courses of death, which would have been captured from the reports will be able to be captured in the section A and B. And if you are not able to select or pick one on the far right, all the details of that particular incidence, the system will not be able to save. So we required you to pick A to pick P to pick C, and if there's more than one antecedent course of death, all of which will be captured. And if you look at the area, state the underlying course of death, the system will automatically pick the last row, which has been filled up there, so that that will be able to be picked as the last course of death. And the system that means, for example, you could be able to pick what what is this thing causing our excess deaths within our health facility all around. The next thing we're looking at is other medical data. This is basically for those conditions. I think some of you are familiar how data appears occurs in the facility. So that are related to surgery, whether an autopsy was done, and the manner of death and lastly, it was a poisoning or not. And what is beautiful is that once the health facility record officer had been able to enter all this into the system, they'd be able to complete the form and the form will be able to be uploaded very quickly into the DHS2 platform, which is our KHS tracker. So what are some of the strategies we did in order to ensure that at least this thing will be able to be picked. Now, being that ICD-11 has not been rolled out in the country, we needed to do capacity billing for health records of some of the system, and we were able to train 220 and as shown clearly at the beginning, we're only working with six counties so far. So we train them very, very well. And this has been a very, very good for us because due to the interest in learning ICD-11, it has meant that most of them have been able to capture and report very effectively. Remembering again that deaths does happen on facility but on average, the large facilities would have maybe a 10 to 15 deaths happening in a day, but the minimum small low level facility level four, working at the district, they probably have two or three. And this made it easier for those other records to be able to quickly move in. Daily reporting was really emphasized and there's a tracking of who was reported on who has not been able to report. And lastly, I think some of you have been able to look work with the program. You'll realize we really worked on the graphic user interface so that whatever the health worker who's reporting was interacting on the screen, they'd be able to be very, very easy and simple to be able to enter. We realized that with the digitalization, especially of most of our records, most of the thing we've been doing is we've been making the forms more of the digital version and that hinders how well or how easy our health workers are able to interact with it. So there are achievements so far that we've had 100% reporting by all, all the six county health facility leaders. And it's important to mention, these are both the government, private and health and faith based facility. We've got a positive responses we might separate mortality reporting from mobility. Kenya has more than one use case of the trucker instance or the program instance. So one of the few things we did with this is we were able to separate reporting of mortality, separate from the reporting of mobility. We did realize that when you combine them, mortality and mobility whereby what differentiates them is mode of discharge whether it's death or alive. It was really becoming cumbersome for health workers to report deaths because someone looks at the forms and realizes there's so many, and maybe there are only three deaths there, and deaths is what was of our interest. Other counties are now asking us to be included in the next phase. And we've actually did most importantly is that the fact that we were able to deploy the ICD 11 within the system and it's what I need to mention is that it's, it is intelligent in that it reduces the need for the clinician or whoever is entering data to know that this is, those of you who've worked with ICD 11 I think you'll agree with me. I just need to type malaria and it will give me all the forms of malaria are available, and it will be able to tell me which one I am looking for and quickly pick it up. Now, our challenges as we've been deploying this particular system is internet connectivity, I think Kenya remains one of those countries where internet limitation is very, very good. Again, the connectivity cost has been quite of our major entrances, but we've asked the health facility to support it. A big gap that exists within the KHS program is the ability to analyze the data, because now we need to transfer the data either downloaded via Excel or CCSV and move it to Anacode or Mamacode so that, for example, if someone was to ask me what has been the top 10 cost of death for this particular facility, we need to take it to another platform to analyze it. So it's a gap that exists within the DHS2 platform, and maybe I believe as we keep working on it and improving on it, we'll find a way to make analysis very, very easy. Now, the capacity of coders and certifiers to use as C11 remains a challenge. I think some of you I don't know any other country where they've been able to do it very well, but you'll be able to realize that 90% of 60% of people will be able to reporting in the data certificate that cost of death is cardiopulmonary arrest, and it stops there. Whereas the other subsequent or antecedent courses that made the patient appear in the health facility, the cardiovascular thing that has been written there makes sense remains a challenge. So those have been our major challenges. And what is our way step? So the next steps as we move, we're really looking at piloting in six additional counties so that we can go in our sample size and we can be able to say whether in Kenya we really had excess deaths. We're also looking at monitoring the rapid mortality cell pilot process and data quality assurance so that whatever data we are able to share, we can be able to tell the population what was the quality, was it good or bad. Data analysis and computation I think that is something we're doing at the moment so that we can be able to say, have we experienced excess deaths because of COVID, or have the deaths just remain within the normal thresholds. Documentation lessons learned and experienced, second data analysis of historical data to calculate with prospective reporting of RMS. That's the disseminating these findings to our leadership so that they are able to involve an informed policy and say called us at all levels. The Kenya health is devolved function so in anything that we do from the national level, we need to be able to cascade it down to the county level so that they are able to understand what is it exactly you are doing. Lastly, we have been able to scale up RMS to all the 47 counties and make the mortality reporting of death to be a very, very thing that is part of our routine data. I believe I will stop there. I hope I was not very fast, but believe my last slide will be a thank you and questions sorry. Thank you very much. Thank you very much Wesley for your nice presentation from his Kenya. I just want to reiterate to the participant that if you have any question to the facilitator or some of the content which the presenter have made please go to the question channel in the Slack and post your question there also tagged the facilitator. I will be shifting to presentation to from his Tanzania with Lee can you. I'm trying to get the bottom. I'm trying to get the bottom I know who else can help me. I think that should be fine. I hope everyone can see the the slide deck here with me today I have I have an M&E officer from the Ministry of Health. His name is Mr. Inkeligi. He's coming from the TV to will courses and leprosy national program. He'll be taking us through the presentation on how they've managed to implement a nationwide electronic TV register in Tanzania. Thank you very much. Good afternoon everyone. Yeah, here is a presentation from the national TV and the lepros program on the on the TV. And the leprosy electronic system. Which we call it to the. It tail. Yeah, that the and the program is a combined the two disease program. Established in 1977 to oversee the control of. TV and the leprosy. It is under the preventive. Services. In the section of the epidemiology, it is headed by the program manager, a senior medical officers. Yeah, the. Tanzania is a. Paul also the. And then you, you are trading standard in. Providing the. Be safe says. Previously. The program operated on the two system. And the electrodes. The one and the. The system. At the district and the highly. And the paper. Only at the facility. So there was the two evaluation or assessment. The epidemiology and the impact. And also the evaluation of the TV. Subvariant system. In 2013 and 2014. Which are. Only. The. The. The. ETR and the net system. Which was the only operation on that. That that system. And on. That year that I was also a. A new. The. The. Venetian and the. The porting. Which also necessitated the updating of. The coding and. The porting tools. Also, I think the. Coming of the entity. The strategy. Which demanded it for indebted analysis. That they are all. To. The. Program. To adapt to a case. There's the system. So that is where the. I also think that. It is. Developed. To. Platform. They initially. Consisting. Of. The. The T. B. The T. and the registers for resistant TB and also a register for culture and the DDSC results. So it provides a simple way to correct the case level data in a systematic manner. It has a level although some of the data are being entered at the DDSC level, but that's for a particular head. So from the system we are able to generate standardizing report, which a lot of us are nervous and also to use the private table and to export the case basically to the software for further analysis. So here is how the milestone was from 2006, where we started each year, the dotnet, which was a standard alone, to print a query when we adopted the current system, the case-based system in the HS2 platform. So during the implementation, we conducted a pilot in Sierra Leone region, totaling of the 22 districts, which included the Diwani, MDR, TB treatment center, that period. So we put in the district and the legion of TB and the NEPA coordinators and also the legion of HIMRC for personal staff. So we did a joint supportive supervision with the program and the developers of the system, the University of Islam, or his Tanzania. And we assisted the data entry, so totally with this connection, but we hope we can continue. So here is the data entry with Sikrin, which is the data entry for the high level and the stages. So the demographic information, they are both on the profile and the other information, which cannot be captured at once. They are put at the stages like the HIV, the treatment, and the laboratory testing results. Okay, here is some of the dashboard, which can be generative from the system. And also here is a sample of the standard report, which is your data customary so the user can generate data automatically and include the some of the most frequent needed to be in the caters. And the author that has the same recording for lipos. So what we left as we were not expecting that there was a high acceptance rate of the system by the users and the different levels at the district and at the sum of the few facilities which were able to do the data entry themselves. So the information on interoperability among the TB registered data and the catch and the ST. So we needed also the patient transfer and the lipos to be in and also the specimen transport and the feedback. That's one of the information we are needed by the users and they are happy with that it will be obtained and captured in the system. Other with TICT infrastructure is culture for the system and the data availability at sub national level and the level for in-depth analysis of the TB cases and treatment. So the little time data monitoring and analysis was possible at all levels. Mentorship, after training it once helps and we were able to solve the problem after at the summit for the data entrant. And they also made the to improve the computer skills and the use capacity to the health care workers. So area of the improvement or the improvement that data extraction features. As we know most of the user to lower level they are not not to have a data computer skills. So we needed to have a simpler extraction features to enable them to use especially to generate the data report. Also to improve the data use or the information you use. Also we needed to capacity on the data review. But in the testing and analysis at all levels to enable or to follow multi for the data use at the lower level. Also we needed to involve the health care workers at the facility level to use the system. The ongoing planning which is some who have been implemented was also to scale up the use of the system at the health facility. We developed the offline model for the data entry which we have opted for the mobile system although we are in process of developing it. And also we developed the SOPs to enable or to as a simplified user for the users. And the other is to include the data quite assessment or assurance and the supportive or supervision checklist in the system, in the HS2 system. And also we are planning to develop a data monitoring and management guideline which can comprise much of the on the data and data analysis and the use for all levels. And now to a steady support of the utilization of the basic system at all levels. Call entry at the facility. We are still see facilities using the system that we are promoting for the facility which infrastructure, computer and electricity to do the data entry direct. Can the other country benefit? Yes. The test-based system can be implemented in the source-constrained factories. For what is made is the external to support the local expertise. Also to focus on the country context, e.g. who are to enter the data, how the ICT can assist in the poor ICT environment. And also the close mentorship and the support which is made to the initial roller to stage and also to go step-wise approach and running up this system. So that is what we did. We did to run out of the ethereal as Santé Nisana. Thank you very much, Ms. Santeligi for the presentation. So, after going through multiple presentation from Hispiganda, Hisp Kenyam, Hispruanda, Hisp Malawi, and now Hispnazonia, I think you have gained a taste of different use cases where they have used DHS to tracker to collect information and also use it. And our coming academy will be focusing more on the tracker use, how now you can use this information to inform either your program, your country, or more or less your data managers within your organization. So, for today, this will be the last presentation use case. We hope you have enjoyed it and I see there's a lot of questions which are participant who you have post. Our team of facilitators will be visiting the Slack channel named questions and they'll be kind of responding to all of your questions. And as the days progress, if you have more questions, please do not hesitate to post it there. Feel free. Tomorrow session will be starting at 2pm East African time. Please join up early. Tomorrow will tell our level best to start at 2pm East African time. Yes, I've seen a questionnaire that the presentation yes the presentation or presentation will be uploaded into the Moodle will be using a platform called Moodle to host all of our materials and resources, including the videos which we are recording in this particular platform. So, our coordinator will be sharing with you Academy, I would say Academy Welcome Guide, where it will have all the necessary information for you for this particular academy including the links or how you can enroll yourself in this Moodle platform and other platform which will be using. So, thank you very much for your attendance. Any participation and your questions as well. We hope we've learned a lot and I'll see you tomorrow 2pm East African time where we'll start our session tomorrow, which will talk more about the new features for the DHS to track. Thank you and good evening.