 There are some additional features for each of these data element values. If I double click on this first value, it will bring up a screen with some additional options. We can see the data element history here showing the various values for this data element over the last 12 month period. We can see the current value that we've entered on the right side of this chart. This allows us to do a quick check of the consistency of this data. Let's just change this data value and double click on it again. When we check the data element history, we can see that there is a large difference between the current value for July 2016 when compared to all of the values that have been entered over the last 12 months. This might indicate that there is some kind of problem with this data value's consistency when compared to the other data values. We can add a comment and save that comment and follow up on this later. We can enter in the information for the comment and then click on save comment. You can see just like data values, this also changes from yellow to green, indicating that the value is now saved. We also have fields where we can define minimum and maximum values for this particular data element value. This will be discussed a bit more in the information use academy. We also have an audit trail. The audit trail allows you to view any changes that have occurred to a particular data element. We can see here that a number of modifications are logged. This includes various updates and deletes to this particular data value. We can see the values that have been entered and deleted corresponding to the modifications that are logged in this particular audit trail. We also see the name of the user and the timing of this particular change. This allows us to track all of the changes for every single data element within the system. Now if you remember when we are creating data elements, we select a value type. This specifies what kind of data we can enter when we are doing our data entry. Here we are in the data element maintenance. We select different number types and assign them to our data elements. This indicates what type of values we can enter into the system. For example, if I select positive or zero integer, I cannot enter a negative data value. Back in the data entry application, let's give this a try. You can see if I try to enter a negative data value, it gives me a prompt that says the value must be zero or a positive integer. If I click on OK, it will remove the data value that I have entered. I also cannot enter any characters. DHIS2 is using the value type that we have defined to restrict the data values that can be entered for that particular data element. In the initial overview, we also mentioned the use of validation rules that can be used to check data as it is entered into DHIS2. This type of validation uses mathematical rules to ensure the data that you are entering meets specific criteria that is defined by the user. Let's have a look at an example of this now. A validation rule typically consists of a left side, a right side, and a mathematical operator. If we consider one example where the left side should be less than or equal to the right side, we can run a mathematical test to ensure that this data is correct. Let's have a look at malaria suspected cases and compare them with the number of cases that are treated for malaria. In this case, the number of cases that are treated should be less than or equal to the number of suspect cases. We shouldn't be treating more cases than we suspect with having malaria. We can run validation rules to check if the data is entered correctly. Let's just do a quick calculation to check our individual data values. If we look at the number of suspected malaria cases, the total is 114 plus 132. This gives us a value of 246. We can also look at the number of treated cases. We have 118 confirmed cases treated and 132 unconfirmed cases treated. 132 plus 118 gives us a value of 250. When we run the validation rules, it should give us a warning indicating that the number of treated cases should be less than or equal to the number of suspected cases of malaria. In order to run the validation rules, I can either scroll up to the top and run validation or I can scroll down to the bottom and perform the same function. Let's go ahead and click on run validation. We can see that when I run validation, there are actually two validation violations. The first is the one that we discussed. It indicates that malaria treated should be equal or less than suspected malaria. Violations denote data entry errors or that some patients have not received treatment. Please follow up with the facility. We can give descriptions to these validation violations so the user can see them when they're performing their data entry. Here we see that the left side should be less than or equal to the right side, but in this case it's actually greater than the right side. There are more treated cases than there are suspected cases. We also have another validation rule violation. It indicates that the number of malaria RDT confirmed cases should be less than or equal to the number of RDTs performed.