 So, and you will find the links to all the different threads in the description of the of the session. So you have the links and you can go there directly. So, just to get a little bit of a quick overview on the on the HIV front in the HIS. As you know, and also it was mentioned in the in the previous session, the general session. Since 2017, the University of Oslo team has been designed as a WHO collaborating center for innovation and implementation. And these are slides to the design and and the publication of a series of WHO approved metadata packages. On the HIV front, we have at the moment out and available for everyone to download the HIV standard configuration package, which also we call it call package because it's the aggregate package. And it has all the core information that a program might want to collect in order to follow it up. And it comes also with with some pretty fine dashboards on burden and different levels of analysis, depending on national district and facility levels. And the moment the core package is used and implemented in 2427 countries, and four countries are under development, and will probably be operational soon. So, kind of preview side of things, we are going to soon release also an HIV stock report, given the fact that the HIS is so widespread and information can be collected very easily a facility, a facility level. And the WHO has also come up with some double we recommended logistic indicators that can be collected directly from from the facility level. But this is coming soon. This is not quite out yet. And finally, we know that the the follow up of the cohorts and in general longitude, you know, programs is incredibly complex and a lot of countries and organizations have come up with different ways to collect this information included in the HIS too. So we are still working in with the WHO, of course, in case based surveillance tracker, of course to continue promoting good design practices as usual, but most importantly to support the new strategic guidance. This is of course just a working project in progress, but we might be open soon to pilot the tracker in some countries if they are interested so they can contact us and we can see what how we can progress. So for today's presentation. It has been structured a little bit in two parts. So the first two presentations are going to be about mostly how some simple yet strategic adaptations of the HIS two products can support the monitoring the follow up of HIV programs. The first presentation is going to be by Dr Kesha, who will give us like an overview of the linkage of HIV programs with the use of data for monitoring follow up with the recycling if we can call it like that, but the application of scorecards. Then we will move on to David Naspik, who will show us how we can apply similar designs to similar data, similar uses across programs and interventions. Then we got to move forward to data analysis and data collection, because as we mentioned HIV and in general any kind of longitudinal program is incredibly difficult at times. And Jenny Monza is going to show us some really interesting walk around to analyze normal what normally are incredibly complex indicators. And finally, we have Nanny, Nanny Lungo, who will show us how to optimize data collection because of course there is no analysis if there is no good collection of an HIV SRAH integrated program. So without further ado, I leave the floor to Dr Kesha. Thank you. Is it visible. Yes. Hello everyone. I'm Kesha Devwa, working as a strategic information specialist at National Center for AIDS and STD control in Nepal. And I'm pleased to present on behalf of my co-authors and my presentation topic is use of DHS to tracker for implementation of differentiated service delivery for HIV treatment in Nepal. I will talk a little bit about the concept of DSD approach and early warning indicators of HIV drug resistant. In addition, I will explain how we are monitoring early warning indicators of HIV drug resistance and so we call it EWI of HIV DR, using DSS to tracker and ensuring implementation of core principle of DSD for HIV treatment in Nepal. What is the DSD approach to raise different national global targets, differentiated approaches are needed to meet the diverse needs and expectations of all people living with HIV, and to enhance the effectiveness of HIV services. The DSD approach is prioritizing HIV program globally, that is moving away from a one size fits all model, DSD tailors HIV services to diverse group of people HIV, while maintaining the principles of public health approach, which is defined as a client center approach that simplifies and adapts HIV services across the cascade in a ways that both solve the needs of people HIV better, and most importantly reduce unnecessary burdens on the health system. So in layman terms DSD approach prioritize those clients or patients needing more intensive services than those clinically stable clients who do not require frequent visits to health centers due to good retention in care, etc. So for implementing DSD for HIV treatment is not easy, because of the following challenges, such as low number of over modern health workers and limited resources in many low and middle income countries, which is also further fueled by using paper based registers, which impede the prioritizations of clients patient for delivery of health services, as per their need and expectations. This is even more challenging for HIV program, when we need to monitor treatment outcomes of patients for their whole life using paper based register. So to address these challenges of paper based registers and ensure the implementation of core principle of DSD for HIV treatment. We have rolled out DSS to tracker in 2017 in all a service treatment centers of Nepal. So we decided to monitor early warning indicators of HIV DR, because in limited resource health system like Nepal, the emergence of drug resistant is a potential public health threat and undermining long term effectiveness of first line and care provider residents. So these EWI indicators are helping us to monitor and minimize the emergence of preventable HIV drug resistance and maintaining the effectiveness of these therapy treatments. So our primary aim for this whole system is that sites can easily identify those patients or clients who are at risk of drug resistance, emergence of drug resistance and prioritize services as per their need. So to develop our EWI to monitor EWI of HIV drug resistance, we have selected these five indicators, and we have provided targets to HIV treatment centers we call it AR centers for each indicator. For indicator on time we'll pick up the target set was more than 90%, which means if there are 100% enrolled in treatment then more than 90% patients should pick their pill on time. If it's below the target that means the patient at the sites are at risk of emergence of HIV drug resistance. Similarly, the target was more than 85% for retention and care. Similarly, 85%, more than 85% for real suppression, viral load suppression, and 100% of ARD sites should ensure no ARB stock outs. So, I have like provided between slide number seven and 17 the detailed definitions, how we calculated numerator and denominator for each indicator for early warning indicators. But due to limited time for presentations, I will not go through in detail but it can be useful for others if they want to use it in their countries to monitor EWI of HIV drug resistance. So this is the definition numerator denominator and target for on time pill pickup. And then similarly this is for retention and care. It is just for the reference. And what is the target. And similarly, and the indicator number three is dispensing practices. So this is like developing indicator for this indicator is very tricky because it covers so many factors. But what we did is we are provided all the available ARB combination list in the DSS to cracker. If site select other resume than from the list, then we consider it as target not met. And we contact sites immediately for not prescribing standard recommended combination therapy to LHIV. So this is the target for this one. And for viral logical suppression. We have like target divided as per their age, if there is any client or patient is less than cost of two years, then for good performance is this target is 70%. If the client is more than two years old or all adults, then the target is more than 85%. So similarly, we also define the no ARB drug stock outside the sites. So now I'm going to present about how it works at the sites. So it is a treatment centers. There are patients who are enrolled in treatment for different time periods, for example, some are recently enrolled, while others are on treatment for more than five years. So we want to see their EWI indicators differently than lumping all patients together. For this purpose, we have divided PLS IV into seven groups as a group a means note like on treatment for less than a year, whereas group Z means on a cyber treatment for at least six years. So how we calculate it is we take two time period one is data we are initiation. Another is data EWI analysis based on this period, we define all PLS IV into seven groups. So at the site how they record the data. This is one example of viral load separation. Each patient's status recorded in tracker during follow up visit of PLS IV. And all the required like date or variables such as viral load sample collection date of reporting viral load and viral load separation status what was the value. So for the sites record each patient details into tracker. And in addition to this viral load separation they follow the similar procedures for other indicators like retention on time will pick up and dispensing practices. But for indicator five that is for ARB stock out. So for to record the information related to it we have created data set into form in tracker. The sites can record like whether they have experienced any stock out in particular month or not. If yes then they select the resume for how many number of days they experienced this stock out. So this is the way the sites record the information related to these indicators. So based on this recording. Again, the HIV treatment centers or the health workers at the different level, a monitor, the different indicators related to EWI of HIV drug resistance. This is one example, like we like the incorporated scorecard in our tracker information system with the help of his India. So all the results of these five indicators are displayed in the people table scorecard. What the site or wealth of us working at different levels can source this scorecard. And we are we are also provided this link into their dashboard so that they can click on that link and access the scorecard directly. So this is one example how the national and province level monitor the one indicator retention in care sources at the federal level we can monitor the status of retention in care indicator by province province can also monitor their overall status can also monitor the site level and district level status. Similarly, what happens at the site is this site can also monitor indicator specific progress both aggregated data and also individual level data. Since it was not possible to go directly from aggregated data presented using a scorecard to individual level data. We also develop early warning indicators line least report from where they can also identify specific individuals. Who are performing well or poor for the figure you're showing is the example of how the sites identify the patients who are lost to follow. So now I'm going to present like how we are using this is just a tracker for evidence informed response to present prevent emergence of HIV drug resistance. For indicator one if like if patient is not performing well, then site can contact that PLS IV immediately or send reminder SMS to the client which is which is in built within our tracker information system, or they can coordinate with community care and peer navigator team to ensure client have access to medicines on time. Similarly approach is also used in retention and care. If some some PLS IV is doing well in retention, then that PLS IV is eligible for monthly month dispensing. So they do not have to travel every month just to pick up their pill. And for dispensing practices, the health workers working at the federal level and province level they can easily identify the sites with for dispensing practices. And after identifying that, then we can guide them to ensure and practice good dispensing practices these are the few examples how we are using it. For viral operations, the site can easily identify the PLS IV with unsurpassed viral load and refer them to the clinicians for further assessment or modifications in the treatment plan. For ARB stock out, it is also really important for the health workers working at the federal and the province level they can easily identify those as a treatment sites who frequently report stock outs or demand or request emergency requests. So it helps us to pinpoint those sites so that we can guide them for timely analysis for submissions of bi-monthly acquisition firm so that we can to avoid ARB stock out in future. So these are the some of the few examples how sites and federal, the health workers working at the different levels can use this for care for the informed response. So in overall, this is an example how we can use DSS to track out their feed required information and alert health workers specific areas which require attention and support overall optimization of patient care. The most important thing is that site can start analyzing data for improvement of services, rather than collecting and reporting to the higher authorities which is happens most of the time because they collect so many variables and they just use it for reporting purposes to the higher level only. The use of routine health facility data is very limited, which also they can analyze this and use the system to identify the need of different PLS IB so that they can plan and respond their responses as per their need, which we also help to ensure implementation of DSD approach. Since we also record each follow-up visit data PLS IB, then we are also using it like DSS to track our longitudinal data in research to improve our program and interventions. One of our research is ongoing to assist longitudinal changes and factors associated with retention and loss to follow-up, missing in testing, test and treat around people living with HIV in Nepal. And this is the end of my presentations. Here I have provided a link for our YouTube channel and if someone wants to contact us, then I have also provided email and I have also provided references link which defines more clearly what is DSD and EWI of SIV drug resistance. Thank you. Thank you so much. It's outstanding like it was a brilliant way to maintain and visualize the data and also maintain the analysis at site level. And as you said, sometimes the people just collect the data just for reporting not actually using it and analyzing it. Outstanding. So yes. Thank you. That's one. David, thank you so much. Thank you, Victoria. Hello everyone and good morning, afternoon and evening, wherever you might be. My name is David Nesbitt, and I am a technical business analyst with BAO systems, headquartered in Washington DC. But I am physically located in Bogota, Colombia. I work specifically on the DHS to instance of the US government's HIV epidemiological data collection system, known as datum. Datum is the primary HIV data collection system for the president's emergency plan for AIDS relief program, widely known as PEPFAR. The project I am highlighting here is about solutioning a cumbersome reporting process made even better by transforming a public metadata package for adverse events from immunizations into a VMMC adverse event reporting tool in our DHS to instance. I have the pleasure of working closely with my colleague, Muhammad Salifu, also with BAO whose expertise made all the development work possible. This first section will provide some definitions, context and background for our project. To start, let's answer what is VMMC and why is it part of PEPFAR. VMMC stands for Voluntary Medical Male Circumcision. PEPFAR funds VMMC programs as part of its prevention portfolio because studies have shown it reduces female to male transmission of HIV by 60%. It is also recommended by the WHO and UNAIDS that VMMC programming be implemented in countries with a high HIV prevalence. As such, partners involved in PEPFAR, excuse me, PEPFAR VMMC programming should identify and report any adverse events. The definition of a VMMC adverse event is any injury, harm or undesired outcome that occurred during or following the male circumcision procedure. This includes not only events related to any error in screening, performance or follow up of the procedure, but those in which no error may have occurred. These events are considered notifiable to PEPFAR if funded through their programming. An example use case of adverse event reporting can be taken from a decade ago between VMMC and tetanus. There had been an increase of VMMC adverse events where tetanus was cropping up after the procedures. It was determined that while the WHO had been recommending a tetanus vaccination series, as well as booster doses through adolescents and young adulthood, it turns out that they were predominantly provided for young women as part of maternal and neonatal tetanus elimination programs. As a result, low proportion of males had tetanus immunity, especially in the age group seeking circumcision and combined with several other factors like males delaying or not seeking medical attention and a low quality of supportive care that this unknown risk was discovered and a plan could be made. The good news is through adverse event reporting, investigation and surveillance, PEPFAR worked with implementing partners, ministries of health and WHO to support the implementation of tetanus mitigation strategies and push tetanus as part of the pre-screen for VMMC clients. However, despite PEPFAR's mature DHS2 implementation status and the great importance of adverse event reporting, PEPFAR's HIV prevention team continues to have a PDF, Excel and email based process, which you can see an example of on the slide here. So over time, as calls for data and reporting have become more complex, the current process has become even harder to track and manage, especially since it's separated from the rest of PEPFAR's data ecosystem. If we have some context and background to our problem, this next section will tell our transformation story for upgrading data collection reporting and analysis. At first we asked, what can we do? So we met with the PEPFAR HIV prevention team to determine that our DHS2 platform would be perfect since it's already the primary data collection tool. We then developed a rapid prototype using the BAO systems import foundry to convert their PDF form into a DHS2 event capture app form. And as a side note, if you are not familiar with the import foundry, it's a free DHS2 metadata creation app tool available on the BAO systems website. Really great, really handy. So then we presented our rapid prototype in a demo to PEPFAR leadership where it was decided to continue upgrading the adverse event reporting process. However, with the added challenge of only using native DHS2 functionality, meaning little to no customization for this reporting process. Right at the same time, and much to my delight, DHS2 and the WHO released a public standard metadata package for adverse events following immunization reporting. This metadata package gave us the perfect foundation for sticking to native DHS2 functionality while still allowing for some customizations we could use to enhance this new process. This basically let us avoid developing a customized from scratch tracker program that would have required a costly and time consuming requirements discovery and development phase. All our team had to do is convert our capture app prototype into a tracker program using the AFI program tracker, which I'm sure makes Mohammed Treacle since it's much easier said than done. The package program allows us to have longitudinal updates to the adverse events report as information is gathered, while also providing automated system generated emails to notify relevant teams as these investigations unfold. It still lets us utilize the same PEPFAR geographic hierarchy, as well as other data streams, and it's in the same system implementing partners are already accessing. Finally, data is stored directly in a relational database after being entered and can be queried using built in datum data visualization and dynamic dashboard functionality, which brings me to this example of our converted VMMC adverse event enrollment in the VMMC tracker. Users will, excuse me, users will register the adverse event starting with a date of the VMMC procedure or device placement. And as you've probably realized by now this is very sensitive data. So we restricted enrollment data to non identifiable unique IDs. So there they begin filling out each relevant event stage. However, and as I just mentioned, further data privacy concerns mean that our users won't be able to load an event stage without selecting a specific PEPFAR funding mechanism, which further restricts data access in our instance. Additionally, no personally identifiable information is collected in the program. I just want to mention that major improvements for transforming this process to trackers that we get to incorporate automated skip validation logic and program rules and warnings for things like PII. As for adverse event analysis, here you can see an example of dummy data from our test environment for things like a line listing report, a pie chart of circumcision devices, or bar graph of primary NE reported events by age. And here I put examples of dynamic dashboards with our dummy data, which are great because as many of you may know, dashboards can be privately shared. And analytic objects are updated in your real time as the data comes in, which is great for us and definitely great for our clients. In conclusion, leveraging a standard metadata package with a similar purpose was an effective way to rapidly adapt DHS to metadata to enable a practical implementation, ultimately saving us time and resources. Given the speed and success of our development, PEPFAR is considering applying the same rapid prototyping model for other reportable adverse events, such as for cervical pre cancerous lesion treatment. We're going to upgrade our instance to 2.36 but anticipate our new VMMC NAE reporting program will go live in just a few weeks, roughly mid July. If you have any questions feel free to reach out and ask them on the DHS to community of practice for this topic from immunization to circumcision adverse events. Thank you very much. Thank you so much, David. That was a great example of how the metadata package approach is is working in a way that then I would like to give floor to Jenny. Jenny was going to present us about her, their way to collect and analyze very complex indicators. Those are yours. Thank you, Victoria. Can you confirm that you can see my slides. Indeed I do. Super thank you. Hello everyone. Today I will be speaking about the development of a harmonized OVC MIS for use by USAID Zimbabwe using the DHS to tracker. Just to cross that out, I would like to introduce you to my co-authors for this presentation. Sarah Minor of USAID Zimbabwe collaborates closely with us on the development of this instance, and Mohammed Saudi. about DataFi. We're a global HIV AIDS project funded by USAID for five years working to accelerate the end of the HIV epidemic by improving processes across the data value chain. So in this year, we are supporting 14 countries and among them Zimbabwe. And in Zimbabwe, we are working to develop a harmonized case management information system to collect information on orphans and vulnerable children across six different implementing partners. So DataFi led by Palladium, along with resource partner BAO Systems, has supported the development of this instance with the intention of streamlining reporting for both Zimbabwe specific indicators and also for reporting to PEPFAR. So we are currently in the final stages of development with legacy data migration ongoing presently and roll out plan for August this year. So why develop a harmonized MIS? With over 250,000 beneficiaries being served by a number of different IEPs who in turn then work with and engage community-based organizations, each implementing partner had a different information management system which led to certain limitations. There was certainly the possibility that slightly different definitions of services being provided and variations in calculations contributed to diminished data reliability. Additionally, data was submitted on a monthly basis via an Excel tracker to USAID to support their decision-making which represents a delay between service delivery and reporting. And then additionally the costs of maintaining separate systems each with their own administrators. So in terms of the system that we were asked to build, this system was intended to calculate PEPFAR indicators primarily on the continuity of comprehensive case management. So longitudinal services being provided to orphans and vulnerable children potentially across many years. And another key indicator said being the documentation of HIV status of all those beneficiaries. So data is collected at war within districts and that data needs to be attributed to the community-based organizations. And of course these key indicators need to be displayed by fine age and sex disaggregates for the six month reporting periods. In addition to these indicators we also provide data and collect data and visualize data specific to the Zimbabwean context. In terms of the implementation challenges we faced, we'll explore some of the challenges related to actual definition of active beneficiaries and then the inverse of that as well. How do we measure when beneficiaries have not received the requisite services to be considered active? Another aspect that was very interesting was accumulation of indicators with different time dimensions. And then finally the visualization of results for reporting to PEPFAR and also for internal performance monitoring. So beginning with the identification of active beneficiaries. PEPFAR MER 2.5 guidance defines active beneficiaries as those beneficiaries who have a current case management plan, have also received a household monitoring visit and have received a qualifying service appropriate for their age group. So here we can see a graph collecting information on all of our beneficiaries. And the first three bars represent those sub criteria with the last bar then representing those children who had achieved active status. So the active status can never be greater than the combination of any of the other criteria. So in addition these scripted indicators would then need to be further disaggregated by age group and then again cumulated. So here in this screenshot here we see examples of our HIV status indicators and what we can tell here is that HIV status is then collected and filtered according only to those individuals who have achieved this active status. So actually complex scripted indicators then applied to another set of indicators around HIV status. So moving on to look now at the inverse, how do we measure those children? How do we identify those children who did not receive the requisite services? And what we know is that historically programs have identified these children through self-report. So we relied on caseworkers who then were expected to proactively report those who were lost to follow-up or experiencing an interruption in case management. And as such many of these reports are not made and beneficiaries were neither active nor lost to follow-up. And so this challenge is an interesting one. And here we see a description of the scripted logic that was used to identify these inactive beneficiaries, essentially starting with all beneficiaries and then through a process subtracting different subcategories to ultimately leave us with those individuals who are considered inactive. And here we see a snapshot of some of the logs from the scripted action. It has been scheduled to run on the server once a day for TEIs updated in the previous two days. And for those of you familiar with this PEPFAR indicator, this indicator represents just one component of the larger indicator around exit without graduation. So again, accumulation of multiple sub indicators to produce the final indicator. So taking a look now at accumulating how we can accumulate indicators that have different time dimensions. So here we describe two different types of indicators, the first being point in time. So these indicators aim to capture the status of a beneficiary at the end of a reporting period. And so by definition, these children cannot be summed across reporting periods because they would be duplicate children. However, four beneficiaries to be reported at the semester needed to do precisely that is we needed to determine their status at quarter one and at quarter two to measure whether or not they had received continuous services. So an interesting configuration challenge. And then a more traditional indicator type would be a cumulative count where the beneficiary status can be summed across reporting periods and graduation would be a better example of that. So here we have the five top level indicators for OVC reporting to PEPFAR. And out of the five, we have two that are point in time and three that are cumulative. And so as I mentioned, these indicators again require complex scripting logic because they must evaluate the status inside each of the quarters that of which the semester is comprised and they cannot be summed across time periods. And the grand indicator of them all, perhaps the most complicated is, as I mentioned before, those who are deemed to be exit without graduation at the semester. So this is an interesting indicator in itself because it actually combines both point in time and cumulative indicators. And so we use a combination of offset periods and leveraging program indicators as well as mixed indicators in order to create this final indicator. And the last implementation challenge I'd like to address is how we might visualize or filter these longitudinal data from an aggregate perspective. So while we know that the tracker module brings to life longitudinal indicators, typically these indicators are best visualized according to the organizational hierarchy. So here we see an example where the data is broken out by province. And so that is a native function of DHIs2Tracker. However, it's not possible to display the same data either by age and sex to this aggregate or by implementing partner and CBO without additional scripting. So here we see just a screenshot, actually a very small screenshot of all of the scripted logic that was used to produce the visualizations and reports required, both for PEPFAR and for internal reporting. And what our technical team created was a tracker aggregate integration process. So I'd like to acknowledge again Mohamed Saleh who was the creative genius behind this. Each required indicator was created as an aggregate data element with a category combination. So the disaggregation for age and sex and then assigned to a data site using subpartner as attributes. So in order to pull data for one data element and all its COCs, we required a total of 768 program indicators and mapping indicators for each required indicator. A custom solution was used to pull data from the mapping indicators and then push into the aggregate data elements on a daily basis. And so we're using API calls in addition that were then created for quarterly and semesterly indicator groups. As I mentioned before, we needed for the other indicators. So this solution now allows us to be able to visualize data both by implementing partner and CBO and ultimately here you can see a table where the results are presented by CBO and by the fine age and sex disaggregates. So this represents a novelty because it's giving us this information not only by the organizational hierarchy but also by the implementing partners. And that allows us to produce these types of visuals to better manage programs. So in terms of reflections, the creation of a harmonized OVC MIS allows for standardization of indicators across implementing partners and of course the benefits of access to real-time data supports real-time course corrections. We anticipate long-term cost savings by maintaining and enhancing one national MIS via coordination mechanism. And of course, tracking of individual beneficiaries across time provides real insights into how to better meet the needs of the vulnerable populations. And in closing, of course, we just always need to take into account the complexities of how reporting requires expert configuration and extensive backend scripting. Thank you. Thank you so much, Jenny. I'm sure there are a lot of people will follow up with you because these are always very tricky. And running the same wave of cost saving and follow-up of programs, I leave the floor to Nene. Nene, I think you are on mute still. I can see your screen, but I cannot hear you. Is it just me? No, here, not here. It's been now, yeah, thanks. Thank you. I hope you are able to see my screen. Yes. Go ahead. Thank you. All right. Thank you so much. Good morning, good afternoon, and good evening, just depending on the different places that we are attending this meeting from. So I am Nene Lungu, the Senior Technical Advisor for the Maui Empower Activity. And I would also want to recognize the co-authors towards the submission, as well as the drafting of the abstract that we submitted to this Texas Two Annual Conference. And let me also recognize the presence of these co-authors who are within us on this group. And we have Linda Nyond, who is our SI Regional Director. And we also have Matthew Kancurungo, who is our data base, as well as HMIS Manager. And Dr. Ponfis Maked, who is the Chief of Party, as well as Yona Nyond, who is our Senior M&D Officer. And I will be presenting on optimizing the digital data collection using the DHS2 in addressing girls and young women programming. And this is the case of the Maui Empower Activity. So in terms of the flow of the presentation, first we are going to look at the background information. And then we're also going to look at the processes that we actually undertook to make sure that we have the DHS2 track in place. Then we're going to also un-eth the key findings. Then we'll actually conclude by sharing a conclusion, a statement. So in terms of the background, so Maui Empower is an acronym standing for Expanding Maui HIV and AIDS Prevention with Local Organization, working for an effective epidemic response. So this is a USAID five-year funded project, which began on the 5th of March 2020. And it's expected to phase out on the 4th of March 2025. So the overall goal of the project is to support governments of Maui commitment to epidemic control by stopping HIV transmission and preventing new infections among addressing girls and young women aged between 10 to 24-year-olds. And the activity is actually being implemented in the two districts of Maui. And these are the districts in the southern region of Maui, looking at the HIV prevalence in the two districts. And these are the dreams districts and they include Zumba as well as the Machinga district. The project is actually being implemented through two local implementing partners who include the Christian Health Association of Maui, commonly known as CHAM, as well as Packageri Institute for Development as well as Institute for Development and Communication. So next through the slide, we are actually seeing a snapshot in terms of the two implementing dreams districts targeting the addressing girls and young women. So the Maui Empower activity is actually a large scale multifaceted program that provides sexual as well as reproductive health services to more than 40,000 addressing girls and young women across the two districts of Machinga as well as Zumba districts. And the project actually used the data as tool to ensure the availability of high quality data. So in terms of the limitations that were there at inception of the project, one challenge that we actually experienced as a project was only the volume of the addressing girls and young women data that were supposed to collect as a project, like I mentioned, that we are actually tracking over 40,000 addressing girls and young women with the different SRH as well as HIV services. Therefore, this actually also initiated us to make sure that there is the real time data collection concept whereby data was being collected at different time points as well as at different places. However, considering that the project is located in the two districts of which some of the facilities are located in the rural areas of the two districts, we had actually also encountered the intermediate as well as limited the internet connectivity across the two facilities, the facilities that we're working with in the two districts. In the same vein, we also had the experience data entry cost, especially paying for data to actually be transported to be transformed from the paper based into the Tony management system as well as also costs in purchases for our computers to make sure that the data is actually keyed in and also that it can actually be used for rigorous data analysis. So now the question that we actually might be asking ourselves is, then what was the process? How did we do it as a Maori power activity? So the process began somewhere around in June 2020, whereby we developed a data set using the data is true tracker, which was actually running on the version 2.33.8. And this was actually capturing the original data for SRH as well as HIV services that are provided to the addressing girls and young women during the monthly community outreach and meetings that we are actually conducting as a project. And then the data is true tracker actually was able to correct individual level data and it runs both on the computer as well as on Android devices for offline data capture. So we actually purchased Android devices for our data entry team so that they can actually be using to actually capture data into the shared database. At the same time, we also made sure that we actually build the capacity of both the strategic information team members who include the M&D assistants and also not building only the SI team capacity, but we also made sure that all other program staff are also trained for how the tracker was actually performing. Similarly, we have actually also been able to develop standard operating procedures that can actually be used as the aid documents to make sure that they assist in the day-to-day learning as well as operationalizing for the day choice to tracker database. So currently the tracker is actually deployed to capture individual level data at about 40 community outreach sites and we are actually capturing data for over 40,000 addressing girls and young women on a monthly basis. In terms of the services that are actually captured within the tracker, we are actually collecting HIV testing data, STI screening data as well as family planning methods that are actually provided to the addressing girls and young women. And this is in addition to the sexual and reproductive heathy talks that are provided to the addressing girls and young women at outreach sites. Now, what has actually been the key findings or key successes that we have actually seen following the development of the tracker? One, we can actually summarize our key findings into three. One is only data merging. So using the tracker, we collected the data at multiple sites and the day choice to trackers actually allowed us for instant messaging, merging of long-term records, unlike other routine statistical softwares where the process was actually taking us more than a week to complete the merging process. So we have actually been able to save time in as far as the instant message, merging of the records is concerned. In addition to the instant merging, we have actually also seen improved data quality following the automated escape patterns that were embedded within the tracker. We have actually been able to make sure that our data is actually complete as well as make sure that it actually conforms to the other data quality dimensions, including that of data accuracy. Lastly, we have actually also been able to minimize costs because using the day choice to tracker, we have actually been able to save over $10,000 by purchasing tablets instead of computers as they were previously needed. And also the tracker has also enabled the project to develop analytical dashboards to track performance as well as adding and improving programming. So this snapshot just actually shows some of the dashboards that have actually been developed within the Morrowian Power DHS to track. Lastly, allow me to actually conclude by saying that through the use of the day choice to tracker and application for long-term data collection for the community outreach programs, we have actually been able to collect large data and these has actually helped us to make sure that we capture the data at different delivery points as well as the merging instant data to inform programming. And this has actually helped us as well to make sure that the concept of real-time data entry is actually achieved and also making sure that we have actually reduced cost and we can actually be able to scale up the activity. At this moment, let me stop there and thank you so much for your attention. Thank you so much Nani. That was a great overview of such a great implementation. This is it. Our time is up, unfortunately. I hope you enjoyed and you find some of the information that we brought to you today useful enough or at least as a starting point for some problems that you had as well. So if you want, you can continue the discussions and follow up with the presenters in the community practice and yes, the recording will be available soon. Thank you so much for today and I hope you enjoyed the remaining part of