 In this presentation, we will discuss data elements. In particular, we will discuss some key principles associated with their design. By now, we have an idea that data elements explain what we collect and analyze. While data elements are sometimes referred to as indicators in other contexts, in DHIS, data elements and indicators are not the same. Remember, data elements describe the raw data, whereas indicators are calculated values that typically use two or more data elements in their calculation. All of these data elements can be further disaggregated. This has been demonstrated in the various reporting tools where we added in different disaggregates as data dimensions. We can separate the types of data elements that we collect into different classifications. This includes routine data elements, which are data elements that are collected through our routine reporting mechanisms. We also have semi-permanent data elements. This is data that changes after a relatively stable period of time. For example, we can consider population data semi-permanent, as this typically changes every year. We also have infrastructural data elements. This is data that's related to the infrastructure, such as the number of beds in a facility, the nature of their power supply, etc. Often, this type of data might be collected through a survey. When we are creating data elements in DHIS2, there are some principles we want to follow when we are naming the data elements that we create. We have been discussing this concept of an integrated data warehouse, and we really want to think about this when we are naming our data elements within DHIS2. We want to think about how DHIS2 is set up as an integrated data repository, and make sure that we share our definitions across our programs and departments. Remember that all of this ends up in the same database or repository. When we name data elements, we really want to think about how the data will be analyzed and used, not just how it will be collected. We want to use self-contained names that on its own can describe the meaning of the data. And we want to use short and concise names. There's no need to include any obvious information. As an example, on a particular data collection tool, you can have a data element that's called the number of pregnant women attending ANC first visit. This can be shortened to ANC first visit. Let's take a look at an example of this and see why it's appropriate to shorten these names. Let's have a look at this pivot table in DHIS2. In the left-hand column, we can see that the data element taken directly from the form is placed in the output. We can see that this is quite long and not really appropriate for the output. On the right-hand column, we see ANC fourth visit. This has been shortened to include only the information necessary to understand what that data element is representing. We can see that it is much more appropriate for the output when compared to the data element name that's been given for ANC first visits. We want to make sure to drop this obvious information, so when we output the data element, the output looks appropriate. There are some additional principles we want to follow when we're naming our data elements. We also want to make sure that we start with the most important part of the name. This will make it easier to find in an alphabetical list. For example, if you have different types of deaths that you are classifying, you should start with the term deaths. This will allow you to find all of the deaths grouped together. You also want to consider applying codes to your data element names. This is particularly useful when you are integrating many different types of programs into one system. Note that short names can also be used when creating your data elements. This can allow you to apply simplified formats to the data element names if you're finding that the name of the data element is a little bit long. When we are creating these data elements, we want to make sure that we drop a couple of conventions taken from the data sets. Firstly, we want to drop any specific data set codes. For example, if I'm looking at an HIV form and I have a number of data elements coded as HIV 1.1, HIV 1.2, HIV 1.3, etc. I want to make sure to drop that from the name. When we get into making the data elements, you will see there are provisions to include that code in other fields. But there's no need to include that code in the name. We also want to drop components such as number of and total. Let's take a look in DHIS 2 to see how we've applied some of these principles. Back in DHIS 2 within the pivot table, we can have a look at how we've applied some of these principles to the data elements that exist within the system. For starters, we can see that within the delivery data element group, we can see that desks and deliveries are listed in alphabetical order by their classification. This is because we have used the identifying component of the data element as the first part of the data element name. This allows us to list the various classifications of desks and deliveries by their type alphabetically when we're doing our data analysis. This makes the system a bit more organized and items easier to find. Here we are now in the data element management application, and we will get into a lot more detail as to how we create these data elements within DHIS 2. For now we want to discuss the second concept where we talked about putting program names in the data element. This allows us to sort our data by different programs very easily. For example, if I want to find all the data elements that belong to a family planning program. If I just type in fp, you can see I can retrieve all the data elements that belong to that particular program. We still apply those other principles to the actual data element name, where we put the identifying characteristic of that data element first. But by grouping these data elements together using appropriate acronyms, it makes managing data elements that belong to a particular program a bit easier. Let's take a look at a couple more examples of naming. We're looking at two data elements that belong to HIV. The first example that we will review is the number of patients assessed for adherence during this month. This is an HIV data element. It belongs to the ART program in section 7, which is treatment adherence. Let's take a look at how we can break this data element down. There are a couple of obvious pieces of information we should drop from this data element. The first thing we can do is remove this number of. Next we have the data element code 7.1. This denotes the order in the section it belongs to. There's no need to include this in the data element name in DHIS2. During this month can also be dropped from the data element. We could be actually looking at this data element during any period when we perform our analysis. If we now review the name we will give this data element in DHIS2, it looks a little bit different. We will start with the program name, ART. We then give the name for the data element, patients assessed for treatment adherence. We can also give the data element a short name. If we look at the short name, it's a little bit shorter than the name we've given it in DHIS2. ART treatment adherence. When we do our analysis we can choose to display either the name or the short name when we create our outputs. Let's take a look at another example. 7.5, number of PWIDs referred for TB. This particular data element belongs to the methadone program. It's been given a notation of 7.5 indicating where it belongs in that particular data set. Just like before we can drop the 7.5 and the number of from this data element name in DHIS2. So we start by assigning the program name. We'll use MMT as a short form for methadone. We then give the name PWIDs referred for TB. We can compare this with the short name. In the short name we can drop the program name. We will use the program name to manage our data elements and find data elements that belong to similar programs. But in our output we might not need this. Remember we can choose between the short name and the name for our different outputs in DHIS2. The last principle that we will discuss are data element groups and group sets. Just like organization units we can take our data elements and create groups. We can further take these groups and classify them into group sets. In this example we can take the ANC first and fourth visit and group them into the ANC group. We can take underweight less than 5 and put it in the child nutrition group and burst still and burst live into the delivery group. These three groups can then contribute to the maternal and child health group set. If you remember when we did data analysis you typically selected your data elements by selecting a data element group first. These are quite useful to create and we will go through that process in the next session. This ends the session on data element design principles. If you have questions about anything that we've discussed during this demonstration please let us know. Please try the exercise on data element naming. After that we will move on to the next session which is creating data elements within DHIS2.