 The session will cover three main objectives. The first one is identifying the main implications of using mobile devices in aspects such as configuration, security, planning, infrastructure, and management, followed by the mobile impact analysis in project management, budgeting, and planning. And finally, understanding the alternatives of application distribution and management of devices. Let's start with the implications of going mobile in terms of server configuration and security. The main advantage of using a mobile device in an implementation is the capability of capturing data offline. Internet connection is only needed for an initial data and metadata download and also to send the collected data to the server. It is important to balance the metadata access and data download to guarantee the usage and practicality of the programs. Keep in mind that heavy things can overload the servers and devices. Therefore, it is necessary to configure and manage both thing time to streamline the metadata configuration, consider three main elements. The first one is a capture and the search organization units. The capture ones will narrow the amount of places to pull data from in the same process, and the search ones will be used to search when there is internet connection. Limit the access to programs and data sets using the sharing settings. In the sync process, the device will download only the ones with view and view and edit data access. In programs using auto-generated IDs, each device will reserve a specific amount of IDs to be used while working offline. It is strongly recommended to evaluate the adequate pattern and the amount of digits to use according to the capture scope. As a wrong defined pattern, could limit the offline capabilities of the app. Your data sync process can be configured using the Android settings of app. It is possible to define the numbers of TIs, events, dataset periods and auto-generated IDs to download. This will ensure having enough data to work with. It is also recommended to configure an automatic period for the metadata and data sync process. By default, the app will program it every 24 hours and in case the user doesn't have internet connection by the time, the app will trigger the sync the moment the device gets connectivity. Using mobile devices implies that the data is no longer only in one place. Compared to the web where everything remains on the same server, mobile implementations allow the user to have the data in multiple devices. Data protection must be a priority not only because you care, but because you are most probably obliged by the laws of your country. The information in the devices needs to be accessible, authentic and present when it is required by those who are designated to use it. The app implements risk mitigation measures following mobile development security standards such as screenshots, which are only allowed if the admin enable it using the Android settings of app, security network connectivity, database encryption, and finally, if your device is rooted, the production app won't work and you'll need to use the training version. There are some actions you are able to do in your implementation to ensure the information is secured. On the server, you can control the amount of access to programs and data by the user's capture organization unit or the sharing settings. On the devices, set a pin code to block the device, but also set a pin code to block the app. As mentioned before, encrypted database is also a possible way to secure your data. On your implementation, use tools such as MDMs to control the use of the devices, train your users on security awareness, and implement good security practices. Now, let's focus on the project management, budget, and planning implications. All projects are different in terms of amount of resources, budget, size, settings, among others, but it's important to follow a guide to reduce risk and future problems. Begin by planning the testing. We divide this process in four steps, server configuration, internal testing, user acceptance tests, and field testing. All of these must be planned from the beginning in terms of work plan, human resources, and logistics. In the server configuration step, take into consideration that it can be difficult to update the metadata once the users are starting to collect data, and if there is a lack of tools, travel shooting can be challenging. It is important to refine your configuration as much as possible before deploying it. The internal user acceptance and field testing are the main focus before scaling up. These phases modify your configuration. Therefore, your configuration should be flexible at the beginning and stabilize it until the testing phase has finished. The duration of the testing cycles will depend on the nature of each one of the phases. Going mobile on the HIS2 will also have budget implication, and it's important to refine them at the beginning of the project to avoid problems. From the human resources, it should include additional costs related to travel shooting, configuration, and testing. As explained later, server specifications might need to be increased due to load peaks while having a big number of devices. In general terms, mobile devices are likely cheaper than desktop or workstations, but probably the number will increase. Also, they might need to be purchased with accessories to increase their usage. Despite the out being designed to work offline, initial and periodic connectivity is required. There are many ways to handle this, like via trips to places with connectivity, remote portable hotspots, data bundles, etc. A general management tool, mobile device management, can hugely increase the costs but add many benefits. This is covered in the following section. Apart from the costs mentioned above, there are some recurring costs that also need to be considered. As mobile devices are more exposed to risk, they are more likely to fail, break, or get lost. Including specific budget lines for spare parts, new devices, accessories, etc. should be considered. In implementations with no Wi-Fi internet connectivity and therefore using data connectivity, additional costs might come from data bundles, its management, and its distribution. NDMs usually are sold under monthly or yearly subscriptions. Server hosting and maintenance is also a recurring cost that should not be neglected. On top of this, in projects likely to increase within time, the server specifications might need to be upgraded accordingly. So as mentioned in the previous slides, its DHH2 implementation is different and its budget and resources will depend completely on the specifics of the use game. Target, configuration, scope, size, among others. Two scenarios are provided in this course to help you understand the best strategy to follow. In this first scenario, for example, we have a new hospital which is added to an existing DHH2 implementation for tracking patients. This hospital is managed by six doctors working in two shifts, three per shift, using Android tablets over a Wi-Fi connection. And country monitors are also needed to evaluate other facilities using mobile data. For the budget of this implementation, it is necessary to consider training, use of the devices and the application, devices because tablets and mobile phones need to be added, and mobile subscriptions for those users that are not using Wi-Fi. Since the amount of devices in the mall and also the data to collect, there is no need to upgrade the server nor use an MDM. In this second scenario, a thousand workers are collecting data in a remote area with difficulties to have an internet connection, which means mobile data is a must to be able to synchronize information. In this scenario, the budget increases due to training, with such a big number of users working on guidelines or training of trainers will be needed. Amount of devices, because at least 1010 devices, power banks and other accessories for rough environments like screen protector cases, etc. will be added. Mobile subscriptions, so the users in the field can synchronize. An MDM, due to the large amount of devices to have a better control of upgrades, correct use of the device and the app itself, separate upgrade to support the amount of data to collect, and also personal for testing, user support, etc. In terms of device acquisition, the general recommendation is to proceed in phases as advised in the official guidelines. Following the same scenarios as before, the purchase strategy could be as follows. In this first scenario, we need to acquire 15 devices, so the strategy could be the following. Acquiring two different devices of each kind, phone and tablet to conduct a test and choose the best option during the design and configuration phase. Acquiring two devices, one tablet and one phone, based on the pilot plans. And acquiring the rest of the devices, two phone and nine tablets needed for the project as a single batch as there are not too many. And then proceed with the replacement or upgrade when needed during the project life. In this second scenario, many more devices are needed, and therefore an example strategy could be the following. Acquiring three or four devices for the design and configuration phase, ideally with different specifications and within a given price range in order to choose the best option. Acquiring the 10 or 20 devices needed based on the pilot plan. Then mass acquiring devices for the rollout of the project, around 500 devices. As a big number is needed, probably good deals or promotions are possible. And then acquiring the rest of the devices, the remaining 500. And last proceed with the replacement of upgrades when needed during the project life. Please note that these are general guidelines and much more information is provided in the official documentation as provided in the link below. In this last part, we talk about the infrastructure related decisions. Specifications for mobile devices to use on a DHS2 Android application deployment are included in the table displayed. Note that these recommendations can be very generic as the performance of the device will be highly impacted by the configuration and other factors mentioned before. It is recommended to use a well-known brand in terms of updates and support in case of any device failures. Also use different devices to test the configuration and make sure to keep the ones that better suits your case in terms of performance and user experience. For example, in some scenarios, a small phone could do the job while in others, you might need an Android laptop with a keyboard. Make sure to keep you updated with the newest information by clicking on the DHS2 Android documentation link highlighted in green. Although using a mobile device management, MDM as from now, it is not compulsory for an implementation using Android devices. It can really improve the support and overall control and experience. And MDM allows managing devices from a central console which translates in ensuring your devices run the specific version of the app and can ensure other security policies are being run. It is especially recommended in dimension but not only scenarios because when you deploy many devices, it simplifies the process of installation and update of the app, but also to deploy other applications or security policies centrally. If devices are difficult to reach, the central management allows not having to retrieve the devices to set a specific configuration. Policies can be defined centrally and spread to all the devices. This can improve a lot the security in implementations with personal and professional devices are being used. In the following slide, we cover specific examples of how an MDM can be used. Some of the features of MDMs that can improve the experience, success, and security of your implementations are. Enforce a screen lock password to some or all the devices used. This improves the security and privacy context. Allowing deleting the information of the phone remotely or tracking the phone location. This improves the security by preventing unauthorized access to information in case of device theft or loss. Please note that in order to perform this operation, the device needs to have internet or in some cases SMS connectivity. Restricting the functionalities of the phone, like limiting the internet usage or applications, can reduce costs or prevent users misusing professional devices. Controlling the version of the operative system and pushing updates ensure devices run secure versions. Distributing the app via a personalized market ensures that implementations are running the specific version of the app with full control of the updates out of the VHS2 current release channel. A guide available in the VHS2 official documentation collects these and many other points to look at while considering an MDM. This table contains some of the recommended MDMs for VHS2 mobile implementations. Using one can imply taking into consideration some other costs such as hosting or unlimited use of devices. This is the main reason to evaluate the needs and include its costs as early as possible in the definition of the project and budget. It is important to evaluate different alternatives to find the most adequate to your project. In some cases where you have a strong infrastructure team, you might choose to host a solution on your premises, while in others you might delegate this task to an external company. Make sure to keep you updated with the newest information by clicking on the Android official documentation link highlighted in green. There are several options to make the app available on your devices. The first and most common one is to download the application from the Google Play Store. This has the benefits of being a common operation that most users will know how to perform and can achieve the task with very basic guidance. However, this might not be available in countries where Google might be blocked or devices without a Google account setup. It is important to note as well that if users download the app, they are recommended to disable the automatic updates for it, so whenever a new version of the app is released, the implementers can test it before it makes it out of the field. Another option to deploy the app is via other markets like downloading the app directly from GitHub, which will require specific instructions to the users, or via an alternative market where you fully control the release period. Both will likely have an impact on the training of your users and infrastructure and management costs, but will give you a full control on the versions that you want to deploy out of the DHS2 channels. The app was originally designed with the offline capabilities in mind, and this means performing operations like record updates, etc., locally and then synchronizing to the server as a bulk whenever the internet connection is available and following the synchronization times defined. In an implementation with a lot of devices, this will transfer my mean asking the server to perform many operations at once and this can overload the server. It is important to define a synchronization strategy and ensure the server hardware and bandwidth specifications can handle these peaks. We could summarize this session with the following remarks. Including the DHS2 mobile app in an implementation brings a lot of benefits and enables features that are available otherwise. However, it comes with some implications that need to be taken into account. These involve considering several actions from the project management perspective like budget, training, testing, support, etc. Tweaking the server configuration and adjusting the hardware specifications, analyzing and implementing security practices, and using additional tools like MDMs.