 Um, so this looks like a properly nerdy crowd. So that's really good. Um, what we're going to do is we are going to do a much deeper dive into the improvements to, um, indicator expressions. Um, really, to be honest with you guys, we've been making a lot of improvements with this. And I think that basically no one is using it. I get, we get, we get virtually no feedback, nor do we get any bugs reported. And that's usually the first feedback that we get is if there are bug reports, then someone's actually using it. And then we're like, Oh, great. What are you actually doing with it? You know, and then you kind of get into it. But, you know, DHS two, um, has been, I would just let's be honest with each other all friends here, woefully inadequate when it comes to indicator calculations for a long time. Um, and we're still not there. We have a long way to go. Um, but I think that we're starting to tick off some of the major boxes. You know, I come from a public health background and coming in and working and moving to the University of Oslo and working, you know, a lot of folks here were not public health people. They're, they're kind of techies, right? You know, they're like informatic software folks. And appreciating the types of indicators that are critically important for public health or clinical surveillance or these kind of things was, you know, not always, not always in their kind of purview and what they were thinking. So, so, so, but that started to change. You know, we have more public health folks, we have clinical, we have clinical advisors, we have people who are medical doctors who worked with us full time. We have a new, we have great collaborations with WHO and CDC and all these partners. And so they're feeding us requirements. And I think that's the point I want to make now is feed us requirements, right? We can continue to innovate and evolve with this. This is actually an area where we can move more rapidly. Like if you want me to significantly change data visualizer application, that's going to take some time. It's not impossible, but it takes some time. Indicator expressions is something that we have been able to move much, much more quickly with, mainly because of Jim. And, and so what we're going to do is we're going to go over the progress that we have made, we're actually going to go back to 236 and just go through essentially everything. And, and then we're going to, so make sure that you kind of get the whole breadth and view of the improvements that have been made. Try to layer in some practical examples for you to keep it contextual. And then we want to hear from you and then we want to hear what feedback you have to us what you want. If you think that some of this is garbage, please tell us. And now that being said, today is a little bit of an overview presentation. There's always there's time for Q&A. But tomorrow afternoon after we have an experts lounge where Jim and I will be sitting there and you can just come up and talk to us and we can go into something more detail we could talk something more specific about your implementation or use case. Any kinds of more detailed questions you have. We'll have time for that tomorrow afternoon after after the session. So what I'm going to do now is just give a little bit of kind of a contextual overview of why we're doing what we're doing. And then I'm going to hand it off to Jim to get into some of the details. And then, unfortunately, I have to go out to a tracker session. So I'm going to have to leave and just hand it over to Jim, but he's you're in you're in very, very good hands, the best hands better than mine, because he actually made the stuff. So let's have this working. Yeah. Are we moving? We're not moving. Green light means go. No, doesn't help. You're right. It worked 10 minutes ago. If technology worked all the time, most of us wouldn't have jobs, right? So is it working now? No, it's not even working. Oh, that's not even working there. It's completely dead to us. This is like the mouse is even working. The click works. Oh, it didn't have the focus. Now it has the focus that will probably work too. Okay. Okay, so let's let's talk about one really big change. So in DHS 2.37, we introduced a new functionality called period offset. Has anyone used period offset? That's surprisingly more you've tried. Did it work? No, we should fix that. Things don't always work. Oh, okay. We have not worked and it worked. So that's 50% work. That's good. Okay, so period. It's been fixed. There were some bugs that have been fixed. So please try it again and let me know. Yeah. So Pete, you'll check that now, huh? All right. So let's talk about period offset. Why did we make period offset? The main use case for period offset that we've that we've been chasing for a long time is the ability to calculate coverage indicators. Who all knows about the annualized feature of indicators? A couple, a couple more hands. Okay, so essentially, in previous versions of DHS 2, we had a, we had a button, right? The button said if you're making an indicator, it said annualized. What did that button do? Essentially, if you're making an indicator this coverage, right? So you have something like BCG doses given, and then that's over a target or a population. The BCG dose is given is coming, that data is coming in monthly, usually in many countries. It could be coming in more frequently than that even. The denominator here, which is live births or annual target, this is typically annual data. So this is just one data point once per year, right? And if you click that annualized button, all it did was it times the numerator by 12. So any month that you looked, it just put, you know, that month's value times 12 over the denominator, live births or annual target, right? I mean, but what we're representing there with that number is an annualized value. Not just a multiplication, not, it shouldn't, you know, not just a times 12. Like what is communicating to the user is this represents a average over 12 months, essentially, or a running value over 12 months. But we didn't actually do that. We just times the numerator by 12. Right? So, not great. I mean, that was, that was the workaround several years ago. What essentially what we're doing is we're assuming that all the months are from are the similar values, right? Every month you expect the same number of BCG doses given. And then that would be the assumption to make that value slightly more accurate. But that's not a safe assumption. Many countries have lots of seasonality. You know, you even see seasonality in birth rates, seasonality in vaccination campaigns, you know, there's a lot of seasonality. So if you're just assuming that every month has the same values, or if, in fact, all the months do have the same values, then maybe this is appropriate way. But virtually that's very, very rare, or at least not common enough to just times the numerator by 12 is the default option. Right? So what do we do? So period offset essentially allows you to add up all of, you know, as many previous periods as you want. So you can say I want this month and I want the previous 11 months in my numerator. Same data element, just different moving back across through time. And put that again over the live births or annualized targets. So that doesn't change the numerator stays changes to factor in all the previous months. Numerate or denominator stays the same, essentially in this example. So what this does is it actually uses the real values that were reported, not just times in the numerator time for this month times 12. You know, it doesn't really make a difference. Well, in our test databases. It makes a slight difference. To be honest, I mean, our test databases are heavily normalized, though we don't have the crazy kind of fluctuations that you see in actual country implementations. But, but I'm really curious if someone could just put this into their, their clone or their test instances of the country database and see what the actual differences between period offset coverage indicator versus an annualized coverage indicator. I want to say annualized, I mean, you take the annualized button. Right. Does this make sense. Any questions, is it confusing. Yeah, of course you guys. In this example, that's correct. But I mean, of course, like if you have a financial year that's a separate kind of period than like this, like monthly. So there you know and I think a lot of people have kind of figured out practical workarounds to the annualized problem. But this kind of just, we try to get to the core. Yeah, john, did you have a question. Oh yeah. Yeah. That's a really good question. So the, the, the official DHS to answer is the people that the databases that you have access to could give you permission to do this. You can give someone permission and DHS to just to be able to edit one indicator and not do anything else. But that's a complexity of system administrator administration that very few implementation seemingly get to. So it's not like you have to share everything in the metadata app and you're like you can burn down the whole house, right, potentially, you could, you know, your the system admins that you're working with could give you the permission to just change this one thing. But that requires them to do probably 15 more clicks than what they usually want to do. Yeah, exactly. So another thing you can always do is, is play with these on the, on the demo, you know, on the demo system you have all privileges and it's not the real world data right then you need to talk to somebody in your instance to get the indicator to run on on your instance, but you could at least play with the functionality and learn more about it. I got to repeat the questions for you. So there was a question over here. Yes. Could this be easily integrated into pivot tables repeating the question for the. That's a very, very good question. Coming in the future of DHS to and we're scoping out the requirements now, we will have a expression builder in some of the data visualizer applicant in the data visualization applications, because we know that is john was pointing out that you don't have as much permission in DHS to as they need. And so they want to do what we call on the fly indicators. So I just have my pivot table I want to add a row or column, and I want to do just like you do in Excel push enter and then plug in my own expression. So that's something that we're exploring. Of course, it's very complex functionality and a bit of a rabbit hole. So we've got to we've got to nail down those specific user stories where that should be enabled. You know, we also have to build a graphical expression builder that and that is better than Excel, and Excel has 10,000 developers and they can't do it well so we've got to figure out some way to do it. Patrick, you have a question. And this how to do coverage for this year you're asking like for year year to date so far within the year. That's that's something we're actually working on also for the next version 2.39 year today. Because like the exact I think the maybe the reason you're coming to this is like, because everybody, maybe you're used to slicking the data visualizer and building a cumulative bar chart. Or something like that, where that's essentially year to date. That's make a cumulative bar chart and then you say last 12 months and then you see that that essentially is a new indicator expression that we're working on. Okay, so that was one example. I'm going to jump to another example now. The other one that we've been doing and this is really small I'm sorry you can't really see this but but Jim is going to go over it in more detail. And I think that has, we've made a lot of progress on is the ability to put in relatively complex logic statements in the indicator expression so like things like if statements is no is not know that kind of stuff right so for the average user this is probably going to be a little bit different because they don't know if statements and you know these kind of things, even for a lot of system administrators but for hopefully some, you know, epidemiologist program leaders, maybe some more, you know, technical people, they would be able to put this kind of stuff in one of the really seemingly important metrics for immunization campaigns. And please if you want to work on a lot of immunization campaigns tell me I'm wrong. At least WHO has made it seem very clear to us that they need to be able to look at ratios, they need to have a metric, a kind of a composite indicator if you will, that is a ratio between other variables, essentially other indicators. And the performance of those various indicators results in the assignment of a, you know, good score bad score kind of simple thing. You know, like, you're doing bad, this barrier is doing good, like a scorecard the kind of what you see there bad bad green good. So what we've been working on is this example here, which is the ratio between the relationship between DPT one to three dropout and DPT coverage. So these are two different indicators DP dropout and coverage. And what we have are these assigned for categories. So we have category one two three and four. You see that in category one, for example, coverage is greater than or equal to 90% dropout is less than or equal to 10%. And, you know, you can see the others. Essentially, we want one indicator that assigns a value one to four to each org unit based upon this these criteria. Okay, so what we we can achieve this with nested if statements, so we can just go if, if this then one, if not, then this, if not, then this, if not, then this, and it just. So, you know, a sign of one, a sign of two, a sign of three, a sign of four. And, you know, you get something like this where you have ones twos threes and fours. And then you can make a legend for it and then you can put it on your dashboard pivot table make a simple scorecard. But this is just an example of you can do. I mean, from a from a computer programming perspective, very simple things, but from like a DHS to implement implementation perspective relatively complex things. So like these nested if statements. And the coverage and this, you know, the coverage indicators and this indicators were kind of the two things that started to drive a lot of expansions. So this is just two examples of two different functionalities. But as Jim is going to start to go through there's a lot more here. But I just kind of wanted to give you a little bit of background context of these are kind of the things that we're looking at. So if you have weird indicators. I say weird but like indicators that you're not currently able to calculate. Please tell us about them. And we want to work with you to try to figure out how we can do it. We may not be able to. You know, like what you're saying. Oh, come on Pete, you may not be able to. You know this requires a lot of typing. You know it requires someone to actually go in and know what the how to do an expression and I'm so sorry so small but Jim's going to make it bigger for us. You know, there's not. We have some simple commands and controls down here, but it's really not that much right you kind of just have to know that this works, or you just have to be willing to experiment with it. Once you do put it in then we have this translator down here that kind of tells you hey is actually we recognize that. Yeah. The if statement has actually been there since 34, and I will go over that along with all the other expressions on each slide it will shape which version that particular function has been in since so hopefully you'll get that question answered for this and everything else. So 34 is quite old so you have no excuse. That's why we're trying to tell the world about it because no one is. It's in the release notes but you know people don't read. Yeah. Anyways, so so I just want to give you two practical examples these are again like these are coming to us these requirements coming to us from WHO and others. And just to again reiterate, if you have things like this please tell us again we can move more quickly. And we don't we want to minimize the necessity to do things. You know, in special scripts and that kind of stuff and I know a lot of folks here probably make their business doing special scripts but I mean, you don't necessarily have to tell the client you can just put it here and then. I'm kidding that's a joke. Don't. That doesn't sound good. Okay. I'm going to hand it over to Jim and, but we'll both be sitting there tomorrow afternoon. So if you have additional questions, you can come up and see us then. And unfortunately I've got to go tell people how to not keep tracker from breaking. Thank you Scott. I'm sorry that Scott is leaving I again I'm often down in the weeds and I'll talk about the expression syntax for, for lots of these things. And I may or may not be able to answer questions about application but if if you get lost in the technical thing and you want to ask well, can you do this. Can you do that please ask, and if I can answer it I will. So when we say expressions what does that mean expressions are formulas that you can use in any of these objects in DHS to indicators, validation rules predictors program indicators and program rules and I'll focus in this talk mostly on the first three. They, the, the expressions for program indicators and program rules often have a kind of different syntax. So let's start with the if statement. It's been there since 2.34. But a lot of people don't know it and that's why we're starting with it it's obviously a very powerful tool. One example is you can test to see if some numbers positive you can return one if it's positive or else zero and then you can then you can count these over organization units. So this is the expression that Scott just showed us for putting things in in four categories. It's saying if in an indicator expression with the end keyword you can actually invoke another indicator inside the indicator. So this first indicator already computes something complicated it may compare different data elements, whatever so you're saying if this is there and that is there then the answer is one. And simply by nesting these if statements you end up with a lot of parentheses at the end you have to close them all. It's a little bit awkward but it works. And it lets you calculate something fairly complex any questions about that. Yeah, not all of these have made it unfortunately into the into the front end expression builder again you got to you got to read the manual or attend this talk and learn that. The question was about the indicators it's not there in the in the visual expression builder in the user interface so it's it's kind of a hidden feature of expressions. But again, sorry about that, maybe someday we'll get the front end to keep up, keep pace with the back end but meanwhile, you know make sure you're scour the release notes in the and the documentation each time. The period offset function. This was in the. Oh yes, another question. The question is what's possible and with textual analytics. And in the last couple of releases we've done some work on in validation rules and predictors and being able to compare textual data values, not yet and predict and indicators because it's it's really assuming that everything is is numeric that you're but you could have a validation rule now since 2.36 or a predictor that compares a data element value with a quoted text string and that should work. And we don't have, we don't have, we could go nuts with the syntax right we could make substring or if the left or if the right. But we don't want to just go nuts because we could we want to know what the use cases are so if you have more use cases. Please talk talk with with us about that on the community site or put in a, a, a JIRA ticket saying this is my use case. It's very important also please when you make a request for a new feature. Say what the use cases say why you need it that helps us prioritize things internally we say oh, this is this is a compelling use case we better prioritize that feature. Don't just say, we want the expression to do this when this when this happens tell us why build build your case. That's very important and very helpful for us. Period offset this is in the first example that Scott gave a very simple thing as you can say you can compare the current value with last months or last weeks whatever period you've chosen for for the data. You can use period offset if you're doing stock levels last months starting value, plus whatever you restocked minus whatever you lost minus whatever you used and compute this month's starting stock level. And you can also do it again in the example that Scott showed, you can get a rolling annual account by taking this month's value, plus last month's value, and so on up to up to 11 months in the past. And that's the actual formula that that showed the slide that Scott showed. This is a period offset is just in indicators. So if you look at the slide and thank you I should I should highlight that up on each slide I'll say what, what kind of expression it can be used in, and since when so the period offset has been there since two 35 predictors has a different way of getting past period data. And to do that also it's, it's in a sense more constricted but, but in some ways also more flexible, and we can we can talk about that a bit later or if it's not covered please come ask me. Aggregation type. This is for indicators and just released in two to 38 Elmarie is smiling she's been asking for this function for years. And finally got it in up until now if you have an indicator, if you're sorry if you have a data element and you're using it in an indicator. Then the data element aggregation type is some, but that's all you get, you can't say, tell me count the values or tell me average the values all you get a sum. So the aggregation type allows you to say, I want to count of the values or I want the average of the values. And that's all there is about that. Yes, for program indicators. The question is you can be able you could you have been able to count. Ask the count it by using a d2 function for quite some time in program indicators but not some other things like first, first or last. And indicators and program rules. I have all these d2 functions. And if you have a use case again please tell us the use case. You're right that currently can't be done with program indicators. Yeah. Oh, that's right. So, the question is you can have a place in the user interface to specify an aggregation type but it doesn't work. There is a custom aggregation. I'm a little bit out of my league because I'm not as, as familiar, but you can specify a data element, a program data element with custom aggregation which means you'll, you'll put the formula into the actual program indicator formula. And when we initially rolled out program indicators with the new expression technology that didn't work that's since been fixed and patched. So you might come, please come talk to me after we can figure out what version you're using and whether there's an answer there. Pete. All right, well, ping me get send me send me a message with that Jira ticket and I'll see if I can help get attention on it. The comment was that it still may not be working the custom aggregation types for program indicators. This is new in 2.38 for indicators. And this is something that Scott covered in the in the opening session. If you have rules that change over the years. I know that that PEPFAR has a case where the way they collected data in one year. They had certain data from a data element that was vital to be counted. And in another year that same data repeated some other data and so it shouldn't be counted when you're when you're doing the sum across years. And Scott tells me that in some facilities in some installations, they actually have different indicators depending on the year. If you want the 2018 data you have to run the 2018 indicator. It's a little changed in 2019. It's a little different. So this allows you to say, take this formula, take this data up until the end of 2018 and take this data from the start of 2019 or take this data for 2021 only. You can have a minimum date and a maximum date you can combine them to have both, or you can just say a minimum or just a maximum if you want. Any questions about that? Yes. Yes. Yes. That's right. The way the observation was this works already. If you have data that you're collecting from one year and a data element, and you're collecting another year in a different data element, and you add them both. Well, you'll only find that data in this year. You only find the other data in the next year and it will work seamlessly. It will work perfectly. What this is useful for is if you collect data in both years in the same data element, but you change the rules. So you should count it from that data element in this year, but from the same data element in the next year you should not count it. And this lets you do that. Good. Good question. Jason. Yes, you can say one, but not the other. This example shows both, but they're independent. You can chain them together or you can just use one. Except that the if statement doesn't really give you access to the date of the data. It could be if there were some placeholder for the date, which there isn't yet. The date is not a variable that you can use in expressions yet, but you can specify the date in these functions. Yes. Yes. The question is if you have two different data elements that are collecting the same kind of data and you want to compare them. The answer is if you have, you want the denominator to be showing maybe expected pregnancies or actual pregnancies. And I think I'm going to agree with the answer that came up from here. Those are two different indicators. You want to switch from one to the other. Yeah. Any suggestions, how do you switch from one to the other? Okay, thank you. Sub-expression. Made it in at the last second and we decided rather than roll it out in 2.38 we'd wait until 2.38.1. Sub-expression starts to get at some of the limitations of indicators where you've had to use predictors in the past and I will talk later in the talk about indicators and predictors and when you might use one when you might use the other. Sub-expression basically lets you, lets you make an expression that will happen down in the database before the data gets aggregated. Usually if you use an if statement in an indicator expression, if you say if this value is greater than one or greater than 100 or whatever you want to do. It goes and fetches the data from the database and aggregates it over all the organization units in your district or country or whatever. And then in the indicator expression, you're just looking at that value already aggregated. Sub-expression lets you look at each raw data value. So for each organization unit down in that you're reporting on. So you can do a test. For example, if the number of malaria cases is greater than 100, put one for that organization unit, that facility else zero. And then when you look at this in an indicator, you can sum the ones and zeros and actually get the count of the number of organization units. That's more than 100 malaria cases whatever is in the test. Yes. Very good question. I'll repeat it for the zoom audience can rather than having one data item, can you have multiple data items so you can get a ratio and say is it more than 30% or something like that. We know that that is a big use case. And right now the only way to do that is to use predictors and I'll talk about that a little bit later. This is very limited. And that's a perfect question for the rest of the setup for the rest of the slide. The limitation of sub expression at least at the moment is that you can only have one data element. Now you can repeat that data element multiple times in the sub expression so you can say if it's greater than or equal to 51 and that same data element is less than 100. This can be a data element or it can be a what we call a data element operand the data element dot category option combo, but it has to repeat exactly the same to use it with a category option combo. Once in the expression it must be used also in the same expression the same way. So we realize that this is a very limited number of cases that we could accommodate by introducing sub expression in 2.38. And actually I had the idea for doing this in the first place and I went to Scott said it's just even worth doing because I know that people want to do it for multiple data elements. And Scott said, yes, there's enough case there's enough use cases out there that this provides some use and it's worth doing for 2.38. So we'll be on there the difficulty the technical difficulty in the database is that each data element is on a different row of the SQL database. And so when you're doing analytics it's hard to say, you know, take one row, compare it to a different row, because we, we, one of the goals is we want to keep indicators very perform it. We don't want to slow them way down by doing, you know, sub queries and extra table joins and stuff. So it's something we know it's a it's a pressing need. You can, you can do it using predictors for now. Yes, other questions. Sure. Yeah, the question is building on the use case that Scott showed on the first slide, where you have different facilities in category 123 or four, then an obvious thing you want to do is for for a district or region a country you want to see how many facilities were in category one, how many in category two, three and four. Yes, and the answer at the moment is you must use predictors for that. But we understand that that would be a great thing if we could make that just work in indicators and we keep, we keep wrapping our heads against that and trying to figure out and maybe we will. A new function that was introduced, we're going to move a little way a little away from indicators for the moment. And this is a function that was introduced in 2.37 for predictors and validation rules. We had some people coming to us and say, we want to, we want to we need predictors we want to to make a prediction, but we want them only for one country. We're an NGO that's working in several different countries. And we just want to, we just want to run the predictors for Senegal, or we want to, to run them also for Sierra Leone but with, with different parameters. So this is a simple org unit dot ancestor test, and you can give one or more UIDs of organizations and you can test to see what part of the organization unit tree is the predictor or the validation rule is being run for and you can adjust the formula based on that. Any questions similarly for organization unit groups. If you have it set up so that you want the validation rule or the predictor to behave differently if it's a public facility versus a private facility or whatever other kind of organization unit groups you have. Again, you can put in the UID of the organic group and this could be both this and the previous one you can you can have more than one UID and here you ID one comma you ID to and so on. True. True. Good point. Would this be useful for for indicators. Please tell us why. Please tell us why in a Jira ticket. I would love doing all kinds of, of, of wonderful things because I'm an engineer and I geek out on this stuff and I'd like to put in a zillion strength comparison functions and but Lars and others have cautioned me that we try to do what the users need not what the engineers think it would be would be fun. Right, there are plenty there in general we've been playing catch up with the with the indicators and predictors and validation rules that there are some. It's kind of been a parallel development there have been some d2 functions that you can use in in program rules and program indicators, some of them are more sophisticated. In some cases some of these new functions maybe, maybe more sophisticated than those so yes it's. Then in 2.38 a couple of other tests that we thought would be useful. Again for predictors and validation rules you can see if the organization unit has been assigned to a data set, or if it has been assigned to a program. And you can change the way an expression calculation works based on that information as well. It's like a series of four functions the, the org unit ancestor or unit group or unit data set and org unit program. This should be organic program ignore what it's when it says data set. I finished this slide deck yesterday sorry about that. Yes. Yes, this, this can be any any logic you want yeah. The question is about in the data visualizer and I think what I'm hearing is is maybe similar to what Elmer he said about the last slide. Would it be useful to have this in indicator formulas as well. Yeah it's not it's only predictors and validation rules, but great ideas I mean this was requested for for predictors in particular, but I'm hearing that this and the previous functions. And many others would be useful for for indicators as well. Please please write your tickets. They're using number of actual reports versus what actual reports for a specific data set. Sure, sure. So, again, you could do it now with predictors if you use predictor to to make other data values. But but please please write us your time I only get to implement what's in a Jira ticket so please please write me a Jira ticket. Yes question here. That's that's one reason why I'm staying in Oslo for four days after this. So we can one of the things we want to talk about. So interestingly enough predictors started when we were doing disease surveillance. And that's why the name predict and predictor. The idea is if you have a certain number of malaria cases in the past. What do you predict should be the average or what should be a cutoff above which you might want to investigate a possible outbreak and the standard formula we were given at the time as well. So, you want something that's the mean plus twice the standard deviation or the mean plus 1.5 times the standard deviation whatever whatever multiplier, you could put that in a, in a function, and look at all the malaria cases for the last 12 months because it's seasonally varying you want you don't you want to go back a year and two years and three years at the same time, and take all that data from the last three years and predict them for the current and as I was as I was writing the predictor engine. I noticed that for for past period data you always had to have an aggregation function you always wanted to say, this is the malaria account. So you always have to have an aggregation function around the past period data say what do you want to do with it. And I was just writing this and I thought well what if they don't put an aggregation function. I could either say it's invalid, or I could just plug in the current period value and so that's what I did just just to make it useful. And it turns out lots of people have been now using predictors just to take the current period value and and count the organization units count the ratio of these two data elements for an organization unit and use that predictor and so on. So the predictors operate from in aggregate data they opposite operate from the data value table and they they have much more flexibility and doing things at the granular level. We do want to to bring indicators and predictors closer together in the future and and I have some ideas about that that I need to further season with my colleagues at university. But that's the point well taken what's what's the future of predictors versus indicators and when do you have to use one versus the other. And we would like to get that a lot more integrated. Jason. Yeah, I won't try to repeat everything Jason said for the zoom users but the comment was dealing with the, the functionality between indicators and validation rules and and they, they. Why do we have two different things why can't we use validation rule out outcomes in in analytics, we have five minutes, let me. One point I would make out before we move off that is that indicators work from data that's already gone through the analytics engine and validation rules can be used to validate form data in real time new new data values that haven't gone through analytics yet. New in 3.8 and I'm going to try to pick up the pace. We have a null keyword which returns no value so it's great if you're if you have an indicator expression you want an empty cell to appear on a table instead of a zero, or instead of some other value can say, if this is return null. And similarly we have a remove zeros function which is basically equivalent to if the thing you're computing is zero then put in a null instead. But you then you just have to say if this is a complex expression you just have to say a watch instead of having to say it twice. Other functions that have been there since 2.34. Again, read the documentation there is some useful stuff in there, and then program indicators and program rules they got a lot of stuff. So in 2.38 a stage offset function was added just to note if you have a repeating stage, you can say give me the last value give me the second to last value whatever. That's a new expression that's been put in predictors. So predictors take data, either aggregate data or event data, and they transform it and they always write out aggregate data. So that's the result. But it's a general purpose tool. If you can do something with an indicator do if you can't, you can sometimes create predicted values, and then you can use those in analytics in turn. Past period data indicators can now do some of this with period offset predictors can just still do other things that that that indicators can't count the number of organization units where some logical expression. So indicators can do some of this with some expression they still can't do other things where you have multiple data elements that you're you're comparing. If you want to predict. Oh, an arrow is missing if you want to predict from aggregate input data you can run predictors there's an arrow supposed to be here that will generate aggregate predicted data. You still have to run this through analytics. If you want to use it in in analytics outputs. I have two minutes left on the clock we'll see what we can do. If you want to again sorry the some of the arrows dropped out of the slide. If you want to have both events and aggregate data. If you want to build analytics tables because the predictors take their input from events data from the event analytics tables, and then they can combine that with the raw aggregate input data that if you want to see it in analytics of course you have to build the analytics data. That's it. Any questions on this come come find me at a coffee break or anytime will be in an expert's lounge I think tomorrow with Scott said, Scott and I will. And if I've, if I've talked to two technical level and you're wondering something higher up don't worry ask me the higher up thing I might be able to answer that too and report problems and request features on Jira. Thank you.