 Hey everyone, we'll get started here in just a minute, just giving people a little bit of time to sign in. All right, I think we'll go ahead and get started. We have a lot we wanna cover in this session. I'm Mike Frost, I'm the product manager for Tracker here at the University of Oslo. Welcome to the final plenaries for the annual conference this year. It's been a really great week. We're happy that you could join us. It's been a good opportunity for us to hear from many of you and to learn more about the good work that you're doing. We're always excited to get to this part in the week because we get to show off a little bit of what we plan for and what we think is coming in the future for DHS2. So in this session, we're gonna talk just a little bit about how we communicate these issues and some efforts that we're taking towards transparency. We do wanna clue you in a bit more on how the roadmap process occurs and how we come about identifying priorities. And then we'll hear from a lot of the team leads and product managers behind the various aspects of DHS2 about what they plan to have coming out in kind of the medium term future. So again, this is not specifically about the next release. We wanna give you a bigger glance into the things that we're working on for coming up over the next year or so. And hope that you'll be as excited about it as we are. So first thing to say is that we, with such a large global community, we've undertaken a lot of new efforts to try to be more communicative and transparent. Hopefully you're all now members of the community of practice. Hopefully you're getting the DHS2 newsletter. We of course are putting many, many videos on the DHS2 YouTube channel, including the recordings from this conference, but also many of the other training sessions and academies that are held. But I wanted to point out specifically that we launched a new dhs2.org in January. This was a complete revamp of the website to try to make it easier to navigate and also to give us the opportunity to include a lot more information. So some of these you've seen mentioned maybe in your sessions throughout the week, but I think they're important enough to highlight here. We have a new security landing page that really you ought to take a look at, describing our security processes and also giving you information about how to report vulnerabilities. This is part of our revamped processes around security, disclosure and notification. Some of you will have seen, we put out one of these notices earlier this week and we hope and endeavor to make this as transparent as possible going forward in the future. We also have a new landing page for integration and interoperability. We have been handling for years, constant emails asking us about which software we integrate with and where it has been integrated. So we're trying to put that information at your fingertips right here on the website and also describe to you a bit of the philosophy behind what we do with the platform in order to make it as interoperable as possible. But this session, we're going to focus more on the roadmap and we have a new landing page for the roadmap. And again, that's partially about describing to you the process so that everybody understands where priorities come from for us, but we also have started to post advanced release priorities. So if you go to the bottom link there, you'll see that we have put up what we think is coming for the 237 release in the fall. And we'll continue to try to do this. We want everyone to know what it is that we're working on and what they can plan for coming out in the future. It also gives you the chance if you see some functionality on there that you're particularly interested in or have a need for, you can try to be in touch and share with us your requirements and get a sense of whether the functionality that we're working on is going to work for you. So to talk you through a bit of the roadmap prioritization process, again, we have a massive user base and a massive community and it's not possible for us to talk with every single individual about what it is that they need. So instead we have processes to try to gather that information from as representative a group as possible, always with the underlying goal to be able to create generic improvements that will be useful across countries, across projects, across donors. This is the goal in our open source platform is to cover functionality that would be able to be reused or adapted for many, many different use cases. So the way that we have captured these priorities, we have a key stakeholder group where we want strongly represented there, the ministries of health and country government needs often gathered through our HISP networks that are working closely with these country implementations and understand the use cases and understand what their host governments are requesting and need. We have global project leads here at the University of Oslo who are interfacing with our partners and the donors that support DHS too and often have very specific requests that they need done by a certain time. And then of course we have the HISP-UIO management team which is largely comprised of researchers, professors, high level DHS2 users. And that is an effort for us to pull in the evidence base behind what would be the most useful steps forward in a given area. And so what we do is we sit down with this group and spend several days discussing priorities, pulling in those from around the community, of course having pulled information from our interactions with the community of practice and the various implementations we support. And then we have to go through a process of ranking and voting and negotiating what would be the next set of features and what are the most important to get out there in the near future, the medium term and the long term. Many of these functionalities require several releases to fully complete them. So it's not the case that we can start something and know for sure that it will be done in the next release. Some of them are much bigger than others in terms of the resources required. So what we do after those meetings is that the product managers and technical leads need to sort and organize the functional requests, try to break them up into tasks, try to determine how much time, software time and development will be necessary and then bring that back in step three back to the group and present a prioritized list based on what they have requested and also kind of the time and resources that would go into them. And then of course throughout the year we also are constantly assessing new priorities that come up and determining whether they need to bump something down in the roadmap so we can fit this new priority in. So an obvious example for this would be the work that we put into the COVID support requests over the last year and a half which really led us to quickly introduce increased functionality around things like contact tracing, disease surveillance, et cetera. So just to give you a look at what this kind of timeline looks like throughout the year we'll have another annual platform prioritization meeting in the fall. This is where again we bring together that large group of stakeholders and we discuss and organize and rank. We take a look at our existing roadmap and we see whether there are new things that need to make their way in ahead of some of those that have been prioritized previously. And then of course the HS2 does two releases annually in the spring and in the fall and a month prior to that release we start to plan the next release so that when we put new software out into the world we're already beginning work on the next release and making sure that we have no downtime and making sure that we've made any adaptations necessary because throughout the process we're constantly learning of additional needs. So things that come up of course in addition to kind of newly requested functionality would be bugs or performance improvements that have been identified that also need to make their way into the coming releases and the coming patches. I just wanna give you a quick glance at our tool that we use for ranking and for discussing and breaking down into activities. It's massive. At this point we have 423 different prioritized features functionalities and tasks. So you can see why we consider this roadmap to be something that covers kind of the next several years worth of work and you could see this is the very top of the list. Tracker performance for large scale implementations was the highest rank priority last year when we did the process. And hopefully you've seen that that's been reflected in the work that we've put into improving tracker performance for large scale implementations. You probably saw in the presentation on Monday from Marcus that we have at this point very large tracker implementation supporting COVID and other vaccination efforts. And we think that this will just continue to improve and get better and better. So that's where I'll transition over to talking specifically about tracker and where we're focusing our time. So we will continue with performance improvements for tracker. Some of what we've done is to build up much better testing environments here at the University of Oslo. Give us a more accurate picture of what any new functionality would do to the environments that you all are running. But we also have built a new tracker importer which is on the ground which we're gonna continue to improve on. And we're looking into other things that have been identified like database lock issues, et cetera. So performance will continue to be something that we take very seriously. We really want to know that tracker is bulletproof for the size and scale of implementations that are running globally. Duplication has always been a concern for us. So we had previously spent a lot of effort on preventing duplicate entry in the first place through improved search, through the ability to mark possible duplicates. We're continuing down the path of now creating new tools for managing and merging duplicates, both in the form of tools for the user doing data entry and in process tools for those that are system admins or that are responsible for the dataset. So you'll see those continuing to come out in the coming release and after. And then a main effort for us is actually deprecating or getting rid of the old Tracker app. So you know that the Capture app was released a couple of years ago. It first replaced the Event app and all of the functionality there. And we've continued to transfer over Tracker functionality into the new Capture app. The Capture app has a much more robust framework that we can build on. It's more performative. It can handle better areas where there's intermittent connectivity. It's also a dramatically improved user experience. And a lot of effort has gone into the user information in the way that we have designed the functionality for that. It paves the way for us to add additional functionality as well to Tracker that many people want like editing multiple TEIs and line lists. So these are things that we continue to work on. You will see already that there's enhanced Capture app experience in 236 where your user can, it doesn't matter whether they're in an event program or Tracker, they can start from the Capture app and they can find and search and register individuals there. And then when they open it, it will seamlessly go to Tracker. But what you will see in the next release is that we will continue down that path so that they don't even need to open the Capture app for many of the use cases or the Tracker app. They'll be able to do everything within Capture and we'll continue from there. Tracker analytics, Scott will talk to us a lot more about when he covers analytics but just to say we know that there are many types of analytics that you'd like to be able to do with your individual level data and we are working on those now. Cross-program analytics, individual tract entity analytics, ownership analytics, these are things that are all coming, they're in the pipeline, they're things that are being designed now. Also from a platform perspective, wanted to mention and Austin will talk a little bit more about these kinds of things but we've worked very hard to make Tracker more extensible. What this means for you is that the new Capture app is a very modular application that makes it a lot easier for you to remove things that you don't want in your workflow and to make it a simpler user experience given what you would like to achieve and also making it easier for you to reuse our components into an app that sits on top of the Capture app so that you can have something very specific to your use case but still matches the look and feel and functionality of DHS2 in general. We've been working on the Tracker API endpoints trying to make them faster and able to scale further and we'll continue to do so and outside of the software, we're working of course with the WHO metadata packages team. We know that Tracker is a quite complex software to configure and one of our efforts to make it easier is to give you a starting point so that we are publishing specific packages around HIV case surveillance or malaria elimination or maternal and child health. So Rebecca will talk to you a bit more about what is in the pipeline there and we think that that is actually become the most common way that countries enter into the use of Tracker is going through these metadata packages. All along our team is also involved in country support and learning. This is a big part of how we were able to make the performance improvements that we've done this year is by getting directly involved in some of these large scale implementations and being able to identify what the real challenges are in the field and also taking that learning back to our functional requirements and design. We have a large team of country implementers that have been a part of the design process for the capture app that meet weekly and discuss functionality and discuss the user experience. And so we're doing our best to pull in all of the real experience from the various tracker implementations to lead to improvements. So I'm just going to share a couple of screenshots of what this will look like in the capture app following those processes. So in the past, Tracker I think was a very program centric kind of software. It very much was about building out a single malaria program or a single HIV program. But in the future, our expectation is that there are many countries now that are using multiple programs and that they have the same population in those programs across their TB, HIV, maternal health, vaccination programs. And we've wanted to make the capture app much more of a tracked entity centric kind of location. So we've fleshed out things like the tracked entity dashboard here. We want the clinical user to be able to see at a glance the programs that this individual is enrolled in, what risk factors they might have, what are their relationships and be able to interact with those very quickly. Likewise in the enrollment dashboard being able to see very quickly what the previous events were in a given program and highlight some of the key information so they don't even need to open those old events but they can see the information that they need from the previous event as they go to enter a new event. And provide again some really quick options for creating new events, scheduling events, making referrals. So you'll see that the new capture app again is much more kind of tracked entity centric. It should be a fairly seamless experience going from one program to another for a given tracked entity and to make it much more user friendly for the people that are doing the data entry. Likewise we have redesigned again the look and feel trying to make it a lot simpler for them to do things like dealing with duplicates, identifying those that are possible duplicates and being able to mark in the tracked entity itself up at the top of the yellow box you can see that this is a possible duplicate and allowing them to make some changes and options right there. So this is just a bit of what is coming. There's a lot of work to be done in all of these areas but we really think the capture app right now is something that can start being used by any program and will only continue to have more and more of the tracker functionality that will make it better and you'll see some of these screenshots that have been showing you starting to come out in 237 and 238. So with that, I think I'm gonna turn it over to Scott who's gonna walk us through analytics and in particular some cool tracker analytics. Yeah, thanks for the foreshadow we might. All right, so I'm gonna go through the 237 what we have lined up for 237 now. As Mike pointed out, we've gone through a fairly extensive prioritization process with our various stakeholders, HIST groups, UIO projects. And so we have a fairly clear idea of what we're aiming for for 237. So I'll present that to you but probably more importantly, I will also present to you what we have going forward 238, 239 and even beyond that potentially on some really big projects that we're working on. And Mike alluded to them, it's mainly tracker analytics, but we'll circle back. So before we move on, I do just wanna point out that there's a screenshot here and I've got a lot of screenshots throughout my few slides here. The first one is for 37, one thing that we're working on is an auto dashboard layout. A lot of us or a lot of you have told us that configuring the dashboards is kind of a difficult task. And that, you know, there's too much flexibility. You can drag and drop anything, you can move around anything. And sometimes it's very easy to make a poor looking dashboard. It's actually a little bit difficult to make a good looking dashboard takes a lot of time. And this is especially true for those low level users being the folks at district level, maybe even facility level. And so one of the requests to address that problem is to have an auto layout functionality in the dashboard. And so that's something that's coming in 37 and that's a screenshot of what that's probably gonna look like. All right, Mike, you can go forward, thanks. All right, some more 37 and Mike put a link to the actual published tentative roadmap that we have put together for 37 on one of I think his second or third slide. So you can check this out. We're trying to be as transparent as we possibly can be. Again, it's a tentative roadmap. We have done a level of effort estimate. We're fairly sure that we can fit all of these things in. Of course, you never know what complexities are gonna hit you. You never know, you know, DHS2 has to be responsive to, you know, any kind of emerging crisis or problem where DHS2 is served like COVID, for example, that can completely disrupt the roadmap, of course. So, you know, right now we're saying that with all things that we currently know about, this is what we're planning to get in. We feel confident that we're probably able to get in the vast majority of this, if not all, but, you know, life does happen. Things do get in the way. All right. So kind of going top to bottom here, the first one is indicator type for single value. And you see a screenshot of that. That's the first screenshot I kind of see right in the middle of the slide. Essentially, we've seen single value be an extremely popular chart type. And we've seen a lot of dashboards this week presented that are really using single values. Single values items are extremely important. And one of the cool things that we're gonna be able to do in 37 is we're going to be able to bring in the value type and put that on the single value chart itself. So for example, if you're showing a single value of a coverage rate, we'll show the percentage sign next to the single value. So that if you put it on your dashboard, you share that. People know it's a percentage and not a count or something like that. So we'll also add per 1,000, per 10,000 and per 100,000 as well, because those are the various value types allowed in indicator settings. I mentioned dashboard layout already. So we'll skip that one. We are also adding drill down for our charts. So for example, you're looking at a bar chart. You see that one bar for one district is looking a little bit weird. You want to drill down into that quickly to be able to look at the individual facility level data. Well, we're going to add so you can click on the bar. You can just click kind of drill down just like you do with pivot tables. And then you'll be able to see all the facilities. You won't have to navigate and move around in your work unit dimension or anything like that. It's just really quick one or two clicks and you're down to looking at the facilities and then you can identify the facility that's going off that district value. Freeze row and column headers. Just like you have with Excel, we see that people are making giant pivot tables. We put a lot of effort into improving pivot table performance. So now you can make gigantic pivot tables and DHIs too. Of course, as you're scrolling through that pivot table, you need to be able to reference back to the rows and column headers. And so we're going to label you to be able to freeze those rows and column headers. So as you scroll through those gigantic pivot tables, you're able to keep reference to where your data is coming from. The next one is access labels from multi-axis charts. That's the second screenshot you see here in the bottom right corner. That is kind of a continuation or kind of finishing up the multi-axis charts feature set. So we need to be able to add levels, excuse me, labels to those charts with multi-axis. And so that's going to be enabled in 37. Then a very popular request, especially for some of our friends in Southeast Asia is the continuous analytics for event and enrollment data. So in 35, I believe we introduced continuous analytics for aggregate data and we have seen it to be really quite popular. A lot of countries are depending upon as data comes in, they're seeing it in their dashboards. And likewise with the, especially with large rolls out, roll out of vaccination, COVID vaccinations, people are using tracker, they're enrolling their entire population in tracker, tens of millions of tried entities and they're giving out dozens, hundreds, hundreds of thousands of vaccines every day and they want to see that data coming in live into their dashboards. Now it is a fairly complex task. It is something that we're trying to enable. There's still some hurdles or still some roadblocks to kind of get past with this one, but we are looking into and hopeful that we are able to get it in. We don't get it in for 37. It's still going to be on the roadmap. We're going to keep plugging away at this. The last one here on this slide is last 10 year relative period. Again, another popular request. Many countries have had DHIs too for a while, you know, at least a decade. Many other countries have data going back well beyond a decade. And when you're doing that disease surveillance, especially for things like forecasting, you want to be able to see that long history of the data. So like, you want to see malaria over the last 10 years, you want to see the ebbs and flows of the seasonality. Well, we're going to be able to enable that with the last 10 years relative period type. Next slide, Mike. Okay, first one here is org unit profile. Actually, Lars is going to cover this one in a lot more detail. This is a part of a much bigger effort to enable DHIs to be a better master facility list or have functionalities as a master facility list. Lars is going to go into more detail on this one, so I'll save that for him. The next one is offline mobile dashboards. So on Monday, hopefully you saw me present the new dashboard on a cell phone. And we have put a lot of work into actually enabling the dashboard to work as well as it works on the web browser on your cell phone. So you can take your dashboard with you anywhere. Of course, that means that you want to be able to take your dashboard, drive out to a rural health facility, and still be able, maybe, and you go offline, and you still want to be able to share data with the folks at that health facility, right? And so one thing that we've actually, we're fairly close to completing is the offline mobile dashboard. So you'll be able to save a dashboard before you go offline, or you'll be able to mark it as, I want this to be saved while I'm offline. It will save it. And then you go offline, you'll still be able to see that dashboard. Of course, new data won't be added to the dashboard because you're not communicating to the DHS2 server, but you still will be able to share that data with whoever you meet with while you're offline. The next one is custom date labels. So this one was actually a bug. This is in the event reports download. So of course you can add custom labels to your enrollment date and your event date. This was not coming through in the downloads. It was really annoying for a lot of folks. We apologize for that. It has been fixed. And I just wanted to mention it here. The next one is legends and keys for pivot tables and charts. So what you have seen me present on Monday is that now we have legends applied to lots of different things. We have it to pivot tables, gauge charts, single value charts, bar charts, column charts, as well as maps, of course. And a legend is very, very powerful. You see the different colors and that kind of thing, but it's extremely important to be able to have a legend to know kind of where you are comparatively with the possible scores or values that are there. And so we see actually two examples of that, the top screenshot and then the bottom right corner screenshot, the pivot tables and then for the gauge charts on how a legend can be shown on those data items. The last one here I want to mention is the addition of category option in indicator expressions. A long time request by a few folks that have really struggled with this for years. If you actually see the JIRA ticket, it's number 716716. That's a very old JIRA ticket. It's been out there for a while, especially I know South Africa has pleaded with us to get this feature in. I'm very happy to say that we are finally managed to actually get that in. And in fact, that screenshot you see in the left corner was actually taken today. I just met with the developers earlier this morning and they're wrapping up that feature and that's really exciting. So you'll have category options and indicator expressions in 37. All right, next slide, Mike. Okay, so this is the big one. So that was 37, now we're talking about 38, 39 and moving on past then. And right now our principal focus for these later releases are putting together and building a new event reports application. And this new event reports application is going to touch on those use cases that Mike talked about ownership, cross-program, tracked entity analytics, relationship analytics. We can't do this in the current event reports app. The current event reports app is old. It's over 10 years old now. We can't add new functionalities to it. The user experience is not very useful. A lot of you out there are struggling with this and it's time to build a new one. It's time to make it much, much bigger and better than the current event reports app. So we've been working on this for actually quite a while now, nearly say probably about nine months. And I have kind of the steps here. I'm going to go through this really quickly just so we're all on the same page. These are fairly tentative now, at least the ones certainly in the future, but I can give you up into a very accurate picture of what's been going on up until today and what we have plans for in the future. So the first one is that we've been collecting your use cases for about nine months now and we have dozens of use cases of event reports, of tracker data, of different kinds of tracker analytics. There's been some community innovation, some apps that have been made out in the field that do a better job than our standard application does at this. We've been able to learn from those. We have been breaking down those use cases into feature sets since we started to get them. So we've done that since the beginning of the year up until today and like I said, dozens of user stories, you know, probably over a hundred feature sets at this point, right? So it's quite the task to start breaking down all these user stories and then turning them into something that we can actually start to go mockups and develop from. We've also been compiling these feature sets into our backend endpoint buckets. I don't wanna get overly technical here, but essentially the tracker backend has to be built or the analytics tracker backend has to be built and significantly improved on what is already there. Before we can build out these front-end applications, before we can make the new event reports. And we need to line up the user stories and the feature sets with the backend so that the backend is able to pull data from the data warehouse and then feed it into the analytics app so that it can produce whatever picture it is that you want it to produce. And so again, we're understanding the pictures that you wanna make, figuring out how that looks in the new app and then making sure that that corresponds with how the backend is gonna be able to pull it out for us. And so that kind of leads me into the next step. And here you see this Joe might not, our UX developer might not be very happy that I'm showing this to you, but you gotta get started at some point. We have started to build out some mockups for what the new event reports app looks like. This one is fresh off the presses here. I mean, this is brand new. It's going to change a lot. So what you're seeing right now, some of the general principles will be the same, but it's going to change a lot. And so this is the current mockup of the new event visualizer app. We are also calling it the line listing app because that's one of its principal functionalities. And we're gonna go through a very iterative process of refining this application and refining this mockup. And so we have identified a stakeholder group that we're working with on a regular basis to do this. We're going to have frequent meetings. And I invite any of you to plug into this. So reach out to us in the community practice, tell us your user story, tell us your problems. If you're not talking to me about this now, then you're probably not included in the process, right? So we need to make sure that we get as many voices at the table as we possibly can to refine and develop this application together. This is definitely a community effort. So again, a 0.5 here, we're building out the backing components first. We have to have the back in there before the front end can actually use or produce any pictures, right? So we have now two backend components. We have event and enrollment. Those are there. They have to be significantly improved for this application. So we're adding a lot to them. And then we have to build two entirely new backend components. We have to build a tracked entity backing component and a relationship backing component. That's a lot of work. And so the team is working on the event and enrollment now. We'll move on to the tracked entity and relationship next. Six point here, I don't know, I'm sorry, I'm just trying to give you a bit of an overview so that we're all on the same page is to build out the MVP for the front end app. MVP here doesn't mean most valuable player, it means minimal viable product. So this initial release of the application will only probably be the event backend and the enrollment backend, which means that it's going to be fairly similar in terms of functionality to the current event reports app. Obviously a much more improved UX, a fair amount of new functionality, but the vast majority of it will still be what you know in the event reports app. But this gives us a foundation that we can continue to build on. So the MVP is giving us that initial place that we can continue to build on. Point seven is us continuing to build on it. This is to complete the full front end. So that's the relationship back in and the trite entity back end. And then point seven here is to continue to add the individual analytics types that we know are important that are not currently supported anywhere in DHS2. For example, if you've seen the Sri Lanka use case, they've made some really incredible network charts or network graphs. There's also some really specific scatter plots that are useful for individual patient or individual case analytics. And we need to naturally add those to this application as well. So just like you see in the data visualizer app, we have pivot tables and all of our different chart types. Hopefully the goal is that in the future we will have line lists as well as many different chart types, pivot tables in this application as well. All right, next slide, Mike. All right, well, I guess a couple of slides didn't make it in, but I can come back to them. I guess you downloaded this right before or a little bit before. I think you can text code. We are okay with time, but I'm in the online version and I'm seeing the same. So I'm gonna try and have you there. All right, I'm gonna let you take over the screen, Marta. So let me text code. There's just one slide right before Android. Okay, there we go. Should we come in? Okay, sorry. And this one is very important actually. So we are trying to get feedback from you about how we can improve translations in DHIs too. And the developer team led by one of our senior developers, Jennifer, is trying to get information from you how you need us to improve translations. Translations are obviously extremely important for the DHIs too. Community DHIs too is translated into probably a couple of dozen languages at this point and we need some feedback from you on how we can continue to improve it. So Jennifer has made a small survey. It's gonna take five minutes to do it. There's the link to the community post where you can go in and take the survey. Please do, we really need some community feedback on how we can continue to improve translations in DHIs too. So I ask you to go in, take the survey and let us build in what you need us to do. Okay, sorry, Marta, over you now. No problem. You are actually still on time. So thank you, Scott. Amazing features coming for both. Analytics and tracker as well. Let's focus now on Android and see what is coming in the next version to release this year, 2.5 and then also let's have a high overview of what will come in the next two versions, though we don't know for sure yet what will include it as it depends on the process that Mike described at the beginning of this session. So what we learned from the last prioritization process last year, the fall last year, 2020, is that these are the areas that ranked higher. We were, it was super clear that we had to focus on local analytics on using the device store in the data. The DHIs to under capture app started being a tool for data collection, but it was super clear from the first minute that it needed, we needed to add some capacity for analyzing and using the data for day to day work. So we are finally getting there after three years. And then I will go through the other features. I'm gonna explain as Scott did, what are we going to include in 2.5? The roadmap for Android is also published on the website that has been shared at the beginning of the presentation. Again, there is a level of uncertainty that we always have based on complexity or other events that might happen and we have to respond to. However, we are, we have a good plan and we also think we can make it. So please go and check there if it helps your planning your projects. There is a point here as you see the second one, which is about stability, quality and security. So I always have that one. It comes from last year presentation and I'm gonna keep it every year I think because this is a constant effort. This is something that is always there release after release and this is not only for, I'm not speaking only for Android now, it's a constant effort in the HIS too. Particularly in Android, I think it's important to share that half of our time it's going to performance, stability, security, maintenance in general. As you can see here, around 25% is for factory performance or improving security. The other 25 is for backfixing. It's never, never that precise and we keep on adjusting as we go. But that's, this is the aim, that the 50% of the developer time is for new features. So aligning to the timeline of the HIS2 web, then actually it's of Android. This is just a reminder within October and we are gonna call that one 2.5. What will happen next year is still not super defined and I'm not writing 2.6, 2.7 here because based on the prioritization, we would really like to be able to release 3.0 next year. But that's gonna depend on the prioritization process and on what are we allowed to include. Something that we already know and I can already introduce is that we are gonna stop supporting Android 4.4 KitKat version. This is for technical reasons. Some libraries are not supported anymore by Google but they will be not supported anymore by our next release in 2022, not in October this year. And we have to stop supporting it. We have been trying to avoid this pushing it because we don't wanna leave all devices non-functional. So we will see how to do this. We will send announcements. If there is a big percentage of devices from 4.4 using the app, we will consider leaving the last version of 2021 under maintenance until we see that we are not blocking any implementation. So everything will be done carefully but if you are planning projects now or you are running an implementation, we would like you to start thinking and planning knowing that 4.4 will not be supported from April 22nd. So moving now to the features, local analytics. We are very excited of being able to say that the next version of the Android app, it's gonna let users analyze data in offline and in their device. What do we mean with local analytics? Local analytics are, as you can see, analytical objects that can be generated being offline but they only use the data in the device. The local analytics will be available in all screens of the app. So home screen, data set screen, program screen. As you can see, we have a new navigation bar here. It's a great present on them. When the users move to the analytics icon, there is where they see the different analytics. In the first screenshot, you can see here that there are analytic groups. This is particularly relevant. We think for the home screen. These charts can be grouped in themes or topics. And then when the user navigates them, the analysis, the charts will change. This is based on the configuration. And this is, as I said, particularly relevant in the home screen because a user might have access to different data sets or different programs and still have integrated analysis and want to be able to move, okay, how am I doing in my external consultations first level clinic or how am I doing with the vaccination? So there will be thematic groups. We are trying to avoid to use the word dashboard because a dashboard in the HIS2, as you saw from Scott is a very powerful thing. It has a lot of features and functionalities that here we are only grouping things and it's only happening offline. So we have to come up with a better name but for now these are just groups. Once the user is in the analytics screen, they will be allowed to change or filter by video or by all unit depending on how, so depending on the units the user is assigned. And then how is this going to work? How do I get charts into the mobile phone, into the Android app? This will be configured by the admin user using the Android settings web app. They will not come by default because we just don't know what to display there if you don't tell us what to display there. The charts and analytics to be shown to the user will be really dependent on the use case. So the admin user will be able to open the Android settings app and decide which charts or tables are going where and group them for the end user to see them in the device after thinking their configuration. This admin user will be able to select mobile, what we call mobile compatible analytical objects. What is this? We have had to make a selection because we wanted to start small. So we have made a selection of analytical objects and features that we can support in a mobile device. Those are people tables, column charts, line charts, radar charts, pie charts and some single-value items. The user needs to have access and they have to be well-formed. They have series categories filters depending on how on the chart type. Yeah, it will be check depending on the chart type. There are many limitations that we have put to the features that you know already. The visualizer app is super powerful. It has an extreme number of features that allow you to adjust and to configure your chart, the title, lines, cumulative charts. We are starting simple. We are supporting a simple visualization. So we will document what is supported and what is not. But just don't expect that all that you can do on the visualizer app, it's gonna come to the device. We will make a simple version of it whenever it's configurable. But these charts will be configured through the visualizer app. And then a sub-selection of those will go to the Android app. We will give you more details when we release it. Another feature, the task screen. We are also very excited about this one because this is where data is gonna help the user organize their day-to-day activities. The task screen, again, if you look here at the navigation bar, is this being in the home screen? The user will have data entry, analysis or task. What do I do today? This screen is supposed to answer that question. What do I do today? So it's just a to-do list. The user will be able to navigate that to the list for calendar view. And what is the task, right? What is this term now? The task is just an event that is scheduled to happen today, tomorrow, next week. The task will be grouped by date, starting today always, but the user can navigate. Or an event assigned to the user, if you are using that, or a dataset which has an expiration date or which reporting period is about to expire. It's trying to help the user organize the data collection. This is gonna be actually great. These two are gonna take the Android app to a different level in terms of its use. Now, we're gonna continue with some other features that are a bit smaller, but they're improving things here and there. About the data entry experience, we are gonna tailor the options that we offer to the user to the tracker configuration. We do this to some extent, but we think we can do more. Simple example, if there are no relationships configured, it's don't show the relationship pattern, which for right now it's appearing. So we are gonna try to simplify the user experience as much as possible based on the configuration. We are gonna also try, we are gonna keep the calendar view that the user uses more often. The last selection will remain. As you know, the users can switch from calendar view to spinner view. So that will be kept in the app. We are gonna display also the reason for data not being editable because for now we are not displaying this. So data can be blocked because the user has no permissions because it has expired, because it's completed. So we wanna show this because it causes confusion sometimes. And then we also want to be able to display or redraw the QR code or bar code after it's stored in the device. Until now we can render them, but we cannot display it to be shared so that you can print it or read it with another device. So now it will be displayed. Moving on tracker features. We have a number of pending features to catch up with tracker. And one of them is break the glass. So I don't need to explain this. I think it's quite clear, but until now it was not supported in the Android app. And from 2.5, it will be. So this is the flow for breaking the glass. And then I'm gonna jump to the students. We will add a filter to be able to filter the track entity instances that are marked as follow up. And then also support the event to the relationships that are for until now not supported in the Android app. I wanna explain the separate online and offline search. What is this? Until now when a user search makes a search in the app, we are searching locally and globally, let's say in the server, and that's transparent to the user. We compile the results and show them in one integrated list. This is making the search a bit slow because connection is not always good. It's in most cases, it's not good. And also in most cases, the users have in the device what they are looking for, because it's a patient that came before and it belongs to my facility. So we have learned that the approach that we took at the very beginning was not the best. We are changing that. And right now when the users, no, no, in the next version, when a user performs a search, we are gonna search locally. That's super fast. And then the user will get the results that come from the device. If not enough, then the user will be able to search globally. And the result will be again, as well, I mean, we keep the result integrating one single list, but we do the search in two steps, to reduce the time and to reduce the number of times that we actually call the server. About maps, we have just reviewed the whole user experience. The maps part of the app has grown a lot and it needed some reflection. So we have improved it and hopefully simplified for the next version and just added the button for the user to center the map on its current location, which complements the navigation feature that was added in the last version. And then the two small changes that are more for the implementer, we have been requested to align how do we handle the language in the app? It may, what do I mean? Until now, the Android app is taking the metadata language from the user in the HIS2, but the UI of the app, the language of the UI of the app is taken from the device. So that was the wrong decision. Again, we are now downloading, we will downloading the language for both UI and metadata from the server and then use that from the user configuration in the server and use that in the phone. And then we are also adding in the settings menu a depth options that will have a few sections to help testers or implementers debug the experience in the app. For instance, the one we like the most is a program rule action quality checker. So if a program rule fails, it will help you understand why in the device. This is all for the next version. Now in the coming version, we will still focus on stability, quality, security performance, as that's a permanent effort. But then we know that we have to work on the mobile implementation support. Implementations are growing and we really, really need to strengthen our capacity to support the implementer, the user managing the implementation. And there are a number of things we can do there, but we have not been able to do it yet. So we want to prioritize that for 2022. We also would like to, I don't want to say we bomb, but redesign and improve the user experience and the user interface. In particular, to follow the lead of tracker and then try to be a bit more like entity instance oriented. Right now we are very programmatic oriented. And that requires some changes in the UI. So if prioritization allows, we would like to do that as well. And then we have to need to leave space for the new features that we will learn and some that are still pending from the last prioritization. So I think this is all from Android, yes. And I'm gonna, I think the next one is either Lars or Austin, Lars, thank you. I'm still sharing, okay. Great, thanks a lot Marta. Yep, so this is Lars. So in this section, I'm gonna talk a little bit about the sort of functional things we have on the platform side of the application. And we're gonna have Austin talk a bit more on the technical foundations, technical platform from a roadmap perspective. So first of all, I would say the main functional themes we have on the platform side are basically three things. First of all, organic management. Some people call this master facility list. Some call it facility registry. It has a lot of names. In any case, you would like to improve the way we deal with organets and hierarchies and facilities and districts and all those things in DHS2. Data quality is another broad theme that we want to do a lot on. So a lot of different features coming around data quality and also working hard to make the user experience of DHS2 better through incremental improvements of the existing apps but also with complete rewrites of some of the apps. Some of the apps we have are quite old. They're kind of becoming a decade old now. So there's due time for a rewrites. So look out for a lot of new cool UIs and apps. All right. So on that note, the first app we're gonna work on to rewrite is the data approvals app. So an interesting fact is that actually some years ago, we introduced a new data model in DHS2 called data approval levels and data approval workflows. But interestingly, we never exposed those in our own user interface. They were only used by certain implementations and it remained with custom apps and it remained a backend API feature only. So it's very much about time to expose this in our own user interfaces as well. So the new data approval app is gonna support parallel data approval workflows. So a data approval workflow essentially contains a period type and it covers multiple data approval levels, which means that we can essentially improve many data sets in one go. You can also actually improve many periods in one go because the frequency of a data approval workflow can be greater than or actually less frequent than the underlying data sets. It also enables you to have what is called parallel approval workflows so that you can actually have multiple workflows in the same instance of DHS2, meaning that some data sets should be approved quarterly at the district level. Some data sets should be approved monthly, just the facility and the provincial level and so on. We also want to make it much easier to view the approval status of different units in the hierarchy by from within the hierarchy at times you kind of hunt for every audience to view the status. So let's start a look at the of the new UI. So these are some of the marks you're working on. It almost looks like if the app is done, but it's not. But these are the sort of design markups that you have. So the first step would be to choose a workflow. As you can see, you could have things like malaria, child health, reproductive health. Next would be to choose a time period. This comes from the period frequency of the workflow. And then you select a organizational unit from the hierarchy. And you can see that we have these beautiful icons here that indicates the approval status for each unit. So they don't have to go and click on everyone to see the status. And then we have the ability to view data for all those data sets, which are part of the approval workflow so that you can quickly browse and switch between the data sets to view the data like this. And finally, you click the approval button and then you're going to see an overview of what you're about to do, like which data sets are you going to approve, what is the time period and so on and so on. So these are the immediate plans for the data approval app. Okay. Another one is the new data entry app. So I think the existing data entry app that we have is arguably the most used application in DHS2. And it might score about pretty well on a global basis as well. It was built, I think, 12 years ago or so. And it's very much about time to give it a fresh look. So we do plan to build a new data entry app based on new technology stack that we have with DHS2 and the new sort of UX guidelines that we have with DHS2 now. We're not going to make radical improvements because we know that it pretty much works very well as it is. And we know that there is substantial training to be done if you want to do radical changes. So we're not going to, so you can kind of, you can sleep well at night. There won't be radical changes, but we will try to make it incrementally better. So one of the improvements we have is always visible data sets and period selections. We don't kind of lose sight of that when you scroll down. This also has a data quality aspect in that we would like to make data validation a lot more prominent and we'll come back to this. And we also plan to improve the offline support so that you A, don't have to be online when you log in and B, you don't have to click the little button every time you want to upload data to the server. That's going to happen automatically when you're transparent to the user. So let's have a look at how this is going to be. These are, this is a new design for the data entry app. As you can see, we have the always visible selection at the top. This is a theme that cuts across the tracker application and data approval and so on. So we want to make the experience similar as possible across the apps to reduce the training burden, essentially. You can see that you have a nice new layout. Functionally, it's quite the same as we had. So there's no big training efforts to be done to have people use this. You will notice on the right side that we have a more visible sort of right side panel with details, comments, min max values, historical values, there's going to be a chart with historical values. Today you have to click in every cell to get this good old dialog that pops up. We would like to make this a bit more accessible and possibly sort of always open and available when you use the application. In terms of data validation, again, we would like to make the validation a much more sort of prominent in the system. Right now, you actually have to go and click run validation every time. And a lot of people don't do that or they would ignore whatever validation is thrown at them. And so we would like to make the validation basically come to the user, as opposed to the user having to go to the validation. So there's going to be a right side panel where we have validation rules coming sort of frequently. So instead of having to click validation, there's going to be validation alerts automatically popping up as you enter data. This is actually quite complex to get right because you don't want to be too intrusive, but we also don't want to be too black matter. So we're also going to sort of discriminate between high, medium, and low priorities so that we can get the most important validation in areas of top and so on. All right, so on that theme, you're also going to come up with a new maintenance application. So the current maintenance application is actually getting also quite old. And we can see that the architecture is kind of crumbling a little bit or because of the sort of frequent changes and refactorings we've done over the years. So it's time to rewrite. For the new one, we don't plan to make a radical new design really. We hope to kind of keep some of the design and sort of the functions that we have today. But we would like to make it faster, to log faster and also use less bandwidth. We know that the current one uses a lot of people's precious megabytes on their dongles. And we would also like to make many incremental improvements to the app. Some of those are what we call advanced filtering, edit fields in lists, bulk sharing, and bulk operations for update, delete, and download. So let's have a look at how it is going to be. This is a new sort of UX. This is not set in stone yet, but this is the current design. As you can see, we have more on the menu and more of the items on the left side menu. So you can quickly navigate between those. We also want to have more advanced filtering. So you can see now the filtering dialogue is currently on the right, where you can have sort of more options for doing filtering and searching. Another highly requested feature was the ability to edit in the list. We know that using the maintenance app, when you want to make a lot of changes across many, let's say, data elements, can be quite cumbersome. And people sometimes have to go back to Excel or CSV and do API uploads and all this. And so we would like to make it easier to do both bulk edits and also to change certain fields directly in the list without having to go into the field or into the object every time, which can be quite cumbersome when you have to edit 100 data elements in one go. So that's definitely coming. So the idea is that we're also going to have bulk operations. So if you can look at the green area there, it's going to be possible to do, to have sort of checked the different boxes next to each, let's say, data elements and then do bulk updates, do deletion, to do bulk sharing and to download to different type of formats. Bulk sharing is not a highly requested feature. We know people would like to do sort of, let's say add things to groups. In one go, instead of having to go one by one, they would like to do updates to single fields across many objects and so on. So these are things we're working on to make bulk operations more efficient in the maintenance step. Okay. So switching gears a bit. The other big topic we have is what you call organic management or MFL or whatever acronym you prefer. So on that note, we're going to work on a much better configurable profile for organets. So a profile is like a visual presentation of the information associated with the organets. So for a start, this is going to be visible in the maps application. We're going to have a right side panel in the maps that's going to display this profile. And later we would like to integrate in visualizer application for things like scatter plots and other types of charts. So the profile is basically going to attain different pieces of information for an organet such as an image of an organets, fixed information like name, description, opening date, contact info, the location obviously, like the point, long lat or the geometry, metadata attributes, meaning customizable fields for information. And then organ groups in group sets. When I say groups in group sets, you can think about things like facility type, facility ownership, area and so on. And also to display aggregate data, like what some people call semi-permanent information, semi-permanent information like population data, human resource data, and so on and so on. So here's a quick mock of how this is going to work. So we are thinking that first of all, you can of course configure the content of the profile. And then when you go to the maps application, it's going to be possible to click on a facility and then have to click to see more info and then have the right side panel there that shows more detailed information about the facility, like the profile image and so on and so on. In relation to this, you're also working in a, what are you going to call an organic layer in the maps or maybe it could be an MFL layer. It's going to kind of simplify the selection of these things to make it easy to do this kind of typical MFL facility registry operation in DHS too. So that's a lot of exciting stuff coming out there. All right, so otherwise we have, I'm just going to go through some various points that we have on the roadmap for the platform team. The first one is what you call organic indicators and analytics. This is essentially a new flavor of indicators that allow you to do things like counts, organets in groups. Is it low for feedable? Yeah, count organic in groups as well as use data criteria for analytics. So we can basically use data elements to say, show me only facilities that have water, show me only facilities that has electricity, show me those that provide certain types of services and so on and so on. So more kind of sophisticated analysis around indicators based on data, group sets, metadata and so on is going to come. And this is also on the sort of MFL thing. Another thing we're working on is having a workflow around the organets. So basically have the ability to propose and then approve organets in a workflow. So in an MFL or facility registry setting, what we quite often see is that multiple systems become part of a bigger architecture. And then they would like to have a workflow around who can create or edit organizational units or facilities in the main system, instead of just allowing everyone to create it or have some kind of cumbersome paper-based out-of-hand workflow. So this is going to be a way for multiple systems or stakeholders to propose organets and then have certain people approve the organets before they become part of the hierarchy. Okay, another one is having the ability to do split on merge of organizational units. So that basically means the typical use case here is administrative districts wanting to either split into multiple districts or many districts would like to merge into one. And this is a fairly complex operation because the organet is associated with a lot of entities and these just too. So having all this is going to be quite a bit of work, but this is something we would like to tackle at some point in the next two years. Okay, so on the data quality notes, we also want to support, we currently support what we call set score for outside detection in the new data quality outside detection page that we released, I think in 2036. Merge unit also more like to support what's called the modified set score. So the regular set score is based on the mean, like the distance from the mean, the modified set score is based on the distance from the medium, which is typically more resilient towards alphyrs in the data sets when you calculate the distance. So that's coming. On the security note, we also have a lot of plans for security. We won't have time to go into all of that now, but one of the biggest one is support for what they call token-based authentication. So what that means is that we would like to allow clients to create and use a security token or access token, which we hope that will make it easier for apps to use VHS2. It's going to simplify things like web portals that would like to authenticate and get data out of VHS2, third-party applications, and also backend microservices that would like to create integrations with VHS2. We think that all of those things will benefit from a token-based authentication process. Yes, and of course, we are continuously working a lot on performance, high availability, better security, and also better automated testing. We have a lot of interesting stuff coming out regarding high availability, easier cluster setups, ability to deploy more easily to containers. We would like to create a guide for how to deploy in container orchestration tools like Kubernetes and so on and so on. That's kind of out of scope for today, but lots of stuff coming out there for easier and better deployments of VHS2. So with that, I'll turn it over to Austin to talk more about the technical frameworks and roadmap for the platform team. Thanks, Lars. So as Lars mentioned, I'm going to just go over very quickly some of the technical foundations that we're developing and the enhancements to those foundations that will be coming soon. These are a little bit more technical than some of the other features we've talked about today, but they're underlying to a lot of the applications and a lot of the features that we're talking about. And they also support not only the bundled core applications that we've talked about a number of the features for, but also third-party applications. And one of the key goals is to kind of merge those types of apps into one platform so that what the core application can do third-party or externally developed applications can also do those same things. And one of the key enhancements that we talked about in the what's new session on Monday and a little bit in another session on Wednesday is what we call continuous application delivery. And this will continue to improve and be used by the core team to develop applications on a more regular cadence or releasing on a more regular cadence than the six-monthly DHS2 core releases. This will allow applications to be upgraded independently of the core and also to be able to support multiple versions of DHS2 so that it reduces the maintenance burden and allows people running different versions of DHS2 to use the latest features and fixes in a particular application. So that's something that we're working on in the core team to integrate that higher release cadence for our applications into our workflow, including things like migrations to Jira, performing more granular quality assurance and testing of those applications and being able to publish those apps to the app hub with confidence so that they can be upgraded independently in DHS2 instances in the wild. And then there are also some improvements to the DHS2 core itself to support those types of workflows, including improved handling of updating applications, seeing what updates are available and rolling back those updates if there happens to be a problem with a particular version of an application. And in addition, we want to combine the installed and bundled applications in the DHS2 core so that they appear at the same level and have the same core functionality available to them. This is a bit of a broad slide. I'm not gonna talk too much in detail about each of these, but these are features that we're working on in the underlying platform that will power a lot of the applications and a lot of the extensibility of DHS2 as a whole. One of those is simply to focus on platform first feature development. So as I mentioned, we want to orient our development process around building for extensibility so that what we build as the DHS2 core team can also be built by external parties as well. And also so that what we build in the core team isn't set in stone when it's built, it can be extended through extension points like dashboard plugins and tracker widgets and configured in a particular application to use those extensions that might be developed by the core team, might be developed by other developers around the world as well. The third piece under first class extensibility is web hooks for interoperability. This is something that we're starting to introduce for program stages and program enrollment notifications and then moving beyond that to a more general approach to web hooks. Web hooks are basically allowing DHS2 to call out to external systems when a particular thing happens. So that allows those external systems to react to changes that occur in DHS2 in an asynchronous way rather than needing to continually pull DHS2 for updates and maintain some sort of state to figure out what's going on and what is new and what is pulled. And another big feature that we are introducing, Scott mentioned this a little bit in the analytics section when talking about the mobile and offline ready dashboard, but we're adding this offline support functionality to the application platform itself. So it is available to all DHS2 apps that are built on that platform. So we're building this in a generic way, initially rolling that out to the dashboard and then also improving, rolling that out also to data entry and capture applications in the future as well. Plus more and more apps that need or could benefit from offline support. That PWA also means that those applications are installable in a way that's similar to a native mobile application on Android or iOS or even on the desktop. So that opens up a number of interesting workflows and easier access to those applications. There's a lot more that we're integrating into our application platform and core extensibility work. We're overhauling the logging page that has been kind of static for quite a long time in addition that it is involved with what Lars mentioned with token-based authentication and also being able to handle, better handle session timeouts and logout events in applications themselves so that the state is preserved and the user can log back in and continue where they left off in a generic way across all applications rather than needing to make sure that their session doesn't expire while they're working. Client site caching is another big one that will improve performance of a lot of our applications and allow for much more reactive behavior in those applications since some data will be available locally in the browser and doesn't need to be requested across the network. That will also reduce the amount of data that needs to be transferred over the network which is important for low latency or low bandwidth situations that a lot of applications find themselves in. We're also improving a lot of our UI components and adding new ones. You'll see a lot of enhancements to the org unit tree which is a commonly requested component and that will also be rolled out and standardized across all the applications that we develop as the core team and available to third party applications as well. And there are many other components that have been reworked or will be reworked including the sharing dialogue and several others. Finally here, and this is kind of a big one there's a lot going into it but improved internationalization that's within applications themselves but also in terms of how we perform that internationalization and translation on the server side how we support customization of those translations with things like installable language packs for applications and there'll be a lot of improvements to how that translations work and how translations can be customized in the individual instance coming down the line. Just a shout out again to what Scott mentioned earlier to go to the community of practice and fill out that survey about the translation workflows and the translation features of DHS2. Final slide here on a technical note this is about end-to-end testing which is testing our applications in an automated way so that we can ensure the quality of those applications prevent regressions and test things in a much more rapid manner and not rely so much on manual testing which is still very important but will be supplemented by an extensive suite of automated testing that will test the application but also the API and the server as well. This allows us to test an application against a live DHS2 server using a technology called Cypress and we've also developed and are continuing to improve an extension to Cypress which allows us to record the network traffic from a test series of tests and then replay that in an offline environment so that we can run much faster on a much more regular basis and also perform them in continuous integration environments to make sure that those tests are run every time anything changes in the application. This also allows us to support testing applications against multiple DHS2 instances which can be quite burdensome to do in a manual way but it's something we wanna make sure is well tested whereas we roll out more and more applications with the ability to toggle features based on the DHS2 server version they're talking to. And the final one here is kind of exciting that we're introducing in the near future is the ability to do visual regression tests which will actually take images of the application and using artificial intelligence or machine learning will be able to detect significant changes or even meaningful but insignificant changes to the visual look and feel of that application in an automated way to prevent visual bugs from being introduced in a very long. There's a lot more to be said about end-to-end testing and API testing and that performance testing as well that will also be spending quite a bit of time to enhance. And that's it for me in terms of the technical platform features. Thanks, Austin. So it's Rebecca here. I'm going to go ahead and share my screen. I hope is it showing up in full screen? Hope so. Okay, so thanks for letting me join you guys. So I am Rebecca Potter here and I'm actually in the implementation team. I manage our global health content portfolio but important part of that is actually our implementation product which is the metadata packages. So I will just summarize here a little bit of what our plans are for this implementation product. So far, we are really looking at our pipeline and prioritization. Our demand is now outpacing our resources. So we're trying to figure out a way that we can streamline our prioritization to better reflect the needs and demands of the community. We've also always designed with integration and harmonized HMIS at the forefront based on the 20 years plus of action research and implementation learning but we're really aiming to put this into practice and do what we preach. And so this really comes down to being able to develop these packages in a way that is modular but also supports a harmonized and integrated HMIS. I believe our next key point will be to also improve the metadata quality. So we've been working a lot on processes and tools to actually improve the quality of the metadata that we're putting out into the world. And this includes things like our own naming conventions, coding conventions, sharing settings, how we share metadata between packages and actually package them up and produce them in a way that the community can take them. We are working on continuous integration for faster delivery to the field. So a little bit of a shout out to our platform engineers and DevOps team who are taking a lot of the principles that they've applied to the DHIs to software and really helping us to get the metadata packages out to the community with full language support, software compatibility and functional updates as efficiently as possible. And last but not least, we are learning from implementers on the ground several of them actually share their time with our core team, Hispuganda, HisWCA and as well as the Ministry of Health Requirements. So we're trying to work towards a process of systematically capturing and synthesizing the learning from the field and then identifying how can we improve these packages as global goods to match more closely the reality on the ground. And our challenge is how do we do that but while also maintaining adherence to the global standards of these packages? So this is roughly our development cycle and I present it here, this virtuous cycle of design because the packages, they're not a software plot, they are an implementation product. And it's a bit unique in that subject matter experts from the WHO, UNICEF, CDC, WHO Regional Offices also from Ministries of Health, they have direct input in shaping the product so that it meets those global health standards. So as I mentioned, we'll be renewing our focus on bringing that implementation learning back into the design. And after a backlog of packages and COVID-19 rapid response we're actually deliberately aiming to ease down on the accelerator of the package development cycle and actually focus more on testing the design practices with the field and documenting this feedback. So very much an iterative loop. We've worked a bit on a software release cycle. So when I joined this team, we were really quite ad hoc and now we've really implemented a twice annual release cycle where we actually try to follow the software. So when DHIS2 is released with a new version we follow up about a month or so later to develop, push out our set of package releases and this includes new packages, packages that might have substantial content updates but also including the software compatibility releases so that we're bringing the functionality of the software closer together with the metadata package as an implementation product. And in between these main release cycles we will also include patch releases for small fixes, minor functional improvements to design, terminology updates, these types of things but with no major impact to the data model or the large new inclusions of content requirements. So we were a little bit behind this year on our release cycle. We diverted a lot of our resources to the COVID-19 vaccine delivery packages. And so I think most of you guys know about those. If not, please go to our website but the immunization registry, core COVID-19 vaccine monitoring module and dashboards as well as site level logistics and the AFI updates are all out there. And then right now between today and in a couple of days next week we will be releasing everything on this page here. So most of these are actually, many of them are already up on our website but take a look out for the COP update in the upcoming hours and days. But this release cycle includes some inclusions to the CRVS, so vital events notification from health facilities, a cause of death package update with a full French local dictionary and COVID-19 emergency code support, a very long awaited vaccine preventable disease case-based surveillance package that integrates nine different diseases as well as the child immunization registry and some updates to our TD malaria and HIV packages to include the common logistics data framework integrated analysis, a new tracker program for TB, the drug resistance surveillance tracker and last but not least, a new data quality dashboard for malaria. So in the spirit of integration modularity and harmonization, in the last year we've seen our team make a huge push to support countries to quickly stand up their national systems for the challenges of COVID-19 response. But we also know that the COVID-19 interventions they need to be sustained long-term. So we're deliberately positioning and harmonizing these COVID-19 emergency packages alongside their overall health intervention areas. And so mainly this is disease surveillance and immunization. And in fact, these packages were designed based on routine immunization packages that had already exist and routine case-based disease surveillance packages as well. So we are seeing that countries are using the strengthening of information systems for COVID-19 emergency response as an opportunity to strengthen the overall system. And this is where we will be taking the direction of these packages and strengthening this as an overall programmatic support. So data quality and data use, these are cross-cutting priorities for DHIs too and for all of HIST as well as our MOH partners and other data users. The software team has made huge strides in DHIs to core functionality to bring data quality issues closer to users through DHIs to dashboards. And so we are now taking those and implementing for the first for the malaria package. So this is out already, but eventually for all of the other vertical health programs packages that help you to bring these data quality issues closer to users and taking advantage of that new functionality. I will also highlight our work around logistics with our LMIS leads, Brenno and George as well as experts from the WHO. And we've been really looking at bringing logistics data into DHIs to both as an end user logistics reporting tool for health service delivery. So that's mainly health facility level, but also being able to triangulate this key logistics data with the health services delivery data in these DHIs to dashboards that are already being used by the program managers. So essentially being able to use this to bring data together from different streams and harmonize it and integrate the analysis. And of course this common logistics data framework it should also be able to better support interoperability with upstream ELMIS systems. So a few of our packages that'll be in the pipeline for our fall release cycle, we are looking at launching the rapid mortality surveillance the technical packages been developed by WHO. Looking into more opportunities for ICD-11 integration with the mortality reporting. For immunization, we have a lot of learning around real-time monitoring for mass campaigns, working through triangulation dashboards with WHO and CDC. So bringing that VPD surveillance and the immunization surveillance, I'm sorry, immunization data and the stock data altogether. We will be advancing objectives on VPD surveillance phase two looking at outbreak models. We have an emergency leadership dashboard coming up with CDC. Advancing the work on NCDs, which is a new priority for us and TV moving towards people centered monitoring frameworks as well as nutrition and wrapping in the entomology into the malaria toolkit. And I will finally just summarize our technical roadmap. So as I mentioned, in addition to these, this health content what we prioritize through the public health community, we're also looking internally at really strengthening our technical processes. And so parts of this include improving the metadata quality, our harmonization, looking at these design principles with our overall implementation team and his team. Also being able to link our generic implementation guidance with the WHO packages, UNICEF packages to make more use of these concepts overall. We are looking, we've made a lot of progress on this continuous integration improved release processes. As I've mentioned, we really do need to make a big focus on ensuring that there's proper translation support. We can move these packages out more quickly to accommodate other languages. And last but not least, we are really looking at the potential for decentralization. So the demand has really grown from the community to be able to use the metadata packages approach to disseminate design throughout these networks. WHO WITEP have done this approach several times for many years for entomology and NTDs. We've been in discussions with PAHO about how can we expand an Isabi's package to really be able to support the countries according to that regional context specific guidance. But we also had many abstracts in the conference this year around other partners using this approach. So one of the things we will be looking at is how can we respond to the community demand and make this a more community-driven product? So I have no promises on the table at this point except to say, we hear you and we see that there's more that we can do to integrate the community into these efforts. So with that, please keep in touch on the community of practice and that's all I have for you today. Okay, thank you to all of our presenters. Really exciting for us to look forward to the future and all the different things we'll be working on. We see there have been a lot of questions that have come up in the chat and in the community of practice we're trying to answer those. So please look for answers. And other than that, we've got to wrap up this session now so that we can switch over to the app competition.