 Okay, you should be seeing the agenda right now. We are here in the last session of the day and what we'll look at now are the tracker use cases, getting a better sense of the way that different countries are using tracker but starting out with giving a shared foundation and about tracker kind of functionality and what we see from the University of Oslo is kind of the main purposes and intentions behind tracker. So I'll spend maybe 20 minutes or so discussing that from the University of Oslo's perspective and we'll dive into the WHO packages and then we'll start to go through individual countries. I have them listed here, those that we would be hearing from beginning with Ethiopia in about 20 minutes or so. So with that, I think I'm gonna go ahead and start sharing my slides. Alice or Martin, can you confirm that you can see my slides now? Yes, Mike, thank you, good to go. Great, thanks. So again, just to make sure that we all have a very shared understanding about what tracker is, there's a wide variety of participants here, those of you that are very experienced with tracker and some of you that are just about to start using tracker. So we just wanted to make sure that everyone has the kind of shared understanding of what tracker is and how it works. Tracker is just a part of DHS too. Oftentimes it's presented as if it is something different, but it's actually just a part of the platform. It's one of the apps within the platform. In fact, we talk about it a little generically as tracker, but the reality is that we have the tracker capture app and we have the capture app, which has the events functionality in it. But essentially we're talking about the parts of DHS too, which are responsible for individual level data. This individual level data can be longitudinal, it can take place over time or in the case of the events model it can just be a single event. It's meant to be generic. So as we are doing the software development here at the University of Oslo, we are always thinking generically. We know that you have very specific use cases and you have very specific needs, especially within tracker because tracker is often used at a clinical level. It's used in a very specialized way to support different work processes. And so we are being asked constantly to add in specific functionality for one key use case. But on our side, we do as much as we can to take that specific request and turn it into something generic that can be reused by many different use cases. The idea is that we don't want you to be constrained to a very specific way of using tracker. It's meant to be flexible. It's meant to be something that you are able to adapt for many different purposes. And as a part of the DHS2 platform, it of course has the ability to take advantage of all of the analytics and visualizations of DHS2. Many times we see that tracker is being used to collect data but it's not being used fully in terms of being able to share that data and analyze it, put it into the dashboard, combine it with different sources of data, compare it to the aggregate reported data. So we wanna make sure that you know and are aware of the various possibilities of using tracker that way. And again, this all fits into the concept of implementation because you are making the decisions about what data to capture, what work processes to support, what decisions can be made and it will help you if you understand exactly what is possible, what is available within the tracker application. So again, I wanted to show you just a very simplified way of thinking about the DHS2 data model. If you think of an event as being kind of the smallest level of analysis or the smallest level of data entry, it's very simple, an event is something that occurs on a specific date at an organization unit within a context, within a program. You've decided that you're collecting information about ART and you have certain data elements, certain questions that you're asking about that ART event. These events can be repeated over time and they can still just be a single event. They're not linked, they are just information that you are gathering about that event occurring at a location, at a date in a program. But if you wrap a tracked entity around a series of events, then it becomes tracker. This is when you get to start to have a longitudinal record so that the events are not just standalone but they're actually following a kind of meta piece of data, which in this case, we're looking at an example which would be a person. But a tracked entity can actually be anything. You determine what you're tracking. A tracked entity could be a lab sample that you follow through collection to result to reporting. It could be a tree that you're following over time as it grows. There are many, many different ways that people are using tracker and they identify a tracked entity as whatever that idea is that they want to follow over time and through events. So then you can have a series of tracked entities, of people, of lab samples, of trees, of whatever it is that you're tracking. Every time something occurs with that tracked entity, then it would be registered as an event within the tracked entity, in the context of a program, in an organization unit at a certain date. All of this information can be aggregated. So you can wrap that information into program indicators or other ways of aggregating the data upwards. So you could still have all of the aggregate outcomes that you're used to getting through the standard DHS-2 HMIS reporting, for example. But you would be given the granularity to also go down to the individual events or the individual tracked entity. So just one way of keeping in mind what is tracker and what can you do with it is just to think of tracker as something you're following over time. You can use it to support work processes or workflows, but you can also make sure to use that data in an aggregate way to have the kind of overview and oversight of your different health programs or other programs that you want to follow. I won't go into all of the details here about tracker functionality. We'll be giving you access to all of these slide decks. And so this may be something that ends up being useful for you. But I did want to give just, again, a basic idea about what it is to run a tracker program. You do define a tracked entity. I've put examples over in blue for each of these and what they mean. You create a program based on some kind of work processes. You then can enroll your tracked entities into those programs. But a tracked entity can be enrolled into many programs. So again, this is one of the things that we often see countries not taking advantage of. The same tracked entity, a person, can be enrolled in an HIV program, a TB program, a nutrition program, and an anti-natal care program. And when you combine all of those different pieces together, it becomes kind of a shared health record, for example. So you can search for tracked entities outside of a program or inside of a program. And if you have access to the multiple programs that the person is in, then you can see all of the health records associated with that person, for example. You can use it to generate a list of tracked entities that meet your criteria. You can follow up on them as a clinical person or as a person responsible for following lab samples over time. You can produce a working list, something for your work process of following up. You can, of course, do searching for individual entities. You can generate unique IDs. This is one of the most important concepts of tracking or of following longitudinal data. You have to know who is the person. And we know for many countries, the national ID is not something that's widely available. There may be challenges with identifying a person just based on their name, given differences in spelling or the constant repetition of names, but you can always generate a unique ID that is attached to that tracked entity. We also give you the tools to identify potential duplicates. The system will return in the search any potential duplicates. Your user also has a chance to mark something as a duplicate and you can always export your dataset and do some cleaning of the duplicates as well in other tools. The data entry is meant to be customized. So if you're, again, not taking full advantage of kind of the layout of data entry, then you're missing out on some of the benefits. You can group questions into different sections. You can hide sections based on the person that is logging in and what roles they have, which program stages they should have access to, whether they're entering data kind of in a tabular format or if they're going question by question and many different types of data elements that you can ask whether you're capturing GIS coordinates or you're entering in a text response or multiple value radio button.