 Let me just start by saying it's been really tremendous to watch all the beautiful presentations that we see in this week. It's just really amazing to see all the use cases and the domains and all the different fantastic work that's being done. When you look back in time, you actually start to realize it's been a while, like we've been doing these tests to you now actually for 17 years, time flies as you can say. So today, Austin, McGee, and myself, I'm Lars, have the honor of taking the opportunity to kind of look back a little bit on the history and reflect a little bit about what is happening and also about some of the lessons that we learned over the years. And then after that, Austin is going to talk about the future. We're going to look at what's next for DTSG. We have a lot of exciting new solutions and new ideas coming up. So stay tuned for that. So to begin with, I'm going to have the very difficult task of explaining the history of these tests too in five minutes. Probably cannot be done, but let me try. And one of the key messages here is that it hasn't really been the way it is now all the time. This is pretty new. The way things are now with product managers and solution architects and JIRA and CI pipelines and things. It didn't really used to be like that in the beginning. So the very first implementation of DHSG actually took place in Kerala in some Indian states back in 2006. And it was done by Hisp India. And the systems were very much standalone. This was before we had even internet in India. So everything was offline. The system was basically then written on a CD, a rewritable CD, and then shipped by motorbike to all the health facilities. So people were driving around and installing CDs in the health offices. Even had rewritable CDs, I can remember, because every time there was a bug, you had to write a new CD. Then you had to go and install it. So I think it's safe to say that the whole thing was a lot more laborious now back then than what it is now. This was also the first developer workshop that we had. And the core team, well, the core team is actually what you see on that photo. I don't know if you can recognize some of these people. We have Abhiyath on the left. He's been a fantastic person for DHSG over the years. Bina from the beginning. We have Bharat, who was the lead developer of Hisp India at the time. And then some other guy on the side. I don't know who he is. Too much, can't even recognize him. And on the left there, we have the one and only, John Lewis. I don't know if you count as developer John, but John has been very instrumental. Also, John told me to say that that bottle on the photo has nothing to do with John. That was not him. All right, so from India, we moved to Salion. So Salion was really the first African country where we implemented DHSG. Once again, it was standalone. Deployed on district servers. And at the time, there wasn't any kind of fancy, you know, web apps and dashboards and visualizations and these things. We only had data entry. We could create the elements and organets and look at dataset reports. That was it. Maybe download the PDF. That's what you could do at the time. So we had trainings. It was less to train on. We had, as you can see here, like data entry screen. That was, it looks very much the same as it does now, even the data entry module, I will say. But everything else has changed. And once again, the data was really then sent offline. So we had to basically then drive around to every district by car, by a Land Cruiser. And then you had to drive to a district. You made an export in XML and then took it down to your own laptop. You upgraded the war file. You got some feedback from the users. You did some training. And then you started driving again to the next district. So needless to say, I was quite laborious. And data timeliness suffered a bit from all the driving. And of course, in recent times, Sierra Leone also has now decent mobile internet coverage, so things have improved. Then we moved to Kenya. So Kenya was really the first large-scale, web-based implementation of DHX2. So this was the first national-scale DHX2, I would say. And I would actually say that the timing was on our side. During those years, the mobile internet really took off in East Africa. So Jörn and I and Ula, who's just coming here, we traveled around in the districts in Kenya. And we saw that people were entering data. When the Wi-Fi went down, people just picked up their dungle from their pockets, put it in their laptop and continued working as if nothing happened. And we were just amazed. And we thought, this is very good for us. This is a good timing. So we managed to actually then customize and roll out DHS2 in Kenya fairly quickly for aggregate data. And within something like six months, people could actually then just enter data and look at reports. I will say that during those years, we had nothing like we have now in terms of CI pipelines and Q&A teams and beta testing and whatnot. We usually joke that we talked to the end users in the morning. We developed features in the evening and at night. And then we pushed the production at midnight. And then you made our silent prayer that things would work in the morning. So yes, very agile at the time, maybe a little bit too much. And then Uganda took on DHS2 and Rwanda and Burundi in all these countries, Ghana and South Africa. And then the ball started rolling essentially in a lot of countries in Africa and Asia started to use it. So we're going to leapfrog a little bit. Then in 2013, we got interests from a huge organization called PEPFAR that looked at DHS2. And we also have Mark, who's here today with us. He has done a fantastic job steering the information systems of data of PEPFAR. And PEPFAR took interest in DHS2, I will say, because it was used in so many countries, right? So many countries used it. And they thought, hmm, it might work for us. So we had a couple of years where there was a lot of work. Day and night to adapt DHS2 for PEPFAR. We called it Datium for PEPFAR. A lot of aspiration and a lot of perspiration, as Mark likes to say. And I think today, PEPFAR is used by something like 35-ish countries, something like that. Yeah. So that was a huge... We even had trainings in Johannesburg. The apps went ready. We developed apps at night and demoed in the morning. It was very stressful. All right. So around 2014, this is when DHS2 really started to become what I would call a global standard, right? So we had lots of people like traveling to Geneva, and Kristen and Ola, and Knut was even in secundity. We even gave Knut the doublet show for a while. He worked there. And that ended up with a official like collaborative center agreement with the doublet show. We had many people, Ola, Prosper and others, traveled to Atlanta to meet with the CDC. We have worked a lot with CDC on the global health security agenda. Other organizations, even Google, show interest, send us an invitation for their Earth Engine workshop. And Bjorn made this amazing presentation yesterday or the day before where he showed all the cool stuff we can do with the Google Earth Engine even today. So that has been really a fantastic collaboration. And then we had the DHS2 symposium in DC in 2014 that really kind of exposed DHS2 to the NGO community. And then NGOs started to become aware of it. And then the bolts started rolling also on the U.S. side. UNICEF also started adopting DHS2. All right. And since then, I would say the rest is history. As we've seen this week, there's so much going on. I think you guys know much more than I do about what's going on these days. Too much to cover in the rest is history. So with all this history, I think it's time to kind of reflect a little bit on the lessons learned, like what I've learned from all these years. And I'm going to focus mostly on the software design now. I'm a software engineer. So I'm going to focus a bit on the software design there. So obviously like generic design, accessibility in apps has really been critical for us. So we like to talk about like generic design as a success factor. So when we went to Kenya in East Africa, we quickly learned that a lot of the countries in East Africa, they had the same challenges. We went to Kenya, sold a lot of problems, went to Uganda, faced a lot of the same problems, went through Rwanda, same problems. And we saw that there was a lot of potential for reusing the same software. Like you should not go back to scratch and build new software for every country. That would be very dumb. So we decided that you should try to make it very flexible, generic, reusable, so they can build on what's there and take it forward like that. The good thing with being generic is that it really reduces maintenance costs. I think today it would have been totally impossible to support software for every country from the core team side. That would have been unmanageable. So we decided to make a generic core software that could be used. The other thing with generic software, I would say, which may be a bit underappreciated is that it really accumulates best practices, knowledge, and solutions. So when you go to one country, you work through a set of problems and you sort of solve the problems, you have long nights, you work hard, you figure it out. When you go to the next country, that problem is more or less solved. Right? And then you solve another problem in that country, you move to the next one. And in that journey, you really kind of accumulate knowledge and solutions. So the kind of the solutions are transferred country by country. And today I would say, when countries today start to adopt these as too for like, especially for aggregating events, it's fairly easy, right? They can get up and running quickly and start using the software because a lot of the problems and the challenges are kind of already solved. This of course still problems, but the foundational ones are solved. And I will say like generic design, of course, has the context dimension where you can use it across countries, across domains, across use cases. You can also then think of generic design in a time dimension. So as you know, like everything tends to change over time. There will be new data sets. There will be new programs. They will, you know, forms will change, new requirements. You go from aggregate to Vingio. The good thing with being very flexible and configurable is that you can do all this without having to go back to the dev team and ask for changes in the software. You can do it yourself with the configuration. And I think that has really been a critical success factor that even as time goes by, you can still do a lot. Yes, of course, there's new features to be built, but you can change the system fundamentally. Super quick history. I'm going to be brief here now. Super quick history of the design. So I will say that back in 2010, we started to have this generic thinking, but there was no API. You know, there was no custom apps, no app platform. There was no way of, the only way to get the data out, you have to download to Excel. You know, so take on Excel and do whatever you wanted with it from there. Which made it very hard to extend the features and hard to kind of integrate and extend for local customization. So the only way to do this was to basically fork the entire scene. So you took the entire software, made a copy of it, and made some changes. And even in India, I remember that they had almost like one DSH2 for every state, which, you know, needless to say, got very hard to maintain. So we thought that we have a legendary discussion in Sandsibar, I think Ula and I smoking some water pipe or whatever it was at the time. Nothing else. And we started thinking that we really need something that could expose DSH2 to the world, right? So it's not like a product. It becomes something that people can build upon, right? So we decided to build an API in hindsight. I mean, this looks obvious, but APIs went really hard at the time. You know, this is like 11 years ago, 13 years ago or 11 years ago. So it was like slightly novel at the time. Sounds obvious now. And then you had, you know, Morten joined us. You had, you know, very good developers joining us, building up the team. We made the API more comprehensive and we started around 2016 to see more web apps being developed. So people now started to make, you know, custom apps. Which was great. Only thing was, it was very complicated at the time. Time-consuming. There's still fairly low quality, no consistency. Everyone basically picked their own framework. So like whatever framework people preferred, they would pick. And the result was that the apps looked very, very not uniform, right? It was very different. No common-looking feel. It looks kind of amateurish. So we decided or often came and joined us in around 2019. And I think his first reaction was, oh my God, what's going on? What are you guys doing? We need some consistency here. So he came up with this idea of the app platform. So the app platform is really kind of the the platform for building web apps. It brings some, some structure, some rigidness and a common way of building apps. Same framework, same style. So with this, the apps are now slightly starting to become more uniform. The quality goes up and cost goes down because now people don't have to spend two weeks just figuring out how on earth am I going to approach this? You know, it's kind of given. So that helps. And we see from, from around 2019, we see that most complex implementations now do custom apps. For every major country, there's now starting to become apps. So the thing is that even though in our apps, I would say, it's a huge success overall, it can be better, right? Can be better. I think it's still complex, still a bit costly to build and maintain, still break. So what we're working on now is really to create a shed and reusable UI component library so that instead of having to reinvent the organetry for the 100th time, you can basically then take the organetry that we built and use that one to avoid kind of reinventing the bill. We also would like it very easy and cheap to build apps. It just shouldn't cost a lot of money and take months or years. It should be quick. So we now would like to make it very fast so you can build custom apps that can even be thrown away when you don't want to use it anymore. The other thing we're working hard on is to allow for custom back-end micro-services, right? This is to support what they call data-intensive workloads. They're just saying that when you have a hammer, every problem looks like a nail. And I will say without mentioning any names or anything like that, that is true for web app developers because if you are a web app developer, you think that everything should be a web app. And the result of that is that people build data-intensive applications as web apps and they shouldn't really be. They build integration jobs as web apps and they shouldn't really be. So what we're trying to do now is really to support what we call custom back-end micro-services where people can build apps on the back-end, things that belong on the back-end, like integration, data processing, and computation that should sit on the back-end. So that is coming, as I like to say. Okay, super quick on the methodology. So software methodology. You know, and if you've been around in IT for some time, you know that many people are very dogmatic. They will tell you that, you know, you need three-year plans. You know, all codes should be tested. You should never break an API. Quarterly releases is the best. You know, the people are very kind of opinionated about this. But I would say that in our opinion, and on the Disha's side, is that software methodology is more of a strategic choice. You should really think of it as a strategic choice. And it definitely relates to the face of the platform and it has trade-offs. So the trade-offs is always between like long-term planning versus being very responsive. It's hard to be both, right? It's hard to have a five-year plan and react very quickly when someone comes to you. Having very long-release cycles versus having short iterations, there's benefits and downsides with both. Testing in Q&A versus features, like how much time do you spend on features? How much time do you spend on testing? And also how much time, how much do you focus on stability versus focusing on rapid change? Those are trade-offs to be made. You can't really have both sides here. So that's why we should think about this from our statistics side. So I would say that for DHS2, we really have more or less three phases. You have the startup phase from the very beginning until like 2013-ish where we were kind of in startup mode. Some people say we still are. So in the beginning, we really focused on building the right solution, right? We didn't really spend a lot of time on testing in Q&A. We really focused on building the right solution. We focused on rapid prototyping, generating knowledge about what people need and what people want. That was the key focus at the time. And really like when you're starting out with something in Discord, I would say goes for any product. If you're building something else, it's really about understanding what the users need and want. That's the top priority when you're starting out. Don't spend a ton of time writing tests and pipelines and things because if you have no users, it doesn't matter if your software doesn't have any bugs because nobody's going to use it. You're going to run out of money and your project is going to go away. So that's why you need to focus on building knowledge about what people want. And you do that with prototyping. Next phase, around 2013-ish, this is what we call the growth phase. So this is when we went slightly out of startup mode and now starting to kind of grow the software. And the idea now was really to make the platform useful for many, right? So at this phase, you really would like to make it useful for many and scalable. It doesn't really matter if you have a beautiful system, if it's used by five people, like nobody's going to care. You'll be the best system in the world. So now you need to focus on scale, like make it scalable, make it possible to run at the country level and make it possible to run even at the global level. So in this phase, it's really important that you still need to accept breaking changes. I remember that we had a lot of complaints. People came and said, you guys, you're terrible, like you break the API, you're breaking our apps and integrations. And he said, sorry, but we actually had to make a data model change because we learned that it's the right thing to do. So instead of then saying, okay, everything's going to be stable, you need to actually allow for some change and even upset some people. You just have to live with it. I know from experience, it can be hard. And then the last phase where it's, I think we're in now, which is what they call global adoption. This is now, when people are starting to say, that this is the biggest, most implemented system in the world and all that, then you can say that, okay, we reached global level now. And this is where you would like to slow down. You need to slow down, focus on stability, focus on testing. Now you can't do radical changes anymore. You can't do crazy things. You need to slow down and slowly start to focus on testing, slowly cycles, more Q and A, more focused on pipelines and CI, stability testing, better testing. And I still thank the guy upstairs that we have Phil join us around 2018-19. Phil is our Q and A manager, has really brought a lot of rigor and testing and culture assurance to the team. So we're very happy for that. Okay. We can skip ahead a little bit. So let's talk a little bit about the software strategy for, for DCS2. So with DCS2, we really, we tried to really have a deliberate strategy from the very beginning. And I would say that a foundational piece of the strategy really was to have a strong core developer team. Right. So the good thing with having a strong core developer team is that you can really have an overall vision and holistic plan for the software. It allows you to build the product that you would like to build. You can have a holistic, cohesive plan. We know of other systems in this space that rely more on community contributions that, you know, people in different countries and teams and so on submit patches. We think that that is problematic because it then really leaves it up to the community to decide what's going to happen. And it's very hard when you sit in one country to understand what to do from a global perspective. We know that's very hard. It's very hard to have a global perspective when you sit in one particular country or organization. So we believe that having a strong core team is really critical for having a software that's cohesive and have a holistic vision behind it. And at the same time, as you talked about many times, we would like to make it very configurable and generic. So by making the system configurable, generic and kind of adaptable, we allow implementers to really configure it to the needs. There's no need to go back to the web team to kind of ask for something all the time. You're not stuck not being able to do what you want. By having a really flexible system, you allow the implementers like the non-technical or semi-technical implementers to basically adapt the system. And of course, designing the software with extensibility in mind, that's been absolutely critical for us. So what that means is that you can now allow the system to be integrated with others. You can build scripts as Prosper talked about in the morning. You can have scripts, integrations, widgets, plugins, name it whatever you want, custom web apps to go the last mile, to kind of cover the last mile in the country. It's very hard to make a generic software that supports the whole world, right? You do have to allow local teams to customize, to go the last mile and make it really work in the context. And to do that, you always have to do some local work. So that's what we're trying to do deliberately in the whole architecture of the software. And of course, we have seen this week that even from Oslo, we're trying to really support a capable community of local developers. So having the combination of a strong core team with a very capable set of local teams in countries is a very powerful combination. We've seen so much innovation, you know, Tanzania and South Africa and Ghana. I'm probably forgetting many now. I've shown us really amazing stuff this week. Local apps, innovations, integrations and whatnot. So it's clear now that this approach is working. Like we can see so much good things coming out of the country. So I'm really, really impressed with all the stuff going on now in the countries. So how does this translate then to the architecture? So all this strategy, we're trying to inform the architecture, right? So this, what you're looking at here is really like a very high level overview of the architecture of these two. A bit simplified, of course, but from a high level. So what you see in the blue part there is really the core platform. This is the backend core DSS2 platform that stores the data and has all the business logic, et cetera. The white areas there are what enables this extensibility and integration. So we have APIs. We have the app platform. We have web hooks. We also have other things that are really the enablers of extensibility and local customization. So these are the things that allow you to kind of plug in an extent. Of course, we also have core web apps. So there will be core applications like the data entry and the maintenance and data visualizer and all these things that you know well. We do believe that it's very important to have a strong set of core web apps at the same time allowing for local web apps to be built in the context. So then around this core architecture we then see that we can have local apps and local integrations. So that's local teams in countries are able to build their own web applications, their own Android applications. The Android app has come a fantastic long way now. We can see thanks to Marta and Jose and the team, really a fantastic job. It now has an SDK. You can build your own apps on top of the SDK. You can plug in new domains, new modules and whatnot these days. It's become very sophisticated and it really also enables people to build their own Android applications. Same with integrations. People can now build their own integrations. We've seen numerous examples this week of people integrating systems. Now it's happening everywhere. So people are using the APIs, the HUEB hooks and so on to integrate with other systems. And this is, we like to say, this is by design. This is what we try to do from the beginning to build a core platform that's possible to extend and build out in the local communities. Okay. So a couple of other points on how we think about software. First of all, facilitate the entire data flow. What this means is that this is to allow you to capture data, import data, manage the data, and also analyze and visualize the data all in one thing. Some people call it a boombox. You know, it can do everything. I think we also seen this week that we now see more and more like data lakes, data warehouses, data integration systems being used, which is very cool to see and it's happening now these days. But for many countries at least going back some years, I think setting up this kind of data lake architecture with data pipelines and joining of datasets and that stuff is quite complicated. It's not trivial, right? And many people struggle, even them all over the world. Many people struggle with that. So allowing people to do the whole lifecycle of data in one platform has really been helpful for us. Data entry, imports, validation, analytics in the same place. Now we see that it's becoming more of a kind of more broader architecture but that's just very, very interesting to see. Open source license, of course, has been critical. I have to be honest, we don't get a ton of contributions. You know, like it's coming in lots of patches and so on. That's not really been the major benefit. I would say the main benefit of open source is that it reduces risk of project financing. You know that many projects are time-bound, of course. So with these charts too, even if you're running low on funding for a while, you can still keep the lights on, right? You can still keep the lights on because the software itself doesn't cost anything, hosting costs, etc. But the software itself doesn't cost anything. So it also then removes the procurement and licensing process. If you're going with the proprietary software, one, you have to pay for it. But B, you also have to have a process, right? You have to procure it. There's got to be contracting. You've got to acquire licenses. You've got to install licenses. It's just so much more inconvenient to do. With these charts too, you just download and install and you run. And that's really been helpful for us to make it simple to operate. Scalability, of course, is important. We always try to think scalability first, right? Many systems tend to do low-level individual data. They don't really... They work very well in a couple of districts, but it don't work so well in a country, right? So if you try to use a system that's developed for a few districts, it typically doesn't work so well at the national scale. But so we try to make it work at the national scale and even at the global scale. So you can take the software, run it in Bangladesh, or you can run it PSI runs in 60 countries, and so on. You're trying to think about scale before focusing on complex features. And finally, hosting anywhere. So with DHS2, you have a wide range of options for hosting. So it's not like it's only in the cloud or only on-prem or desktop. You can choose. So DHS2 can be hosted on-premise in a local or government data center. It can be hosted in the cloud, in your own cloud accounts. And you can also sign up now for managed hosting in the cloud. There are multiple providers of managed hosting of DHS2. So you can, if you just want to click a button, you can do that also. So this kind of breadth of hosting options has also been critical. Okay, we're getting to the ends. We're getting to the ends. So a couple of, just a couple of design principles that we have behind the DHS2 software. There's a ton of software principles, obviously. So I'm going to just pick, pick some of my favorite principles here. So the first one is that real user needs and input really are the foundation of product design. So listening to users is really the foundation for everything. I think we all agree. Like if you don't have users, if you don't listen to them, you're not really having a system. If you're sitting somewhere else in a meeting room trying to make up your requirements, it's not going to be very successful. So you need to have users, you need to listen to them. That's number one. When that's said, I also want to say, since I have people's attention, that you should tell us your problem and not your solution. This is something we see a loss. So people come to us and say, you know, like I would like, you know, custom forms in Android, right? But then as system engineers, we always try to think, but why do you need custom forms in Android, right? And then people start to say, oh, because I would like to have these colors and I would like to have, you know, fields in this order, and I would like to have a table of things, right? And then it's like, okay, so that is your problem. That is your problem. You would like to order the things differently. You'd like different colors. Let's work on that. And then we can go back and design a solution that allows you to do that in a different way, that might be better, right? So when you give us feedback, we sincerely appreciate the feedback, but try to tell us your problem and not your solution necessarily. And again, I just want to mention that sometimes it's quite hard to also be a core team because we get a lot of requests. You know, people come to us and ask for many things. Now that we have apps, it's become better because people can build things themselves. But from our perspective, also we have to be a little bit careful that if you try to please everyone, you're not going to really going to please anyone. So differently, if you say yes to every request, I think the reality is that nobody's actually going to use your platform 10 years from now. We try to keep the software a little bit simple. Like we try to not overwhelm it with a million features because if we add a million features, it's going to be too complex. And one day you're going to say, this is too complex for me. I give up. So when you talk to us and we say, man, maybe not. That is typically why we say because in the long run, it's very good to keep the software simple. Which is the last point? Start simple. We always try to start simple. So when you build new features, when we build new features, we always try to keep things simple. Like in the first iteration, we don't add too many things. If you add too many features, if you make it too complex, the chance is that you're making too many assumptions. You're trying to starting to guess what people need. And when you make guesses, very often you get it wrong. And the risk goes up because now when you're building things that people don't really need, you have to go back and change it and people get unhappy. So that's why we strive to keep it simple. All right. And that's it. It's nice for listening. I think we're going to move it over to Austin now. I just want to say, Austin has taken over the lead developer role now recently. He's been doing a really tremendous job. He's doing hiring and recruiting and proposals and software and team management and whatnot. It's been really good. I think you should give Austin a good round of applause. Don't leave yet. Thank you, Lars. But don't leave yet because I have the great misfortune not only of following Lars on the stage here, but also as the technical lead of the project. So whoever is willing, please stand up and give Lars a huge round of applause for the last 17 years with DHS too. Come on. Don't worry. He's not leaving yet either. We're keeping him in around as much as we can. Thank you. Thank you so much. Thank you all. And it's not like he's left, you know? So, you know, he still continues in a capacity advisor and he will continue to advise us in a 20 percent. Okay. Yeah. Lars is handing the reins a little bit as the lead developer, technical lead over to me, which is a challenge that I am trying to do my best to step into, but I'm very appreciative of him also being on as an advisor as we continue. So coming from three people in Kerala, India, building DHS too, this is a screenshot from the DHS2 website, great new map that was put together by Bjorn and Max's team and communications, showing all the different use cases and all the different countries where DHS2 is used. There's more than 100. Probably this isn't even a complete list. I think there are several that are not yet in that database because it is free and open source software. People are using it all over the world in ways that we don't understand. We don't know. We can't know because it's somebody downloads it and uses it as the national system in their country and tells us three years later when something breaks. But if you go and see yourself on the map, you can send us an email and we'll add you. If you don't see yourself on the map, go to the website, go to the inaction section and you can look at the different categories, share your stories also with Max. There are great impact stories from a lot of different countries on there. But we now also have a much bigger team. So from three people in the room, kind of writing code at night and pushing to production in the morning or sending it on a CD, on a motorbike around the country. We now have more than around 60 people on the core software team spread all over the world. It's a remote first team, so a lot of them are watching online here today. And that's been a big change and it also helps us to push things forward while also building in the stability and the foundation that DHS2 provides for all of these different countries. And one of the ways that we address kind of the trade-offs that Lars put in his slides where he mentioned that you have to choose between either slowing down releases or moving quickly and innovating quickly. You have to choose between stability and agility. And that is true, but we're kind of cheating by building this platform for extensibility. So the core and the foundation is moving into that global adoption phase where it's the foundation for so much that all of you are working on around the world. And that needs to be stable. That needs to be rock solid. And we need to do a lot to make sure that that has all of the core functionality for usable software, a usable platform that it has no bugs, that it has performed as well as scales go to huge, huge numbers in many different countries. But it can also be at the foundation, the platform for innovation. And that innovation is something that we do by developing different applications, but mostly it's what all of you do. And there were a large number of very high quality applications that were submitted to the app competition this year. It was a very difficult choice to choose the finalists that you'll see later today. And so we want to enable that type of innovation, not only locally, but also to share those innovations and use them across different countries. So we were able to kind of cheat by building a platform that is stable, but also provides the foundation for agile development and iteration. So how are we going to do that going forward? I'm going to talk a little bit about what's coming next for DHS2 as a platform. Extensions is something that is the next step beyond applications. So we have web applications and Android apps. We have the app platform. We have the Android SDK. But very infrequently, I think, is an app, a web application enough. If you have that hammer, everything looks like a nail. You start to build integrations and you start to build data processing in web applications, which is not the right place for those to be. So really to enable the full spectrum of customization and adaptation of DHS2 to different contexts, we need to build the kind of the primitives, enable those primitives to be used in those extensions and to be built. So that includes extending the API, extending the data model, having custom configuration that is shared between different countries and contexts, having applications, having plugins that let you put extensions in certain places in DHS2 and not having to reinvent the wheel and build an entirely new application. And especially integrations also with other systems as there's more and more heterogeneous and complex architectures in health and other domains as well. So this is where we're going. There's a lot of ways that we can support this and we'll talk about a few of them. One of those is plugins. So we for a long time have had the ability to build plugins on the dashboard. We're expanding that capability, making it more secure, more performant, allowing you to bundle a plugin with an application that's already available in version 239 and 40. But there are other places where we want to enable extension points in DHS2, enable people to extend just the part that they need to customize for their particular use case or their particular context. So that includes on the tracked entity dashboard and the capture app in data entry with what has been custom forms, being able to enable customization and adaptation of those forms and interfaces for a specific context. It includes Android application modules. So you can plug in, as we saw with the real-time stock module that was demonstrated in version 40, you can have modular, modularization of the Android application and be able to replace the specific parts that you need for a particular program while still keeping the rest of the great application that's there. And many, many other examples as well, potentially custom map layers. We'll look at where we can add additional extensions. Another way that we're looking at approaching this is by moving to what we call a global app shell. So in the development of the application platform, we introduced the concept of an application shell. That's where the header bar became much more consistent across the platform than it was before. At one point, there was no header bar on many applications. In some cases, that's still the case. And what we're moving towards is being able to make that consistent across all of the different applications within a particular instance by furthering that separation and allowing the app shell to be updated independently and to be global across your entire instance. So this is one way that we're addressing this as well, and this also helps to provide a consistent user experience and a usable experience for the users of DHS-2 in different contexts. Another way is by introducing tracker plugins. So I mentioned this for Trakt entity instance dashboard in Capture App. There are many other places where we might want to include extensions or plugins in DHS-2. And this one is plugins in the Capture App for data entry. So being able to customize how you actually enter an ICD-10 code or an ICD-11 code or other potential ways that you want to customize the experience so that someone can have a... Basically perform their job in a better way. So this might look like having a button instead of just a drop-down with an option set that then opens up a very complex custom interface for doing ICD-11 coding, for example. But there are many, many, many more examples of where this can be very valuable. So this is something that we want to add as an extension point in DHS-2 is to be able to customize how you do data entry for specific data elements in a custom form or in a form, for example. I mentioned also Android application modules. So thank you very much, Marcos, who's here for providing this slide for me. But currently there are a lot of modules within the Android application and some of those you might want to customize for particular programs. Maybe your stock management tool, which is like RTS, the real-time stock tool, that is a little bit of a different program than a typical tracker or event program might be. And so being able to customize the look and feel in the user experience just for that one program while keeping everything else that is built into that application is really powerful. We have other examples from logistics and education, but there are many more that enable this to be useful for individual country implementations as well. And then we get to the server side. So as we mentioned, a web application hammer is not necessarily the hammer that you want to use for a lot of these solutions. And so we're looking at how we can expand the platform of DHS2 to make it easier to build and share extensions that also occur on the server side, as Lars mentioned, the microservice server extensions. So this is enabling us also to be more agile and more modular and granular in the releases that we have in the components that we provide, but also allows for custom integrations and custom backend services to be built and shared within the community. So now I want to talk a little bit about how we're actually going to do this or what the next releases are. This is the main bad news for the presentation. There is good news that comes right after it, so don't worry about that. Version 41, so first of all, before I dive into that, we're talking about versions here in whole numbers. So version 40 and version 41. We're moving away from the concept of having 2.40 and 2.41 because that gets a little bit redundant and gives us a little bit less flexibility. So there was actually an announcement that was published today basically sharing that Hisp and DHS2 aren't just names, and they are names because we're moving into new domains outside of health and we have functionality that's outside of just district level. There's national level, there's facility level, there's district level, there's international level. So they're just names, just like IBM and others have moved from international business machines to just being IBM. There are many other examples of this. And as part of that, DHS2 being part of the name, DHS2 2.40 doesn't really make sense, so we're moving to version 40 and version 41, just a small semantic thing that we're doing. But in order to focus on a few key things, namely quality, design and extensibility, and really make sure that the core is stable and a solid foundation for innovation and for use in countries, the next version, version 41 will be out in one year. So in May of 2024. But that doesn't mean we're going to be doing nothing between now and May of 2024. So these are the patch releases, approximately, that you will see for version 40, which was out last month in the next year. So we release a patch release or a minor release, approximately every two to three months for each of the supported versions. So this is version 40 patches. And these are the other patches that will, approximately, obviously, the exact dates and the exact numbers might change. But this is what we're working on in the meantime. So we have supported versions for 38 and 39 and 40 that will be continually improved and worked on during the next year, as we're also developing version 41. And that's not all because we have continuous release, which I talked about on Monday as well. And this is where applications can be released independently of the core. So even though version 41 won't necessarily be out for another year, we can continually improve and build even features and functionality into the applications that are built on top of that platform. So that's things like the maintenance application, the data visualizer application dashboards, every single web app that you can see in DHS-2 can be continually improved over the course of this year, including adding some functionality. So there might be releases of these applications throughout the year. It might be every week. If there's an issue that needs to be handled quickly, we can release it very quickly. It can be updated in different instances in a very timely manner. And if there's an issue, it can also be rolled back in those instances. So we'll be releasing continuously the applications and the extensions to DHS-2, which are becoming more and more powerful over the course of this year, which allows us to have both the stability of the long release cycle with the agility of short releases for individual applications or extensions. And if this sound feels overwhelming, there's a lot of releases there. We'll be also including these applications in the core releases. So you don't need to take them if you don't need those features or that functionality. You can wait for the one that's bundled with the next major release. You can also, we'll be trying to bundle up kind of an announcement of what has been released in the last three months, once a quarter, so that you can know these are the applications that were released. These are the minor versions that were released. And this is the major version that came out this quarter, for example. So now I'm going to talk a little bit about version 41 specifically. Who here has watched the films or read the book, Lord of the Rings? The Hobbit? Darrell Tolkien? Okay, there are quite a few for those of you online who can't see the audience. Who do you think is the hero of that film? There was an answer, Gollum in the crowd. For me, the Eagles, that's a good one. So there are two main Hobbits in the film, and one of them is Frodo, who everybody knows. And the other one is Samwise. And Samwise is the one who, slight spoiler, not too much, carries Frodo across the finish line, more or less. He's the one that is stable and gets the Frodo to where he's going, which is to destroy the ring that is, yeah, anyway. Well, we won't go into that too much. This is the codename for our version 41 release. And why is that? That is because we want to be the stable hero that is the foundation for everything that we're doing. This means that we're going to focus on three things, quality, design, and extensibility infrastructure for the version 41 release of DHS2. And what does this actually mean? So I'm going to share here a picture of my colleague Anna, who this picture was taken in Jamaica. It's going to be a year of focusing on these things, which means there might be a few fewer features. I'll talk about a lot of the features that are exciting and coming up as well. But we're going to focus on quality, design, and extensibility so that we can provide this solid foundation. This means we'll work on stability and performance. We want to make upgrades as seamless and risk-free as possible. And we want to limit regressions that we introduce in version 41. We want to focus on design as well. So there are things in DHS2 that are complicated sometimes. And sometimes it's training is a big challenge for a lot of implementations. And we can work to reduce the cost and the need for those trainings and the complexity of the software by focusing on usability, the quality of life of a user of DHS2 so they can find what they're looking for and have an intuitive way to navigate around the platform. Consistency across different applications and things like accessibility that have not been highly prioritized in the past. And then extensibility, which as I mentioned is allowing the rapid iteration and the rapid adaptation of DHS2 to local contexts. That means we need to focus on building a rock solid platform for that extensibility that extends beyond just applications. But it wouldn't be a what's next for DHS2 presentation if I didn't talk about some of the features of DHS2 that are coming in the 41 timeframe. So we have a lot of releases in applications as well that might be a little bit before, a little bit after. But in this timeframe, we're going to be working on a number of things that are exciting. And some of these are part of the usability push. So some of these are focusing on making DHS2 more usable, more accessible, more easy to understand. But some of them are functionality that is highly requested and that we've known we needed to implement for some time as well. So the first of these is a new version of the login application. So the login app is a little bit dated. I think I saw a presentation for PEPFAR maybe in one of Lars's slides where it's had this exact same login page probably from 2014. I'm not sure if it's exactly the same, but maybe it was 2016, 2017. But it's been around for quite a while and needs a little bit of TLC. This doesn't look that different, does it? That's okay because this means that we can build on the core that we all know, the core login application and extend it. So have an updated refreshed design while still keeping it familiar. But importantly, this also allows for customization in a way that hasn't been supported in the past. So this login page could also be supported out of the box for DHS too. It's customization using themes to be able to say I want to put my login dialogue on the left side. I want to put an image on the right side. Maybe I want to have some logos there for different supporters of this particular implementation. And this will be a theme that we can provide potentially out of the box. We're moving to a new technology that is part of also the extensibility infrastructure effort to eliminate some of the older technologies that are underlying DHS too. So we needed to redo the login application anyway. And there are a lot of ways that people customize it today that aren't typically supported out of the box. They're very custom kind of hacky ways to do it. So we're trying to make that more of a first class feature. That includes having login support, theming of the login page support like you see here. It includes an improved way to do two factor authentication so you don't have to check a box and then put in a code if you don't really know what that is. That's very confusing. So if you have two factor authentication enabled, you will log in as normal and then you'll get just like you see in most other applications, then you'll get a dialogue asking you to enter the code from your authenticator application. And then we have the ability to do fully custom DHS to login application themes. So this means you can put custom images, custom links, you can do whatever you want with this. While keeping the login functionality that is built into the application and can be basically injected and then themed in a fully custom way. So now for the next functionality that probably a lot of people have been waiting a long time for. This is around maintenance and particularly the maintenance application. We're going to make it better. That's the bottom line. So I should preface all of this by saying that we're engaging in an iterative development and design process where some of these mockups might change. And that's actually a very good thing because it means we're talking to users. As Lars said, we're talking to people and seeing, all right, this is the idea that we have. Let's make sure that this actually makes sense for the 100 countries that are using DHS to bulk edits in maintenance. That's something that has been asked for for a long time. So this is a new way to view and edit and manage your metadata or your configuration in DHS2 in a way that's been very difficult in the past. And so building in a lot of this functionality to do bulk edits, to do more intuitive and streamlined ways to edit individual objects, pagination, standardized look and feel, being able to filter all of these types of things are part of this redesign. This is just an example of one of the data entry forms, but it'll also be much improved compared to the look and feel that's been a little bit dated for DHS2 maintenance app. And then we have organization unit management, another functionality within the maintenance app that has been long requested. So this includes things like being able to merge organization units, as things like bulk editing and management of organization unit trees within the maintenance application. So there's a lot that's going on there. And I did want to mention one thing that is in addition to this, that this is part of a larger effort to make it easier and more powerful ways to manage and maintain the metadata of DHS2 systems and particularly a network of DHS2 systems over time. So in addition to this, we're talking about import, export stability and improvements there and talking about ways to extend the data model to make it easier to manage permissions and bulk groups of metadata within DHS2. So now I'm going to go through some more features quickly. We don't have a lot of time, so I'm just going to go quickly through them. One of those is cross-program line lists. So we introduced the line listing application recently, but that is only listing events and enrollments. We now will have the ability to introduce tracked entity line lists or cross-program line lists to be able to analyze and cohorts of people that are across different programs. We also have some functionality in dashboards that has been very much requested. Again, these are early mock-ups, but that includes being able to manage dashboards in a way that hasn't been possible before being able to manage these dashboards in a dedicated interface, which cleans up and makes it easier to have the data be front and center in the dashboards themselves, so hiding a lot of the management interface that you might have seen in the past and really getting out of the way of the data that you want to present to the user. This includes things like filtering and moving those into places where you have more room to really expand on the functionality that's based there and more features like that. A couple more that I wanted to talk about. I only have a few minutes left, but referrals and transfers in the capture application. This is something we've referred to as temporary referrals and permanent referrals in the past, but this allows you to not only make a referral out, but also to respond to that referral and say that some person was potentially seen or a referral was processed by the receiving organization unit or the receiving facility. Android capture usability, we talked about a little bit at the beginning of the week as well. This is improvements that are ongoing and is part of our push for usability, making it easier to understand what's going on and to see the data that you need and to really get through the application in a consistent and intuitive way. So there's a lot of improvements coming there for usability. And then this one is a small one, but it's one of my favorites. This has been there for quite a while in the maintenance app subsections being available in the application menu, but it has slowly faded out of the interface, and now we're bringing it back and we're making it even better. So in addition to being able to jump to data elements overview in this example or to create, go to the create a new data element screen immediately from anywhere in DHS2, we're looking at being able to also jump directly to visualizations that you know exist in your system to be able to search for malaria and find things related to malaria in different applications in DHS2 without needing to know that you need to go to the data visualizer application and then file open and search in there. So this will help users to find their way around the system. And this is just the tip of the iceberg of what we can do with an interface like this in combination with the global app shell, which allows us to have this immediately available in all the different applications across DHS2. So you have a consistent interface no matter where you are. And then my last slide is there's a lot of things under the hood that we want to work on in 41. And this is around the focus on extensibility infrastructure on quality. And that includes a big focus on performance and a focus on security and a focus on quality. So we have testing efforts that have been overhauled in version 40 with the beta testing program. We have performance testing that we want to do and we want to make sure that we are improving the functionality of things like program indicators and analytics runtime and having a robust functionality for importing and exporting metadata to be able to manage metadata in a system. So look for a lot more that might not be flashy screenshots, but hopefully will be even more useful and make DHS2 a really useful platform in all of the countries where you're working. And with that, thank you for listening and we'll turn it over to you. Thank you, Austin. I guess there's so many that want to pose questions for Lars and Austin, but we are actually doing the panel again. And then there will be question possibilities for you. Please, Austin and Lars, please sit. And then I will call upon Mark to say, yeah, from PEPFAR. We heard the PEPFAR story a bit today. And then they will also call up Pamut from his Sri Lanka and Rue from Ministry of Health in Rwanda and his Rwanda. And then Jörn, where are Jörn? Jörn also, but then you need to bring your rucksack down. You cannot bring that for the panel. No one will steal your computer while you're sitting there. We will take care of it. Tomika will take care of it. We wanted to continue to be a bit energetic here this morning. We need one more chair. Welcome to Mark. He just arrived. You will be able to squeeze. Because we have the last, I would say, semester discussed heavily how we can improve the innovation capabilities, creating even a more innovative innovation ecosystem around the DHS2. And that is actually been, of course, inspired by the, we would say, proof of the concept of the DHS2 as an innovative platform during the pandemic, where we saw that Sri Lanka was the first, even in January 2020, late January 2020, three days after the two suspected cases coming into the Port of Colombo in Sri Lanka, they were able to make a port of entry. I just have to tell, it took the municipality of Norway, or Oslo, or Norway, one and a half year to do a port of entry for Godomon, took three days in Sri Lanka. So I just want to let Pamud brag a bit about how that was possible on the platform of the DHS2 without having all the programming expertise. So thank you so much, Christine, for briefly introducing what exactly happened in Sri Lanka back in, back around January 2020. So in summary, like what was made possible was one thing, like, so within couple of weeks of, like everyone got to know, like there is something really strange going on, starting from China, but like spreading really fast. We were able to produce something for COVID-19 surveillance in Sri Lanka, which is again, like we as in not just his Sri Lanka, it was us and especially the Ministry of Health and many others, like especially the ICT agency who's representing all the tech related work and the entire governance of the country. So that is one. And the next thing I wanted to highlight is around this, I mean, like just after like one year's time, then we started producing COVID-19 vaccine. And that is when we were also tasked with this very difficult target of enrolling the entire population of 21 million. People of Sri Lanka introduced us to and to track them for COVID-19 vaccinations. So these were the two things that, that are the highlights of this entire implementation. But, but I would like to highlight is about what made it possible. So this is some, something that is also relating to my PhD work. So first thing, of course, like I will start with what Austin has, and last has been highlighting the platform. So yesterday evening, there was one session at 5pm, where we kind of tried to discuss about the digital public goods and the community. And like one aspect was like, now DHIS2 is present everywhere, right? Not just health, education, climate, who's doing that? Are you guys promoting DHIS2 by just going to all the ministries? It's not really that. The, the true thing that actually happened in, in Sri Lanka and many other countries is like platform. While it is being modular, it's so customizable, right? We have many other DPGs or open source solutions where the community and I mean, like it's actually mostly talking to the developers. But here it's the implementers and the ministries. It is so easy to adopt. So that is one main thing about the platform that made it possible during the pandemic. So it was not just agile development. It was agile implementation. So we started with something very basic for port of entry monitoring. And then of course we had a lot of support. That's my second thing, the community and the engagement. So we had a local community in Sri Lanka plus UIO and the entire HISP. Like we were working with everyone in the HISP and the UIO. Austin specifically, I must mention like he had sleepless nights supporting us to build apps based on this innovative platform. And of course, finally the local capacity. So we had a lot of collaborations with the University of Colombo. Like more than one decade, I would say like Prof Yon can talk more about it. So we had in-country capacity. So that's why we were competent and confident to do something during the pandemic. So these strings, three things, what made it possible? Super. And then we can go over to Andrew maybe because they may be the best in class of borrowing all these innovations across the HISP groups. Can you tell a bit about your experiences? Thank you, Christine. I think Rwanda is like Sri Lanka. So for us, what happened is that, you know, my personal experience is that during the pandemic, people always panic. And the panicking goes around the different areas. I remember when they called me to go to the front line, I was at home. Then my family was telling me, you're going, I said, yes, I'm going. Oh, you're going to bring COVID in the back home. I said, no, no, no, no, it's not bring COVID. We're going to do interventions, ABCD. They said, let's pray for you. Then close your eyes. When that time you see good when you close your eyes. But what I want to mean is that sometimes during the pandemic, there will always be no options. I mean, no one will be knowing what to do, what will happen. Then, lack enough when we heard a story from Sri Lanka, that's when we understood that at least there is a module, there is a package that can be implemented. So one story I want to tell you, when we are trying to find different solutions, because during COVID, there was many suggestions. One vendor came and said, we can customize it. Then let's have a meeting tomorrow. Then all of us, we went including our leadership to check on the system. Then when you reached on the timeline, the person said, it will take us six months. That is the minimum. Then the minister was like, oh, six months, all of us maybe will be not there. Then that option was not our option, because that's why I want just to emphasize on the flexibility of the HHS too. So imagine if you can implement a solution and it takes six months when it's an intervention for the outbreak. So what we did was, because after reading the story from Sri Lanka, we told our leadership, give us time, because when we are taking this innovation, we don't say we are taking them. We just say we are going to code. Then they give us two days, we go somewhere when it's just importing the package. Then we went and imported the package one day, second day, third day we started the system running and everyone was reporting. We were able to get the data because it was important for us to know the cases, to confirm the cases and be able to know which intervention. Because remember on the pandemic, you have to ensure that one district, if it's more affected, it doesn't affect another district. So for me, I think the important thing that made Rwanda to use the HHS too during the pandemic, one is flexibility. It takes a little time to implement, because at least we have a big community that are implementing and they're having innovations. And these innovations are free. They are open, that is our value. The second is that we have a global team, the network. We are not working alone. We are in the countries, but we work with the country experts, but again, we have global teams that are developing the system that gives us the confidence to implement. The third is that we don't require training. Sometimes some of these modules, they are using tracker and we already have tracker there. Then whenever implemented, users will get used without having the five or 10 days training. So without taking long, I think we will be answering based on the questions. Thank you. Thank you, Andrew. And this is very good examples, but as we learned from Lars, but some of us knew it before and everyone knows it actually, our history with PEPFAR goes way back from when Mike Garen came, 8th of December, 2012. And okay, we can go into 13 of them. But Mark, can you tell a bit about the travel and the journey with DHS2 and why PEPFAR chose to go along? And we are very happy for that, I have to say. That's another story, how PEPFAR has been so instrumental for DHS2 to become a platform because somebody needs to finance the core and nobody wants that, except for PEPFAR. So, you want to see us? Thank you, Kristen. And it's a pleasure to be here, particularly in this panel with so many esteemed colleagues. PEPFAR has been investing in the DHS2 platform, as you said, since 2012, actually. I think some of those initial discussions started. And this predates the shift in the PEPFAR program to doing much more granular data collection, much more frequently at the facility level. And we support over 50,000 individual facilities over 53 countries, so more than 30. And in 23 of those countries, those are bilateral. So we have a bilateral agreement in those, in almost all those countries, DHS2 investments predated PEPFAR's engagement in those countries. And that was one of the major reasons why my predecessor, Mike Garon, chose, as we were looking at reading the tea leaves about where the program was going, wanting to do more than sort of a single data point entered for a single country once or twice per year to quarterly getting much more granular about all aspects of the HIV epidemic monitoring that. And so that appetite for data we knew on the system side that you were not going to be able to engage with host governments around that level of data collection, that level of frequency. If you were to bring in some big proprietary system that really had the perception of hoovering up data from a country. So that was a strategic decision to use the systems that were known and trusted and that there was a large community built around DHS2 already. However, there were growing pains associated with that. And Lars mentioned, and I see Jason and Ula and lots of other folks who've been part of that journey with the PEPFAR program over the last decade plus. PEPFAR is celebrating its 20th anniversary this year. There's a big campaign, of course, with our lawmakers to advocate for a reauthorization of the program. And we're very hopeful about that. But something really remarkable is happening right now within the Department of State where I work and where the PEPFAR program is focused. And so we are, as in about two weeks, we will be the Global Health Security and Diplomacy Bureau. PEPFAR has always been sort of a temporary office within the Department of State. And the PEPFAR program will be the anchor for this bureau. So we will still be executing PEPFAR. We'll still be doing that. But there will be other diseases added to that bureau. And our ambassador, Ambassador John Kingison, who previously led Africa's CDC and worked on the COVID response across the continent, will be dual-hatted representing that bureau and the PEPFAR office. I mentioned this because it's relevant, because as the PEPFAR program has helped to advocate for more investments than DHIS-2, created that appetite for data much more frequently, much more granularly, which again, we can get into some of the caveats associated with that. We have an opportunity to better coordinate the way in which different parts of the United States government are thinking about their data models, the tools they use to take those up, the capacity approaches they take for those that are collecting and managing data systems at a country level. And so we see potential over the next years to really leverage the new organization within our office and our bureau to be sharing the examples and experiences that we have within HIV data across a variety of other areas. Now, the double-sided coin with PEPFAR using data so often is that there's just this insatiable appetite for the types of data at a global level that we need. And so we're really trying to, there's a sustainability roadmap in development right now, and we have a data roadmap that will be a part of that, that'll be publicly available in the next few months as well. And we really want to start incentivizing, my boss disagreed just last week, and I was trying to say we need to control our appetite for data, and that's not going to happen. Where we do agree is we can control our appetite for parallel data. So we really need to be doing more education showing the consequences of asking for things that don't really exist in national systems. And using a better awareness of what actually exists and what it takes to generate those to inform what we collect, when and how we use that. And so part of that data roadmap is better describing the sort of archetypes, the states of national systems and investments from country to country and helping us to understand what we can reasonably ask for and what formats. And I'm looking at my colleagues from Global Fund who are in here as well, who are already starting to think about following PEPFAR's model for direct reporting and really just want to encourage us and our colleagues from WHO as well, really just to be thinking really very hard about how and what we're requesting because of those consequences. I did just want to say a couple other things. As we're developing and using these systems, the need to monitor the HIV epidemic longitudinally is very real. And most many countries are doing some sort of individual level systems, whether that's Tracker or OpenMRS or something else. And also for HIV and many other programs, we need to look beyond data that may be in DHIS-2. And so there's a lot of guidance that we have out around our program right now around sort of integrated national data repositories, data warehouses. In some countries, they may be trying to use DHIS-2 for that, Lars and I spoke earlier, but a lot of they're using Azure, they're using AWS, they're using something that may be on-prem that might be hosted, might be hybrid. And we should only expect more of that. And we're driving a demand for that. But thinking about how DHIS-2 beats into that is part of that is absolutely important. Coming from representing the United States government, we have a lot of cybersecurity requirements. And so a lot of these investments in core have been a necessity for things that we need to be able to use this platform within the United States government system boundary. And those are only increasing. So multi-factor authentication, encryption data at rest, encryption data in transit, zero trust architectures, a big one that's coming as well. And so we were able to grandfather use of DHIS-2 in as an open source product. And it's not as encouraged right now with the US government. So we really want to be working more closely with the University of Oslo over the next years to really continue to advocate for why investments in open source systems are so important and demonstrating how those can actually work within the United States government boundary, other boundaries where there's an increasing focus on cybersecurity, et cetera. And that gets me to the point that Kristen raised well. So we continue to hear about how great it is to have free features in the platform and the importance for standard core, but that doesn't come for free. There is someone paying for those salaries and others. And so PEPFAR has been very fortunate in the ability for our funding to be able to be not implementation focused for the funds that we give to core software development. We do have a much larger amount of funds that we put into implementation, but that happens at our country level. So we have a core investment that goes there. We were able to ignore that and PEPFAR was some of the original partners that were able to provide that core funding. And for all the reasons that Austin and Lars have laid out this morning, we feel that this is absolutely important. And looking at my colleagues from Digital Square Path where we coordinate our investments to University of Oslo for core software, we're looking to donors to be able to make that case more broadly. There's huge benefits to having a stable platform that we can use in a lot of different sectors in a lot of use cases. But in the early days, we were very nervous where PEPFAR was an outsized piece of that pie for the core software development. Those pieces have increased. The overall size of the pie has increased and that's great, but we need to continue to advocate for why that's important. And then just, I'll leave with the importance of working with Indigenous capacity. The PEPFAR program has a target of 70% of our funds that go to the country level are focused on Indigenous organizations. I think there's so many with the HIST networks with others that are using DHIS too. There's just a huge community of developers that are doing this, but more broadly even beyond DHIS too. Huge initiatives around data science and if we want to just host an event and miss this year as well. And we're really looking at more data literacy, making sure that we're able to support platforms that are using data in all sorts of different formats, not just from DHIS too. And those are not sorts of things that you need to bring in outside organizations to be really meeting a lot of those sorts of needs. So I'm very excited that we're able to continue supporting the DHIS to platform. Thank you. I think it needs a hand for this one. Thank you for that pledge. And you and maybe you would like to talk about something else, but however, or you want to talk about the phone, no problem. Yeah, no, one thing I wanted to raise because I noted that in one of his slides where that open source is good because it's less bureaucracy. And what I will emphasize is rather that it's good, even research based evidence that open source is enabling innovation. Innovation, as it is evidence that proprietary software is hindering innovation. And that was the example from Andrew and Pamu on what happened during the pandemic, where the network of open source software actually enabled sharing of best practices and even apps and not necessarily only the apps, but also the way to do things, the best practices, etc. So I think that is a very, very important part of everything. And it's also about, I mean, after you, I have to mention something about the platform as well. And we started to discuss with your predecessor, Gary McCarron, many years back. And at one point I remember I asked him, why is the US government coming here and supporting open source kind of anarchistic group like this? That's not very normal. And he said, yes, no, because we are progressive, he said, and also because the reason, the official reason was that DHS is used in all these countries and eventually we want to have interoperability and collaboration and leading on capacity, etc., etc., various countries. So that was, according to him, the official reason that, but I think it's quite interesting that this collaboration came about and I'm happy here that it will continue into the future. Cross the fingers for that. And into this talk about Petra and Mark Aaron, I want to say something about the future of DHS, because he also had one other, in our numerous discussions, he also said, I don't understand why you guys are not focusing on where you have monopoly, absolute monopoly, and that's aggregate data and that kind of analysis. And when we now think about the future of DHS too, I want to raise that again, not only the aggregate data, but please remember that everything that has to do with analytics, M&E, etc., whether it's on the run from the tracker or from medical records, etc., it's always about single units of numerical data. And the analytics coming from that tradition is what we have now seen is a big problem for DHS too, because we have been so successful in making it possible to specialize into different systems, which is a good thing because that enables participation and user control of the development, but at the same time it creates a problem with integration and different silos of systems, etc. So that has brought us back to where it started and that we need to work harder on the analytics and we have already had a lot of, say, competition and all these other kind of tableau and others who are actually doing exactly what we did in the old days, saying that let's take data from all these sources, put it into one database, call it a data warehouse, and do our analytics. So maybe that is the future. Go back to that again. Yeah, okay, thank you. I was thinking maybe Austin, since the two of you had the presentation, maybe we should open up a question to all of you guys or you have a comment, Austin? Yes, of course you have. I was going to just respond quickly to the four previous speakers. So thank you very much for the comments. I wanted to start with Pamud and the sleepless nights supporting Sri Lanka. I haven't been yet to Sri Lanka, but I would love to go someday. So I had to support it from quite a far away. But I think you highlighted very clearly what is the power of a platform in addressing real needs and real urgent needs in public health, but in other situations as well. And then Andrew, you extended on that to say that it's a community. All of us are sharing our innovations and working together to address these problems. And that's really I think quite unique and enabled by that platform as well. I was in Rwanda with you a couple months ago with a group of 50 people learning about integration. And that touches on another point that both Mark and Jorn brought up, which is interoperability and integration are a part of that platform and that extensibility and being able to play well with others and get data to where it needs to go. So it was really a powerful experience to be in with 50 people learning about interoperability with DHS-2 from 20 different countries or more and then taking a bus across the border to Uganda to meet with some very talented developers in the network, in the community, working on building extensions and adaptations at DHS-2. So I think the interoperability is a really big part of our focus as well as security. And I think that it was on one of my slides but it's a big focus for us as well is investing in first-class support for interoperability and first-class support for top-notch security which has sometimes been an afterthought in the space where we work. And yeah, so interoperability and complex architectures and being able to get the data to where you need it to be able to do triangulated analytics on that I think is really the way that we're going in the future. So looking forward to that journey together. That was my quick comment. Sorry, it was a little bit longer. Thank you. No, no, no, no, no. Can we open the floor? Lasha, you want to comment? I can just have one. Just do a super quick comment on to build on what Mark says and also Euron says. I think DHS-2, we do spend a lot of energy building out analytics. We have people working very hard on it. But the thing is, we also built out very complicated, or not very, but the big complicated tracker systems now where people do modern child analysis, this household and the spraying and this whatnot. And then the problem is that people come and say, oh, but we can't really analyze this data. We spend all this time putting the data in, but we can't look at it in analytics. And I would say that maybe we are putting a necessary constraint on the system and ourselves because the data is there. I mean, the data is there. And there are things like, there's a thing called SQL that allows you to query the database, to get the data out and display it in the report. That exists, right? So, but still we say, can't be done, right? But it can. So, I feel like to kind of take some pressure off the DHS-2 analytics and save the poor guys working on analytics day and night, we should be able to also kind of integrate the more ad hoc, explorative analysis that we do find today in data warehouses and BI tools in DHS-2. Because it can be done. Is it that we say that it can't? I would say that DHS-2 is really a fantastic tool when it comes to distributing analysis to many people, right? You know that implementing a data, like a BI tool at scale can be difficult because of training and installation and costs. So, like distributing analysis in DHS-2 is what the software does really well. So, I think in the future now, within Lettuce Team, I think it's going to be really interesting to see if we could try to combine the power of the kind of DHS-2 predefined reports and dashboards and program indicators with the more explorative ad hoc analysis that we can do in data warehouses and BI tools together. Thank you, Lars. Any questions, guys and girls from the audience? You have the chance? No hands? Yes, we have one. Pamu is not here for running anymore. So, first of all, I just wish to commend you. This has been fabulous four days, really eye-opening at all levels. Oh, sorry. My name is Amani Siam. I'm the Regional Advisor for Health Information Systems in the WHO South-East Asia Regional Office. I'm responsible for 11 countries. Eight of them are using DHS-2 profoundly and strongly. So, I just wish to commend you on this. Lars, I take your point. We're not going to ask you do this and do that and solutions and whatever. But I need you to help us please to, in a way, having like a marketing strategy for DHS-2. So, the asks I have is that you have, we are still trapped with the lower and lower middle income thinking for DHS-2. We need to raise the bar on this. We have a few upper middle income countries who are really in a mess with their facility-based systems. There's something to learn there. So, that would have been one thing, of course, to reflect on. The fact that it's not just a map and what you drew. It's the socioeconomic groupings that you have gained. And now that you are crossing over from the health to other sectors, you have to take that into account. The second thing is about data sovereignty. I think this is something we need you to package into your marketing. And I have to say, as technical agencies, we failed you a bit because I think it should have been our responsibility to market the data itself and the use. We can't expect you to handle the informatics and the public health aspect as well. So, you really provoked us by a lot of what you've said and what Jorn has said. So, the two asks are definitely to raise the game to speak more about upper middle incomes and what they can learn from. DHS-2 is not for Africa only or for Asia. It has a global dimension of applicability now. Second, the data, the idea that the data sovereignty is always guarded. And then third, I think what I would really ask you to consider given all the collective partners, especially that you have a meeting coming up of the partners, in the sense that what I think my colleague from PEPFAR spoke about, the spectrum is increasing. Like for the Southeast Asia now, we have a big issue with Lingi. It's again uprising. We still have a big entrapment with TB. So, we have to look into cross-infection. So, for me, the big education I had coming is the capture, the fact that we will definitely want to look at the profile of co-infections, what do they look like. And third, but of course, the NCDs. We need more to be done for the NCDs. And in that respect, I want really to urge you to have like a Marshall plan to start thinking of patient registries that should be trapped by DHS-2. For instance, cancer. We still are not doing well in analyzing cancer data. And they complain about we don't have good data. It's really hooked into very small places. So, I'm just saying that if you can come up a bit more, as you say, you focus on quality. This is what Austin said. We are going towards quality. It's also speciality, not just quality. We have to show new offerings that we are able to handle patient registries, for instance. That will be a huge asset. You will open up a massive scale of data use if we can trap the new types of users beyond what we call the communicable and infectious diseases. So, these are for us. I'm going to write you an email. Yeah, probably better. Thank you. Thank you. Yeah. Speaking of which, Norway was actually using DHS-2 for contact tracing. So, it's not only the upper and middle in Asia. That is a mess. It's also Norway, to be honest. We have our own problems here. But that was more like a comment I felt. Thank you. Absalom. Mamrima from Malawi. Of course, I just want to appreciate for the good presentation and the ambitious plans for the future of the DHS-2. My question, I just want to find out if this functionality whereby one is able to compare within countries, like in our case, we have borders, of course, we have some challenges, cross border challenges, when dealing with the immunization API, whereby there are cross border issues. One country, let's say we have Mozambique, Tanzania, we see, we're building our country. So, this issue of cross border challenges, and I just want to find out maybe there could be that fraction out of that linkage between one country to say within the DHS-2 to say what they are doing in that country and that our border in our country. Thank you. You could talk about we have many cross border projects. We have the Mekong. We have a cross border project. Yeah, as if you have a cross border project between countries in Southeast Asia, and the big, big, big problem with everything that has to do with cross border is to get the data sharing agreement, because even though it's about sharing necessary data, for example, transfer referral of patients between the two sides, it seems to be so close to national security, etc., that all the governments are thinking, wow, this is dangerous, so take it easy. But yes, cross border movement is very important in the healthcare. I mean, you have patients moving back and forth. You have Malare. We have a Malare project also in Southeast Asia, where all the countries agree on surveillance and monitoring Malare on the border areas. So, yeah. What about the East African community? Yeah, we have the East African community also, but that's more like data to shared database. It's similar. We have West Africa Health Organization also having that kind of shared data across countries. So reporting up to a shared database, that of course should be easier to actually have cross border direct exchange of data, because it requires less agreements on security of data and MOUs, etc. But yes, we are both in the East African community and West Africa Health Organization. I think so. Yeah, thank you. I am Tomeka from West Africa. Yeah, West African Health Organization. And yesterday we shared some experience on that. And I think so more than the other colleagues in the other regional economic community. West Africa today, this problem of the data sharing agreement is not a problem because among the countries, no border. The people are just circulating from freely circulating one country for the other. We have Nigeria. That's all. No visa, no anything I'd require it. So the challenge become for the health. Why to do to ensure that so the health epi- the health problem not become the barrier for that free circulation among the people. And we since Ebola crisis in 2014-2016, we have now a regional platform for the information sharing. And that regional platform, we are improving it every day to improve the information. That's all is accessible for any country. That's all the data entry is done in each country. Basic epidemic, prone disease for the moment. And the all other country have access on it. They can do it on the district level. That's all they can localize the points. Now we are putting information on the point of the entry that can be in the GIS module. So that the people know where the people getting entry from the other country and where the problem. That's all the problem of the, I think so, one of the difficulties in the other countries, that's all that free movement in the, among the country, they become a problem. That is not a problem in the Yokoas. That's all what we are doing now and working with his supporters is to how to improve the platform to be really, today we are working on the early warning system on that platform. That's all in any case, notified at a suspected case, you know how the other countries can take it as alert to activate the mechanism of the prevention for that point of the health security. Thank you. Point 15 minutes into the app competition. So maybe somebody will look at me. Oh, we have a question more. Okay, we can't, can't be short. Pakistan. Well, this is Mustafa Jamal Ghazi, national coordinator of Pakistan for TB, HIV and malaria. Ever since I'm not a doctor, but I can be a very good manager. Ever since I've joined this assignment and I'm keep on very close eye on the DHIS too. And what problems we are facing right now. The sharing of data's from the private sector to the public sector. And from public sector to private sector, it seems very, very tough. And every one of them are engaged. Not the public sector, but the private sector is quite engaged working in the silos. These needs to be, you know, mandatory for the private sectors to share the data's with the public sector so that we can integrate it a proper data space into the entire DHIS system and the CMU. What we have seen so far it is not happening. And seldomly, you know, they talk too much, but they don't do that. So what I would be requesting that it should be done in latent spirit. And this is what everyone is in connection with DHIS too for developing the software. And then they, you know, manage their data accordingly. I would be suggesting that the public sector is the most, I would say that the key and pivotal for all the databases for the partners and supporters to work with it. This is the main problem. And secondly, I would be saying there are some cross sectoral or multi-sectoral approaches in the DHIS too is little lacking. We need to do that also, strengthening the multi-sectoral engagements into these diseases. Like HIV, TB and malaria are also facing challenges in blood front transfusions. So this could be the best educator. Well, any patient or anyone who is actually transfused the blood, it should be indicated. So I would be inviting the DHIS too to come to Pakistan and prepare a software for blood transfusions also so that we can maintain the data and manage this thing. Thank you very much. I can actually try to wrap up a few of these different lines of thinking maybe a little bit and bring it back to the platform that we were talking about at the beginning as well. Data sharing is important and Mark, you mentioned direct reporting using national systems and not having parallel reporting. I think there's a lot of similarities between that and cross-border sharing not necessarily of cross-border migration but of different countries reporting the aggregate data at the end of the day that we want to see to track progress overall. And we see that as something that we're investing a lot in as the DHIS do platform as well is in being able to have the ability for multiple systems to come together to have the aggregate data from the result of a tracker program, for example. You want to get a count out of it at the end of the day and you want to send that to your national HMIS and maybe that national HMIS is sending it to PEPVAR or sending it to Global Fund or sending it to the East Africa region or something like this. And there's a lot of I think opportunity for us to be able to bring that data together in using the tools that we have and building in integrations also with other systems because it's not always DHIS do. There's a lot of DHIS do but there's many other systems as well. So building interoperability with those systems and being able to combine data from different programs, different countries into somewhere where they can be actionable. So bringing that data together to where it can really be operated on I think is really valuable as a platform. I don't know if anybody else wants to. Just one final comment. So the problem you highlighted the way the HISP look at it from our approach it's more socio-technical. So there is so much that the platform a technology can do but it's more about the governance that you set up in the country and the way you implement. So especially when you're working cross sector a lot of stakeholders are engaged. So I mean like other than looking at what we can do as DHIS to platform the technology it's more about how you approach the problem and work with the government set up the proper governance and implement in such a way that this cross sector collaboration is made a reality.