 Okay. Hello, everyone. Welcome to a new session, one of the last sessions of the Android academy and the implementation academy. In this session, we are going to talk about in continuation to high mass session. He was talking about going mobile security implications and configuration implications. Here we are going to see the implications in your implementation plan. I'm going to start sharing my screen. Let me do this. Yes. And then by the end of this session, what we would like to share with you is information on best practices, on configuring and testing the HIS tool to know what to look into where you are acquiring devices, the different alternatives that you have for installing the application, to know what is a mobile device management software, and then also to understand the implications on your server infrastructure. And then we will have a small online quiz that we always like to have. So I will be covering actually only the first part and maybe second and how may it's going to cover the second half or two-thirds of the rest of the session. So what we are going to share here is not rocket science and it's probably things that you already do because most of you here are experienced implementers. So we are just repeating and repeating things that you might know because when you implement and when you have mobile devices in an implementation, let's say in simple that everything complicates a bit more because before you have one server and you keep control of your server, but now you have a replica of your server in many little devices all over your country or region and that makes things a bit more complicated. So I'm going to focus first in the phases of configuration and testing that you do before scale up. So these phases, what is important to remember and the main message we want to send is that they are iterative. They go in cycles and all the phases, internal testing, user acceptance, field testing will keep on informing and fine-tuning your configuration. You are going to keep on making changes all across this in principle phases before scaling up so that when you scale up, you finally have a robust and reliable implementation. This is very important because, for example, this academy is a very good example. We have been having problems with the metadata, you could not sync, you cannot see what you are expecting to see, then we go, we change the server, but I think most of you have experienced how complicated is to troubleshoot and to support you when what is happening is in your device and we don't really have access to it and we depend on you to tell us what the problem is. And we are all more or less sitting comfortable at our desk, our offices or homes and we do have a relatively good connection. So imagine what we have had in this academy with the devices in the field used by an end user with bad connection, probably working in a rural remote area. Everything complicates very much. So these phases are very important. You have to be very rigorous and strict in following this process for a successful implementation. So let's go one by one. Internal testing. What do we call internal testing? You might call it differently. It's the first phases of your configuration. It's done by a very small team, probably your experts, saying what they want, the subject matter experts, and then your technicians configuring. Because what you are testing here is the configuration and the Android app. What can the Android app do or not? What is it back? What is supported? How is my configuration behaving? And you are looking for your program rules if they behave properly, if the forms look as you expect and the time to flow, the visual configurations that we have learned, if the indicators work as expected too. Of course, you will also find, well, hopefully not, but you could also find bugs. You could think of improvements. You could think of new requirements. So how to do this? The methods and timings for this vary from group to group. But the common thing is that it has to be iterative. This one is very quick, fast cycles. It goes in very fast cycles. And it has to be done at the very, very beginning. Documentation is your best friend for this phase. And this slide that we are going to keep is, these are links. You can explore all of them. Because what is supported, what is not, how to configure everything that we have said in this academy is in these documents. These are links to one same document. So everything is together. Besides this one, this is different. This is for deployment. And from here down, it's for the app. So make sure to go back and to use the documentation. And now, once you are happy with your configuration, you move to the user acceptance test. Now you are still testing your configuration. Yes, you are still testing your visuals and icons. You want to see how the users behave to that. If it's usable, if it comes out as you expected, and if they can do the tasks that they are expected to do in their work practices. And again, you keep learning and adjusting your configuration. You are looking for adjustments again all the time. And you can start identifying champions on your users. Like who is going to be your, are going to be your key person for your deployment. The key thing here is that it's done in a controlled environment. It's a short exposure. We are not deploying the solution. We are just telling them to please stop work and test this and tell us what they think is not necessarily integrated in work practices at this moment or left for a long time. After the user acceptance test and after the changes that you might do after that, you might go to the field testing or pilot or however you call it. Now you are testing in the real scenario and you're testing your protocols. You are testing the workflows, the infrastructure and architecture. You are also testing your training procedures and materials that you have prepared in the previous phases. And you are looking for again adjustments that you are also evaluating your solution in a real scenario competing with the real day to day tensions. And you keep identifying champions for your, for your deployment. There is no golden rule for this, but 20, 30 users and about two months of exposing the software could give you information. It's, it's very important that the location, the setting where you do your pilot because you should not go to the easiest location you have, but neither to the most complex. You need to challenge your, your tool, but you also need to be able to perform the pilot and learn. So maybe something in the middle. And then you need before doing this, you need to have defined how are you going to evaluate your solution? What are you going to be looking at to decide if you go on rollout or if you need more basis? At this point, you also define your strategy on how you will replace. And once you have finished all this, then you will move to the scale up, which comes with acquisition of devices. Jaime will tell us more later, but you need to decide if you are going to work with phones, with tablets, with Chromebooks. You need to configure if not done before your user roles and locations. And our recommendation is that you don't acquire all the devices you need at the very beginning. Most likely your deployment is going to be on cascade mode and phases. So you can acquire devices slowly so that you learn and test your, your, the devices you can, you can change it if required. And also implementations can, can be delayed in time for reasons that we don't control. And then we can have a lot of devices becoming obsolete. So this is just an example of planning. You can keep it for reference of how would you acquire your devices to, to scale from 100 to 1000 based on your implementation plan. The training you need to define as well, if you will do training of trainers or, or if you will do on the job training or class-based training. All this will depend really on your project. We are just telling you here things that you should consider and decide. And, and of course we have this developed in more detail in the, in the guideline that I will refer to you later. More considerations you need to decide if your systems are going to work in parallel or if you are going to replace one system by the other. If paper is there, if you are going to eliminate, if you are going to replicate, and if there are any approval workflows. If you keep all these considerations in mind when planning your project and you do your proper phases, we believe you can have a very successful implementation and you probably know all of this. And this is just a reference to our mobile implementation guidelines. So we have a structure that document which is in the documentation of the HIS2 in the docs page website. We have blocked it in, we have grouped them in depending on the phase where you are. So if you are considering to use the Android app, this is your chapter. If you are already setting up your server, you have recommendations here. If you are testing, you have recommendations here. If you are rolling out, you have recommendations here. And what I have just said in this session is a very, very quick summary of all these documents. So we really invite you to go and check it out there. I'm going to leave it here. I know I went very fast, but I hope the basic concepts were transmitted and over to you Jaime. I'm a bit over time. Yes. Do you mind changing your slides so we don't swap on it quicker? Sure. Okay. So let me put my camera. So see my entire face after this week. So yeah, let's go with the last part of this session before we go to a quick quiz to make you chill a bit before the exam. So in terms of devices, now Marta has been explaining how to acquire device with the example. I'm going to quickly talk about a bit more technical things that you should be looking at when acquiring the devices. And this is, yeah, perfect. Actually, maybe I can request control. So this is something that we have extracted from the official guide that you have down there. I'm not going to cover it here. Yes, important to note that depending on your acquisition, in terms you're looking for devices that need to have a keyboard, for example, you will be looking at Chromebooks. We are giving you here the minimum requirements or specifications. Have a look. This again is the minimum, but because we say it here, please don't take it like written stone. You have to test before because maybe we're saying you here with, you need at least four geeks of memory for your Chromebook, and then maybe we'll work with less. Maybe you will not have a very good performance, or maybe we tell you between four and eight, and you get a device with four, and then you see it goes very slow because you have set up a program with hundreds of Chromebooks. So ideally, I will see in the next slide, we can see that when you acquire devices, there are things you have to do. And first of all, is that they match the specifications we told you, but then you don't take them like that. It's suddenly, and you say, okay, I'm going to get a little amount of devices. I test them very well with my program already set up. I see how it works, and then I decide to buy more. So I think that's the sentence Mark also said. For me, what I always say is like, few, test, test, and then the rest. Okay. And another thing that we had to add recently, because in the past, pretty much every Android device that was being shipped out of factory contain the Google services embedded because Android and Google, et cetera, et cetera, we're not going to this technical discussion. But because now there was a ban two years ago with Huawei, important to know that some devices, if they don't contain the Google services, will not work with the application. So you will get this awful message saying DHS2 training doesn't work because you need Google Play services. By default, it's not going to impact you. But in case you are thinking to acquire, I think, at least so far Huawei devices, you can find a way to work around for this. But this can happen. So test, get a little amount of devices, test, and don't find yourself afterwards with a thousand devices that do not work. Yeah. This we saw on the first session. Well, on the first day, third session, I think we discussed the different options. I'm not going to cover them here again. But for you to know that there are several ways to download it, most of you went to GitHub to download the training one. We already covered what they were on the first day, and I told you I would be talking a bit more. Just wanted to mention that in the next slide, Marta, please, we have this. When you decide to install the application from the Google Play, like some of you did, and then you found out that you wanted the training, so you had to go to GitHub to get the training. The important thing to remember is that when you go to the Google Play Store, you cannot control when a new and a refresh. We also control the Google Play Store. So when we push a new release, we put it in the Google Play so people can download it. Unfortunately, it might be the case that you have a project and you have been explaining people how to use the version 2.5, the one we have now. And then in six months, we released a new version. You are not ready because you didn't test it properly or you didn't give the training because the application has changed a bit and the users will find a different welcome screen, etc. When you use Google Play Store, it's very easy to manage because you don't have to do anything. Most of your devices will probably auto update, even though you can disable this and we have guidelines where this is explained. But by default, your users will have always the latest version, and we control it for most of them. However, if you use other channels like GitHub or your own market, you control it so you decide, okay, also people work very hard. They managed to push the 2.6 or the 3.0 version, but I'm not ready. I take my time. I will do it in the future. So when you control your distribution channel, you can act upon this. So it's more difficult to manage, but you have more control. So is there the balance you need to evaluate and decide if you want to go for the easy, but you lose the control a bit or hard, but you have absolute control? Yes, yes, yes. So we have also, I think in the next slide we will have the documentation. So sometimes you will be hearing us talking about MDMs or EMM or UMM. They all refer kind of to the same thing, which is a security software that you can use to administer your mobile devices. If you're in implementation where you have many devices, it might be very difficult to administer those because in terms of security or because at one point you want to push the application that you have built in your channel or you have decided to build the application to change the specific thing, et cetera. Doing this without an MDM might be complicated because you need to go to each device or you have to call every user. A, please pass by the office. We need to update the software. We need to change the application. We need to do this and this. We need to put up in code, et cetera. An MDM, basically, what it does is you install a piece of software the same way you install the HHS21 server. So you install another thing and you tell all your devices to talk to the server to get, I'm sorry, I don't mind. It's just that I thought you were main. So you have your devices down here reading from the server and reading the policy about it saying, okay, I need to have a pink code in my phone. I need to install the new version, et cetera. Just a quick concept of this. In the next slide, Marta, if you can show it, please, you will have a reference there that I invite you to reach and basically if at one point you decide to look at the MDM because you already have an implementation in your country with 1,000 devices, 2,000 devices and you think this might be interesting and give you some key points here that you might look into. We think that it's important for these projects. For example, you want to be able to put a screen log password. So in the previous session I talked to you, I explained you how to put a pink code. There's something you need to go to each device to do it. If you could have an MDM, this can be done manually, centrally, and then push trigger to all the devices. I'm leaving it here for you to go through it afterwards. The last thing is to know that when you, we have convinced you, after this week of Android Academy, you say, wow, this is very nice and I want to implement, I want to use this with Android. So I'm going to push to my manager and we have to start using Android. Apart from the implications I was talking about before security, et cetera, et cetera, they saw something you need to consider and it's from the server side. And I'm saying here the server side because some people believe that it's as simple as buying 100 devices and then started using Android and nothing's going to change. That's not right. And it is because when you are working with the web version, you will have someone connected in front of his or her computer putting patient data and at this moment the information goes to the server. If your server was working properly because you had 10 users for example, you would expect the same with Android. The thing is Android, we have been seeing this week that every time you make changes, the changes remain on the phone and it's only when you sync when this data is sent to the server. So because of the offline capabilities I explained in the previous session, we might find ourselves at one point sending a lot of information at the same time to the server. I'm putting here a email, imagine you have 10 users and they send one letter per day and 10 users at the end of the month will have 10 users bringing 30 letters. So I don't know if it's very clear or whatever. This is going every day to the post office but with Android would be for example taking all these letters at the very last moment because our device is synchronized at the same time. So what was being spread among time in terms of information reaching the server with Android might happen that this information, the same information that was like this, instead of being spread on the time is now sent everything at the same time to the server. So just to remember that when you implement Android you also need to check your server and might be the case that you need to improve your server specifications on you need to tweak your system for Android devices to synchronize at different times or you could specify policies and say okay people from the region A will be syncing on Monday, people from the region B on Tuesday etc etc okay. Just quick concepts about this. The last slide that we have today is the last part of the day which is called offline because basically is one key concept we have been discussing today. So remember that you need to mark your attendance by putting words of the day. So this is the today's one.