 All right, everyone, welcome. We're going to talk today about extensibility in DHS too. For those of you who don't know me, my name's Austin McGee. I'm the deputy tech lead for the DHSU software team. And I'm apparently too loud because Max is turning me down. That's the first time that's ever happened. Welcome everybody. So today we're gonna talk about extensibility and I have a good group of folks to join me up here today to talk about a real world experience with extending DHSU. But first to get people kind of in the mood, who here has ever installed DHSU and never touched it again and then it just worked for the rest of the time you used it, it's out of the box. You install it, you never touch it again. Anybody raise hands? Who has done the opposite? Who has had to configure it, maybe had to extend it a little bit, had to change it? Raise your hands on Zoom if you're joining us there. I'm surprised. So some people are maybe just working with empty DHSU instances, that seems possible. Maybe we need to work on some data use in those cases. But what the moral of the story is that DHSU always needs to be adapted to the local context. It almost always needs to be changed, needs to be extended, needs to be integrated with other systems that are around it to match the workflow and the use case for which it's being used. And so what we're gonna talk about today is how we as a community and we as the global software team can help to provide infrastructure and support for those extensions to make them easier, lower costs, easier to maintain, and so on and so forth. But before I get started with that, I wanna take us, wind us back to 2019. Not for the obvious reason, but because that was the last DHSU conference that was here, live in Oslo. And back at that time, we had something, a vision called the application platform that we hadn't even started to roll out yet. And I gave a presentation with this slide that is kind of dizzying, but it shows the cost of maintaining applications in DHSU. This is particularly for the core team, which maintains 30 plus applications across multiple versions of DHSU, many libraries that support that. And basically we're maintaining hundreds of code bases in order to keep DHSU running and provide all the features that you want across multiple versions in the wild. And that's only a piece of the puzzle because then there's also everyone else out there who are building additional applications in DHSU to extend that functionality to adapt to the local workflows, to the local data use needs. Those also in the world before the platform of DHSU, would need to have an entire set of the components to build up an application. And so what we did by introducing the application platform, one piece of our extensibility infrastructure, I'll talk about some of the others later, is to do what's called inversion of control, where instead of allowing an application to basically take control of your entire web browser and do everything, which means that the developer that's building that application then needs to do everything for you. We flip that around so that DHSU provides an encapsulated space that is a smaller problem space for the developer to work in, makes it easier to build something new, easier to iterate, and also easier to maintain those innovations over time. We also have built since 2019, and this was the slide that I presented at that point, and have built an ecosystem around this application development infrastructure. So not only do you build an application, but you deploy it, you test it locally, you deploy it to the app hub, you share it with other users of DHSU who can then install it and use it and give you feedback. And that's the genesis for what we'll talk about today. As I mentioned, there are multiple stages of what an application needs to do, or an extension needs to do in DHSU. You need to build it, you need to maintain it over time, which is a lot harder than people anticipate. You might share it with other people, and that also comes with costs and also challenges because you might be installed on a DHSU instance that you've never seen before. You maybe never will see because your application then needs to work in a completely different context, and then it needs to be used. And so then there's additional challenges around documentation and around use of innovations and applications and extensions in the wild. So I wanted to share, I hope Dennis is here, he might be in the room somewhere, but I wanted to share something that he said in the hallway to me the other day, which he was talking, I did not prompt him about this at all, I promise. He was talking about what application development or extending of DHSU looked like before the introduction of a lot of this infrastructure for extensibility in 2016 and involved forking DHSU core, which I think it was 225 that he was mentioning, that's when you fork DHSU, then you have to maintain that fork over time. And if new improvements come into the main branch of the core, you need to invest a lot of energy to bring that into the fork that you're maintaining. Apps were built in all sorts of different technologies, each one was different, each one was not related to other applications in the ecosystem. And just a very specific example, this we all know and know and love the org unit tree in DHSU. At that point, it was necessary to create your own from scratch and basically build up, how do I represent all of these org units? How do I allow the user to select multiple of them? How do I allow them to select different levels? And none of that was provided easily out of the box at that time. So you needed to build that yourself if you were building a new application. And fast forward to today where things have become much faster and much easier in Dennis's own words to extend DHSU. And this is using the modern DHSU application platform, the modern DHSU core, so not a fork building on top of the platform that we provide the extensibility infrastructure and using things like the UI library, which provide an out of the box way to represent org units and select org units at different levels and in different methods of selection. So I talked a little bit about this platform, DHSU as a platform. I'm a little bit hesitant to use the word platform because it is overused incredibly in our lexicon. But that's the word that we've been using for quite some time. So what is this platform or what is this infrastructure for extensibility in DHSU and there's many, many pieces of that. The one that has been around the longest that is very powerful is the REST API. So we have as most of you probably well know very extensive and documented REST API that lets you do everything that an application in DHSU can do. And there are some drawbacks to doing that from a UI perspective, basically from a UI first design. But there are basically everything that you can do in DHSU in the web application happens through the API and we provide that to everyone else to be able to build their integrations, build their extensions, build their applications on top of us. Similarly, we have the app platform or the web app development framework, which as I mentioned is using inversion of control. We have the Android SDK to build mobile applications. We have a flexible data store, which as Lars mentioned yesterday has been significantly enhanced and improved in the 238 release. We have UI design system. So this is written description of how you should design applications to be user friendly and accessible to various people that might be using DHSU. And also importantly gives people that are using DHSU a consistent system to interact with so they can understand, I'm looking at a DHSU application, I see this org unit tree, I know what to do with that. Whereas if it was designed in a very different way, they would have to be trained or understand somehow that this is something that they've seen before in a different form. So we have a design system, we also have libraries of components to be able to use that design system very easily in your applications and your extensions. We also have a number of other tools including a DHSU client written in Java more recently by the interoperability team that is another form of how do you interact with DHSU from outside of it and extend the capabilities of the core. We have standardized developer tools to be able to spin up local instances of DHSU to test your application against multiple versions of DHSU which has significantly improved the agility of developers to build on top of the core of the platform. We have an app hub which allows you to share your innovations, everyone to share their innovations with other people in the community. And it allows those innovations to be reused and those investments also to be reused and to become more efficient because they can apply to multiple different contexts. And that has been significantly improved in the last year or two as well. And we also have extensive documentation, a community of developers and training for developers to build on top of the platform that is DHSU and to build those types of extensions and applications. This is just a screenshot of the developer portal which is the entry point for those developers to get access to that community. And if you aren't familiar with it developers.dhs2.org there's a lot of material there and we also run a lot of trainings and do a lot of direct outreach as well to the developer community. And hopefully those of you that are developers or that have developers on your team can join that community as well. So a lot of has happened since 2019 when the application platform idea was first introduced at the annual conference. That platform was released and is now used by nearly all of the applications that the core team develops in DHSU. It's also used by many, many dozens of third-party applications, both local applications as well as ones that are shared and used across different countries, different regions. The core apps have transitioned to using that platform which has reduced the cost of maintaining those applications over time for the core team and also allows us to bring new features and address bugs in a faster way. We've run developer academies and built a developer advocacy program which allows us to reach out to that developer community to cultivate it, to allow that community to share with each other as well as to provide support and importantly get feedback from the developer community on how we can improve our tools and our infrastructure in going forward. And one of the big ones that was mentioned a couple of times yesterday but I don't think is maybe fully understood by everyone at this point yet is that we decoupled releases of applications from the DHSU core. So 238.0 has come out, 238.1 should be coming out soon. And that is just the server side part of DHSU and all of the applications can be installed and updated independently which is a much smaller job, a much less risky operation than upgrading the entire DHSU core. So that's something that we've worked hard to do and it also allows us to reuse all of the tools that we're building for third-party developers to improve our own workflows and our own processes and that allows everyone else that's using DHSU to get new features quicker to upgrade individual applications when there's a bugs instead of needing to wait and do a ton of testing to upgrade their entire DHSU core and many other advantages as well. So again, just to recap what the platform infrastructure that we're developing allows us to do is to make innovations cheaper to build to maintain, to share and to use. And I put cheaper here, I could also say easier. It's important to say cheaper also because this allows us to reduce the cost that it requires, the investment that's required to build a new innovation to iterate on top of DHSU as well as to maintain it over time which is oftentimes an underappreciated cost of building these innovations and these applications is that once you build it you need to continue to maintain it even if you're just using it within a single country but especially if you're then sharing it with other countries or other places that might want to use that innovation, that application. And finally, it's easier for users, cheaper for users to access and to use those applications, those innovations because of the common design framework, the common infrastructure, it's not, you're not needing to learn something new from scratch every time you see an application. You know you're in DHSU, you know it's a DHSU application, you've seen these before, you know what an org unit tree looks like, you can access that and use it without needing to be fully retrained on a completely different interface that might change over time. And with that, I will turn it over now to my colleague, I believe Prosper is coming next from Hisp Uganda who will tell us about a collaboration for development of an application, several applications actually between Uganda and Tanzania and he'll be joined by Wilfred in just a moment. So thank you and please welcome Prosper who is getting his mic set up. Okay, go, can you hear me? Okay. Yeah, thank you, Austin. Yeah, so we're sharing an example of so many apps and hacks and whatever have been happening over time. So the example we are sharing is one where we have collaborated as Austin was sharing. It's very expensive to maintain these apps with the different versions. So our use case and our sharing today is about how we've been able to collaborate and work on a common app that has worked over time that has also even seen some pieces of it being implemented in the core. So I'm sharing this presentation with my colleague Wilfred and I will do the first bit. So I'm moving. Oh, it's this one, okay. Yeah, so this is one of the powerful tools that we have seen from the Alma scorecard that most of you have been using and struggling with. So in the early 2013, with so many countries adopting the HIS-2, it became so critical that we needed to continue actually keep using it. But it wasn't giving enough information for a counter-level implementation. So a lot of countries were struggling to see how they can implement a scorecard. And of course, excited about the HIS-2 implementation with the sub-national data. So in Uganda, we started off in 2013 again with some support from UNICEF in trying to attempt the first HIS-2 apps and we developed the scorecard, a district scorecard for MCH. And that was how it was looking a little bit better. Similar to the Alma scorecard, it embedded into the HIS-2 and was exciting in terms of using the data. And our colleagues across the South, the Tanzania was also doing the same with the HIS-2 data using the standard reports by then. These were two initiatives which were all moving parallel at the same time, looking at the same platform and looking at the same data. And so somehow along the way, John and the John Lewis got us to work as an East African community. And this really pushed us to work now, start working together as HIS-2 groups within the country. So this was one, all the way from Brunner, Rwanda, Tanzania, Kenya, Uganda and South Sudan to implement a regional ESC data warehouse and particularly the scorecard was part of it. So the joint effort, now the two apps and the reports came together and we were able to build a scorecard in the East African data warehouse that was pulling data from all the East African states and then displaying it on the website. Actually, that's a website where you find that scorecard. It's still running up to now and very exciting also to be able to see the comparison of the countries before we go to the Alma. And this again was an effort between now the two teams, the developers in Uganda and the developers in his South Africa, Tanzania, coming together and comparing notes and then we started building that. Which was very exciting and they really got us to start working together, moving from region or state to state, setting them up, working together in supporting all the other implementation we had in the country. Then as that was also happening then, we got support from through the University of Oslo to through from UNICEF that helped us to be able to now consolidate all the efforts in the region and be able to build three standard apps which were generic, which were supposed to be generic and then be able to use them across the East and Southern African region. And we're afraid we share more about that but what you'll see in the pictures here is a team. Apologies, this is not looking so, it's looking a little bit hazy but in the caption there is a team seated in Nairobi working together on the scorecard from development to testing and the planning. And the members there, not all of them are developers but these are subject matter experts, people who have worked in the field and we could see we had UNICEF spearheading this process. It was a small group, a five day workshop. Then we have Hisp Uganda, then we have Hisp Malawi, Morgan is out there, we had Hisp Kenya in there, we had Hisp Tanzania, Ethiopia and also Hisp Uganda. So the team coming together and working together to plan on the development and also plan on the deployment. So this is a little bit of history on how we've been able to do this and it's something that we feel that we can be able to again work with so many apps and the innovation that have come through the COVID pandemic that we can be able to see how we can sustain this because they're going to be very key for the future implementations especially in disease surveillance also in the immunization registries that we are working on. So I'll turn it over to Wilfred to really share a little bit more about how we've been able to do this over time across the region and the Hisp groups. Thank you. Yeah, can you hear me? Great. Yeah, thanks Prospa for the introduction. As Prospa kind of elaborated, this work started a little bit, 2013, 2014 when we started all these work along scorecard development of scorecard internally. And then later on, we kind of formed this partnership in terms of Hisp, Uganda, HIST and the NIA, but also Universal also kind of coming in to kind of work with that, but also UNICEF played also a major role in terms of pushing this, we call that use apps. Looking back now, we see that we have gone a long way more than five years now, which have passed. And through that five years, there's a lot of learning which we have gathered. One thing is recently, we kind of understood that we really need to kind of understand which role of each organization should play in terms of working together on this particular task. And one of the key thing which we did is more kind of a map out. What are the roles of the HIS groups? First of all, HIS groups play a key role in terms of gathering information, interpreting and document this information from the field. And the HIS groups have been doing that quite a good job in terms of understanding the implementation of scorecard, BNA, action tracker, documenting this and also playing, putting it together. The HISP Tanzania and the HISP Uganda now plays a key role in terms of coordinating these other HISP groups, collecting all these requirements and later on, of course, the team kind of developed these requirements, test together with the team and of course support some of the configuration which is happening at the individual countries. One of the key things also we have kind of learned throughout the process is more or less about documenting these usability of these apps, kind of understanding how the user perception of these apps and also kind of understanding the better aspect of the configuration. Together with that, we have also been working with the HISP global team here. They have been playing a key role in terms of oversight of these particular implementation of the app, especially on the development aspect, the quality aspect and see that we kind of, you know, the development of the HISP groups are kind of also tying into the standards of the global thing, global teams. They have also been kind of playing a key role in terms of coordinating, coordination, the HISP groups, but also kind of putting together some of the activities which we have been working on. Last but not least, the UNICEF team has also been quite an instrumental. Maria, is she here? Okay. Yes, Maria has been kind of instrumental in terms of working together with the HISP groups, coordinating the project kind of, you know, pushing together some of the requirements which UNICEF have, but also some of the requirements which the country has. We have been working with the UNICEF team in terms of making sure that we also follow up some of these plans which we have along the way. So UNICEF has been kind of quite instrumental in terms of supporting us, but also kind of be part of the process as well. And I think that has been kind of a key thing during this particular collaboration. So this is kind of an example for joint roadmap in the release plan, which we kind of had so much information right there. But one thing which we kind of noticed that we have kind of different layers of activities which we have. We have the implementation activities which the HISP groups are more or less kind of for supporting countries into, you know, implementing the scorecard, BNA and action tracker. Once all these HISP groups implement, get the feedback, we sit together at least quarterly fashion and also kind of discuss these things. And along the way, the requirement kind of change. I remember when we started 2016, we were only thinking about three apps, only scorecard, BNA and action tracker which is kind of linked to the BNA. However, as we kind of continue to progress, we noticed that there are some organizations which are doing the action tracking without doing the BNA. So there was a need to kind of say that we really need to develop a standalone action tracker where people could actually track some of the actions which they've agreed. And this kind of evolved into developing a third or at least another app which is an action standalone action tracker. So some of these plans which we have kind of divided into quarterly, some of them divided into monthly, some of them divided into weekly. We have these kind of bi-weekly meetings where we meet together, discuss a little bit of what is going on, plan together and also coordinate some of the activities. Recently, we have also been trying to push out some of these information to the HISP groups, other HISP groups so that they could understand what we are doing and also implement. For example, HISP West Africa have been showing a lot of interest in terms of implementing these particular packages and we've been supporting them as well. But recently we have done a webinar which support of course by the HISP Global Team in terms of creating the materials and also hosting this webinar and share some of the information which we have so that not only the HISP East Africa could learn about it but also the larger group within the HISP community could learn and also could continue with that. So this has been kind of a journey which we have been kind of going through in terms of learning, working together, learning through that process and also sharing now our experiences and knowledge to the community so that they could also understand and also take it forward to another places. Then I will welcome Scott to continue with the presentation. Is it too hard? Yeah, it's good. All right, so I'm gonna talk a little bit now about how we can sustain some of these innovations and as Austin was pointing out, we have a lot of tools to have innovation but I don't think that we have collectively sorted out how do we actually keep these innovations going long-term and what does that look like? What does that look like from you guys? What does that look like from the core perspective? And so that's what I'm gonna go into a little bit. First, I wanna talk about some rationale or motivations for why we would have an extensible ecosystem. The first one is that essentially, there's a lot of benefits to having an extensible application. And a lot of the applications you're having to make decisions, should I do it in a generic way or should I do it in a custom way? And if I do it generically, what's my end goal, right? We have conducted, I think about 15 interviews with nearly all of the groups represented in this room today, a lot of you personally. And what we have found out is that you are making apps not be generically, not necessarily because you wanna share them with the world or maybe you do, but that's not your primary concern. Your primary concern is that you have multiple DHIs to implementations that you're managing that require the same functionality, the same application. So you make a generic app in your organization and use it in the various implementations of DHIs too that you as an organization are supporting, right? And if it happens to be good for the rest of the world, great, I'll put it on the app hub. But once it's on the app hub, what happens? How do you sustain it, right? It's essentially most folks are just putting it out there and hoping that it somehow lives on forever. And what we're seeing is that's probably not necessarily the case. There are many advantages for you all to make applications. First one is that you are able to move much more rapidly than the core. If you send me a JIRA ticket, who all has written a JIRA ticket that I've responded to? Yeah, a lot of people have at least this side. This side's not so engaged. And it takes time, right? We are at, so right now we're on JIRA ticket like 15,000, but last week we just submitted, we just completed JIRA ticket 87, right? 2016, all right? We're still working on it. It takes time to get stuff into core. We move slowly, we move incrementally, we test, it takes time. But with applications, you're able to move much more quickly, you're able to be responsive to specific requirements, to specific projects, you're able to be more agile, you have a closer connection to the actual end users. And you, and that's a huge advantage. That's what we want. We want you to be able to do that. You're also able to stretch DHIs to beyond its current confines, right? You're able to go into new domains, like education, agriculture, climate change. And you're able to thrive in these new domains because you're able to extend DHIs to with applications. These are good things, but there's also potentially some important questions or challenges that we have to address. How can adopters be assured of the quality of the application? So if you put the application on the app hub, how does anyone know it's a good app? Well, we've asked you and you told us you don't. In fact, you don't trust most of the applications that are on the app hub. You have no insight. They're basically a black box to you. You don't have enough information to know should I adopt this application? So we actually see that adoption from the app hub is relatively limited, right? That's not what we want. We want people to be able to get apps from the app hub, know the app is there, it's good quality, you can trust it, you can use it, and we want you to collaborate and share, right? You don't know how the app is going to be sustained. So if I get an app from the app hub that someone else made, how do I know it's gonna be there in six months? How do I know if I upgrade to a new version of DHIs too that it will also be supported in that version? You don't know. And that's a serious limitation. And then once you have an app, you're not sure with how to deal with support. You're not sure how to deal with feature requests. You're not sure if my app gets adopted, if I'm Hiss Uganda and my app gets adopted in Sri Lanka, for example, how do I deal with any of the feature requests coming from Sri Lanka? Are the people who paid for my app in Uganda going to pay for the Sri Lankans as well? You also are not able to build a roadmap. So you're not able to communicate even if you do want to do something. This is what I'm gonna do and galvanize support around it. And then funding, at the end of the day, it comes back to funding and automate a few very salient points about things become cheaper if you start to use some of the resources and tools of the app platform. But these things do cost money. And we have asked, we've done a lot of interviews and very few, if any, have what I think most people would consider a sustainable business model, business model air quotes, right? We're not a for-profit or anything here. But you don't have a predefined stream of revenue to be able to continuously develop, support your applications, right? So a few problems, let's talk about some ideas here. The first one is you've told us that you want to see when you look at the apps on the app hub, essentially what the plan is for that app. You wanna know who supports the application, both technically and financially. You want to know the status of the app. So is it in progress? Is it actively being supported? Is it being only updated with new visions? Is it no longer supported at all? And you wanna know some financial information about that application. You wanna know, is it completely free? Some apps potentially charged for use under the DHIs to license, that is a possibility. Some apps only charged for support. So if you wanna functionality, you gotta pay me to help, you gotta pay me to build it. Some are wrapped up in other bundled services. And this is a frontier of DHIs to app ecosystem that is we've basically not researched at all. What are the models? What are the ways for you to sustain your applications? And this is something that we wanna hear back from you. We wanna know what you think are some reasonable ways that you are able to make apps, put them out in the ecosystem, have adopters, and be able to continuously sustain those applications. We asked 15 app developers what they thought the best end goal for them would be. And we were told, what's the ideal outcome for your application? And we were told 15 times that it would be brought into the core. That it become a core app, right? And that's possible in some situations, as Prosper pointed out, we drag some of the functionalities from like scorecard into the core. But for the vast majority of applications, that's not possible, right? And what does that mean? That means essentially we're just making innovations, we're putting them out there, and they just die, a slow death. And that's not benefiting anyone. So we've got to figure out not how do we drag everything into the core and University of Oslo owns everything, but how do you come up with models and how does University of Oslo support those models to continuously sustain these applications? And looking into kind of the financial aspect of it is something that we have to figure out. Now, as Prosper and Wilfred made clear, I think, and certainly a lesson that we learned from COVID is that we have got to collaborate. We have got to foster collaborations, and the collaborations means between app developers, like Tanzania, Hishigonda. You know, every year we do this app competition. It'll come up on Thursday. And in that competition, we have probably five apps that are submitted to import data for DHI's too. Even within DHI's too, all of you sitting here, we're reinventing the wheel constantly, right? You all have shared problems. You're just working in isolation. You don't know that you have shared problems. And so we have to make some kind of means for you to share your issues and for to connect to those other DHI's too providers, app developers who are able to collaborate with you to work through these shared issues, because you're not really doing it as it stands right now. And this is, I think, a recipe for disaster. We need to make sure that you're able to connect, you're able to communicate with those who have shared issues, and you're able to build apps together. The more people working on applications and contributing to those applications, ultimately the more sustainable it'll be. That's a double-sided, there's two sides to that point. The other side is those who want to use the application, you need to be able to have a community, kind of a micro community of practice around the applications that you're using, right? So if Uganda's using the application and Sri Lanka's using the application, then they should be able to communicate. They should be able to say, hey, we're also using this application. We having these issues with the application, can we collaborate and work together to improve the application? Or what are some of the best practices with the application? We have this community practice for DHIs too, and we were talking about DHIs too, we're talking about dozens of apps, but what we really need are small community practices just for each individual app that brings together the users of those apps across various geographies and domains so that they can collectively work together and share insights, potentially support one another in various revenue streams as they come up. And then the last one is we've been kind of toying with the idea and we've asked you guys, what would be some other good ways to kind of spark or jumpstart this degree of collaboration? And so you've given us a couple of things. So the first one is it might be cool if UIO could foster application, like we could put out application challenges. So we have the app competition, but maybe we hear about shared problems and that we can put out a challenge to the community to get a consortium of organizations, DHIs to implementers, app developers together to address that problem. The other one is we can put out ideas, right? So we ask for an idea challenge and you tell us your shared problems and then we try to connect the dots because that's I think our role, our role is to try to connect the dots. Our job is to make sure that you all are able to talk to each other. You're able to collaborate and we have to make sure that we're doing that around the app specifically. So I think with that, I will now hand it over to Pamud and he'll take us through Sri Lanka. Thanks very much. Right, good morning everyone. So what I will do is I will explain to you how we use the local innovation through collaborations and country capacity building during the times of COVID-19 pandemic in Sri Lanka. So apologies for those of you who are already familiar with the story but I assure you what we are going to do today is to look at it from a different perspective of how we did the local innovations and capacity building and what we really, I mean how we invested on the collaborations. Right, so I will start with this slide. I think you must be already familiar. This was from Christine's presentation yesterday. So what you see here is an extract from a Norwegian newspaper. Remember the date, it's February 5th, 2020. Right, so this was in the early pandemic and in this newspaper article, it was highlighting how a product of Norway is being used in Sri Lanka for contact tracing and COVID surveillance while in Norway, they were basically using pen and paper. Right, so this I heard was a big story in Norway. So let us see like what really happened in Sri Lanka by then. So this is a timeline of all the events that happened in Sri Lanka in the early pandemic. So we all know that COVID-19 came into light in December, 2019. And Sri Lanka being a tourist destination, we were very vulnerable because I think the second highest country we get tourists from is China. So it was spreading rapidly in China. So the country was really worried because we did not have a proper information system to do disease surveillance, a digital information system. We had a paper-based system, but of course like we did not have a proper digital system which was interconnected with all the stakeholders, not just the health sector. So we had some discussions with the Ministry of Health back then that was around January 20th. And we had the first case of COVID-19 around 26th or 37th January. But by the time we reported the first case, we were able to design a system based on DHIS-2 to do the port of entry screening. So how is this possible? This again is a screenshot from our DHIS-2 Slack channel. So we are using, I mean, we as in the UIO and all the HIST groups are well connected. In addition to using the community of practice, we are having this Slack. And what we usually do is like whenever we see something new happening in any of the countries that we are supporting, we usually share it. So again, the date is on 29th January. So I shared what we did in Sri Lanka. So this was like ready to be piloted. In fact, like everything was ready and I just mentioned here that we are planning to launch it tomorrow. And this again from 31st January. This is a newspaper particle from Sri Lanka where the Ministry of Health informs the parliament that I must mention, they mentioned it as a group of doctors have produced an application for digital surveillance. I will come back to why they mentioned a group of doctors. But it's quite interesting, so whatever we did in Ministry of Health with the team, with the core team was rapidly spreading in a matter of few days to Norway as well as within the country. And this is what we had by May 2020. So within a period of four months, we were able to design many modules. So these modules were not produced overnight. It was kind of produced incrementally based on the changing epidemiology of the disease. And most of these components were customizations on DHS2, but I must mention there are few applications. So custom developments, local innovations on top of DHS2. So let's see what really happened and how we were able to produce these local innovations. Right, so we all know like when we are implementing DHS2, we usually customize the DHS2 platform. So that's what we initially did. We use the DHS2, the core platform and we customize it. So we were able to produce nine modules in like for six months of COVID-19. They were both aggregate and individual, to collect aggregate and individual data. But the challenge was that we were not able to meet some requirements at that time using, I mean, the core modules and customize in the DHS2. So this was when we had to develop components on top of DHS2, that number one. And the second thing is we had to integrate, right? So it was not just DHS2, which is the only system used in Sri Lanka. There are so many other systems. And I mean, people were very enthusiastic. So they were producing many solutions and we had to integrate with them. So I showed you like we were well connected with the UIO and the HIST network because I have already informed them back in late January that we are doing these things. So when it came to development, we only had by that time just one developer. He was our lead developer in his Sri Lanka who has been there with us for so many years, but we could not actually reuse him to cater all these requirements. So this was when I informed Ula, like we are kind of stuck. We have to develop some components and we only have this one fellow and we need support. And I must also mention like his Sri Lanka and Ministry of Health were not alone in this entire thing. We had very good support from the government of Sri Lanka. I'm in fact glad to see the chief technology officer of our government ICT agency of Sri Lanka is present here in person, Mr. Hiranya. So what actually happened was the ICT agency of Sri Lanka was working with us. So they said like, don't worry. We have people, we can arrange people. We can get them together. It's just that you need to provide us guidance. So we had UIO and his network from one side who was ready to help and we had this local support from the ICT agency. And we kind of linked them together by organizing this hackathon. So it was a collaborative effort between his Sri Lanka and volunteer developers. So these were developers from various private sector ICT companies and then volunteer developers. I mean, who are doing freelancing. And we also had the Ministry of Health, the ICT agency UIO and our, his network supporting us. So we were able to conduct this hackathon mostly virtually, but we had few people gathering at the ICT agency office. And I must also mention Austin here was the one who was kind of, I think I troubled him a lot. He had a couple of sleepless nights trying to help us online from, you were based in France that time, right? Yes, okay. Right. So with all this, we were able to design this COVID-19 surveillance package which we were able to implement in Sri Lanka. And the other thing is like we often overlook thinking like innovations are always tech solutions like web apps or Android apps. But what about training, right? So we were used to do trainings physically on site. But during COVID-19, we had to revise our training approach. So we were, we had to conduct trainings online using platforms like Zoom. And in addition, we had this lengthy training manuals. You all know what DHI has to manual looks like at the moment, but it is very lengthy for a reason. I mean, it is not supposed to be the end user manual that you should try to introduce when you're doing training programs. But what we actually did was to come up with this single page training manuals, right? So we were able to share it together with our training programs. And that again, was an innovation. And with all this, we were able to do, I mean, have a local use. And the most important thing, like all this while we were connected with the UIO and the HIST network and they were working parallelly on a kind of a metadata package so that all the countries can use this innovation. So it was something that was produced in Sri Lanka and few other countries. So UIO coordinated the entire effort and we were able to produce this COVID-19 a digital health toolkit. Right, so this is like all the modules that we have around COVID-19 surveillance in Sri Lanka. But I must highlight the arrows that you see in yellow, right, the ones here and there. So these are all integrations. So we had to integrate with laboratory systems. And also during the immunization campaign, I think those of you who joined the immunization session yesterday, I mean, I presented what we did. Like, so we use this digital public good to I work to produce our vaccination certificates and we had to create these integrations. So this again, was a lot of effort that took place during the COVID-19 pandemic. Right, another example is our contact mapping visualization application. So this was the one, I mean, one of the very early applications that we built, I think it was in March, 2020. So our team and the ICTA team were working together to produce this application. So this is a very basic one. And what actually happened was, I mean, once after the produce this thing and this again was posted on the community of practice. And based on the interest, the UIO figured out that it could be made more generic. So we can share it across the network. And that was when with support of Austin and his team, we were able to produce this generic contact mapping visualization app, which is already there in the app hub. Right, so this again, was a collaboration. This is not something his Sri Lanka did alone. Again, another one to track, I mean, in early days of pandemic, it was like we wanted to track people based on their mobile phone location, like, which was a bit unethical, looking back at it retrospectively. But yeah, like, but the solution was ready. It's not that we are not saying like this was put into full use, but the solution we prepared because there was some requirement. And then this was about ICU bed tracking. So we often say that DHS2 is not a EMR, but during the pandemic, what they wanted was not to see like, what's the diagnosis? Like what has been the treatment course of the patients in the critical care unit? No, they just wanted to know where the beds were available. So we just realized that DHS2 tracker capture application was a bit too much to be trained and used by ICU staff. So we created something very simple with this, like we do just have some few bed icons, which they have to tap on it and to kind of change the colors to see whether bed is available or not. Right. So all this was possible due to many reasons. So one very local contextual reason how we were able to do this was our long-term capacity building. I will briefly mention what this is. This again, actually it's a long-term work. So all this happened in 2009, a decade ago. So the University of Oslo and the Norwegian government had a collaboration with the University of Colombo to create a master's program in health informatics to train doctors. So they were like, I mean, up to date, more than 400 doctors have been trained on digital health. So if you ask why doctors, that is again contextual because in Sri Lanka, most of the administration and at national level and district level are medical doctors who are trained in specializations like administration, public health, and now we have informatics. So this is why the Ministry of Health when they were reporting to the parliament group of doctors is because of this, right? So in fact, most of the senior implementers in our history Lanka team are products of this master's and then we have an MD or a local doctorate program. I know, or actually they have completed the PhD program from the University of Oslo. So what actually happens is University of Oslo produce the capacity, right? So they do the PhD program and once they complete it, they go back to the global south. For example, in Sri Lanka, we have two of them. So they contribute back to conduct this master's and doctoral program. So these people were already, they are at national and district level. So it was very easy for us to communicate with them what to do because they were well familiar and we were well connected. And they not only trained, I mean, other doctors to do stuff, they also train the allied health staff including nurses, public health midwives and other people. The collaborations. So it's all about collaborations. I must say this was the key most important thing. So what you're seeing here is one initial meeting we had in person, very few people at ICT agency back in March 2020 just before the hackathon. So we were actually planning for the hackathon. So we had collaborations within the country. We have never been able to engage so many different departments within the ministry of health before. But during the pandemic, it was possible. I don't know why and we are actually observing closely whether it'll routinize and it'll continue to be so after the pandemic. And then the government ICT agency, as I mentioned before, they were really providing us the infrastructure. So we were using, I mean, later of course we had issues when it comes to COVID-19 immunization where we registered the entire 21 million population in DSHS too. So with that, we had some performance issues which I have presented yesterday, but the thing is we were thankful that we were kind of hosting in the government cloud. So they could provide us the resources and they were really prioritizing and they were never hesitant to provide us resources. So that's the infrastructure side and they also provided support through their network. And then again, sharing of metadata and web applications. So like it was not just Sri Lanka doing it. We had Sri Lanka, then later, I mean, we have already seen how Uganda was contributing. So we had all these his groups contributing to create this metadata package and other innovations which was shared across the network and use of digital public goods. I think you will get to hear more about digital public goods on Thursday. So DSHS too is a digital public good and we also use another digital public good, Daivok. This again is contextual because our government ICT agency was on the opinion that we should invest more on digital public goods. But then again, it's not an easy task. So more innovations, more DPGs, you need a lot of capacity and infrastructure to sustain it. It's not, it's one thing is to implement it but sustaining it is the challenge. So in fact, this was kind of the support that we got from the ICT agency. So this is a tweet, Gauta Kelke is ICT agencies, country ICT agencies, social media channel. And it was, it is actually Hiranya was rich, I mean, posting this. So interesting thing to note here is like they are requesting some urgent help from a front-end developer who has some tech expertise and important thing is no prior expertise needed on DHS too. Why? It is because we had support. I mean, we only had one person in our team that time but we had support from the University of Oslo Co team and the HISP. And that is why we were not really keen on finding anyone who has prior experience on DHS too which was impossible to do in like a couple of days time. Challenges and how we approach them. So there are a lot of challenges. Now, first thing is about engaging stakeholders. So the thing is like it's not the infrastructure or the technology. I think we have so much of infrastructure and technology. It's always about the people, right? So without the people, you can't implement the innovations. You can have innovations. You can develop innovations but they will not be put into practice. So that is why it's always about engaging with stakeholders. So these stakeholders, I mean, these are about soft skills of your organization and even the stakeholders that you are dealing with because like if a country feels, if the ministry feels that you produce something that will be put into good use and you will be there to help, you are not just there to introduce a solution, just pilot it and get the research data and disappear. Then the next time you go there and try to implement, they will not support, right? So it's, I mean, these are not computers. People have their own memories, right? So and trust. So the thing is like the more you create trust with, I mean, in minds of people, it is very easy for you to collaborate. The local capacity and skills is a challenge. So we still have that challenge because the thing is like we are a small team but it's just that we are managing with the help of everyone else. But the issue is the more capacity and skills that you try to retain, you need more resources, right? You can't just keep developers idling in your team. It's costly. It's again a very valuable human resource. So this can be a major challenge and the financial support for development and integration. So we all love apps. We like innovations. We like nice things. But the thing is we don't tend to realize that integrations really cost. So when it comes to solutions, there are people who are there to maintain and fund the platforms. But the connection between the platform is a really costly thing that you have to kind of continue for the entire lifetime and the people don't really tend to realize, right? So this is one challenge because you will have some initial funding to support the integration. But in the long term, this becomes a major challenge. And again, something to do that is the sustainability of innovation. So this again, I think previous presenters already mentioned, like, you can kind of innovate something for your country. But when so many other people start using it, you don't have the resources to assign from your team to cater all the requirements. So this again can be very challenging. And finally, networking in the community. So I think I have heard discussing with few of you. The main challenge that we had in most of the countries was that during the pandemic, TAs couldn't fly into the country, right? So if the country did not have a proper capacity and if they are not part of a network, they were isolated and it was not possible. But for us, I mean, for his Sri Lanka, we had very good support from the UIO and all this awesome, his network. And I'm really thankful to them. So we have many of them, the logos that you are seeing now. So it's all together 17, his group. So thank you very much for your support during the pandemic. Yeah, surprise. Can you hear me? Hopefully you can hear me on Zoom as well. Yeah, good, great. Thank you very much to my fellow presenters here. I think it's inspiring and interesting to hear the stories of collaboration and working together to solve problems, especially in a huge time crunch as it was in March, 2020. I do remember some of those sleepless nights. I remember the weekend specifically when we were working together. And it was very early also in the working from home, everybody connecting remotely, world that we were living in. We had been a remote organization for some time, but it wasn't something that everyone was familiar with. So there was a lot of radio silence. And it's, what's going on? Do you need me? Should I wake up at 3 a.m. or should I not wake up at 3 a.m.? I didn't that time I think because they didn't need me for everything. But it was really inspiring to be a part of that with Sri Lanka and also with the larger community. And just before I get, I switched back over to the other presentation. What Pamud was mentioning about the innovations that Sri Lanka spearheaded in this COVID pandemic work. So much of that has fed back into the global DHS-2 and all of the different regions around the world that use DHS-2. So there's the obvious one of the metadata package for COVID-19. There's a lot of innovation in or challenges that we're run into with the relationship model in DHS-2 tracker that are now being improved in DHS-2 core as well. And there's, from the genesis of that hackathon in March, 2020 is a lot of the developer advocacy and developer community work that we've done since that time has come from that in that we recognized the importance of the support to developers who might not have any knowledge of DHS-2 whatsoever, but our good developers know the problem that they need to solve much better than the global team ever could. And that's something that we have really grasped and moved forward since then. All three of those developer academies have been since after that March, 2020 hackathon with Sri Lanka. So the developer academies that have each had 30 to 40 people from around the world learning how to build applications on DHS-2 were all after that time. I think it was actually March, 2020 though, I will correct myself, was after the first Android developer academy, which was also in Sri Lanka, I believe in December, 2019. Yeah. Okay, moving over back to this slide. So now I'm going to talk a little bit about extensibility in DHS-2 again. And the key takeaway that I want to share is that it's not just apps, very, very rarely, sometimes, but rarely is it just an application that stands on have infrastructure for applications in DHS-2. We have infrastructure for Android applications and web applications, but very often there's a lot of other things that need to be put in place to really make those work for the extension of DHS-2 in a robust way. And some of that is the soft skills, some of that is the training, the capacity building around those applications, but there's so much technical work that also often needs to happen around those applications. And I have some examples of that, some from the Sri Lanka example, but many others from around the world that I will share. But almost all of those, basically you need something else beyond just an application. You can build a new interface for what DHS-2 can currently do, but so often you need to integrate with an external system or you need to put something onto the dashboard in addition to having an application or you need an Android app that needs to have some way to configure it in a generic way. And sometimes you need a custom data model or a custom database or metadata packages and the interaction between the application and the metadata package is quite complex. So you need to kind of bundle those together. And that makes it costly and challenging to develop, but also to extend or use those innovations in DHS-2. Losing battery on my mic, so I will be right back. Second? Okay, so you should be able to hear me with battery now? Great. Yeah, so I'm gonna talk about a few specific examples of those innovations, what's required outside of just an application, how extensibility extends beyond just apps in a moment. And also how much of that is not technically supported by the scaffolding of the DHS-2 platform today. It's something that we have good support for applications, but everything else, you kind of need to figure out for yourself and put together and then teach other people how to do it if you want to share that innovation with others as well. And that's something we'd like to change. So the first example is the relationship mapping example from Sri Lanka. And this was an application that really pushed the boundaries of what you could do with the relationship model in DHS-2 Tracker. It also pushed the boundaries of what you could do in a browser when COVID started going crazy and this graph started getting really big and you tried to download it all and put it in your browser. That was a challenge. So there were performance issues that we ran into from the API itself, but also in the browser and being able to support that and provide tooling to let people more easily adapt to larger databases was something that was an early lesson from this development of this application, but also came from the introducing 21 million tracked entity instances into DHS-2 as a whole. So not only the extensibility and the application of relationship mapping. And so the relationship data model itself, as I mentioned, is something that was a challenge with this application that is beyond the scope of what the application itself could do. So it couldn't solve those problems by itself. And so that's something that we needed to provide and to integrate into the DHS-2 core and the platform itself to make that possible for other applications as well. Another big example is COVID vaccine certificates. So you heard mention of DIVAC in Sri Lanka, but there is also several other efforts to build COVID vaccine certificate systems as integrations between DHS-2 and some external system, whether that's custom built or it's based on the EU specification or it's DIVAC, which is a global public good. Oftentimes that is a combination of not only an application. In this case, it's often a customization of an existing core application, which is a whole nother thing, right? So you don't want to tell all of your people that are delivering vaccines who are currently using tracker capture or the capture application to learn an entirely new app just to issue the vaccine certificate. You want it to be part of their workflow in tracker capture itself or in capture application, but it's not something that is easily extensible there. So you then, going back again to the forking example, you then need to fork at least the application for data entry. Maybe you need to fork all of DHS-2 as well. But then even once you've done that and you've added the user interface to be able to issue and maybe print a vaccine certificate in a clinic or in a facility, that's not enough because then you need to somehow integrate that new interface that you've built with some external system that actually does the issuing of the certificates. And maybe also that system needs to do the verification of those certificates. So that is something that has been a challenge that has come up across many different use cases, particularly for COVID vaccine certificates, because you can't just, or it's a challenge to then just talk to some external system because you need to think about authentication. You need to make sure that if you're doing this in a sensitive environment like COVID vaccine certificates, you don't want it to just be open to the public internet. So you need to have some sort of authentication. You need to integrate with the authentication system of DHS2 and that's something that isn't easy to do out of the box and something that we want to improve as well. And then there's another whole component of this with the public access side of COVID that we all know very well. So there oftentimes is the public dashboard for viewing the statistics of DHS2. I'll talk about public dashboards in a minute, but then there's also in the case of COVID vaccine certificates, you need some mechanism of verifying those certificates and you need to control the access of who can verify those certificates maybe and you need to protect the information that is contained in those certificates so it isn't just open to the public as well. And that's another challenge that is outside of the realm of an application but as an extension to DHS2 that you need to support in the extensibility infrastructure. That is very similar or maybe one specific case of interoperability. And we see this over and over with applications that are built that integrate with some external system through the browser because the system makes it so easy to build an application and to build a new interface that you can build that, you can download all the data from DHS2 and then you can push it to some external system or you can pull it from some external system and push it to DHS2. There are security challenges with that because you need to then authenticate with this external system from the browser. And how do you do that? How do you deal with different users in DHS2? How do you share the credentials for this external system with multiple users without actually telling them what the password is, those types of things. How do you also deal with performance when you are starting to talk about 21 million tract entity instances or even just large volumes or large amounts of data coming from an external system into DHS2 downloading all of that into some users' browser that might be a Chromebook is a big challenge and something that you support that we have for applications and it also prevents you from having the user interface that an application can let you build so easily. So that's why so often the easier path is to build it in the browser without dealing with some of those more challenging performance and security complexities. Another one that I mentioned a minute ago is public portals. So COVID vaccine certificates is one thing but COVID public portals is access to analytics data from the public. And there are a lot of challenges, security obviously in accessing that data from a public website. There's performance challenges as well because if you do it the naive way where you just plug in the public portal to DHS2 core API and then every time anyone in your country or in the world goes to your public portal you will crash your server very quickly. So you need to really think about security and performance when you're doing these things. And again, this is extending DHS2 with public access to analytics but it's not an application. So it's beyond the concept of an app as the core piece of extensibility in DHS2. There's also a lot of complexity in setting up a public portal that could be made a lot easier but every single public portal, every type of public portal, every single one that is set up in a country is done separately, the wheel is reinvented. And you have to think about all of those security and performance challenges over and over again rather than having a kind of out of the box and standardized way to address those challenges. And then there's another one which is mobile apps. So this is, we have apps but then we also have apps on the web. We also have apps on mobile and the Android SDK supports the Android data capture application. It also supports many third party applications. You'll see some of them in the app competition on Thursday but even that core application requires something beyond just that one app. So it may be requires a web application as well to be able to configure the Android settings app to be able to configure globally the applications that are connecting to DHS2. And you need to store that configuration somewhere. So it also requires the data store and it requires some custom data model that maybe needs to change over time as you release new versions of the application. So it's not just that app again and there's so much additional challenges with not only mobile apps which have performance challenges as well that the Android team works very hard to mitigate. But if you have 10,000 people that are all of a sudden using mobile apps and hitting your DHS2 server at the same time that's a whole nother paradigm that you need to think about in terms of performance. And that's something that we could address beyond the scope of what we currently support with extensibility infrastructure in mobile applications. So one way to address this is to move towards what I call full stack extensions but it's just expanding the concept of applications as the thing that you do to extend DHS2 to be extensions as a whole. So that includes interoperability it includes server side configuration data model extensions, API extensions server side logic sitting somewhere. And there are so many reasons that we need this. One is because we're reinventing the wheel as I've just mentioned so many times each of those had many examples of what had been when that problem had been solved but in a different way every single time with a lot of effort spent to address those challenges or not enough effort spent to address those challenges which left them with security or performance issues or sustainability issues. It also significantly improves the ability of these extensions to be shared amongst different use cases. So the app hub makes it very easy and there are challenges obviously with sustainability and with understanding the sustainability model of those applications but it makes it very easy to put the application somewhere where other people can use it. It also improves setup and maintenance of those applications both or extensions both in the, once they're installed or set up in a particular DHS2 instance but also over time for the developer of that application or extension. And as I mentioned in the previous slides performance, security, reusability and interoperability are all things that would be significantly improved by moving to this model. I'm not gonna go into the technical details too much so I have each of these kind of broken down a bit more on the following slides but there's a lot that we can do to continue to support this concept of extensibility infrastructure in DHS2 as an extension no pun intended from applications as the core model there. So the first is guides documentation training and this is the logical kind of progression of the developer advocacy program that we have and continuing that and continuing to document best practices or good practices not necessarily the best practices but good practices for setting up a public portal for example for doing interoperability through an application why those are challenging why the easiest path is maybe not the best path in some of those cases documenting those learnings and giving guidance on how to approach those problems when you see them so that you're not reinventing the wheel and not running into those challenges afresh every time you do that. And then there's collaboration. Oops, sorry. I have a meeting in five minutes. So I will wrap up. The collaboration is a huge part of this as well. So we heard from or we will hear from the UIO design lab and there are other university innovation labs that we're working with but also in and amongst the DHS2 community in that ecosystem. I'm not sure why this didn't... Oh, Sarah. It is connecting. Apologies, one second. Maybe my internet? Oh, Zoom disconnected. One moment. And I was just wrapping up too. It was building to the climax. I can go ahead and just talk so long as my audio is still going. Yeah, okay, great. So I don't need the rest of the slides but basically the concept is applications are not the extent of extensibility. Extensibility is so much more than that. And we can build a lot of infrastructure both soft skill, interpersonal training, capacity building, community building around development of these extensions but also technical infrastructure around how we can make it easier to build extensions that have server side components that integrate with external systems and have a complex topology of all of these different pieces of extensibility, how those all need to work together to be able to be shared, to be able to be built, maintained, shared and used cost effectively and easier than they are today. So with that, I think we'll wrap up for the day because my internet isn't working and you don't have any slides. Thank you. Now wrap up the day. Everybody can go home now. You came in from 8.30 to 10. I think it's 30 minutes and we have the breakout sessions across the hall.