 So just quickly before I start the next session, just so you know for all the work that you've been kind of these diagrams and everything. We're going to give you an opportunity tomorrow to discuss these so we want to discuss all the different components as part of this exercise together. So that includes the capacity building exercise that we were working on before lunch, this architecture exercise, and we will have a couple more that tie in to this implementation planning. Oops, that tie in together right so we'll have some time tomorrow and will allow you to present your work what you've done. If you have any questions or clarifications on anything that you've kind of made. So we'll just because it's a big kind of joint exercise even though they're separate components we want you to kind of think about how all of these pieces fit together okay. So don't worry we are going to discuss the diagrams and the different components of the system that you have identified, and we'll make sure to allow you to present that so just over the evening and you can present in Arabic tomorrow if you want to. Okay, but we will ask some of you to come up in order to just share your work. So we can see what you've done. Okay. All right so in this this last session of today. We're going to talk about infrastructure and hosting, and we do have a couple exercises prepared for this session as well. Okay. So this ties in quite neatly with some of the principles that Olaf was discussing regarding architecture. All right. So what we would like to do as part of this presentation. We want to identify some of the various infrastructure components that are associated with DHS to implementation. We want to understand how DHS to implementation shapes infrastructure needs, because there are some specific components that are required to really make the implementation work. So to understand some long term maintenance issues, understand the implications of using DHS to on a mobile device. So some of you have brought this up in particular the ability to work offline. Right. Describe a high level DHS to architecture. I think this has been covered a little bit already somewhat. We want to kind of get into the server hosting components. So understand the different hosting options that are available. Understand the skill sets required to actually host servers for DHS to and be able to create a plan for hosting of these servers. Okay. So we'll start just by discussing some of the technical infrastructure associated with DHS to implementations. So here are some of the components on screen some of the kind of hardware requirements that are needed in order to get this up and running. And this is kind of like the minimum that's needed. In some cases right. So you have the DHS to server itself, and you might have at least one server could be physical or cloud based. Okay. And then we'll have maybe another server for backups. Right. And we never recommend that you keep the backups, especially if it's physical in the same location, because if something happens to that. You know you're in trouble right. We also have then the actual devices that people are using to enter and capture data and analyze the data right. This could be laptop computers desktop computers, and we could also have phones and tablets as well for capturing data and also reviewing data as well in the field. So, at least some of this typically exists. Maybe you don't have, you know, a component of this, for example, you might not have mobile data collection. I mean that case you wouldn't have phones and tablets in the picture. All right, so the whole idea that we're kind of going to kind of try to convey is that, you know, we can make these systems run, and especially initially there's maybe a lot of kind of momentum. But we want to put it together and kind of a robust scalable fashion, right. And the whole idea is that it needs to be available all the time. It needs to be available, not just, you know, shouldn't be turning on and off at random intervals. And this is something that needs to be available, kind of, for a very long time. And as the scope expands of the system, you know, there might be some modifications to your routines to make sure that it can be still be used correctly. And you might have then as the system grows, thousands of users as well that are connecting to the system. Okay, so we kind of split this up into a couple different categories in terms of the key infrastructure requirements that are needed. So, the discussion on servers, I'm going to leave that later on will level come up and explain a bit more about servers and hosting. Okay, I'll focus on some of the other areas, power and connectivity and user devices and it support. So, one of the kind of key things we look at when we're considering infrastructure is not just kind of the initial implementation, right, because maybe things work, you know, during a testing or pilot phase. Okay, but the whole idea is how do we maintain these over time. And especially if you can think of if you're trying to reach maybe every facility in your country, right, that could be thousands of devices potentially. And they all need internet connectivity, they need power, and you need to maintain those devices as well. So, you can think about some ways and you might have this already, right in place in terms of managing that inventory of all those devices, making sure that you understand where, you know, what are all the devices in the field, what is their status, you know, and maybe some of them need maintenance and support as well. You may also want to kind of just practically speaking is if you have laptops and things of that nature, keeping spare parts around is often helpful. Maybe you just need to replace some memory or something. This can be way cheaper than buying another computer for example. But just to kind of add to that you do need kind of also people in place a little bit and we'll discuss that. Okay. So, the way we kind of think about these implementation concerns that was just a bit of background to give you a sense of what are the different components and probably seems pretty great. But the whole idea is that the way you're implementing DHS to kind of affects the level of infrastructure that you need. Okay. So, as an example, we can look at the level that you're capturing data to start, right. If you're entering data at a district level, then you know, you might not need infrastructure all the way down to the facility level. And, you know, this might be an area or a place to start in particular if you don't have devices power connectivity at that lower level, even though many people kind of want to make that jump immediately, and say okay I want to collect data from the facility immediately. It might not be feasible or practical. If you are however then collecting data at maybe a facility or even lower level maybe communities in the villages, etc. with community health workers. Then you know, you will have different infrastructure needs based on this requirement. You will have to make sure there's enough devices to make sure all those community health workers for example, are able to capture data. The type and the amount of data being collected can also affect your infrastructure requirements. We went through just a couple. You saw now a bit more practical examples of our different data types. Maybe if you're collecting aggregate data versus case based or individual based data. Right. This can really affect kind of a little bit in terms of the infrastructure you require because you know that the amount of data you're storing can substantially increase if you're collecting aggregate versus case based where case based will take up a lot more space for example on a server. And if you're using mobile devices or not this can also kind of affect what your kind of your infrastructure needs. As well as you know what's kind of acceptable for people in terms of downtime right because you can have a lot of measures to make sure basically things are operational 24 seven. We can kind of cut corners a little bit if that's okay if it comes comes down here or there, but we don't recommend that in most cases. All right so as a kind of concrete example, if we look at aggregate versus tracker data right so aggregate data is just numbers right and tracker data is our individual patient based case based data that we're collecting right. Usually aggregate data happens at different intervals kind of set intervals right maybe we collect this data monthly or weekly. I know there are some examples of daily collection but typically it's a little bit longer right, but then if you have kind of individual data this might be transactional this might be every day might be every hour it might be in real time. You have a person in the facility interacting with patients and entering that data as they're interacting with that patient. Right, so then you will have more individuals accessing the system, some more users. Right, you will have the data being entered more frequently. Just overall there'll be a lot more data collected, right, because aggregate data maybe 1000 cases is just represented by one value. You enter 1000 you move on right, but for case based system, you would be entering all 1000 records so there's you know the magnitude of data is much higher. Right, so you have to kind of make these considerations. And kind of the implement here we've listed some of the implications that are dependent upon the type of data that you're collecting. So, as an example, you will need more devices often if you're implementing kind of case based data collection, whether that be laptops or maybe mobile devices, especially if you're collecting data at the point of care, right, because you know you will need to cover maybe thousands of facilities versus aggregate data, maybe there's papers submitted through a process, and then you're entering data at a district level, as an example. You might also need different types of devices right. You might need a bit of a mixed or hybrid approach because maybe some areas have connectivity, maybe some don't. And if they don't have connectivity, you will need to use a mobile device of some sort. So, we can move on to the next point which is power and connectivity which ties in neatly. Right. We haven't shown much of the Android application or talk much about mobile devices in general, but generally speaking, if you're going to do anything offline. We recommend using a mobile device. Okay, this allows you to kind of collect data when you're offline and synchronize when you're back online. That being said, there are challenges to implementing that. Okay. But even being said, if you kind of are in a situation where you're evaluating your connectivity, and you find most facilities don't have internet, and it is kind of your goal to have those facilities enter information. You might want to consider using a mobile device of some sort. If you are using kind of case based data in particular, we don't recommend that you're interacting with facilities or locations that are offline for very long periods of time. Right. One, it's not practical to there can be a lot of challenges with actually synchronizing that data correctly and making sure people have access to the data they need. I'm servers and hosting. Well, we are going to talk about that a little bit more. It just as I mentioned, because there's so much data, you know, from a kind of hardware perspective, you need more hardware to kind of make sure it can accept that data. Right. And then a support structure right so I quickly mentioned this, but you need people to help with all of this stuff. Right. Not just from a DHS to perspective, but people to actually fix hardware. Right. Manage the connectivity to be maybe issues with users just accessing the internet. Maybe their device all of a sudden turns off and they can't turn it on again. It won't charge if it's a phone, for example, they plug it into the USB port. It won't charge anymore. Right. There's all these kind of little problems that can occur with those devices, and you need to make sure that there's some kind of support team that's available to actually perform maintenance on these devices troubleshoot and replace these devices as needed. Which means you also might need a little bit of money to buy devices as well to replace them if they just can't be fixed. Okay, so real quickly, I'm just going to discuss mobile. Because I think there's some considerations here for offline implementations. Okay, so for the most part, going mobile in DHS to usually means you're going offline. Right. If you have connectivity, a lot of people tend to be more comfortable with using a laptop. Just the general kind of consensus and skills within communities tends to be a little bit easier to implement. Right. Not to say that mobile device interfaces can't be easier in the end. But that's kind of generally how things work right now. Right. So when you go offline, what you're doing is basically syncing that mobile device with the DHS to configuration, and you're kind of going off into the field. So there has to be kind of protocols within your implementation to manage this. Right. It's very dangerous, for example, to start modifying your configuration when people are offline. Right, because then when they send the data, there could be a lot of problems won't sync correctly, and then you could lose some data, for example. So you have to be a bit more careful and implement more procedures and protocols when you're implementing offline data collection. Okay. There's also a lot of additional security implications, and we haven't talked so much about security yet we will talk about it more. Okay, but if you think about it now, your data is distributed across potentially thousands of devices. Right. And especially if it's patient based data, and there is any aspect of confidentiality associated with that data, maybe it's sensitive data of some kind that will result in bias or, you know, even just making sure that that person's identity is protected. Okay. If I just leave my phone out on the table, and it's open with the application, someone theoretically could view the data. Right. And you're thinking now of many, many users, potentially in communities and villages in other areas, where you won't have as much control over who sees the data potentially. So you have to implement some procedures to make sure that you are actually, you know, making sure there's some integrity of the data when you are kind of moving to this vast scale. And some of that data will just be solely on the mobile device as well. Right. Because if you're offline, and you don't synchronize the data yet, it's not yet on any central server anywhere. It's just on the device stored locally on the phone, until that person uploads the data. Right. So you just have to be mindful of these things. Okay. So there's a couple implications here for security and we'll discuss this a little bit more. Right. But, you know, you can look at kind of security from three separate angles if you're looking at mobile devices on the server itself. You can grant various access controls, you can maybe have some user based control right what type of permissions do specific users have, what data can they see, what can they edit. Okay. You also might only want to grant them very small, like, for example, if I work in one facility, you only grant them the ability to see data or interact with data in that facility. I'm on the device as well. Right. So there's some security features on an Android phone right. Some of them have fingerprint readers, all of them have the ability to add a pin number. For example, right. So you can protect the device, the DHS to app itself, right. The idea of just leaving it open like this with the DHS to interface open and someone being able to scroll through it. You might also want to lock that down so you can have some kind of ability to just make sure that screen gets locked as well. And then on the implementation side of things. So focus on one which is training your users on security awareness. This is probably the biggest thing right just kind of tell people to take care of their device. Don't leave it out. Most of the problems we have with security are not really related to any of this technological stuff that I've outlined as important as it is to have that really train your users when you're kind of moving to this big scale. So I've kind of been mentioning this a little bit. But this whole idea on the server and we're going to talk about that shortly. Right. When the users connect so so when you're on a web based laptop, let's say okay and you're entering tracker data, you might have a lot of data, but it's kind of synchronized case by case. Right, you're not uploading hundreds of cases at any given time. Right. So one of the challenges with mobile devices is that if they're offline, maybe they're offline for two or three days. Maybe they've captured data on, you know, a couple hundred cases. Right. So their amount of information they're sending at any given time. It's also much greater. Right, because they're not doing it one by one. Typically, it's usually maybe hundreds at a time. Right. And you could have many of these in parallel. Maybe in one community or in one village, there's more than one device or even several facilities and they decide to synchronize their data at the same time. Right. So then you could have thousands of records all of a sudden being added to the system all at once. Right. So just the scale and the operation. It can often be much greater than what's typical with the kind of web based workflow. So just as a summary for kind of the mobile data collection. Okay. You have to consider a bit more on the configuration side. Right. There's kind of key ways to configure the system to kind of work well with mobile devices. And, you know, there are some considerations there to make the data itself because users will just be offline for longer periods of time. You get more of it coming all at once. There's a lot more around the kind of protection and security side, which is kind of the next point there. Okay, your data is stored in these devices. Right. It might not be stored anywhere else until it's synchronized. So it's just completely stored on the phone if something happens to that phone or tablet, then you lose that data if it's not synchronized in time. From a project management point of view, you need to make sure that you have funding for all these devices that you can support all these devices that there's people to help troubleshoot all these devices. Right. So there's some kind of clear implications on budget, which will be discussed more tomorrow. And from the infrastructure side, you just want to make sure your kind of whole situation can handle all these extra requests. Right. So however you set up your architecture and servers and hosting and things like that. You just want to make sure it can handle many parallel requests and large kind of uploads of data, because if not, then it's going to kind of cause ongoing problems with these mobile devices implementation. All right, so, so just to get you thinking through this a little bit. Before we move on to servers. So there's this template here infrastructure and hosting exercise and Moodle should give that a download and once again I would suggest you stick within your teams your groups. Just open it up. Okay. So there's there's two tabs at the bottom here ones for infrastructure ones for hosting. Just ignore the hosting one for now. Okay. So let's look at the infrastructure tab and try to work through some of the questions that we're asking. So we ask you specifics about your kind of infrastructure situation. If you're are using mobile devices there are some extra questions. If you are using case based or tracker data versus aggregate data, then we also have some additional questions for you. All right. So just to give you a sense of what you might need. So let's look at this in practice. Right. So, time is four or five. Okay, so we'll give 15 minutes to do the exercise so at around 20 after four will continue with the remainder of the session. Right. Yes. Yeah, I wanted to find out, especially on the, the support on the infrastructure and hosting from the University of Oslo. I understand that I think every country as a kind of a savers that is being hosted within those within these countries. But from experience, there are some countries that are struggling or they have struggled before with a kind of, you know, having a proper backup to the main servers to extend that events, relating to losing that data completely imaged. There was one time in Malawi, we lost that data, and there was no other means of retrieving that data. Other than asking the users on the ground to reenter that data to the choice to match as we have these local saver hosting services. I'm not sure if University of Oslo can provide support to different countries to kind of having a backup within the cloud environment. I know it will go against the police of many countries where they are emphasizing local hosting, but at the same time I know that within the cloud. There was also an aspect of local hosting whereby you can create countries, countries, I would say country accounts that you allow their data to be localized within the cloud with access only to that country. So I'm not sure if University of Oslo is has that kind of plans in future to maybe encourage countries to you to follow that approach. I'm looking at the cloud services because currently the way DHS2 is being implemented or managed within the countries will find that users, they compile reports and then they transfer that data to DHS2 manually by entering that data to DHS2. But there are other technologies, support technologies whereby you can just scan that form instead of you entering manually you can just scan that form. And then that form gets to DHS2 and then you have the data entered to DHS2. So we are looking at such kind of services where we have a simplified processes to avoid much of these data quality issues. As it stands, we are failing to move in that direction because of these local server, I mean local data hosting arrangement that restricts that kind of investment or ideas. Sure. Thank you. It's a good question. I don't know if Olaf wants to, maybe he's going to talk more about hosting in the next session, but he might just have something quick to add. Yeah, no, I think like you said the next next part of this after the exercise is on the hosting. But I think like you said it is a challenge, especially this, we've seen some bad examples of not having proper offsite backups etc. And so I think from the University of Oslo said what we're trying to do is to sort of support in the planning and capacity building around the hosting to make sure countries have a plan that is sort of secure and includes offsite backups. So I think we'll talk a bit about tomorrow, but in terms of actually like providing, providing any backup service. That's nothing, not something we have plans to do or are allowed to do from the sort of Norwegian legal perspective even. Thanks a lot. Okay, so yeah, we'll continue with the exercise if there are any questions just so we'll be walking around. I have another question before. Yeah, please go ahead, Joe Paul. Yes, let me ask a question on behalf of my friend. So we were just discussing but he wants to hear from you, what kind of media device for those who are hosting more than one program the same infrastructure in the same server. We can just share my experience. When you are is we have seen when you're hosting more than one program on the same server, you need also to think about what we will be correcting for each and every program so that you can try to anticipate the amount of I mean the specification of the server you need, because if we can have an example, one of the country have been hosting like five programs on the same server. And they were TV, immunization. And then when we started, when each and every program started growing in terms of number of data being corrected, the infrastructure was compromised. So it started the freezing. So, maybe Nick with advice but I think hosting many programs on same server. It depends to how amount of man are going to correct and how wrong, so I think it needs a good pruning. Thank you. Okay, so maybe we can just hold off on further discussions on the hosting for now. I think it'll be a little bit more clear after all of goes through and presents we're presenting several options about how hosting could potentially work. I think we can leave the discussion for there that way, we can have some discussions around kind of specifics. And some of the options that are available etc right so just focus on the infrastructure for now hosting will come very shortly in about 10 minutes time we'll talk about that as well. Okay. Okay, thanks everyone. We will continue now with the second part of this session. So, I'll continue talking about server hosting, which is also a question I think there has been a topic that there's been quite a few questions about. So I'll be talking a bit about how the tries to can be hosted different ways of organizing the hosting the implications for the kind of people you need to support this. So general considerations when you're making a decision about what way you want to go. So what we're doing now is focusing in on this server part of the infrastructure picture. So what we call provisioning so where should the teacher server be located, how should it be managed. So I'll just go through some alternative ways of hosting the tries to. So I think starting with what we sometimes call hosting it in the basement. Essentially that you set up a server within the Ministry of Health, typically taking a room that is available and equipping it as a server room. And of course, that gives you very sort of direct control over the server it's sitting there in the office you can sort of more or less touch the data. The challenge with this is that it's actually very difficult to do it well. So you really need to have people who know what they're doing in terms of not just setting up like the network infrastructure, the power with redundancy. But even addressing things like cooling and avoiding making sure it's a room that there is no risk for water leaks are all this. complicated issues that you need to address if you're doing this locally. And it also costs, there's a sort of high one time cost because you actually need to buy all the equipment you need to buy the server. So it has a high startup cost and then of course you need to plan for the server to last for a few years and then you need a new one. And very often we we don't really recommend this in most cases of course there might be ministries who have really skills equipment infrastructure in place. But most often the Ministry of Health is not really. That's not what it's set up to do server hosting. So very often we, we advise against this. The only way of managing a physical sort of infrastructure using a physical server to host the tries to is when there is a like ministerial government data center. So this is I think becoming more and more common in lots of countries that the government builds a data center to host the various IT systems that the government runs I don't know from the countries here. I think Jordan has a national server center what other countries have a national Palestine as a national data center. So I think compared to hosting it within the Ministry of Health what we call in the basement. This typically means it's sort of according to the national policies because it's government setting this up. The Ministry of Health team managing the tries to is not responsible for making sure there is cooling in power and all of that is sort of part of the service provided by the data center typically. So what you really need then is just someone who can manage the server itself. Most of the things around it is taking care of in terms of cost this still means to you need still need to pay for this typically so the ministry needs to pay the government data center to host their data. Even if you're not required to actually buy the physical server. And this is price what we've seen at least from many countries is that it's more expensive to do this in a government data center than for example using Amazon or Microsoft cloud servers. You're sort of dependent on the national data center infrastructure team being good at their job to make sure network security and all those things are well configured. Another thing we see quite a lot is that there are often some bureaucratic sort of layer to this. Compared to a cloud service where you essentially you get access to the server you're paying for. And also with this government data center you might to open a port on the server you need to have the minister send the letter to the other minister to say that we need to open a port on the server so it can be more complicated from a sort of management perspective. Overall this is often a good approach, assuming you have the you have the technical skills and infrastructure in this data center is in place. Third way to do the hosting is of course through the in the cloud. And what we call infrastructure in the cloud. So basically renting a virtual server from one of these cloud companies whether it's Linode or Amazon or Microsoft Azure. So the ministry sets up an account and pace, and they have access to server infrastructure. This is usually the cheapest. These are big companies that knows how to do this so the performance and reliability security is generally good. And the skills needed from the DJI side is just maintaining that the server itself and not all the networking and infrastructure around it. One challenge there in some places is that not all ministries are sort of set up to have this use this sort of need to register and use a credit card to sign up. That's not always easy in all, all ministries. One of the ways that we worked with for a long time we have sort of contact persons within the company that will help do like enable you to send the invoices instead of using credit card for example just to make the practical issues easier. And, and of course with this if you don't pay they just turn it off. So you really need to then make sure you have budgeting for the monthly cost. As I mentioned here but is of course another challenge is that depending on the legislation you're not might not be allowed to actually host your health data outside of national boundaries. The last option is again in the cloud, but using what we call a software as a service. So basically paying a company to do all the server management of the choice to. So they will you will write them an email and they will say okay we'll upgrade the choice to will take a backup will share a copy with you. So then you really don't need a lot of system administrator skills within the D tries to team. Then they take on the sort of responsibility for security performance, assuming you pay. And you typically then have an agreement that actually specifies this many hours a month downtown is a downtime is allowed etc this kind of service level agreements. Because you're having someone manage the server for you this is more expensive. It has some of the same challenges with the payments as the other cloud options. And the same challenges with budgeting if you don't pay it and you lose your server basically. The last thing to point out here is that even though you do not then you don't need the team to actually do the management but you still need someone who has skills about server hosting to be able to sort of make the right decisions about how big server do you need what is a reasonable price sort of do the negotiations with these service providers. So this is just for you for those of you are looking at the slides or want to look at them later summarizing the pros and cons of the different options. I won't go through this in detail. Okay, so coming back to this capacity building that we keep talking about very often. I want to sort of guide your decisions around the server hosting is the the skills in server administration that you have available in the DHS to team. So if you don't have anyone with server administration skills, then it's a good idea to outsource as much as you can. The skills available to manage the system is one of the most important factors when you're actually deciding what type of provisioning you want. So this is a bit of a repeat of what it was talking about one of the roles in the core team is the system administrator or server administrator. Unless you're outsourcing everything to a cloud provider. You need to have a system administrator who knows, typically Linux open source technology, Java, Postgres, the kind of technology that the tries to use based on. Sometimes that's a challenge because you might have a very good team of server administrators, but they might not have that much experience with open source tools they might be very good in more commercial tools but not necessarily in Linux and Java and Postgres. It's also important that this is more than one person, otherwise you're very vulnerable if someone leaves for some reason. Sometimes this is one of the things that is often at least in the sort of an initial phase, more or less outsourced to one of the his groups who provide much of the technical support in this area, since it takes time to actually develop the skills for server administration if you're starting from scratch. Okay, then two sort of more specific things if you're actually hosting it locally so you're responsible for buying the server and setting everything up then you also need someone who knows network engineering so someone who can manage the old network infrastructure. And this kind of infrastructure engineer who can sort of take care of the physical physical equipment and not just the software platform running on it. Okay, so there's been a few questions now what is what actually makes sense in terms of the actual hosting of the tries to when should I make a new server use an old server new instance should I add more to my one. Should I add all the programs to one or should I have multiple separate the tries to systems. So first of all, if you think of the tries to as one system you want to use for your HMS for your routine data. You would typically already here have actually many databases many instances as we call them. So when we talk about the instance it's sort of a separate separate database separate version of the tries to running. So if you add the data to one of this is not linked to the others even though they could be sort of copies of each other. So you would very often you would set up. Of course this is the main instance that the end users are actually reporting into. But then if you're doing training you don't want people to enter his data training data into your actual production database. So you would need a separate system for training. And then of course, when you're working on new things you're working on a new data set a new program you don't want to do that. So you need a separate system in case you're making a mistake you're breaking something that breaks the time tree for example. So you need a separate instance for working on your changes. And then you would ideally have. What is typically called a staging instance, where you take the changes you made here. You put them together and you make sure that you everything works. And your changes is not breaking any of the production functionality. So that's fine maybe you have four versions of your HMS. But then you want to start doing some case based reporting as well. So maybe it's easy then to set up a new new version of the tries to. So you set up maybe you have your aggregate monthly reports here you're starting with immunization registry. You do that in a separate details to also needs a training database staging database development database. And then the surveillance program was usually tries to so they set up a new details to instance for surveillance. Also with the training staging production development instance. And then TV they do the same. And then that's dedicated instance for the aggregate API. And then maybe you want to have an instance for finance data. And then suddenly you have. I don't know 1215 20 instances of the tries to running. And having separate data separate user accounts. And this is sort of a very easy thing you can easily happen we see it happen quite frequently that it's very easy to set up. New version and work on that you don't need to think about anything that exists. But it's not really a very good approach in the long term. So just in general, what you've been doing now with the drawings and thinking around the architecture of course that influences how you do the hosting. How many servers do you need how many instances do you need. Which ones are belongs together thinking of the server and the instance. It can be if you're sort of new to these concepts. It can be a bit confusing but like I said the instance is a one copy of the tries to running with its own database. And on one physical server or virtual server, you could have 10 instances of the tries to running next to each other. But if you have a very large scale system with thousands of users, millions of data values coming in every week. You might also have the opposite that you need multiple physical servers, just to run one version of one instance of the tries to. So some common things that people are often sort of considering wondering about is, should I have separate the tries to for my case based data and my aggregate data or not. And should I have separate instances for each vertical program or should I have one where I just add everything. And I think there are a few things that help can help you sort of think through these things. Coming back again to this ownership issue. If these 2d tries to instances are managed by completely different departments, different teams, it might be difficult to put everything together, even though it might be ideal from sort of a data integration perspective. It might be performance considerations like shampoo mentioned. Maybe there is some concern about adding too much. Too many big systems into the same server and they eventually you might have performance issues. So that's something to consider. I would also say then maybe it's also about the planning to say okay before I add more to this server I will need to increase the resources. Another reason that we sometimes see for setting up a separate instance of the tries to for a new health program is if there is a new version of the tries to. There is a new functionality that you need, but you're not ready to upgrade the whole system yet all the other programs. So then sometimes you will need to set up a separate instance to use the new functionality for one particular use case. And then hopefully later you'll be able to merge them and all the tries to instances are upgraded. I think might be easy to forget when you're sitting at the central level. I'm working on this might be easy for you to set up a new instance and do work there. But for the end users, it's not necessarily so convenient for them to have four different usernames for different URLs for different systems that they need to log on to. So I'm reporting immunization data I need to log in here, I'm reporting maternal health data I need to log in here. So that's a third fourth aspect to keep in mind. So I think the only sort of general recommendation we have is that we think it's a good idea to keep your case based data and your aggregate data into separate instances. Part of that is sort of it adds another layer of security, because then your personal data is not accessible necessarily for users who should just have access to your aggregate dashboards. So even though there is functionality in details to for managing access control. There can be of course someone does a mistake when they're setting up the user account suddenly they have access to all the case based data. If you have separate instances for your aggregates, typically analytics, and your case based data that's another level makes it harder to make mistakes that gives people access to the wrong data. But then I think beyond having separate aggregate and tracker I think you would need to have a good reason not to use the same instance you already have. So if you have an individual level system with where you collect maternal health data. If you're working now you want to add immunization program. I think what the starting point should be what what are the reasons for not using the same. The default should be that we want to have an integrated system. And then if there's a good reason, typically one of these to make it separate, then you should consider making it separate, but unless there's a good reason to have it separate. So it's the default should be to add one the tries to instance, with the data integrated. Something we haven't really talked about here. We'll talk about it very briefly tomorrow morning is the type of access controls in the tries to. For those who are not familiar with that. Having adding multiple health programs to one instance of the tries to does not mean that all the users of that instance have access to all the different programs. So for each individual program for each individual or unit for each dashboard, you set up the access levels. So a user within the platform only has access to the things you've given access to through assigning the person to help facility or district. By giving authorities to do certain functions or access certain apps. And through this. Metadata sharing giving you access to specific programs or data elements or indicators. So using one instance does not mean giving all the users access to everything in that instance. Common question we get is how big server do I need. And that's not really possible to answer. So how many gigabytes of RAM how many CPUs. It all depends. So the best we can do is typically look at what you're planning to do. How many users do you expect. How many data values to expect. And then we have an idea what is being done in other countries okay they that's sort of the same size as what they're doing here and then we know this they are managing with the server. And then that's, they can be a starting point. When you're planning. What you need to do this is just making sure you're monitoring your resources so that you see before it's too late that you need to increase the resources or maybe you've. Maybe you don't need all the resources you plan for so then you can reduce, but I think our best advice is to look at what has been done in similar situations, monitoring and adjusting. So of course, in the example from sample has starting with one program and then adding more and more programs. Then of course, in those cases you need to also adjust your resources. Because then you know that you will. It will be more demanding on the infrastructure. In terms of the costs. I already talked a bit about this. Just renting infrastructure, renting a virtual server from one of the cloud providers usually the cheapest option. Renting the whole details to as a service is usually the easiest, although more costly. And hosting in national data centers is a bit more expensive than the commercial centers and to be very honest often not as professional so you might, you might be told that you're being given a server with 64 CPUs, but then there are also two other departments that have been told they've been given the same server and you're actually sharing just 120 CPUs so no one is actually getting what they're paid for that's one example of what we've seen with this data centers. Of course, anything that involves physical buying a physical server. As a big upfront cost. And it means you really need to have a plan for how you're going to maintain what you do if something breaks budgeting for buying a new server after three years or five years etc. So buying a physical server also of course makes it more difficult to increase and decrease your resources, just some final points. Of course, you need to, if you're starting with the tries to you need to make a decision, what you want to do. Whether you want to host it in the cloud, whether you have a server, whether you have a government data center. So change over time. So, one option and something we see quite a lot is that there are a lot of these government data centers being built, it will be ready in one year there will be ready in two years. So then there's nothing wrong in saying okay we'll use a commercial cloud for one year, as long as there are no legal issues. So when the data center is ready we can shift our hosting there. Another option we've seen is that there might be legal limitations or where you can host your case based data, but not your aggregate data. So some countries have said okay the cheapest option is for us to go to Amazon or Microsoft rent a server for our aggregate data. So we'll do that for our individual level data so we'll do that in with a physical server for example. So with that, I didn't have the exercise here but I'm done talking about this topic. If there are any questions. We can take a few of those and then I think we should. If there are any questions, if there are any now and then we have a second part of the exercise we started earlier in the session which is around the hosting so there was one tab in that Excel sheet around infrastructure. And then there's a second sheet on the hosting specifically. So the plan for the last 10 minutes is to let you have a look at that and try to think through. What hosting options. Make sense for you. Any questions. Yeah. In fact, it's not a question rather than a reflection. And thank you for mentioning both option the physical server on the cloud, because at the beginning maybe some countries are enforced. But sometimes it's easier for them to go for the cloud, just to make sure that they are able to deal with the system in the best configuration or ideal configuration and how to deal with the ecosystem. When they move to the physical server hosting, they can compare the performance and see what is the differences between them. In fact, we utilized both both modality in Palestine. The modality was utilizing bow. And based on that experience, we go to to buy the servers and infrastructure based on the testing period on bow. So I think it's a good advice for other countries, mainly for the Ministry of Health and IT departments. To start planning for the data center and to do the architecture of the data center and servers and the needed specs and specifications. It's great to have like a period of testing. At that time you can utilize and see the system performance in the ideal situation. And then based on that you can do the planning by considering definitely the data ownership and other perspective. So that's the reflection. And I think that's a very, very good comment. And I think of course the advantage of the clouds initially is that with a click of a button you can have a twice as big server so if you're seeing your, your estimates to begin with we're wrong, then you can easily fix that and then sort of upgrade. If you buy a server and you see okay we should have bought the bigger server then you need to buy one more. You're sort of stuck. Any other comments or questions. Otherwise, I think we should use the last five minutes to look at this exercise. I can open the. Yeah, so this not seeing the same screen. So earlier you were looking at this infrastructure. Now it's the server hosting tab. So just a few, few questions to trigger some reflections for the last five minutes.