 So the agenda today is planning for tracker data use, so we'll be reviewing how our analysis and information needs effect program design. As mentioned earlier, my name is Brian O'Donnell, I'm an implementation advisor for UIO, and I also advise the Norwegian Institute of Public Health on some of their tracker implementations in Palestine and Bangladesh. So the outline for today's session, tying in with our questions from earlier on the mentor that we just had, but we'll be talking a bit about how to build our tracker system so that they support better data use across the board. And often this means thinking quite early in the process of designing tracker about what the most important indicators are that we want as outputs from the tracker model, right? If the purpose of the tracker is to get more granular and routine data about the individual level conditions of certain patients or your healthcare system, then you want to make sure that you're gathering all of the data that you actually need for that purpose at the very start of your design process. Next we'll be thinking about the process for gathering your indicator requirements. So who to involve and what to review with that process. And then we have a few use cases before wrapping up that we'll explore as discussed earlier. Ghana will discuss their workshops for designing indicators across multiple programs of Ghana Health Services. Sri Lanka will talk a bit about COVID-19 analytics requirements and how they work those into the system design that we promote from his Sri Lanka. And then I'll wrap up with some research that was done with the MCH tracker in West Bank of Palestine, comparing aggregate and tracker data a couple of years ago and maybe discussing some of the reasons why that might be there. So yesterday and in the initial day we brought this concept of the tracker maturity model or the tracker house. And you can see here that there's a number of different things that you'll remember from Mike's presentation. There are a number of different topics that should be considered when you're designing a tracker. But the focus of today's sessions will really be about the linkage between the very peak of the pyramid or data use with the design and configuration process. We won't go into so much of the technical details about how to build a program indicator or how to build a dashboard, but really coming up with the requirements that you need to actually build dashboards or reports that suit your use case. So these are just a few of the key considerations not meant to be fully comprehensive. And the reason why we're mentioning this now is because often we see that there are upstream and downstream considerations for your tracker because you're intending to make this a sustained part of your health information systems in your country. So when you're first designing your tracker system, you may have requirements in mind that you won't have when you actually start consuming those data and using them to make decisions. So initially people are very eager to jump into the design process, start prototyping and then deploying it and scaling as rapidly as possible. But then when they come to the actual consumption of those data for their research analyses or their data use workshops or their monthly meetings for an integrated health system like their provincial integrated meetings, then they say, wait, why can't we make DHIs to indicators about something else? That's also very important. And there might be some certain design considerations with your tracker system that you need to have in mind at the very beginning of this process. That's why we are printing this workshop into the very beginning of this academy. So what makes tracker analytics different? I think this is a very important step that people might not consider when they're first designing a system because how tracker produces figures is very different from what you may be used to with traditional data sets and aggregate reporting. So first, when we talk about the patient's longitudinal record, this might be considered a new dimension for data analysis or there are many more variables that you could consider with your analysis when you have a tracker system. So the patient's longitudinal record consists of the track entity instance and enrollment and events. And each one of those different items has an event date associated with it, maybe also a due date. It has an org unit where it took place, and then it has a number of different data elements as well. And we can think about how we group those events and enrollments and track entity instances together and how it fits within this traditional model that we have of the organization unit, the period, and the data dimension. So there's a number of different options that we have, but it also means that you really need to think early about what your indicators actually mean in the tracker sense. Secondly, and I think this part is just as often overlooked, is that you have far more end users of a tracker system because you're entering individual level data. So you have many more people who are actually entering the data. This also means that you'll have more demands for data analysis. You'll have other end users who may want different types of data from tracker than you would be traditionally used to when you were doing an aggregate report from a facility. And so that also means that this is a golden opportunity to really reimagine data use across the program, right? Because you have more stakeholders that are involved in sort of crafting and designing this process. You also have more opportunities to really ask some very detailed questions that you might leave to a survey or some sort of ex post research analysis on a aggregate data set. And so it's really a good time when you're first designing a tracker system to step back and think about what each indicator that you're collecting means in clear terms, determine who is going to use it and when, and then what decisions would really be made based on that indicator. So you can actually take a sort of step back before you go diving into your tracker system. We won't go into this so much today. It's more of a configuration academy topic. But there are certainly design considerations that you could confer with experts in this academy or in the COP or your your own team about the feasibility of certain indicators within tracker design. We'll just briefly touch on those topics today. But the very last process of this is you'll have to have a list of all the different indicators that you want to collect is that you'll actually be prioritizing which indicators you want to see in your own implementation. And then this will in turn inform the design process and the scale and rollout of your tracker. So in the first day, Mike mentioned some of the key concepts for the tracker data model, which I touched on earlier. You have your tracked entity instances or your enrollments. You have events. And then each one of these discrete events has a date organization unit program stage and a TEI that are associated with it. If you group all of these together, then you have aggregate data, right? You have counts of the number of tracked entity instances. You have a count of the number of events, number of discrete org units that were involved. We might also consider relationships to be a part of those aggregates that you could include. And so there's a lot that you can really work with here. And the problem that a lot of people have is thinking, okay, how do I get from this tracker data model into some of the advanced analyses that I've seen other countries have and some use cases or some of these digital data packages that UI over leases, how do I actually transform this tracker data model into some actionable evidence from my program? And so this does require a lot of thinking through not just the technicalities of configuring these indicators, but also about how the data might be interpreted by the end user and how it would help them on their job. So we see here, you can make some pie charts about the types of vaccines that were taken last month about stock status. There's also some ways that you can do individual level indicators as well. So not aggregating up to the clinic or organization level, but just to an individual tracked entity instance. Can you show me the Z scores for weight versus height for this child over the last six months? And that's now something that's possible with tracker analytics that you couldn't do before. So really the first step in thinking about your requirements assessment for tracker indicators is thinking about who is requesting the tracker data and where is the demand, right? And then thinking about who is actually going to be using the system and their day-to-day work and what are their key incentives? So typically what we think of with tracker systems is it's a bit of a pyramid shape, no? So at the very top of the pyramid you'll have your IT staff who are actually or your Ministry of Health staff who are actually designing the system, coming up with program indicators, annual reports, people who are designing program rules, etc. And then maybe you would have health information officers at the district level in the middle, but especially with tracker, you're talking about thousands of end users potentially. And in some cases in Bangladesh and Nigeria we've had tens of thousands of people submitting event data, right? And so that means that you'll have a lot of people who are really invested in the system. The problem is that the people who are actually designing the system is very often the people who are working at the ministry level and are in charge of the purse strings to decide the direction of the project or they're people with the technical know-how to make certain assumptions about how the tracker should look. And sometimes this mismatch can cause problems because either the workflow doesn't match how the end users typically think the tracker should work or the data outputs are not actually matching what they need to make decisions at a local level. So here's one example of this. As a health system manager, I know that it's essential for my HMIS to know the number of hospital deliveries per month and by method of delivery. It would also be nice to know just for administrative and staffing purposes. Can you give me the number of hospital deliveries by time of day? So if I know if I should be staffing the hospital at late hours or if certain hospitals are seeing a greater influx of cases. So that might be nice to have for them, but at the data entry level, the people who are actually entering the data in the facility, maybe they're not so interested in just the raw number of deliveries that they're having and tracking it over time. What they need to know for their own job are the delivery risk factors that were observed at a patient's third trimester and then maybe also getting some routine feedback on the percent of patients that actually received their blood glucose test according to national guidelines. That way they can actually improve the quality of the care that they are providing and they are alerted to key risk factors that an individual patient might have. So often we see that these nice to have indicators end up being prioritized over the important data for frontline workers and this is not just about extending an olive branch to these frontline workers, but this is actually about including them in the process of designing the system so that they have the data that they need to make to improve their job and they also care about quality data that are being entered into the system. So this is a lot of text and I apologize, but really we can think about three different ways for designing a tracker system. There's the paper-to-screen approach which is you have a very limited budget or you have a very limited time scale so you're essentially looking at just at the data that you need for it to create a replica of an aggregate report. But this is often very difficult in the long term because the data entry flow doesn't match how the end users typically work with an individual level record. There might be redundant or misleading questions at the individual level and the output indicators would just not be relevant for the key stakeholders. If we go to the very right of this, some people would often then course correct and say that okay, we're going to try and get as much data that we think might be relevant as possible into the system and then we can make an assessment later about which data we actually need for our routine data analysis or some research. So in this case they're really approaching tracker more like a demographic survey or a longitudinal study and this really over burdens the end users with data collection tasks that are not necessary. Also as we discussed yesterday, there are additional privacy concerns that you might have with collecting too much data than is strictly needed for the purposes of data use. So we can maybe try to find a balance here in a middle road with a user-centric approach that we're actually encouraged to reach out to the end users and treat them as true partners. And this way ask them about the types of data that they would like to see a tracker deliver. And also really that helps you narrow down the key questions that your health system has and avoid these unnecessary or invasive questions. With a user-centric approach, you can really also instill within the end users a sense of confidence in the system. And with that confidence they will then proceed to deliver higher quality data because they actually get something out of it. So I want to proceed a bit more quickly now, but these are some examples of indicator source requirements that you have. So of course the very baseline that you would start with would be your current aggregate reports. Here's just a disease surveillance form for Uganda that you might be delivered on a weekly basis. So what is the frequency of these paper reports? What are the expected disaggregations or importance to keep in mind? Like here you would see the disaggregations would be by age. But also it might be time to consider in the prism framework for health information systems an actual data quality assessment for your aggregate data. What is the relevance of the data of each data point? What's its completeness, its timeliness, is it actually accurate? And each of those questions will help you fill certain gaps in your aggregate data system that could then be filled in with Tracker if you really focus in on them. You might also look at our M&E framework. So here's just a very basic M&E framework for malaria control monitoring for Ghana. And here we see that there's a number of process indicators and output indicators as well as outcome indicators. And each one of these might be something that you could consider for deriving your Tracker data indicators. So how can our M&E plan incorporate Tracker data for the program is another thing that you need to keep in mind at these very early stages. So maybe there are certain indicators that you should be monitoring routinely on a very frequent basis, like your process indicators, the number of patients that are coming in on a daily or weekly basis, for example. And then which indicators should be monthly, maybe there are some that we only need data for on like an annual basis. So maybe there are certain data that you don't need to see on a dashboard, but you can export the data from Tracker and do analysis outside the system. If you're looking for other places to get some ideas and brainstorming about the types of analyses that you could do with Tracker data, I might recommend this like the global funds list of recommended analyses by program and administrative area. You can see here that there are a number of analyses that individual data would really would really support. And you might even be able to run these analyses on a more frequent basis than the traditional annual or semi-annual basis. So you could do TV and HIV testing linkages or cascade analysis. You could do survival analysis or treatment cohort analysis for TB. You could talk about age disaggregated analysis for adolescent girls and young women programs. These are all things that you might think about how you could actually use Tracker data to deliver these analyses on a more routine basis. And one other thing that I think is a really huge opportunity with Tracker data are considering the quality of care indicators that you have for your program. This is an example from Bangladesh of tetanus immunization. So in Bangladesh, if you're not known to be vaccinated under over 15 years of age or have an unknown status, then during antinatal care, the first TT dose should be given by week 28 of gestational age and the second one by week 32. But you maybe don't know from aggregate data, are these TT doses actually being provided at the right gestational age week to most people actually get their second TT dose during pregnancy? But with this ability to look at the individual patient's record, you now have this opportunity to really look at quality of care indicators that at every visit a patient has, they're receiving all of the care that national guidelines say they should be receiving at that visit. And that further not just at that visit, but at subsequent visits, there's a follow up action that's taken. So I think that looking into your national guidelines for clinical care might also be a place to look for your indicators. So here's like our last sort of brainstorming or thinking exercise before we before we break into the case studies. But you know, when you're sitting with the program staff and you start brainstorming about what data might be possible beyond aggregate, there are a number of different types of analyses that could be done. And here's just a few sample indicators that you can start thinking about. And nutrition, for example, you could think about the percent change for an individual infant and their weight since the previous visit, no, in an Android device if this infant has gained weight. For an HIV system, you could use program indicators to do a cohort analysis of ART attrition. So then you're actually finding all patients who started ART say 12 months ago and analyzing them about their current status, you know, last month, right? If an MCH program, you could provide data directly to the CHWs about the number of postpartum care visits that they provided less than 14 days after delivery. So you can see if they're actually getting this frequent follow up just after delivery. With malaria, and this is a use case for the relationships model of tracker, but you could actually see the number of new cases that were linked per index case. And you can do some analysis around that with some sort of clustering at the very local level. And then TB, and I like today's quote of the day, is TB case surveillance. We'll keep this up for the next slide, too, in case you miss it. But for TB, you might consider the median days between the clinic visit and the lab result by test type. So you might actually do a time to event analysis between the routine clinical visit and then the lab results that should happen after that clinical visit. So you can actually see the performance of the lab in responding to requests for lab results. So I have a short video here about this workshop that Ghana Health Services did a couple years ago. And I really think it illustrates quite well how you can get many different program staff together in a room to discuss the different ways that tracker might support their system. So here you see HIV programs, TB programs, MCH, all sort of sitting around their DHIs to systems and trying to understand how program indicators work so that they can start incorporating them into their monthly analysis plans. And one quote from, I think this might have been Felix afterwards, who was the, he was at Ghana Health Services reading this workshop, but that it's very important to ensure program officers give their support to the eTracker system. And it is more important that they are fully involved in the beginning of the program and continue the training provided for them. So he's acknowledging that it's very important to get your program officers and the end users of your system involved with this tracker system at very early stages so that they understand what data are possible together with tracker and what types of indicators they want. So with that, I think we have Oswald on the line who might be able to share a screen and tell us. Hi. Good morning. My name is Oswald. I work with the Ghana Health Service and a member of Ghana's Institute of Nuclearity. So just a continuation of what Brian has been presenting on the need to build capacity across both as far as implementation of tracker is concerned. For you to be successful, it's not just enough to deploy tracker and build the indicator, but you need the buy-in of all the stakeholders that I had mentioned in an earlier presentation when we started this academy. And one of the key stakeholders as far as tracker implementation is concerned has to do with the program staff, that is technical people, M and E officers who are working at the program level, TB program, HIV, malaria, and all the technical areas of your healthcare system. So it's critical for them to understand what you do and what type of indicators that you generate on tracker. And so in Ghana, in the latter part of 2019, as part of our efforts to make sure that we are at the same level with the programs for them to understand how the program indicators are generated and what outputs they can get from our tracker implementation. It was critical to have capacity to build the session between the Institute of Nuclearity as well as the program offices. Now, there are very key things we needed to achieve. One was to be able to allow us to build that working relationship and our trust levels from a technical point of view and also from the program area. Even though a number of words from the technical team from a public health background, it is always critical in developing program indicators to have these program officers who are really the people who define how the program achieves these objectives, understand exactly what you are implementing, then they can make proper use of it, become part and parcel of the development of the indicators and they are able to relate better with it. So one of the key things we needed to achieve with that session was to build that relationship between us. And we were riding on the back of a TV surveillance tool we were developing and we used that as an opportunity and used that as a test case while we built the tools. We were also building capacity alongside for the program officers in that regard and also to have a common understanding on which data elements and which indicators to create. The reality is that even though Tracker may have the ability and the capacity for you to create multiple indicators and data elements, it is critical for efficiency to really create what is needed and you can only establish that when you have these engagement with the program officers who do the MNE staff and go to the further interactive service providers and all that. And then we also use the session to build some program rules for the TV Tracker program which we do to start implementing the following year that was in 2020. Now there were three key things we did during this capacity building session. The first one we did was to review the program rules and the data concept for everybody to understand what goes into the program rules which in essence helps you to structure how your Tracker program flow so that at a point in time based on data that is being entered on the system, certain data elements that are not applicable get hidden although that becomes necessary get shown and then also use them as validation processes to clean up the data that you are capturing at the service provider level and also went through the indicator concept so that they understand clearly what it means when we see a program indicator and then what an indicator is especially when we were moving from the background of the aggregate system where the indicator concept works a little bit different from the Tracker program indicator perspective. Then we also went through using custom functions in the rules and the program indicator creation as well. Then we had a conceptual discussion on the program rule and indicator evaluation in the priority setting so that you are able to determine which program rules to take precedence over the other. Sometimes it is also critical not to overbear the system with a lot of program rules because that has an impact on performance and so you have to take that into consideration. So it's critical to have this program office that's helping you to really screen up the program rules that you are writing so that especially when you are implementing Tracker and you have to deploy to facilities using the Android app, the more program rules you have in there sometimes you have a bit of a lack and a slow rendering of the Android app. So it's critical to only add program rules that are really necessary and not everything that is in there. So for program rules as I've indicated they simply provide a way for producing dynamic behaviors in response to how users input the data onto the system either for Tracker or for Event Capture. As far as DHIS is concerned the two systems is critical for us to introduce these program rules to structure the system. Another critical thing that it does is to allow you to create a control how the user interface in the Tracker behaves as far as events in the Tracker Capture are the same. And also during data entry the rule expressions are able to be evaluated each time the user interface is displayed and each time a data element is changed. Then we talked of the program indicators which allow us to create values based on the data elements or attributes. Remember that the Tracker system is a transactional system that virtual capture just attributes and data elements of each client. So program indicators essentially help us to be able to generate aggregate values from these individual transactional data that are included during service provision. And essentially we can then build that as indicators and if we so desire we can transmit that into data sets and eventually get aggregate reporting system. And for us that is the key thing as far as Tracker and deployment is concerned. It then reduces and helps you achieve the overall aim of not getting so many errors which regards the correlation of data and then data entry because once you are able to have very good program indicators you are able to convert them into data sets. So as transactional data are captured directly they are aggregate data to be produced and it becomes a lot more efficient. So basically those were the things we went through. We went through quite a number of examples and by the time we finished it was a week long session. By the time we finished with the help of the program offices we had created almost all the program indicators that we needed as far as the TV surveillance system was concerned. And for us it was successful in the sense that this time around it wasn't just the technical thing that was creating this program indicators. We also had the program offices understanding what went into the program indicators and helping in creating them so that if we're defining logics in this program indicator that did not meet the objectives of the program. Our attention was drawn and then together we discussed a structure in a manner that is more efficient for us to be able to deliver the program indicator. So basically this was what we did and since then it has helped us as far as our implementation of Traka and Ghana is concerned. Thank you. So good morning, good afternoon, good evening everyone. In the next 10 to 15 minutes what I hope to discuss is how we consider the analysis and information needs when we design Traka programs especially with the experience we had with regard to information requirements around COVID-19. So Sri Lanka was in fact one of the first countries in fact the first country who started using DHS2 for COVID-19 surveillance. So what you see here especially onto your left side are the components that we designed in our DHS2-based system for COVID-19 information requirements. So you can see like there are a lot of components but what I want to highlight is most of these components are based on Traka. So for example boats of entry, quarantine, hospital, community response, ICU bed tracking, I mean almost all except a few logistics monitoring which is on aggregate. And then this year we launched this large-scale immunization module which is also in DHS2 and it's a large-scale Traka implementation. So overall we had a lot of Traka related experiences as well as mostly challenges when implementing it in the last one and half years. So what I hope to discuss is I will be taking around four examples of different modules and how we consider the analysis and information requirements and how that these requirements affected when we were deciding the Traka program. So few general concerns now only thing which is certain about this COVID-19 is the uncertainty of requirements and the uncertainty of COVID. So the requirements keep on changing so you really need to have a very open mind when you are trying to configure your Traka program. So you definitely have to expect in this kind of situation to have multiple Traka programs. So as you can see here as of now our system has like 18 Traka programs that we are using for different information requirements. And then when you are talking about this many programs it is very crucial that you have your metadata clean because like you are talking about a couple of hundreds of metadata only for these Traka programs. So it is very important that you follow these best practices of claiming conventions that we usually learn in design and customization of PHS too. And then the other thing that we realized is like we have to reuse the same Traka entity type. So as you can see here down here. So we have attributes and then we also have something called Traka entity attributes. We have a separate thing called program attributes. So the difference is that if you use an attribute as a Traka entity attributes irrespective of which program you are going to use it is going to be displayed. And you can search using this attribute. So one thing that we kept in mind in general is to have a minimal number of Traka entity attributes. And if requires we had more program attributes so that we just keep this the access controls and that the granular control of access to data at program level. And then of course one other thing we might not realize because if you are too much DHS oriented is that for end users most of the time they expect analysis and data capture together. Even for us it's mostly analysis separate capture separate but for end users it's very difficult to convince that these are two different things that at least when you're configuring in DHS too. So we had to address this also at certain instances. Right. So I will be talking about couple of use cases. The first one is about contact mapping. So the broader requirement was to visualize the chain of transmission from a suspect to case. So from which one to which person the COVID-19 was transmitted. So it's a kind of like you can visualize a map kind of thing with the people or Traka entity instances connected that we wanted. So the challenges the first of all we did not have a proper visualization support DHS to with the built in the default applications or like data or event visualizer we could not do that. And then we also had to consider about how to adapt the tracker model. Right. We have to decide like we have cases and suspects. So whether we are going to configure them as track entity instances or are these going to be two separate programs for cases and suspects. So this decision we had to take. And then of course like if you are talking about two different track entity instances how are you going to link them up? Right. So one option that was quite straightforward was to use relationships. And then if that is the case, are we using it in a single direction or bidirection? How are we going to do it? And then of course if you use relationships, how are you going to visualize with existing DHS to tools that are available? And then we also had this issue like for example, we know like we have attributes and data elements. But in case if you are going to filter in a front page list or something, are you going to use the mass attributes or data elements? If it is data elements, then the filtering part is going to be a bit tricky. So these are the main issues that we had. And we finally decided that the best way we can achieve the flexibility was to design a custom application. Right. So this is the initial version of the application that we designed based on these concepts that we had in mind. So this kind of visualize from which track entity instance to which one it was transmitted. Right. And we also tried to demarcate whether it is gender based on the domain requirements. So they wanted to have in this visualization itself to identify whether it is a male or female. And of course whether it is a case or a suspect. Right. So those are the basic requirements we initially had. So with this we designed something for Sri Lanka and we also found that it's a kind of a generic requirements that was there across a few other countries as well. So this was when with the help of DHS to Portium in University of Oslo, our team tried to make a generic application for contact map visualization, which is so what you're seeing now is the kind of visualization that you get with this generic app, which is available in the DHS to a pop. But even with this app, we had a lot of challenges and issues that mainly we observe, we obtain from the feedback from the end users. So I'm not going to go through all the challenges, but you can see. So one major challenges like what if we get this kind of a visualization, right? You are talking about now in this, at least I'm seeing couple of thousands of track entity instances. So we were processing all these in the browser. We download everything, right? Because we could not filter it based on a period and the relationship. So we had to download everything and display it in the browser. So if we are talking about very large number of people, the cases, like how is going to be the performance when you are using it in a web browser was kind of quite questionable. So for this, we have obtained some feedback from different stakeholders. And this is what we are trying to do now, so that we try to incorporate one thing is this longitudinal aspect of tracker visualization, like say for example, in COVID, we are mainly considered about 10 to 14 days. So this we are trying to take into consideration here in this new design. And then of course, rather than displaying everyone, I mean, all the patients at one go, we try to just select one and try to drill down to multiple levels. So these are some design considerations that we are doing right now for this visualization. But like only thing we have to go back and think like how we customize the tracker tracker, basically the tracker data model, how we used it to support this visualization. So there are some limitations in the platform as well, which we have to find answers. Right, then of course, the next requirement that we had was something very unique. So we have this PCR testing, which is done in the community, and we have the PCR testing laboratories in institutes. So the requirement was like they want a very transparent mechanism to see like for the community people as well as laboratory people, the status of the laboratory sample. So one major challenge that we had was like they wanted a kind of a custom working list and the visualization. When the community person logs in, he should see only his area's cases that he has sent to laboratory. And the laboratory, the person should only see the lab test that he has received. And the tricky part is like all these community centers can send these samples to any laboratory in the entire country. So if you just, so that is one issue. And then we also have these issues about filtering and sorting based on the test result and whether the test has been approved. So we are talking about whether to use a track entity attribute or a data element, right. And again, when we think about a person, community person being able to send a sample to any laboratory, are we going to give access to the community person to entire country? So that's again a concern. And then of course, so all this, we had like major discussions how to cater this with DHS to, and this is the approach that we took. So we decided to go ahead with this custom application, mainly to serve the requirement of this working list, like a very custom view when they wanted approval and couple of other things to go, which we captured as data elements. And then we use two programs. So we are one, the community people enters data and we have another one for laboratory. And then like we had to have some granular access control at program stage level, so that we achieved by using sharing settings, that we sometimes don't, I mean, we sometimes don't think about this having sharing settings as program stage level, but it was really helpful for us to design this. And then of course, there's this concept that we usually don't use called breaking the glass. So that's how we achieve this granular visibility, like we only see the data that is only relevant to us. This we were able to achieve by using breaking the glass. And then there is another concept that goes with the breaking the glass called ownership override. So we use this, of course, somewhat advanced tracker concepts to configure this program and to achieve our the expected visualization and the information requirement of these stakeholders. And of course, like what we are seeing here is this breaking the gas concept that you can configure when you are initially setting up your program. What we did was we set the access level to the protected. At user level, we had to think about how we are, what is going to be the capture and the search or unit, because all these also have some implication on what data we are able to see. So with this, of course, we were able to like this is the view that the community people see initially. And then this is the screen that that the hospital is able to see, of course, if they approval and the test results sorting everything is possible. So one reason we had to go for this custom application, mostly for to have this working list and also to have this multiple API calls pushed in a single click that the end user does. The next one is, of course, the ICU bed management requirement. So this is a very simple requirement from the end user's perspective. They wanted to know how many ICU beds are available in the country and what is the hospital user hospital ICU person wants to know what is the nearest ICU bed available for me to transfer my patient in case we don't have sufficient ICU beds. And from the national level, they wanted to know the daily status of how many patients are on high flow oxygen so that they can have an idea about the resource requirements which are needed to manage this critically ill patients. One major concern we had from the feedback when we were doing the requirement analysis was that the ICU people, it was very difficult to do a proper training for them. So they wanted something very, very basic without much confusion in the user interface. And then of course, they wanted this separate analytics for ICU beds and the daily status of the patients. So to do that again, mainly because they wanted this simple interface, we had to go for a custom application. Again, we went with two programs, one for ICU beds, one for the patients and track entity types also were different, like one entity type was the ICU beds basically, and the other one was the patient. So it's the same patient I mentioned to you before, like we have the same patient with different program attributes that we are using across different programs. So of course, we went for incremental development. Initially, we just made a small basic application to display whether the ICU bed is occupied, reserved or is available. But then of course, they wanted to capture this daily status of patients to get the resource requirements. So to do that, we had to kind of like one stage, we mean, our program, the tracker program for patient, it had couple of stages like stages admission, daily status, and the discharge or the outcome. So there, of course, the daily status, we just redirected them to the tracker capture because like, that was kind of changing all the time. So that's again, one consideration you can do, like if your requirements keep on changing, better to go with the standard DHS2 application. And then of course, they had this advanced program indicators that had to be created. For example, we have enrollment date by default when capturing program indicators and the analysis when we are configuring. So for example, in some of this, we had to configure based on this concept called this period boundaries where we have, we can, I mean, rather than going with the enrollment date, we can use the event date. Say for example, if we have ICU patient who was admitted or enrolled a couple of days back, but the indicator that we want to know is based on today's situation. Like so that's the latest event of a particular program stage, we can use this event date, event date, instead of the enrollment date and have the enrollment. So these kinds of considerations we had to do while configuring this tracker program. So this is what we did for ICU bed. So as I mentioned, it's just a matter of clicking the status and the color changes. And of course, we also include another interface for entering data. Right. So the final use case that I want to discuss is of course, the immunization, COVID immunization tracker that we designed. So the thing is like, it's like, it's the largest tracker that we have implemented in Sri Lanka. Why I say so is we have the entire doll population, which is 16 million enrolled into this program. Right. So that means like everything that we are going to do with the tracker or the DHS to instance is going to be difficult because it's a very large database that we are handling every time. So few major concerns was the pre-populated large track number of track entity instances, enrollments, and of course the number of attributes, right, we had in the instance. And of course, in on top of that, they wanted to have real-time analytics available. So they wanted to know how many vaccines have been given today as of now. I mean, as per this hour. So for this thing, we had to get real-time analytics enabled. Right. So to do that, we had to enable real-time analytics by, we have a new feature from last couple of versions called continuous analytics. We enabled it. But then again, one issue is like, you always have to keep in mind the continuous analytics currently does not involve enrollment based on. So in case if you want to get design some dashboards based on real-time data, then you have to know that whatever that is there as configured as the attributes, we cannot get a real-time output. Right. So we have to move them to data elements in that case. So there we had to be very mindful about how we are using the attributes and data elements. So that was one major thing. And then like how ambitious we are, of course, it's not V. Sometimes it's beyond our control, how ambitious the ministries are in getting some analytic output. So in small trackers, we don't feel that, I mean, even if you want to get a number of vaccines given in last, I mean, say from the beginning of the pandemic, like one and a half years, it's a major issue. But you can see here, this is from our Glowroot monitoring instance. Like when we tried to get this particular analytic output or this dashboard item loaded, you can see it took 150 seconds. Right. So that particular person who opened the dashboard had to wait. It's around two and a half minutes for this dashboard item to load. So this is because we are trying to get like a very large, I mean, analytic output. We may not actually realize, but the DHS too has to process, do a lot of processing. So this again is something that you have to be mindful when you are deciding your dashboards. So I guess I can stop here. So these are the insights that we have from the implementation of COVID-19 about how to configure DHS based on the analysis and the information requirements. Thank you. Great. Thanks so much, Pomod, for this very detailed and insightful presentation. I am aware that we screen one. So we have a few other questions to go through just to wrap up our discussion on analytics. And by the way, if you have any questions for Pomod on his presentation, please just leave them in the Academy Slack. So about this question of comparing your tracker analytics and your aggregate data, this was actually a research question for the Palestinian National Institute of Public Health when they deployed their antenatal care and MCHE registry, which was a point of care tracker system. So all public health facilities in West Bank were using DHIs to tracker for I think about the last five years to enter in pregnancy profile data. And then a research question compared to this with the National HMIS. And I think it's quite instructive for future tracker rollouts because what you actually find is that the data on things like maternal conditions or timely attendance, these were very different in the e-registry tracker system and the routine health information systems. And so I can mention this is a paradigm shift, right? But you might also have some type of discontinuity with your regular data from aggregate reports. And it may cause a little bit of pause or cause concern or maybe some distrusting of the tracker data. But it's really important to sort of dig into why these results may be very different. So you can see the amemia was misdiagnosed quite a few times, same with very important conditions like preeclampsia or malpresentation at turn. And so either of these were being, we had some issues with counting diagnoses instead of individuals or misdiagnoses. So it's important to really find where the discrepancies are as you're rolling out the tracker to see if it's a data quality issue with your aggregate system or your tracker system. That's very important, especially if you're trying to integrate aggregate and tracker. This is a lot to go through. But so I won't get into all of it. But when you're mapping your tracker data and your aggregate HMIS, we have a full session on linking aggregate coming next week to go into this in more detail. But it's important to really keep in mind how you will align your indicator definitions between tracker data and the aggregate HMIS. One of the most important considerations is whether you are counting events or encounters with the client, whether you're counting enrollments or that is the individual cases. So you might think of a case as like a pregnancy that has multiple visits, and then a tracked entity instance, which is like just like the actual individuals themselves or the patients. But there are a number of other questions to consider, like how you're going to handle referrals or transfers in your indicators if you're calculating incidents or cumulative incidents. And then also about certain types of skip logics you might need in your tracker, or data validations, and then also what types of disaggregations. So this is just a number of questions that you may need to be considering as you're designing your tracker system so that you can ensure that the final tracker data are actually linked well with the aggregate HMIS. So some key takeaways just from the last session before we'll move on to Android. Before building your program, it's important to write down the expected data outputs, because this might actually impact the analytics options for routine statistics, as we saw with Oswald and Pomod's discussion. And this was a question earlier on the slack as well, but I don't want to say that you need to try to include everything that you might want to have in your tracker system. But it's very important to balance a smooth data entry workflow, and also the downstream information needs that your program will have. So finding a nice middle ground there that where the end users are not overburdened, but you're still gathering all the data that you need for your M&E and your routine reports. It's very important to consult with your national strategy guidelines and a broad stakeholder group to actually ensure that you're capturing all the data in tracker that you need for this new model of capturing data. But it's especially important to consider the routine information needs of the front-line users of the system to make sure they're getting the data that they need, and see if they should maybe be increasing the frequency of data, but always important to be specific with what these indicators are measuring, and be prepared for the possibility that because the data are being collected in a different way, they're not going to align perfectly with the aggregate system. So that might be a risk for your confidence in the system down the road of your tracker. So next steps to consider for your project, and maybe this is something you can think about later on in the day, but which indicators are most important to my project, and maybe come up with a list by user profile. So whether you're MOH, an M&E manager, or a care provider, and then rank your top indicators and really go into them in detail, like what you actually mean by this indicator. And then think about how can tracker deliver some key performance metrics to the end users or front-line workers. Maybe a dashboard might be too detailed, but a message or a routine meeting with the care providers would be another way to do it. And when you're thinking about what key decisions will be made based on your data, this is the very first part of that project planning template that Anna shared earlier. So think about what is the objective, what systems will this replace, and who is asking for the system. And I really think that the key decisions that will be made based on tracker data should be at the forefront of those questions as well, so that you can make sure that you're planning to use the indicators that are produced by your tracker. And with that, I think that was all that I had. And we can move now to Android and Jaime. We're set up because I've put my tablet there, so if I look at one point like this, it's trying to work it out because I'm not sure you should be able to see it, right? Yes. All right, good. Oops. Okay, so thank you very much, everyone. Sorry, Jaime. It's not in presenter mode though. What did? Ah, okay. So you see the, so I need to make it for spam? Yeah, perfect. Thank you. Okay, well, all right. So thank you everyone for being here. I am going to be presenting Android for DHS2 and the subtitle or the title of the session to be DHS2 Goes Mobile and Offline. And as you can see, it says part one because we have decided to split the session in two of them. One is going to be taking place now for an hour and the other one has been a schedule for Monday. I think there's a lot of content. There are some questions in my rise up during this session that I think I'll be answering in the second one. So in that the case, I might push the questions for that session and I will try to prioritize the questions for this session. And we will have this last 10 minutes for questions. So please wait until then. I usually like interacting much more between you guys and me, but well, given the global pandemic, this is the way it is. Just a quick introduction of myself. I'm Jaime. Some of you know me already from all the academies. Some of you know me from the community. I hope one day we can meet in person hopefully soon. But I'm part of the Android team in Oslo. Well, I'm happy to see you all guys here. So the sessions have been divided in two. As said, session one, session two. In this one, what I'm going to try to do is present what is the application. I will try to talk briefly about some use cases. Then I will go a bit more deeply onto the application, what it can do for you, what are the main features, let's say. And then I once I have explained this, I will try to demonstrate or I will try to trigger something in your mind for you to understand why would you like to use Android in a tracker implementation, trying to provide some information. And then briefly we will cover some considerations from both parts on the server side and on the Android. Again, there's going to be a lot of information. Do not hesitate to raise, to raise up questions on Slack that I'm not watching now, but I will later on or on the community. And then the last 10, 20, 15 minutes we need to see, depending on how we allocate the time, we will have Pamela again talking about some of their Android issues or considerations they took into when deploying Android in San Francisco. And if we have this time, we might do a little demo or game that I will present. So let's get started. Quickly, what is the Android application? As you can see here, I've tried to separate the Yagonly and you will see in the upper left corner, it says UIO Devs. So basically is because what I wanted you to try to understand is that the Android application that you see down there on the bottom, it's part of the UIO, but does not mean that all the applications are part of the UIO. So the way DHIS2 works is we have a server that provides an API what we can interact with. And this, the main thing that the Android SDK is doing, so Android SDK talks to the DHIS2 API, and then the DHIS2 application is built on top of this DHIS2 Android SDK. Just for you to know that some community applications might be developed and they can interact directly with the DHIS2 API, or maybe they could even use the DHIS2 Android SDK. This is something that is explained deeply during the developer's academy. And I'm just putting it here in case there are developers in the room. I was very gladly surprised last year in Ghana when someone from the audience was a developer, and we got to know a little bit more into each other, and he explained me some stuff that he has developed. I just mentioned it here because in case you are curious about this, please do not hesitate to reach on Slack or in the community, and we can explain a bit further. But basically here we are today to talk about this, the DHIS2 Android application that interacts with the server. So I don't know if we would be live, I would ask a question. I will ask you to raise your hand, but I cannot see any of you now. But I would like to know who of you already knows about Android, the Android application. I hope most of you do, if you do not, don't worry. I'm going to be trying to cover pretty much everything now briefly. But I would advise you to go to the website there, dthis2.org, Android, and then you go to features in the main site on the mobile data entry, because there is a video that covers a lot. There is a different features covered by release version. So I think it's pretty well explained. I'm going to be talking about it, but anyway, if you need to share this later with someone, please go to the website. I think it's quite complete. It might be very useful for you to understand what's going on with Android. Last thing before getting deeper into the application, where to get the application? Well, some of you have been interacting already with the server. Probably a system administrator has set up the server for you. But now if you want to, I'm sorry, this is popping up. I don't know if I can stop it. So where can you get the application? There are several ways to get it. The last one is your own store. This I'm not going to be talking about it now. I will cover in the next session, but basically you could get the application going to Google Play. If you look up for DHHS2 or DHHS2 Capture, you will see the application. You might still see some legacy applications, or you can see some applications developed by other his or by other people, as I was playing before. But basically it's the official one. And you can also get it from GitHub. GitHub is the repository where we code the application. It's fully open source, as you know, the same as the backend. And here, I just wanted to mention that if you would go to GitHub, you will find three versions production, which is the same one that gets published on the Google Play. Training and SMS. Training. I'm putting there in bold because I wanted to let you know that in case we do the demo, you're going to be seeing my DHHS2 training application. The training application allows you to do some stuff that you cannot do with the production one. And for me, it's very useful because it allows me to travel shoot much better. So at one point, if you're going to be implementing Android, you will be installing the training when you are doing all the tests, and then you will pass the production. And the SMS is still this tier because we have some issues with Google in the sense that the application, because it can be used to send SMSes that we will see later on, you might need to publish in a different way. So let's focus on production and training mainly. Quickly, the features we have. This has changed since I was having this lecture last more lecture, last week in Ghana. But I'm happy to announce that now this is kind of what the application could look like. It might be the perfect companion for your products because it can allow you to enter aggregate data entry. It has full tracker support, and it has recently been added with local TI analytics. A little remark here. Sometimes I will be saying TI, I'm sorry, I dragged the Spanish thing. So when I say TI, I'm referring to this in case I say it because I think it will pop up during the session. But because we're in the tracker academy, we're going to be focusing mainly on this. If there are questions about the other two, we can discuss in the other channels. So let me show you the application. I'm not going to have the live. We will do maybe at the end, but I have been taking some screenshots where I cover mainly the main features that could be useful for your tracker projects. So when you would open up the application that you have downloaded either for Google Play, as I've explained before, or from GitHub. This is on the left side, you will see the main screen, where you will have to provide the URL of the server, your username, and your password. Just for you to know that the URL could be used with a QR code, we will see at the very end. And once you log in, what you will see is this thing on the right. Probably you will not be seeing this thing on the right, because this is an example and contains a lot of information. Probably you will be limiting the information that reaches your devices, as we will explain later on. But I need to do something like this, where you can see a lot of things. Because what I wanted to prove is that what we tried to do from Android is we know we are aware that we are talking about a small device and we need to put as much information as possible in a nice visual way. So if we could go through every little detail in this application, in this screen, I think it tells us a lot in a nice way. So for example, you can see that for each programs, we can have icons and colors, as you see pointing on the first one, that we could see what data types are we talking about. For example, here, we have events in green. So here we have the antenatal care visit, which is an event program. For aggregate, we will be having the purplish one, so we can see that it says datasets. And the one that we are interested most in is tracker program, so TI. And basically, it's going to tell us the tracker entity instances we are targeting here. So in this case, person, but could be other stuff. So in case it would not be showing person, but foci, malaria, tracker entity, vaccines, whatever. Just for you to know, and I wanted to mention here that whenever we are using a tracker program, we're going to be seeing here that okay. On top of that, we can see what's the status of our programs or of our aggregated datasets. So for example, here in this mark, we try to see that we can see that this AR team on this summary has not been synchronized because we see this little icon. In case we're talking about events or tracker programs, sorry about the tracker programs, we can see what's going on with our events. So for example, we have overdue events. It helps us recognize and quickly jump into the program where we want. And also, we could do some filtering that is here, that we cover a bit later. So again, just trying to prove that Android tries to put as much information as possible in a nice visual way for those who have to enter or analyze the data. When we are covering a program, tracker entity, tracker program, we are going to define some things that we will reflect it on the devices. So I'm going to try to make a difference between the left side and the right side, and I will explain why later on. I don't have my speaker notes that I should be able to see here as well. Basically, what I wanted to mention here is that when you set up something on the server, this will reach your devices. And what you can do is for specific programs, you can define which attributes you want to be searchable. And this is what Android will later on populate the same way nothing new compared to the web version. But what you have is this plain list. And here, because we have a limited amount of space that we could use, what Android is going to do is going to take the first three attributes and we'll display them in line here. So in this list, whenever you perform a search, you will see those here. It does not have to be the same search about this plain list, but this plain list is all the cards of the DIs that you will be seeing. I'm saying three attributes, but it's not true. It's three plus one, because in case you would have images as a tracker entity attribute, the first one will be display here. Okay. And this is an example program, but probably in this one that we have been using for this academy, we are using COVID cover specifically. And this one on the right side is actually coming from the WH package. And you see that here we have many, much more information at when the card displays, while the card displays only three of these attributes, you could click on the little arrow you see there and would pop up, pop out all this other information. On top of that, again, trying to provide more information here, we can see that there is an overdue event for this entity from the 31st of March. Okay. And still on the program main screen, I would say on the search and list, it has been included recently, the navigation bar down there that allows you to switch. I'm going to go back in the slides, you can see it as well here, bottom part of the right side allows you to switch between list display or map display. So with the map display, what we tried to do is provide visual information like your locating information, where you can zoom in, you can scroll down here on the carousel, what is called the carousel. Sorry, I'm getting this pop up with the people in turn. And then on top of that, on the maps, what you could also do is define layers, the same ways that you can do I think in the server side, where you could have some different layers to map or to pin on the map different things like TI, the enrollment of the data. So still there on the main screen of the program without entering, when you perform a search, not going to cover all of them, but just mention that there's a huge possibility of filtering and sorting. So again, we are trying to help up to help the person in putting or taking out information from the system with all this filtering that allows him or her to search, for example, with dates that were added yesterday or in the specific time in the specific or units that the sync status is one of these ones. For example, imagine you have had errors while working on the field and you want to filter now to correct them or the same for SMS in case you have been syncing by SMS, that we covered that later, don't worry. And you want it to include more information, you can filter by that or for the enrollment status or for email status. So all this is part of the main program screen. And once we get into one of the TI's, these were going to be seen. So imagine here I would click in Fiona, not the case, but I will click on this tracker entity instance that I have searched or filter or search and filter and sort it. I don't know if I mentioned that sort in here, but we can also sort the sending or ascending. But basically, once we get into the tracker entity instance, this, everything we're going to see. Again, a lot of information in a small screen, trying to provide as many details as possible without overwhelming the user. So we'll not go through absolutely everything, but just for you to know that up there, we could have access to all the different programs this entity has been enrolled or sure, yeah, or has been enrolled in one of the other ones. There we could have options regarding the program. We can see, again, the first three attributes plus the picture if that would be the case. We can see what's the status of the enrollment. We can see where the tracker entity was enrolled, what time and which organization unit. We could see more details. We could share this, I will explain a bit later. And here are the program stages or where we could add the events, refer or schedule. And down here, again, something that came in the last version, I think on the previous last, we have a navigation bar that is going to allow us to move from one to another thing. So for example, I think I'm covering it here. The second entry or tab on the navigation bar would take us to the local analytics, which might be very useful for the person doing the analysis, can present here in different ways, could present in bars, in a tabular way or in plot lines. The other, the third tab, it's the relationship. So we could click there and we could see the relationship from this TI to another one that we could visualize either in a list or in a map, as you can see here on the right. And on the last one, we can see notes. So sorry to be a bit rated in this, but trying to present as much information as possible, properly or nicely display area and way to scroll. Okay. So I've been presenting all the application. This is things that you might already knew. But once you have seen this, what I would like you to convince or I would like you to try to understand or I'd like you to think about when you are doing an implementation is why do you think you could be using Android? What is Android giving me that I'm not, I cannot get from the server version of the test. And I've listed some things here. I am, I think I had there on my notes saying that what I'm going to be explaining now, I'm not trying you to, I'm not trying to convince you to drop server. So web version for Android, what I would like you to understand is that Android is there and it offers you some possibilities that might be really interesting when you implement a project. So again, this is not a fight. I'm on different versions. It's just another possibility. So instead of being locked down in one box, we're offering you another box and ideally, you can probably combine both of them. So when I try to explain this, well, I make this point, but I'm going to be covering some points that might apply might not apply. I'm not covering all of them. So I think I'm out later on my explain some of them, which might be listed here or might not. And maybe there are some of them that are not covered here that you might come on, come up with them in the future. So for me, one of the main things, one of the main strong assets of Android is that is mobile. So you're going to be having a small device like a half year or I have my tablet that you cannot see there, that can be taken by the person who's entering data or person who's checking that data and can be taken to the very last mile can be taken to the point of care. So if you have community workers that are going somewhere instead of having papers, they could take the device. And this device will have the information. This is difficult to do with desktop, obviously, and it's it can be done with a laptop, but because we will see later on might not be ideal. The fact that it's mobile and it's included in one of these devices gives other possibilities that are not usually happening with the web version. One of them, for example, is the QR on barcode input. We know that in some projects, they use barcodes to enter data, lab tests, COVID passports, et cetera. So if you could be using a desktop, probably you will need to add a barcode scanner or this kind of barcode guns that will could read the barcode. But this forces you to install some software on your on your laptop or desktop and somehow set it up. While the fact that most of the devices, if not all of them include a camera, allows you to just click on one data element or activity that has been defined as barcode or QR could make your camera to pop out. You could read as it says here and this field will be auto populated. This works for barcodes and QR and we know it's been already used in some projects. Another good, strong thing that it has is that it's touch and graphical input, which can help some people with which are less skilled or with literacy issues. For example, as you can see here on the right screenshot I took, we have tried to put different colors, but also some pictograms that could help someone if they would not know what a microscope is, but they could relate because of the pictogram might help people that have lack of language skills or translation skills by being able to just click on the screen button, let's say, or the screen area. Sorry, you could input it. So there's something that it's really useful. Also people are really used to use phones, so we believe it's quite easy to enter. The fact that it's a battery-powered device makes you capable of taking it with you. It's also a small device, but also usually the batteries will be lasting much more for these things than in laptops. Obviously you cannot do it. So again, trying to reinforce your demobile fact. Another strong point that we cover a bit later on is connectivity. Most of the Android devices include by default a SIM card. This means they have 3G, 4G, or well, maybe 2G capabilities, but also SMS. Tablets in some cases might not be because they do not include disconnectivity, probably they will have Wi-Fi, so still could work in terms of if you can move with it. You don't need a cable anymore. When we're talking about community work, for example, or you go out there in the field, this can be pretty useful because you have your phone, you have everything you need as we will be seeing in the next section, but you take it with you. No need to have cables, no need to have connectivity. If you have great, if not, you can always sync later on, as we see later. But that's it. You take this as you. And also offline, I'm covering this a bit later, I think in two slides. I will go back to it because I think for me it's also one of the strongest assets. So in terms of cost, I'm not sure if you have already had the budget session or it's coming soon. But when you decide to use Android on your projects, it's going to have a big impact in your budget. And I'm not saying it's always going to be on the bad way because somehow it could also be on the good. And here I'm trying to put some examples, but I think it could somehow reduce your infrastructure, infrastructure costs on some cases. For example, if you will need to provide facilities with devices to enter data on your tracker program, you might be buying desktops or laptops. If they are ready, it's fine. If they're not, you have to procure them. And sometimes you will find that these devices are cheaper. For example, I know some players like in Gambia, they have decided to use Chromebooks. For those who are not aware, Chromebooks is like a laptop, a bit cheap, but runs Android. So they are using the DHS200 application on them because they wanted to have a keyboard and they didn't want to buy tablets and on top of that keyboards. So by having the Chromebooks, they had everything the best from the both sides. They have like a kind of keyboard, laptop, but running Android. In some scenarios, I think this already present in some projects where they have allowed health workers to use their own device. This BYOD means bring your own device. So somehow you don't need to procure, even though these have some security risks that I will comment on in the next session. But you could be using devices that most of us already have. I think everyone almost now this has a smartphone. So we could be using the Android application to access the DHS2 on their device. They will just need to be facilitated by username and password and they could be using it. And also, I think in some logistic cases, you could enjoy this country to infrastructure cost because in terms of power supply, you might have power banks that you can take with you that it's impossible to do with laptop or desktop. In terms of connectivity, the fact that these devices already have the connectivity, you don't need to procure Wi-Fi access points or you don't need to provide USB modems, etc. And the online one. For me, I think this is the highest highlight of Android because connectivity is a challenge in many implementations. I come from working on an NGO when I know this is a fact. In many places, you will be lacking connectivity and this would make it possible for you to work from a device that requires to be connected the whole time as it is with the web version. So the strong feature of Android is that Android allows you to work completely offline. This has its advantages and its drawbacks as we will explain in the next session. But basically, what Android does is try to acquire all the information that might use when they are offline. So let's say you have a community worker that is going to an isolated village where there's no absolute zero connectivity. So he or she will go there and could perform all the work without needing to have 3G, 4G, Wi-Fi, SMS connectivity. He or she can work on the device and then whenever he goes or she goes back to the town, he could put the information. That's the reason I'm putting the Bradley connectivity or fully offline because also if at one point you will be implementing a project tracker project where there is absolutely zero connectivity, you could say, okay, the person could work for a month or two months, whatever beauty is required, and then could come back to a place where they have synchronization or even fully offline in the sense that the application has capabilities to transfer information even though it's not ideal by QR codes. But you could also find that situation where an isolated phone could somehow sink the server via another phone. And also SMS sync. I know that some places cannot have or not have 3G or 4G. So Android application still would allow you to synchronize via SMS. I know that some Ministry of Health in Africa have reached an agreement with telecom operators for them to be able to sync Syncs free of charge. So I think it's also something that it's really interesting, even though SMS when using aggregate will not send as many SMSes and when you're using tracker, maybe for the synchronization of that tracker in the instance, you might need four to up to eight SMSes. So I think it's not ideal, but I think it's worth also mentioning that there is also a possibility. Sorry. Okay. So I've been talking about the application, why you might want to implement Android. And now let's say I might have convinced you and you say, okay, I think it could work on my credit. What should I take into account if I decide to do this? So of course this slide does not cover absolutely anything. It goes some minimal part, but there are things that I want to mention here because I think it's really important for you to know and to consider whenever you decide to do an Android implementation for a tracker program, because there are things that you must do both sides on the server side or on the client side. So if I go to the server side, one of the main things you should consider, well, first of all, you should know that whenever you implement an Android way, you need to make changes on your server. Most, I mean, I would say in 99% of the cases because your specific setup is not fully adapted for Android devices. And these are one of the main things. Again, there are more, but for example, the sharing settings, I've been telling you that the way Android works is the device tries to download all the information that it might use in the future when being offline. So the device will take and will tell the server, okay, give me everything I might use in the later data entry stage. If you have not set this properly for the web version, that's no matter, because when you connect with your computer, you work, but you don't pre-cache all this information. With Android, it's the opposite. Android takes everything. So if you would have not set this properly, the device is going to add a lot of information that will not be used. And this, you could see a problem from maybe the security perspective, but also it's a problem from resources in the sense that you're going to be downloading a lot of information. So this affects your internet connectivity, but also could affect your server in the sense that if you have one device, a lot of information could be okay. If you have thousands of devices requesting all this information continuously to the server, you might kill the server somehow. This is something that we explained in the next session, which is called the syncing strategy, and it's something you have to think of. So the sharing settings need to be usually adapted from what version to Android version. Ideally, when you reach the Android version, we'll also work for web, and we'll be more optimized in that sense. For the visual configuration is the same. If you remember, I was showing you on the right side at one point a microscope, the RDS, et cetera. These are things you need to work on. Probably this will also trigger if you have people that are not very well educated and they might need to have specific training. You could work with colors, you could do different pictograms. So all this is not there by default. It's something you need to work on. I am not sure it's available on web if I'm not mistaken. So this is something that you need to build on top of what you have. Everything is there, but you can reach this beautiful configuration in a linear entry or a matrix entry with colors, pictograms, et cetera, which I think might be really useful again for people who might not be very literate or they might have some translation skills. So by using colors and pictograms, you could really improve the data quality. So this is something we achieve through the visual configuration and it's something you need to work on. If we talk about how to generate it values, I know many, many programs, rocket programs, they use unique identifiers, which are generated automatically by the system. And here I'm going to try to explain somehow for you to understand because some people have already found it a bit surprising, but if we roll back like five minutes when I was trying to explain you that Androids are going to download everything they need to perform their tasks in the future. As an example, imagine that you have decided to have a unique identifier for a set of patients that work from the zero to the 1000. And you're going to have 10 workers collecting this information. So whenever you could set up your program, you would expect to have from zero to the patient 1000, somehow in line. So first time, first patient you enter is the 001, 002, et cetera, to the 1000. Because Androids devices cannot know how many patients you will be included beforehand, what Androids devices are going to do, the application is going to say, it's going to tell the server, okay, give me a number of these identifiers that I might use or I might not use. So again, when you have 10 devices, so the first one is going to request the server 100, the second one another 100, et cetera. This means that at one point, I might have in the server, because the first worker goes on the field and register 20 patients. So he's going to register from the 001 to the 0021. And then he synchronizes towards the server. And then the second page, the second worker is going to register from the 100 to the 120. So at one point in my server, I could have these gaps. And this, I think it's important for you to know, not specifically this case, but just for you to understand how Androids is working. Androids pre-catches everything and then syncs to the server. And this can lead to these kind of gaps or discrepancies that you would not see in a web version only implementation, but it reaches with Androids. So somehow might trigger different complexity when setting the I hope it was clear. And then program rules. And I'm very sorry for this because it's one of recurrent topics in the community or in different support channels. Some people set program rules on their server. They work on the web version. And then they say it does not work on Android. I'm sorry to tell you it's absolutely true. It happens. And it is because the web version and the Android version, they are using different program rule evaluators. And I know it should not be the case. And we are working on it. And at one point they are going to merge. So you will not have these discrepancies. But at the moment, at the current time, whenever you set up something on your server, might work in one thing in one version, so one version and might not work in Android. So this forces you to make tests and tests and tests. Okay. On the client side, so we have been talking on the server, the things you would need to do on the server. Now when you have decided to implement Android, the thing you need to do on the client side is that you need to make sure that devices you're going to procure to your workers. They are complying with what we have called the device specifications that I have linked here and I will link also afterwards. Unfortunately, it is impossible for us to tell you this will work. This will not work because it really, really depends on each implementation. If your program is full of program rules, is full of pictograms, is full of a lot of information, you might need a more powerful device. And if your program is very simple, you might be able to do it with a very cheap or not so powerful device. This is the same way that for servers, I think there's another session talking about this. We give somehow guidelines, but it is impossible to tell these yeses no. So what we usually recommend in that sense is that you would acquire a small set of devices, you test them, and once you're sure they do work as you expect, you will buy the rest of the devices. It can be challenging. It's also could be very bad that you decide to move to Android or to put into place Android. And then in the end, the workers decide not to use them because they're very slow or because they don't work or because you have provided them with the small screens like this and what they need is to enter a lot of tests. So they wanted to have a keyboard, et cetera. So that's what I'm seeing here, the type of devices. I think you need to understand your worker requirements for you to analyze. That's okay. Now I have these device specifications. I have tested that it works with this device and I know that my workers need this, this and this. So with these things into mind, you should be able to acquire the proper device. And again, we just recommend starting small and then scale up. Also for the bring your own device, what I mentioned before, at one point, you might find yourself using or implementing bread, but you do not have the time as it might be for COVID, I think in some places, I think in Uganda, if I'm not mistaken, they told the users, this is your phone. So the workers were given a username and password and they could use it on their own. So might not be ideal from many points of view, but somehow you could use them for a quick deployment process. I know there has been a lot of information here. You might have gras some of it, you might have not. So what I wanted to tell you is that we have most of this information shown or explained here in these two guidelines, we have included, they are both in the official documentation. One is the configuration, which explains a bit better how to, what you should do, the changes on your server to achieve something on your devices. And the other one is the implementation guide. So I think both could be very helpful. You have the link there, but if you could go to doc.thi-super-log, you can also find them. And I think, yeah, so that's all for this session. What we have in the next one is going to be this. So I will cover all the things that I've been saying. This I will explain, this I will explain. It will be explained here. So now we are going to have some Q&A, but I think because BAMMOTE should be ready. I don't see the stream. I will check now, but I think what we could do now is have, instead of the Q&A, have BAMMOTE. And then we can have the questions. If he's not ready, we can take some questions. But just for you to know, if there are questions related to what I will be saying on Monday, I will not answer them if you agree with me, because I think it makes no sense that I anticipated what is going to be coming. And if BAMMOTE finishes before, whoops. Oh, yeah. So