 We are now live, so I'm going to start accepting participants. Good morning, good afternoon, good evening, everyone that already joined this webinar. We are going to wait a couple more minutes to allow all the people that are going to be interested to join the webinar, maybe just some housekeeping. In case there will be any questions during the webinar, we invite you to write your question in the community of practice of DHS2. So this question then, if they are not answered during the webinar, can be answered later on. You can find the link for the community of practice on the G. Okay, great. I think we can get started. So again, welcome to everybody and just housekeeping. In case you have any questions, please feel free to post them on the community of practice of DHS2. You have the link directly in the chat on this Zoom webinar. The agenda for today. So we will have WHO representative, Shona Dalaube. She is going to explain a little bit about this collaboration. There is between the HIP Center, DHS2 with the WHO teams. Then we will have, we will provide an overview about the updated DHS2 HIV toolkit. After there will be as well a presentation from WHO about the smart guidelines and the integration of this on the updated DHS2 HIV toolkit. And last but not least, we will have the presentation from two countries, use case, Ghana and Costa Rica. And then we will reserve around 20 to 30 minutes of Q&A. So without waiting more, I think I can leave the floor to Shona Dalaube from WHO. Thank you very much. Thank you so much, Stefano. It's wonderful to be here today after an awful amount of work. And my name is Shona Dalaube. I'm the surveillance officer in the department of HIV hepatitis and STIs at WHO in Geneva. We're so pleased to have you here and to be able to release these two new DHS2 trackers, one for HIV prevention and one for HIV case surveillance. These have been based on the latest WHO guidelines. That's our consolidated strategic information guidelines released in 2022 and are aligned with our clinical guidelines also on HIV testing prevention and treatment. It's been a wonderful collaboration with the University of Oslo to put these materials out to enable, most importantly, the ability to follow individuals over time and to monitor program and service delivery. We know in the world of HIV that this is incredibly important as people come in and out of care, both for prevention and also sometimes for treatment. So Stefano, Rebecca, Brian, Pablo and others on the team have worked very hard to do this. And our colleagues from the PAHO, the Pan American Health Organization have developed one also for Costa Rica in Spanish. And so we will be hearing from them today as well as from Ghana. So we're thrilled to be able to share these materials with you and hope to be able to turn now to implementation and for better person-centered monitoring. Back to you, Stefano. Okay, great. Thank you very much, Shona. So just going to enable my camera for a few seconds for two greetings and then I will just switch off for connectivity purpose. So the next item of agenda is the presentation about just be able to provide an overview about the updated DHS2 HIV global. But first of all, I just want to provide that for the ones that maybe they are not as familiar with DHS2. Some basic information about what is DHS2. So DHS2 is a web-based free and open source software platform that has been recognized in the last years as a global public group. It supports the collection, management and analysis of data, both aggregated individual data. Both of them are two components that we are going to see during the presentation of the day. It's highly configurable and can be adapted according to the local context. The platform architecture as well is a web app allow for development of custom applications on top of the DHS2 infrastructure. But as well for the integration with other systems. The owners of the instance of the information is the user organization. It can be MOH or it can be other organizations. And there is a very large community of stakeholder and a very active community of practice, which I think most of you are already part. And the DHS2 has been developed and is developed by ISP Center, the University of Oslo. And it is constantly updates. DHS2 is considered as an integrated platform. It is the world largest health management information system at the moment. And it is being used and adapted in more than 70 Ministry of Health around the world. It's being coordinated by ISP Center, University of Oslo. And there is a big network of developers and experts all around the world. As well, the University of Oslo works with a new network of ISP groups and trust the regional partners to provide DHS2 implementation support, local customization and configuration. And as well, building national and regional capacity through our DHS2 academic program and promoting DHS2 as a global public good. The ISP group also play an important role in the DHS2 software development process, including gathering requirements, facilitative feedback from the field, and developing innovative web and mobile application and local configuration that DHS2 developers can then integrate into the main platform for worldwide use. The groups, some developers and moderators are made up of various profiles. Program developers, IT specialists, specialized people, interest in health, education and other fields. And as well as programs, managers and staff. Then the ISP groups are among our most trusted and long standing partners in the field. ISPs are the main liaison for DHS2 with Ministry of Health in countries where DHS2 is deployed. And this close and continued collaboration has been the main reason for the successful adoption of DHS2 in more than 70 countries. In addition to co-working with the ISP UI University of Oslo on project individual ISP groups are also available to provide directed DHS2 support and advice. So here the network with ISP groups has now grown a lot. They are not all here on this map, but now we are counting up to 26 regional groups that are supporting the community all over the world. So a little bit here is a kind of pyramidal representation about when we are talking about global standard, global goods. So in this case, for example, the HIV toolkit that we are going to present, then it comes back on the regional hubs. So the adaptation at regional level that can be facilitated by the different ISP groups. And then of course the implementation at national level, which these toolkits, this metadata package need to be installed, but especially need to be customized to ASRA to the local needs. Since 2017, the ISP center has been designated as a WHO collaborating center for innovation implementation research in health information systems training. So since this date, we have started this collaboration with WHO. We have been working on the development of different standard toolkits. As today we are presenting HIV, but there are as well a lot of others like malaria, tuberculosis, community, API, etc., etc. So here I just want to point out a bit because these are changes that we have done during the last year. We have shifted from a metadata package concept to a toolkit concept. So when we are talking about metadata package, it's really kind of the product is a common metadata library with the dashboards and the dependency, tracker programs or aggregate programs and a group of indicators. And we have shifted to more a toolkit concept of delivery of products. So in which in this toolkit, of course, there is still the components of a JSON file. So a metadata library, but they are supported by guidance, the system design guides that are that is a very key documentation that we will see later, in which we are going to kind of details all the information related to the implementation and why is the different decisions were taken during the elaboration of the product. So there is a demo instance in which you can enter and play around with the different programs that have been done. There are as well kind of very well described all the different tools that have been created and integrated on the system and training a capacity building materials that can be used during the implementations. So here to start for HIV, as Shana was mentioning, the last guidelines are very focused on a person-centered approach. And what I'm displaying here is kind of an example of what an HMIS architecture can look like inside a country. Okay, so really to explain and to show the complexity because most of you know that when we can have a different software, different platforms that are collecting different information for the same program, then this information to be aggregated together to be able to be analyzed. Okay, so here is kind of example of maybe a country which is using the HS2 app through the Android or the HS2 web apps, collecting maybe individual information, having other actors collecting individual or aggregate information and how this information can verge all together to then be able to be analyzed. So this is something that you're going to see. And there was a key aspect that we were taking consideration during the development of the toolkit. And that's why as well is key is very important to work for us to work with global standards. Okay, WHO recently released a guidelines for person-centered monitoring, not only for HIV, but as well for tuberculosis. So part of this learning is really to understand how country information architecture are established and how data comes together from different sources to comply with the guidelines. In the future, this inform our approaches and guidance. That's why as well we decided to switch from a package concept to more toolkit because the toolkit we are going to keep all the documentation updated and having some of less or learn from the country implementation. And another key aspect is putting a data analysis, having a data analysis that forefront and recognizing the role of an integrated health information management system. We are generally able to provide solution with the flexibility countries need to meet global analysis standards and address local realities and needs. We believe that it's important to provide a pathway for countries at any level of health information system maturity and to grow their system to full maturity. Very few have reached the moment the national scale with tracker and other individual data systems. So that's why we need to take in consideration all these aspects when we want to tackle this type of work. So the HIV tool kits leverage all the DHS2 application and data model to support a practical, implementable approaches to collecting, analyzing and using HIV data effectively to prevent HIV infection and link new identified HIV cases into treatment programs and national HIV case surveillance system. These tools can be used in a modular way to meet the needs of any country along the maturity model for digitizing for digitization of health data, including hybrid implementation of paper base and digitalized system, and as well incorporating data from other electronic tools like hospital or EMRs where they're mainly used. The HIV tool kit is optimized for improving strategic information system in countries to facilitate data driver decision making, as well as streamline routine data management process. The DHS2 HIV tracker are not designed to provide clinical decision support for HIV service, but rather serves as an operational tool and a source of individual data for person-centered monitoring. The latest version of the DHS2 HIV toolkit is based on the WHO consolidated guidelines on person-centered HIV strategic information and as well the second edition of the digital adaptation kit. If you look at the toolkit, you will find a set of tracker, one for HIV prevention, one for HIV case surveillance, a set of aggregated data set, and all the data analysis tools, dashboard and visualization and the standard indicators, but as well all the implementation data, system design guides and other key information. Here, I just want to give a snapshot about how the HIV prevention tracker model is organized. For time sake, we cannot go and do demos of both tracker programs because if not, the webinar is going to last three hours at least. So I just want to provide a snapshot of how the program has been organized. And as you can see, it's a very flat structure. In this program, you will see both prevention tracker and case surveillance tracker, the number of stages is very reduced. And as well, the way how it's organized is in a very moderate aspect, to enhance and to simplify the local implementations. So you will see that we have the first part is their enrollment, the initial case report for sensitive applications, and then the main stage is the visit stage, in which inside of each stages, we have all the different actions that can take place during a visitor. HIV test, middle-series program, content distribution, prep, PEP, risk assessment, OMT, etc. Here, just to give a little bit, an example of what has been collected on the enrollment page. So here we have a kind of a very key information. For example, program ID. The program ID has been kept blank by purpose. Because each country is going to have its own way of codification. So that's why it's been kept blank. Then other generic information like name, date of birth, if it's known or unknown, sex, gender, etc. And then another key information is what is collecting the initial case report. So initial case report, this information related with the key population like MSM, people who inject drugs, etc, etc. This information has very sensitive information. That's why they have been kept in a separate section. So when we are enrolling on new patients into both HIV prevention, HIV case surveillance, this information that should be present in the enrollment page has been kept in a separate one. Because as you will know, when we are looking for what we call the TI, the drug-related instance inside our system, we don't want to have this attribute as a search attribute. Because it can be a very, very sensitive information according to the different context. And then here is an upshot of the main stage. Okay. It was really decided to keep all the information in a stage rather than scatter this information in all other stages. Because, and this was done mainly for implementation purpose. We see during the years that when this very complex toolkit, a very complex program need to be adopted and adopted in the country implementation is much more easier to have a very flat and convertimalized structure that can be then reorganized according to the needs. So you can see here that there are all the different specific actions that we can do during a visit. For example, to a patient we are doing a risk assessment, maybe we are doing a counter-distribution on HIV test. We just need to select which section do we want to display. Sorry. And then we are able to enter the information. There are some specificities. So for example, for a risk assessment, this is something that has been, the risk assessment section contains a set of questions that are designed to ascertain whether the client is at elevated risk for HIV acquisition or not. If any of these questions are answered with yes, then the TI will be classified as an elevator risk for HIV acquisition. So this set of questions were taken from the WHO guidance, but of course these need to be adopted and changed according to the country context. But it's very key because most of the indicators are really asking about the risk of our client as well. It can be implementation in which according to the risk we can decide to provide prep or other type of follow-up of this patient. And then here the HIV test. HIV test, you will see that we only have one HIV test. Yeah, you will see testing three-point, the TB status, the partner HIV status, and the HIV self-test. But for the HIV tests that are done on CTUS, there is only one typology of one type of HIV test. Why? We know that each country, each implementation has a different algorithm. You can have one, two, or three different tests to be able to diagnose an HIV case or not. We leave it only one by purpose because if we're already going to provide, for example, a logarithm of three tests, then this needs to be changed, adopted, a lot of program rules, etc. need to be customized. So here was just to provide an example of how this could look like. And now jumping to the HIV case surveillance tracker module. So you see that the structure is the same. We have the enrollment and initial case report. The information collected are almost the same. The busy stage is the main stage with all the different details inside. If you are going to collect information about the treatment, TB, HIV, vertical transmission, STI, paralipatitis, or cervical cancer. The only difference, for example, in the initial case report, you can see that they are present here and not in the HIV prevention for obvious reason, is about the information related to the positivity. So when the case was diagnosed as HIV positive, the age, the testing entry points, and the probable route of transmission. If not, related for the key information, for the key population information as well, the same list of options are present here. And for the same reason as before, the initial case report is not part of the enrollment because there are very key assistive information that we don't want to be searched widely on the application. Follow the same logic. You see here we have the different activities like tuberculosis, HIV, vertical transmission that we can select to enter information or not. The only part that means it's very key for HIV case management is the treatment. The treatment, yes or yes, we always need to have information on it. Okay, so sorry, we always need to provide information about the treatment station, treatment status, sorry, if it's an initiation, it's still on RT, if it's stopped, if it's refused, and then other basic information like CD4 count, viral load, if viral load is available only after the patient has been in RT for more than 180 days. And if it's part of any DSD, RT, enrollments, et cetera, et cetera. So these are key information to be collected always. So the tracker data elements, these elements that are part of the tracker, that can already be considered as a metadata dictionary. So all the elements that are configured for the tracker are included in 2D-4N data element groups. And this serves the factor of the DHS-2 dictionary for HIV prevention track reduce. Then we have these are just some characteristics of the tracker data elements. We have the multi-option selection. As you know, this functionality is still not present. We'll be available from the version 2.41. But so we need to do some work around this case. It's just, as you can see here in this gift, we can select different time. We have different data elements for the same purpose, with the same option sets. In case one option is selected more than once, we provide an error. So just a workaround for this multi-option selection. Then we have quite a big quantity of hiding data elements and assigned values of data elements. And why these are the ones that are needed to be able to calculate all the indicators that are present on the toolkit. In the toolkit itself, the objective was really to have it with a flexible and flat tracker structure. Because in this way, having it as a flexible and expandable, you see that you can have a different section that can be easily translated stages in case there are different users that are going to do. For example, in the case of HIV case surveillance, if the ones that are entering information already with the coinfection of HIV tuberculosis of other users, you can simply create a stage with the same information already part of the section. We reduce a lot of the amount of program rules. And they are as well very well identified to be able, once you need to modify the data model to identify them. And as well for a local adaptation, in case any of the activities are not done. So here is an example of the MMC for the HIV prevention tracker. You can just decide to eliminate this section. So really the objective for this was to make it as simple and as easy as possible to be adopted at local level, but still keeping all the core metadata that are necessary for the calculation of the indicators. It's said before, both tracker or the HIV toolkit has been based on the list of indicators from the HIV WHO guidelines. There is the possibility, maybe you can think why we have two separate tracker. Why we have one for HIV prevention, another one for HIV case surveillance. Normally, a patient's appliance enter in the HIV prevention and then if it became positive, then we'll continue on the HIV case surveillance. We decide to keep it separated because there are different factors to be evaluated in case we want to merge in just one tracker. First of all, the scale. The number of persons that are enrolled in a prevention program is likely to be much, much greater than the number of persons diagnosed as positive and enrolled in a case surveillance program. And this may have an impact on performance and also requires an adequate server infrastructure for large-scale tracker implementation. The second point is the type of service provider. There's normally in many countries, all of these activities for HIV prevention, they are done by NGOs, Internet NGOs, civil society organization. So that's why also the type of use and who is going to collect this information are different. And then as well for analytical demands, according to the indicators that are present on the WHO guidelines, all of these indicators can be calculated as well with the two separate tracker. So that's why we decide to keep this structure separate. But in case we can merge both of them because as you can see here, the structure of the tracker, we have the enrollments that the information are the same. Information and the UIDs. Okay, when I say information, I'm referring to metadata. The metadata is the same, the share between the two programs. Initial case report as well is the same. In HIV case surveillance, we just have more information related with when the person was diagnosed with HIV. The visit stage as well is the same. What is different in the visit stage is the different section of information are collected. But still, there are some of them that are the same. The STI, the metadata is the same from one to another one. And as well, the viral hepatitis. So here is just to show you, for example, from the enrollment part, the metadata is completely the same from HIV prevention and HIV case surveillance, to enhance this possibility. But now the most important part is the HIV analytics. Because as we say before, both tracker, all the program, all the metadata has been based on the indicator and analytic needs that are part of the WHO guidelines. So in the toolkit, you will find two different types of analytics. So we have the WHO standard indicators that are really a collection of indicators and program indicators that are mapped with the WHO guidelines. Then we have the ones that have been used on the backboards. The one that you know that board is a subset of the ones that has been used on the data being created for the WHO standard indicators. Because the ones that were created, we are talking about 75 indicators, plus all the different aggregations. Okay, so all the indicators that were present on the WHO guidelines can be calculated and they are really present and mapped in this toolkit. This one with all the different aggregations. Of course, these indicators are kind of advanced indicator, because most of them are coming from a program indicator. So here you will find that there is kind of a large use of program indicator or even type for performance reason. There is a large use of custom period boundaries as well in the custom period boundaries. We are using different boundaries for before and after. Here is just an example to calculate the people that are in HIV currently, people with HIV currently on an ART. And all these details are described in the systems guide. So are part of the toolkit, are part of this key documentation. And then the part of the analytics, the part of the dashboards. So for example, we have three different type of dashboards. We have programmatic dashboards, case surveillance and prevention. So the programmatic dashboard are two overarching programmatic monitoring dashboards that need to monitor key performance indicators like the 395, but then we have the HIV case surveillance as well that have another set of indicators that are specifically for the follow up of a specific aspect of case surveillance and as well for HIV prevention. Yeah, we have a snapshot. So for example, for the programmatic dashboard, of course, all the data that you are seeing here is dummy data, not the representative of the country. Okay, so we want to thank Salahos, Ministry of Health, to all of us for the use of their organizational unit, your CHI, but all the data that you are seeing here is not real data. So for example, here you are seeing kind of the key indicators that are part of a bigger list on the dashboards about the 395 distribution cases, community by organizational units. And then here we have the set of prevention dashboards. You see that there are 10 different dashboards that are divided into, let's say two subcategories, which we have by topic. So HIV prevention testing, HIV prevention prep, HIV prevention prep, and what is present there are present the core indicators that has been identified in WHO for analysis. And then other two, health facility and subnational level, we need to facilitate and provide some example of how this data can be analyzed at these two different levels. And then HIV case surveillance dashboards, in which here you see we have case surveillance generic, then air initiation, rotation, and virus suppression, DSD models, HIV, TB, epidemic status, et cetera, et cetera. So we are talking about a total amount of 20 dashboard within the toolkit, but it has been categorized to be able to be in case you want to see specific information, you know where you have to go. And but the most important question is where is this data coming from? Because what I just saw you are dashboards that are populated, but these data are coming from the aggregate data system or an individual data system. They're coming from both. You remember well, no, this snapshot of how an HIV on an HMIS system can look like with all the complexity of integration, different system, different source of data, different type of data. So we try to replicate a bit with the toolkit and really try to provide a kind of example of an integrated ecosystem because in this case in this toolkit, you will find that all the data that are populated in the dashboards are coming from an aggregate data model. But this aggregate data model, the data that are present there are coming from program indicators. Okay, so the first step was the production of program indicators. So we produced the program indicators and we produced the program indicators that need to feed an aggregate data set that is based on the dashboard needs, okay, on the analytics needs. So first step, production of program indicators. The second step is this time was that exchange app. So through that exchange app, what we did was map all every program indicator to is correspond that data element and category combos. Okay, this application what is doing is simply aggregating the data from the program indicators to an aggregate data model. And here you have an example of the mapping that the mapping as well as provided in the toolkit in which you have for each data elements. What is the program indicators for each data elements with the category option combination. What is the program indicators. So, populated data elements that are populated with program indicators that are fed in a data set that are going to populate dashboards. And why we have done this. First of all, for this reason, okay, we need to provide a kind of an example of integrated, integrated approach for analysis. But also because the fundamental, the most important part is always analysis. Once we have the data, we need to analyze that so we need to enhance this. But as well for performance issue, how many times we found ourselves with the dashboard and visualizations with data coming from program indicators that they keep loading infinity time. Quite a lot. So that's why we took this decision. And simply, here you have the set of data sets that are where the data elements are landing. So we have kind of three different sets of data sets. Prevention, case, variance and program. So the prevention we have HIV prevention monthly, yearly and population estimation, same for case surveillance. And for population estimation is more for generic for generic indicators like incidents and more time. But why we have monthly and yearly spare these things. Simply because for the analysis that we are doing the dashboards, what we are counting, we are counting the number of patients. We are counting the number of clients. So of course, for example, if we have an indicator saying, okay, number of clients that have been tested. The result is given for one month is different from the results is given for the world here because a client can be tested several times. But we want to count it as one during the year. Okay, can be tested several times during the year, but we want to count as one during this period. And then the HIV program at the dashboard, we have these two data sets that is the stock report that you know already very well. That is what the health facility profile something very new. So for a health facility profile, what we mean is really to be able to map which type of service are provided a health facility level. We have a separate toolkit that is specific for health facility profile, but we decide in collaboration with WHO to integrate this aspect of kind of be able to map the availability of the service because sometimes this is extremely necessary. Okay, to be able to know that all the population are served by basic basic services. So here are really key cases, you know, okay, does a offers HIV testing does offers ART, CD4 counting, viral load testing. And another key points that are presented in this, in this toolkit is the ownership analytics. You will know that there was always this was a very request key possibility for for the HS to a specific for a problem like HIV in which we have cohort in which patients can change from an organization you need to another one can change from a health facility to another. The problem is that before we were not able to distinguish. Okay, this and these clients receive a receive that this this this treatment here then it was transferred so we need to counter now we need to count it at the end so in which health facility now is present with the ownership analytics that are presented from the version 2.4 2.40 owner. We are able to identify and we are able to specify. Okay, which clients we want to come we want to count the ones in there. The owner, the owner, the organization unit owner at the end of the period at the beginning so where it starts or at which point. Okay, so until now, we were able only to have the outputs for the last organization units in which they were transferred. So with this ownership analytics, we are able to see, okay, this patient start here and end up here so we can decide to come to the in the in the first alpha city which was enrolled or in the last one in which you receive any type of treatment. And then here just want to provide the kind of guide and all this material because here for sake of time it cannot really go on the details but where you can find it. First of all, all the documentations, then the demo sites and download so you can see here on the landing page of the site where you can find the health apparatus and go for the specific programs and here is where you can find the system design guide in which is very well detailed. Everything, everything, everything, all the specificity of each of the elements of each on the, of the indicators and as well the decision of on the development of this book either work taken but as well that you can go on the demo site so here is the new metadata download page in which you can select that by the area so for example let's say HIV and you have the different packages located and create a case surveillance operation for the version of the language, but then the most important part is the demo. So here now today just really give you some bits of what, what the case surveillance a preparation truck and looks like but it really invite you to go in the demo sites. You have the username the password on the landing page and to play around to play around to be able to see okay is going to be useful not useful and in case you have any feedbacks. Sorry. Any feedbacks please just contact us and here always very, very important is the committee of practice of DHS. So, thank you very much and now I will hand over to she's going to explain us a bit about the smart guidance process and how these were integrated on the development of the book. Thank you Stefano. Let me just share screen. I think there are several questions I just noticed them in the chat so we can try to address those. Could you confirm that you see my slides and full screen mode. Yes, I can. So, thank you again Stefano for this really nice summary of the two tracker modules that you've developed for us for HIV prevention and this is really for the first time to enable person centered prevention monitoring and the goal is not just to monitor people receiving prevention but to also identify missed opportunities for prevention when people test HIV positive and that is recorded in the case surveillance package which is as you heard the second the second version. So, I'm just going to shift gear a little bit to tell you a little bit about the smart guidelines that we're developing at WHO, as well as how we track some of these pieces together both for the digital adaptation kits and for the DHS two trackers. So, you know, WHO puts out formal recommendations that are have a clinical meaning for several different areas across HIV prevention testing treatment and service delivery as well as monitoring. These recommendations can be fairly complicated. And they include integration across other disease areas such as tuberculosis SDIs hepatitis and some NCDs. So, why do we want to help translate these recommendations to digital systems so that there can be more easily understood. The first is for decision support tools where, for example, clinicians can understand which clients are better suited for multi month drug dispensing. So, the tracker doesn't do this, but the other digital tools we're hoping will support this kind of work. The second is for automated scheduling. So, when is the next schedule date for an ARV drug refill? The third is for automated validation. So, was the entered drug dosage within the recommended range? Are there any likely interactions with that drug regimen and so forth. And then finally for automated reporting of indicators because we want to make sure that everybody understands exactly what we mean when we list out a particular indicator. So, we know what the numerator and denominator are and where they are derived from. So, even though we put out these clinical recommendations that HIV digital ecosystem of countries is enormously variable both between countries and even within countries. Some have predominantly paper based others are moving to electronic medical records. Others have fully functional electronic medical records and they have different levels of reporting at subnational and national levels on, you know, where are the paper based forms aggregated and entered into digital systems. And it's so our goal with the release of these products and we call them the smart guidelines from WHO is to really represent the WHO recommendations, the clinical recommendations content as digital health components to first preserve fidelity to the intention of that language of the recommendation and then secondly to accelerate uptake. So there are five layers of WHO recommendations in the smart guidelines process. The first is the narrative so this is the standard PDF that we released that said, you know, for HIV treatment and prevention do this or the other testing guidelines, and so forth. The second is the L2 so this is the second layer these are the operational guidelines and they bring in this narrative content from the from the guidelines that are released the PDF into what we call digital adaptation kits. So these are human readable, but can be entered into a digital system to describe how that digital tool should function. So we've released the second edition of the HIV DAC in December of 2023. And in 2024 moving on to the layer three. This is now the machine readable content of the guidelines where we have it's based on the clinical practice guidelines as a fire implementation guide. And, and again this is software agnostic. So we expect this in 2024. The fourth layer is the executable so these are fully executable software tools which have mechanisms for real time updates and then are interoperable with others and national systems. And then the layer five is the dynamic advanced analytics where you have your precision public health and AI based decision support we aren't there yet unfortunately but we're working towards it. So the currently available HIV guidelines so this is the first layer is the 2021 clinical guidelines and the 2022 strategic information guidelines that are focused on person centered services. So when building the digital adaptation kit for HIV and these DHIS to tools we really focused on the data dictionary construction from the strategic information guidelines. So essentially what that includes is a minimum data set so here's an example from the management of HIV associated TV. We have minimum data sets for the first time throughout the strategic information guidelines where we define what is the data element that has to be collected. What are the codes and what's the frequency and with that information it enables person centered monitoring. We call it a minimum data set because it's not comprehensively everything you need to know but it includes the key components. We then use that minimum data set to get the data requirements for clinical management for HIV prevention for surveillance and for reporting. So we use that minimum data set map it to international standards and then develop this data dictionary. So the HIV DAC is packaged as a PDF which has several different examples and personas about a nurse and a client and workflows through different aspects of the cascade of care that you may encounter for HIV prevention testing treatment and service delivery. And then in addition to the PDF, there are four Excel files. The first one is the data dictionary that I just described to you. The second file is the decision support logic. So this is where WHO recommendations are written as decision logic so that it's software neutral but the elements that are required for example to determine what to do if a viral load test is X is very clear. The third file C is the indicators where we calculate the definitions and determine how to calculate them automatically. And the last one is the functional and non functional requirements which says you know what functions should the digital system perform who should do it and what type of security access they have. So this can be accessed at our website it's on the HIV surveillance page here at the bottom. So here is how we used it for these trackers that Stefano has been telling you about from today. And essentially we've used the data dictionary to determine the types of data. What are the valid categories and the validation conditions. And although the trackers don't use decision support but how we're making sure that it maps to the international coding standards. So for example here's an example you have the ART start date we define in the data dictionary the data element ID what it means how it's described what type of data is it and then the codes for it. So essentially the DAC as well as the DHS to case surveillance and prevention trackers have specified requirements, you know based on the guidelines. The HIV DAC was used as a reference for the indicator calculations and the data elements and the DHS to tracker metadata includes mapping between the DHS to tracker data elements and the date HIV DAC data elements. So essentially, once you have that data dictionary defined it enables the calculation of other indicators. Depending on what's important for a country. If they've already adapted the HIV DAC so for example, if a certain partner or somebody else has a different reporting period, those can be modified in at the country level. So in conclusion, at WHO we strongly believe that strengthening routine individual level data system is critical. It improves national capacity to monitor and respond to health needs in real time at local levels and at national levels. It improves the quality of care it improves surveillance program performance and impact. It's sustainable and scalable. It increases the capacity to link across different data systems for example labs or pharmacies. It facilitates longitudinal records so for following individuals over time as they interact with the health services over their life course. And ultimately they should have individuals and patients should have access to their own personal health record to enable their continuity of care. And digital tools such as the digital adaptation kit and the coming machine readable guidelines as well as these two trackers really support this idea of person centered monitoring to improve data at the facility level at the national level and to aid in the monitoring of the HIV response. So we have many people to thank but in particular I'd like to thank Stefano, Rebecca, Brian and Pablo for the work that they've done on developing these trackers and also particularly the Global Fund which supported this work including Michelle Monroe and several people including Will Provert, Nat and others who developed the digital adaptation kit for HIV with us. Thanks so much. Thank you very much, Shona. And I'm just going to link here myself for another moment because as you can see my screen and because as Shona mentioned, we really use this DAC especially for the second level, the DAC for the work on the conceptualization and the production of the tracker. And not only the tracker itself for all the toolkit. So here, what we did there, we did that, between our data model and data model we're presenting the DAC. So for example, the HIV preparation, 80% of our metadata is mapped with the DAC. The ones that are not present so the rest of the percentage is more for the enable the multi-options so that means that repeated or other for the data flow. And meanwhile, the indicators, all the indicators are present in the DAC are present as well in the toolkit. For the HIV case of variance, the data model is 92% compliance. So 92% of all the metadata have been mapped with the DAC and as well here for indicators 100%. And here's the example of the mapping. So you have the DHS through metadata and the DAC code. It's not only the DAC, because as Shona mentioned, there are as well other standard that have been mapped to the DAC. Okay, like Snowman, the ACD, et cetera, et cetera. But here, what we have is the DAC, but as well, the rest of them. And this part is part of the documentation that is present in the toolkit. And here I just want to show an example of how we use the DAC for the creation of the indicators in the AKS2 system. So for example, for this indicator for the PRV number 7, the HIV in PEP recipients. So the numerator and definitions is the number of people testing positive for HIV three months after receiving PEPs. You see here, this kind of complexity as well for the system to be able to see, okay, after three months, what is the HIV status of the client. So here we have step-by-step count of clients. So it's a program indicator of even type with aggregation of type count. The medication prescribed is PEP for HIV prevention and the type of visit is initiation of PEP. The date, the medication was prescribed, so when the PEP was initiated. And as well, within reporting period and HIV test date, so the date of our HIV test when it was done, that is less than three months. So the difference between the HIV test and the last PEP initiation is less than three months. And here is the formula that is the filter that is present in the program indicators. And moreover, the rest of the filter is all the ones that have HIV positive results. So here is really a translation of what is present in the DAC into the DHS2 systems. And here is another example because there is a part of what business logic is where it's present in the DAC, how this has been translated, something very basic, okay, in the DHS2. But here, for example, initiation of PEP, we know that the course of PEP is 28 days. So here is already suggesting the end date. And based on this, then we can decide to have notification sent to the client to come back for visit, et cetera, et cetera. Okay, just want to show how the DHS2 can support as well the adoption of the DAC. And with this, I will just stop to share. And I will leave the floor to Ekaterina from Costa Rica that she's going to explain and to show a little bit how the work that was done conjuntally with the University of Oslo in collaboration with the PAHO and the East Columbia on the adaptation and the use of the DHS2 in HIV prevention and in case management mostly for prevention in Costa Rica. Please Ekaterina, the floor is yours. Thank you. Thank you, Stefano. I'm going to share my screen. Okay, please let me know if you can see it. We can see it. I'm sorry, just on housekeeping because I see there are a lot of questions in the chat. We really invite you to put the question in the computer practice because we are not sure that we are going to be able to answer all of that during the webinar. If you are posting them in the computer practice, then we'll be able to answer them later. Thank you. No, that's fine. Thank you. Can you see the presentation mode? Sorry. Yeah, yeah. Just wanted to be sure. Yeah. Okay. Thank you. Okay, so hello everyone. My name is Ekaterina Trujillo. I am the program manager at HIVOS. I oversee the Costa Rica HIV project funded by the Global Fund to fight AIDS tuberculosis and malaria. I would like to talk a bit about our experience with the DHS2 for the use of civil society organizations working in the HIV response in Costa Rica. Okay. So first, I want to share with you some data regarding the epidemic dynamics in our country. Regarding HIV prevalence, it is concentrated within two key populations, gay men and other men who have sex with men, MSN and transgender women. The prevalence of HIV in this population sees 15.4% for gay men and other men who have sex with men and 23% for transgender women. In terms of the estimation of people living with HIV in Costa Rica, this moment needs 17,000 people and we have fewer than 1,000 new infections. And finally, the mortality rate was 3.1 deaths per 100,000 people. All this data is from the year 2022 and the sources are here below in the slide. Okay. In terms of the model in Costa Rica, the main focus in Costa Rica has been to establish a sustainable model for HIV prevention and comprehensive care. This model relies heavily on the collaborative and synergistic efforts between civil society and state institutions. The main coordinating body for this goal is Conacida, which is the national council for coordinating the response to HIV in Costa Rica. Conacida brings together over 20 civil society organizations and 10 institutions. The main goal for Conacida is to ensure representation from these organizations as well. Key populations subtly involved in the decision-making process. We as a principal recipient of the Global Fund Grant in Costa Rica, we are working very closely with Conacida. And Conacida has been key in the implementation and all the setup of this program in the HIS-2 for the country. Okay. The need for an information system on HIV, I guess that it is very obvious, but you know that it's not always that clear that we really need an information system for this condition. In recent years, during the implementation of the Global Fund Grants in the country, we realized that care and response to HIV in Costa Rica are in general good shape, but having high quality data is still a challenge. So we need an information system in Costa Rica for several reasons first, because there is a pressing need for comprehensive data collection. While the Caja Constablecencia de Segurosocial provides significant public health services and collects data on prevention services through its EDU system, which is the digital medical record system, there is a need for a dedicated HIV information system to ensure comprehensive data collection. This system will allow for the aggregation and analysis of data beyond just prevention services, providing a more holistic view of the HIV epidemic in the country. Well, second, in terms of coordinating and governance, the Ministry of Health serves as the governing body for health in Costa Rica. And of course, having a dedicated HIV information system will facilitate coordinating and alignment with the ministry's goals and strategies, and also with the guidelines within our national strategic plans in HIV, and in a line, of course, with the international guidelines and commitments. And finally, for enhanced service delivery, of course, because civil society organizations plays a crucial role in linking key populations to health services. However, without an unified information system, there may be challenges in effectively coordinating these efforts and tracking the impact of their interventions. Implementing an HIV information system will provide CSOs with a platform to collect and ensure data enable better collaboration and enhancing service delivery to key populations. So the services provided by the CSOs in Costa Rica and this I guess that this is related to one of the questions in the other previous questions in the chat of community based systems. These services produce a lot of information more closely linked with the prevention cascade through self-report data and of course information related to the needs of people living with HIV. But this is a bit different than the information that is provided by the health systems itself, as you can imagine. So civil society organizations deliver a spectrum of services aimed at responding to HIV with the prevention CSOs offered tailored prevention packages, HIV testing services, and disseminate information on PrEP to key populations. In the sphere of care, because we also are working with organizations that are focused on care services, these organizations provide navigation support for initiating the treatment and fostering adherence to the treatment as well. They have peer support groups to people living with HIV and they collect some data on these services because these enhance the quality of the services they are providing to the users, to the people. Additionally, the CSOs recognize the importance of complementary services, including psychological assistance, socio-economic assistance, and the support on migration regularization. So in Costa Rica, the data has been collected by some rudimentary tools so far, such as Excel sheets, which is not bad, but of course it's not the same as having a strong system that could allow people, allow CSOs to aggregate data into and enhance the analysis. While this has strengthened the CSOs capacities, it is still insufficient for aggregating this data and producing this information at a higher level. It was not possible to standardize or unify the information and all of the analysis needed to be done was done by a very manual process. So why the HIS-2? Well, recognizing the need for a system, Costa Rica has undertaken a number of tasks and processes to create the conditions necessary to build an information system on HIV in the future. One of these processes involved the search for a unified system for civil society organization, which is where the HIS-2 comes into play. Sharon would use the process timeline to develop this HIS-2 module focused on the CSOs needs. So how did we start? The Global Fund offered technical assistance to the country during the first semester of 2022. The assistance began with an analysis of the country and the requirements of civil society organizations. Additionally, it involved defining governance, legal context and aspects to consider during the implementation phase. In our specific case, the development of the prototype was rapid but initiating implementation has taken some more time. This is because we need to register the system and the database with product, which is the public institution responsible for any information system containing personal data. The registration is a fundamental step to align this effort with local legislative requirements. So by the end of 2023, the technical assistance was finalized and the implementation phase began. And this implementation phase is still financed by the Global Fund, but it's more on our hands. I mean, it's something that has begun with the Conocida and the Ministry of Health, but we are implementing this phase in a more independent way. Of course, with the help of the university and his Columbia who has been collaborating with us. So in terms of the structure of the flow of the, I'm sorry, of the organizational units, when the prototype was created for the youth. I'm sorry, I heard that. Okay. Yeah, you can continue. Okay. Okay, thank you. Okay, when the prototype was created for the youth of CSOs, especially structure of the program was required because the CSOs provide. Thank you. The CSOs provide services in multiple geographical locations. So, therefore, if you wanted to visualize the data in the form of a map, we needed to combine the geographical variable with the CSOs scope. We created with the university admits, as you can see here, we have the province, which is more like the bigger level of our geographical division. Then we have the municipalities, and then we have each of the CSOs who are working within that municipality. But for instance, the CSO, why one can duplicate in each of the municipalities. This was a little tricky, but it was very useful for objectives of the model. In terms of the modular structure, the information flow is like very similar. It's based on what Stefano has shown before. And it's also based on our previous databases and systems. So in this case, it was natural for CSOs to use it. This allows for greater appropriation and smoother capacity building process. So we have four steps in the HIS for the CSOs here. We have the personal data, which includes the population identification and all the confidential data. Then we have the HIV prevention services that I explained before. They shall be care services and then the complementary services. Okay, so in synthesis, based on our experience, it is important to take into consideration some factors. The legal context, it is crucial to ensure that the system is tailored to align with the legal framework. The political negotiations, in our case, we had the opportunity to negotiate with the Ministry of Health and they granted us permission to install the system on the ministry server. So this marks the first instance in Costa Rica where civil society has an information system within an institutional web page. And additionally, we have agreed to cover from the Global Fund grant the server cost until June 2024, after which the ministry will take over demonstrating their support for this project, of course. In terms of the CSOs appropriation and appreciation of the system, developing data culture is essential so that every stakeholder recognizes the benefits of having high quality data and uses this to improve user services and analyze epidemic dynamics in the country, leading to data-driven decision-making processes. And the governance structure finally and potential interoperability. It's important to define who will be in charge of the system and responsible for its ongoing improvement. Regarding interoperability, our system currently does not share data with other health systems. However, Costa Rica's health sector is transitioning to using the Health 11-7, HL7 standard, which aligns with the HIS-2. We suggest that in the future, we may be able to share data more seamlessly with other health systems enhancing collaboration. So these are the critical factors to consider as we continue with the project in the HIS-2 in the country. So thank you very much. Muchas gracias. Yes, thank you for having me here. That's great. Thank you very much, Catarina, to describe the experience on Costa Rica was very nice and see as well how the civil society is very involved on every aspect of the HIV prevention and how you are supporting them. So thank you very much. And our last speaker from Ghana. Luckily, they will not be able to join us as there is an international down in the world country. So they will not be able to join, but we will try to share their presentation in the community of practice. And we try to answer the question that were present in the Zoom chat that in case there is anything that has not been answered, please feel free to highlight it now. In the chat, maybe you can use these last 15 minutes for any Q&A. In case as well, as was suggested in the beginning, you can use the community of practice as well to the community of practice to post your questions there. So, okay, I can see that just want to check if there are any other questions for the moment in the chat. So Stefano, while you're checking there, if it's worth just answering there were several questions about how to control duplicate patients. So I think that's something that comes up very often. So it might be a good one to just answer verbally here for those who may not have seen the chat. Absolutely, absolutely, absolutely. So this is a problem that has been there since a long time and there is not a gold standard solution. We are in the process to improve the possibility to avoid the creation of duplicates in the system, but as well to search for these duplicates in the system. So for the searching part is something that is going to be tackle on the next version of the HS2. But one of the suggestions we normally give to avoid to have this duplication is to have a unique tracker entity attributes. Okay, so for example, several unique tracker entity attributes to cross to to translate information from the same for the clients. For example, having HIV, UID is a unique. Okay, so it's kind of number of days donated to the patient. Or when we record a client's obligated to enter document can be national documents can be more there. Okay, so just to me to be able to make sure that when we are going to register. We avoid duplicates for the moment there is not a standard solutions on that we are working on this because it's very is a big constraint, especially when it comes to data quality. But for the moment, one of the technique can be exactly one of these one of two to have several unique mandatory TAs inside our our enrollment to avoid that then duplicates is going to be inevitable because in some implementation is impossible to have personal identifications or documentation from from the clients. But but still it's something that we are going we are continuing to work on the especially on the data quality side from the DHS to global perspective. Thanks, Stefano, but I asked you while you're while we are going through the some questions are still coming in about the utility and the use in different country context. So if you could just explain a little bit about the DHS to platform and how and where it can be deployed both in the health facility context and also in the community context. I think those are some other important questions. Absolutely, absolutely. So as I say in the beginning, which is true is an open source platform. So for example, we normally we are used to her, which is true for the user in the health, but it has been used for everything has been used for animal health for climate for logistics for education for whatever. So why I'm saying this because this is true is highly customizable. This is true can be adopted by MOH can be adopted by other organizations. We has the University of Oslo. We have this network of we don't have. Okay, but it exists. This is a very strong network of East groups that normally are the ones that are supporting MOH on the adoption of DHS to or as well other software. But mainly DHS to tackle specific either for the world HMI system or for specific programs. So of course, it's something that can be used for the programs either at the health facility, but as well the community level. We need to do something that I don't really mention at the beginning that the DHS to is working both web platform. So classically from the from laptop, but as well employed. So all the things that, for example, the configuration of the tracker that we have it in the web platform is available as well in Android. Okay, so when we need to do any type of community activities, maybe the best use is with the Android platform as well because enable the data collection in offline. Even when there is no internet. So the data collection is done offline and then update uploaded once there is once there is network. So of course, it's something that can be adopted and used in every every context. So we have example of very positive user case stories on the health facility to use it, but as well on community user of the of the platform. It can be the student HIV prevention was not really. I mean was explored, but all the part relatives for the analysis standards something that is coming is coming a lot right now. So in the HIV prevention is something that yes it's done it at the health facility levels, but how many activities are done at community level. So example of Costa Rica. How many things are done at community level or community door to door or in the industry. So this is true is very highly flexible and can be customized for every type of of use case. So yeah, it's possible can be adopted in the country. There are countries like I see here that is requesting for Uganda or Tanzania Tanzania there are we using HS2 since long times. Okay, and I right now I'm not sure if they are using it or not for HIV for HIV, I'll get data and pretty sure of yes. I don't know for for the tracker use case. But yes, it's something that is on the table need to take a consideration that the scaling up a tracker at country level. It demands a lot of efforts are a lot of a lot of willingness as well from the country to do this type of of implementation is happening. We have the example of Ghana that suddenly they they they were not able to join us today that they they scale up the tracker at country level. So, yeah, oh, sorry. Yeah, I should put my video on. I'm really sorry. And so, yeah, and I see it was a question about what is the stage of integration of HIV that the HS2. So, we will share later the presentation just want to, yeah, we will share later presentation you will see that the one of the presentation. The HS2 toolkit of HIV was based on HIV DACA. And metadata, almost all the metadata from the from the HS2 HIV toolkit was mapped with the data dictionary in the DACA. All the indicators for the DACA are present and can be calculated from the from the DHS to product. So, yeah, but we will then share the presentation so you can have more details there. Thanks, Stefano. I wonder if we can come to a cat arena to there are several questions and I see a discussion going on around vertical transmission and maybe you can also share some more information on the community based aspect in Costa Rica. So just want to give you a chance also to share some additional thoughts. Yes, thank you. And I'm sorry that I missed that data to share. Yes, the vertical transmission in Costa Rica is mostly controlled. I don't like to say that eliminated, but it's mostly controlled and, and, unfortunately, we have fewer than 100 cases. And in more specifically, we, we have grown 2020 to 2023 38 cases. So yes. And if you want, I can share the latest report from the Ministry of Health on the data. Yeah, that's great. And it's really a huge achievement. So close to Costa Rica. Thank you very much. Yeah. And then I think if we can take one last question here that I'm seeing that again has come up several times, Stefano to you is on the again, you know, I think it's coming back to the question of duplicates is to use if there's not a national ID. You know, how can we ensure that we're not entering the same person multiple times? Yeah, for this is really matter of using to triangulate informations. Okay, so we make sure that, for example, you can ask more demographic information about the provenance of the person close to the date of birth. And yeah, it's true that they in emergency settings, this can be very, this can be very challenging. And I think that we can try to limit the risk, but there was no, there will never be a zero risk. Because I think in emergency settings of big displays of populations that they will jump from a structure to another one. This is really inevitable. So on this case, it comes much more on the data quality part and cleaning up the database and make sure that there are no duplicates on that. But yeah, what they can really say for the moment is related to try to triangulate as much information as possible to try it, because we sometimes it's possible to have a kind of not protocols, but algorithm that based on the information that are shared create some codes that are that are going to be unique codes. So when this person comes and that's where provide the same type of answer to specifically questions based on demographic. This can be type of solution but always eliminate the risk of duplication. This is impossible in some in some settings. Okay, but no, in some settings almost all the settings. So really comes at the moment of cleaning up the data and be able to identify. So to identify duplicates is something that we have not really be that good. At the moment on the platform, but in the coming versions is something that everything already with data quality. We already have in the new version, the 41 version, specifically for aggregate data, everything that are outlier already part of the core platform. So it's something that for sure, we are going to continue to work on. Okay, and I think we have the last question to a cat arena. It's coming to ask what were the biggest challenges in implementing the age to in Costa Rica just so that the other colleagues who are here from ministries can think about that as they consider this tool. Yes, thank you. I was thinking that maybe the legal restrictions in terms of the protection of personal and sensitive data. Because of course is very important to protect people. But in Costa Rica is illegal to transfer sensitive data among institutions or organizations so we need to do the registering of the database and the system in an institution and this could make the process a bit bureaucratic but it still we are sure that this is something that is very important and we need to do it to align with the legislation and of course to protect people. Thank you so much. The final I think back to you. And just to from our side that WHO thank you again. To you, Stefano and the whole team at the University of Oslo to our colleagues in Paho, who helped develop the prevention one for in Spanish to a cat arena for her excellent presentation on the Costa Rica experience and apologies we didn't hear from Ghana. They've been using this for some time and have some nice work to share but perhaps another time. Stefano back to you. Thank you very much. So now, thank you very much and I just want to just kind of last sharing about the the DHS channel conference is going to take place from 10 to 13 June on Oslo. So if there is any possibility to join a positionally if not there is always the possibility to join a virtual so it's something that normally it's very rich man because you will see first of all from the from the global team all the news all the new application the new system but as well you can hear from the actual actual implementation actual use case and I really encourage you to register even if not the present online because the information shared there are extremely valuable and can be replicated to many politicians so I really want to thank you again for your participation in case you have any type of questions suggestion please use the community of practice as well. If you have any questions related with the HIV toolkit posted there and we are going to be able to answer you and support in case there is any need. So, thank you again to Shona and Katarina for the presentation the variable output and yes Shona. I was going to say one more thing I forgot our colleagues from global fund were unfortunately able unable to join today but again, if you have global fund grants that you're considering in the next several years they are certainly able to support this work so please do consider that. And aside from that we look forward to seeing more implementation of person centered data. That's great, that's great. So, thank you very much. Once again, and have a great day. Thank you. Thank you. Bye.