 And we all like pictures, we like to see what's coming, what DHS2 can do. So there are lots of pictures that we'll show about all the new features that are in DHS2. So I'm gonna start by talking very quickly through some of the high level features that we've introduced just in the last year. As Pummold mentioned, there's a big team working on this. We have about 70 people at the University of Oslo that are building features and listening to all the requests that are coming in from all of you for what we need to make this software better and make it more useful for the many, many use cases that are out there. Many, many ways that DHS2 is being used to make health better, to make education better, to make all of the different programs that are so important in all of our countries, have them be improved through digitization. So we'll talk through some of the new features that have come in the most recent releases of DHS2 in the last year. And then my colleague Phil will join me to talk a bit about the process that we have for reporting bugs, for getting issues in DHS2 to the team so that we can fix them and get them back to you, get the software fixed and make it better. And he'll also talk a little bit about the release process and how we release DHS2, how we make sure that we're doing quality testing for each release to make sure that what actually gets into the hands of all of you and is in use in your countries is as stable and as high quality as possible. And then I'll talk a little bit about what's coming next. So we'll start with what is already in the latest versions of DHS2 that has been released in the last year. This is only within the last year, so there's already lots of other features that are in the software that we won't cover today. But then I'll also talk about what's coming next. And that hopefully will be an exciting time to see some very cool features that are coming in the next versions of DHS2. So just to start off, gonna talk a little bit about what we've been doing in the last year. And Phil will talk a little bit more about this, but we've had quite a bit of activity, quite a few things that have come out of the University of Oslo. The biggest ones are the major releases of DHS2. We've had version 39 and version 40 within the last year. And we also had three versions of the Android capture application. So versions 2.7, 2.8 and 2.9. In addition to that, that's not all. We've also released patch releases to all the supported versions that many people in this room are probably running in your countries. We release patches with updates, with improvements, with fixing of bugs. And also in the case of very critical issues where we wanna get something out really quickly, we have hot fixes. And Phil will talk a little bit more about this. So we've had 10 patch releases, 15 hot fixes and many app releases as well within the last 12 months. We'll talk more about continuous delivery and what it means to release apps separately from the core in a few minutes. I also wanted to touch on this and it's a little bit grainy the picture here, but one of the major focus areas for us in the development of DHS2 is to improve the usability. So this means that we wanna reduce the number of clicks and the amount of time it takes for people to do things that are very critical, like searching for a patient. When you have a patient in front of you, you wanna find who they are in the system, you shouldn't need to spend two minutes or three minutes clicking through a bunch of different screens and trying to find that person. So we're working on improving the usability and the experience of working in DHS2, not only on the Android Capture app and searching for patients, but throughout the whole system. This is an area where we're really focusing in our efforts. So hopefully you'll see a lot of small improvements in different parts of DHS2 in the interface that make very big impact on the actual workflows that everybody is doing every day. I also wanna talk a little bit about the continuous release process. So as I mentioned, we've moved in the last couple years to a process where we release applications separately from the DHS2 core. So that means that we can get improvements and fixes to the applications that you run. So that's something like the maintenance app, the dashboard application, the data visualizer application. There are 30 of those that are built into DHS2. Other developers can actually build and share their applications as well. And those are all released independently. So we can get a fix out within a week of hearing about an issue. And you can install it in a very low risk way to all of your actual production implementations as well. So this is a really exciting new way to release applications and fixes more quickly while also maintaining the stability of the core that we need to do a lot of testing to make sure is stable and ready to go. And Phil will talk a little bit more about this as well. Also wanted to touch, but right before we go into the new features that are available in DHS2 on the testing that we're doing. So I'm talking a lot about quality. I'll talk more about why that is a little bit later. But one of the big successes in the version 40 release is our beta test program. And Phil's team is the one that manages this. But we had seven different organizations around the world who have or may support production implementations of DHS2 who actually helped us to test before version 40 was released. So we had more than 11,000 tests performed by all those people on making sure that things work in all the different, many configurations that DHS2 can take. And we had a 96% pass rate, which it sounds like we should be aiming for 100 and we are aiming for 100. But it's actually a good thing that that isn't 100 because that means we found issues before this was released. So we either fixed those issues after we found them or we made sure to document them and make sure that we're fixing them in the next patch release. So this is a really big program or important program that we're continuing to expand with the future releases as well. Okay, so now what you've all been waiting for, the pictures of what's new in DHS2 in the last 12 months. And I'm gonna go a little bit quickly through this. I had to take out a ton of features that we have also introduced because we just don't have time and a lot of them are smaller or take a longer time to explain. But I'm gonna go through quickly about what's new in the system. And we're gonna go through it kind of in order between different ways that you can interact with the system. So we'll start with how you collect data. And this is what's new in collecting aggregate data. There are three different types of data in DHS2, aggregate data, event data and tracker data or individual data. And we'll start with aggregate. So the big news, the big improvement in DHS2 is a new data entry aggregate application. So the previous application has been around for more than 10 years. It's quite a well-used application. There's a lot of functionality in there. It's one of the main things that people do in DHS2 is collecting aggregate data. And so it needed a refresh and we've managed to do that and we've released a new version of the aggregate data entry application. This is in beta, but it will be migrated to full release in the next releases of DHS2. But it has a lot of improvements. So instead of needing to kind of navigate through the system and lose track of where you are before you start to enter data on the form, you always have your context available at the top of the screen. So this seems like a small improvement, but it lets you know that right now I am entering data for Nagellahun Community Health Clinic. I'm entering data for the January 2022 period. I can select which data set I'm trying to enter data for. So in this case, we're entering data for child health, but it might be malaria. It might be a different program. So this gives you a clear idea of where you are in the data entry flow. We also have the ability to filter the org units or the areas where you're entering data based on where this data set has been assigned. So this is something that helps a lot in if you have access to multiple organization units and you're trying to enter aggregate data, previously you needed to kind of hunt and try to find which organization units had this data set assigned. So this means that once you've selected that you're entering data for the child health program, you can very quickly find which organization units you have access to that also have this data set available. We also have a new sidebar which helps to give more information, more context to the data that you're entering. So in this case, you can see actually the graph of the history of values for this particular field, which is fixed organization or fixed facility type less than one year fully immunized child. So I'm entering data there. I wanna see kind of what is the trend of this data over time over the previous time. And also you can see the history of changes, the audit log of the people who have changed this value for this exact org unit and period selection and many other things. But this side panel is available and it makes it very easy to see this while you're still entering data in the system itself. It also allows you to run validation rules and see the results of those validation rules very quickly. So this allows you to quickly see that there might be an issue with the data that you're entering. Maybe it's higher than normal. You wanna make sure that the person that's entering that data knows that that validation rule is triggered so they can say, okay, maybe I need to review this. Maybe it's going to be flagged in the future. I need to make sure that this is the actual, the number that is true. It also works offline. So the data entry application works offline. It synchronizes data. So you can enter data offline and then when you have access to internet, you can synchronize it back to the server. This is something that has been supported in data entry for some time, but we've improved it. We've added the ability to really kind of use modern web technologies to do this in a much better way. We also have the ability to enter data for multi-select option sets. So if you have a data element that you want to be able to select multiple values, in aggregate data for data entry, you can now do this. So this is something that's been requested for a long time and it's coming soon to both tracker and analytics. So those are not available in version 40, but they'll be coming soon. But this is something that's been requested for a long time. So what this might look like is you want to choose multiple colors. This is a very simple example, but you don't want to just choose red, blue or green. You want to be able to choose multiple of those. So you can select multiple values for a particular data element. Okay, moving quickly along, we're going to talk about individual data. So this is the tracker product and entering data for both events and tracker. First of all, this is something that continually we work to improve, but I wanted to point this out, especially as has been mentioned a few times, the important work that Sri Lanka did in kind of spearheading the efforts to address COVID-19 here in Sri Lanka. And then that spread all over the world. We have about 50 countries that are using DHS-2 for COVID vaccination and surveillance. And as part of that, we saw kind of an unprecedented scale of what data is stored in DHS-2, specifically for individual data. So you're starting to track entire populations, rather than just children, for example, you're monitoring or putting the entire population of a country the size of Sri Lanka into DHS-2. And in addition to that, you're having massive vaccination campaigns for the entire country. So you have potentially tens of thousands of people trying to enter data at the same time, or a thousand different clinics. So this is just an example of a country, this is real data, but the country is obscured, of the performance of the tracker system. When we're talking about scales that were previously not seen in using DHS-2, or most health systems, to be honest. So we saw incredibly high speeds of requests per minute that were served by the system, being able to search for patients very quickly, being able to enter data. So 4,000 event data values stored per minute throughout the country. So this is really an impressive scale that we've seen and we continue to improve the performance of the system thanks to these improvements based around the COVID pandemic. The other big enhancement that we've introduced to the tracker product or the individual data product is the implementation of the capture application, which is a much improved user interface for entering this individual data for managing patients and people within DHS-2. So what does that look like? The idea is that it's a very similar user interface. Again, you have the context that's always available in that top bar, but the form is very similar and you have a migration from tracker capture, which again has been around for quite some time, has a lot of quirks and things that are challenging to use to something that is a modern user interface, has modern technology, so it's very easy to interact with and for people to navigate through. Here's an example of that. So this is, yeah, just another, yeah, this is an enrollment dashboard, so being able to visualize a patient enrolled in a particular program and having a view to that entry point into the system. I'm gonna go through these quickly because there's quite a few of them. You also have widgets on this dashboard, so you can see things like the date of enrollment, a lot of the transfers that have happened, so this may be this person started at one clinic and then they moved to another clinic. You can see some of that history here and we'll talk a little bit more about that in a moment. You can also have a dedicated entry point for scheduling events, so not just recording events that already happened, but also scheduling events for the future, which previously those were the same thing. Now that we have a dedicated entry point or a dedicated way to schedule future events as well. We also have a very important concept of working lists that have been introduced to the capture application, so this allows you to see what are the patients that I expect to come in today, for example, or many other ways you can have a working list for someone to actually go out into the community and visit certain households, for example. Lots of ways that this can be useful. We also have the ability to assign events for scheduled events in the future to individual users, so this allows you to take an event that you've scheduled and say, I want this health worker will be the one that's going to do this, that shows up on their working list, then they have a work log for that particular day. We also have the ability to filter these working lists by data from different program stages, so you might have multiple events in a particular program. Previously, it was difficult to kind of filter and say, I only want to see in this case the births that were under 2.5 kilograms of weight, so this allows you to say the birth is one, maybe one stage in that program. I want to filter my working list and show only the patients that had a underweight child, for example. Many other ways that you can use these working lists and the features that we have there, but you can also save these so that you can save a view with some complicated filters, for example, and use that in the future, so you don't have to continually create these filters on demand. And I mentioned earlier that a patient might start in one clinic and then move to another clinic. In the past, it's been difficult to understand kind of if I'm trying to use due analytics on a particular facility, and I want to see a list of patients. Am I talking about the patients that are currently enrolled at that clinic or the ones that started there or the ones that were there at some point? So we're introducing a lot of functionality for analyzing the ownership based on the ownership of the patient in Tracker. And again, I'm saying patient a lot, but Tracker is generic, so it can be things other than patients as well. So anything that is individually tracked. So you can do things like the current enrollment, the organization unit where this patient person was enrolled, where they registered the system, which might not be the same place where they were enrolled in a particular program, where they were enrolled at the beginning of a particular period, where they're enrolled at the end of a particular period. There's a lot of ways that you can use this functionality to identify people that have been at different facilities over time. And I also wanted to point out, this isn't actually a software feature, but we have a very thorough Tracker design guide that's available on docs.dhs2.org. I believe these slides will be shared so you can follow the link. You can also just go to docs.dhs2.org and you'll find the Tracker design guide there. And this is a very thorough and useful resource for how do you actually design a Tracker program and use the Tracker functionality in DHS2 to meet programmatic needs. Okay, moving quickly along again, we're gonna talk about offline and mobile. So we have an Android capture application, and this has been also significantly improved in the versions that have been released. This actually, the features that I'll talk about here don't include version 2.9, which is coming out this week. So we have a new version of Android capture app that's coming out this week. You can find out more about that when the release notes are published. It should be later this week. But these are features that were introduced in the previous two releases. So in November of last year and May of this year. Much more flexibility in how you display and enter data for aggregate data, for example, in this case it's aggregate data or data sets in the Android capture application. So you can resize and drag columns. You can apply color themes to be able to kind of identify values. You can use a legend to actually say, basically apply colors to different values within the system and lots of other enhancements to the usability of the data set entry form. We also have improvements to the sync process, which can be quite cumbersome. If you have to synchronize a whole lot of data every time you open up DHIS2. So it'll actually only load the full set of data that is needed, all the metadata, all of the configuration, all the values that are associated with this particular org unit on the first load. And then it will dynamically adjust the amount of data that it downloads so that it only downloads exactly what it needs, which reduces the network consumption and the time that it takes for people to actually start to enter data or activate the workflow that they're using. We also have improved synchronization error feedback. So instead of just saying that the sync failed and it's very difficult for somebody to understand why, it will tell you that there is a particular problem with the age and years, for example, in this case that you might need to address before you can successfully sync this data. This is a highly requested feature as well, both of these, but being able to collect patient signatures or signatures. So being able to actually use the Android device to have somebody enter a signature, it's then saved as an image and associated with a particular event. So this is something that can be quite valuable for gathering consent from patients. It also can be used for physician signatures, lots of other use cases as well. And you have more deep integrations with the operating system itself. So in the Android ecosystem, you have an email address field. You can now click a button and immediately open the email app on your phone directly. Similarly, a button for a phone number, you can open the phone application and immediately call that person if you have that data stored in a DHS2 tracker program, for example, and similarly for URLs, opening that URL in a browser. And we have many other improvements as well. We don't have time to list all of them here and there are many more coming soon. So improvements to the usability by making the tappable area for different parts of the screen more larger and easier to interact with, the ability to have more feedback from the system, better offline user experience and display of long text, things like that. This is part of the usability improvements that we talked about. And that's the main focus of this last release of Android as well. So you'll see a lot of improvements coming in the release that's coming very soon. This one is really exciting as well. So one of the challenges with large Android deployments with DHS2 is that you have Android devices all over the place and those might be offline, they might be very many different versions of Android and you have to have 10,000 people install an application on their phone. That can be quite challenging and the DHS2 Android capture app is deployed through Google Play, which has automatic updates enabled by default. So unless you have an MDM, which can be a mobile device management system, which can be quite expensive, you have to basically train all of your users to turn off that auto update or make sure that your system can handle those automatic updates happening on a rolling basis across all 10,000 of your users, can be quite complicated. So we've introduced a web application to DHS2 that lets you actually upload or install a specific version of the Android capture app to your DHS2 instance and then your Android users can install from the DHS2 instance itself. So not installing from Google Play, but going to the Ministry of Health, HMIS, DHS2 instance, for example, downloading that application and then they're fixed on that version specifically. And when the administrator of the system then goes and installs a new version of the Android capture app, what's very exciting about this is that the app actually will auto update itself. So it will give you a notification to the user that says a new version of this application is available and you can install it. And so that allows the administrator to control what versions are used by all of the people that are interacting with the system and it doesn't cause any additional friction for the Android user to update their application. So as soon as that happens on the server, they get a notification that can immediately go and update it from within the application itself. This one is also very exciting. So we have a lot of different use cases for DHS2. There are many, many things that are being done with the system. And as much as we try to optimize the workflows and the user interface for the generic product, there will always be things that could be done better if they were designed specifically for that use case. So Breno, my colleague will talk a little bit more about the use case for LMIS. We have developed a real time stock management functionality for the Android capture application and that can be assigned to specific programs. So this is just the first of many specific use case workflows for the Android capture application where you can specify for this program, I want a custom or a different workflow to be displayed to the user. And so we have a use case configuration web application that lets you specify which programs should be assigned to which workflows. And you can, yeah, and then it will seamlessly be available to all of the Android users in your system. So an example of that is this real time stock management tool which I'll leave to the LMIS session for tomorrow to learn more about. But this is one example of a specific workflow for entering stock data that's a little bit different. It's underneath the hood, it's the same data model as all the other programs in DHS2, but there are ways to improve the, and I think we went from 15 clicks to three clicks to distribute some stock by moving to this workflow. So it can significantly improve the experience of the user to do a particular task. And this can be then assigned to specific programs for tracking stocks, for example, in DHS2. Okay, this one has the prettiest pictures. So this is very exciting. We're gonna talk about analyzing data. So we've collected data already, we've collected aggregate data, we've collected data offline using the Android capture application. We've also collected data using the capture app on the web. Now what do we do with that? So we also have the ability to analyze data in DHS2, as most of you probably know. We have a data visualization app. We also have the line listing application to be able to visualize some individual data. We have a dashboard app where you can combine different types of visualizations, including maps, including charts, including pivot tables, including line lists as you'd like in the dashboard. And one of the very exciting features that came out in version 40 is the ability to add custom calculations without defining a new indicator within the data visualizer application. So as a user who maybe doesn't have access to create new indicators or doesn't need to create new indicators for the entire system, they just wanna do some calculation, divide one number by another number, or divide one number by a hundred, or some sort of custom calculation that can now define that in the visualization itself in data visualizer. So this means that you go in and you say what data do you want to use, and you can define, as you can see up on the top right there, you can define a formula for what you want to do. So you can do more exploratory analysis, you can define custom calculations that maybe don't make sense for the entire system, but would work specifically for this visualization. This is not saved as an indicator, so it doesn't pollute your specific defined indicators for the entire system. It's saved with the visualization. So other people that access this visualization will also use the same calculation. We also have the ability to apply legends to pivot tables. So being able to, I'm sorry, this is actually a line list, to apply legends to values in this line list. So you can see quickly kind of which values are high, which ones are low, you can apply custom legends, depending on what makes sense in your use case. But this is much, much easier to read at a glance than something that is just text on a white background. And this helps a lot with being able to analyze that information. And this was one that's been requested for a while as well. We introduced the line listing application, I believe in version 38. Yeah, it was 38. And since then, the line listing application, which is a new version of event reports, has not been able to be included on the dashboard. We now can include line lists on the dashboard. And because of continuous release, this can actually be done, even if you're running 38 still. So you don't need to upgrade to 40 to get this functionality. And this is really powerful to be able to visualize individual data next to aggregate data, for example, in the dashboard context. There's a whole session on maps in a couple of days. So I'm not gonna go spend too much time on maps today. But I did wanna mention this one, or a couple of features that have been included in the maps application. This one is the ability to customize the download and the print of a particular map. So this is very useful. If you're trying to print out a map, you want to define where, maybe some information about what this map is displaying. You wanna make sure that you display the legend, maybe show a context of where this map is actually located. You can define all of that and customize the layout. And then you print a very nice looking piece of paper or a PDF to display this or to share it outside of DHS too. The other big functionality, this isn't actually in the maps application. I'll talk a little bit more about it in a couple of days as well. I'll talk a little bit more on the map session, but is the ability to import data from Google Earth Engine. So we'll talk about more about what Google Earth Engine is and why that data is very useful in a lot of programs on Friday. But this allows you to, for example, import population data from Google Earth Engine and actually calculate the population estimates for each of the org units in your system. So this lets you get very granular with the population estimates that can be helpful in programmatic work. We also have the ability to, yeah, the introduce the ability to import that data. So this actually gets imported as a data element in the system and then it can be used in a custom calculation and a visualization, for example. It can be used as a denominator and an indicator if you would like. And this is something that previously you could have this population information visible on a map, but it wasn't easy to actually use that in data analytics and in analyzing data in the system. We've also significantly improved the performance of analytics. So improved the performance of querying as well as the performance of generating analytics tables over version 35. And I'll talk more about this a little bit later, but you'll see much more improvements in that as well coming soon. I did wanna mention one additional thing. Actually, I think it is not on many of these slides, but I'll talk about it on Friday as well. But Google Earth Engine, we have a relatively new mechanism that's very easy for countries to request access to Google Earth Engine. There's a ton of data that's available there. And usually you have to sign up, maybe you have to pay, but country governments can get it for free if they just send us an email. So we'll, we have a link to documentation. I'll talk about this on Friday. Very easy way to sign up and get an API key or access to Google Earth Engine. We've had a wealth of information on all sorts of things from climate to population to land cover to rainfall to temperature, all sorts of different layers and access to global data sets that can be very valuable. Okay, next functionality is about data exchange. So we introduced a new application or a new functionality into DHS2 for exchanging data between DHS2 instances. So this is really, really powerful. It allows you to, and there are several examples of how this can be used, but this allows you from one DHS2 instance to perform maybe some aggregation of the data in that instance and then send it to another one. So this could be very useful, for example, in this case, from a DHS2 instance that's running tracker to send data to the HMIS. So that the tracker data stays in a separate instance and that you have a dedicated HMIS instance, you can send that automatically from one instance to the other. It can also be useful for global reporting to donors such as the Global Fund or other places where you can actually aggregate and send specifically the data that makes sense from your system to the global system without needing to re-enter that data. So it's automatically calculated, it's automatically aggregated and sent to another DHS2 system. So you send it from a source to a target, it uses the data value sets API, so it's always going to aggregate data, but the source can be either aggregate or tracker. So you can automatically say, count up all of the patients that match this request and then you come out with a number that you insert into the aggregate data model. So this can be very valuable also when you have, for example, programs that are maybe incrementally being adopted in tracker or individual data, but a lot of districts are still reporting an aggregate. You can combine that data by having the tracker data basically automatically aggregated and input into the same aggregate system. So you have in the aggregate system, you have a holistic view of the entire program. And it's very important also where is this? Yes, it's very important also that this can be done within the same system. So it doesn't need to be going to another system if you have aggregate and tracker in the same system or maybe you have a data set and tracker program, you can do that aggregation of the tracker data and put it directly back into the same database as aggregate data. It's also significantly improved performance because you can pre-calculate those program indicators instead of calculating the program indicators on the fly all the time. So this is something that's very, very powerful. We also have a web application for this so you can review the data before you submit it. So if you're submitting to a global donor, for example, you don't wanna just send that automatically maybe, you want to take a look and see this is the data that will be sent in this report. And then you can click submit and it will send right then. If you're doing tracker aggregation, for example, you might wanna do that automatically, that's also supported. So you can do this as a scheduled job that runs once a day, once a week, however you want to do it. And it will run that in the background and do that automatically. But if you wanna review the data, we have a web application to be able to actually see exactly the data that will be submitted and submit that actively. We have a number of other functionality that is related to extending DHS too. And my colleague Morton will talk a little bit more about some of the ability to integrate with other systems and the features that we have there. But I'm gonna go through them quickly here as well. One of those that just helps to interact with DHS too is open API specification. So this is something that has been requested for a long time. The DHS2 API is huge. There's so much that you can do, it's very, very powerful, but it's hard to really understand what's there and figure out how you wanna specifically design a script or an application. So we've implemented an open API specification that defines what is there and it lets you explore in a much, much easier to consume way the entirety of that API. And that's actually generated as part of the development process. So it's not something that we need to keep in sync by writing documentation or that type of thing. It's actually produced by the process of creating DHS2 as software and it makes it always kind of up to date with that. Still things that we want to improve about this, but it's a huge step forward in making it easy for people to interact with DHS2 programmatically. So this is just an example of what that looks like. It has an example of, we were just talking about aggregate data exchange. There's a number of functionalities in the DHS2 API that you might want to use. This tells you exactly what parameters that API endpoint expects, what it will give you back, what errors are possible, those types of things. So it's very, very useful information. We also have the concept of web hooks or event hooks, which Morton will talk about tomorrow, I believe, or maybe it's the next day, I forget, Friday. And this is also a very widely requested and useful functionality basically to allow other systems to react when something happens in DHS2. So if you want to say, whenever somebody changes some metadata, I want to send a notification to some other system so that they can also update their metadata or maybe they do some processing and then they have a subsequent update or something like that. So initially this supports metadata and scheduler. There's lots of different event targets. Morton will talk more about this as well. And we wanna support different types of events that make it even more valuable in the future. This is also a feature that I think we're just starting to scratch the surface of what this can do. It's called the Routes API. So this allows you basically to have a secure way to define some external service and route the requests from a DHS2 application, for example, through DHS2, use the user model of DHS2 to make sure that only certain users can access that external service, that you don't need to share the credentials for that external service with every user. It will automatically apply the authorization that you need and it will talk to that service. It might be a client registry. It might be a COVID vaccine generation service. There's lots of different use cases for this. And again, Morton will talk a bit more about this on Friday. And I won't get into this as well. There's a lot of additional functionality that we've built in and around DHS2 as software to make it easier to integrate with different systems and to build an integrated health information system that involves multiple different components and is a complicated architecture. So we're building out a suite of functionality for integrating and interoperating between different systems. And we'll talk more about that again on Friday. Okay, that was the whirlwind tour of the last year of development in DHS2. And with that, I will turn it over to my colleague Phil who will talk to us about how to report bugs. So if you find issues in DHS2, what do you do about it? And how do we respond to it? And also how we release our software and what we do to make sure that it's high quality. And then I'll be back to talk to you about what's coming next as well. So with that, over to Phil. Oh, you can hear me now. So yeah, I'm Phil and I'm gonna cover a couple of aspects that are a bit more boring but necessary parts of our process. As, yeah, as Austin said, bug reporting and release cycles. So is anyone here aware of any bugs in DHS2? No, we can skip. Okay, I mean, bugs are part of the software development process, we all know that. But they're really challenging and they can cause a lot of difficulty. They can make your job very hard. They can cause lots of frustration for end users and they can damage the trust in the system. So it's very important to us to make sure we address them. But if you say bug to me, I say JIRA. That's the way we track our bugs and make sure that we can actually deal with them. So you might ask, how do I access JIRA? And I'd say go to this URL. That's simple, right? Our team use this all the time. We know exactly how it works. It's very simple. It seems simple, but if you go there for the first time, first you realize you get redirected to this cloud site on Atlassian. Then if you've not been there before, you get, you see various different projects. You have to know to choose the DHS2 software project, maybe. If you don't have an account with Atlassian, when you try and create a ticket, an issue, a bug report, you won't be able to until you create that account. And just as I started to put this presentation together, I realized this isn't well documented and it's not a very easy process. So we need to do better there for a start. And so that's something I think we have to address and make it easier for people to get into the system to see what bugs are there and to be able to report bugs. But once you've reported a bug, I think often you want to know when that bug is going to get resolved. And if you ask me that, I'd say it depends, right? Because it does, it's very difficult. It depends on a lot of factors, the criticality of the bug. So how we classify these bugs, you know, it's based on all of these factors and we have to prioritize, we have limited resources, we have to balance against the development work we're doing and so on. So that's always challenging. But what we should be able to do is let you see the status of bugs and let you see a bit more, have more transparency of our process. Because otherwise we end up with this perception that bugs go to Jira to die. And we know this is a perception amongst many people. And for good reason because there has been a history of bugs not being acted upon or at least it's not visible that anything's happening to them. So I don't want to really use this session to talk so much about how you report bugs, but I want to look at how we're trying to improve this process and to try and convince you that bugs don't go to Jira to die. So the start of this is that we're growing and improving the QA team, the quality assurance team. A few months ago we took on a new QA lead, Alina. She has a lot of quality experience and she's very dedicated to the processes around quality for the whole team. And so she's a great addition and a great leader for our team. We have Geeta who's been around for several years now. We have Hello and Haroon who joined a few years ago. Joseph and Wedega have joined us this year from the Sri Lanka team. So those guys represent mostly manual testing and regression testing components of our team. Then we have Adele who joined us also this year as an automation test automation engineer looking at automated tests and so on. And we have Nancy on the Android testing side. So our team is growing and developing and that also gives us more capacity of course to deal with problems. So one of the first things that Alina started to do when she came on board was to look at this issue with Jira and say, you know, how can we start to solve the Jira problem? And some of those problems were that triaging of new issues was happening more or less ad hoc or when time allowed amongst all of the other constraints that we have. We also had a general sort of unawareness of what bugs we have in the system. There are almost too many. So you lose a bit of visibility. And bugs weren't always updated. So that's a really problematic when the status is not actually reflecting what it should be. So she resolved that we need to move to at least being able to acknowledge all newly created bugs within four weeks of their reporting, which is still pretty slow, but it would be an improvement over what things were. She also wanted to try and make the process a lot clearer and make sure that our team has a better awareness of what bugs we have. And then that transparency can go back to you guys. So we took some very simple measures. One was to make sure there was ownership of triage process and it was consistent and ongoing so that we could keep up with all of the issues coming in. Another one was just improving the dashboards and the way we're using JIRA so that we can actually get better visibility of the bugs and the statuses. Another was using that visibility and working with the development team to make sure they also had the visibility so they can address things and they can put priority and balance things with the rest of their work. And there was also some hard work of rechecking things and getting the statuses up to date and so on, but making that commitment to do so. So when we first looked at this, we had this kind of status. We had 127 in open status on the 12th of July, as you see here, which is a high number and many of those had been there for several months. We have some in needs info, which is where we're trying to get more information before we can move things on. So it's kind of still an open status. We had quite a lot in to do, which is basically the issues which we know are issues. They've been accepted by the team, but they're waiting to be processed. That may always be quite high depending on how you need to balance development and maintenance and bug fixing. But we also had quite a large number of bugs in testing. So this was another blocking point. So both the initial triage, the opening and the testing were two clear bottlenecks that we needed to address. So with these new approaches, with this focus on trying to improve the processes, within a couple of months moved to this second view, where we only have a few issues in open status. We may have still more in needs info, but that's, as I say, this is where we try and get back to the reporter and try to get that additional info that we need in order to process the ticket further. But this really low number of open issues is great. It means we now are keeping up to date on a daily and weekly basis and being able to respond and check and triage the issues, which is much better than we even had a target for with this four-week response time. We still have some in to do, but you can see that even that has gone down because we've actually also worked at processing some of these bugs and putting some effort in that direction. And there's still some work to do on the bugs that are caught in testing, but it's going down. And this has continued to go in this direction since this September set that I've got here. So just the, oh, I don't know, you don't see this. Yeah, here we go. The trend over the same time shows the same picture, basically, that the bugs created is much lower than the bugs resolved through this period. There are some significant peaks where we've resolved quite a lot of bugs. That's because we've had a particular focus of some of the dev teams to go through, move their focus from development and do pure bug fixing for certain periods. And we can see that the really positive impact that this has had in terms of going through and breaking down some of this backlog of bugs. So just in conclusion on the bug side, we're really actively working to try to make this process work better. Okay, so that we can actually deal with the important issues that are blocking you guys. And we're also trying to work to make the bug status clear in Dura. This isn't really in place yet, but we've got ideas to try and simplify the process and just make it a lot easier for you to understand where these issues are in terms of their state and so on. So we do really want you to raise your issues in Dura. It's very important that they're in the system for us to be able to even acknowledge them and deal with them. This is, you know, don't give up on Dura, please put your issues in there. And we do want you to give us as much useful information as you can to help us understand the problem. Otherwise we will have to push back and try and get more information. And it slows down the process. We are looking at ways to try and improve this as well, like adding templates that will prompt you for the right sort of information that we need. But yeah, okay. So moving on to release cycles. I think most of you probably know a bit about how we do releases. So this might not be too much new information, but I thought it'd be useful to step through the types of releases we do and look at the various aspects of why we do those different types of releases. So first concentrating on the core releases. I think we all know we have these major releases. So these are examples of like version 40, version 41 next year. We now try and refer to these as you may know without the two, two dot 40, two dot 41. I may even refer to version 37 instead of two dot 37, but that's anonymous. If you say two dot 37, dot 10, that's fine. If you say version 37, dot 10, that's also fine. But we're trying to move away because the nomenclature helps us indicate the kind of type of release a bit better when we drop the two basically. But it's a long process. This two is everywhere and it's difficult to get rid of basically. So as Austin mentioned, we now we have a yearly release cycle of these major releases. We've moved from a six month cycle. This is based a bit on feedback and our understanding of how implementations plan their upgrade process. We know that that's a challenging thing for everyone, both upgrades, updates of patches and so on for various reasons. And this we think gives a good balance between the speed at which we can bring new features like Austin is presenting and the ability to maintain the older versions. So with a yearly cycle, if we're still supporting three versions, those versions actually maintained for three years before they go out of support, for example, if we continue along this yearly cycle. The focus of major releases is mainly to bring these cool and major new features that require quite big updates to the system. We also fix all the bugs that are relevant for that version that are still applicable to that version. We'll fix those as we fix them in the maintained versions too, of course. There are usually model updates with these yearly major releases, which means it's very unlikely I don't think we've ever had a release where you don't have to have some database model changes. So you generally can't downgrade once you upgrade. And that's an important part of the approach to how you do the upgrades and how you test and prepare for those, of course. We perform extensive regression testing on major releases by our internal team, which also extends to the beta testing program that Austin mentioned. So we try and cover as many of the use cases as we can. But of course, you can use DHS2 in so many ways, you can give it in so many ways, we can't cover every scenario. So it's still very important that implementations test their own use cases extensively before upgrading. Okay, the next type of release are the patch releases. Again, the examples are the next version number. So it's 40.2, for example, 41.1, 37.10, as I mentioned. The frequency of these is supposed to be roughly bimonthly. So every couple of months, it can vary a bit based on certain factors. If we have challenging time testing, if we find problems, those things can delay. If a previous patch release for another version got delayed, it will push on and so on. We may adjust and juggle the order of releases around in order to accommodate critical needs of certain versions under some cases, but we try and stick roughly to this bimonthly release. The focus is maintenance and bug fixing. We do include some new features, but we try and limit those. We try and be conservative so that we keep the stability of these patch releases. There can be model updates, not always, but there are quite often, I would say, model updates even in the patch releases. So also, they're problematic to downgrade. In fact, you can't just upgrade to a patch and then go roll back to the previous patch in most cases. The regression testing we do is much more limited than in the major releases. We have much shorter turnaround time, so that limits what we can do. We try and prioritize on the areas that we test based on what's been modified. We're trying to extend the beta testing process into the patch release cycle as well to increase the coverage, but compared with the major releases, that's just the nature of it. So again, testing before upgrade, very important, your key use cases, run through these in a test environment, make sure it's working and you should be okay. Finally, the next number in the version is the hotfix. So the example is 40.2.1, 41.1.2. If it was the second hotfix of the 41.1 patch, for example, these are created on demand, so we don't plan for these. We do them if it's necessary to get out a critical issue, which is the main focus of these. Critical issues could be things that have impact with data integrity. They could block certain use cases or security vulnerabilities or a key one where we might need to quickly roll out changes. They usually wouldn't include a model update, so it's actually possible to go to a hotfix. If there's some issue with it, you should be able to drop back to the patch below the hotfix. We don't do regression testing. These are very small changes, very isolated. We test around that area. We run what we call smoke testing, which is making sure the system generally works and the different apps all start up, but we don't do any of the regression testing. We want to get these things out fast, but we keep the risk very low. As I say, it should be almost identical to the previous patch, but with just these critical fixes in place. So, do you test before upgrade? Ideally, yes, it depends how quickly you need to get these out, but the risk is very low. So sometimes you will need to be able to apply this this quite quickly. As I say, in an ideal world, you would be able to test this quickly. You'd have a test environment where you can quickly just validate some of your key use cases to make sure they're not impacted. Finally, as a separate thing, Austin mentioned that app releases now have this independent cycle where we call them continuous delivery. So examples might be the Captrap version 100.45.0 or the line listing app 100.10.4, so on. So these have a varied frequency, I'd say, which I'll show in a moment, but we try not to have them too frequent because that's less useful. We try and have more batches of updates, but yeah, they can be typically, maybe weekly, maybe monthly. It depends a bit on the app and how much development is going on a particular app or how much maintenance, how many bugs and so on. The focus is both features and bug fixes. So it's just incremental changes depending on how we prioritize these. You can actually see based on the version numbering, so the sort of second number indicates that features are added, the third, the minor number indicates the bug fixing to some extent. Downgrading is well supported on these. They generally don't change anything. Well, they don't change anything with your data model. They generally can just be applied to your instance and then you can roll back if you want. So there's very low risk being able to just apply the new version on your production system. So just to kind of summarize those things, this is a little kind of view of what the core releases look like over a yearly cycle. We'll go from one major version to another and we'll be releasing patch versions. Usually they'll actually be staggered in terms of like the different versions not all released at the same time, but that's roughly what our kind of plan looks like throughout a year. And there may be periods like holiday periods where you see different sort of times between and maybe a few months instead of a couple of months and so on. And then you've got these continuous releases of the apps going on in parallel. I just wanted to show, finish with this picture of the app releases. I don't know how clear it is actually from a distance, but this is just over the last six months. Each one of these lines is one of our core supported apps and the dots along the lines are the releases of those apps. So this green one is the Capture app, pretty regularly releasing. Up here for example is the Maps app. Here we have the Data Exchange app and so on. But you can see they vary, but there are a lot of releases coming out for these apps. And it's a great way for keeping these things as Austin said up to date and keeping the fixes, getting the fixes in there fast as we need. So yeah, I'll hand back to the more exciting stuff again from Austin. Thank you. Thanks Phil. And Phil thinks this is boring, but it's very important. And I think people were a little bit shy when you asked if there were bugs in DHS2 because we all know that all of those features that I talked about that were added in the last year, that's a lot of things, right? And that's only a subset of what is in DHS2. So the surface area of what we have to test, what we have to make sure is stable is huge. So there will be issues. And that's a, I'm sure everyone has found an issue in Facebook or an issue in Google or Microsoft Word at some point. Every software has issues. And what we're trying to do is really build a process where we can listen to the most important issues and figure out, make sure that we identify them as quickly as possible and get them fixed. So it's really, really is important. But I'm going to talk a little bit about what's coming next for DHS2. So we have a new release version 41 coming in May of 2024. And we've taken a little bit of a step back to focus on these three things for that release. Quality, design and extensibility. I talked a little bit about design already. Phil talked a little bit about quality. We'll talk about extensibility or kind of the underlying infrastructure that makes DHS2 a platform that is extensible and configurable. And why these three things? It's because the footprint of DHS2 has grown so much over the last five years, 10 years even that there are many, many, tens of thousands of people using it every day, 100 plus countries that are using DHS2 or have DHS2 being used. And they're all relying on this underlying platform to be stable, to be usable and effective for the workflows that you're trying to optimize and to be able to be configured and customized for the adapted to the local context and the local use case. So these are really critical things that none of these are flashy new features, right? These are mostly things that are easy to forget about and when we're just trying to push the use cases forward. So it's really important for us to keep these at the top of our mind and also to communicate to you that these are things that are important to us and that we are trying to build into DHS2 to make sure that it is a stable and useful and adaptable platform for all of you. So what does that actually mean? We'll talk a little bit more about it, but there's a number of things that we're gonna focus on. We're gonna focus on stability, making upgrades less painful and less possible to cause problems, limit regressions when we introduce features. So we're adding a lot of quality process and people to our teams to be able to make sure that we can test when we introduce a new feature. We're not breaking some other feature accidentally because there's so much going on. We're trying to also really focus on performance. I showed the graph of the performance for the COVID-19 use cases, but that's just the beginning, right? There are a lot of places where DHS2 is being used in huge programs nationwide vaccination campaigns, more and more programs being adopting DHS2 for individual data, but also aggregate data. Analytics run times are very slow sometimes, and we wanna make that as fast as possible. So really focusing on performance and making sure that the software is fast and it is useful so that you can actually get the data when you need it and act on that data is very important. So that's another focus. I mentioned design and usability a bit earlier, also just quality of life. So being able as a user of DHS2 to have a quality experience and really be able to interact with the system in a way that makes sense, in a way that is easy to train, it's less expensive to train, that it's easy to navigate through the system to understand what's going on. That's something that is easy to kind of forget about as we're constantly pushing and adding new features is how does somebody kind of just interact with DHS2 as an entire product? So that's another area that we're trying to focus on. Consistency is another one that we've made huge strides in the last few years to address is that you might have multiple applications within DHS2. They should all look basically the same, right? At the top level, you should be able to understand that you're interacting with DHS2. You have a way to navigate to other applications. You have a way to log in and log out of the system that should be the same no matter where you are. So really improving the consistency, both of our applications and our pieces of the software that we build on top of the platform, but also what other people build. So there are many developers and organizations out there that are building apps for DHS2, either to customize DHS2 for a particular country or a particular use case or to share and to make it basically to add a piece to the ecosystem that many different countries could use. And so we want that all to be as easy as possible to develop and to build and to maintain, but also to make it a consistent experience for a user of DHS2 that's interacting with many different applications that might be built by UIO, that might be built by a HIF group, that might be built by a country ministry, make it as easy as possible for the experience of the user to be familiar and to be easy to understand and to learn. And the last piece of design here is accessibility, which is making it more easy for people with maybe vision deficiencies or other ways of interacting with software to be able to more effectively use DHS2 because it's being adopted by more and more people. This is very important. And then the last piece here is extensibility. Another way to say this is kind of the infrastructure or the underlying foundation of DHS2. So we talked about continuous delivery. That's kind of a fundamental piece of the infrastructure to be able to release applications, to be able to install new applications, to be able to roll them back when there's an issue, to be able to understand how those applications are being used. We have the app hub that lets us deploy applications as well as other developers in the community to share them. That's all infrastructure that we've built and we continue to want to improve that to make it easier for people to share and to use those extensions. Some of the underlying technology of the platform itself might need to be changed and that might not mean a new feature for DHS2 but it might mean that instead of 10 hours to run analytics, it takes two or it takes one. So that requires kind of a new way of thinking about the technology and maybe some new technologies to be employed. And that requires some effort to get to that point. So that's something that might not seem like a flashy new feature but it will really be a step change in how DHS2 works and how it can be used. And then additional extension points throughout the system. So we've talked a lot about applications. You can build applications, you can share them, you can install them in your system. There are many that we as UIO build and that you can install and update but there are other places that you might want to extend DHS2 as well. Probably Morton will talk a little bit about some different services that might be running on the server side. You wanna be able to kind of manage and share those extensions in a similar way. You also want to be able to maybe adapt just one field in the capture application to be able to, I'll show an example of this, to be able to enter a code and use an external API to look up that code. Maybe to look up a demographic information about a patient from a national ID system, for example. There are lots of additional places where we wanna add extension points where people can plug in and adapt just a small piece of DHS2 to make it fit their needs. And all of this functionality, a lot of that was under the hood but the features that you saw that we built in the last 12 months and the ones that I'm gonna show more pretty pictures of in just a minute. It's all, as Ula mentioned earlier today, it's all a community-driven process for developing this roadmap and figuring out what is the most important thing that we need to build. So we have an annual prioritization process where from the countries to the HISP hubs, this group here today, to UIO, we gather up all of the input that we can to be able to understand what are the most important things that we can build that will have the most impact for the most people. And again, I mentioned DHS2 is used in 100 countries. There are hundreds of DHS2 instances all over the world that are being used at various different scales, various different programs, education, health, climate, you name it. It's a big task to be able to gather all of that input and then synthesize it and try to figure out what is the one or 10 features that we can build that will have the most impact here. So we really want to engage all of you as much as possible in that, to learn about what is missing from DHS2 today that would help your programs improve. So similar to what Phil asked earlier, I would like to just a show of hands. Does anybody have at least one request for DHS2? And anyone have a request for something that they would like it to do that it doesn't do today? I have many, so I'm gonna raise my hand, but please raise your hand if you have something that you would like to do, like it to do. Come on, I've heard requests from half of you already. That's important, right? There are a lot of requests and maybe some of those are the same request and we wanna make sure that if there are 10 people that are requesting the same thing, that's something we should think about and we should really figure out how we can do it. So this is a community different process. We have an annual prioritization process and we also have a public roadmap available so you can see what's coming soon. We're working on updating and improving the information that's shared in this public roadmap, but you can find it at dhs2.org slash roadmap. Okay, so I'm gonna talk quickly about extensibility, but then I'll get into the pretty pictures and the new features that are coming soon. We talked a little bit about kind of extension points and this is something that we're really focusing on to be able to add additional ways to extend DHS2 in a standardized way with performance and security and a lot of other things taken into account. The truth is that an extension to DHS2 is rarely just an application. There's a lot more that goes on to actually make it work and so we wanna build some of the infrastructure to make that possible. An example of this is plugins. So you might know that we have the ability to put a plugin on a dashboard so a developer could build an application, a mini application that lives in one of these squares on the dashboard, but we wanna extend that to other places as well, like in Tracker. We also wanna make improved consistency by kind of pulling out the common parts of the platform outside of the application and being able to provide that in a standardized way. This is an example, just a hypothetical example, but an example of what you might be able to do with Tracker plugins, right? So you have a capture application or tracker capture and you're entering data for a particular program, but maybe you will need to put in an ICD-10 diagnosis or ICD-11 diagnosis or you need to enter data from a national ID and then want to fill in all the rest of this information automatically. How do you do that today? Today it's difficult to do and we have certain value types that are supported but ICD-11 isn't one of them. WHO drug isn't one of them. Those are things that there are many, many different ways that you might want to interact with an external system or to select data. So what this allows any developer to do and we'll build some of these, but others will build them as well, is to customize the experience of just entering this one field or maybe two or three fields. So be able to say, I want to look up this patient in a national ID system or I want to open the ICD-11 coding tool. This is ICD-10, but we're going to show the ICD-11 coding tool. Oh, that's not right. Oh, there we go. Yeah, so it might be a custom experience where you open something that's a very sophisticated search experience. You need to narrow down the diagnosis and then figure out what the synonyms are and figure out what the actual code is for this exact case. That might be a very complicated interface that we don't want to hard code into DHS to itself because it might change over time. There might be 10 different types of coding systems that you need to support. So this extensibility or this extension point allows us to a developer to build something like this, a customized experience just for this one piece. And importantly, they don't need to reinvent the entire data entry flow, right? So they can still use CaptureApp for all of the other data elements. They can still use CaptureApp for the tracked entity dashboard. They can use it for being able to create new events. They just want to customize this one piece. And so this significantly reduces the work and the maintenance that is required to customize something in this way. This is just one example of the types of extensions that we want to support. Another one is Android app modules. So in the Android application right now you can build your own custom Android application. Many people do. You can use our SDK to build it in a more effective way. But maybe you don't need a full custom application. You just want to customize, like we saw and we'll see more about tomorrow, the workflow for a particular program. But the rest of it, so being able to synchronize, being able to log in, being able to select the program, apply settings, all of that, other programs are just the standard workflow. So you want to just customize that one piece of that one program. That's a module or a widget within the Android application that we want to support being more dynamic and being able to load that on demand. Stock management tool is one of those. You might have others and be able to support developers to build just the custom workflow for a single program, for example, and other ways to extend the Android application without reinventing the entire wheel. And there's more coming soon as well in terms of how do we manage a more complicated topology of server architecture. So this is kind of a representative diagram, but there's more that we want to do to support this use case as well. All right, now for the pretty pictures. I'm going to go through quickly. I have 10 minutes left. I will talk through some of the things that you'll see coming soon in future releases of DHS-2. Many of these will be available in May of next year in version 41. Some of them will be continuously released before or after version 41. Some of them will be in 42, but these are all things that are coming soon. They're on our roadmap that we want to do. The first is what the screen that everybody has seen probably a thousand times is the login screen. So this might look familiar, but it might also look a little bit different. So we're replacing some outdated technology in the login screen, but we're not changing the look and feel. So it's basically the same thing that you're familiar with. It's just kind of under the hood. It's a little bit nicer. But this is just one way to log into the system, right? We've seen many, many countries, many, many implementations. They want something different than this. They want to show some logos. Maybe they want to show a video with a tutorial for how people should log into the system or how people should use DHS to. Maybe they need to link to some documentation somewhere or make sure that you have a link back to the ministry website, lots of those types of things. So that's also going to be supported in the new version of the login application. This is just an example of the create account functionality. It's improved from what we had before and obviously this is an optional feature that you can enable or disable. But maybe you want to show a bunch of images, right? So this is something that today you can do, but it's quite hard to do. You have to hire a developer to do some very hacky things to make this possible. This will be supported out of the box. So we'll have a number of themes for the login page with things like show the login dialogue on the sidebar and show a big image on the right. We also have improved support for two-factor authentication, which is increasingly adopted for security within DHS-2. Previously you had a checkbox where you had to say enter a code. People don't really know what that code is. They don't know if they need to check that checkbox. That's gone in the new version. You just like many other services, you enter username and password, you click login and if you have two-factor authentication enabled, you see this additional dialogue which shows enter your code and you can have additional instructions for how to do that, those types of things. But if you don't have that enabled, you never see this. You don't have to worry about it. It doesn't confuse people. This also allows you to fully customize that theme, right? So we talked about themes for DHS-2. You might have the sidebar with an image. This is not a pretty color, especially not on this screen, but you might wanna customize it completely, right? You might wanna have some links in there. You might wanna have, like I mentioned, a YouTube video. You might wanna have custom colors that match your country or you wanna have logos for all the different supporters of this particular project. That's all possible and you can do it without writing any code, without building a custom application. You just either use one of the built-in themes or you design a theme yourself using HTML and CSS. And images. Okay, this is a big one. We're gonna talk about maintenance. So the maintenance application has been around for a long time. There's a lot of power and a lot of flexibility in it, but there's many things that we know we could do better and we're going to do that. So we are launching a new version of the maintenance application, which makes it much easier to manage the extensive configuration of DHS-2. This includes things like bulk editing, which has been requested for a very long time. So you can filter a list of all of the data elements in this case. You can select the ones that you want to do and you can do bulk sharing, you can do bulk editing of that list of data elements, for example. It also has much improved user interface and makes it easier for people to discover where sharing settings are, for example, those types of things. This is just an example of kind of the form that would be used to edit a specific ANC data element. Similar to what we've seen before, but really the bulk editing is the power of that functionality. We also have significantly improved in organization unit management. So this is something that is quite complex to manage because you have a tree hierarchy of different organization units at different levels. This allows you to do things like merge different organization units, to download a set of things that you select, in this case, organization units, to move those from one district to another, for example, move things within the hierarchy. And this is just the beginning of what could be possible with this improved interface. Here's an example of what it would look like to merge different organization units. So you might, you need to define kind of, all right, we're merging these two facilities. What do we do with the data in those two facilities? Do we put those together? How do we do it? Do we delete it all? What makes the most sense? So this is a pretty sophisticated workflow for how do you actually apply this and then the merge actually happens on the server side. So it's not something that needs to be done manually. That's just the beginning. You'll see there's a lot of other types of objects that will be supporting different operations for bulk editing and many more to be able to manage metadata. All right, I have six minutes left. So I'm gonna move a little bit quickly through these next things, but hopefully it wets your appetite and you can come and talk to me more if you wanna learn more about what we're doing here. So now we're gonna move into Tracker. Or sorry, this is a Tracker Analytics. So in the line listing application, we have enrollment and events line lists today. So you can see based on a program or based on an event program, you can see a list of events, but this allows you to instead see a list of tracked entities or people in this case, right? So you might have people that are enrolled in multiple different programs. You wanna show a list of people across those. So you wanna actually list the tracked entities directly. This will be supported. There's another name for this is Track Entity Lime Lists or Cohort Analytics. This allows you to select the attributes of that tracked entity and list those people directly. We also have pretty exciting things coming for dashboards. So you might know that dashboards can get quite unwieldy to manage when you have a lot of them, maybe you have a dozen or two dozen or a hundred different dashboards configured in your system. So we'll be introducing better ways to manage the dashboards in your system. So this is a dedicated interface for managing a large number of dashboards being able to navigate through them and to manage all the different ways to visualize analytics within your system. This also allows us, because that management is kind of extracted to make the actual viewing of the data much simpler and much more straightforward. So you'll see that a lot of the buttons that are there on the dashboard today are gone. This makes it easier. It brings the data to the forefront, right? So you're really just seeing the numbers, seeing the graphs, seeing the maps and the editing experience, the kind of configuration is hidden from the main view. This makes it easier for people to understand and for people to interact with. Yeah, and we also have the ability to kind of highlight specific visualizations on this dashboard and to show additional information about what that is actually showing you, right? So you can highlight, this might be a graph, it might be a map. You can show details about what information is being displayed here. You can actually investigate what is the data that we're seeing and you can also do interpretations and visualize this interpretation so you can share how you interpret this data with other people in the system. Okay, moving on to Tracker. We're significantly improving the ability to refer and transfer individuals between different facilities. So this might be from a clinic to a lab, it might be between two different facilities. You have temporary transfers, you have permanent transfers. All of this is supported and we also are adding the ability to have not only the referral but also the response to that referral. So you have a referral from a facility to a lab. The lab needs to respond and say, yes, I saw this person, this was the result or yes, I accept this person into my facility. That can all be configured in the system and can be performed within the capture application. I'm gonna touch on this, I've mentioned it a few times but we're continuing to improve the usability of the Android capture application. This is a big highlight of the 2.9 release which is coming out very soon and you'll see more and more improvements here. So you can see at a glance these patients and some of the key information about them without needing to click on and navigate to individual pages for each of these patients. You can more quickly search and enroll new patients. Lots of improvements there. We also have the ability to configure complex data exchange between different DHS-2 systems. So I mentioned earlier the new data exchange service and the application for manually reviewing and submitting that data. We now are gonna be introducing just within the next month or two, a application that can be used in any version that supports data exchange of DHS-2. The ability to visually configure that exchange system so that there's a lot of complex things that you need to manage to map between your local system and the remote system to fit to determine how to aggregate tracker data into analytics. All of that is supported in this configuration application. All right, I'm excited about this one too. This is a new way to navigate through DHS-2 as a whole system. So it's an upgrade to the apps menu which allows you to very quickly use the keyboard to search through and find the applications that you care about. But it's not just applications. So applications you can search through today. We're improving the ability to use the keyboard to navigate through these menus. But in addition to applications, we also have shortcuts. So you might be searching for data visualizer or data and we don't know if you'd want to go to the data visualizer application, the data quality application, or to go to the data elements screen in the maintenance app. So this introduces something that was in previous versions of DHS-2 specifically for maintenance only, being able to navigate to specific subsections of that application. But this makes it available to every app in DHS-2. So you can navigate to the pivot table screen of the data visualizer application. You can navigate to creating a new pivot table, to opening a pivot table, to opening a new visualization, lots of things like that. So being able to kind of let people who don't maybe know where pivot tables are in the system, they don't need to know that that is in data visualizer. They just search for pivot and then they find the pivot table section of the data visualizer application. That makes discoverability much better. So this is just an example of a lot of the types of shortcuts that we envision and we make this also extensible so that custom applications can define their own shortcuts. We can continue to add shortcuts over time and it makes it very easy to navigate through the system. We also have commands. So this is really exciting to be able to open contextual help, for example, from anywhere in the system, to be able to define an indicator without leaving the data visualizer application. There's a lot of very cool things that we can do with this kind of fundamental functionality in addition to some very basic things like clearing the cache without moving to the cache cleaning application, logging out from anywhere in the system, et cetera. And this is my last two slides because I know my time is up, but underneath the hood, we're also significantly investing in improving performance and security. So security testing, improved analytics, run times, program indicator performance and management, expanding the beta testing program, having more robust import and export support, as well as, as I mentioned earlier, investing in new technologies and new functionality to be able to significantly improve the performance of databases. We're talking 10X or more, not 20 or 30% faster, improved usability and accessibility and improved ability to build really scalable systems that support huge populations managed within DHS-2. And with that, I hope that you are still with me and have enjoyed the pretty pictures of what is new in DHS-2 and what is coming soon in DHS-2. And I believe it's time for lunch. So thank you all very much. All right, that was a lot of information. And I've just been told by Pamoud that I can take questions. I hope you have questions, but also I know that I won't be able to answer all of them. So please, if you have some questions that are burning from what you just saw here, please let me know and we can talk through them. I will also be around for the rest of the week. So please feel free to find me and I will connect you with the team or answer those questions directly. But if anybody has any questions right now, I believe Pamoud has a microphone and we can, yeah, we can address those questions. Hello everyone and thank you Austin for the nice presentation. Just I wanted to ask about tracker plugins in which version plan to be available and is it support the attributes or only the elements? It's a good question. So yeah, the first version of tracker plugins will be in version 41, which is coming very soon. So we already have an alpha available and people that are developing the first versions of these plugins. The first implementation will be just data elements but then we can pretty quickly expand to other places within the capture applications such as attributes, such as widgets on the tracked entity dashboard and a number of other places. So we're building the infrastructure and we'll have that in place and we should be able to expand it quickly to other places as well. But the first version will be in 41 and also because this is primarily a front end feature it's something that we can continuously release once we have the basic infrastructure in place. So it should be able to be continuously released with the capture application even after the version 41 release. Great. Any additional questions? There must be at least one. Don't be shy. About new features. Anand has one in the front. Yes. So that's actually quite required by many is quite long ago. The reason is to we have to branding our implementation. So if they're all implementations so Bangladesh have five instances but all is the same wage. So no idea is understanding what is inside it. So we want to put some vector graphics or graphics but that should be the low weight, lightweight so that this can be render any places with the low resource settings. So consider as you put the images so make it quite flexible. So whether we can put one side say for example one of the EMR we put on the patient's picture that's going to the hospital in the one side so the login in the middle but whole picture the say that is what this application is for. So that's a definitely good idea. We appreciate it that what you do at last. Thank you. Yes. That's definitely something considering low resource network resource environments is really important for what we do. And this is gives a lot of flexibility so you can define it however you want and you can really optimize for that use case if that's important. Other questions. Any more questions or requests? Box and request new features. I'm surprised there are no new feature requests, no box as there's one more question here. Thank you. This is Najib Ashari from Ministry of Health, Yemen. Regarding utilizing multiple instances and connecting different versions to exchange data. Is there any problem regarding this? Because we are running multiple instances and some are still old instances and we are testing right now new instances, new versions and we are facing some problems. We had to go back and to the old instances. Yeah. Yeah, so it's particularly around exchanging data between DHS-2 systems. The data exchange service that I mentioned supports basically any version of DHS-2 as the target system. So if your HMIS, for example, is on a version that's many versions back, that can be the target of that exchange service. The source needs to be a version that supports this data exchange service for that particular way to implement exchange between DHS-2 systems. But we also have other ways to do it with older systems as well. So there's a tracker-to-aggregate script that has been around for some time that you can use to migrate tracker-to-aggregate data. You can also do similar scripting for between any DHS-2 instance and any other DHS-2 instance. So it is something that we think a lot about. It's especially facilitating the upgrade process is something that is a big focus for version 41 so that you don't run into issues and you can move forward, but also that if you have multiple versions of DHS-2 in your ecosystem, you can integrate them together and you can make sure that they continue to work. So the, yeah, the basic answer, there's more complex answer that we can talk about offline if you'd like. But specifically for the data exchange service, the target system can be any version of DHS-2. We have one more question from Maldives. Hello, I'm Shyama from Maldives. Our question is that in Maldives, we are using multiple programs, tracker-based programs in parallel, but one issue that we have identified is that if the programs are separate from one another, we are not able to pull or push data between two different programs. So this creates an issue for us. For example, we have an electronic immunization registry where the child information is there and we are going to be working with the reproductive health, the ANCP-NC module as well. So some information in the mother and the child, we actually want to form a relationship, but they are in separate programs. So I hope that this could be considered as further development later on. Yeah. Thank you. Yeah, that's a very good example of a request with the concrete use case. That is something that we do have, you can do that, but you need to do some custom development to make it really work at the moment, to be able to do an integration basically between one program and another program within DHIS-2. But it is possible to do that transfer, and maybe Morton will talk a little bit about some ways to do that with some of the tooling that we provide, but it is something that we will be looking into how to do that more natively within DHIS-2 itself, including both improved support for relationships between tract entities. So for example, from a mother to a child, being able to navigate between them more quickly, being able to see some information from a related case or related tract entity from the one that you're looking at, as well as the ability to kind of move data around within the system in a way that makes sense and in an automated fashion. But that's a very good request, so thank you. I think we have time for only one more question. Okay. In fact, it's a request, it's a shared request from the minor region. So it's about the RTL, right to lift, so to support Arabic language in the system. So this is shared from all Arab countries. Thank you. Yeah, that's something that I was speaking with you and your team a little bit earlier this week as well. It's something that we definitely want to support or improve our support for. Translation into many different languages is an important part of the system, right to left languages is something that there are some small tweaks that we could make to really improve the experience for people that are used to, or expecting to see an interface from the right to the left instead of from the left to the right. So we've done quite a bit of investment in that area. Additionally, not specifically for Arabic, but in Ethiopia, for example, and Nepal as well, support for multiple calendar systems, being able to improve that support. That's something that it didn't make it on the slides here, but that's something that is improved in version 40 and is continuing to improve in version 41 as well. Support for localization, translation, and different different calendar systems are all of core functionality within DHSU that we want to improve as well. Future upcoming in this, through the whole parties and where the participants, I came to know that you are the lead of DHSU with this app. That's very good, sir. Sir, my request would be that in all parts of the world, our target audience who are using the DHSU in field, and now it is compelling because it is now digitalizing, sorry, whatever, you got it. So the target audience who are operating on it, the intellectual level varies. They can't be adopted. They can be paramedics. The language is also a barrier. As just asked by the Arabic, it should be Urdu as well in Pakistan. We are seeing in software for different apps. There is every country, but there is no Pakistan. There is no Urdu. So Urdu is for the India as well as for the Pakistan. So the more it is easy, it is easy, but it's in the English language. My point of concern is that it should be for the user who will be using it in the field, where their educational level is not so high. The words or the data in which we are interested might be misled. DHSU is a very open form, and we are hoping that with this, we will be entering into a new era where the data will be more accurate rather than the previous DHS. So my request would be keeping the audience in mind. It is a comment. It is not a question. And the last part of the comment would be that when are you coming to Pakistan so that you should have the hospitality of the Pakistan? I appreciate that very much. So a couple of your points really resonated with me. Number one is translation into many different languages. I don't know, Phil, if you know the number of languages that we have supported them. We have more than 40 languages supported in DHSU at the moment, and we really rely on the community to help to do those translations. So for Urdu, for example, I would love to get the teams involved to help to make sure that that translation is available because we have the infrastructure in place to translate into many different languages, and we'd love to support as many as we can. But I don't speak Urdu, so we need to bring the community together to really help with that translation into all the different languages. So that's absolutely something that we would love to work on. Yes. Yes, exactly. Yes, thank you very much. The last point that I wanted to make, which I think is very important on this in general, is that we're really investing also in user experience research. So actually going on the ground, talking to people who are using the system, who might be a clinician at a facility and understanding how they interact with the system and how we can make it easier to understand in their local context and easier to use and more efficient to use. So that's definitely something that we're investing in quite a bit. And with that, I think it's time for lunch. So I'll turn it back over to Pamela. Thank you so much. So as Austin mentioned, it's time for lunch. But before that, so we did rounds of introductions of all the Ministry of Health participants in the morning, but we had one team who arrived a bit late due to all logistics related issues. So we have Ministry of Health Kirgistan team here. Can we see where they are seated? Yes, we have the team there. Yes. Thank you so much and welcome to Sri Lanka. All right, so it's lunchtime. So lunch will be served at the back of the hall once you exit those two doors. So you can serve your lunch and come back to your tables and have it. So it's time for lunch and we are going to start the next session for the post-lunch session, sharp at 1.30 p.m. local time. Yeah, so we have around roughly 45, 40 minutes. Yeah, let's try to stick to time and we will be starting at 1.30. Thank you so much. Yes, and feel free to trouble Austin and Phil during lunchtime. So yeah, they're happy to answer all your questions.