 Right. So once again, good morning, good afternoon to all of you. So the next session that we are going to cover today is on tracker terminology and tracker data model. Now, it is so good to see so many familiar faces. So I know like some of you have been working with DHS to for a while may have also been experimenting. So you are kind of familiar with tracker, but I also noted there are a few participants who are kind of new to tracker. But for all of you, I really recommend I mean this tracker data model and understanding the terminology is the key. Even though when I mean is the key if you are going to configure the tracker in DHS to or even you are going to use the DHS to tracker for analyzing data. So for whatever the purpose that you are going to use use DHS to for it will be very important to understand the data model. So I hope in next 30 minutes or so you'll be patiently listening to what I'll be presenting. And in addition, I also expect you to be actively engaged. You can ask questions. Of course, you can use Slack or the zoom chat whenever you have a question. And sometimes I may ask one or two questions where you can raise hand and unmute yourself and answer. Because I feel like this is the core which you really need to be clear of before you start analyzing or using the data which is captured in DHS to tracker. All right. So let's see what we are going to cover today and the objectives. So the first objective is to understand what a data model is and how it relates to the DHS to tracker. And then we will define the common terms used within the DHS to tracker data model, which are very important. And then we will describe the general flow of information used within the DHS to tracker data model. Like how, where we are capturing data and how it flows throughout the tracker data model. That's what we are going to cover in the third objective. And finally, we will also try to understand how these components of the DHS to tracker data model are linked together. So these are not just isolated building blocks. These are all interconnected. And actually this interconnection is what makes the DHS to tracker so flexible in rendering different use cases. So what is the tracker data model? And in fact, what is a data model? So in fact, in the DHS to the data model is a fixed part which cannot be modified. So this you have to clearly understand whenever if a client or stakeholder or you by yourself encounters a use case, and you are in doubt to decide whether you can use DHS to for this use case or not. The best thing you have to always remember is that you will have to compare and you have to actually analyze the use case and identify all the elements and different workflows within the use case and see whether the DHS to data model is supporting this particular use case. So if it is not supporting, then it might not be ideal to use DHS to as a standalone solution for your use case. So that's as simple as that. So this is exactly why you will have to understand what the DHS to data model for trucker is. So then only you will be able to decide whether it is going to serve your requirements in customizing or adopting DHS to to serve your requirement. Okay, so this includes the required structures and objects that define how we can set up metadata and store our data. So I hope you are familiar with these two concepts called metadata and data. So data are actually this granular the actual data that you will be storing in the DHS to or whatever the database. What we mean by metadata is actually data, some information about the data that you are going to capture. So metadata is actually what formulates the structure. You can think of it something like for you to say, for example, in good old days, if you are actually collecting some data and you are going to put them in a table, you would draw a table, right? And you will draw a table and you will kind of name the column headings and maybe the row headings, right? So basically these column headings and row headings are kind of defining what will be the data that you are collecting on that particular column or row, right? So it's kind of describes what will be there in that particular row or column. So it is kind of defining these data a bit further. So it's data about the data that you're capturing. So in fact, that is what we mean by metadata. So in DHS to also, we have something called metadata that you usually configure once before start collecting data. So when it comes to configuring your DHS to tracker, what you will do first is to configure the metadata, right? So for example, these are the different types of metadata that we are using in DHS to some of them. So organization units, you must be definitely familiar because you have you have all done the fundamentals. So we talk a lot about org units and data elements indicators. And when it comes to tracker, we are talking about few other new metadata items such as programs track entity attributes and many more. So what we are going to discuss in today's presentation is about this metadata, which formulates the tracker data model, right? But we will not be talking too much about the metadata that are general metadata. You might also find when you are configuring DHS to for aggregative cases. I guess you all must be familiar with these general metadata because you have covered the DHS to fundamentals. So this slide kind of highlights all major types of metadata involved with the tracker, right? There are few other finer areas which will not include in this slide because we don't want to really confuse you too much at the beginning. But we will be talking about them while we are in the course of this academy. So now when it comes to the tracker data model, we can actually divide all the terminologies and metadata components into two broader categories. So what you are seeing at the top inside this orange color box, for example, the concepts such as track entity, track entity attributes and track entity instance, they kind of identifies the concept that we are going to track, right? So the DHS to tracker is called and named as tracker mainly because we are going to track, right? Of course, we have two separate components within the tracker called the event and the tracker events are kind of one of incidents, whereas tracker is where we are kind of longitudinally throughout time dimension, we are going to track a particular entity. So this entity can be anything. It could be a live entity like a person or maybe an animal if you are kind of implementing DHS to veterinary sector, or else it could be any object. So it could be a laboratory equipment, right, or as a sample. If you are kind of collecting, I mean, it all depends on the use case that you are going to use DHS to form. So these three concepts are kind of identifies what we are tracking. Okay, so all the other concepts that we are highlighting in this blue color box below. For example, program, program stage, event, data element, option set, option, these kind of describes the information we are collecting about the concept that we are tracking. So for example, if we are tracking a person, so everything related to the person are included and defined by these three metadata concepts that we are, that we are highlighting in this orange box. And what actually the items or data points that we are collecting are inside all these, I mean, it is captured in an environment which is constituted by all these metadata items which are highlighted in the blue box. Okay, I assume you understand up to this point, but what we are going to do next is to kind of explain and go through all these type of different types of metadata items. Okay, right. Do we have any questions as of now? I don't see any on the chat. I hope there is nothing on the slack as well. Right. So let us now see what we mean by this first three metadata items which describes the entity. So I will start with the second one, the tracked entity. So as the, as the, as it implies, it's, it refers to the type of concept that is being tracked. Right. So the tracked entity means the type of concepts that we are going to track in the HIS too. So this could be a person in most of our implementations in health sector. I must mention health sector because right, I mean, right now we are seeing a kind of a trend where the HIS too is increasingly being used in outside of the health sector as well. Okay. So in the health sector, it's mainly the persons are what we are tracking. So basically at a very broader level, a person could be a tracked entity. But in case if your DHS to implementation or is focusing mainly on the laboratory sample, the laboratory sample could be the one that we are tracking. Right. So, but I must also mention in one single DHS to implementation, you can have one or more than one track entity types configured. Right. So for example, in a, in an ideal COVID implementation, you might have, you might be tracking persons, you might be tracking laboratory samples, and you might even be tracking cases. Right. So that is, you will have to define all these as tracked entities in your tracker configuration. Okay. Right. Let's now go to the third one, which is actually the tracked entity instance. So as the word, these three words implies, this actually means a single instance of this tracked entity. So for example, if you configure a broader concept called person as a track entity, the person named a named James Andrew could be the tracked entity instance. Right. So if you are coming from an IT or informatics background, this is something really similar to this object, task and object relationship. Right. So you have class is a kind of a broader thing. An object is one single entity. Right. So similarly, here tracked entities, this broad concept, for example, a person and person names, named James could be the tracked entity instance. Right. So laboratory sample would be the tracked entity and laboratory sample a one zero five could be the tracked entity instance. Okay. So this is basically a kind of a group and one single instance concept that we are describing by using this term tracked entity instance. Okay. Right. So all these tracked entities are inherently having their own properties. Okay. So for example, if we register a person as a tracked entity, the person has its own properties. These are usually semi permanent. Right. And these are the ones that we refer with this concept called tracked entity attributes. So if we have a tracked entity called person, the person's attributes or properties are the ones that we define as tracked entity attributes. So for example, if our tracked entity is a person, our national identity, the name, sex, date of birth address, four numbers are individual attributes of these persons. Right. So you have to define when you are configuring your DHS to tracker, all these attributes separately for that track entity. Okay. Unfortunately, we are not going to cover the configuration part of these tracked entities and track entity attributes in this particular academy because we have a separate academy called tracker configuration level one to serve this purpose. But here I'm just, we are just trying to highlight how the configuration of your tracker instance is linked to the data use that you are going to actually study during this academy. Okay. Right. So I hope, are there any questions? Right. Any questions related to this, this presentation others, of course, my colleagues will be attending to the logistics issues related to Slack and all they will be attended. But are there any questions you have about the three concepts that I have described so far? If there are any questions, please type in the chat box or else you can even raise your hand. Great. So I don't see any specific questions. Very good. Right. So let's move forward. Now, the blue box, right? So now we are already familiar with these concepts called track entity, track entity instance and track entity attributes. Did someone unmute? Yes, Sashan. I'm seeing you are muted. Do you have any questions? All right. So probably it's a mistake. No, sorry. Okay. All good. All right. So now what we are going to discuss is about the data, right, that we are going to collect or about these entities that we are going to track. So there are a few concepts related to this configuration of this great data. Right. So the first one is a program. So what do we mean by a program? A program defines the sequence of events that attract entity can go through. Okay. So I'm repeating it again. It's a kind of a sequence of events attract entity can go through. Okay. So for example, if we define something or some concept called a disease surveillance as the program, right? This is surveillance as the program. What it means is if we have this tracked entity call person and if we have the track entity call attract entity instance called James, this person James what he will the sequence of events, he will go through during the data collection, right? Is what we refer to as a program. So for example, if we have a program called disease surveillance and James is a part of that program. It is like all the sequence of events that we are going to capture for James is what we are going to define in this concept called program, right? So now here this program, of course, will have like so much of data that we are going to capture that it will be too confusing to list all of them at one go, right? So what we actually do in this broader program call, for example, disease surveillance, we kind of break down all the particular different events that he has to undergo into broader categories, right? So these broader categories are what we call as program stages, right? So program is a very broader thing that attract entity will go through and that we are kind of compartmentalizing and into stages. So that those, of course, are what we define as program stages. So for example, in a disease surveillance program, it could involve broader categories of events such as clinical examination, right? And then specimens, if we take some samples from that person, we are the tracking of the specimen, laboratory results and case investigation. So these are broader events, broader areas that we are going to collect data on, right? So these, of course, we can kind of define as program stages, right? So ideally speaking, program stage kind of defines what data should be collected during a specific type of event within the broader program. So for example, lab result stage, if we have something like that, it will collect information about the lab results events, right? So these can be one single event or repeatable event. So for example, in most of the instances, clinical examination, we are kind of doing once, right? So we may not want to have that particular type of event repeated, right? I mean, this is an example. You may have pressing reasons to have it repeatable. If that is the case, you are feel free to define it as a repeatable kind of a stage or else you just can define it as a non-repeatable one, okay? So what we try to highlight in this slide is that we have something called program where we can kind of connect attract entity into, right? Inside the program, we are collecting the actual data, right? And this program, because it's a kind of a broader thing, we can compartmentalize it into different stages. So these stages, of course, which I will mention next, will be the kind of snapshot where we are collecting the actual data, which I will be explaining in the next slide, right? So are you all kind of okay with this program and program stages? So do you have any questions? Yeah, all right. So I have a question here from Dr. Janaka about explain more on attract entity instance. So if you can, of course, unmute and ask the specific question or in fact, like what we are going to do once we have defined all these concepts is to kind of have one slide where we will kind of go through a particular use case. So you will understand it a bit more. So shall we do it there or you want to ask the question now itself? Okay, all right, okay. So let's proceed and we will take up in that final slide, right? Okay, so now we have discussed about attract entity, attract entity instance and attract entity attributes, program and program stages. Now let us see the next few concepts which are the first one is event. So basically what we mean by event, it is actually a snapshot of a particular program stage, right? So program stage can ideally have one or more events. So when a program stage is not repeatable, you have one to one match between a program stage and even, right? But when a program stage is repeatable, right, that particular program stage can have multiple events. Okay, so what we actually mean by event is an instance of a program stage, again, kind of like object task relationship. So we have something called program stage and a particular instance of this program stage is what we mean by the term an event. It's actually an encounter, right? So these events for a program stage can be repeatable or non-repeatable. Some program stages, the way we define it are non-repeatable because we are sure that these kind of events only happen once for a particular attract entity when he's enrolled in that program, right? But sometimes you can have multiple events. So for example, if we have, say, collection of specimens, it might be that we are collecting multiple specimens. We might take, say, nasal swab, so we might take even blood sample, urine sample. So that kind of a program stage, we can't actually define it as non-repeatable because we might have repeatable events. Okay, but for example, based on your context, something like clinical examination, you can do it once for the surveillance example. But if you are configuring a program for, say, a clinic or, say, I mean, maybe in board setup, right? There are clinical examination is something that you might do on daily basis even, right? So if that is the case, then you can actually configure it as repeatable. So what I try to highlight here is there are no hard and fast rules as how you should configure it. It is all very contextual based on your use case. You have the freedom to define the DHS to the way you want. But to do that, you have to understand the limitations and the data model very well. Otherwise, after configuring, when you start collecting data, you will encounter issues, okay? Right. So I hope you understand the concept event, which is actually one instance of a program stage. Okay. Do you have any questions? All right. So next we will be discussing about a few other concepts which actually kind of connects the tracked entity that we describe first with this program and the data that we are collecting. Okay. So let's start from the one below, which is called the enrollment. So what we mean by enrollment, it is the process of taking a tracked entity and registering them into a program. Okay. So remember, in the first slide I mentioned that we showed there are these two boxes, right? One with the orange lining and the other one with the blue lining, right? So these are two different types of concepts that we are that is associated with the tracker data model. And we mentioned there is something called track entity. And then we also mentioned a few other concepts related to program, program stages and events. These are actually the sequence of events this track entity will go through. But for this to happen, we need to actually connect, right? The track entity with this program, this connection or registration process of a track entity into a program, right? This is what we refer to as enrollment. Okay. And together with enrollment, we generally tend to define these two other concepts. First one is the enrollment date. So what we mean by enrollment date is a date the entity is enrolled into the program. So for example, in the COVID-19 use case, the date the COVID-19 patient visits the clinic and receives their initial diagnosis and assessment would be the rational date to be considered as an enrollment date. Okay. Because like when the patient comes to the hospital and we are suspecting this patient to be having COVID, then only we kind of, you know, tag or label that patient as suspect. COVID and start, you know, enrolling and start investigating to confirm whether this person is actually having COVID. So that's the kind of, that's actually the date where everything is triggered and all these actions starts, right? So that we generally tend to consider as the enrollment date for this given use case. But having said that, is it fair to consider that the day the patient came to the hospital and we detect that person and we suspect and start investigating as the date the patient actually got COVID? It is not, right? So we all know, like in most of these infectious diseases, there is a, there is a window period from the day the patient actually contracts the disease to the day he actually starts showing symptoms so that he will be presented to our health system, right? So that is why we all also have another concept in the DHSU tracker called the incident date. So here it is a date which actually triggers the first event. So for example, it could be even like, so this again is very contextual, right? So here we have to define a date where, you know, like the patient can recall or like we kind of in our health system, we agree, like, what is the, I mean, when do we consider as the date he got COVID? So for example, the date of onset of COVID symptoms could be considered as the date of incidence, right? So again, no hard and fast rules. So we don't need to argue about a given scenario and the public health perspective on that, right? This is all about configuring and using DHSU. So here you have the freedom based on your expertise to decide what should be matching date for the incident date and what would be the one that you'll be using for the enrollment date. And I must also mention, in some of the tracker use cases, it is optional to define an incident date, right? So because for infectious diseases or for surveillance and communicable diseases, it may be very relevant. But there may be other examples that we are using for tracker, we are actually using tracker, we are using the concept called incident date is not that relevant, right? So it's a kind of optional feature that we have in DHSU. Is everyone clear? Are there any questions about the technicality of these dates, not the public health aspect of it? Okay. All right. I don't see any questions in the chat and no hands raised. So I believe that you understand everything I have, we have been discussing it can be even the other way around. I hope not. But let's see. All right. So the next is where we discuss about the actual data that we are going to collect. So to do that, again, going back to the experience you have with DHSU aggregate, you know, in DHSU, how we collect data. I mean, basically the variables where you are collecting data in the DHSU terminology. We define it as a data element, right? So even in tracker, the granular metadata that we actually collecting the data is called the data elements. But the thing special here is these data elements in the DHSU tracker, we have to define them as tracker. You remember when you are configuring data elements in DHSU, it prompts us to select whether it's aggregate type data element or a tracker type data element. Remember, these have to be defined as tracker type data elements when you are defining the data elements for them to be available to be capturing tracker data. Okay. So here the data element actually we can define it as a data points collected within a program stage. For example, if we have a program stage called laboratory tests, the laboratory test result could be the data element, right? Because that's the one actually which is collecting positive, negative, like all these different possibilities are collected actually at this data element level. So what we are actually doing here is we have to define a data element. And when we are configuring the tracker program, we are assigning this data element to the particular program stage. Okay. So important to remember it has to be the type tracker. So when it comes to data elements, you must be familiar that you can kind of define what type, what is the data type that you are collecting, right? It could be a number type where you can actually even have decimal, right? It could be integers or in that case it could be positive integer, negative, positive zero, positive integer, right? It could be yes, no type and it can even be text. So usually when the data element is generally type of text or categorical data and the data element is of categorical type, right? Because of the requirement of analysis, we tend to configure options and options sets. So again, I think you must be familiar with this from the DHS to foundation and the courses, the fundamentals. So what we mean by options set in DHS to is a predefined related list of values for data elements, right? So actually options is the related, the broader term, the name that we are giving for this group or the set an option are individual values within option set. So for example, if you can have an option set called gender, male and female would be the individual options in that option set, just to recap, okay? So supposing if your data element that you are collecting is a categorical type of a data like say for example, you want to collect data about the gender. So for example, let's take this one laboratory test result, right? So the test result could either be but it could be positive, negative or it could be inconclusive. So these are the three possibilities. So for that case, we might define the data element as the type text, right? And then what we will actually do is we need to have this positive negative inconclusive define, right? So where we are defining it is by creating an option set. So we can actually create an option set called test result and have the individual options, positive, negative inconclusive attached to that option set test result. And once we have this option set called test result, we can connect that to the data element. All this we can do when we are configuring the data element. So this part of course, we are not going into too much detail here. I'm just mentioning them to recap. But if you don't remember, please refer the material related to the DHS to Fundamentals Academy. All right, any questions up to this point? No questions so far. All right. So let us now see how we are connecting all these different, I mean, objects that we have discussed. Okay. So it's a bit of a crowded slide. Don't get too confused. Let's take one by one. So right at the top, right at the top, let's focus on this box that you have at the left top corner. We have something called track entity, track entity attributes and the track entities, right? So here we are discussing about the person that we are registering in our use case. Okay. So we have the person registered in the system number one. And then we will have different programs. I told you, right? In DHS to instance, you can have one program or you can have multiple programs. So the broad objective is something like this. Let me tell you a story. Okay. So in an ideal setting, say like if you are configuring DHS to for your country, ideally attract entity. If you have a track entity called person, the person has to be registered. In the DHS to tracker when he's born. Okay. So after that, that person during his lifetime will be encountering and will be facing, will be having encounters with your health system for various purposes. So the moment the person or the child is born, we might be given the birth vaccine. Right. So that means if we have a program configured to collect immunization data. Ideally, if you have a person or the baby registered in the system, he has to have some some connectivity and he has to be enrolled and followed up in the immunization program. So supposedly you have a separate program for child immunization. Once the child is enrolled at birth, that child will be a part of that immunization program for like till up to like, say, I don't know, like it depends on your country. It could be like even 15 years. Okay. Till the child is 15 years, the child will be enrolled in the childhood immunization program. And in the meantime, let's assume now this child, like say maybe even the child is two or three years old. We might diagnose that we might detect this child is having major nutrition problem. Right. So in that case, you may have a separate program in your DHS to instance to collect data related to nutrition. Okay. So there what we are going to do is till up up until age two, the child was only part of the immunization program, the childhood immunization program. And at two years, we will decide, okay, this child is having a nutrition problem. So we are going to enroll this child into the nutrition program so that we can very closely monitor. Maybe we can actually, like if your general practice is not to measure height and weight monthly, but now that this child is having nutrition problem, we might decide, okay, we are going to measure the height and weight slash length on a monthly basis. Right. And then we might do some interventions. So for that purpose, we will enroll this child who is already enrolled in the immunization program also to the trial nutrition program. By say supposing at age three, we detect that child is child's nutrition problem is now solved. He doesn't really need to be followed up in the nutrition program anymore. So what we will do is we will complete the active enrollment that we created for that child for the nutrition program. But that doesn't mean the child is not required to be, I mean, the child is required to complete his enrollment for the immunization program because that will continue till age 15. So that means at age three, he only again having enrollment to the immunization program. Okay. And okay, let's go even further. At age 18, this child again, I mean no longer child, I mean now a grown up supposing the child is a female, she gets married and she gets pregnant. Okay. At age 18, the child may no longer be actually a part of child immunization program because she has kind of completed all the milestones and everything that we are collecting information for the immunization. But because now she's pregnant, she's encountered by our health system and we might need to be actually need to enroll this lady into the antenatal care program. Right. And then we will be having separate program stages and the different events and the data that we are collecting related to the antenatal care program. Right. So this is how it continues. So the tracker is kind of a life cycle approach. So attract entity could be enrolled in multiple different programs at a given time. That's the first scenario or else the track entity can be enrolled only in a single program at a given time. Okay. It could be the second scenario or thirdly, the track entity could not be having any active enrollments for any of the programs at a given time. You'll understand. Right. Think of my life cycle approach. I mentioned those three possible scenarios can happen. Right. So this is again same for a different track entity, but for the simplicity, I mean, I didn't want to kind of confuse and by taking a complex examples, I took this scenario. Okay. Is there any questions? I hope not. No. All right. So let's go back to the slide. So we have the track entity. Right. And what we are actually doing is whenever we have a requirement, we enroll this track entity or else the track entity instance, if it is the name of the, I mean, if you are thinking of a actual person, we do something called enrollment of the track entity instance into one of the programs. It could be one or more given your requirement. Right. And inside the program, we are collecting different data. Right. A series of data. And this, this, this series of data actually categorized based on program stages. So program stages are generally the actual enrollments. Right. So if, so when a, when a, when a patient or person is in the health system, he comes there for a reason. And the data that we are collecting, we can always categorize and put them under program stages. And inside the program stages, we might, you know, like collect data based on data elements. It could be anything. Right. It could be the numbers. It could be the gender. It could be the test result, anything. Right. So this is what we try to highlight in this particular slide. Is everything clear? Any questions? All right. I'm impressed. Right. Now this is a very interesting slide highlighting everything. Okay. Let's start somewhere from the, where, where should we start? Okay. Let's start with track entity. So here onto your left, we have this generic concepts and tracker terminology onto your right. But you're seeing the probable use cases. Right. Actually, we have taken one use case and different granular configurations that we are going to do in, related to that use case are highlighted onto your right. All right. Let's start. So let's first start with the track entity, the green one. So here, if our example is around, you know, tracking patients related to COVID-19 or our requirement is around COVID-19 surveillance, the first thing we should do is to register a person. Right. So the person is what we are going to register as the track entity. And once we do that, this person is having different attributes. So some of the attributes we have mentioned here. So the person can have track entity attributes such as first name, last name, six, and many more. Right. You can think of whatever the attributes that you want to define and configure it in the DHS2 as track entity attributes. Right. Okay. And let's go further down. We will skip enrollment for now. And then we need to. So once we have defined track entity and track entity attributes, we have to actually define the program. So what's the program here? It's COVID-19 surveillance. Okay. So inside COVID-19 surveillance, now we have to actually like see we need to have a design document first before actually configuring all this because we can't actually because in fact in DHS2, the order in which we are configuring is slightly different. We are not really, you know, like starting by configuring the program because we start from the bottom. But this of course is out of scope for this academy. We are not going into too much of detail, but you need to have a design document identifying all these different metadata items that you are going to configure in your instance. So here the program, the broader program is COVID-19 surveillance. Right. And then inside that program, we have to identify the program stages, the broader categories. So for example, here we have the clinical examination is one broader set of data that we are going to collect and we want to define it as a separate program stage. And we might also define the laboratory request to be again a different program stage. And when they want to issue the result, everything related to the result could be another program stage and the outcome of that patient as a separate stage because you know, like outcome is something that comes separately. So again, when you are defining program stages, you can think of it as an encounter. I mean, like what kind of encounters this patient and the patients like, I mean, different experiences related to the, to this program can have. That's how you are kind of defining the program stages. So again, I mentioned event is a snapshot of a program stage or basically it's a program stage instance. So here, clinical examination for this particular use case, we assume, we define that this is not a repeatable one. That's why we only have one single event for the clinical examination where the medical personnel will see the patient and examine and find out all details related to the examination. And then we have laboratory request. Of course, we can send multiple lab requests for different samples. So this way, it's going to be a repeatable one. That's why we have many events for the lab request. Same with laboratory results. Because again, like when we send multiple requests, you are definitely going to get multiple results. And the outcome for this particular use case, we have defined it as non-repeatable. So we will only have one outcome event. So for all these events where we are actually collecting and storing data are on data elements. So that's why we have to define data elements first and assign them to the program stages. So here, for the clinical examination, for the clinical examination, we can identify different data elements. It could be the temperature. It could be the blood pressure, heart rate. All these could be different data elements that we are collecting for the stage clinical examination. But here for this example, in this slide, what we have done is we have analyzed a bit of what data elements we'll be collecting for the laboratory request program stage. So here, we have identified some of them. One could be the reason for laboratory test and the type of test and the type of specimen. So these are the individual data elements. Because these are actually the variables we are going to collect the data on. So we have defined them as data elements for this particular use case. Now, the lab test reason in this instance, reason could be what kind of data. It probably will be a text data. So here, we have decided it to have a kind of a free text. But the type of test we have decided we should not give the freedom for the people to enter a free text, but rather we will get them only to select one of the few options. So for that, we have defined the option set called type of test. And we are collecting these individual options, PCR, NNAT, and serology. So likewise, we have different options that we have defined here. And then these options have been assigned to type of test. And this type of test we have linked it to the data element type of test. And then finally, what we are doing is we have to connect this tract entity into the program. And that's what we mean by the enrollment. So the enrollment is what actually links a tract entity instance who is already there in the system to the program. Remember what I said? I mentioned a tract entity which is already there in the system to the program. But actually in the real world, what we usually tend to do, the first time a person is encountered with the system, we do two things generally. What we do is we actually register that tract entity instance into the DHS to environment, and we also enroll that person into a program. These two we are doing generally the first time we are encountered with the patient. But subsequently, if the patient is already there or the person is already there in the system, what we do is if we have a new requirement to enroll this person to a different program, we search and create a new enrollment for an existing person to the new program. So that's what we are actually doing. So that's kind of the summary of the program, I mean the data model related to the tracker. Any questions you have? Yeah, Dr. Pamo, I have one question regarding option set. If suppose there is one option set called negative and options are negative and positive that option set can be linked to more than one data element. Option set can be linked to more than one data element, yes, correct. Thank you. That's possible, yes. Any other questions? Yes, Arsalan. Tract entity like person can create okay, yes. Now one concept that we didn't include here is the relationships, right? Because it's a bit complex. So there is one other concept in the DHS to tracker whole relationships. So basically what relationship does is to link a tract entity to a different tract entity or else we can link a tract entity to an event or program stage, right? So likewise we can create links between some of these concepts that we have discussed here. For example, tract entities and events can be linked to each other, right? This becomes useful especially when you want to create a map kind of a visualization, for example for contact mapping visualization, right? This is where map is not a geographic map, right? I mean, map of different entities. Usually what we see when we are doing contact tracing. So for this, relationships is one that we are using and we'll be discussing and showing you that during the academy, in the course of the academy but we didn't actually include it here because we didn't want to actually make it a bit too complex, right? Yes. There is another concept called relationship. That's why I said like some of the kind of complex concepts we are not discussing in this particular presentation. But thank you for asking. I hope it is clear. Yes. When it comes to analysis, we have some limitations analyzing and visualizing the relationships which are of course which will be enhanced more in the upcoming versions of DHS2. Any more questions? Is this all clear? So I mean, again, I would really appreciate, I don't know whether we are how strict we are with the time, Saurabh. So what we can actually do is if any one of you have a use case a very simple use case, don't take a very complex one. We can actually like, you can all contribute and we can have a discussion, small one like maybe 5-10 minutes max. You want to do that or we can actually do a proper quiz which is already there in the model. Any other questions? Or anybody wants to discuss a very simple scenario or a tracker use case that you have? All right. So Rathi, there's a question. Can we actually have more than one value for a data element? I have a use case for diagnosis EMR. Good question. So this is actually not related to the tracker itself. It's actually about the DHS2 platform. So at the moment DHS2 data elements are only collecting and registering a single value based on the data type. So what I mean specifically by this is say for example, if your data element is defined as the data type yes no, you can store either yes or no. Right. But if your data type is configured as integer say 0 positive integer, it can only collect and store a single value from 0 to whatever the number. Right. And if your data element is defined as text then you can actually store a text or string value. And if this text type data element is also having attached option set, which may be having multiple options, you are only allowed to store a single option value from that large option option set. I assume your requirement is around recording multiple options from that single option set. Right. I presume so. Unfortunately, it is not supported but so the work around is you will have to create separate data elements as of this time but again this request and the feature has been highlighted and identified so probably in the roadmap it will be included and it might be a part of DHS too in the future but unfortunately not as of now. Do we have any other questions so great. I hope you understood yes Arsalan is it a good practice to use a single data element in stages is it a good practice to use a single data element in stages so I assume your requirement is you have you have some pressing requirement that you want to identify a particular encounter as a program stage but in that program stage you can only figure out collecting one single variable or one single data right. So again it's again very relative contextual so we'll have to see why you are kind of why you want so badly to have a separate program stage for that but if you have very good reasons to do that it's not a problem in doing that I mean if you have a good reason but generally we tend to have of course more than one data element generally collected in most of the program stages but it could be justified to only even have one data element there is no restriction when it comes to configuration. We have like close to 40 participants but I only heard from few of few so what about the others did you all understand please feel free to ask questions if you don't understand the concepts and data model I can assure that you are not going to have a very good learning experience next week and also like if you don't understand all this advance you can always go back go through the presentation and there is one quiz in the model it's not graded but for you to check your knowledge and probably learn a bit more please do that quiz in the model for the day which is there under the data model so you will be definitely able to understand and clarify some of your doubts but if you get scared in case if you don't understand any of these concepts that we have discussed you can always ask these questions in the Slack and we will do our best to answer them but we still have few more minutes in case if you want to kind of clarify any questions okay I really hope you all understood all the concepts discussed so the final slide is of course about different examples of healthcare we can have like pregnant woman tracking through antenatal care delivery and postnatal care and then child through full set of immunization services patients receiving ART treatment and TB patients diagnosed and receiving TB treatment disease surveillance malaria case investigation and if you are thinking of education student tracking teacher tracking and if you are thinking of logistics management you can track any commodity if you are thinking of agriculture you can track crops right if you are talking about disaster management I see some interesting stakeholders here you can think of so many other things so there are no limits on using VHS to tracker for your use case only thing please analyze the use case and see whether there are any exceptions where you cannot match your use case to the DHS to tracker data model right that's my advice and then thanks to all the efforts around COVID-19 there's very good performance enhancements in DHS to platform the tracker because you didn't ask questions I will probably ask questions that you should have asked about the performance compared to how it was two years back right now we are actually having very good performance in collecting tracker data for example I can mention in the region itself Sri Lanka right now has COVID deminization tracker which has more than 60 million events recorded and more than 20 million track entity instances right almost close to the entire population registered in one single DHS to instance and we also have some large scale instances DHS to implementations in few other countries including Bangladesh in the region so yes there are many examples where we are having very large tracker implementations so the best thing is performance is something that has really enhanced over the last few months and then the analytics is again an area which has really improved and there will be a lot of any other features coming up in the upcoming versions right so I guess this is all what we have yes Cecilia you have your hand raised please go ahead and ask a question you can unmute hi thank you so much for this session I just wanted to find out so for each tracker you are setting up a tracker program I had an experience whereby I was giving a tracker program to set up and I was supposed to replicate from some other instance of DHS too there were no program stages set up so the program was supposed to collect information on patients vaccinated for COVID-19 so everything was set up on using the tracker attribute the name of the patients the address identification age and all that and then if the person was vaccinated yes if you had first dose or second dose so there were no program stages there it got me a little bit confused so I wanted to find out does it work that way without additional program stages or I don't know particular programs that might not really need the program stages so you just have generic information on the attributes and it's fine right very good question so if you go back to what we discussed so far so what we mean by tracker and track identity attribute so track identity is what we are going to track and track entity attributes are generally the properties they tend to be semi permanent related to that particular patient or person right if it is a person who we register so ideally if we collect doses and things like that as attributes that's not a very good setup because these are not semi permanent data probably it was configured by someone who is not too much aware about the tracker data model so that's the kind of I mean DHS too is a kind of a very sharp blade right you can probably use it for a very good reason very well configured tracker program will help you provide you a lot of insights related to decision making and all and a bad configuration can again cause equally damage so ideally in this example you should have gone with programs and program stages because we I mean we need only the I mean attributes to be decide defined as data items which are semi permanent and which are properties parts of that particular track entity you are tracking everything else should have been program stages and under the program stages they have been configured as data elements so I would say like that was not the ideal setup but DHS too is not preventing you that's the kind of beauty of DHS too because it's so generic there might be instances where this is required so for example if you just want to pre-register your entire population without actually having a program then what you will actually do is just to register all the track entities along with their track entity attributes as a startup that's where you will start so for that kind of setup DHS to be DHS too has to be I mean we should be able to do it with DHS too so that's why it is allowed but ideally in most of our implementations what we see is we generally get a use case so we configure the track entity and track entity attributes as and together we do the program as well so ideally for the use case that you mentioned you should have gone with setting up program program stages and the relevant data elements thank you very much I've gained better understanding of that thank you any more questions I think there are no more questions so let me hand over to Saurabh then so Saurabh do we have anything else to one more thing I think we have a feedback session so please provide the daily feedback but I will for this session so Saurabh over to you yeah thanks for so we've reached the end of the webinar for today so we will be starting with the academy course from Monday onwards so in the announcements channel we have given the link to created account on the mobile platform so please do so so that you can access the course material and and all the presentations and the assignments which you need to do so and then you have your agenda also available there so please we will try to put up a calendar invite since there are people who belong to different time zones at present but we will also try to send a reminder email 15 minutes before the course so that you get a notification that the course is about to start and we will also leave a message on Slack as well about as 15 minutes before we start the sessions on Monday in the meanwhile if there is anything else any questions please feel free to put on the Slack channel we will review it and come back to you with answers and if there is any announcement and the recording for today's webinar as soon as it is available on the YouTube channel we will share the link on announcement channel on the Slack workspace so please feel free to access it in future and also who were kind of dropping in between because some reason they can access the recordings for the full webinar so that is all for today any suggestions please feel free to reach out to us to Slack and have a good weekend and we look forward towards starting the Academy course on Monday onwards so thank you everyone for your time and meet again on Monday