 Okay. With that, I think I'm going to go ahead and get into some of the key considerations for Tracker when it comes to scaling. This is going to cover a number of the topics that we've raised over the course of the academy so far, but maybe give you some mitigation strategies or techniques that you would use to try to make your chances of scaling successfully more likely. The key consideration here, the most important thing is to realize that you're going to with a large scale tracker implementation, dramatically increase the number of users, the devices, the technical and organizational support that are required. So we want to go through what that should mean in terms of your planning and in terms of the kind of support that you need to be able to provide the resources that would be necessary to achieve this. When we talk about scale, we talked about this a little bit in the beginning of the academy. Scale often is something that people don't think of across various dimensions. They think solely in terms of the number of users, which I think is the most obvious scale to think of. But there are other ways to think of a scale also. So just like we were talking before about you could be having multiple tracker programs that cover various different health areas. That's another way that you could think of scale. So that perhaps you've scaled one national system that's around, you know, adverse events following immunization. But that actually has a very small number of users potentially in a small amount of data that you would collect because there are not very many adverse events following immunization. There's not that many users that are responsible for conducting an investigation or reporting on adverse events. But if you start to add in additional services like malaria services, this has a much broader user base. There are many, many different care providers that have responsibility around malaria testing or malaria diagnosis of prescribing anti-malerials. And so you could see that even though you have two national implementations, they're dramatically different in the terms of the number of users, the amount of data, and the considerations around the hardware that would be associated with those users, etc. So that's the next piece is hardware and infrastructure. Again, you would find that in the malaria program, perhaps you have, you know, 15,000 users compared to the adverse events program where you have 1000 users. So this should really factor into your planning for budgeting purposes when it comes to the hardware that you would be using. This should factor into your decisions to use something like an MDM solution for Android, like Jaime was discussing yesterday. And can also factor into some of what Marcus will be discussing around the kind of infrastructure around hosting that you would need and whether or not you can continue to use the same infrastructure that you had for your aggregate system or for your smaller scale tracker system. Data, of course, is another change as you scale in the amount of data that you collect. This can have an impact on performance. It can have an impact based on the storage space that you have available. It can also have an impact on how serious your data breaches might be or on how, how big of an impact it would have if your data were to be corrupted or lost. So these are also key things to be thinking about when it comes to scale. And then finally, of course, geography, geography has a very tangible impact on things like training on providing user support on replacing hardware, etc. So again, you may have had a system that was considered national scale, but it was at a district level and the districts all had a good road network to travel there and to provide training. But when you scale down to something like the community health worker level or to the main primary health facility level, it may be take much longer time to reach sites or to set up a location for users for seed training. So all of this is to say that your previous training IT support budgets hosting approaches will all likely need to be modified as you scale up tracker across any of these dimensions. So this is important in your project planning, the template that we've provided for you and thinking through what your timeline should be what your cost should be, and what to expect when trying to achieve, you know, this the scale that you're hoping for. So we'll talk about these in a little bit more detail. The users for tracker, more so than aggregate, for example, they're often at the lowest levels of the health system trackers targeting specifically individual level data, which means that you're getting close to the point where the data are generated. Either the data are being collected by the person that's actually providing the services or maybe they're one or two steps away at a data clerk who is receiving those individual records. They're more difficult to reach to provide the kinds of IT support that you would want to provide for any information system. So you may have many more people that are having troubles with their network or logging in or they have deleted the application from their Android device, and you need to have a way to stay in contact with them and to reach them. Many of these users are newer to the technology. Very often we're seeing that even in the more periphery areas that people do have devices they often are used to texting their use perhaps to kind of basic smartphones, but that doesn't mean they're used to using those in their work environment that doesn't mean that they're ready and prepared to use them while they're seeing a patient or for entering data. And it's difficult to provide retrain. So you may go through a massive effort to train this high number of users that takes an entire year to get around the country. And by the next year you have 20% of those that are new, and they weren't part of the training the year before. And so you have to think about what what are your strategies for keeping people trained and up to date on the system. And the recommended approaches in the trainings themselves, focus on the hardware and the devices that they will be using, getting them familiar if you're providing Android devices this means not just teaching them the app itself, but also the basics of how to make sure that the application remains charged and talk to them about whether or not the phones are waterproof, and make sure that they know what to do if they are logged out or if they need to read download the application. So there are many kind of basics of the hardware that you might want to be giving them some more familiarity. This of course adds time to the training where you may spend the first day on topics related to maintaining and the storing and keeping charged these devices. So planning for that appropriately. This is an IT support strategy. So again this may mean devolving some of the IT support down to other areas of your health system. And often this means you don't have the funding to actually hire a new IT support staff for every district, but perhaps what you can do is train your district supervisors for a given health program to field the most basic IT support questions about what to do if there has been broken or lost about what to do if somebody has trouble logging in how do you get them a new password. So some of these basic things that if the entire country were reaching out to your central team. They would be quickly overwhelmed with those kinds of questions. So trying to devolve some of those tasks down to the lower level so that the system can remain functioning. So this idea to provide some of those basic guidance and support in the form of hard materials that they can have at the clinic or or for the community health worker, give them a poster, give them a handout, give them some kind of very graphic or easy to read kind of instructions on how to handle the most basic support problems that they might have. Again, as we said from yesterday strongly consider using mobile device management being able to redeploy an updated app, being able to determine the location of your Android devices, being able to see the amount of users using the system. These are all things that will help you to better manage your implementation. The next point about location specific synchronization plan what what this is referring to is that many of the locations as they're on Android, they may not have good connectivity. And you will want to know from the district level or even from the local users. How will they be synchronizing their devices. So if they're a location that they know of where they can go to and synchronize their device. Do you need to establish a plan where on a weekly basis they are expected to travel to that location. Maybe that's at their district maybe they already have a regular meeting with their supervisor or with the other facilities in the area. But if so that should be a part of their training, rather than hoping that they will figure out themselves how often to synchronize or where to go to do that. So it's nice to give them that as a plan that you've developed with the local knowledgeable people about how and where they can synchronize their device. And when it comes to kind of retraining thinking through who at the district can continue to provide those kinds of training and refresher courses. When someone is hired or it's a new person at the location. What are the kinds of materials that you have available for them to learn the system themselves with support from their fellow colleagues or with support from a district supervisor. When it comes to health program coverage. Again, these tracker programs can be kind of stacked and used in combination across health services. The data entered in the tracker often represent a wide number of paper based report and work processes for the user. These health programs are resistant to some of these changing processes they're used to doing things a certain way and they're not always happy to have yet another new system being being sent their way. And the health programs themselves often have different indicators and ways of representing data but they come from a single source of data. So the user is used to entering one piece of information whereas the health programs perhaps TB wants to see some representation of the HIV data, but they want to see it in a different way that the then the HIV program does. So you want to be careful about the design of your forums and how the data are being analyzed. So a way to kind of think through some of these combinations of health programs and the way things are being reported is to have a steering committee at the national level that combines the different health programs that are going to be affected by these changes. And that usually means getting an appointed representative from the health programs. So if you're trying to have a coverage of health programs for HIV for TB and malaria, there should probably be a representative from the national programs for TB HIV and malaria, that not are only there at the very beginning, but that they take some ownership of these systems. So how the system works, they agree to the way that they are designed. They understand the training program and the IT support structure, and they can be a focal person as the system matures and as changes are made. They contain kind of the history of the program. They also are involved in any of the decisions about whether you're going to be changing processes or not, or if you're going to be replacing paper. With this group, you would want to review all the guidelines and processes that could be affected and perhaps take the chance to streamline your processes. So again, if there are at this point two or three different paper reports for different programs, but they actually are representations of some of the same data. So you may want to be able to combine that into one program or into one way of reporting the data, try to make things as easy as possible for the user. One of the key benefits of digitizing is that they don't need to repeatedly enter the same information on various different forms. And so you want to give them that benefit to try to make reporting easier for them and their, their responsibilities streamlined. This is a strategy from the beginning to remove redundant processes. So what we've seen when it comes to actually replacing paper, for example, the way to make that happen is to agree at the outset of the program. What is the strategy for deciding when to remove paper. If you do an evaluation after three months or after six months, what would need to be the, what would need to be the outcome of that evaluation in order to agree to remove paper. If you don't have these conversations at the beginning of your implementation, it dramatically lengthens the time that it takes to make those decisions. Because nobody is looking at it. Nobody sure what the goal is and whether they should be trying to change processes. And so it can take much longer to come to these kinds of agreements. And the design of your program we've talked a little bit about this before it should really take into careful account what all of your analytic needs are. You want to see from that steering committee that all of the different health programs have approved what data are being collected what analytics will be put out. You don't want to find out two months into your implementation that you're missing some key data elements and that you're going to now need to update all of your programs. You're going to need to provide communication to your users and perhaps some level of retraining. So you really want to know ahead of the implementation that you've covered all of your data needs. So infrastructure data again we've talked about a lot of these challenges in the beginning I won't go through all of those trying to stay on time here. But some of the recommended approaches here would be that you establish at the beginning, the processes you would need to maintain and replace hardware over time. So it's great to you you have you know 5000 Android devices that have come through a certain project or that have been budgeted. What is the plan for replacing those devices. How long do you expect those devices to stay in the field will they last one year will they last two years. What percentage of those devices do you expect to break or be lost. What's the process for someone to order or receive a new device. All of these should be kind of a part of your implementation plans so that you are ensuring continuity of the system. It's a it's a very challenging thing to spend all of the time and effort on building a program training people on it rolling it out only to have them lose an Android device six months into the system and get no replacement. That ends up being then a lot of wasted resources on a system that they can no longer use the landscape review of the other digital health interventions and consider the combination so what already is out there how many different programs are are the users that you are targeting, supposed to be using already. Is there a way to combine data collection in those systems do you need to make those systems interoperable. Is there some way to maybe replace one of those systems so that you cannot have redundant systems. Review the hosting guidelines plan for increased requirements. So if what you've put together is the bare minimum for hosting as you roll out one tracker program. You already know you'll have a problem for any health program that tries to add, which is the most common thing that we see as soon as you know TV gets digitized program at the provider level. HIV is going to want the same thing. And so you want to make sure that you thought through how would you increase your posting capacities when you bring in other programs. Again, we'll have a specific session about security and privacy kind of guidelines and what the policy approaches are but this is something that you'll want to do with the outset. Try to have an approved policy in place, something that the different health programs have all agreed to that the Ministry of Health has signed off on, perhaps that is even approved or in line with the legislation in the country. So that there are no questions six months into the system about whether it's adhering to expected requirements. And then on the hosting topic again which will dive into a little bit more. We know there's often kind of default expectation to host at the Ministry or at a local hardware server approach. And this is something that requires a lot of additional expertise and can be something that over time costs more as you try to replace hardware and think through your requirements. It's much better in many cases to outsource that challenge. The kind of expertise that it takes to run a large scale nationally scaled tracker implementation for hardware is something you might not have the expertise in the Ministry. And it's often difficult to keep those people employed because of course in the private sector somebody that is very skilled at database administration at managing you know thousands of users at dealing with any hardware challenges that come up. They can receive better salaries outside of the national public health system. And so it can be very difficult to try to fund those people internally to manage a locally based installation. It's it's worth having the conversation even if you have heard before and you know that they want to host locally. It's worth approaching the conversation again in the context of these like nationally scale tracker considerations. For the geography. We've already talked about some of this increase your dedicated it staff at the national level as well. I know that they are well staffed to be able to provide the kind of support, even to your secondary level. So if what you've done is established a district level frontline support. Those people still need to have somebody at the national level that they can refer problems to or they can ask questions to you want to make sure that you're not overwhelming your national IT staff because there's been no increase in staffing despite a dramatic increase in needs. Again, cascade kinds of trainings perhaps is the way to go. It depends on what your resources are in your timelines, but you may want to think that you actually are going to do a slower roll out than you would do for other kinds of systems, because you only have five training teams but you need to cover, you know, 55 districts. It can take a lot longer than you would have expected from other types of IT systems that are rolled out. Consider establishing a hotline for reporting system problems. This can be through a phone and phone number that people can reach out to for immediate support. This can be through an SMS message that they send this can be an online support system and actually probably could be all three of those. But then of course you need to staff that hotline as well. You need to have somebody that knows the system that can respond that can escalate real problems to make sure that there are no system gaps or downtime that don't need to be there. And routinely conduct reviews of the system with the IT support team and adjust the support accordingly so that you're learning over time as well. No implementation plan is going to be perfect from day one, but you want to have a process for thinking through what improvements can be made over time. So I'll end here I think on the general recommendations put significant effort into managing expectations from the outset. This this kind of a list of the challenges is something you can share with the national programs with the ministry people that are responsible for making decisions so that they understand what they're getting themselves into. And this helps, you know, three months from now when there's when you haven't met timelines or if there's some unexpected need for more resources that it's not as surprising that you have an over promised. Again, communicating that these implementations are difficult. They may be kind of the largest implementation that your country is undertaken. And so making sure that people are aware that that comes with challenges. There's going to be some long term budget discussions around all of these different pieces. So, again, having a plan for this year on how things are going to be budgeted is great. What are you going to do two, three, four years from now with the expectation is that you're building a national system that has become a part of your public health resources and needs. You're going to fund that indefinitely past the life of the current donor cycle or the current project that is funding. So getting some agreements at the highest levels that perhaps after two years or after three years of funding that the government will have, you know, increased resources to give to it support, or that there would be a review process every two years around hardware needs and where the budgeting can be found for that, for example, go slowly is a is a standard recommendation. Try try things out. See how the training are working adjust as needed. See how many it support requests are coming through and if you need more resources before you add more users and use a phased rollout approach so that you're you're rolling out not based on some deadline that we want this all done by August, but rather you are expecting to grow a mature system and you want to evaluate it over time as you roll it out and make sure that you're meeting your objectives so that you know the system is working in one location before you're moving it to the second location or the third. And again getting the most out of these individual level system does mean replacing processes. You don't want to duplicate reporting all the time you don't want the users to be coming in on their their days off to try to catch up with all of the work required in a digital system. So try to establish these expectations from the outset that you're hoping to replace processes and make life easier for the users. And so how will you go about doing that. So I know this was this was a lot of information all at once. Usually this session would be one where we have a lot of interaction back and forth with you to learn more about your country and what you think the some of the challenges are. So I'd really appreciate it if in the questions you can pose, you know, your own concerns considerations or concerns. Of course these slides will be available to you so they are hopefully slides that you can use when talking to partners in the country, and when trying to explain some of these difficulties. So hopefully these will be a useful resource, and hopefully they will also feed into the sessions that you have around the long term planning and the planning documentation that you're doing. So that you think through what the budgeting implications might be or what the training implications might be. So again we'll make these available to you you can hopefully follow up on on any of them that you want to have additional information on in the slack channels. On that I better stop talking so we have time to move on to the next part of the session. So Marcus, I will turn it over to you to take us into some more of the hosting considerations. Thanks a lot, Mike. Just gonna share my screen. I trust you can see my screen. Good morning everyone. I'm Marcus, I'm gonna pull us through this next part which is about hosting of tracker systems. We are gonna talk about some of the decisions that you will be faced with as managers when you are gonna host the tracker. We are gonna lead into some of the discussions and also try to help you answer some of your questions on what decisions you have to make. With me today is also Bob is one of the people who knows this topic best and will hopefully be able to help me answer some questions. And also chime in with his points of view as we go here. And with that, let's look at this old friend the house. When we talk about house hosting. It's natural to think about the very top layer of the foundation there called infrastructure. And hosting is about setting up and managing this infrastructure. But I would argue that there is also other rooms that is involved in the tracker house when you're setting up your hosting. Today we're gonna spend some time on five decision points. And the first one is whether or not to set up a new or instance or use an existing instance if you already have DHS. In some form or fashion do you want a new one or do you want to set up the tracker on an existing instance. There is many things that comes into this discussion and we will look at that question a little bit more closely later. The next part is the architecture of your solution. What is the setup you need in terms of servers in terms of other interacting services. And what is the environment you're setting up your tracker in. The third decision point we will discuss is whether or not you want to mic touch on this briefly. Whether or not you want to buy the DHS software as a service. Whether you are buying infrastructure as a service and setting up DHS yourself. Or whether you use some form of local hosting. In your data center for example in the government data center or in your basement. So we're gonna talk about things that goes into this discussion, this decision. Then on the backup restore routines you will have to make some decisions on what is the acceptable level of risk. And what is the acceptable level of loss in case of a disaster. And also what is the requirements for your restore in case there is a disaster. And lastly monitoring what type of monitoring are you gonna set up and how are you gonna use it. So the way this is gonna work is that we will spend some time on each of these topics. And we will answer in essence a few yes or no or a few questions that has three or two or three possible answers. And while we are doing these slides and looking at the questions. There is a mentor going. And that you can answer the questions together with everyone else. And the mentor code is here and it's going to be shared on the on the chat. So please go ahead and log in. But wait, do not answer the first question. You can open the mentor but do not answer the first question. We're going to do that together when we look at the slides. I will let you know when we're going to answer the first question and the second and so forth. So when it comes to before we start diving into the questions we can talk about some general ideas that goes into the requirements for your hosting. Your pro project will have some requirements and you have to review the scope of the project. There's a very big difference between a small scale. Silo project for example malaria vector control. Or a national HIV tracker. And this the scope will inform many of the questions we are going to look at together. Another thing that informs the decisions are how your programs fit together. If you need interaction between the different programs that you're setting up. And if you need your data to travel between the different sort of instances or concerns. Whether you have aggregate or not is going to affect the rest of the questions we're going to ask here. So for uptime this is another another big driver for some requirements. Your users might need more uptime if they are actually entering data live. Instead of back entry the users might might also either work during the day or they might work during the other hours. We have seen that in covid surveillance the covid teams and in stressed situations are working from very early morning and very late in the evening. So other things like an HIV tracker might have a more working hour related uptime requirement. If it's down in the evening for a while it's not a problem and mostly during work hours. So the IT support unit is also part of this. Are you prepared to have support for your users? If you now have thousands of users it's going to be a big need for support. And if they're working outside working hours what's the plan for supporting them? And when are your users going to connect? How is their access to the internet for example? Do they probably have to work in the night because the internet falls down during the day? This might be a consideration to take in. The last thing on this slide is the consequences for unplanned downtime. If you get a downtime that wasn't planned what will actually happen? If the system is being used replacing paper this might be a huge problem, a practical problem. If your system is the clinic system that is actually needed to see patients unplanned downtime might be a disaster. Whereas if you do back entry it might not be a huge problem if the back entry gets delayed a bit. Also in an Android setting you are more resilient to unplanned downtime than you would be if you're using only the web. When it comes to tracker versus aggregate there are some considerations that we will get into. I won't spend too much time on them now. Tracker might require a newer version of DHS2 because of functionality and late play stability and performance. The later versions of DHS and later point versions is much faster than the older ones. The other potential thing to think about is security fixes. You want to stay on a new tracker version because we put security fixes into the code. If you're on a very old code base that is not supported anymore for example these security fixes might not come so easily to you. This is of course a problem also in the aggregate world but in the tracker world it's usually a bigger problem if your data is not as secure as it could be. The requirements for access control might be higher in tracker than in aggregate. The granularity of each user's access might be different in tracker and aggregate. Marcus can I chime in with a quick comment? Pick it up on your point that tracker requires a newer version of DHS2. It's also important to bear in mind I guess that you need to not just implement a new version but you need to keep it up to date. Part of the planning process should include doing regular patching of your DHS2. Sometimes it's something that we don't take into account, we don't take the budgeting for it or the time out. It's important to realize it's not something that you just install and then you're going to run for the next five years. You're going to have to upgrade it typically at least once a year. You're going to have to do patch upgrades perhaps a few times. That's a great point. We also brought it up in the long term tracker maintenance session earlier for those who attended there. The point releases are generally released on a six week cycle. So even if you're on the very latest version today. In six weeks there will be a newer version. And this newer version will contain fixes and it might contain security fixes. So, as Paul points out, this is an ongoing effort to stay on the latest code. That is under much more pressure on the tracker instance than it might be on your aggregate one. The last point I had here was on the disaster recovery. The requirements in Tracker might be very different than aggregate. Both in times of how long the timeline will be for restoring the data. And also in terms of data loss. If you have a tracker instance then there will be data coming into that instance. Much more frequently than on an aggregate instance. And if you have a disaster, then more data will usually be lost. And it might be harder to find this data again. If a lot of different users, a thousand users and a little bit of data, it might be much harder to get back the data loss. Okay, so to jump into the first decision point or first question, we will talk a bit about whether or not to set up a new instance or use an existing instance. What we mean here is if you have an existing HMIS like this and you're going to implement a tracker project, you might simply put new programs for this new tracker project inside the existing HMIS instance. That is one option. We're going to talk a little bit more about the pros and cons of each option on the next slide, but just introducing what I mean. The other option is if you have an existing tracker instance like this, you will have existing programs and metadata and you might put your new program on the same instance as your existing tracker. The third option is to set up the new tracker on a separate instance and make the new programs on this separate new instance. So these are the three options that we should consider together. You can see the menti code repeated at the bottom of the screen there. We're going to go through some pros and cons and then you can reply to menti1. When you reply to these questions, please either think of the tracker project that you're about to plan or about a tracker project that you have done. Or if not, then you can make your hypothetical tracker project an answer from the point of view of this hypothetical tracker project that you mentioned. So the first question, new instance or existing? First option, do I add the tracker to an existing HMIS aggregate instance? And the pros is that the pros I could think of is that there will be less complexity in the architecture if you do that. If you already have a server and a database, then setting up a new instance or adding to this existing instance might be the simplest option that produces the less complexity in the architecture. It might also be slightly easier to connect tracker and aggregate data and visualize it together in dashboards. This one got a little bit of a smaller font because it's not super hard to move this data between the instances either. And this is the topic of the next session with ULA. And you should, but it is a pro, I would say. So for the cons here, we sometimes see conflicting requirements for time and security in the tracker versus an aggregate instance and there might be routines and there might be practices on your aggregate instance that is not good enough for your tracker projects. There might also be older users of your HMIS, so there is no, not only do you get no help from the existing users and setup on your HMIS, you might actively have a problem in that in the HMIS instance you have some users that are super users that should not be able to see or track your data. Super users is a super bad idea in any case, you should have as few as you can, but in HMS there might be different super user than the one you want to be super user or your tracker setup. Also there will probably be very little metadata overlap, the org units might be one of the areas where you have an overlap between the tracker and the aggregate, but it might also not be. It might be that the org units is not matching. Do you want to add something here to this one above or I'll let you chime in. Yeah, the next question. Yeah, you did. Do you want me to answer? I just wondered if you had any other thoughts on the first point, other pros and cons or thoughts about what is here. I think you've covered most of, I suppose also stability you haven't talked about, you know, often the HMIS system is something that may have been there for for a number of years and it'd be quite stable and does what it does. And introducing a tracker program to it. Very often, particularly in the early stages of implementation may introduce instability to your HMIS, which is generally something that people want to avoid. That is, that is true. That's also a point that is brought up on the next question. Do I add a new tracker to an existing tracker instance if you have an existing tracker. Then you might get the pro of a longitude note record that goes across different services. If you already have HIV tracker. And you're introducing your COVID tracker. You might say that it's tempting to add the COVID tracker to the existing HIV tracker, because the record will then any person can probably be enrolled. Either in the HIV program or the COVID program or in both and if they're enrolled in both, then you have a very nice longitude note record for that person. So this might be one reason to combine the trackers, especially if you have functional needs that goes across the different services. And you want your family practice tracker to involve modern child health or ANC. Then combining the trackers in one instance might be what you need. Another pro combining trackers is that the overlap between metadata might be much bigger and you might have data elements tracked at the attributes. You might have defined a lot of reusable metadata for your new instance if you already have an existing instance. And you can harmonize the data elements and maintenance across the two instances. So some of the cons, the first one, are you actually only used longitude note record across services? That's like a counter asking the question. If you have an HIV tracker and a COVID surveillance tracker, will you actually end up having any practical use for combining these two things? Will the HIV personnel have access to the COVID data and vice versa, or will you actually not open up this and use this for anything? Another con is the same as the pro. Already existing metadata might also be a problem. Already existing metadata might be a source of a conflict. And if you plan to integrate your tracker instances, then you should plan for quite a lot of work to align the metadata between the instances. It might not be the same. And it might need functional discussions. It might need a process to align the metadata between the instances. And another con is the server resources being shared. If you set up two tractors on the same instance, it's much harder to scale because they will consume the same server resources. So many of the COVID surveillance and vaccine setups lately were set up on a new server for this reason alone. They were expecting to push the limits of what a tracker can do. And if you're expecting to push the limits, then you should not set up two tractors on the same server. So for COVID, many ended up with the third option that you will see in your mentee. That was not really listed as an option explicitly, but that's setting up this as a new instance. Please click the answer in your mentee and select one of the options and then we will go on to the next slide on the architecture side. One of the questions that you should answer is whether you run the database and the application together on the same server. And some pros is of course less complexity in the architecture. If you have several servers running different parts of architecture, that's more complexity for you. And it might be cheaper to have just one server if that's an option. The colonists just simply that it's harder to scale the server resources are shared between the application and the database. It might also be slightly harder to moment. Sorry, go ahead. There's a nuance to that. One thing that's quite common to do is you might have the same actual server, the same virtual machine, but you might run your database and your DHS2 application as separate containers with it. And that's very, very commonly done. And that has some of the advantages of both really, you've got less complexity in the sense that you're just managing one virtual machine. But you also have the advantage that you can quite precisely control the amount of server resources that are allocated to the database and to the Tomcat. So it's a, I guess a hybrid of the two approaches in fact is probably the most common. They're running on the same machine, but they're running in separate containers on the machine as virtualization within virtualization. I see that Abdul is also asking a question about this. So, if you're setting up two different containers and running it on one server, they will be the two instances are not are competing for the same server resources. But it might be easier to scale if you do need to move the database to a different server later. And it might also be easier to monitor the two containers differently. I see that Abdul is using a software as a service provider. And this question was most close to him, whether to run this on a different servers or together. Do you know anything about this? If you're ordering software as a service, you might get less insight into how the underlying setup is actually working. Yeah, I mean, I don't know too many software as a service providers and the real systems will be the most well known one. And I think in their case it's a specific offering you decide whether you want to run it. I think they have different sized instances and the smaller ones will run together and the larger ones can separate it. There is something to bear in mind if you're running in the cloud in particular and you're running your database separate to your application. It does mean that by default all of the traffic between your DHS to your database is potentially running in plain text through your cloud providers network. And so often you would need to know what you should really do is on your when you're setting up your JDBC connection, you want to use SSL on that connection. So that the traffic between the database and the DHS to instance is all encrypted. That's the other advantage of containerizing them because if you run it on the same actual single machine but you run them in separate containers, then the traffic is never is never traversing through the cloud providers network. Yeah, I think with it, with the SAS offerings, typically it's a choice for the price point. It's what I call the boom box, right, you can have a boom box, which everything is all in one, or you can have a component. And one costs more than the other. And there are security considerations to bear in mind if you think about the traffic going through the cloud providers network. We will also get a little bit into the different options of SAS or the other options later here. And Bob will also be able to answer and give some detail on this on the questions channel if there's anyone that needs that wants to follow up on this. On this security consideration for running a SAS. Another thing to consider is semantic question to be and that's other applications in your ecosystem. You can just go ahead and answer QA if you have an answer. And then an answer to be you might be in an environment where you need to connect to other other types of systems or other services. If you have a SMS service, you might need the rapid pro integration. If you're working close with the hospital, you might or someone using open MRS, you might need to connect with them and transfer data integrates. There might be a civil registry that you need the data from or potentially send data to you. And there is no general answer general, general. We will questions that can be can be answered generically here. We invite you to be to put in into the world cloud what your environment looks like. So, please go ahead and enter into meant to be if you're if you have any considerations in the landscape in your ecosystem that is relevant to you. Next, the next topic is services service infrastructure as a service or local hosting services. It means that you would pay someone to run your DHS instance for you, and you would have less insight into the underlying system. You would not probably not have access to the server either infrastructure as a service means that you would rent containers you would rent servers. That you can access to your command line or to log on to but the hardware is actually hosted somewhere else and the hardware is run by someone else. This might be a variant of this might be a local software, a local infrastructure provider that might be running a local data center for you. And you would rent access to their servers. The last one is local hosting and this is what I put in this bucket is everything that essentially means you have to make sure that the server hardware is running as well. And everything from the hardware and up is your responsibility. So some pros for software as a service. It's super easy to get started by far the easiest one. Usually you just contact one of these providers and you get a login to the DHS instance and you can start working. And the time for the both the hardware and the service is included. You wouldn't be responsible for keeping the service up. Also monitoring and often upgrades might be included in this package. You might get alerts and they might monitor your server resource consumption. And potentially also have an upgrade plan. At the very least, if there is an important security update, they might intervene and let you know that the server has to be upgraded. Some cons is that you probably would not have access to the database or the server because this is their responsibility and therefore they don't want you to mess around there in their server. If you need to log on and run SQL and so forth, this is probably not going to be an option or software as a service. You also get a little bit of a higher dependency on external parties. I mentioned help this here. I've seen that many times that we are trying to help someone on the software as a service plan. And they need a custom war file or urgent update SQL script, something like that. And to actually get this run, they would have to go through a third party and this might be a problem in some press situations. It might mean that some things takes more time. For infrastructure as a service, just a reminder, this is renting a server more or less and then you have to put on the software yourself. You have to install the address and database and do everything like that yourself. The pro of this is that the infrastructure of time is guaranteed through what you're renting. You will not be the one that handles hardest crashes and hardware. It's often easy to scale and upgrade if you're running your service in a smart way. It might be easy to migrate to a bigger server if you need that. Some cons is that this is recurring costs. This is the same as above, of course. If you're renting something as a service, there is a recurring cost every month. The other, not really a con, but something to think of is that if you're renting the infrastructure and you're setting it up yourself, you will need local capacity. Someone in your team needs to know how to set up and configure this server. Mike, you had your hand up. Yes, sorry. This is just a time warning that we're a bit over time. So just pointing it out for you. I'll try to speed up a little bit. We might use a little bit less time on that. We might go back to it in the break after Jerry. Please answer the tree as we're on this slide. Do I use local hosting? You can. This will give you full control over hardware and software. But I think maybe more of the main pros of this is that the main cost will be upheld. So buying the server, buying infrastructure will be upheld. It might be easy to get this budgeted into your project when the project gets funded and harder to have a recurring cost. Cons is, of course, that you have to plan for both hardware and software failure, which means setting aside funds to replace hardware. If something breaks, you have to have the knowledge on how to replace it. And all the infrastructure at time is the team's responsibility. You need to have the capacity for running all the aspects of a server. For a large-scale tracking implementation, this means that you need a really professional team. And you should have people in this team that has done this before on other software or on the HIC, ideally, but on other software have run a large-scale implementation and know how this is done. So Mnt4 now on the backup restore routines. Frequent say is the first question, do you need a mirror site and continuous backup and a disaster recovery without data loss? So this means that you, in essence, everything that gets saved in your database gets saved twice. This is what you do if you cannot accept any data loss. If it's not okay with the nightly backup, if something goes wrong, then one day of lost work is not acceptable. Then you need to have some sort of mirror site or continuous backup running. This is possible to set up with the database failover. If the database fails, you might automatically failover to the mirror site and the users wouldn't see any downtime if the database would fall offline. This is, of course, very high maintenance. That's the call. Very few people do it. It would have more costs from more hardware. So what many people choose is to live with a backup recovery plan to potentially lose some hours of data but not a lot of data. This might be manageable in many cases. That's why it's chosen. The cost and maintenance is easy. It's more or less just setting up an interval and doing a backup and storing that backup. The con, of course, is that some of the latest data would be lost if you have a disaster. The last option is data loss of so little consequence that you can live without a backup. The pro is no cost. The con is you should always, this was a trick question, you should always backup your system. Yeah, and please, that was cement before A. So please answer that question in your slide. The next one, backup restore routines. Do you need to keep a longer backlog of backups? And the pros of a longer backlog is that you can recover data over longer periods. If someone did something by accident and notices it the week down the road, you might recover it. And also when investigating problems, it might be nice to go back a few weeks or a few days at least. And we store an older backup. And the only con is that such backups takes more space. There's also the wrinkle of backups kind of backups are very sensitive. And if they get spread around, then that's sensitive data. Let's get spread around. So keep how and where to keep your backups is a very important point. Do you need an office? There's also another. There's a refinement over keeping longer backups because you, you can't keep a daily backup forever. Because the space requirement obviously becomes too much. But what we typically would do is you might decide, keep the last seven days back right on a rolling sliding window, but then also keep the weekly backup, maybe every Sunday's backup. And then you can keep that for six weeks. And then you may keep the backup once a month and keep that there perhaps for the last 12 months. So you kind of lose granularity as you go further back in time, but you're still able to get it back up to restore them from this time last year. That's the way I do it. That's a good point, Bob. Thanks a lot. The last one is living in an offsite backup. Offsite means you store your backup somewhere else than your, your data is there, your service running. And this is resilient to real disaster. Something strikes your data center or knocks out your service provider. Then you might actually not only lose your day to day instance, you might lose all your data and all your backups if you don't keep it off site. The con is that it might be more expensive. If you're transporting it over the internet, that might also be a hurdle. But it's something to think about. If you don't have it, then it's nice to make a note that you don't have it. If your data is stored on the same, on the same site, then there's a chance you might lose everything. That chance might be very, very small, but it's there. And sometimes it's not acceptable. The last monthly question is on monitoring. And first question, do you set up an application to use database? Do you set up application and database monitoring? Do you do it? Yes, you should because it makes it possible to see problems before they hit the users. You can see the server health deteriorating. Also it makes it possible to do retroactively inspect events that is recorded. The cons is not really there. I mean, you have to set it up, but there's not really other cons setting up monitoring. So we recommend that you do that always. Of course, you need to have a routine for looking at it from time to time or using it as well. But even if you don't have a very good routine, it's important to have the monitoring there to help recognize something that's arise. It's nice that it's already been capturing data that you can go back and look at, for example. Do you set up automated alerts? Yeah, you can. It makes it possible to get automated messages if something happens. Irrespective of if you have the poor routine for looking at inspecting the server, even if this is a good routine, then something might happen late at night and it's useful to get the message. The cons, it must be so that this automated alerts are not a false security. You will only get an automated response on data that you already set up. But this might also be a reason for not checking the server health yourself, which might be needed. And if you don't set up well, you will produce noise for yourself that you wouldn't pay attention to. Or it would not report on something that is actually important. So setting up automated alerts might be nice, but it takes a bit of effort to give them useful. Okay, that was my last slide, and we are a bit over time. So I think I will give the word to Jerry now. And then after Jerry, and in the break, we will have a review of the questions. I will go to Mendte, and those interested can have a look. I will also paste the results after these slides so that you can see them later. But right now, the word of the day is, ain't no mountain high. And I will give the word to Jerry. The word of the day is, ain't no mountain high. I hope you all hear my voice. Okay, great. So I'm going to talk about two approaches that we had for scaling and hosting. The difference was mainly on scaling, but hosting is probably the same thing. But I'll talk about all these. So we actually have a tracker for tracking people living with HIV and key population, and this COVID vaccine tracking system. So for the background related to the key population, tracker that we have, and people living with HIV, it's a tracker that we developed for FH-360, and it's actually a tracking system. It's a tracker that we developed for FH-360, and it's actually capturing data for people living with HIV. So you have, first of all, for key population, you have counseling, testing, socialization, condom distribution, and so on and so forth. And then, I mean, for ART treatment, we have a specific tracker where you could actually track the ones that are on ART, and we get the information about treatment received. We can actually identify lots of follow-up. And this information, this tracker is used at the service interview level to keep track of the people, the key population, the people living with HIV, and also to do some basic analysis because they also need to know the number of people that are lost to follow-up so that they can identify them and track them. At the central level, they use aggregate data for analysis, and they also send it to donors. For the COVAG package, so we actually build on the COVAG package, and then we actually tailor it to the country's needs. So at the service level, it's actually used to keep track of people that are going to be vaccinated. So you have a platform where people register, and then after that, they get a schedule for their first dose and then their second dose if it's AstraZeneca. At the moment, we mainly use AstraZeneca, so it's two doses, but the others are coming, so we have this possibility or this flexibility of actually having many doses. But they actually keep track of that, and we have an SMS that actually sends reminders to people that they are going to have their second dose. And at the central level, you use that to see the progress in the immunization process because they want to know how many people are being enrolled and how many people have been vaccinated, how many have the second dose, and so on and so forth. And this is actually done weekly, so we have a weekly meeting regarding that. So what it comes to scaling, for the tracker for HIV, we have people living with HIV, we have around 200 users, 260,000 tract entities, instance, and 80 organizations. And then for the COVID one, we have like 5,606 users, and then for the tract entities, instance, we have 305,947, and then for the organics, we have 1,727. So this is just a comparison that we have when it comes to the approach, the scaling and hosting approach. So for the data entry for the first tracker, which is the one for people living with HIV, we have the service providers collecting the data on paper, and then they send the data to data players that enter the data. For a rollout strategy, we roll out at once. We didn't do a phase approach, but it's actually due to the fact that we actually didn't have a lot of health facilities, so we could actually do that at once. User support. Okay, so they have a team that, because it's every time 3,60, they have a core team that actually helps people or goes to every facility to see their difficulties. They check out the data and there's a problem. They ask the health facilities to see what is wrong with the fact that they are not entering the data and so on and so forth. So they are trained to actually handle basic troubleshooting. But if they are intricate things, they actually ask us to help them, so we do that a lot. But we also work with them, because sometimes some of the users have our contacts, sometimes they even write to us on WhatsApp. For the HIV, they actually use laptops to enter the data and they actually, they have an office where they enter the data and then there's always electricity and internet connectivity. For the hosting, it's cloud hosting and we actually have a separate instance. It's not part of the Togolese instance, because it's actually Togo and Bukina here and we don't have it in any national instances, a new instance. We have daily backups and we have regular updates and we actually monitor the server. But for this one, the good thing is that we have access to the server. So we actually hosting it. So we have a lot of mechanism to make sure that the system is regularly backed up. We monitor the server so that it actually has always, it's always up and so on and so forth. Now for the second one, for COVID, what happens is that the service providers are the one actually entering the data directly. The rollout was phased because we started with the capital city and they started vaccination at capital city and then after we roll out in the whole country. So it was a phased approach for that. Actually, the HMIS team was trained for basic troubleshooting. So the HMIS team actually works on this a lot, but we actually intervene in some of the times, especially when they have intricate things. And we have a telegram platform where we actually talk a lot and if there's an issue, we try to solve it. But we work alongside with the Ministry of Health and there's a Ministry of Digital Economy too. They are using the Android phones because they are going to be in places where they don't usually have internet connectivity. So using an Android phone could help them have the data stored on the phone and then send onwards. So it's actually hosted in Togo. This platform itself is hosted in Togo by the Ministry of Digital Economy. And it's a new instance. We actually do daily backups because we also have access to the server. They also have access, we have access. So we added things to it like we have the monitoring app, we set up a daily backup, et cetera, et cetera. But the server is here actually in Togo. Okay. So what we've learned, when it comes to user support and when it comes to data entry, we realize that when you actually have data clerk, sometimes they are very good at using the hardware and software. But the problem we have sometimes is that they actually don't understand what is written on paper. Or sometimes there's a problem with handwriting. So there are sometimes mistakes or data quality issues that come from that. Luckily in most cases, they tend to be next to the service provider. So they sometimes go to the service provider and ask them that this sounds a bit, I don't understand how this is written. Can you explain it? So sometimes it is solved. But sometimes there's also some problems with the quality that is actually detected afterwards. And then we try to solve it. But that is one of the issues. The rolling out strategy for a small amount of facilities can be done at once if it's possible. That's what we've done because we only had 80 facilities. The support we realize that we had to intervene a lot when it comes to maintenance because there are slight issues here and there are performance issues. So we had to even work on the server sometimes. So we were more involved in maintaining the system, the server or the DHS to instance itself. We realize that when you are using laptops, when you don't have low bandwidth or you have primary internet connectivity or you don't have electricity, it might be tricky to use it. So there's a need to do that. You need to actually make sure that you have those requirements before setting up something on the laptop. Well, we also realize that hosting you probably need to have a very high performance server. It's very, very important to have that when you have it, you need more performance related to the aggregated server. When it comes to the vaccination, we realize that some of them, some of the users were not really familiar with the hardware, especially outside of the capital city. So they were actually community workers that actually know how to deal with the data, but they don't know how to use the hardware, not the software. So there's a need to actually follow up a lot. And then sometimes you have mistakes that are not used to the fact that due to the fact that they don't know what they are entering, but due to the fact that they don't know how to manipulate the system so they create duplicates and so on and so forth. Well, the rollout is recommended. In this case, since it's a lot of facilities, it was recommended to have a phase rollout that we did. But we actually had to work a lot on the maintenance area to solve some of the issues because we also had a lot of duplicates because of the first problem I cited, the first challenge I cited. And then we also had issues with the Android. So the Android version has, I mean, the web version has some features that you don't have in the Android. So we were a bit stuck sometimes, and we needed to change some of the things with it. When it comes to devices, Android phones are sometimes less convenient to users because of the size of the screen. And then you also have sometimes problems with hardware and software compatibility. Because in this case, for example, they actually use a previous program laptop phone. So the phone is a bit old. Yes, it's actually what we were able to install the app on it, but the RAM is low. So the performance is a bit slow, but they actually use, instead of buying new phones, they actually use phones that are used for another project. As for hosting, since it's hosted in Togo, of course you need to have a lot of high performance. But the good thing is that we have high-qualified IT specialists in the Ministry of Digital Economy. So they were able to actually help us to actually work on the server so that we didn't have a lot of problems implemented. So quickly, this is what I can say about our experience in the approach of scaling and hosting. If you have any questions, feel free to ask. I'll be glad to answer over. Great, Jerry, thank you for that presentation. And it was really useful, I think, to see the different strategies employed and kind of the differences between the tracker implementations, which is definitely the case.