 Great. So thanks so much everybody for coming. We're going to be talking about metadata management with attribute option combos and approvals. If you don't know what any of those terms mean yet, we're going to explain a little bit about them as we delve into the presentation. But first, we want to introduce ourselves. So I'm Jim Grace. I'm a DHS II core developer. I've been working in areas such as validation rules, predictors, expression parsing. And one of the areas I've been working in is data approvals based on requirements from PEPFAR and other places. I designed the feature and did all the back-end coding and have stuck with it as it has evolved to where it is now, which we'll tell you some about. And I'm Ben Geraldi. And I'm the technical lead for datum. And datum is the PEPFAR installation of the DHS II. So it's used to record information about the AIDS interventions by the US government across the world. All right. So what are we talking about today? So we're talking about metadata management, how to manage the metadata in your system. So the information about the information in your system. We're going to talk about two DHS II features that are used for metadata management. The first one is attribute option combos. And the second one is approvals. And we'll explain what those each are in the part of the presentation that's about them. Both of these features were designed and developed by Lars and Jim. Jim, who's here. Lars, who's somewhere else. With PEPFAR in mind, around about 2015. The commits in GitHub don't go back that far. So we're not sure whether it was 2015 or 2016 or 2014. But it was around about that. But they were also both designed to be useful in situations that are very different from PEPFAR. They were designed as general tools. And we'll talk a little bit about how PEPFAR uses them and then how they're used in the Sierra Leone demo. But you may be able to imagine ways that they can be used in your instance. All right. So the first one we're going to talk about is dimensions. And this is sort of a roundabout way of getting to attribute option combos. Okay. So what are the basic dimensions of a data value? What it is? Like what is the information that we're recording about? And this is represented in DHIS 2 with a data element and then aggregations of the data element, which are represented by category options. Where is the data value? And this is represented in DHIS 2 generally by the organization unit, somewhere in the organization unit hierarchy. And when is the data value? And that's represented by the period. Right. So these may be sort of generally familiar terms to you. Okay. So disaggregation categories. So we talked a little bit about category options. How do category options work? Or so what are some examples of category options? Oh, and we're going to begin, but we're talking mostly about aggregate data in this presentation. But some of the things that we're going to talk about do apply to event data as well. All right. So the first kind of category that we're going to talk about is the disaggregation category. So some examples of that are age, sex, test result. And these are things that can be specified for a data value. What age is that data value for? What sex is that data value for? Is the test result positive or negative or indeterminate, et cetera? And we're going to show you how this works with two dimensions, one dimension, and zero dimensions in the next couple of slides. You could have more than two dimensions. You could have, I mean, you would have to have a finite number of dimensions, but you could have a very large number of dimensions as long as you have a database that's large enough to handle all the dimensions. And we'll talk about what that means a little bit in a little bit. And as long as you have a system that's sort of performant enough to deal with those dimensions. But we'll talk about two, one, and zero, and hopefully you'll be able to generalize for the two. All right. So here's a disaggregation category with two dimensions. So the two dimensions are age and gender. So this is an example from the Sierra Leone demo. It's ART enrollment stage one. ART enrollment stage one gets disaggregated by the category option comp, the category option that I always want to say option, the category combination HIV, age plus gender. That's the category option. The category combination HIV, age, and gender. And that is made up of the two categories, HIV, age, and gender. Those are each separate categories. Now in each of those categories, there is an option that is selected for this particular data value. So for the data value that we're talking about, you've got the option less than 15 years old and the gender female. So those are the two options that are selected for this data value. Now the category combination has a variety of options as well, if you will, or category option combinations that are combinations of the category options that are selected. So we combine less than 15 years old and female to get the category option combination less than 15 years old female. That whole thing with the comma is one object in the database. And that is the object that the data value is pointing to. That category option combo is, and we're using the ID for that. It's pointed to in the data value table. And we're showing the data value table not because you necessarily need to know about the data value table, but because we think it helps envision and understand how the HIS-2 is dealing with categories. So that's two dimensions. So one dimension is actually pretty similar, and this again is from this here, Leon Daniel. HIV currently on care is attached to the category combination HIV, age, which only has one category, which is named the same thing, HIV, age. But those are two different objects in the system, the HIV age category combination and the HIV age category. And that category combination combines HIV age with nothing. So it's just HIV age, but that combination is restored separately. Then we have an option from the HIV age category. That's less than 15 years old again. And we've got the category option combination less than 15 years, because again, it's not being combined with anything. And that's what gets assigned to the data value table. We happen to be wondering why we're talking about HIV age rather than regular age or just basic age. That's because there can be different age bands in the system. For instance, there could be HIV age and TB age. If those were tracked differently in a Ministry of Health, there could be a general age. There could be an age band that was used prior to 2015 and an age band that was used after 2015. And those would be different categories with different options. Okay. Just looking at my notes. All right. Okay, so what happens if we've got a data element that we don't want to disaggregate at all? An example of this in the Sierra Leone database is facility has access to running water. There's no disaggregations with that. It's either it does or it doesn't. So that attaches to the category combination default. In every DHIS2 system, there's a default category combination. And that is part of the default category. So the default category is combined with nothing to make the default category combination. Well, which option are we taking from the default category? There's only one option, default. So we've got the default category option. And that's combined with nothing to make the default category option combination. And so that ends up in the data value table. Right. And so that's how we do it with zero dimensions. All right. So we've talked a bunch about disaggregation categories, which are categories as applied to data elements. But now we're going to talk about attribute categories, which are attached to data sets. So data elements are sort of atomic data values on a form, right? But a data set can be thought of as an entire form. And those can be disaggregated as well. So just back to where we were talking about, where is the organization unit? When is the period? But I'm going to complicate what we said before. Data elements and disaggregate category options are not just what. They can be who, they can be how, they can be why, and they can even be additional dimensions of where and when. Perhaps a period says what day it happened, but it refers to a calendar year as well. And that can be present as a data element. Similarly, data sets can also represent who, what, where, when, how, and why. And so can attribute category options. All right. So here, so, oh, here are some visual examples of what these look like. So what does this look like in the UI? So here is a disaggregation, disaggregation categories with a data element, right? This is the ART stage one that we're looking at before. And we see that there's male and female. These are the two genders that happen to be present in the Sierra Leone database. And then we can see the age bands, less than 15, 15 through 24, 25 through 49, greater than 49. And we see those age bands reproduced for both male and female. So you can put something in each of these boxes and have this data element fully disaggregated. But what does it look like with the data set in an attribute category? You may have seen this on the data entry screen at the top. You can pick two options, right? And these are attribute category options, the implementing partner, which right now Afea Plus is selected in the project, nothing is selected there yet. Okay, attribute category. So some examples of this project could be a good one that you'd want a whole form of partners is a good one, accounts, etc. And we're going to reverse it a little bit. I think it's clearer to show this way. We're going to show zero dimensions first, then one dimension, then two dimensions. All right. So again, an example from the Sierra Leone database, the child health data element does not have any disaggregation in attribute categories. So similarly to when you didn't have any disaggregation for the disaggregation categories, the default category combination, default category, the default category option combination, and the default category option are all used. And these are the same default category combination, category, category option combination, and category option as was used in the previous slide. So this is the same object in the database. It's going off of the same table. But it applies to a different part of the data value table. So we saw the category option combo ID before. And there's also in every single data value an attribute option combo ID. And that is what is attached here to the category option combination. It's a little confusing, I know, because the category, you would think the category option combination attaches the category option combo ID and it does a different category option combo, but it also attaches to the attribute option combo ID. And that enables DHIS to use the same set of tables to represent two different pieces. All right. So what does it look like with one dimension? So the emergency response data element has one dimension, target versus result, which has two options, target or result. And so the category combination is target versus result. The category is target versus result. It's a different object, one's a category combination, one's a category. So that category is combined with nothing to make the category combination. Which option have we selected? We selected the target option. So that's the category option. And then the category option combination is target combined with nothing. So get target again. And again, that goes to the attribute option combo ID. And then here we see it with two dimensions, partner and project. This is for ART monthly summary. And this is the, we saw this bit in the UI earlier. The partner in the project is the category combination. And then there are two categories, partner and project, that could combined to make the category combination. And then each one of those has an option selected. So UNICEF is the partner and clean water is the project. And those two are combined to make the category option combination UNICEF clean water. And that one object UNICEF clean water is attached to the attribute option combo ID. All right. So when do you use disaggregation categories and when to use attribute categories? Basically when you're using them on a data element or a data set. But here's some other guidelines. You use disaggregation categories, DCs, when you, it's a long thing to write on slide. So I abbreviated it here. So you use DCs when you want different combinations of categories on different data elements within a data set. So we want, in a data set, we want to see data elements with disaggregations. Use disaggregation categories when you want to enter all of the category option combinations on one data entry screen. And so as we saw in the UI earlier, you see the whole cross product of all the possible combinations on one data entry screen. Use ACs basically in the opposite situation. You want to use the same combination of categories for all of the data in the data set. So you want to select it at the very beginning and then use it for all the data. And then when you just want to see one screen for each category option combination that you're selecting. All right. And then just so you know, there are also some constraints that can be applied to category options. You can add a start date to a category option. And these constraints apply to both disaggregation categories and attribute categories. So you can apply a start date. And so then it is not valid before that start date. You can apply an end date. Then it's not valid after that end date. You can create open periods after the end date. This was something that was added recently to Core DHIS2. So it may not be available in older versions, but it certainly is in 2.36. Then you can specify an end date. And then based on the data set, have it stay open after that end date. So not based on the category option. And then you can assign it to organization units, which means that it's available for the organization unit and all of the descendants of that organization unit. All right. So we've got some data. Now we want to analyze it. So let's talk about analyzing dimensions. So and we'll talk mostly about analyzing attribute categories. You could create category option groups and category option group sets. So the PEPFAR use case as an example, one of the reasons that this all got put into DHIS2. So PEPFAR has these things called mechanisms, which is the US government term for a project. It's basically, it's got a number and that number represents a bunch of work that is going to be done. Hang on. I need to get my notes out. Yeah. So it represents work that's going to be done. It represents money that's going to be spent. And it's going to represent results, hopefully, that are achieved. So each mechanism has exactly one partner. And that partner is usually an NGO or sometimes it's an MOH or sometimes it's actually a different part of the US government. And that partner is the group that's going to do the work. And then it has exactly one agency in the US government. And that agency is going to supervise the work. And so the partner also reports to the agency as you see here. So each mechanism has exactly one partner and exactly one agency. A partner might have more than one mechanism though. And an agency almost always has more than one mechanism. And a partner might share a mechanism with more than one agency. So they might have a mechanism with USAID and then they might have a mechanism with Peace Corps or something like that. So we want to limit what the users from the agency can see to only their mechanisms. We want to limit what the users from the partner can see to only their mechanisms, which is a different subset of mechanisms. So it's not exactly hierarchical and it will involve sharing, as you'll see. Okay. So let's start here. How are mechanisms represented in data, which is PEPFAR's installation of DHIS2? The mechanisms are represented by a single, a one-dimension attribute category, right? So the category is mechanism, right? And then in this case, we've got the category option selected, which is mechanism one, two, three, four. And because it's a single dimension that's combined with nothing to give you the category option combination one, two, three, four. And that is peers in the data value table at the attribute option combo ID. You should seem really familiar because we were just talking about a similar case. Then that category option is put in a category option group. So it's a group of category options that belong to this particular partner, which is named FHI 360. And there are several other category options that are in that group. And then that category option group is grouped together with other category option groups to make a category option group set. So that's a group of category option groups. And that is called partner. It's the word partner. And so when you look up that category option group set in the pivot table, you can see all of the different partners that you're allowed to see. All right. So that's how we deal with the partners and put their category options together. But we do the same thing with the agencies. We group the category options together into a category option group, in this case USAID. And then we take those category option groups that represent the agencies and we put them together into a category option group set, which would be agency in this case. All right. So that doesn't get us all the way there. We still need to restrict and allow users to see what they should see. Restrict users from seeing what they shouldn't see and allow users to see what they should see. All right. So this is a different representation of what we were just seeing. So here are these two mechanisms, one, two, three, four, and five, six, seven, eight that belong to FHI 360, the category options. And they're part of the category option group, FHI 360. And that category option group is grouped with the other category option groups that represent partners and put into the category option group set partner. So now we're going to apply some sharing to it. So both the category option group and the category options are shared with a user group, Kenya FHI 360 users, which is assigned to the Kenya organization unit. And also the users are assigned to the Kenya organization unit. And so they're restricted by their organization unit. They can only see data that's within their organization unit or its descendants. And they are also restricted by another thing, the user dimension restriction of mechanism. And that's something that you apply to the user in the user's app or via the API if you're modifying users via the API. And that user dimension restriction of this category of mechanism means that the users can only see the category options that are assigned to them. Agency users are done in a similar way. Here are the category options that represent mechanisms that belong to USAID and the category option group that it means that is USA. And that's again put into an agency category option group set. And those are shared with a different user group, Kenya USAID users. And that user group is assigned to the Kenya organization unit. And these users also have the user dimension restriction of mechanism. And I should say that each user will only appear in one of these user groups. And that indicates what type of user they are in the PEPFAR system. They're either a partner user in which case they appear in a group that looks like that or they're an agency user in which case they appear in a group like that or they're one of the other user types which we'll cover in just a moment. So country users have all of the mechanisms in Kenya, all the category options that appear in Kenya shared with them. They have all the category option groups that are applicable for Kenya shared with them. And they are assigned to the Kenya organization unit. So they have no user dimension restrictions. And so they are only restricted by what is in their organization unit. And so this is another type of user, third type that we're going to cover today. And then the fourth type of user is global users. So the top level organization unit in datum is called global. And there are users assigned to global. And they have all mechanisms, all of them are shared with them. They have all category option groups shared with them. And they're assigned to the global organization unit. So there are no user dimension restrictions. Not that they would have any applicability because everything is shared with them, but there aren't any. And they have no restrictions based on their organization. Whoo, I'm out of breath. So that was a lot. If you have any questions, feel free to put them in the chat and then we'll handle them at the end of Jim's talk. And so Jim is now going to talk about approvals. Thank you, Ben. I'm going to talk about data approvals. And next, there will be two parts of the data approvals that I'll be talking about. First of all, a data approval is based on an organization, a level of data approval is based on an organization unit level. And so in the first part of this talk about data approvals, we'll just talk about how data works with organization units. So you get the basic idea of how approvals work. Then I will talk about how approval, data approval levels can also use the attribute categories that Ben just introduced us to. So this is where things get kind of interesting and not intuitive. But first, let's just review data approval with regards to organization units next. So data approval always follows a hierarchy. The idea is you have one or more levels. You only need to have one level of data approval. But if you have multiple levels, then you approve data starting first at the lowest level, and you approve it at higher levels as you go up. So in this example, C and D or units might be facilities. And once the C and D have approved their data, then B, which might be at a district level, I can approve its data, can approve its data, including all the organization units underneath it. Organization unit A in this scenario is not yet ready to approve because not all of its children organization units have approved. So the hierarchy always flows from the lower levels to the higher levels. Next. So a data approval level is based on an organization unit level, even when we get fancier and add attribute options as you'll see later. Okay. Yet an organization unit level may or may not have a corresponding data approval level. So you could have just a single organization unit level or as we're about to see, you could skip organization unit levels next. So for example, yeah, you could have five organization unit levels in your system. And maybe you only want to approve data at the sub district level, and then approve it at the province level. So it's up to you when you design the metadata for data approvals as to which org unit levels, if any, you want to approve data at. Next. The number of steps in approving data can be configured by a system settings. There are two different options here. And this is another thing that's important to decide before you deploy data approvals, which option you want. Next, the first option is where you just have your approved data at one level. And then once it's approved for all the children of the next level up, it can be approved at the next level. Now, why would we want anything different from this? Well, one of the challenges, if you have a system like this, let's say you have a district with five facilities in it. Let's say that facility one approves its data. So it's ready for review at the district level. Oh, first I should say, one of the design principles we used in data approval is if you do something by accident, as much as possible, you should be able to do it. So let's say that facility one had their data approved, and then they realized, oh, I hit the wrong button. I hit approve or something, or perhaps they just got in some late coming data or a correction, and the people at the district office haven't looked at it yet. So you can actually un-approves, you can undo the approval, fix the data, and then hit approve again. So that's great at the facility level. But what about if the district, let's say facility one submits their data, approves it, facility two does. So meanwhile, at the district level, they look over the the data for facility one, it looks good. They look over the data for facility two, it looks good. But maybe at the time they're looking over the data for facility four, facility one goes back and oops, they made a mistake, they approve the data, they fix it, they re-approve it. So in order to be more sophisticated for that kind of scenario, we offer another option next, which has two steps at each approval level. So the facility can approve the data, and then when the person at the district starts reviewing it, they can accept that approval. The accept means that the approval is locked, and the lower level can't just undo it anymore. Now at the higher level, they are guaranteed that the data will stay the same as they review the data from various facilities or various lower level units. And when the higher level feels like all the data is good, then they can say approve, and the next level up can't accept. So this process goes up. So it's important when you're configuring data approvals, understand these two different scenarios and pick the one that's the right balance for you between the amount of work and how your workflow goes. Next. Speaking of workflows, a data approval workflow is something that we designed for reasons I will say in a moment. It specifies a period type and one or more data approval levels. Next. And you can spec, you can join data sets to data approval workflows. If you're using data approvals, you don't need to use them for every data set. That's your choice. You can have every data set assigned to some workflow or not. So next. For example, you might have oops, you might have a one workflow that you here we go. You might have one workflow that you call HIV. And it approves the data in multiple data sets like HIV care and HIV pediatric pediatric. Another word I can't say monthly summary. You might have other workflows that are assigned for other data sets. And when we first implemented data approvals, we didn't have workflows. You just approved a data set. The reason we developed workflows is that PEPFAR found that they had many, many different data sets that they all wanted to approve pretty much at the same time. And then it just became an administrative hassle to go through well, let's approve this data set and that data set and the next data set. So we created an abstraction in a subsequent release of DHIS2. They have a data approval workflow where you could just approve for one workflow and it would cover a bunch of data sets. In fact, the old data approvals app, some of you may remember that, is organized around data set. You select the data set for approving. We are now in the process of designing a new data approvals app that should be available in 2.37 that will let you select the workflow. It will better match the model that we have underneath. Okay, next. So here's a question. Next. If you have a data approval workflow, you're going to be approving data for some period, some aggregate period, a month, or a quarter, a week, a year, whatever. And you're going to be approving data in one or more data sets. So here's a question. Does the period type for the data approval workflow have to be the same as the period type for the data set that actually contains the data? So think for a moment before Ben shows you the answer and think, what would your answer to this question be? And this was a design question that we were facing and had to figure out, did we want to constrict it? What would we want to do? Okay, so Ben, you can show the answer. The answer is no. The data set may have a period type that's smaller or the same or larger than the workflow period type. And the next slide will show how that works. Next. So for example, if you have a approval workflow that has a quarterly period type and you approve things for the last quarter, that looks like it should be Q4 on that slide. We'll have to fix that. Of 2018 shows you in these slides, the slide deck was first written, or at least this slide. That quarterly workflow approval can approve data in monthly data sets. In this case, it will approve all three months in the quarter. It can approve data in a quarterly data set for that quarter. It can even approve data in a yearly data set. And how does that work? Next. What we did was we decided that if a data set ends during the approved period, that approval will approve it. So if you want, your fourth quarter approval process can also cover all of the annual data. Now you don't have to do it this way, but it's flexible you can if you want. Next. Next. One of the things that's been suggested is that we extend approval and there's even a ticket, I believe it's even marked to do in JIRA, that we extend approvals to handle event data as well. Currently, data approvals only apply to aggregate data, the standard in data sets. Next. But it can be extended in future by allowing a program to be a member of a workflow, as well as allowing a data set to be a member of a workflow. And this is one of the things that we envisioned when we designed workflows and moved away from improving data sets that have provided an additional level of abstraction, so workflow in future could apply not only to data sets, but to programs. Next. So we talk about data approvals as if we have some shared understanding of what it does. Someone says, oh, I approve, I like that data. It looks good. I think it's correct. But what does it actually do in the system? Well, data approvals actually do two things in the system. Next. First, it locks data that you've entered from being new data from being entered or existing data from being changed. You can go ahead and build next. It allows it for a given organization unit. Next. And all the organization units under it, an approval at a district level will lock the data for all of the organization units under that. Next. Next. For a given period. Next. For all data elements belonging to any of the data sets in that approval workflow. Next. And for attribute categories, which we will talk about very soon. You'll see how that factors into data approvals. Next. The second thing that data approvals do in the system is option. You can figure it with a system setting. Next. It can hide unapproved data from higher level users. And the reason for this is that in the case of PEPFAR and maybe some other cases as well, what we were trying to model is a country collects all of its data. And it used to be that a country would physically say physically. A country would upload their collected data in a some form, in a zip file, to the central system. And until the country decides that their data is good and they like it and they approve it. They have it on their own system. The central system doesn't have it. And when they decide it's good, they upload it. So we wanted to do, we wanted to model that because sometimes a lower level system does not want the higher ups to see their data until they believe it's correct. So there is an optional system setting. Again, another thing to consider when you're configuring data approvals that can hide the data entered from higher level users. And then, of course, there's also a special way of privileging a user by giving them a certain authority where if you have users who are auditing or they're consulting with the lower level users, you can let them have a special privilege to get around this restriction. But mostly it restricts higher level users from seeing lower level data. Next. So the data hiding. This is a kind of arcane thing but good to know. If you have users assigned at different levels, let's say users A, B, C, and D are assigned at four org unit hierarchy levels. But let's say you don't approve data at the province level. Where would user B fall in? You might assign them the privilege to approve data. Where would they approve it? The answer is they would approve it at the next level down where there is an approval level. So user B could operate to approve district level data. In fact, user B could approve district level data for any of the districts in the province. And like user C, they could see the data from lower levels. Sorry about the use of the word C in two different contexts there. But they can view the data at different levels because they are authorized to approve it. So this is again something that you might want to consider as you're designing the data approvals for your system. Next. So I've been talking now about how data approvals work in an organization unit hierarchy. Now we'll add the fun stuff. We'll show how data approvals work in an organization unit hierarchy and using attribute categories. Next. Next. Data for each attribute category when you use them are approved independently. So you can have, you can approve data for each project or for each partner or in the case of PEPFAR for each partner and then for each agency that's overseeing the partner. Next. Approval levels, data approval levels can be defined in one of the following ways. Next. You can have, as we've seen before, you can just have one approval level for each organization unit level. Next. You can have, these refer to examples. Next build. These we're about to see in the following slides. You can have two approval levels in the same organization unit level. And I will show you how that works just very shortly or three. You can have more than two. In fact, you can have any number depending on how complex your requirements are of approval levels in an organization unit level. I'm, I do a lousy job at looking at the chat at the same time I speak. So if there's something I should be aware of, someone please read the chat. Yeah, I'm reading it, Jim. Like, there may be some questions that we'll take at the end if we have time. Otherwise, and we might be able to run over, I don't know. And then otherwise we'll take them to the community of practice. Good. So next slide. If you have just one approval level for an organization unit level, you just define the levels. And so for example, you might have approval level one, you might call country, and that's at the organization unit level country. You're in perhaps you have some other levels in your hierarchy at which you don't approve data. Maybe you go all the way down to organization unit level four, before you have your second approval level at the district level. And then your approval level three might be for facility at the Oregon level five. Now you see this extra column called category option group set. What the heck does that have to do with approval levels, you might be thinking. So we'll get to that in a moment. But if you only have one approval level at each organization unit level, and you're not approving by individual category options, then you just leave that leave that blank. Don't fill it in. Next slide. If you have if you want to have two approval levels at the same or unit level, you can do that by assigning a category option group set to one of your approval levels. So in the Kepler example, they want to be able to have a project partner approve data on a project basis or on a mechanism basis. And for example, you could do that at district at the district org unit level. And then at the same org unit level, you could have someone responsible for approving all the partners within that district. And so those users would be operating at approval level two, whereas the partners who were only assigned to a certain number of attribute options, the way Ben described earlier in the session, would be approving data at approval level three. Now we did this because we wanted to have something that was flexible for PEPFAR. And with all the hundreds, thousands, I guess, of users in the system, we didn't want to have them have to configure a separate standard workflow engine off the shelf and re-enter all the users and all the groups. So this workflow, this model of approvals follows all the sharing setup that Ben just showed, where you can have partners that are shared with some attribute options, and you can have above them agencies that are shared with some attribute options. We go to the next slide, okay. Yes, go to the next slide. So what PEPFAR wanted, and we had to model, was three approval levels at the country level. They wanted the country partner user to look through the data and make sure that the user, the data for that partner was okay. They wanted a country agency user such as CDC or USAID, in PEPFAR's case, to look through the data from all the partners that they supervised within that country. And then they wanted a country team, a country interagency user, to approve the data that came from all of the agency approvals that came from all of the partner approvals, all this at the single org unit level of country. Next slide. So this is modeled in DHAS2 by setting up two different category option group sets for different approval levels. If you remember back from Ben's slide, there was no hierarchy in how the sharing was set up between partners and agencies. It's just that an agency happened to see more mechanisms than a partner, but there was no hierarchy in that configuration of the metadata. Here is where the only hierarchy exists within PEPFAR between partners and agencies is in the approval levels. A partner has first crack at approving the partner is configured to be at approval level four because the category option group set is part of approval level four. So this means that a partner, I'm sorry if this is all a little bit confusing. This is how we got it to work for PEPFAR without the need for reconfiguring thousands of users and groups. So an implementing partner will have first crack at the data. They'll implement it for all the mechanisms, for all the category options they're responsible for, then funding up or at the code already, then up at the next level agency can approve what had been done by the implementing partner. So that was a little bit rushed and it is a little bit complicated and the code to implement this is a little bit complicated as well inside the backend. And I'm guessing that you might have some questions. So who would like to ask a question? So I could read a couple of the questions that are in the chat. So is it too cumbersome, Stephen asked, is it too cumbersome in practice to take and click the complete button as a kind of approval at that level? Do you understand that question? Yes. So what we were asked for is to have approvals be a different process from completion. And if you have data completion that goes into certain reporting. But the idea is that we wanted perhaps a different set of people to look at the data quality and not just vouch that it was complete, but that it looks good. And so again, from the user requirements, we developed this as a separate facility. But if there are ways in which data approvals should relate more to data completion, please let us know your use case. Ideally, say something about that in the community of practice because we're always open to how we can make the system work better. And it's all driven from user use cases. All right. So the next question. Antonio and I were talking a little bit about how user groups are managed. And he was asking whether it was possible for user administrators to be restricted in the users that they managed. And I mentioned that we do that through a parallel set of user administrator groups. So I was talking about all the different user groups. If you're a user administrator at these different levels, then you're in the user administrators group. And the user group has the managed by property set to the user administrators. And actually, what Jim said before, there are actually two hierarchies where agencies are above partners in PEPFAR. One is approvals and the other is in the sort of managed of user groups. And that's pretty outside of the scope of this presentation. But I'd be happy to talk about other portions of that in the community of practice. There are a lot of user groups. It's basically the answer to that question. Okay. So Stefan asked, I think this one's for you, Jim. I think I noticed that approvals only make data read-only. Facilities that didn't report can still report. Is that correct in your knowledge? And if so, is there a way to prevent that? It should block new data entry as well as existing data. The thing about approvals is they don't apply to every data value. They only apply to a group of dimensions. So they apply to an org unit for a particular approved period of time for a particular set of data elements that belong to the data sets that you approved. And if you use attribute options, they apply only to those attribute options. So we don't store an approval for each data value in the system. We just store one approval for those, oh, and for the workflow that's approved. We just store one database record for those set of dimensions and we don't allow new data entry or data changing in those dimensions. So theoretically, if a new facility were created, and if it was underneath a different organization unit that had an approval level, then it would not be able to enter data. But if it wasn't, it would not have been approved and would be. Is that how that works? Correct. If a new org unit is under something that's been approved, then it's approved as well. Yeah. But if it's not, then it could be open, even if all the other org units that are sort of at the same level that are. So anyway, we could talk about more of that in the community to practice too. So Maria writes, an important functionality that is missing for us from the approval app is being able to see a list of what has been approved, what is pending approval. We are on an older version of DHIS2. So I don't know if this has already been implemented in newer versions or if there are any plans to implement this in the near future. You've looked at the specs of the new data approval app. Can you talk to whether that's covered in those? The new, I'm sorry, I was just noticing someone had their hand up and I missed part of the question, but the new data approval will allow you to select the workflow and this might not be there in the first release, but the plan is ultimately you can drill down the organization unit tree and you can see where the organization units below have been approved or not. And again, this might not be there for 2.37 that's currently under discussion. That particular feature might wait for a later release as we reconfigure some of our front-end software that we use to display organization units and such. I'm sorry, did that address the question? I think so, yeah. And Stefan mentioned that his organization has an app, but it's not publicly available that does that. And PEPFAR does too, but our app is a very tailored to our own approval process and I don't think it would work on another DHIS-2 system. So if you were interested in attempting to configure it to your system, we could talk about that and see if we can release the source code to you. I'm all looking at CA Hussain. Hussain has his hand raised and I'd like to put that question. Yeah. Yes. Thank you very, very much. The approval process works with organization unit levels. That means it's assuming that every organization hierarchy in a country or an DHIS instance has the same organization level structure. But for instance, if you come to Ethiopia, we have about 10 regions. Most of them have different hierarchy levels. For instance, if you come to Addis Ababa, it has only four levels. We go to Oromia in Aparah, if they have six levels, some regions have five levels. So using the approval process, the approval workflow here is not working. It cannot work. How do you think we can achieve this approval process? Do you suggest any workflow? Or are there any methods that are planned like Orgid Groups or something else? What do you propose for this? Because we really like the approval process, but we cannot make it work here. Thank you. That is a very good question. The traditional advice for creating your organization unit structure from DHIS too is that if at all possible, keep all the like org units at the same level. Keep all your facilities at one level and so on. And in some installations, that just doesn't work for various reasons. In PEPFAR, it is not that way because PEPFAR is in multiple countries and each has their own administrative hierarchy. But that is a good question and it is a real challenge because as you were saying, approval levels follow the organization unit level. That is something that we might be able to look at. It would be it would be great if in the community of practice you could document exactly what your challenge is there. And I am not promising anything, but we will look at it and we will see if we can think of a way to do that as you say with Orgid Groups or maybe some other way. Thank you. Great question. Well, I took a look at the community of practice and there aren't any questions there yet, but feel free to ask questions after the session. Any last questions that folks want to put in the chat or raise your hand to ask? All right. Well, thanks so much for having us. This presentation we are going to put on GitHub at that link right there and it will be on SCED as well. And then I know that there will be a video recording of this that will be posted to the DHS2 YouTube channel. So, yeah, thank you so much for coming. And oh, we forgot to mention something. So hopefully you're still here. If you didn't learn anything in the session and you listened to the whole thing, then the next time that Jim or I sees you in person, we'll buy you a drink. So, let us know if you want to take us up on that. I can see Steven Napaua has a hand up. Do you want to take one last question? Absolutely. Are you able to do that? I don't know how to do that. Okay, great. Yeah. Thank you very much for this wonderful opportunity. My question is, I'm Steven calling from Ghana specifically and I'm a health worker. I'm a physician assistant. And currently I'm managing a health center in Ghana here. My question is, how different is this one, the teams that you are getting the training from, the one we are using in Ghana here? We have the system whereby we enter our data, then the district director of health service approve the data before it goes to the regional, then before it goes to national. And looking at the approval levels, I have an issue because the facility that the data is coming from, the in charge or the head of that facility cannot approve the data before it goes to the district level before it goes to the regional or go to the national. So my question is, looking at the way the approval level has been presented here, I would have been very much happy if our own here to something like that can be implemented so that lower facilities can own the data and then they can approve it before the data is also approved by the district director or maybe the regional. Thank you. Sure, good question. So that is a decision that would be made for the entire installation. Either you have an approval, you add a new approval level at the facility level, and then all facilities would need to approve their data. Or you just have the first approval level as it sounds your system is currently configured at the district level. At the moment, there's no way to do it. Only some facilities, but not others. However, you can also have users, higher level users, maybe at the district levels, who are authorized to approve at a lower level. So for example, if at the district level, you have three facilities or five facilities, and you know that facilities A and B want to approve their own data and they want you to wait until they've approved it. And maybe you know that at facilities C, D, and E, they don't have anyone to approve the data. You can assign an authority to the district level so that they could on behalf of facilities C, D, and E, they could approve their data up to the district level. So there are options for making it work, but it would need to be configured at the national instance in order for it to work. And Phillip writes in the chat, I think referring to this, that it's a critical process that should be done very carefully where every stakeholder will not have a functionality problem. And related to the previous presentation where Bob and Austin were talking about upgrading things, when you make changes like this, you want to do a backup beforehand so that if you realize that it doesn't work, you can abandon it. So yes, that another piece that may be useful is with the PEPFAR instance, there's a period of time where the approval levels are set by the different folks at the different levels, as we've been talking about. But then at the end of a period, all the approval levels get pulled up to accept it by global. So everything gets auto approved. So things don't languish in those sort of low levels of approval. So that is something that your ops staff would have to do or something like that, or you would need an app that could do that or something. But that is a potential approach that is admittedly a little janky. Well, I think there's a poster session going on right now. So we're happy to, I don't know, Martin. I mean, if you want to kick us out, you can. Otherwise, we could take some more questions or we call here.