 In this session, I will talk about infrastructure as part of a DCHIS to implementation. We will go through the different infrastructure components of a DCHIS to implementation, understand how the nature of a DCHIS to implementation shape the infrastructure needs, and understand long-term maintenance issues. I will start with the infrastructure components. In order for a DCHIS to implementation to be successful, physical infrastructure and support is needed. There are some key infrastructure categories that you need to consider when planning and maintaining a DCHIS to implementation. These are servers and hosting. There are various ways of solving that, which is covered in other sections in this course, devices, electricity slash power, connectivity, and support structure for end users. Support structure for end users is not infrastructure per se, but it is closely linked to making the rest of it work, so we have included it in this session. The one thing to remember is that it all depends on your implementation. It's difficult to come with clear advice to say that you need so-and-so number of devices or exactly these specifications because it depends a lot on how you choose to implement your DCHIS to a project. For example, data entered at national, district, or facility level can be done in different ways. Maybe you have aggregate at some levels, you have tracker or Android in other depending on readiness or maturity. Some sites require several devices, others require fewer number of devices. If you have large data loads, it might mean increased server capacity and also different projects might have different acceptance for downtime. This all impacts infrastructure needs. And if it's one thing you should remember after this session is that the existing infrastructure situation should shape your implementation strategy. So don't design a system that the infrastructure cannot support. So one example can be planning a very advanced tracker project where you want health workers to enter data at point of care every day when they're meeting patients, but half of the facilities in the country is lacking basic electricity or connectivity is a big problem or there is not enough devices. So do not design a system that the infrastructure cannot support. So devices and hosting are two important infrastructure components. Servers are covered more in the hosting session. So I will not go into detail about that here, but there are several types of specifications that needs to be addressed before choosing how to host your system. The system be hosted on site within the ministry or in the cloud and who will deal with server administration. Then you have the actual devices used to enter and analyze DHS2 data. So this can be laptops, desktop computers and tablets. Different number of laptops or tablets are needed per site. Again, it depends on the implementation strategy and how the programs are set up. And mobile devices is another category. This is covered more in detail in the going mobile session. There are various types of mobile devices. Sometimes you would have projects where people can bring their own personal devices or should only devices purchased for the project be used. Device management is also a key topic here. How do you keep track of all your devices? How do you update them in a coordinated fashion? How do you know which ones are working needs to be replaced, et cetera. Power and connectivity, you need to understand the electricity availability and the sources. For connectivity, is Wi-Fi available? How will you solve that? Data bundles for health workers or district statisticians, for example. How much data is needed? Can people also use this data for personal use? Or how do you plan to solve that? Sometimes D-CHI's too can enable you to work offline, which can be useful. We have also seen some interesting examples where there has been co-sharing of connectivity. For example, common Wi-Fi points across domains. For example, that's in a district that the health office and the education office, for example, can share a connectivity hotspot. And then the support structure for implementation. We also put that under infrastructure. So user IT support is required to assist users, and often real-time. And this is often an overlooked domain in planning and D-CHI's to implementations. You have to think about who will pick up the phone when the user has a problem. And of course, if you enter data once a month between 50 different users in a country, it's a very different IT support needs than if you have 2,000 health workers entering data every time they see a patient. So typically, you might need a structure to help users recover lost passwords or user names, support them if their device is broken or lost, if the program is not working properly, or if they just have general questions or are stuck. Next, I will talk a little bit about the difference between aggregate and tracker D-CHI's to programs and how that impacts infrastructure. So aggregate data entry and analysis happens at regular intervals, for example, monthly. So somebody will enter data monthly and a weekly or monthly in a clinic or a facility or in the district office. While if tracker is used, it's often used in the clinic, sometimes at point of care when they're seeing the patient, so at frequent intervals. This largely affects the number and type of devices that is used. So more devices are needed for tracker, potentially one per health worker. For aggregate, maybe one device per district can be enough for power and connectivity. Both tracker and aggregate, of course, requires connectivity, but with Android, you can work offline for periods of time. And tracker can also require more stable internet, especially if it's used in real time as part of a treatment process. You have less tolerance for downtime and the support structure, the more users, the more you need to plan and budget for a support team that can address small and large problems as they arise. So when tracker is used in real time, the IT support unit also needs to be available live during business hours. And for server and hosting, tracker systems frequently involve heavier server loads. There's more data entered at higher frequency. There are more users, and this will be presented more in the detail in the hosting session. And then for mobile data entry. So adding mobile data entry to a DHS to implementation that involves additional infrastructure considerations, which is addressed in more detail in going mobile. So typical, which mobile devices should be purchased? Again, can personal devices be used on the job or are there specifically purchased for the program? How would you keep track of all the devices and inventory of what you have, what needs to be replaced? And again, think through airtime and connectivity for each single device. Lastly, I will talk a bit about maintenance and replacement. So maintenance and replacement is often neglected, but it's a very crucial part of a sustainable DHS to implementation over time. Often we see that there are budgets available to purchase infrastructure at the start of the project, but as the project moves on over several years, these devices break, they might need repair, they become obsolete. Sometimes they disappear and it's very important that the country has a good plan on how to replace devices, how to repair devices and how to do it quickly. So having an inventory or mobile device management is a good way to do this. It will ensure an overview of all devices where they are, when they need to be replaced and also tools for mobile device management and support upgrades and management of devices remotely. So you could install new things, for example, or upgrade to newer versions without having people physically bring their device to a central location. Spare parts and extra devices are important to have handy. They should be available close to the users to quickly replace a broken device. And it's especially important for tracker projects, especially if there are points of care implementations. A nurse cannot wait for two months for somebody to order a new device if it's something that she uses in her day to day work, seeing patients. So how does this impact a project budget? So ensuring adequate devices for DHS2, meaning adding budget lines for yes devices and server costs, hosting costs. Some costs will be recurring and they need to be planned for. So connectivity, for example, this is a monthly cost that comes every it comes every month, it's per device or per user. Replacement and repair of devices needs budget before and to have an ongoing support team that's knowledgeable about the topic they are going to support on and they need to be available as long as it's being in use. So in summary, key infrastructure categories are devices, laptops, phones, tablets, stationary computers, its power or electricity, connectivity of various kinds, servers, hosting and the support structure for end users. And again, to stress that the nature of the implementation impacts your infrastructure needs, but also the other way around. So your existing infrastructure needs should really shape the implementation strategy. Implementing tracker and Android system has infrastructure implications. And there is a difference between implementing tracker versus act. Existing infrastructure situation should shape the implementation strategy, as I said, and including potentially varied approaches at subnational level. So depending on the infrastructure situation, maybe you would have some health facilities entering data directly on a device at the facility, while if other devices have more challenging infrastructure situations, such as lacking power or lacking connectivity, maybe they will fill out on paper and send that to a district office where they do have connectivity and power and the data will be digitalised there.