 Okay, good morning. Good afternoon, everyone. I see people are still trickling in. So it's right about two o'clock. So we'll go ahead and get started because we have a lot to cover today. And as some more people enter from the waiting room, I think they will be in here just in time. So we just wanted to thank Gaby again for helping with the support to this quarterly immunization webinar series. And this quarter we wanted to focus on a couple of WHO approved packages for using DHIS2 to strengthen disease surveillance implementations in countries. So today we're going to cover primarily the IDSR and the case-based disease surveillance tracker for vaccine preventable diseases. A bit of a quick background. Well, first let me remind you, there are some links in the chat that will take you to the community of practice. And so we'd like as much as possible people can answer, put their questions in the chat, or also go visit that COP post and can also add their questions there. So at the end of the presentation, we might have some time to take some questions live and the ones that we haven't been able to answer, we will follow up in that COP post to make sure that they are addressed. So to give a little bit of background on these DHIS2 packages, what is a package? It's a program-specific module that we've designed for DHIS2 and it can be used either as a reference just to understand how DHIS2 can be configured for a certain use case. But it's also installable and it makes it possible for countries with their own DHIS2-based systems to install this package and then customize it within their own national country system. So the packages contain several different components that we have defined based on guidance from a global group of subject matter experts. And for this group of packages, we worked very closely with a WHO convened group of subject matter experts across USADC, WHO, World Health Emergencies, as well as partners at regional office level, including strong support from WHO AFRO on the design and content of these packages. Now the components, these conclude electronic representations of the different data variables that are recommended for a collection, grouping these together into data collection forms. We've pre-configured indicators based on these variables and based on those standard definitions for indicators related to the disease surveillance. And there was also, we've also designed a number of dashboards, analytical items, data outputs, such as charts, maps and tables that countries can use to sort of automate the analysis. And they're also able to go ahead and customize those types of dashboards and data outputs. So we'll show some examples of these. So we also believe that the packages really represent what we as the University of Oslo, HIST Center would recommend as good design practices. And these also can, of course, be customized to meet local workflows and requirements within implementation. So in some, these packages are basically a starter kit. And then countries that are able to take these and then continue to adapt and customize and refine through their local requirements. You're going to see a couple of terms being referenced in this webinar today. So I'll quickly explain the difference between aggregate and trucker. So in the DHIs2 data model, one key data model is the aggregate, which is collecting these summary counts of information for a predefined period. And so in this use case, you'll see that typically the IDSR data is collected weekly. And this data is really summarizing counts of a very key information across a number of diseases, such as the number of suspected cases that was presenting at the facility during that period, the confirmed cases that might be reported by the lab or by the facility, and things like the number of deaths among the suspected cases. Then our tracker data model, of course, it's a longitudinal individual level based data model. So it allows you to actually enter the case and track them over time from presenting as a suspected case at the facility, linking to their laboratory information, the laboratory final results, and then lastly, that classification of that case. So following that entire case through the continuum. And then of course, we'll talk a little bit about how it's possible to use those kinds of counts of cases in the tracker and also compare that to the weekly reporting. So for today's agenda, we will go a little bit in depth into the IDSR package. I was joined by my colleague, Sharjeet Dutta, to help with these demos on the IDSR package, as well as the case based tracker for vaccine preventable diseases. And then we are also joined by our HISP colleagues. So Maurice Jules from HISP Rwanda will share some of the piloting experience of these packages in Rwanda. And our colleagues, Akiba Wallisane from HISP West and Central Africa, who was the lead designer on this VPD case based tracker, is also going to share some of the implementation lessons learned in Mali and Togo. And then lastly, we will wrap up the webinar with some next steps and review, some support mechanisms, if there's any ministries of health, EPI, MLH focal points in the audience, sharing just a bit of reminder around how to use some of the available Gavi grants and linking up with his groups to make these TA requests. So to begin, I will just review a couple of the main features of the integrated disease surveillance and response package. And then I will hand over to Sharjeet to take us through the demo. So this package, the IDSR, it's modeled very closely around the IDSR mechanisms that are promoted primarily in the WHO Afro region. But many other regions have similar mechanisms for capturing weekly aggregated reporting, primarily from facilities. So this package goes a bit hand in hand with the tracker. We're able to preconfigure these disease thresholds and outbreak alerts. So we'll show the functionality that allows that. And of course, it's customizable. So we have preconfigured this sort of threshold. And then when the country takes and adapts this, they can decide what types of case thresholds actually make sense for their context. And then also be able to configure what can be done for setting notifications via email via SMS or through the DHIs to messaging system. This package currently covers 15 typically notifiable diseases. And so that's what's contained in the package. And then countries might have their own lists of notifiable diseases that are contained in this type of weekly reporting. And so they can adapt and customize, expand, or even remove some of these diseases depending on their context. The weekly aggregate data sets, we will show you a little bit around how we've designed these for facility reporting and also for lab reporting on the confirmed cases and how this might be changed depending on what is the workflow in the country. So there are some components that can be mixed and matched. And we have given a couple examples of how this might work based on learning from country examples where at least more than 25 countries have been using DHIs to for this type of use case to date. And lastly, we'll review some of the flexible configuration and the predefined dashboards. So the dashboards that come with the package and then a few examples of what can be done to actually expand those data visualizations for data use needs. One example of our flexible configuration, a number of diseases they've been disaggregated for age bands and some of them have not. And so we have actually introduced a custom form design into into DHIs too. And then the diseases, these can be added and also the configuration modified based on local requirements. So this is a little bit to show how an AFP, if you are able to capture that age disaggregation, you would be able to see zero to four years, five and above and also the total. If the country on their paper-based forms, data collection tools are not able to disaggregate, then they could simply have the total number of confirmed cases and use that for the disease thresholds and alerts. The outbreak alerts, so these include the threshold placeholders for suspected cases and outbreaks. So for example, in neonatal tetanus, the threshold placeholder that we've placed is one suspected case. And then the country can actually take that and decide maybe they want it to be higher than one. And based on that, we can configure these validation rules to actually produce. I won't go into this too much because I think Shurji is just going to cover it in the demo. But we do have sort of these notification templates. And then these templates might also be customized within the country to decide what it is that you want to say when you alert your users and also to decide how is it that you want to alert your users. Is it through email? Is it by configuring an SMS gateway or other mechanisms? This is an example of some of the predefined dashboards that we worked through based on sort of the core global requirements and through the WHO AFRO system. So for each disease, we do typically have some representations in terms of giving the districts that are in outbreak mode, being able to visualize those on a map. And then also on the case-based side, starting to look at some examples around epi curves and also starting to get down into that outbreak mode. You know, if there are a lot of measles cases happening, how can we sort of visualize these on various levels? So for example, how many doses of a vaccine are these cases seeing? So this is really quite in depth in terms of dashboards. And these are just really a starting point for where the country can continue to modify and expand. Just a small note is to say that the law ministry of health, they have generously given us access to use their org unit hierarchy to create some of these maps for demo purposes. But just as a reminder, this data is in fact, it's artificial. This does not actually represent the country situation in Laos right now. And then lastly, we will go through a couple examples of how you can customize these additional data visualizations. So here is taking the example of the Maps app and actually being able to visualize these kinds of outbreaks that are happening in various districts over time. We've also given you sort of an example of your traditional epi curve. So looking at cholera with the suspected cases and deaths and what this visualization might look like in an outbreak scenario. So without further ado, I will hand over to my colleague Sharijit to go a bit in more depth on the IDSR configuration, and he'll also take you through the CBS package. So I will stop my sharing now and hand over to you. Thank you, Sharijit. Thanks, Rebecca. All right. So I want to start by going over the components of the IDSR package that Rebecca had spoken about. And we'll just start kind of from the beginning. So we'll start with the data entry components. And she mentioned some differentiation between these different data sets that we have on offer. So let's just talk about that a little bit just so you can get a better understanding in terms of what that design is for. So I'll just have a look here. So we have these three data sets here. IDSR suspected and deaths. IDSR suspected confirmed cases and deaths and IDSR aggregate lab weekly report. And basically, they're kind of meant to mix and match various components based on the maturity of the implementation potentially where you guys are or even potentially who you want to have access to enter this information. So if I just open this first one up here, suspected and deaths, it's going to have a list basically of all the different diseases that we are collecting aggregate data for. And if I scroll down, you'll just see that these different diseases that we mentioned in that slide there, they're all present here and they're desegregated by age. And basically, it's all built the same way for each disease. You're looking at the number of suspected cases along with the number of deaths and making this comparison within this particular data set. You'll notice there's nothing about confirmed cases in this particular data set itself. That is reserved for other components and I'll go over that in a moment. All right. So everything is kind of designed the same way for these and you will see some of these are not desegregated as Rebecca had mentioned. And this can obviously be changed based on what you need. But this is completely flexible in terms of how you want it to set up. But the whole idea is to provide some kind of starting point, I think. And then you can kind of go from there based on your own requirements. All right. So if I just look at the other data set here, so here was suspected and deaths. If I look at the suspected confirmed and deaths, now pay attention real quickly, you'll see it updates rather quickly. But then there's more variables or more fields here for me to fill out. This includes in this case, the confirmed cases where the previous data set did not. So depending on the maturity of your implementation, if you are able to collect this type of information, and if you want to collect it all at once, that's kind of dependent upon your own implementation status. And if I scroll through, we'll see this kind of pattern emerge for all of the diseases. So they're all set up the same way within the confines of this data set. So now we see, for example, the number of suspected cases, sandwiched process, confirmed cases, and then deaths. So we were seeing the suspected cases along with the deaths previously. And now we're adding this additional component where we're looking at the number of samples or just simply the number of confirmed cases for a particular disease within that week. And then the third one we have is this aggregate lab weekly report. And this is just basically the confirmed case data separated out from the suspected cases and the deaths. So it's what we would have seen on that integrated data set, the same types of fields. But now it's just segmented out. And the reasoning behind this is there's a couple of reasons, perhaps. Maybe you start with suspected cases and deaths, and then you want to add this component later on. Maybe you only want to have lab staff be able to edit this data. And the easiest way to do that is just to segment this off and then only allow access to lab staff to edit this data. You could share this data with a wider audience, but that way your suspected cases and your deaths are entering maybe by a separate set of team members. And then your lab data would be entered by lab staff, for example, if you wanted to segment out that access. So we've just set up a couple kind of reference implementations of these data sets to give you an idea potentially of how to get started. So it allows you to kind of mix and match components or at least give you an idea even for yourself if you just want to use it as reference to think about how you might want to put this together in your own implementation. So depending on how mature you are in terms of where you are in your data collection and in terms of maybe who you want access, who you want to have, edit access in particular to enter new data values in these different data sets. And you might be able to think of other ways that might be useful to you in terms of segmenting this off or maybe just putting it all together. It just kind of depends on what you need at the time. But we're essentially looking at complimenting all of the data together for suspected cases, confirmed cases, and deaths within the confines of these various data sets. It's just that there's different ways you might want to set these up depending on what you're doing in your implementation at the time. So I'll just go over some of the kind of properties of these data entry forms as we fill them in. So Rebecca also mentioned there's quite a bit of validation and notifications and things of that nature. So we can just try to do some quick validation, for example, if we compare the number of confirmed cases in a week with let's say the number of suspected cases. And I'll just quickly do a quick check on this. All right. And we'll get a result real quickly. And this applies directly during the point of data entry. We can see here that it's giving me an error because the amount of confirmed cases should be less than or equal to the number of suspected cases for the week. Now there's a number of other validation rules. Validation rules are set up for each disease. So as you're entering data, basically, it's going to go ahead and validate all of the various kind of components that are there. And when you review this, you might see that you might need to add something perhaps. But quite a bit is that it is available from the start at least to give you a sense of what might need to be there when you're actually doing this data entry for the user. And I will note that also this is also compatible on Android. So I'm just going to pull this up here. So if I have a look at the same data set that I have open, which is right now I have the suspected confirmed and deaths. This is an aggregate data set and I'll just open one up that's already been filled in. We can see that this is just basically the configuration looks a little bit different. I will show you another example of a way it's set up on the Android device. And you're basically just able to enter this data. The nice thing about Android is that it is fully, it works fully offline. So this data is actually stored online device. And then I can synchronize it back to this web interface when I have internet. Now, all the validation is also supported on the Android device. So if I just run a quick check here on this, you'll see I get some errors returned. And I'm able to kind of perform similar checks as I am on the web interface. So all of this is also supported on Android. And you can have all the same type of data, same type of information collected throughout these various data sets that are part of this IDSR package. And just to quickly note that, you know, the Android setup is also can be different. So here's a different setup than what we saw in the previous screen. So in the previous screen, everything was just in the long list. Here now at the top I have all of my diseases basically separated out into sections. So if I select one of the diseases, it'll bring up the relevant information related to that disease and I can enter my data. Okay, so there's also different ways we can set this up to work on Android. And that is fully compatible with all of the various kind of data entry modules that we have created for this package. All right, so on top of the validation, just the kind of routine validation that we've seen here, for example, comparing suspected with confirmed, which is what I kind of entered here. Okay, we can also do a comparison of thresholds, and that might cover a larger period of time depending on the threshold itself. So Rebecca mentioned some, you know, quite simple examples if you have one case, then that triggers a notification potentially or an alert. And, you know, we also have, you know, more sophisticated thresholds based on the criteria that's been defined. So you can get this to run automatically. And typically, that's what's done. I'm just going to trigger it manually for the sake of demonstration purposes, but keep in mind that, you know, everything I'm showing can basically be run on an automatic process. So you can check these, if there are any thresholds that have been exceeded, you know, on a basis based on what you define. And you are also able to receive any of the notifications that I will be showing you. You're also able to receive those automatically without, you know, any manual intervention in the system. Okay, so I'm just going to trigger this for a period. Let's just run it, let's say here for a particular period. And what you can do is, with all of this, I mean, you can just, you can check the kind of simplistic logical rules for data entry that we saw, like we're confirmed cases was larger than suspected cases. And you can also check the various thresholds that you have set up in your system as well. And you can run these as a batch operation. So you can look, for example, for the notifications at all, for all the diseases at once. So if you want to check, you know, measles, cholera, you know, tetanus, if you want to check all of them at once, you can. You can also run them individually for each disease as an example. So I'm just going to start with a simple example. Let's just check one of the diseases. And I'll check it for measles. And I'll also get this descent notification if there is anything detected. So I'll just run this all validated. Okay. And we see in this case that there is a threshold that has been exceeded. And I'll just pull up the details on that. Okay. So the number of confirmed measles cases within the district over a 30 day period is three or more. Okay. So now there is a confirmed outbreak within this particular district that has been identified on the left side. All right. So once again, I'm manually doing this, but this can be automated, this whole process. And you'll be able to receive this, you'll be able to check this automatically and then subsequently receive a notification if it triggers, if the threshold is exceeded. So you are able to receive these thresholds in a couple of different ways, these alerts, sorry, when they are exceeded. The first is a DHS2 messaging service. And I think for a lot of people, it's not necessarily as useful as it could be in practice. You have to be logged into DHS2 in order to receive this message. And the whole purpose is to kind of instigate someone to check the DHS2 itself. So this might not be as useful in practice. Now there are other methods, as Rebecca mentioned. So for example, you can also have this sent out to your email. You can see this is the same message that was just sent out to me. I just received it. And this gets automatically sent out as part of that process of basically checking those various notifications and various thresholds within your system. And lastly, you could also send it out as an SMS. Now, I don't have that set up to demonstrate, but we do have some guidelines available and I'm happy to share those with you if that's something you're interested in doing. But you can send out these messages and notifications when thresholds are exceeded via an SMS message as well. All right. So we've gone over some of the data entry interface, why it's set up that way, some of the validation alerts and the notifications that we can receive in response to thresholds. The last thing I just wanted to cover was the dashboards for this particular package. So what we've done is basically create example dashboards for each of the diseases that are collected as part of this IDSR package. We also have dashboards that compare different diseases as an example. So I'll show you one called the IDSR overview. This just allows me to compare a number of different diseases together on the same dashboard. We can see some just click measures of quality of basically reporting rate and timeliness spread over weeks within the different locations that we're getting data from. If we scroll down a bit, we'll see quite a large table looking at the cases, alerts and outbreaks for all diseases last week and we'll also see it for the year. Now, these tables are quite large, obviously, and you can expand these directly from the dashboard. Just click on this action button here in the corner. You can go to the full screen. This allows me to bring it up. I've not exited the dashboard at this stage, still on the dashboard, but I'm able to expand this and look at this in a bit more detail. I can see, for example, there's quite a few Shigella cases and quite a few districts that are an alert compared to some of the other diseases that are present. And if I keep scrolling over, I'll see something similar for measles as well. And you can think of other ways where you might want to potentially compare some of the diseases that are collected as part of this package. So I'll take you then to one of these specific disease-specific dashboards just to give you an overview of what is available as a reference. Now, once again, these are a starting point to give you an idea of what's possible. You can add to these different visualization types or you can think of other indicators or pieces of data that you might want to review on these dashboards. Now, the way these dashboards are set up within this IDSR package, all the dashboards are basically the same setup, but then showing the disease, replacing the disease that's here. So in this case, I'm showing you measles, but the dashboard for Shigella or for neonatal tetanus or for other diseases, it would have the same components, just showing the information for that particular disease instead of measles. So what we see in the first part of this are the number of districts in suspected outbreaks within the last couple of weeks. And then on this map, we see the direct last week information for the districts that are in a suspected outbreak of measles. If we scroll down, we'll see the number of districts in a confirmed outbreak of measles. So this is where maybe lab information has been reported and we see the number of confirmed cases triggering that outbreak notification. We also see the total for the year and this gives you an idea kind of of the geographic kind of reach of the outbreak overall in the country. And just to note that these items are interactive on the dashboard. So if I scroll over one of the districts, I'm able to see number of districts basically. And I can also, there's a legend for each of these items as well. This red color basically for this map is just indicating that the district is an outbreak. But there are more types of visualizations that show more information. For example, there's an incidence rates visualization of a map here. And if I scroll over that, I'll see the different incidence rates and the colors that correspond to that incidence rate on the legend. And just like for any of the other items, like when I expanded that table in the previous example on that overview, I can expand any of these clicking on the action button here and going to be full screen. And I can investigate that further. It's completely interactive when I'm viewing these items on the dashboard. And you'll see some kind of more traditional outputs as well. So a distribution of cases and deaths, a simple epi curve, as well as in tabular format within the pivot table. And then a comparison of cases this year and last year to give you a better sense of what's occurring. And this is showing you by month, but you could do it by week or by another period if you were interested in doing so, or maybe over a couple more years of time instead of two years, just depending on your needs. All right, so Rebecca did note that you can add additional visualizations to this. So anything you can make within these tools, just opening up one that I've made as an example. So you could add any of these items that you make within the various data visualization tools and add those to the dashboards based on your own requirements, based on your own needs. Here's the timeline map that we showed. If you were to add a map like this, it would be interactive as well. You could play back the timeline on the dashboard itself. So just depending on what you need to do, the dashboard does serve as a nice reference. I think it's got quite a bit of good information in particular in identifying the areas that are in outbreak, which maybe you might be a bit more challenging to create those outputs. But then you could think of other outputs you could potentially add to your own configuration based on your own needs and requirements. All right, so that was just a quick overview of the IDSR package. And I'll hand it over to Rebecca to continue the discussion and I'm happy to answer any questions about this either in the chat or on the community practice as well. Thank you, Shira Jeet. So I will pull up the slides again. So the case-based tracker complements a lot of what Shira Jeet has shown. And so we know that it can be quite challenging to always scale up the case-based tracking down to facility level and also to be able to get really a completeness of case-based surveillance, especially when there are outbreaks, and it might be hard to keep up on on the data entry. So we'll talk a little bit later about how we see these packages kind of fitting together. But kind of considering now that you have in your mind the quite basic, many countries have scaled this up at national scale for IDSR weekly reporting and the types of analyses and outbreak alerts that you can get with that package. Now we'll kind of move down one level or even up one level if you think in terms of system maturity around how kind of a DHIS2 tracker can be introduced as an integrated case-based surveillance tool. So when I say integrated, what we mean here is that we've actually combined the various data variables, data entry points that need to be captured for nine different diseases within the same tracker program. And so sometimes they actually share these variables and sometimes the variables are quite specific to whatever it is that's the suspected case. And so we've used program rules to actually kind of create a dynamic data entry experience that you can use the single tracker program for all of these nine diseases and then through those program rules you're going to get the data variables that you want and that are needed for those specific diseases. So in a sense you can think of it as combining nine different paper data entry forms into one tracker program and adding quite a bit of logic to support that workflow. So these variables, they were combined and consolidated from the WHO Health Emergencies Program which was coordinated by the meningitis team lead there as well as with WHO AFRO. So that's where this configuration is essentially representing those recommended standards at WHO global and regional level for this type of disease surveillance. These variables also match very, very closely exactly I would say. The typical epi info system that many countries in AFRO use to actually capture that VPD case-based data, typically at a central level. So the advantage here is designing DHAs to track a program that can facilitate this decentralized data entry. It's being done on the web. We'll share a little more some of the aspects around automating data exchange but we worked very closely with these partners who had designed epi info for that kind of centralized data flow to present DHAs to trackers essentially an alternative that can link to the data reporting requirements through WHO AFRO. So this package also contains a number of predefined dashboards and again these are really just the starting point for the different types of analyses that you can do when you have this really robust granular case-based data. And then lastly this package itself contains and what we mean by that is you can take the IDSR package individually alone or you can take the VPD case-based case-based surveillance package individually alone or you can take them together. So these are kind of represented as two packages or two modules and then the country can maybe start with IDSR for example and then at some point they would like to bring the VPD case-based tracker into their system so that's also possible. So for collecting the case-based data in real time so as I mentioned that that typical centralized epi info system some challenges with that system is that it was not web-based and it's not really able to be decentralized to where the initial data collection is happening. So this DHAs to tracker program allows you to capture those same data variables. If in the beginning this can only be done in a centralized way so you know waiting a little bit for those paper reports to get sent upwards and then entered it's perfectly suitable for that workflow but the advantage here is that it's also designed for a decentralized workflow so that as different users at facility level at lab level among district level surveillance officers are trained in being able to do the data entry and they are also you know equipped to have infrastructure and connectivity they can actually start to enter this data as soon as they are collecting it and that's what really gets us to this more real-time data. So we'll show this a little further through the demo but just give an idea of how this works. If you're starting with the case registration that's typically happening at the health facility when a suspected case shows up and there's a first part of that case report form where they capture then the clinical examination the clinical diagnosis and then they might go ahead and submit a laboratory request. So if this is being entered into DHAs too at that facility level you're already starting to get that real-time data that you know there is a suspected case being reported and you can start to monitor that case through the next set of the workflow which is of course to have the laboratory results attached to that and then a final classification of that case. So typically almost all of the diseases have a lab component the one exception is neonatal tetanus because there is not a laboratory diagnostic for that disease but most of these diseases essentially allow you to screen and identify that suspected case whether they're hospitalized or not hospitalized and to begin filling out those that case notification and reporting form in DHAs too. So then that can be submitted to a lab it could be a different set of users at the district regional or even at a national reference laboratory level who have access just to do the data entry on that lab request and of course that is now being linked in the system with the case records so we know that this is a challenge across country systems to be able to link lab results with that case report and this is what the tracker data model allows us to do. Then some more details might be filled in in the case notification and reporting form at some point there's likely someone responsible for assigning that final classification based on the clinical data as well as the laboratory data and then these can be sent upwards to the national level and finally the case can be completed in DHAs too once it has had all of those stages so throughout this process as the data is entered different types of these analytics will also be displayed and demonstrated onto the dashboards. So to give a bit of a review of this case-based data so this does support in a sense what some people might consider a line list so being able to kind of capture this data and at some point possibly even push it back out of DHAs too where you know you have all of the data more or less contained in a row and so this is what it looks like where you'd have your your clinical exam, the lab request data, some specimen tracking, the final lab results and the final classification. You can actually take all of this data that's been captured through all of those different stages and often buy different users and actually present it in this kind of line list so they are actually easily able to relate all of this data to that case itself so this is really helpful particularly for enhanced analysis and also being able to take some of these data out and actually use it in more statistical software systems among epidemiologists. We're also able to create individual level outputs so this is an example of being able to kind of display some of those key characteristics around cases so in this one it's just looking at the breakdown by sex so starting to understand at actually quite a granular level you know what kinds of populations that in this district level or even down to facility level what are the risk groups here you know why are there such a high majority of females being affected some districts versus others so these types of outputs can be quite useful as they're analyzing this outbreak and trying to understand what response measures to take. So with that I will let sure take us through the demo so thank you. Great thanks Rebecca. Okay. All right so we went over the any start package let's go over the case-based surveillance package in this demo so I'm going to start the process just by registering a new case when you're working with this type of data this tracker data this is always kind of the first step in the workflow so we create a new case and then all the other processes that we spoke about are going to be tied uniquely to the case that we are creating so I'll just go ahead and register a new case and you know because all of this is integrated so we'll see the registration page here right now I'm just going to change some of the dates so we can walk through the workflow and there are different ways to do this as Rebecca had mentioned some of it is maybe you're collecting data in real time and in that scenario you might have different people entering data you know and accessing different parts of the program at different times you could then also have you know maybe forms or something sent up and this data entered retrospectively as well in this scenario I'm just you know because I'm only one person I'm just going to enter all the data but I will kind of talk about where it might be useful to have inputs from others and you know what that might look like if other people were accessing things in real time and maybe you know only accessing a subset of the information that was present and being able to update and edit that so others can also view it later on now as this is an integrated system so here's this field clinical diagnosis at the top it's one of the first fields it is kind of the most important field in this configuration because the idea is basically when we select one of these diseases here it's going to then reflect or update our configuration so we only see information related to the particular disease that we have selected so for example if I were to select yellow fever all the other inputs on for example vaccination history or the types of lab samples that I would collect or other details would be related to yellow fever and I will show an example of this later on you know so if I select measles here then similarly you know what I will see in terms of the inputs that I can enter are related directly to the measles program okay so I will show an example of that so you can get a better look at it's kind of hard to see just from this page itself all right now in Tracker we also have validation basic validation while you're entering the data in addition to some of the alerts and thresholds which I will show so the first one is just I'm going to show is for the epic number now basically what I'm trying to kind of demonstrate here is that if you have some kind of ID embedded within your system you can create a verification to at least check if the pattern is correctly followed so I'll just enter in an example and what what it's going to do is it's going to tell me that the the number should follow this specific format right so it's it's just trying to verify this ID and in particular if these IDs are important for identifying your case it is a kind of a nice thing to kind of implement in your system to make sure that you know at least the IDs are following the basic pattern that you set and that way you know you won't get a lot of you know IDs that maybe are not following your pattern and then are not useful for helping you find your case later on when you're going to update it especially if you're entering data in real time all right so I'll just enter that in correctly this time then we have some other information that basically allows us to establish you know who our case is we have their given name and their their family name okay their date of birth there is some additional information on the date of birth if it is unknown if you click on this tick box here you're just able to manually enter in the date of birth and age and years if you know their date of birth however then you can calculate their age and years months etc based on the date of birth itself we have a field for sex here I'll just keep entering in some some information and then we can you know enter in some other kind of characteristics of this person based upon where they're located for example and we can also enter or use our current hierarchy to also you know help us understand parts of their location for example the district and the province for example and this will just pull up our hierarchy and allow us to choose from that hierarchy directly then there's some other information here as well their phone number if they're a young person maybe you would also want some information on on their parents as well okay so we would just enter in all this information for the person along with the the date of notification in this case okay you know just set it a couple days back and then we can continue with the rest of the process right this allows us to establish our unique case and then you know any other part of this workflow related to this particular case you would search for them and update their record basically whether we were entering data in real time or retrospectively so click on save and continue okay and this will bring us to kind of the main data entry interface for this case and we can see right now we only have two parts of this program available the diagnostic and clinical information as well as the final classification and I'll discuss in a moment you know why that is the case right so I'll just pick a date from which I'm entering the data and we'll open up the program and what we'll see as we go through this okay I selected measles as my initial diagnosis so all the fields that I see are related to measles so this includes vaccination status for example if I click on the type of vaccine last received I see vaccines related to measles if I look at the signs and symptoms they're related to measles and then if I as I go through the remainder of the program we'll also see that the inputs I can select are directly related to that disease that I selected during the initial diagnosis within that field okay so this location information at the top this allows you to map your cases map the actual location of the cases I'll show an example of that visualization type later on I think it was also in the presentation we then we have some dates as well the date of the onset of symptoms for example so there is validation as we enter this in so for example if I select the date of onset that's after my date of data entry here it's not going to you know it's going to give me a message telling me that maybe I should have a look at that and fix that so similar to aggregate data we also have this validation occurring as we're entering the data for our tracker information okay so I'll switch the state two or three days before the came facility and there is then rules to also you know show and hide various components of the data entry so for example if I were to select inpatient I'll see this field for data of admission that's hidden if I select outpatient you know that's not a required field so it's just kind of hidden okay now what happens when I select whether or not a specimen was collected or not so I'll say yes so that was rather quick but you'll see that on the left side I now have the information on the laboratory information right so the request the specimen tracking and the laboratory result and you know that's not shown if a specimen is not collected for all these reasons I think right so we're able to you know and you can think about this in terms of just holistically for your own programs you know whether or not you want to show or hide specific parts of your workflow depending on inputs related to your data entry right some of it might not be relevant given a certain context and in that case you could hide it and then you know you could have it shown in response to you know the correct input being being put into your data entry form right so we'll just continue on with some of the other fields the vaccination status the type of vaccine received and the date of their last vaccination maybe with some time back okay and then some of the signs and symptoms and once again these signs and symptoms they will change depending on the disease that I selected my initial diagnosis so let's select some related symptoms here okay and I'll just fill in some of that information we can also enter in some information on the notification um let's say it was notified on the same day and then we have the patient outcome and the patient outcome in this case is at the time that you see the person this might change over time if they're admitted or or you know under some other scenario so you know where you put this is kind of dependent on on what where you when you want to classify them but you know if I can say they're alive at the time that I seen them for example or you know they died or whatever happened you're able to do that okay so so there is quite a bit of information in this first part of the workflow but I can just go ahead and complete that and continue on with the next part so then we can look at the lab request okay so this this process that I'm looking at this first process this diagnostic and clinical information it's only done once right we just assess the patient and then we move on to the next step if I look at the lab request so let's say it was made on the same day that I saw this patient there's just a handful of fields right this is just to kind of initiate that initial lab request so we can you know make a request for this particular person and here you'll see the types of specimens that are available once again this is a filtered list so if we were looking at a different disease then you would see different options here and if you are collecting multiple specimens you are able to enter multiple requests at this particular stage in the workflow so if I could add another one for example and I could save that and then I could subsequently enter in more information on the the specimen that I've collected so maybe this time I collect different types of specimen okay and I can add as many requests as required based on the number of specimens that I've collected so the same thing is true for the specimen tracking stage so if I have a look at this workflow and open it up and this is going to track each of the specimens that I've sent for testing basically right so I'll say these are being sent to the national lab if you're entering my first specimen ID let's say it's adequate and say it was received okay and in this particular case you know right now as I mentioned I'm going through and entering all this data but maybe you want someone specific to the lab for example to access this specimen tracking stage and maybe same for the lab result and they're the only ones who could enter in the information for this and that is possible so if you just want to segment this off and say okay only lab staff you know other staff can see all the data but only lab staff can enter the data for the specimen tracking and the laboratory results parts of this workflow then that can be done if you want to segment this off and allow different people to kind of have specific access to your program in real time as you enter this data you can also assign this to your lab staff so if you send the request and then you also want to say okay there's a specific person at that lab I want them to fill this information then they could filter out basically the cases that they would need to check up on in order to you know update those pieces of information for those particular cases so while I am running this all as a kind of retrospective entry as one person you are able to specify make more specific requirements in terms of you know how this is segmented off who has access to enter data in different parts of this program you know how they get notified about the entry for this information and how they're able to filter out cases that are related to their immediate needs or workflow okay now for the specimen tracking stage it works very similar to the lab result it's just a handful of information and we're able to add as many kind of specimens as we're tracking as there are available right so I can do that again you can see it's the same type of setup same exact information I'm just entering it for my next sample and I can enter in the related data okay so the same is true for the lab result so I'll enter in that information as well and the lab result you will typically see a bit more information compared to the other pieces of the workflow as well so it's the laboratory request specimen tracking very short pieces not so much data just kind of tracking the status of the lab sample that's been sent but then you will see quite a bit more information in the lab result and once again this is disease specific so you'll see here for example various tests that are being around our related or test results are related to measles in this case if I were selecting another disease then I would see that information related to that particular disease as well okay so we'll just kind of kind of follow the information workflow here and once again because you're sending multiple samples or if you are sending multiple samples you can enter more than one lab result right so I'm doing it for one specific sample at this point in time but you know if you have more than one sample you can enter several lab lab results in response to those various samples that you are collecting so we can say for example this person has measles and no rebel if there is some other test that you performed there is a field here for that now of course if there are other tests that you are using you might want to consider adding that to the core part of your configuration this is completely modifiable as well just like the rest of the package so we'll just kind of finalize this workflow here so once again if I wanted to add the information or data on that next sample I could do that you know so we could see here I could enter more than one lab result and it'll load up the form and it's all the same information and I would just enter in the same well whichever data I needed to for my next sample that I've collected okay so last part the last component of this is our final classification and once again you know I'm doing this all together but in particular you know the lab component and maybe even the final classification you know you might have a team that reviews the results of the investigation or reviews the details of the case and determines the final classification of this and if you only want them to be the ones to be able to edit this component then that is possible right especially if you're doing this in real time you might have different people accessing this at different times so just depending on your workflow depending on how things are set up you know you could have different people accessing the program and kind of working on their specific part of the program at any given time and you know you can also have provide access to others to just view this information and not be able to edit it so maybe you need to share the information with a wider audience but maybe that wider audience should only be able to view the data and not edit the data and there's only a small subset of individuals who are able to subsequently edit this data all right so I'll just classify the case here I'm just to give you a sense of what's been done so that's just kind of a quick run-through of the various components of the package and kind of the workflow that's involved with this package so you're with the with the kind of case-based surveillance data entry in particular just keep in mind as a reminder this clinical diagnosis informs the rest of the package how to kind of set itself up and what information to show within these different stages of the program within these different components of the workflow. And just to kind of demonstrate that so here's in this particular case this person the initial diagnosis was selected for meningitis so we could compare some of the kind of core components of data entry you can see here for example the vaccination status it's pulling in different types of vaccination information it's quite a bit different from what we saw when measles was selected as our initial diagnosis and we'll also see for our signs and symptoms right there are different symptoms listed here it's all related to that initial diagnosis that was selected if I were to go through the different components of the program and we would see something similar right where the lab components and the final classification etc but all be related to the clinical diagnosis that I have that I have initially selected. All right and just like the aggregate components of the package this is also completely compatible with android and in fact I'll just pull up the case that I have open in the web just so we can compare so I've downloaded this person to my device basically and you'll see all the same types of information that I entered on this individual you'll see the left side of my screen kind of is the the web interface the open android window is this person on the android device and they're cross compatible in terms of you know all the same information is collected you're able to download cases to the android device you're also able to enter cases on the android device and send it to the server so you know everyone has access to that particular case. Now in particular with tracker because with aggregate you can kind of get away with working offline for small periods of time but for for tracker you know android is really the the most robust method to work offline you know using the web you can't really work offline using tracker so if there's a need to work offline for any period of time for tracker for collecting this type of case-based data then the android device allows for that functionality and what happens is you know as you register new cases they're basically stored on your device and you're then able to subsequently synchronize this with the online system and you know you can see here you know all the kind of sections this is the first kind of workflow of this program the diagnostic and clinical information so it contains all the same sections that we've gone through the admission and clinical information vaccination status signs and symptoms notification information and outcome you know I can open this up this already has some data here and all that same information is there and available for the user to interact with. Now if I were to just to kind of verify that this is the case if I were to kind of enter a new case okay so what I'm doing now I'm just adding a new case on the android device and what happens is when I do this it just gets stored on the device itself there's synchronization periods that you can set up if you're regularly connected so it sends the data kind of automatically if you're offline for a longer period of time then you can also send in the data manually as well so I'll just select some information here so for example we could select meningitis just entering some more of the kind of required information that's needed and you'll see how the interaction is a little bit different on the android device obviously it's meant for a touch interface now so just enroll this person in this particular location on the state and save sorry some of it's missing so this gives you a sense of how the interface looks a little bit different compared to the menus and some of the drop downs you know if I look at some of the drop downs again I'll just pull that up like this and we can just select via the touch interface so save this person okay and what happens is now you know you see first because no data has been entered within these events we just see the first two stages all the same types of rules and logic that are working on the web device also work on the android device so until I say that a lab sample has been collected I won't see those laboratory request specimen tracking and laboratories on the android device either follows all the same kind of patterns and logic that has been defined on the android device itself and what I've done I've just created this new case and it's saved on my android device it's not yet saved on the web interface so if I go back here and I just reload this I won't see the person here yet this is this is the person I entered during my first part of the demonstration the person I just entered on the android device is not yet available and that's because it's saved here on this android device itself now there are different strategies you can use to synchronize the information depending on what you want to do but I'm just going to go ahead and manually send this case to the server basically so we can synchronize it allows me to there we go okay so you can see the message that that pops up when I go to synchronize this it says the data is stored in your device only it's not synced with the server so I can go ahead and send it it's going to go ahead and synchronize the data send it back to dhs2 the main interface here and then if I reload this page so here we go here's the person that entered on the android device they're now available you know for anyone to access whether via android or web you know another android device could access it anyone logging into the web interface could also now access this person all right okay so we've gone through quite an extensive orientation of the various components of data entry we've gone through the entire program we've also shown it working on android both you know the ability to download and work with cases that have already been entered via the web interface as well as you know going the other way entering data on an android device and sending it to the web device either in this case I just registered a person but you could enter in you know information on all the stages of the workflow as well and send it or you know you could you know however you choose to kind of work with that case offline or you know based on your requirements or needs and I just did one but you can do more than one obviously store that on the device and synchronize all of those when you do have a connection basically okay so I also wanted to go over the dashboards for this package okay so similar to the idsr package we have created dashboards for each of the diseases that are covered within this case-based surveillance package okay and just like we had the ability to compare some of the data for different diseases for the idsr aggregated information we can also do the same thing within the case-based data and you know what we're looking at right now is actually comparison I mean if I just kind of pull your attention to this measles one where there's data from both the idsr which is our area data collection platform as well as the cbs which is our case-based surveillance platform not to be confused with community-based surveillance right data and we're just comparing the number of cases that have been reported the number of suspected cases and we can see in this instance the the number of case-based reports for measles is just a bit lower here and you know it kind of helps us to triangulate our information a bit and determine you know how these can work together a little bit to complement one another and I think Rebecca will talk about this a little bit more in the presentation but it does give us some power to actually check you know if the data we're receiving especially if we have both of these implemented you know in particular in outbreak scenarios it can be hard to kind of scale things up quickly and there might be issues with accuracy if we're having to enter every case so you know depending on where you are in your implementation it might be quite useful actually to have both of these operating together so you can then compare the outputs from both of them to to make sure that the determination of your data is in fact correct so we also have dashboards for each of the diseases just like for the idsr package so pull up one for the measles example that we've been working through and we have some similar outputs as we had in the idsr package the first kind of outputs are looking at the confirmed the districts that are in a confirmed outbreak and you know all these outputs work the same right so all the menus and everything for these are the exact same you can view these full screen if we wanted to to you can see quite a bit more information when you open up this table for example and view a full screen from the dashboard any of these maps are the same they have the the legend you can interact with them and check the values directly from the dashboard as well if i scroll down however then we'll start to see kind of some you know this is a basic epicure still in the number of confirmed cases and then unconfirmed cases incidence rates but as i get into this we'll start to see some inputs that are really only possible because of the case-based data that is being collected so for example this measles vaccination status where you're able to check who has been vaccinated and compare this with suspected unconfirmed cases the number of specimens that you collect the type of samples that you collected with specific type for example this one is for blood you know none of this is really possible in that idsr package it's just based upon you know now we're collecting individual data and collecting quite a bit more details about that case and we're able to create quite a few more specific outputs that are not possible based of you know within the idsr package itself and you can think you know this is just the kind of cross-section of a handful of some of the outputs that would be possible but you know as we were going through that you probably had a sense of some of the other outputs that you could potentially create for your own purposes to use within within the confines and constructs of this package itself so so there's a lot you can do with this case-based data and a lot of information that you could potentially review with this case-based information as well right okay so so the last thing i wanted to show and they're also going to touch on this during the discussion and demonstration is the you know we've basically we have some tools to help you get started bringing in your data to the system or you know if you're kind of using something some other tool or something else you know it might be difficult to bring in legacy information or maybe you'll be using processes in parallel for a little while so we have different data exchange tools that are available and we'll talk about this kind of in the wider regional scale as well the implications of that but just if we can you know in this part i'll just focus on a particular implementation um so this tool has been developed by our colleagues in Uganda and from his Uganda and it allows us to quickly map tracker data to just a simple excel sheet basically and bring in that information now um DHS2 also has a functionality to basically bring in data but that can be quite complex as you need to really understand all the specific DHS terms and nomenclature um whereas this you know it can just be a regular spreadsheet um that has your cases listed line by line so if i open up an example one that i've made here um you know this is a very simple one one case represents uh or sorry one line represents one case um and basically i can bring in all that information this is much more standard and some of the inputs right don't necessarily have to match up a specific schema or coding schema or you know whatever the nomenclature of DHS2 is we can just map those and we do that once and once we do it basically anything any other spreadsheet within that same format will be be able to bring it brought in quickly so i'm not going to go through the entire mapping process because that that takes a bit of time but i'm happy to answer any questions about that maybe in the chat or through this community of practice but i'm just going to bring in this data real quickly because what i've done is i've created a mapping with the spreadsheet and will notice uh just bring this in okay um just a regular excel sheet okay and um i'll just show an example of of some of this so for example um just to show you kind of what this mapping looks like on the left side is what's in DHS2 on the right side is what's in my spreadsheet right this is just uh you know how i might see it in practice there's none of this kind of codification of the terms um that i see in DHS2 so this is just kind of written in plain english um i don't have to worry about matching them exactly someone will create this mapping for you or perhaps you yourself if you're your your system's administrator and once this is done you know you can just go through the whole process i'll go through it real quickly okay and you can bring in that information you know this tool is quite nice because it gives you a example uh or output right so it allows you to preview exactly what you're bringing in and if there is any problems with the data as well um conflicts or errors in this case this sheet there's no problems but if there was um it would also tell you that so you can see for example i have this person john smith they're male they were born on such and such date etc um and it's going to register that person on form okay so i can just quickly run this go bring it in for me and finish that up and then we can just check in tracker here to make sure that that was done um now obviously this is not that many cases if you have more cases you'd have to go through and do the data quality check etc but you know here are these people that i brought into the system just really quickly i'm just using a simple excel sheet um you know i didn't have to think too much about what was inside DHS2 and this might be quite helpful in terms of you know getting things up to date in your own system if you are starting um you know from scratch and needing to bring in previous data potentially um you know there are different mechanisms and you'll see also the data for the various parts of the workflow you know that can also be brought in at the same time essentially right so um we will talk about these uh in the in the context of why they might be helpful in the wider regional workflow as well um but but that might also be helpful in terms of you know getting your implementation started essentially all right so um i'll end the demo there for now if there are any questions about anything that i presented i'm quite happy to answer them i also have my colleague on the call sakebu with me who's uh who's also very good at explaining all of these things so and we'll try to help you together if there are any questions and i'll um we'll just continue on with the presentation so i'll actually start that out and we'll go to the next slide and rebecca over here thank you sure jeet so i will um just kind of finalize this this piece just a little bit of information about how these packages uh kind of can can go together be implemented together and um complement each other so in particular um you know one thing to keep in mind is is being able to scale up your case-based um data system but also keeping an eye towards timeliness and and kind of understanding um you know what is the best way to keep up with data entry and so in many cases having this kind of weekly ideas are while countries um might be scaling up a case-based system it's a really good idea to have both in place because you can sort of monitor the the completeness of that data um the case-based side um with the aggregate until the country gets to a point that maybe they feel confident enough um in the timeliness and the completeness of the case-based data um that they can remove uh that aggregate weekly reporting um it's also good to know that just you know sometimes having these outbreak scenarios there's a lot of cases being recorded at once it can be really difficult to keep up with the case-based data entry so having these kind of basic aggregate data sets available where the facilities are typically entering all of their monthly reports also being able to to keep up with this weekly is is a good idea um in the case that the case-based entry just can't be um sustained in a timely way during that kind of scenario and and then so lastly I think we will we can go to the next slide and we'll show just a couple examples around um how we've actually taken these two packages and started to try and delete the data so um I'm about to post um the link to the demo into the chat and we'll also make sure that's updated on the community of practice um but we have been working um with CDC and with Gaby's support um and with quite a few countries who have been sharing examples with us around how to um demonstrate some examples of actually triangulating these different types of data in a dashboard and so one of those common um sort of analyses you might want to look at particularly if you are scaling up that tracker program is to be able to confirm the confirmed cases sorry to compare the confirmed cases in your weekly IDSR versus the CBS um and just to see if there are significant gaps are you seeing um a large amount of aggregates confirmed or suspected cases through your IDSR and maybe a very small amount in your CBS um that probably means that your country is not quite ready to to completely cut off that parallel aggregate reporting because it doesn't seem like that CBS data is is timely enough or complete enough or at national scale so that's one of the things we would like to think about we've also given you an example around how you can actually take this one step further um and to actually be able to integrate some components of of for example immunization coverage data alongside this disease surveillance data and so from from sort of a um immunization perspective this helps you to identify immunity gaps potentially so where you might be seeing measles outbreaks is also a place that you would want to check um you know what is the coverage in that area are there potentially immunity gaps um if we've been able to sort of pinpoint this outbreak down to a particular area or community um there might be some follow-up activities that need to happen there with um a vaccination campaign or um catching up or kind of a real-time monitoring um sort of framework so this is where we want to be going with these packages um it's really the beauty of having an integrated harmonized HIS design with DHS2 and having these data at your fingertips across programs across disease surveillance immunization coverage other aspects of your facility data to be able to actually plan some response measures um when these outbreaks are detected uh next slide I believe we might actually I will say a word about the WHO Afro data warehouse um so this package was uh designed very closely um with the VPD focal points at WHO Afro and there is a reporting mandate for some of the weekly IDSR data and also for that VPD case-based data that um traditionally has been coming in at a centralized level through the epi-info system so the shared vision um with WHO Afro was to be able to to take advantage of the the very large number of member states who use DHS2 as their national disease surveillance system um to facilitate that data exchange to a regional platform so essentially moving away from some of these um you know sharing of excel sheets weekly to actually be able to push the data from the uh the weekly IDSR data to a regional WHO Afro instance on a weekly basis so that there's um really a lot of efficiencies to be had it reduces the burden of reporting and should improve the timeliness of that data and also making it available on a regional platform that is easy to um generate these automated analyses at your fingertips so as an example we can have dashboards across uh diseases they can show a dashboard by disease across countries um we can also get to the point of showing districts an alert across the entire Afro member state uh area and then lastly of course we can we can really provide that access control to different countries um and different types of users depending on the role in their system so perhaps uh WHO Afro would have um access to uh a regional view ISTs might have access to their countries in their sort of subregions um and then maybe also WHO country office stakeholders could be able to access this platform for the data that's being reported for their country so the vision here is to be able to really take advantage of where the data is being captured in the country system and to automate and improve how it's sent uh to WHO Afro and also to be able to provide these um types of automated analyses so without further ado I will um hand it over to my colleague is it uh Maurice is starting with Rwanda is that correct Maurice are you here and able to unmute yes I'm here I was only booked to unmute myself okay welcome so I'll hand the floor to Maurice Jules from uh Hisper Wanda to share the experience of piloting uh this this WHO VPD package in Rwanda okay over okay thank you thank you so much uh to the team that organized this one and uh my name is Maurice Jules, I'm a software developer at Hisper Rwanda and at DHS to implement uh I'm really happy to present in this public webinar about IDSR VPD because I've been involved in this project both IDSR and VPD implementation in and I've been closely working with a team that implemented the VPD package from the point we downloaded metadata to the point we went for training of trainers. Moreover we are working currently closely with Hisper West Africa to test the data transfer application that is going to alleviate the process and the need of sending data and exchanging data manually. So let me dive into the presentation and tell you about the implementation lessons from Rwanda. Here currently DHS2 is being used as the main system for collecting reporting and reporting in disease surveillance units. There might be other systems that are being used but that is on lower level and most of them are being phased out and DHS2 is being chosen as the main one. And the few ones that are being used now either they are being phased out or they are looking into ways of incorporating an interpreter to perform some interpreter ability to make sure that every data is in DHS2. And currently there is a instant instant notification on live data that's being entered into the system which helps a quick integration to the by the team from MOH and also this helps in decision making as fast as possible. VPD implementation by while implementing VPD package what we did we had the existing DHS2 instance and most of the information were similar so what we had we had to include and incorporate that was missing for instance there was four new diseases that we didn't have in the IDSR we had to include those ones in the option list and also we improved over a hundred program rules to make sure they're up to date and they comply with the new package. We also added three new stages because those new diseases needed those stages that we did not have in the IDSR. To the profile not much was added just two attributes and we had to adhere to naming conventions of diseases to make sure that exchange would be as smooth as possible. Another exercise we did was that we had to import data that was being collected offline. There was a there's a system they use called AP info and to make sure the transition is going to be smooth the program needed to have every data that was entered in that system from since 2004 to be transferred into the HIS2. So we did that and we finished that exercise successfully. On the other hand we are working as I mentioned we are working with the East Africa to make sure the data transfer app is being is tested on our instances and also we work with the Ministry of Health personnel to train on the use of this application so that as soon as it's ready for production they will be able to transfer data without the need of sending files manually to other countries. Also we put much emphasis on improving user friendliness of the system because we've we've been receiving some reports that different interface errors and system errors and the interface that is hard to use by the users discourages people from using the system and they sometimes keep some reports or like weekly reports. So during this implementation we had to make sure the data entry flow is as seamless as possible and the errors popups and and popup dialogues are very few and they're not destructive. We provide constant support and maintenance to MOH all the time and just just for example before we talked actually I spoke to MOH personnel who was collecting the information to be sent actually like the file she was currently extending the file and she was asking me some support. At the end we there's a planned training to take this further into like health facilities and other districts of Rwanda. There's a planned training to in districts near the borders of Rwanda that means like district near Uganda, Tanzania, Congo and Burundi. So but because of COVID there has been a delay but we are very happy that there was a successful training of trainers that happened a few months ago and currently the system is being used in production. People are using the system and the feedback received is that they don't have now to go back and forth and entering data in different systems. So those are the lessons from Rwanda and I'd like to thank you for the time you gave us and if there's any questions or any any qualifications I'm here and my colleagues are here also to help me answer them. Thank you so much. Over. Over to you Sekibu. Okay thank you Maurice and the others. So my name is Sekibu Yassani. I'm a leader for system development at East Post and Central Africa and I already be involved in those these packages both aggregate and tracker one. So for Mali, you know Mali already has quite some experiences when it's come to this surveillance. So that means the access to this official platform for the national health data system which means that it is implemented everywhere at the national level and for this work the HMIS work in stronger collaboration with other partners and technical GM to have these packages work into the system. So this collaboration reflecting the availability of both hardware as well as connection and electricity during the training which can be easily overseen but in some peripheral region the lack of electricity can pose some serious obstacles when it's come to data collection and the flow. There is an established work flow and the flow of data which is overall well respected among all partners. So on the front of the results of implementation of stronger collaboration we are now capable to share this organized data with the virtual data warehouse to prevent and spot outbreaks and epidemics by disease. Also thanks to also thanks to the setup of the program which allows the data collector and investigator to move rapidly between disease and to make sure that the data reported apparatus and of high quality. So Mali starts this implementation in 2020 and the counter of WHO package because they use directly the WHO packages as a strong baseline and the technical support come from the HISP Mali which is some like a sub HISP from HISP for Western Central Africa and they support this implementation with helping in the technical team. So they don't use all of these diseases coming with these packages so there's some those that they are not using we just create a program hole to hide them. Okay so that is for the VPD part but for the aggregate part they directly went to the dashboard aspect and making the mapping between educators and data elements. Okay so currently the system is still supported and maintained by HISP Mali okay but with the support of WHO and Gaby which are fundamental to avail the found necessary to continue the activities because when they start these activities we have issues for the financial aspect. Okay so the main challenges we have now it is it shows a way for the hard work because they are not a lot they haven't a lot of tablets because in this country they choose to use tablets to better manage data like based on offline aspects you know for you know they have like internet connectivity issues so they chose to use a tablet but this tablet also is not full available for them so that is some kind of a gap or challenges they have now. So I think for Mali the background they are not a lot of issues to do to tell there but again I know that for VPD aspect and the IGS aspect is not only that but they also added the COVID surveillance packages in this in the system so currently they have VPDs and they have COVID packages are working on the field for them thank you we can move on the next slide. Okay so this slide illustrates what it is currently done from Mali and Afro instance so here you can see the first dashboard it is the country itself dashboard and at the end every week there is a script we manage from our site based on the transfer data transfer app which send all those information okay currently it is only the aggregate one they are sending to to afro instances so the first dashboard it is the country and the the other one they are to the right side it is afro data-wise instances so the same aspect we are doing it with Togo also and Niger they are unloading now thank you so next slide okay so for the Togo you know the packages we are providing it is like a standard packages and then you guys can add diseases like you want you need to customize a little program roles in the section like Rwanda Jits so that was the same with the Togo the packages into the these packages from the Togo needed we add four diseases goleha with blood, virality and rigid fever and SRS and so for that we add some program roles to better manage the workflow of the data country to help those users but for the IGSR side which one it is aggregate we didn't use any more the forms so I did the demonstrated after the first demo we only use here dashboard packages it is packages with the related indicators so since the countries already have their own data set we just make the link between those the those indicators and the data element already available into the national system so the dashboard will show directly the data and from the data the country already submitted so those those customizations both vpgs and the IGSR was done a bit with the participation of HMIS but also surveillance guys and the laboratories stuff so there is something so we noticed so when we are doing this implementation it is sometimes so we forgot that for laboratory stuff but as you know into the trunk aside we need them to understand well how the workflow will be done so they will take in account when we did this work after so currently after the Togo we're still on cascades training progress we only use choose one region for the pilot phase so currently the central level and the original level have their staff training now the country is moving forward to district level for this operation so about the challenges when we start this work we have issues to have you know workshop available because of there is no funding so there is a lot of discussion with the WHO country one and Geneva one to have a funding to to have those workshops done but also we need to notice that we have also COVID aspect we make a selection of for some of our training activities when case is thank you that's what I want to share with you guys thank you so for next step I think it just it will be Nick yeah yeah so I'll just discuss some of the next steps from here so Rebecca has shared the demo link with you and we'll share some other resources I apologize if there are other questions that we haven't been able to attend to yet maybe post them in the community of practice if we weren't able to attend to them in the zoom chat just because you know with very screen sharing etc sometimes we're not able to respond but please add those to the community if you haven't already if your question hasn't been answered and we will make sure to get to it after the session is over okay so just a bit of a note on support about these packages so if you're thinking about implementing these packages just note that you know all the development of these packages along with the implementation of these has been kind of very well supported by Gavi along with our colleagues from WHO if you are a Gavi supported country then you may already have a mechanism to access support already to install configure help with training implement these packages so a HIST could work with you potentially to then you know set this up in your own country okay so if that is something you are considering you might want to talk to the relevant information people about this information or you might know already if you are a Gavi supported country and then you would have kind of access to this already through various mechanisms so make sure to also reach reach out to your local HIST group because they could help you with this as well so if you have a HIST that you routinely work with they can also advise you on the status of this in terms of technical assistance requests and how that might work out a bit more you can also reach out to your your Gavi SCMs and anyone in the WHO country office for support on this to understand you know how you can kind of continue with next steps if you are considering doing this if none of that applies to you then please reach out to us directly using the email in this presentation and we will be sharing the presentation and uploading the presentation to YouTube later on if there are any you know questions about links or emails or things of that sure okay so if you do have some questions about support just you know take these into consideration and if you are a Gavi supported country then chances are you already have access to some support already maybe that can be used to help you implement these in your own setting there's a couple useful links that we'll share that will allow you to you know continue and check some of these items this includes the downloads of the packages themselves the demo instance that Rebecca has shared already with you as well as some documentation about you know how these things are configured what the kind of thought process was between having you know things in a certain way I know there has been some questions about that we try to justify those design decisions wherever we can so you can have a look at that as well if you want to learn a bit more about how how things are set up and how they work and of course if you access the demo you'll be able to access the same configuration that I've been using for my demonstrations today you know both the aggregate information as well as the case-based or tracker data is available within that demo instance along with all the dashboards and all the other functionality with the notifications and all that other stuff that we showed and you can also ask city and android device if that is something you're interested in doing so all right so please that wraps up the kind of main portion main content of the webinar please if there are any questions related to any of the content that we've talked about today posted on the community if especially if you asked it in the chat and it wasn't addressed I apologize we just weren't able to maintain an aisle for everything also if you have any questions about you know further support mechanisms etc reach out to your his group reach out to gavi reach out to dbcho if none of that applies to you please reach out to us directly and we can perhaps put you in the right direction as well if you are thinking about implementing this in practice all right so thank you everyone for your time today we really appreciate it and please if there are any questions as I mentioned add them to the community of practice we'll try to keep in touch there if there are any questions about anything and yeah I hope this was helpful helpful for all of you and gave you some insight into how this package works and how it might be implemented in your own own setting so thank you very much everyone I'll close the close the webinar off for now and we'll continue from there thank you