 Welcome back. Glad to have you all with us. Just a little fun fact that I noticed from yesterday. The latest time zone that was joining us was Papua New Guinea, which is I think 6pm. And then the earliest time zone that I saw was from the US with 4am. So we have quite a range of times here. I realized yesterday we went a little bit over the schedule time. Apologies for that. We really wanted to make sure that we had time for each of the countries that was presenting and time got a little bit away from us. We will do our best to stay on the schedule time slots going forward. We also promise you that the word of the day will come up before we run over time. So if you need to drop off at the exact time and we are running over, you still can get your attendance points for the day. So at least for that you should be fine to get your certificate. So the other thing I just wanted to go through before we start the presentations is to show you again the two sessions that we have today. So I'll speak a bit at the beginning, going over some of the maturity model and key planning considerations, and we'll also introduce the planning template, which we mentioned yesterday. The planning template has now been shared with you fully. I believe that many of you received it before the academy that started with the readiness assessment. We've received from those of you that filled out your readiness assessment, we've already received those for the for the rest of you if you look in the project planning template channel, or in the announcements channel on Slack. We've also got a link for the project planning template, and we'll talk a bit more about that after the main topic of the first session. That template just so you know is a document that we're hoping you can use throughout the academy for the two weeks and that will become a useful product for you in your own tracker implementation. So please do take a look at that download it and feel free to be using it throughout the academy. I think we're ready to jump over to the initial presentation here. As usual, please be on Slack, ask questions in the Slack channel will do our best during and after the presentations to look at the questions and try to share the any answers with the full group will also be writing answers in Slack so you can see those answers and they'll be served there. But if you haven't yet open Slack or signed back in today, please do so. I'm actually going to post a couple of questions in the Slack channel, after I do a few of these slides, so that you can be thinking of the answers to these and we'll read some of your responses out towards the end of my first session here. So please do sign into Slack. The first thing that we wanted to do was just give a little bit of our considerations around tracker maturity and scale. This is something that it's becoming a much more understood topic in the realm of health informatics and digital health implementation. For those of you that have been working in digital health for for 10 years, you know that this is a topic that has always been discussed what is a mature digital health system. What does it mean to have scale. How do you know your system is sustainable. And we went through an era where there was a lot of discussion about pilots there's too many pilots, small scale projects or are a waste. They take up too much time. And that was kind of an in our opinion I think a very early way of discussing digital health implementation. The fact of the matter is that the digital health implementation at this point we recognize should be implemented at the level that is appropriate, and that level of which it is appropriate depends very much on what you're trying to achieve. There's nothing that says that having a more complex system or having a system that covers every health facility in your country makes it a better or more worthy implementation. It really should be the input implementation should be suited to your public health need, and it should be suited to your users and it should be suited to the hardware you have available and the network connectivity that you have. You can always think of kind of a two by two graph here that is giving you a sense of the complexity the coverage the scale of your system. And this is actually a useful way to visualize it for yourself and for your team as you're doing your your planning for your implementation, and you're thinking about the various systems that you have in country. I'm showing you an example here of how at least at one point we thought of the Ghana implementations. This is a couple of years old so they may have a different understanding of where their separate tracker systems fall on this graph. But just showing you on the left on the y axis we would have what we call coverage coverage doesn't mean every person in your health system it doesn't mean every patient it doesn't mean every health worker. What it means is out of your desired population. How far have you reached. And so we could see that the Ghana TV system at in in this graph was almost at the end it had achieved what coverage it had intended to achieve. Whereas the ART system at the time had not gone very far with its coverage they intended to cover more ART sites they wanted to get more of their patient population into the system. But meanwhile, the complexity on the bottom the x axis was very different between them. So we would have a system like the maternal health system which was a fairly straightforward system for entering in the basic key data that were captured during a maternal health visit. It was not something as complex as the ART system. It didn't include, perhaps, notifications or it didn't have the strong link to the desired analytics. So it had less complexity in the configuration, but a higher coverage rate. Whereas the TV system would have been somewhere in between it was a little more complex than the mch system, not as complex as the RT system, but with a very high coverage rate. And the utility of thinking about it this way is helping you to better understand some of the underlying requirements of your system, who is your population, who is your user population, what level of data are you trying to access. How complex is the system how much it support is it likely to need. How important is it for this system to maintain constant uptime versus how big of a challenge would it be if you were needed to do an update and the system was down for two days or something. So just being able to think about your system in these terms kind of helps you to have a more sophisticated understanding of the support requirements and the goals that you're trying to achieve. So we wanted to spend a little bit of time today talking about why you're using tracker, and what are the benefits of capturing individual level data, what are the benefits of capturing individual individual level data at the point of care. So you can see from the top triangle in blue, we've listed out some of the things that you can expect improvements on this can lead to better data use or more data use. For example, if you're providing data back to the healthcare provider, giving them information on which children are missing vaccine doses, or which ART patients are lost to follow up. So this can help them actually use the data to improve the clinical outcomes. These benefits can be given to patients and health workers. So again, in many aggregate kind of systems, the data is really going one way, it's going up, and it's not being used to give benefits back to the clinic or the patients. But with a individual level system, you can do things like send SMS notifications to the patients, letting them know when their visit is or which medication they should be using or what are some possible complications to look out for. For the health worker themselves, again, it can give them planning tools that can provide them with decision support. It can give them, you know, an improved set of tools for actually carrying out their job rather than just reporting. Operational clinical performance improvements. So you can create, for example, dashboards that are clinic facing, giving them information on how well they are performing at managing hypertension. And maybe some links to resources to remind them of the clinical workflow that they should be following or how to improve. You can give them the opportunity to send messages and notifications about needing resupply of a given medication. And the data for individual level systems also in the last one can have a strong impact on health policy and research. You don't need to know ahead of time all of the indicators you will ever want to calculate, because you have the individual granular level data, meaning that you're essentially creating a registry that can last over time. And you could learn a year from now. Actually, we need to understand better the link between malaria and COVID. We didn't ask for that as an indicator that was nothing that we thought of. But we do have individual level data on all of the patients that had malaria, all of the patients that had COVID, and we can design new indicators that recombine that individual level data and give us a better understanding of whether or not there is a link. So these are fairly strong benefits to trying to get down to an individual level system. In the public health world, I would argue that we always have wanted individual level data and that the reason that we have aggregate data is because that was what we could achieve at the time. But in the future and going forward, we expect there to be a stronger and stronger desire to collect individual level data. On the downside of having this kind of a tracker system, it is a much more complex configuration. There's a lot more to take into consideration about how the data entry should look, adding in those kinds of tools like decision support or notifications. It adds a degree of complexity. You may need to think about dealing with your SMS service provider and setting up a gateway. You want to consider every possible reason that you would want to send a notification and work on the language of sending those and agree with the care workers that this is the right information to send. So there's there's a lot of different things that come up in tracker that make it more complicated. From your IT support system, you're expecting a lot higher number of users, whereas in the past, your DHS2 system might only reach to a district level or even a regional level. And you would have a handful of users in each district or region. Instead, you're pushing down to facility level, you're pushing down to community health worker level. And this can be the difference between having 200 DHS2 users and 10,000 DHS2 users, which is in order of magnitude higher and brings a lot of additional challenges with IT support with, you know, complaints with trying to handle turnover. You're also a much larger amount of data. You're simply collecting more information and this brings in additional challenges around performance, around data storage, around data management, data cleaning, duplication. So any number of challenges associated with the data management. And by its nature, individual level data is typically more sensitive. All of the healthcare data has always been considered to be something sensitive, but when you're dealing with personally identifiable information, you're looking at you have somebody's name and their HIV status, for example. This typically in the legal realm really brings up added burdens or added requirements when it comes to keeping that data safe, having strong data access policies informing the population of any breaches. So there's much more to consider when you're trying to implement an individual level data system. So what we would go through and are going to be talking a lot about through the course of the next two weeks is how to mitigate those challenging aspects of having an individual level system so that you can end up achieving the benefits that you see on the top. And so the way that we at least graphically have thought about this is we're creating a house, and we have these five kind of infrastructure prerequisites for DHS to tracker system at the bottom. These are the horizontal bars we think of these as prerequisites. And then we have these eight boxes that we think of as the key considerations. And this really represents the bulk of the topics that we will cover in this academy. These are all of the parts that if you are responsible for an implementation, you will want to have standard operating procedures named staff job descriptions budget lines, all that correspond with these different key issues. And so we'll talk a little bit in the second session about doing a readiness assessment where you're looking at, for example, these five horizontal bars and and determining whether you are ready for this kind of an implementation. And we'll talk throughout the week about these eight boxes, trying to understand the different implementation considerations that are involved with ensuring that you have proper hosting and security, for example. So this is what we'll start to give a little bit of an overview for during this presentation. And at this point I'm actually going to pause the presentation for a moment, and I'm going to put a couple of questions into the slack channel that would be things that I hope that you can consider while we discuss. So give me just a moment to stop sharing one screen, and I'm going to jump over to another. Okay, if you are in slack right now you'll start to see that I'm going to post three different questions into the questions channel, and I'll read them to you in just a moment. We'll go back to sharing my screen now. Okay, so the three questions that I have shared the first is after we have discussed all of these different challenges. Why have you decided to use tracker, and what benefits are you planning to get from adopting tracker for your program. The second question would be if you could start over with your implementation what would you do differently. So there are many of you in the in the academy that are already running tracker what would you, what would you try to do differently if you could. So something that you would tell us not to do what would that be. So throughout this presentation as I discuss a few of these different key considerations try to be thinking of some answers to these questions. Please post those answers under the individual questions in slack and towards the end of the presentation will bring up some of what each of you have to say. I want to make sure from Anna or Martin, are you seeing now my slide that says real time versus second entry. Good to go. Okay, so this is the first key consideration. This is something that you would want to be thinking about as you're doing the design of your tracker system. If you are trying to have the people who generate the data also be the ones that do the data entry, or is the data entry going to be done secondarily it would be first captured on paper, but you would have a data clerk, or even that same individual who would later in time go into the system and enter the data from paper into the system. So this, this is a key thought that you would have when doing the design because if you are doing real time data entry, you can add in things like decision support. You would want to make sure to highlight some key information that perhaps you're going to generate a notification to the care provider, for example, if they're doing an ANC visit, you want them to immediately get a response that based on this would make sure the patient likely as hypertension. Right, so this is the kind of information you would, you would have to plan for and put into the system if it were real time. If it's secondary data entry, rather than optimizing decision support, you would focus instead on data entry, a data entry clerk has a lot of data to get through they want to do it very quickly you want to make it as easy as possible for them to navigate the form and capture the data. You may also include different data items, the healthcare worker may need to capture more information than you're planning to analyze. And there's no reason to for the data clerk to enter all of that information, the data clerk rather is creating more of a reporting form. So this is again something that you would really want to know about and think about ahead of time. It would also have an impact perhaps on how many people you're going to train, how many devices you need to make sure are available. These things would impact your budget they would impact the IP support structure that you have. So it's definitely something to think about and to know. We generally believe that doing real time data entry brings the most benefits from an individual level system, but that doesn't mean you should do it. If it's not possible if you don't have the resources for training if you don't think that you can provide the hardware. If the users that you're aiming at don't have a reliable network connectivity, then you could probably decide that now is not the time. You could also decide there are different parts of the country where it makes sense to do real time and where it makes sense to do secondary data entry, and it's completely fine to have a mixed system. You want to make sure that as far as the reporting goes that the information that they're all sending up is standardized, but you may determine that in a given level of your health system or in a given region of your health system. And yet to do real time data entry, perhaps it will be time next year, perhaps after you show the benefits and impacts in one area, then you would be willing and ready to roll it out to another area. So these are things that will impact your planning of training your planning of how many resources you need etc. Another key consideration is how your tracker program is going to live in the ecosystem of your HMIS. In most countries that are adopting tracker now, they are already using DHS to for their HMIS and for their aggregate reporting. And there's already a process with people that are trained that are used to doing the HMIS reporting on the ministry side or the program manager side there's already a routine for assessing the data that comes through the HMIS. In other words, they are expected dashboards they know what analytics they're looking for. And so if you're introducing tracker, you need to know how tracker fits into that same ecosystem. Are you going to have the same people looking at data from tracker that would be looking at the HMIS. Are there going to be additional people. Are you now going to start providing dashboards at the district level or at the health facility level whereas previously you only had dashboards for higher level users. Is it your collecting. Is it going to be able to calculate the same indicators that would come through the HMIS. If it is calculating the same indicators as the HMIS. Would you want to replace some of the aggregate reporting, or are you going to have two different sources of information. If you do have two sources of information, how will you reconcile them. What do you do if the tracker system is telling you something different than the HMIS. There's a lot to consider here. We have a session later in the week that talks about linking tracker to aggregate and thinking some of those through. But this is something that also would just feed into your design overall about who your users are and what they're going to be using tracker for another key consideration would be whether your users are going to be on Android or the web. So the web is easier interface for many users because they have a full keyboard they have a nice big screen. The web is also persistently online. The data as you enter it is being sent to the server so it's being safely stored somewhere outside of the facilities location. And it gives them the opportunity to have a computer at their site that they're using for other purposes as well. And many of the kinds of users that were targeting were actually giving them their first health data system. They don't have a computer at their location they don't have wired internet. They often have only an intermittent mobile connection. And so there's no chance for them to be using the web they actually would need to be on an Android application. Android is the intermittent connectivity solution. They can collect data on Android it's stored locally and they can sync that data later when they do have a connection when they go to the district for their monthly meeting or when they check in at a different site once a week. And so for those kinds of users Android is the solution but that brings with it again a host of implementation considerations. How are you going to provide everybody with an Android device. How are you going to ensure that those Android devices are updated regularly. How are you going to make sure that the Android device has airtime. What are you going to do to troubleshoot when somebody loses an Android device how would you replace it or if the device gets broken. So many of these are key considerations again you might determine that there's a part of your country or a part of a region that can be on the web and another part that should be on Android. And those can live side by side they're reporting data to the same place, but you would want to have kind of a sophisticated rollout plan to make sure that you're serving the needs of both users that they both have it support solutions. To manage the main complications that come with either of the different modalities hosting and security again we've talked a little bit about this I think we've emphasized the point that tracker information is often more private and more sensitive. In many countries they're passing legislation about data privacy. We of course in Norway are dealing with the GDPR legislation that came in effect a couple of years ago. I can say for sure that we, the tracker can comply with this very rigorous legislation because it is being used in Norway for the coven tracking and coven surveillance. But it also depends very much on how you use tracker. The tracker itself has many, many different tools and ways of being configured, and it could be configured to be completely open where you've given no thought to who has access or what type of user should be able to see individual level data. And this would be the implementation failing at sensitive data, not the software. So it's very important for you to know what the regulations are in your country and in the project in the area that you're working. It may also be important for you to establish your own policies. Many countries don't yet have appropriate regulation or legislation, but that doesn't mean that we don't have a responsibility to try to protect this data. So again, there's this has an impact on staffing and has an impact on who you are going to put in charge of the privacy and security aspects of your system. It has an impact on how you decide to host, how you decide to design user roles, how you offer trainings. So there's many different considerations for implementation that are about trying to ensure the most secure system possible. When it comes to hosting, again, this is something where many of you may already have a DHS to hosted environment. But you would want to do a second assessment on that environment if you're going to start including tracker data to see if it has the appropriate level of security, who has access to that aggregate data. Would you need to keep your tracker in a separate instance would you want to keep it on separate hardware. Are there requirements in the country that would actually require you to have the tracker data on a separate server than the aggregate data. So again, a lot of kind of legwork to be done at the beginning of your implementation to understand what the key considerations are for your country. And perhaps develop policies that you want to have signed off on by the leads in the Ministry of Health. This is something that we've done in a couple of countries, where they didn't have the legislation that you would expect. And so instead we drafted policies that were signed off by the director of the Ministry of Health, and they would include some kind of training for every user that they would have to also sign in agree to the designing process. This essentially we're just saying here that this depends again on understanding very much your use case. What are you trying to achieve what is the data that you may need to make sure to collect how does that does that align with the indicators that you're going to be responsive to what work processes are you supporting and can you map out those processes, to ensure that the system you have come up with is matching what the user wants to use it for. Probably kind of the at the lower end of tracker configurations we see a country simply redesigning their paper form and putting it into tracker. This usually leads to some frustration because there are already things on the paper form that people are used to skipping through there are things that are easy for them to ignore. There are things that are unnecessary and everybody knows that, but if they get re implemented into tracker it can lead to a lot of frustration. So when you're going through the design and configuration process, you probably want to take time to reassess your paper forms and to think through which of the aspects of the form are not being used, which of them should be improved. Are there key data elements that are missing from the paper form, but then take it a step further and think about who is your user. And what is their role, how do they actually enter this data, are they a data clerk or are they a clinical health worker, are there additional tools that you would provide to them because you can in tracker. This is a process. This process should usually be done working with users, try to do some level of user acceptance, some, perhaps some level of user design, visit the sites that are using the system once it's introduced. See if they have any recommendations on how to improve the use of the system, what aspects of it are the most frustrating. So this can be something that again happens before the system is introduced during kind of the beginning piloting phase after the system has been in place for a while. And making sure that you are trying to constantly improve on this, the tool that is being provided to your users scale. This takes us a little bit back to that first slide, just thinking in what is the impact of introducing such a system. What we've really seen over the last year with the introduction of so many of the COVID surveillance and COVID testing programs and now the COVID vaccine programs is that this in many countries has become their largest IT implementation ever with the highest number of users, the highest number of people or patients that are being entered into the system. And this is means there's a lot of learning to be done about how to manage that volume of data, how to how long will training take how many trainers do you need. What is the cost associated with all of these things. So again, before the implementation begins having some discussion around the cost associated with it understanding what scale you're trying to achieve. Perhaps you'll do a phased roll out. Ghana talked a little bit yesterday about doing kind of a continuous progressive roll out where they rolled out the system two years ago but there's still a portion of the country that they're training even now and getting them to adopt the system. So that is something that doesn't all need to be done at the same time but it's something that you can think about and plan for in the implementation process. Training we've mentioned several times. But again, we I think are all very familiar with a training of trainers kind of approach, but you may find that you need to do even another tier of training, where you have trainers at the national level that go and train district level users who will then go and train facility level users, for example. The time that it takes to train 10,000 users is massively different than training 200 users and the number of teams that you might want to have involved with the training changes as well. Also the types of training that you're offering. Much of the training now may revolve around the device itself. You're introducing an Android device and you want to teach them about how to keep it charged and how to make sure that a pen is used for security purposes. You'll have to train users about whether or not they're able to load additional apps on the phone or what to do if they run out of airtime. So there are more topics to be introduced when you're rolling this out to the lower kind of parts of the health system in terms of training. So any of them, these topics may have nothing to do with the HS to or the health program they may actually be about maintaining devices or or how to, who do they call when they have an it question, which takes us to the it support unit. I think if Ghana were speaking right now they would, they would have a lot to say about how their it support unit structure has had to change over time. They went from having a very successful aggregate system with a dedicated unit at Ghana health services providing all the it support to having multiple national scale tracker implementations with many more thousands of users and many more thousands of devices. It support starts to need to devolve down again in the ecosystem. Perhaps when you're training the district level users on the system, you also need to train them to provide frontline it support. They can perhaps answer the most basic questions when a user is struggling because they have locked himself out of the system, or because they have, you know, run out of airtime or because the battery is not charging and how do they get a new device. Usually the team that you have at the national level won't have enough staff to be able to field all of these questions. But that means thinking through is there are there more people that we need to hire is there more of an infrastructure that we need to put in place at the lower levels. Are we going to change some people's job descriptions are they going to be providing more it support along with the typical kind of supervision that they used to do from the regional or the district level. At the central IT support unit, you may also want to staff up as well around managing 100% uptime for your tracker system. If the tracker system is a part of your clinic clinical care process. It has a really negative impact when the system goes down for a day or two days in your aggregate system you maybe could live with that. It's nobody's ideal but if the system goes down for three or four days, the health care still is provided there there are not as many negative impacts. But if your ART system goes down and there's no way to bring that system up for the next two days that can have a very significant problem for the people that are trying to receive and provide care. So thinking about how to have round the clock over the weekend support for a system failure is really important. If it's because I've come to the end here that I'm. Okay. So, again, this, this was a brief overview of these key considerations we have more to say on every one of these topics but we wanted to start getting you thinking about some of the challenges associated with this in order to help you plan in order to help you. So please ask for the appropriate level of resources from the groups that are supporting your tracker implementation. Many of these topics again will have their own dedicated tab and the project planning template and I'll spend a moment on that. Now, so I'm clicking over to the project planning template. Again, this document has been made available to you in Slack. It is in the announcements channel it's also in the project planning template channel. You can download it and use it for yourself throughout the week. I'm just showing you a little bit of what is in here in the next session will be taking a look at this first tab the readiness assessment. The readiness assessment is really trying to answer some of those basic questions that I was just raising about the scale that you will go to what is your end goal your support structure connectivity and hardware, trying to give you a set of questions that you should be able to answer as you're dealing with stakeholders as you're working with your national programs as you're thinking through the timelines associated with your system. We have a process matrix here which again will spend more time on later but just giving you helping you to map out what are the processes that you're trying to support throughout the life of your tracker implementation. You can go through your objectives what any inputs and outputs would be how you could use this kind of information to design your tracker implementation. We have a roles and responsibility tab, where you can think through who the governance team is the management team the development team deployment operations. So this is helping you think through what their responsibility is, who the named individuals can be, who are their supporting staff. We have a privacy and security tab that will again walk you through more that is providing you the opportunity to think through all of the different aspects of how to keep your system private and secure, including the processes that you would put in place and who the responsible people would be for those. You keep going over, don't get lost in the first few tabs there are more tabs to help you set up a monitoring plan and an evaluation plan for your system. And when you have come up with all of that information, you would then have the opportunity to think through a work plan about how you would roll out your system, what are all of the different activities that need to come into place, what are the new documents job descriptions so P's that you would need to have and how long it would take for you to get to the appropriate scale that you are wanting to achieve. And then finally we have a budget tab, which would help you to map out what are the resources that you need for your system. We have some plug figures here, but again we'll have a dedicated session to helping you think through and fill this out. So our hope is that by the end of the Academy, you will have filled out all of these different tabs, and you will have at least a very strong starting point for the planning for your system. For those of you that already have a system in place. This is also an opportunity to document some of these things that may just exist in theory or in practice right now. So helping you to write out who is responsible and how things are working. I see Martin you ever raised him. Yes, like, there was a question about after they filled it out, do they share it with us in some way by email or. At the end of the week actually are at the end of the Academy, our last day will be an opportunity for some to share their project planning and for us to discuss. And so that's the main point of sharing the project planning template that the full project planning template is for you. It's not going to be graded on our side. It's not going to be where your team to have and to fill out and to be able to use going forward. So it won't be used to give you a grade or something instead it's meant to be a very practical exercise for you to be able to document and plan around your own implementation. Right, so, like practically how do they shared with us. I guess we'll make some decisions and give some more information about that the very last sessions is about sharing and we'll we'll probably ask you to create some slides for your different implementations that answer at least parts of these and that will share them together during that final day. I'm going to give you some more information about that for now, using the tool as we go through each of the sessions so if you take a look back at the agenda, you'll see today will do the readiness assessment review conversation, and you can be filling out then this first tab today while we're talking and after the session has ended. So I'm going to continue to have then questions about key Android considerations in a session about how you do program design. So again, this will give you an opportunity to start planning out some of those parts of it. We have sessions on data access management that would fit into your security profile, for example, we have this scaling, linking our data tracker budgeting monitoring and evaluating. If you have any sessions you will have your version of this document open, you would be able to fill it out throughout the session, put in some thoughts and and and the information into the document and and again follow up even after the session is over. Yeah, I know I just want to add to that that there are sessions almost every day where we put aside time that the facilitators are ready to discuss after the after the normal sort of course sessions, so where you can work on your assessments and you can and you can post questions to us and we will, we can help you to fill it out and to discuss with you. It's also noted in the agenda. Okay, the last thing that I was going to do for this session before we take a break was take a look now at our slack and see some of the things that people have entered for responses. So our first question here after seeing all the reasons trackers difficult. Why have you decided to use it what benefits are you playing to get from adopting track. So let's take a look. From Abdul having timely data and be able to make decisions based on facts. So this is one of the things that tracker is really good at. It's a good reason to be adopting an individual level system tracker data is immediately available. So if you have depending on where you're doing the data entry but if you do it at the point of data generation, then you can have updated indicators and dashboards immediate. You can have them updated nightly, rather than going through a monthly process where it's first on paper, it's then entered into a reporting form at the clinic, the clinic sends that to the district the district aggregates that information, enter enters it into the aggregate system. So it really speeds up the process to being able to make decisions and to react quickly. If you see a stock out at a facility then you immediately respond rather than waiting for a monthly report that shows the stock out. If you see a spike in fevers in a given location, then you can have an epidemiology team looking into what's going on and react more quickly with a disease surveillance approach, for example. Abdul Rahman shares the envisaged benefits will consist of reducing dropouts in the API program and to be able to track women and children enrolled in the API program. So again, this is a another clear benefit to the individual data, rather than reporting higher level aggregate numbers of who, how many children are lost. You can be producing daily a list for the healthcare worker that shows which children have not received their second dose and giving them that child's contact information their mother's contact information a phone number to follow up with. So allowing them to really have a working tool to address the problem of dropouts rather than reporting on dropouts and trying at a national level to make a difference. Okay, let's take a look at some of the other responses here. If you could start over with your implementation, what would you do different. All right, Anna, it looks like you had a response, do you want to share your response. Sure. So I've been working on a project. I've been working on a COVID contact tracing tracker project here in Norway where we're making a system to track the infected person a surveillance and then who has been in close contact with them to enable to put them into quarantine and keep track of how many close contacts as a positive case have etc etc. And this is being used by contact tracers all over the country. I think one reflection I have had after working on that project is the complexity of the of the workflows. It's very specific how each different office working with contact tracing works and they find their own little routines to make this run smoothly and if I would do this again I would involve healthcare personnel or the contact tracers in this case at an earlier stage in the design process. And I would also involve the people requesting and data and dashboards at an earlier stage to even better understand what their needs for data is so that we can provide that in an easier way without manual work for example. Over. Thanks. Abdul I see that you again responded having a view of the reports that the system will have to answer. Yes. So this often is something that I've run into when we've worked on systems where we are told from the beginning Oh here is the paper report implement this and tracker. And then we find out after that is done that that paper report didn't answer all of the analytics needs, and that it never has that there's just been a lot of people skipping some of the required indicators, and that the ministry really wants to have a different set of analytics than they used to have. So knowing ahead of time okay what are the analytical outputs what kind of reports need to be provided and rethinking some of the, the ways that you are designing the tracker would be really useful and important. So having DHS to aggregate for HMS and some health facilities Abdul Ramon says, making sure that these health facility staff and provincial project supervisors are involved in the design of the tracker framework from the beginning. So I guess I'll make some guesses here as to why this would be useful to you but I think it's, it's great advice if you already have people that are used to DHS to or to the aggregate, and now you're introducing something new. And of course to let those same people have a say in how the new system is going to be, whether it's going to be replacing parts of it or not. How do they use the systems together. Who are the users that are entering data making sure that it's very clear to everybody involved what this new system is and what they should use it for. And it also lets them give you very useful advice designing with the user is always going to be better than making kind of assumptions or guesses at the national level. Okay, and last thing that we'll just take a look at before the break. If there was one thing in to tell the room not to do what would it be Abdul says never start without training the people involved very well. One point training can make the all of the difference about whether or not your system is a success. Do not get web hosting services from general service providers rather search for providers who are familiar with the HS to this I think is something that is really a learning point for every country is to figure out what the best approach is for hosting services. So they're often requirements for hosting locally there often is some kind of infrastructure in place. You can use the requirements for tracker to reconsider any of those policies and to think about what would it mean if you had downtime how would you get a response who would be responsible. What are the privacy requirements and that those kinds of answers should really drive your selection of hosting process, whether it's on the web or it's done locally. And there are quite a few as Abdul Rahman points out there are quite a few groups NGOs companies that specifically provide DHS to hosting services. And so they may be worth considering depending on what resources you have and what policies to provide. One of this says starting without a clear idea what the data will be used for what kind of decisions will be made based on the tracker data. So this is something you would definitely not do. And again so doing like an early data mapping process as you're designing your tracker thinking through each data element you're going to craft what should be the limits on those data elements should you have program rules that hide or show the different ones. What are the decisions that you want to make. Why are you collecting the data. Are you doing it just because it's always been done that way or is there an actual clear purpose for that data. So many of those things that really you should do in an early process of design before you have put additional burdens on all of your users out there. Okay, I think with that will will stop those questions will remain in the slack channel. Feel free to continue adding some thoughts there that you'd like to share with the group. Of course use the slack channel to ask additional questions and we'll continue to fill those out. But at this point I think we're ready to take a 15 minute break. And schedule 30 minute break. Okay, we can do that a 30 minute break. So we will do a 30 minute break which means that we would be coming back here in Oslo at 1125. So 30 minutes from now we'll be coming back and this is where we'll dive into the ready assessment review. We've had several participant volunteers who are going to join on for that session to talk through their readiness assessment. And we look forward to having the rest of that conversation. So we will see you back here in 30 minutes. Thank you.