 My name is Yuri Rogachev. I'm a DHS2 implementer consultant at the HISP UIO based in Norway, originally from Russia. I'm very happy to be here and I will share some insights and hopefully provide some background for discussion on the standard based toolkits. The topic of today's discussion is to review how these standard based toolkits can be used to support the implementations in such health programs as HIV, TB, malaria and others. I would like to from the start reformulate that because it's not only that the standards based toolkits can support the implementations, but the real implementations can support our work on toolkits and make it easier and more accessible and more adaptable for you. So that is the main idea of this. What we'll look at today, we will try to define what are the DHS2 standards based toolkits. I'll give you some examples. We'll talk about some implementation considerations and then we'll end up with the discussions where people from HISPs will be able to maybe reflect on that. So let's start. It's not a mistake. I was considering should I remove this or not. No, I won't. In every presentation that I've been talking about DHS2, somehow this way or another the topic of Lego was mentioned. Either in the context of the whole DHS2 is a Lego and then we provide the metadata packages or toolkits. This is the guidance or maybe that is Lego plastic bags. What you can see here is where we don't want to go, the Lego disaster. And I think that's a part of what we are working on. So let me give you my interpretation of the Lego metaphor here. So when I started as an implementer at the UIO, I thought, great, I have the Lego set for myself. I'll build a toolkit or package on TB surveillance with the guidance from the WHO. And then sometime later I saw that it was implemented in some countries. I said, what did you do with this? It doesn't look like what we've done. And this, well, we had to. I said, why? Well, there are many things. I guess you understand there's the legislation. There's different donors, implementation considerations that make you change. There's sets of indicators and whatnot. And that's when I realized that I knew my job maybe on 5%, 10% of what I had to do. But that improved me, helped me improve. And I think that that was my personal journey. And I think that we as a implementation team working with the different packages and toolkits, we are improving our strategies to make it easier for you. So let's define the implementation toolkit. It's a Lego set consisting of guidance documents. So the design guides, the guidance on how to use those toolkits, the implementation suggestions, and then also documents on Android optimization, and so on. Then it gives you a demo instance, a database that you can use to demonstrate a certain package to the donors, to the ministry, to the authorities. It has a metadata package. So we're talking about the JSON file with the configuration. And then it can have some integration tools and guidance on what to do with the package, training and capacity building materials, and sometimes custom apps. So all that makes an implementation toolkit. And we have together with our partners with WHO, with UNICEF, with other partners. And donors have been working on the implementation toolkits on HIV, malaria, tuberculosis, community health information systems, vaccination, immunization, maternity and mother and child health, COVID, then we have the non-communicable diseases, neglected tropical diseases, rehabilitation, and other areas. And this is only public health, then there's also the logistics, and then there's also the education, agriculture, climate, whatever. A more technical component of the metadata toolkit is the package, so the file that you import into the DHS to instance. This is one of the main components, but not the main ones. With the minimal requirements from our team, we have agreed that the minimum we can provide or the minimum that the toolkit may contain is the guidance, documentations, and some sort of demo. A metadata package is something that is already more materialized, that's something that you will have to work with to adapt it. And so I'll look into that and explain what that is. So a metadata package is a logical grouping of metadata objects that can be exported and imported into DHS to instances, and all of that is compiled into a JSON file. It contains a common metadata library, and that has been an achievement that came several years back, making sure that the installation of the import of the JSON files becomes easier and that you're reusing some metadata that makes it possible for you to keep your instances more harmonized. That you don't have two attributes for sex or two attributes for date of birth and so on, but you keep it all one. A metadata package can have dashboards with dependencies or indicators, legends, and the guidance, the instructions on how to map your existing metadata to that that we provide you with. It can, depending whether it's aggregate or tracker, it can have data sets with dependencies and it can have tracker one or several with dependencies included for you to analyze and to work with. And on the screenshot here, you can see our new downloads page that you can access from dhs2.org, where our toolkits and packages are organized by health area, and very soon we'll be adding educational domain there. So now let's look at the examples of these toolkits, and I will start from something that is more overarching and quite new, and we'll talk about the health facility profile. So a health facility profile is a toolkit that is meant to collect and analyze semi-permanent facility data in dhs2 for staffing, services, equipment, and infrastructure. So what kind of data does it have? It collects data about services provided, the basic staff numbers by cater, the bed availability, for example, equipment, and infrastructure, availability of services, internet computers, and so on and so forth. What's the source of the data? Where is it collected? It can be done through health facility assessments, health facility surveys, and facility self-reporting. Frequency can be done on a six-monthly basis annually or ad hoc as needed. It's a tracker data model, so the data entry can happen at any time, not necessarily based on a period, for example, in the event of a health emergency. And what's the purpose? It is to provide the policy makers and planners information on the availability and accessibility of various health care services. One of the reasons I took this as an example is also that this product is, it requires adaptation because you may be using dhs2 for certain areas and therefore you might want to include only certain services or certain equipment and so on. So you'll have to customize it, but the baseline, the skeleton is there, the dashboards are there, so it's the matter of having implementers that know what to do. And our role as the global team is to work with HISPs if they're present in the region, to work together with them on adaptation of these products, and also work directly with the countries in the regions where we don't have HISP representations and not only support them in this one direction, but as I said in the beginning, get the feedback on what is needed from our side to make these toolkits and packages more adaptable. Again, the health facility profile, as you can see, all the data that is collected there on the availability of services, staff, analysis of the preparedness of the services, the availability of key equipment, the infrastructure, all that can be analyzed separately, but it can also be used integrated into your HMIS system. When I looked at the configuration of the standard health facility profile, I saw various denominators for the basic HMIS system that can be taken out of a program like that. And this product, it's relatively new, it's already flexible and modular, so it's set up for local adaptation and then provides the analytics tools, so point three and four and guidance to how to adapt this package, this toolkit to your local demand. Another example, tuberculosis, so what does the tuberculosis toolkit have? The one that we provide guidance for and materials, so we have full HMIS module with WHO recommended indicators on case notification, outcomes, drug-resistant, TBHIV, comorbidities, TB prevention and laboratory and contact tracing. In addition to that, we have facility reporting of essential TB stock items to complement your logistics systems. We have a tracker for TB case surveillance and the linkage of case records with the lab results. We have a module on TB drug resistance survey, a program that has been taken about many times by many countries and even by me, even though I've been developing the global module, we've been working on and supporting the implementation of TB drug-resistance surveillance in Central Asia and we had to adopt it. We have a module on TB prevention on the contact tracing and the household contact tracing tracker, something that is coming up now in the end of the year. TB is a large, very broad program and it's very complex because an enrollment in a TB program can take up to two years, so one of the reasons I'm bringing up the example of TB here is that it's used in many countries and it's still a burden in many countries and there it requires many types of adaptations. Not only technical, but the package has to be translated, the materials have to be translated, the staff have to be trained. You have to, based on the current systems in place, you have to understand is there need for data analytics or standard analytics or do you need to start with some custom reporting forms to first comply with the requirements from the government and so on and so forth. So it is very difficult to come up with a global package, but we are trying and not only that, but we're constantly updating the toolkits that we work on, either well because we find more optimal ways to do that or because some requirements changed. In the example of TB, the new guidelines are underway and so we're working together with WHO currently on implementing those guidelines in the existing package so that you don't have to take it all apart or start from scratch. So that's again how this work is important and how important it is to take maybe a glance at the package before you design something new and I will just take you back to the beginning. I was shocked at first when I saw a real implementation in the country that looked completely different and the same I saw the people at WHO, the headquarters that helped us design those modules, they came back from country missions and said, but that's not the package we designed together, why this effort and it takes time to explain to the people to the stakeholders about the complexity of that process. So HIV, another big topic and also new guidelines that have been published this year including the new DAC, so the digital accelerated that and so what we have here is the HIV core HMIS module. So for the cascade analysis of newly diagnosed people with HIV, the RT retention, viral load suppression, we have the prevention indicators and integration of the STI indicators. At the same time, we have the stock items so the stock management for HIV, we have an HIV case surveillance module for longitudinal data collection and the person-centered monitoring and the new module that will be released in the summer 2023, this is the module on HIV prevention. And the way we are releasing modules now, sometimes we start with version 0.1 because we want to start the process of implementation of filing prior to the publication. And so if we together with our partners identify pilot regions, pilot countries before, we are very happy when it happens so that they start. And so the HIV prevention work, it has started in the PAHO region and we have three steps in publishing this module. So first was the PAHO version of the HIV prevention module. There was a subset of the package that was developed for one country in the region of Costa Rica. And then based on that and the experiences plus the new guidelines, the global HIV package will be available soon. And because we are learning and we are working on that process of making the steps easier, when the HIV prevention module was in the making, we have reviewed the HIV case surveillance to make sure that it complies with the same kind of principles and becomes easy for countries to have kickoff with the pilot with testing and so on. Immunization, here we have a variety of components within the toolkit. We have the API program, so the expanded program on immunization. We have triangulation dashboards where data comes from three packages. One is the EPI standard for HMIS, the integrated disease surveillance package, and the case-based tracker for vaccine-preventable diseases. So it can be implemented as is and you will have to search for the data elements in your HMIS systems. It can be taken when you implement all three of these packages. We have the electronic immunization registering, so for case-based data we have templates for real-time monitoring of vaccination campaigns. You see it's not specified, is it COVID or is it something else? Because we have seen that we could take the experience of the COVID vaccination campaigns that were held during the pandemic and translate that to the future campaigns and make it easier and and adaptable. Again, the module on the EPI logistics and then adverse events following immunization and some apps developed for the for the program that are also available for you to to utilize. Malaria, the HMIS module on service delivery, on data quality, facility reporting with surveillance for elimination settings with case notification investigation and classifications and then an array of entomology and vector control modules available. There are other toolkits that I will not go into details. You can visit our sites. You can also contact us at any time, contact me during this conference. I would be very happy to show you some of this work to guide you to the demos. But the examples worth mentioning here is rehabilitation, a quite new module also for the for the WHO. They have been developing the guidance for that and the indicators. So we have toolkits that contains 15 WHO indicators, six proposed data sets for data collection and seven dashboards. And what you see in the screenshot, I will share the presentation later. You can have a look at it. What's on the left, you can you can see the three indicators from WHO and in the right part you see the DHS two indicators that have been set up to report on those WHO indicators. So when we're making this module, we we had a clear understanding that the countries might take three or five indicators out of the 15 provided. So we had to make sure that the side that implements the package can actually take it apart and without really going through too many efforts. And now based on those indicators, we are working on the rehabilitation tracker, adding additional indicators to help the facility managers to plan their work. A lot of work is being done on NTDs. So we have burden data set and dashboards, plus the possibility of integrating that with the IDSR packages. We have been working on simple entity stocks, so neglected tropical diseases. And you see the human resources part. And then if I go back a few slides to the health facility profile, this is where that data could already come from and be mapped to. So sometimes it is very important for you and for us to look at the tool kits that we provide in an entity to see what could be combined one with the other. And the current work is being done on human rabies surveillance. And here we are also dealing with a, I don't know, unique or in that sense tracker that in one hand provides the, covers the indicators for surveillance, but on the other hand may be served as a decision-making tool in the country where it's implemented, if adapted in a certain way. And because we are working on the surveillance part, we provide guidelines on how that can be done because knowing from the countries and from the WHO, very often the cases of rabies, they're being treated or attended at the facility where you don't have the specialists who know much about rabies. So they will have then the decision-making or the suggestions coming from the program itself to help them guide them through the necessary steps. So that will also be available by the end of the year, but we are starting together with the donors and the partners work with the pilot regions. And I think here in Asia specifically to identify who would like to try start piloting. So to the summary, what are the DHS2 implementation toolkits that we have talked about? They aim to improve data quality analysis and use in national systems. They incorporate the collaboration process between UIO and WHO UNICEF and other organizations for the data analysis standards. They are modular and customizable and they're becoming more modular and customizable as we work more together with you. They're available for many core health programs and they're designed in an integrated way. The localization and the adaptation of these toolkits needs to be based on country assessment, context and national priorities. That's your part. And they, of course, provide guidance and examples, but do not aim at replacing local design. So if I built that Lego car that I think is cool, doesn't necessarily mean that you find it cool. But you understand what I mean. I talked about it before. So the considerations, it's not only about customizing the packages that we produce, but the adapting and the implementing of those packages means sometimes adding additional budget lines. So you need readiness assessments. You need to customize the process itself. You need to plan the implementation and get the technical support and you need to train the teams. Also the end user training for the new modules, the dashboard or the data analysis trainings. Again, a lot of these materials are part of the toolkits, so you do not need to reinvent the wheel, but maybe localization translation is needed. For the new tracker implementations, this is a specific topic. We have a tracker budget guidance, so that needs to be addressed when considering the implementations. And then it's not a one-off implementation like it happens sometimes when you think, okay, I started and that's it. You need to, some costs will be recurring because of the upgrades, updates, the training refreshments and so on. And of course the upgrades to the systems and review of the data and metadata quality is very useful and needs to be considered. So I think, I have, do we have time? I think we're not too late for discussion, so I would like to hear from the, maybe starting from the HISPs about their feedback on the process of how these standard toolkits help them to implement in the countries and open it for the broader discussion and questions. Thank you. Yes, please. So the objective of the toolkit, and I think that's one of the main ones from our side is to improve data quality and provide the team or the implementing party with tools for analysis and the use of that data. And even in this aspect, not all the implementations are mature enough for this. I can give you examples where people want, let's say, statistic data only because that's required by the government and they don't have the capacity to look into analytics tools, but still adopting part of the toolkit will help them to replace the burden of, you know, manual aggregation and then in a stepwise approach address the data use questions and so on. So that's number one. And number two, the toolkit is a collection of resources, basically. It has the design guidance on the packages, it has the overview of different components that you can implement within one health area. So let's say data quality, dashboards, trackers, aggregate packages, and it contains different resources, whether you want to start by reporting aggregated data or whether you have enough capacity to start with the individual case-based data in DHS2. So that makes it a toolkit. So the collection of resources that are available for you at any time to study, to present to the ministry, and to consider using. Yes, so let's say you start with a simple data set with aggregated data where periodically the data will be collected. How it's aggregated, whether the people doing it on paper or in registers, that's one question. You have that. The second step maybe is to build some visualizations or adapt the visualizations that are coming with the toolkit to analyze the data. So the dashboards based on the data you've entered. Then the step after that would be to plug in a tracker where the individual-based data will be automatically aggregated and filling those aggregate data sets that you implemented in step one. And therefore making the data granularity even more clear. And there can be several steps in between, but that's kind of what I hope I've managed to answer. Adnan, would you like to come here? Yeah. I don't know if that microphone works, but you can. But actually, Adnan, sorry. I remember we are recording the session and the microphone is sitting in the computer. So. But I mean, I guess we are the only hits apart from Indonesia who have been using tracker over here. And Mina is also there, but I don't know if you've used any packages. While Yuri was talking, I just kind of recalled when we met for the first time, he was there online and he was presenting this TB and HIV tracker. And at that time, I mean, we had this Gates Foundation project coming into digitized case-based TB tracker. So when I saw the tracker, I was very happy and I said that my whole work is done because I got all the configurations, I got all the dashboards, I've got everything. So I guess it was like this. So we got the early release and we just installed it onto a dummy server. We started working and then we changed that tracker a lot to an extent that I and Ula were working in the office and we practically broke it. And then we had to contact Yuri again. Yuri, I mean, we broke the tracker, there's something issue. So no matter how close your configurations or your data flows are, these trackers, these packages are very good and can be used as a reference material because they do make your life easy. You will get all of the data flow by just clicking a few buttons and the tracker is installed, the packages are drawn and you can simply show the government that this is the data flow that you're following. And the data flow usually is the same. The reason is because UIO is a WHO-collaborating organization. So Yuri, there's Boston, Brando, all of them sit with WHO very closely, work with them and make those workflows work for you. So Yuri also presented about this health facility profile. I guess we were the first country to use a TB tracker, WHO TB tracker package. We were the first country to use nutrition aggregate module package. And I guess we will be the first country to use the health facility profile package as well. But this time, I'm not keeping my core size. So we'll be doing a lot of configuration according to set the tracker according to the country context. So you get a card, but you need to put in the fuel and necessary parts just to make it run. So I guess that's what I wanted to say because I mean, these packages are really good when we talk about baseline configuration when you get all of these really good data flows going in. And we also learned a lot while implementing this tracker that how these program indicators are working, we had to change them according to the country context. But this helped us a lot. And secondly, the good thing about these packages is that they follow our standard. So like we have this WHO aggregate TB package, which only collects aggregate data. And then we have this WHO cracker TB package, which is a more kind of a case-based system. But if you want to do case-based to aggregate because you do need aggregate reporting at your end, and that can be easily done because the standard they are following is the same. So this is also something that helps you a lot while you're implementing. So yeah, thank you. Thank you. I'll just add a comment to what you said. And yes, these two kits, these packages, they follow standards. This does not stop countries or individual organizations to develop their own trackers. But I think knowing the steps that we have taken and learning from our experience will also help you to develop your own material in a way that you will not be regretting it in the future when you have to change, add or remove our things. So the standards we include in our toolkits are also helpful for any individual developments. So for the global portfolio, we have our donors, we have the organizations that we work with. And so together with them, we have the calendar of releases we plan ahead for the next year. What are we going to work with them? So that is being on the global level of the global fund, the WHO and us. But then you have exactly like you're saying, if you have the local requirement. And I have just had the conversation with a WHO country office and they said, well, what do you have on your agenda for the upcoming releases? Because we would like to work on that. I said, well, but why does it stop you? Why do you need to be chained to all the global work? You can also try to define your local demands. Oh, the donors, they react better if they see some global components in that surely. But if you have a hispin place or if you have the local implementers that can work on the requirements that you have and build those trackers, we can support you through that. So you can first of all contact us. And if we might help you identify countries or maybe players that have already gone that through that path and find some resources that you can use to get you started, we have a community of users where you can also try to give it a start. And that's how things get started. And maybe from that we can also think of something more global. So and sorry, and you, where are you from? Well, you know, some people think we are doing that. Yes. And then we have to say that we can, but should we? You can cross question. Can you develop? Yeah. Yes. And there's also another component. I think you should also I would always recommend a stepwise approach to that. Okay. So the first may be that just, you know, studying the demo and the guidance. The second would be to demo it to the to the country, to the implementation partners and then consider where to begin. Because sometimes you can just throw the resources and say, oh, let's translate everything first. And then you realize how through the way, no, those dashboards are not needed for us. And then you've spent the resources on that already. And translation is maybe not the major part of that, but still that happens. So you maybe say, okay, let's let's, when it comes to tracker, let's look at the data entry. How can it be worked? And then if it works with a standard configuration, you can try to pilot it in the standard configuration and see what data you still need, what is not needed. Because even with the country needs, you might at a certain point identify that you're building such a complex thing that you might not really need. And then you can say, okay, let's park that for the phase two, for the phase three, and start with the basics. Because it's much easier to extend than, you know, to have the whole giant to the, you know, monster that you will not be able to take apart after. So, yeah. So I guess if there are no more questions, we can close the session. And thank you very much for listening and taking part in that.