 Okay, so in today's session, we're going to mainly focus on this this data model for the majority of the day, and what we're going to kind of describe is actually you know what this data model represents is in particular as it relates to DHS to tracker. And hopefully this term data model is familiar to you, because if you've gone through any of the other academies or even had training by somebody else or gone through some other training in your country. We would have talked about this right in terms of what this is as it relates to DHS to, and you might not know all the components for tracker necessarily, but you are kind of familiar with, you know, the one for aggregate, for example, or for events. So what we want to do is really define these common terms that are used within the tracker data model and link them to kind of, you know, use cases and how we would kind of translate these use cases to these DHS to terms. Because you know DHS to uses a, you know, quite specific terminology, but it is generalizable to kind of broader use cases and things that we work with in the field. All right. We also want to describe that the general flow of information used within this data model, right, and understand how the different components actually link together so these are not kind of disparate components that are segmented or completely separate. So you'll see the kind of, you know, piece by piece for this the sum of a whole part. And we'll see that towards the end. All right. So it is a bit of a terminology heavy session today, but this presentation it is available on noodle for you to review so you can download it you can have it open. And if there are any questions as we're going through things. And once again, my recommendation is to ask them on slack. I'm just so you know that is kept there and we don't lose it after the session. In case we're not able to follow up necessarily or we need to look into something in more detail. All right, so please feel free to ask any questions on slack as we're going through this. And, you know, one of us will get back to you. What we can with a response. All right. When we talk about the tracker data model. What we mean is the kind of the fixed part of DHS to that can't be modified. Right. So you have items that you add to the system, things like metadata that you kind of define, but there's kind of this underlying structure underneath that actually kind of make sure you can add these components to the system. Right. So it includes the required structure and objects that we define and kind of how we can set up metadata and store our data. So these are the concepts themselves, not the individual pieces right. So you know when you deploy a DHS to system and it's completely blank. You have this concept of organization units there. You might not have any organization units in the system, but it's available for you to kind of push those organization units into your system. Same with all the other pieces data elements programs, you know, traffic programs event programs, all these concepts are already there for you to kind of populate over time. All right. So when we look at the various kind of metadata objects that are part of the tracker model, we have these kind of listed here, right. And I'm going to describe each component as it relates to a particular use case and I'll pull that up in a moment to discuss it. Right. So we have these these top three, the tracked entity tracked entity attributes and tracked entity instance. Okay, and I'm going to describe all these three terms, I'm just going to go kind of going over them at the moment. Okay, and this identifies the concept that we are tracking. So in our examples, it'll be patients, you know, we're tracking patients patients that come back to receive clinical care or health services. We can basically track, you know, anything that you need to could be a lab sample it could be a fridge it could be, you know, some kind of other stock item. It could be some other component that you are tracking patients is a kind of common way to kind of describe it just to kind of get you in the mode of thinking, regarding you know how you can track an object and through, okay, so that's the example we'll use here but there are other examples. Okay, then these this other part underneath we have this what we call the program and hopefully you're familiar with the term program from you know working with events for example at least program stage. Okay, that is part of the event model but not really used so much right they're kind of one in the same between program program stage but here there is some differentiation and we will get into that. We have this other component called the event data elements which which hopefully you're all familiar with, and option sets and options okay and we're going to kind of work through each of these components as well. And these kind of components highlighted in this green color, these describe the information we're collecting about the concept we're tracking. Okay, so they're kind of broken up into these two kind of components that we use in order to track our various objects. And we'll get into it now actually a little bit more alright. So, each of these terms kind of has you know something we can use to describe it. So let's start with these kind of three top terms that I identified right. Regarding the concept of you know what it is that we are tracking right. So if we looked at a tracked entity attribute and we'll go through examples of all of these so you get a better sense of what they are. Okay, okay, these are used to register a profile information for what we are tracking. So, as I mentioned the example we're using is patients so if we're tracking a patient, and we want to register them in our system. Right, so we can follow up with their kind of continuum of care. Okay, we would take things like maybe they have a national ID, their name, their sex date of birth address phone number. And then we can actually, demographic details when we're dealing with patients. Right this allows us to uniquely identify that person, and then we can kind of retrieve their record, anytime we need to interact with that individual. Okay. We then have the tracked entity itself. Okay. And this refers to the type of concept that is being tracked. Right. So we identified patient as the tracked entity that we're actually kind of tracking. But as I mentioned, there are other types of things you can track the case lab sample, maybe a village or a community. You know there are other types of examples that you can track through the system for various updates regarding you know whatever services that it's that you're tracking. Okay. And then we have this concept of the tracked entity instance. Okay. And this refers to a single track entity that has been registered in the system. So if I'm tracking a person. Okay, and I register somebody. Okay, let's say myself sure that is registered in the system. Okay, I represent one track entity instance. Okay, because I'm registered in the system as one person. And there are other people in the system and each of those individuals would represent one track entity instance. Okay. You know, we'll go through some examples of this and I'll show you inside DHS to so it's a little bit more clear and it's not just kind of conceptual. Okay. Okay, before we do that. Okay, I just want to go over a couple more terms and then we'll demonstrate this inside DHS to and link it to a kind of use case that we have. All right. So, then we have this this beginning information, right, that kind of defines the information that we're collecting right and program and program stage or these two terms we're going to start with. So a program. Okay, it defines the sequence of events that attract entity can go through. Okay, so me myself let's say I'm the track entity in this instance. Okay. And I'm registered in the program. Okay, so I'm registered to receive some type of care. Okay, so let's say for example I have I've been identified with with having a suspected case of polio or something like that. So then the program itself will then identify well if I have polio what what happens right what would have what's a general procedure that I follow when when someone contracts polio or suspected case of polio. Okay, so it's in the case. So for example if we have a disease surveillance program in that example, right, you know maybe you have steps where you do a clinical examination, where you take a sample, right, maybe a blood sample or something like this to send to the lab, and confirm the diagnosis, you would record the lab results, and there would be a case investigation right especially if it's something that is very rare and doesn't occur. Okay, these are just general steps, general examples. Okay, but each of these steps, you know, is linked to that program, and the program kind of defines that sequence of events that a person can go through, or, or, you know whatever it is that you happen to be tracking. Okay, through through that program that you're creating. Okay. So within that program, you have what we call program stages. Okay, and if you are familiar, you know those of you who work through the events right, we talked about this term in that event fundamentals course, but also you know if you've kind of worked through creating an event program on your own or receive some other training. There is a program stage there but the kind of ratio, why it's kind of a one to one ratio between the program and the program stage you don't really have to think about this in too much detail is just created for you really actually right you don't have to think about it at all. But when you're dealing with tracker programs. If I have these different sequence of events that person needs to follow. Okay, each of these represents, you know, a program stage right. So in this example that I've been pointing to earlier, this disease surveillance program, where they have clinical examination specimen tracking lab results case investigation. So each of those represents a program stage within the program. Right. So, these tracker programs can and often do have multiple program stages. Okay, and the program stages define what data should be collected during a specific type of event within the program. Okay, so for example if I have that lab results stage, it collects information about the lab results events. Okay, and these can be you know you can have more than one. So let's say I have more than one lab sample that I'm processing, you know, I can repeat this lab results. But it's still one stage on its own is just repeated maybe many times right. So each of these items kind of links to show us what we have within the program. All right, so within and then finally within this and then we're going to show examples of this. Okay, we have the event. Okay, so each program stage is made up of one or more events. Okay, so in that lab results example that I used. Okay, if I repeat, you know, several lab lab results. Okay, I'm going to have more than one event. Right. And we can just think about, you know, translating this to kind of as closely as we can to general systems right it's kind of hard because it's not exactly the same. Right, but you know each time I have I run a lab test, I get a lab result. Okay, that is an event. If I have another lab result for another sample. That is another event and maybe I repeat this two or three times. For the same person, if different types of specimens were collected as an example. Okay, but sometimes it's not repeated right sometimes you just have a one to one match. Like, maybe you'd only do the clinical diagnosis once right it's not something that's repeated necessarily all the time. All right, and when it's not repeated you just have this one to one relationship between the program between the program stage and the events. All right. So let's actually, before I kind of get into more of these terms. Let's actually go through an example all right and kind of discuss this a bit more. So in this example, this is the example that we're going to be working off of, and I have the program kind of built in DHS to. Okay, it's an example TV chart, simplified TV program, I'm compared to probably a lot of TV programs that are being run out there this is just the treatment chart right so there's other components of TV program of the TV program and this can often be a bit more complicated use case than this, but this will help us kind of identify the general principles that we want to understand. In the use case that, you know, within use cases that you might experience, or come across in your own implementations. All right. So what we want to do is kind of define what, you know, if I have a tool like this. You know how do I kind of identify how this moves over to DHS to right so I need to identify things like the program, the program stage, the different events that would occur. So in these stages, I need to identify the trapped entity that I would want to track. Okay, you know all those terms that we just discussed. So what I'm going to do is I'm going to open DHS to, and we'll go to tracker capture right so hopefully you guys are familiar with this tracker capture. Okay, and I'll just go to this program. I'm going to register here. Okay, so when I'm starting this off. Okay, a couple things we can already identify based on what I'm kind of entry. Okay, for this one the program, the program name is just called the TV treatment card. Okay, and this lines up with this information here. Okay, this is a treatment chart. It just has some information on the individual person. Okay, that is collected and you can see there's a timeline of events right at zero months, two to three months, five months and a treatment. Okay, so this person is coming back multiple times and receiving treatment at various stages. As a TV kind of hopefully reduces based on the treatment they're receiving. All right. And then we have to identify these individual components that we discussed before. Right. So these are kind of specific to the tracker data model for example, we don't have tracked entity attributes in any of the other data models within DHS to right because we don't register, even in an event program where you really shouldn't but sometimes it occurs you enter some demographic details. It's not really kind of, you know, serving the same purpose as it is here right because here when I enter these details, details like their first name their last name, a unique identifier of some kind. I can use this to kind of search for the person and uniquely identify that record, you know and follow up with their continuum of care, or follow up with whatever it happens to be that you're tracking. Right. In other models, we can't really do that. Okay, not to the same extent at least there are maybe kind of ways to go around it but this is kind of the best way easiest way to do that right where you can kind of just easily search for the person based on a unique set of identifiers. Okay, so some of these components are quite unique to this data model. Right. And I'll see that as I go through this right. So we have the program. We have here are tracked entity attributes right, and this is the demographic information that I've taken from the form, right. And sometimes you'll be given a form sometimes if you don't have a form. Maybe you'll be given a list of requirements or sometimes you'll be responsible for, for that you know depending on you know where you're working from I know there are many assumptions that I'm making here but just for the sake of being on the same page. We're going to assume we've been given this as a tool. Okay, so if I look at this. So some of the information I can identify already that would be useful as identifiers things like their name, their date of birth their sex, their home address their phone number right we can use all of this. And up here I also see the registration number. Okay, we can use all of this to uniquely identify that individual, and we can identify these as the tracked entity attributes that we would use to track that individual. Okay, and I can see that reflected in DHS to when I go to register this person. Alright, so let's say I register an individual. I can register myself. Unfortunately, I have TV. Okay. So once I enter these details. Okay, and then I register this person. Okay, I'm able to use these details to search for them later on. Okay, so I can use the registration number. I can use any combination the name, the sex, the address, the phone number. Right. I can use any combination of these to search for this individual to find them. Okay, and this is not possible as I mentioned in the other models in the HST. So I'll go ahead. You also see here a couple dates. I'm going to talk about the dates in a moment. Okay, but I just want to cover some of the other terminology at the moment. I'll go ahead and register this person. Okay, and then we can see on the left side, some of the other components that we have talked about. Okay, these are actually the four program stages. Okay, that I talked about. So we have the program, which is the TV treatment card. Okay, and then within that program we have program stages. Within those program stages we have what we call events. Okay, and this is in this case, these just occur one time each. Right, they have the initial diagnosis. If I look at the form, okay, they have the initial diagnosis right at zero months, they come in at two to three months they come in at five months and then there's an end of treatment. They are not repeated events, because you know they're not coming in and receiving multiple pieces of information they have different types of lab tests that are collected, depending on the stage they're in. But these are not, you know, they don't have like multiple types of the same sample or something like this, or, you know, multiple types of care that they're receiving during each period. Okay, they're just coming in one time during this timeline that's been defined. If I look at this right so I have these then for distinct program stages. Alright, and these are the ones over here right so these are my program stages here. Okay, for distinct program stages that allow me to kind of walk someone through the sequence of events that aligns to my you know standard procedures for care regarding this person right so this aligns closely to this country's initial chart for treatment which they would fill in as the person is receiving their care, and this allows them to then kind of walk through each of these individual steps, piece by piece as they're able to kind of access these services, based on the timeline that they've defined. Right. Okay, so if I look at one of this stages the initial diagnosis for example we'll cover the program in more detail, to get a better sense of it, but if I look at this first stage, I have this kind of event here. This is where we enter information on the initial diagnosis, okay, and this information that is taken once again, you know, from my form so I have information like the TV patient type, the disease site, the type of treatment they receive, and then the type of these lab results for sputum culture gene expert, and their weight. Okay, so if I look at the form, you know I have these variables here for example in this zero months. And then I have the various lab samples that they would receive, I have the type of treatment they receive at the initial phase so you can see not everything is kind of in the same order as it is in DHS2. That's because they just have one form for the patient and we're kind of responsible for figuring out where this information goes. Okay, oftentimes we would work with a subject matter expert to kind of identify okay you know someone who really understands how the TV program works, where the information actually go. Okay, we're going to work through some registers that are a bit more simplified, and hopefully that allow you to, even without that kind of, you know, maybe background knowledge, quickly identify some of this information. But in practice you would often work with somebody who really understands the program to kind of fit these in the right place the right sequence, make sure the stages contain the right variables for the information that you are collecting. Okay, so if I look at some of this, you know the disease site is collected, the type of patient is collected. I want all of this reflected somewhere in my program, right, and a lot of this information is collected initially so you'll see here, you know many of these variables tied to this initial diagnosis component, where you classify the patient for example, identify the site, the type of treatment they've received, and so on and so forth. So let's say they have TV so. So when we're working through this, we are able to identify so far, we've had an example of the program. Okay, the program stages. A single event, okay which is the information I'm filling in for this individual. Okay, and we will talk about these events that are kind of repeated in a moment. Okay, I'm also able to identify information like the trapped entity attributes. Okay, so this is this information here, all the demographic details, for example, when I'm dealing with a patient that I use to uniquely identify that individual. Okay, so here's a couple examples of those terms that we have just discussed, and kind of you know, taking them, we take them from whatever tools were given whether it's requirements we make ourselves, whether it's a data collection form that we receive, whether it's some other form of guidance maybe maybe there's a little guidance document that you're following. Whatever it is that you're following to kind of identify these these kind of individual pieces of information that you would add to your program. All right. So so please if there are any questions about that, please do ask okay I know that sometimes we're you know we're covering a lot of ground with these terms but yeah please please ask if there's any kind of clarification require. We'll continue and discuss a couple more of these terms and we'll continue to demonstrate them as well. Okay, when I, when I registered that person, there was some dates, so let's talk about those dates. Okay, what I mean is if I go back. I register this person. And we have a date here, for example. Okay. And if I go back to the individual here. Okay, we have dates for each of the events as well. Okay, so in tracker when you're working with information there's there's a lot of dates. Okay. So let's discuss these a little bit more. Okay, so let's first discuss these dates we first see at the beginning. Okay. All right, so that date you actually see that that report date that is displayed here. Okay, this is what we call the enrollment date. Okay. This is the date that the entity in this case it's a person. Okay, and I registered myself, for example, this is the date that they're enrolled in the program. Okay. So for example, it could be the date where a patient visits a clinic and receives their initial diagnosis or assessment. This is completely dependent on, you know, how you define the date itself, right. So I've defined it as a reporting date, but maybe you could define it as the date of their first visit. You know, as another type of date, but as long as it's consistent across the program, you know, and everyone kind of is aware of what that date is represented. Right. We also have this other date and it's not reflected in this program. Okay, but it is can be reflected in other programs such as anti-neal care or disease surveillance, for example. Okay, and it's something called an incident date. Okay. And this is a date which triggers the first event so it's the reason why they came, you know, to the facility or clinic, for example, to receive care. So in the case of COVID-19, it could be the date of onset of their COVID-19 symptoms for, let's say, for anti-neal care. It could be the date of their last menstrual period, for example, right. So that's kind of the date that initiated the sequence of events, right, without that kind of happening. They wouldn't really have any need to come into the facility necessarily. Okay. So that's not reflected in this program I'm showing you, but there are other programs where this is important. Right. And the main reason that this is important is because we can use it to schedule other dates. Right. So if there's guidance that says, you know, 40 days after their last menstrual period, they should receive this type of service. Right. We can use that date to schedule such a service. Okay. So sometimes these dates can be important based on the guidelines that are kind of being implemented in your setting. All right. So in many cases, the enrollment date, the enrollment date will always be there for every program that you interact with the incident date. It's not mandatory, but there are cases where it is quite crucial. Okay. Then this last process. Well, not the last process, but one of the processes tied to registering the person. This is called the enrollment. So I kind of skipped that when I first did it. But basically what it means is after I enter the details. And I actually save this person. Okay, what I'm doing is I'm taking this person that I'm entering the details for and I'm enrolling them in this TV treatment card program. Okay, so if I click on save and continue. Okay, now that this person is registered in the program they're enrolled into this particular program that I've selected right. I could enroll people in multiple programs. Right. So that's the whole thing right when I create a record. If I am kind of uniquely identifying this as a person a unique person. Okay, this person maybe they have TV now. Maybe they also develop HIV later on or they already have HIV. Okay, and then you could enroll them in an HIV program, and they would, you know, you would have one person enrolled in multiple programs. Okay, so this enrollment allows you to kind of take this individual and kind of, you know, provide them with the care they need and register them in the services that are kind of required, right. And you have that one unique record that ties together all this information. Okay, so when we register them into the program, we're kind of performing that enrollment act. Okay. All right. So, we've had a look at some of this so I'm going to go ahead. I've just been kind of going through with some of these as we're doing it. Okay, hopefully some of this is quite familiar to all of you. All right, so when dealing with event programs actually these terms are all the same. Okay, and the way they're used is all the same. Okay. So, when we're dealing with tracker now we actually use the same type of nomenclature for our data elements, our option sets, and our options. Okay, so if we look at this program I'm just going to go through this here and describe it. Okay, so here I am in this program stage in this particular event, and I have my data elements. These are the variables that I use to collect my information. Okay, and I take them from my form. Okay. Right, so type of patient for example is a data element disease site is a data element type of treatment. Okay, these are all data elements that I use to define the variables that I need to collect information for. Okay. Then I have something called an option set and this should also be familiar to many of you. The option set is the list. Okay, it's a predefined list of information. Okay, so if I click on one of these data elements, I will see in many cases in this program in particular that most of the data elements use these these kind of option sets can just think about it as a predefined list that you select one option from. Okay, and if I look at the form, you know, similarly I can identify those so I look at my type of patient variable, I can select one of these possibilities. Okay. Okay, so the these this just represents my predefined list of options that I can select from. Okay, very simple way of kind of thinking about it to just the way we define it right. So the option set is kind of the totality of all these individual items, and the individual options are just you know one of these items. Okay, so if I were to say my option set is type of patient, and that encompasses all of these different options. And then new is one of the options within that option set. Okay, and we can see that reflected here right what we really see is this the option set is grouped together this is the list. Okay, and then the option, for example could be new or relapse or any of these particular options that we see here. Okay. Okay, hopefully everyone's okay so far. I know it's a lot of terms we're going through quickly. I'm really hoping some of it to review. But for those of you, but once again if you do have questions please feel free to ask them okay, and we will try to address those as best we can right. Just keep asking questions if there's any need for clarification of these items. All right, so these were the three items we just discussed and hopefully these this is familiar to many of you right. And when you're creating these in maintenance for those of you who've worked in maintenance right. So we use domain types aggregate and tracker so these are all the tracker domain obviously you're working with a track program. And the way you store that data is just a little bit different all right. So we use the tracker domain for all of this. And then you know, not all your tracker data elements will have option sets and options. It's only for those data elements that have those predefined lists. So for example if I look at my chart, you know for example wait, this would not have an option set right it's just a value, you're capturing their at the time when they receive their treatment. So it's a numeric value you don't really have a preordered or predefined list associated with this variable and that can be true of other variables as well right. So just depends on the variable that you're collecting, whether or not you would be kind of having to define a predefined list to use in your calculations or in your data collection I should say sorry. I'm going to look at those. Okay, so that kind of covers the majority of the, what we call the metadata model. Okay, but there's also like a data model underlying data model, and I'm just going to cover this quickly. And we talked about a little bit of this, but just kind of give you a brief view of what happens when you store data related to tracker in your programs. All right. From our review, we have a bit of an understanding of what attract entity attribute is. Okay, so on this registration page whenever I register, enter in these details. Okay, these are all my tracked entity attribute values here. Okay, and what happens with those values. Okay, they all store information in the system. All right, and there's different information that is tied to each of these values. Okay. So the tracked entity attribute values that I'm entering in the system you register the value itself. Okay, so for example here, if I have a name, like my name. That's the value that gets stored. Okay. You have the tracked entity instance. Okay. I have a person right so in this case, I have a person with all of these details. Right so I'm registering. I create a person attract entity, and within that tracked entity, I have each of the values for these various attributes that are stored. Okay, then I also get information. That's kind of automatic, which date it was created. If you modify it, then there's a data was updated, and you also get who created it right so if you ever want to audit this for any reason, or just kind of see who's entering what data, you are able to kind of access this is not really front facing through the user interface necessarily but there are other ways to access that. Okay, and the track entity attribute values. It actually doesn't have reference to any program, right, because like I said you can take that track entity, and you can register them in multiple or enroll them in multiple programs. Right. That's the kind of nature of creating a unique individual in the system that you can track through multiple sets of services, or, you know, register and enroll them in different types of continuance of care for example. Okay. So all we've dealt with this kind of this front page and the data values that are stored within right. So we have the individual tracked entity attribute values. We have the tracked entity instance, which is you know this all the details about this person that are uniquely stored when I create them. Okay, then we have the actual dates who created it. And also who the user information about who created this person. Okay, so all that happens when I click on save and continue. Okay, or save and add new. So whenever I save it, all that information kind of gets created within the HST. Then when I actually have them join the program. Okay, so when I, you know, in this case enroll them in the TV program for example. Okay. Other information also gets created. Right. So, things like the incident date, the enrollment date and the organization unit. These are all attached to that enrollment. Okay, so I don't have an incident date here, but I have the enrollment date, and I have the organization unit. Okay, so where they were actually enrolled. Okay, so in this case para district hospital is my organization unit. I selected it before I started the registration process, and my report date is January 25. Okay, which is equivalent to the enrollment date in this case just with a different label because you can label the date. All right. So when I just let me enter data group. So I'll save and continue and all of that stuff gets created right first I get the tracked entity instance created. I have all the details the data tracked entity attribute values get created. The date that this was entered, which would be the same date in this case is January 25 here. So this, that would be the date it would use my username as well and say okay. So this person is the one who created this this track entity. Okay, it would store the organization unit. Okay, it would store the date. Okay, so quite a bit happens when I click that button. Okay, it all happens very quickly, as you can see, but once that is done that information is now stored in the DHS to system. And the reason I'm pointing that out is because if you ever need to access any of that information, you know it gives you a better understanding of what gets created and what you can theoretically access or what you can access when you create your reports, etc. When you're creating, you know, for example, if you need indicators that meet some of this information. All right. So now we also have values. Okay, associated with the events themselves. Okay, and all the individual kind of tracked entity data values as a summary, right. So, like, when I look at one of these events. Okay, here I am in this initial diagnosis program stage. Okay, and then here I have all the events. Right. Here I'm just looking at one event, and I get values, right so I maybe this person is a new pulmonary case of TV, and they have some very kind of mild TV so they're just doing community based therapy. And all this value that all these values that are stored are stored against this particular event. Okay, within this program stage. Okay, so you will remember if I go to, you know, something like event reports. Okay, and I do something for a program. And when I'm working with a program you can see here I have to select my program. Okay, and then actually this data within the program stage is the event data that we see. Okay, and then all of the variables within that program stage from those events, you know, that's what I can select from right. So that's where the data gets stored so far to pull out some values from this when I'm doing my analysis that's that's actually where the data is coming from. So that's how it kind of all gets kept in there right and I can pull that out. You know, however I need to and that's why we can see, you know, this data when we make our various reports, etc. Right. So that's where all of this is kind of coming from or tied to right. But when we do our analysis and creator outputs, right, it is being kind of stored that way initially, when we first enter that information here. Okay, and by doing so it allows us to access this information in other parts of the application. Right. And then whenever I enter those those values, right. So the event itself it has similar actually kind of characteristics. Okay. As as we saw before with dates and organization units stored right so in this case. This event is actually in the same location as I registered them. But for example, you might have a referral for some reason right and maybe one of the events occurs in a different hospital, for example, right. So even though they were registered here initially, maybe they receive part of their care and in another facility. All right. And that is tied to the actual event. Right. So, you know, maybe they're one of these phases is somewhere else. Right. And that is stored and tied to this particular data. Okay, and you also have the date. Right. So there's an event date. Okay. So there's once again, a lot of dates here. But you know there's a date in which they receive this initial diagnosis. Okay, maybe the date in which they were maybe the date you reported it for example, is not the same as the date they actually came in and receive their care. Okay, for example right so maybe the date they actually had their initial diagnosis was several days back and you're entering this data retrospectively as an example. Right. So let's get stored for the event but then when we enter the information within the program stage. Right, we get the value. Okay, the event. So which event it actually belongs to me because like I said, you can have more than one event within a program stage. The one we're showing you right now is just kind of one to one ratio, but you can have more than one event if it's repeated if you're doing something more than once that has the same set of variables being collected. You also get the information on the data it was created. You also get information on who's the last person or when the value was last updated, and also who stored it. Okay, so this information here. There's similar information that's created basically between all of this this data that is stored. Right. It's just tied to different components of our metadata model. Right. Some is tied to the event, some is tied to the enrollment, some is tied to the to the actual information variables data elements within our program and program stages. Okay, so this is more for reference purposes, you know this the information on kind of the data, the data value model. You know you're not going to be pulling from this routinely necessarily in the course of this academy, right. You might need to in the future, you know maybe you need to understand, you know, especially things like stored stored by, for example if you want to audit, do some auditing and figure out you know who's entering what type of values with the quality of that information is, you know that can be quite useful. But a lot of this also helps us kind of understand when we're creating our reports, you know what what is the information we can actually pull out right, because we know for example if we look at this right, we can pull out specific events, for example, because each of the values is tied to a specific event. Those events could be in one organization unit or multiple organization units and we're able to tie, pull out that information as well to understand that that might be the case so when we're looking at information, you know we have to kind of think through how to interpret that right. If it's the case that our data was entered in a particular way. It helps us understand, you know, what our output might, what what it might look like in practice when we actually go to review that data, and you know why the data, you know it's not necessarily correct, but if it was entered in a certain way then that's going to be reflected in the way our data is output. Right. Alright, so what we're going to do here is actually, I'm going to skip over this because I want to just talk about this a little bit more. So if we look at the model in its totality. This is really what we're looking at right these are the different concepts that we went over. Right so we have the track entity attributes. Okay, and that helps us define attract entity. Okay, in this case I'm using person or patient. Okay, but like I said, could be multiple types of track entities. Okay, you take that information, and you enroll them into a particular program. Right. Irrespective of the program itself, you know you can create individuals, you know, and you can enroll them in one or more programs right and that's the kind of nature of tracker right when we're creating these unique entities, you don't have to kind of register them again and again. If that's the way you're working right, then you could just register them once and kind of register them or enroll them in multiple programs. Okay. From there we have we enroll that person into a particular program. Okay, and the program contains our sequence of events that we refer to as program stages. Okay, and if we're looking at this TV treatment card example I've just listed the program stages that you would see in data entry that I showed you. Okay, each of those program stages consists of one or more events. Okay, and in our case we didn't have any, any need to have multiple events within one program stage but we could, you know, if needed to. But in this case we didn't have because there's a very kind of strict sequence of events, right that they follow they come in at zero months at two to three months at five months, and then they have the end of treatment. Okay, but there are other protocols which are kind of less strict or where there is more repetition. Okay, within those events we have our data elements. Okay, these are the variables that we collect. Some of these data elements can be things like numerical data elements like weight, or some other type of numerical data elements that might be interesting to collect. Okay. So, for example, in the case of antinatal care. Okay, but, but some of these data elements will have these predefined lists, right, and anytime we have kind of text responses it's, it's better to use these lists obviously because then we can aggregate those right. There won't be any chance they misspell it or something like this right and then we won't be able to add it up correctly. So, some of these data elements will have option sets and then within those options sets you have options. Okay, and that's just kind of everything we went through. In a nutshell, right, tying it all together right from beginning to end. And these are the kind of components that we have to take from our requirements documentation or data collection tools. Okay, whatever it might be in order to kind of map them to these DHS terms which you know are kind of unique in the sense that you know you don't really use them in everyday language right so it's kind of understanding you know where these things are going and how to kind of map them right between our requirements, however we happen to receive them. Okay, and our information that we're going to plot inside of DHS to. All right, so to kind of just quickly demonstrate this. Okay, just created a kind of joint exercise that we can work through together. Okay, and I know the terms are kind of fresh in our mind and new and I went through a lot quickly. Okay, but we just want to kind of try to see you know if you can you can apply this it's not like a graded assignment or anything like that right just something we can do together to kind of test our knowledge quick and see if we're able to identify some of these items that we talked about. Right, so if I go to Moodle. Okay, I'm going to ask you before we go to the Mentimeter to download these two forms. Okay, so if I go to the level one Academy. Academy here and we're on this session now tracker terms and data model. Okay, and then here you'll see these two forms. And then you'll see the presentation that I just went through. And then you have these two here, WHO CDC immediate case reporting form, and WHO CDC lab forms. Okay, and these look like this. Okay, so this is the first one, the case reporting form. And this is the second one, the lab reporting form. Okay, so what we're going to do is try to take these. forms, and try to map some of the terms that we discussed in DHS to to the actual form itself right so this is a it's an older version of the form, but it is a real life, you know, form that is, you know, defined by CDC. Okay, so we can take this and kind of trying to figure out what are the options that's that's okay so let's let's just make sure you have these forms available. And then what I would suggest is if you do have your your phone connected to the internet probably it's easiest connect to the the Mentimeter via your phone. Okay. That way you can see everything on screen as well when I display the questions and things like that might be a bit easier if you have access to two devices if you don't you can use your laptop of course. That's not a problem. So if everyone can go after you've downloaded those two forms, if you can all go to Mentimeter mentee calm, you can use a link in Moodle, or you can just type in mentee calm. Okay, and just type in this code six this code that you see here okay. So just give everyone give everyone a chance to join. And then we'll continue. Okay. So this is a you have 40 seconds to answer each question okay it's not graded by any means. Okay, just to get you thinking about some of these terms. All right. So, not graded there's no ranking, nothing okay but it'll give you a chance to kind of see if you can apply some of these terms to that form to the CDC form okay so I'll pull that form up and make sure to explain as well. And then give you enough time. Hopefully you'll have enough time. Okay to work through this. All right. I see some people still joining and that's okay. But I'm going to go ahead and start okay. So, don't worry about that there's no points, just answer there. Okay, so looking at these two forms. How many programs do you think you should make. One, two, three or four. Right. So we have two forms here, but just review them. Okay. And to start, you know, how many programs should we make to encompass this data. And just think about, you know the sequence of events that would occur when you're looking at this information, right because in tracker we can tie information together. There's not necessarily a right or wrong response actually for this. I do want to highlight that but there is maybe one way we can recommend. Okay. But there are different workflows, depending on the context with tracker in particular. Okay, so a lot of you selected to and and I kind of thought that might happen. Right. And we have to think about when we're working with tracker. Okay, how we actually tie information together. So let's have a look at these two forms. Okay. Here we have information on the immediate information they need. And we also have some information on, you know, clinical history, right, the date of the last vaccination. Some of the information on the number of vaccine doses they have received. Okay. Then if we look at the lab for it's kind of a continuation of this. Right. And a lot of the demographic details that we see here. They're not collected necessarily here. Okay. So here we have then the lab, a lab request. And then we have the lab results. Right. All of this information is actually tied to the person that was registered initially using this information. Okay, so you can make two programs actually it's not wrong. I should, I wish that X wasn't there just only last for one answer, but you can make one program from this information right that encompasses all this data. And then, you know, for my next question, before I get into it. If we were to make it one program. Okay, how many stages do you think there should be. Okay, if we look at the type of data that's being collected between these two forms. Right, so you have two forms with disparate information. But you know that program stage concept, how many, how many should there be within this program. So this is kind of difficult to think about right how we're framing these objects. Right, but let's have a look at the data that we're collecting. Okay. So the first thing we have to think about in our sequence of events is what are our track entity attributes right because this actually doesn't go in a program stage. Right, that's our registration page right in DHS to right things like the, for example, their name, their date of birth their age, right, we're not going to collect those each time. Okay, we collect them once at the initial registration. Then we have information here on their history, right, things like their number of vaccine doses their date of their last vaccination. Okay, the date the form was sent. And for example the person completing the form. Okay, the initial disease, things are really out of order right on this form so it's kind of hard to tell. Right, but that could be kind of our first stage right where we have this individual information that we're collecting about the person's history and their initial kind of diagnosis right based on the initial disease or event that they see. Okay. Then if we look at these, this is kind of more split up right. The current health worker completes this form and sends it a copy to the lab with the specimen. Right, the date the specimen is collected the specimen type. Right, so this is an initial specimen request right and the reason we're splitting these up is because each of these events will have a different date. Right, theoretically, right, I could do the initial diagnosis. I could then send or collect the specimen. Maybe I collect and send it on the same day maybe I don't. Okay. And then process the lab results right lab to complete this section and return to the form to the district and clinician. Right, so these are kind of three distinct phases that a person would follow within this program. Right, have that initial information that you collect on their history. You'd collect a lab sample, you'd send the sample. Okay, and then you would process the result. So these can be three stages that we identify for use in this program. Now this is a bit hard obviously not everyone here might be having that background in, in, for example, disease surveillance. But we, this is why it's important to identify someone to work with when you're dealing with these requirements right so we really understands the program, because they can walk you through the sequence of events, get you to understand the dates in which these events occur. Okay. Next question. Okay, so which form can you obtain the majority of the tract entity attributes from right so these are generally when we're dealing with patients these are generally our demographic characteristics right. So we have the case reporting form and the lab and where are you going to kind of get those attributes from. Yeah, the immediate case reporting right so we kind of talked about this a little bit, and hopefully this is kind of as we go through this hammering home, those concepts right so on the immediate case reporting form that's where we get things like their name, their date of birth their age their sex right through the residents their neighborhood, etc etc right information like this their country, the region the district we often see this on forms, even to this day. Right, but if you remember you know GHSU has a hierarchy and that's kind of recorded automatically so some of this information actually, we wouldn't need to necessarily collect via text, right, you would just be. That would just be a replication of something that's not as distinct as the organization unit, for example, that they select. So sometimes you know there's information on the form would necessarily add, but then you know here you can see a lot of these attributes that we would want to collect about this person. So we just kind of talked about this. Okay, if you look at the variable reporting district in the case reporting form, do we need to create this variable. So that's this variable here. Yeah I know we don't need to create this variable right so if you go to DHS to right now different hierarchies I use district as kind of a representation, maybe you have something like states or provinces or you know something like this in your own setting right, but because the organization is captured, you know, when we went over through that data value model, both for the track entity, as well as the events. Okay, organization unit is captured, right. So if I wanted to get a summary by a top level, right, because I've already selected an organization unit during the data entry process. Right, I don't need to recreate that variable and enter in some information on that right it's captured. I actually go to enter my data by selecting an organization unit from my organization unit hierarchy. Okay. So if I select this hospital for example, and I wanted to get a summary of everything within this district. Okay, and I selected this district when I do the outputs, it would automatically give me that output. All right, you'd automatically say okay this person I've entered in parent district hospital is counted in the district total. And that's the same for the region, the country etc right all that information. Okay, this information here country region district, things like that. Whether it's, you know, using different types of terms maybe it's state instead of province maybe it's something else commune instead of district whatever it is right, but that type of information. So if you are able to kind of capture using the organization unit hierarchy that you defined within DHS to so if you see this type of stuff on forms. Generally speaking, you will be able to get this through your organization unit hierarchy. And that is a lot, you know, it's a lot more flexible in terms of the outputs you can create in any case, rather than creating a list or a free text field for example where they were they would just enter this. And maybe that's what happens on the form. But you know, whether it's, you know if they're entering it by paper. So you can always select the right one when you're doing it, you know, via data entry. Okay, so let's just kind of review the case reporting form right and kind of get a better understanding of what is available. Right so. If I have a look. So this information here. Okay. Okay this information here that we just discussed the country province district site. So this is my organization unit hierarchy essentially right. So I enter information at the site level. Okay, this could be for example, the facility I select. Right. So that's some information that we see here. Okay, then we also have, for example, a lot of our tracked entity attributes so we have the name, date of birth, age, residents neighborhood district. What else do we have here. Things like this. All of these are tracked entity attributes, right, the name, date of birth, age, sex, residents neighborhood district, whether they're urban or rural their address. Okay. All of this is actually the demographic information we could identify these as our tracked entity attributes. We do have some dates, and in this case we have some interesting dates for example we have the date of onset of symptoms. This could potentially be the incident date. Okay, and we haven't seen an example I haven't shown you an example of this yet. Okay, but this is what kind of causes them to come and seek treatment or care. Right. They got sick. What day did they start experiencing symptoms. Okay. And then the rest of the information that we see here, except for the unique identifier. Because the unique identifier would also be a track entity attribute or some kind. Okay, that these are basically our data elements right or lab results or data the last vaccination. Final classification, the person completing form, you could theoretically have this as an attribute but probably not. So, so that's how we can kind of go through and identify these elements right and tie them to the information that we receive. And we would do this basically in each instance for any type of new use case that we're dealing with. Right. So we would kind of go through and try to identify all these elements, all these things that we've been talking about. Okay. So, next question. Alright, so I see just wait for everyone to kind of come back. Okay. Okay, so you look at the lab form now and the variables specimen type. Should this value have an option set. Okay, so I'm going to open it up here. So here's the variable specimen type. And it's got the star. Okay, the star is indicating something. So, that's how you should have an option set attached to it. So most you've got that right so sometimes you'll see this on the form. Right the star is referring to these pre selected options that should be filled in. Right, so the person shouldn't be entering anything outside of these options. So you can just create a list of this and then allow people to select from that essentially. Right, so this is kind of a review, but it's a good idea to think about this. So we have this long data element. This is the number of vaccine doses received in the past, against the disease being reported. Right, if I were to make this data element in DHS to what would be a good name for it. Right, I don't want to give it this name, because this is super long. Right. And it's not going to look good and reports might be hard to find. It'd be hard to filter out and maintenance for any administrator. So we can often shorten these names. This is just an open ended question to get you thinking about it right because when you create the data elements, you know you have to name them right. So, as you go through and create your data elements later on tomorrow when you're working through your programs, you know you're going to have to give them these. So I haven't touched on it now but hopefully this is something you've touched on in the past right. And it is something you will have to think about actively. So some people are coming up with similar answers. Okay, this vaccine doses received, you know that's a pretty good one. Generally we try not to include number of in our names. And the reasoning behind that is you can generally assume, you know, it's a number of some kind, especially if you define it as such, when you're creating your data element. I see this vaccine doses received repeated quite a few times. Right. That's not a bad name for this data element. Right. So, you know, things, especially, you know, these symbols, that makes it quite hard to find and makes it, you know, maybe it's the first or last item in a list. For example, we generally try not to include that any type of symbol. So if it's a percentage or a number, which we try to include that at the beginning of the name, right, maybe at the end of the name. But then if you're looking for that like in the list or maintenance or something like this, it'll appear kind of out of order. So generally when we make these, we're trying to think about, well, what's the user going to see when they access this in analysis? What is an administrator going to see when they look for it in maintenance, right. And if we can somehow marry these two concepts and allow it to basically make it easy to find, make it shorting to the point so people understand what it represents. You know, then we've done our job. But if we kind of make it difficult and long and then you know you create a chart or something and it takes up the whole horizontal space. You know, then it's not really going to be so useful if we want to add in other data elements to analyze at the same time. Right. So just think about this a bit more when you're naming your data elements through your exercises in the next couple days, because that is something you'll have to do. Okay, last question. Okay, so review the lab form. Do I need to collect variables such as name, sex and age again, if this is all one program. Okay, so pull up the lab form. So we can see here it has name, it has sex, it has age in the specimen collection kind of program stage that we've defined, right. So I need to collect those again. I have them here, right. Patient name, I have the sex, I have the age, the name. Okay, so if I collect them once at the point of registration, do I need to collect them again within each of these individual stages. Good. So, so no, we don't write, because once you register that person, this is a unique set of variables that defines who that person is. You know, you don't need to collect those within the individual stages that you create right because when you look up that individual, all the events all the program stages that they're a part of will be tied to that record. All right. Okay. Thank you very much for bearing with me. I know that was a lot of terminology. I'm kind of working on these principles. Okay, as we go through the sessions I wanted to introduce it now. But we will, you know, to in tomorrow's session when we create the program will be working with all the same terms, all through the next, you know remainder of this academy will be working with those terms will be pounding them home and making sure that you can kind of just remember them, and identify and be able to understand how they work a little bit more. All right, so I know it's kind of a terminology heavy session and it's kind of, especially in this environment virtually. It's a bit hard to kind of work, work on this together. But, you know, thank you very much for bearing with me so far. Okay, what we're going to do now is we're going to switch gears a little bit. And I'm going to hand it over to Brian. Okay. And what we've done now is we've really talked about the metadata, right, you talked about, well, here's my form or my data collection tool. Okay, how do I convert it over to DHS to the next consideration, which is, I would even say more important is then, you know, how am I going to use this data, right, and I need to think about this a little bit more potentially before I go in and make my program, right. The last thing we're trying to emphasize over the course of today is, as you can see, it's important not to just go into DHS to and create stuff, right, we have to think through the logic of what it is that we're actually making. All right, so I will.