 Let people unmute themselves and speak on Zoom. Yeah. Because we're going to try to have more of a discussion. Raise your hand. Okay. All right, everyone. Welcome. To those of you who are here and online as well. We're going to have a little bit of a different session today because we're going to try to make this more of a discussion. I'm going to be joined by Scott and Magnus a little bit later. They both had conflicts, unfortunately. So the first half, we're going to talk a little bit more on the technical side about how we can work together to support. Innovation and extension of DHS to. And make it easier and more cost effective to, to build those types of extensions. And then we'll talk a little bit more about the, the financing and the business model side when, when Magnus and Scott joined in the second half of the session. To start off, I wanted to have something that's a little bit engaging and, and please the people that are on Zoom, please join us as well. I'm going to have this. Mentimeter. So if you're familiar with Mentimeter, I'll get this out of the way. If you're familiar with Mentimeter, hopefully this can stay. Go to menti.com on your personal device. And you will see the. Basically you'll enter the code that's at the top of this screen. And then we'll have a few questions just to get a feel for, for different people's experience with a building on top of DHS to what you're, what you're working on building. And I might even add some custom questions towards the end as we, as we work through the discussion, but to start off, just to, to get everybody warmed up put on this map, which is the, the Peters project projection of. The world where you come from. And while you're doing that, this projection is great because it's equal area. So every country is represented. Proportionally to all the other countries, as opposed to the Mercator projection, which overemphasizes the North American continent and the polls, but. But it also looks kind of funny. So sorry about that. All right. We've got a few people coming in. Great. Thank you. Wait, wait another couple of moments here. So because this is going to be a bit of a discussion, I also would like to invite everyone to think about. A discussion topic that you would like to bring up. Or something that you have struggled with or open questions that you have around sustainability of extensions and innovation in DHS to customizing it, particularly sharing those extensions. Or applications as it might be. And there's a kind of a theme that we'll talk a little bit about through, through all of this, which is. There is a choice that you, that all of us have to make as we're customizing DHS to is do we, do we build and invest in one particular local context and you can build an application that follows exactly the pattern that you, that you want to enforce or that you're, that you're to match your local context or your local use case. But then that's very difficult to share that. And so then if somebody else has to do that somewhere else, they have to go through that whole process again. And so there's always kind of a choice between, do you build for the local context in, in kind of a microcosm, or do you build something more generic, which maybe takes more effort upfront, but then has potential cost savings or, or benefits to the larger community. And what are your incentives and goals in, in choosing between those two things. So I'm going to move on to the second question here. Looks like we've got some European representation, some African representation Asian. I'm sad that we don't have Latin America here, but some, some US as well. Also, I'll put myself, I can't put myself on here. I'd have to get my phone out, but I'm on the west coast of the US originally and then Europe. So still that in a little bit. Here we go to the next one. Okay. So I put in some things that have to do with building applications or innovations, local apps on DHS to on top of DHS to as a platform. These are not everything that you have to consider, but between these, can you rate, rate them each between very easy, meaning that you don't even have to really think about it. Probably none of these you don't, you don't have to think about it all, but maybe to very difficult. So that means that it's, it's something that is so daunting that maybe you don't even want to want to consider it. I want to do it. Interesting. So yeah, please fill in each of these bars and we'll see what the, what the averages are in just a minute. Tough race. I'm not sure if I can see how many people have responded. There we go. Understandably, it looks like financing is in the lead, which will be the second half here. But they're all, they're all actually fairly, fairly even, which, which is an interesting dynamic. I kind of thought that, that we would have a very clear winner here. So we'll come back and discuss this in a little bit. Maybe it's just hard to estimate what's very difficult and what's very easy. Okay. So just to get a feel for the audience here who, and when I say you in this case, it could be your organization. It doesn't have to be you personally, but it does have to be you personally. So I think that's a good point here. Here has built a DHS to web application as your, as your application. Or as your organization. No Angular fans in the audience. I like this. Very even once again. Okay. We have one, one person who's built something. Using who didn't use the app. I'm two people. Okay. Interesting. We'll, we'll have a discussion about that. If you, if you answered the second point here, if you don't mind to get ready and people on zoom, we will have the opportunity as well for you to join this discussion. So if you would like to contribute to the discussion, feel free to raise your hand. And Alejandro will be able to unmute you. Give you the opportunity to unmute yourself, I suppose. Okay. So pretty, pretty evenly split here between yes. And we use the app platform to know, what we will in the future and know whatsoever. Interesting. So now we're going to have the same question, but for Android applications. So this is something that maybe is, is a little bit less common, but can be quite powerful. If you build custom data entry is supporting offline data entry using Android. Or I should have said maybe mobile application. So let's, yeah, let's, let's update this in real time to be, have you built a mobile application interacting with the HS to obviously if you have built one that is not on Android, you have not used the Android SDK. See that would be your answer in that case. All right. We have a few people who have built applications. Mobile apps. Cool. Again, I might call on you to share your experience here in a, in a few minutes. And then this is a free form text. So in this case, if you've built an application, if you think about thinking about building an application in the future, if you're thinking about extending the HS to in some way. So building some sort of functionality outside of what it can do out of the box, what are you building? Just tell us generally what, what is that? Is it a. Maybe a new way to configure DHS to in a custom way. Maybe it's a. Maybe it's a way to import data from an external system. Maybe it is a. Custom data entry application for a particular workflow that you want to optimize for. Outbreak management, for example. Yeah, interesting. All right. So feel free to fill these in. For those of you who are joining us. We're using mentee meter just to get some, get people kind of warmed up. This will be more of a discussion. So feel free to think about what you want to contribute to that discussion. And you can join the mentee meter poll on when your phone or your computer mentee.com with that code at the top there. Okay. This is quite, quite interesting. Metadata packages. I'm going to give, give people a little bit more time to, to write through this one. Tracker to aggregate tooling. Emergency pilot. I'm curious what that is. All right. I'll give a 10 or 20 more seconds to put in what you. Geo validation tool. I would like to, like to discuss that one whoever, whoever put that in. So. All right. We'll talk. Whatever we can do in DHS to snarky, but I like it. Yeah. So we've got 18 people in here. Cool. So we'll, we'll, we'll leave it at that. We'll come back and discuss some of these points in a, in a minute as well. And I wanted to quote people in again saying that making apps in DHS to get 50 times easier with the app platform, which he told me in the, in the hallway the other day, which I thought was quite, quite a vote of confidence. So thank you, Pete. All right. So let's look at, let's look at some of our answers here if we can. And maybe I just got rid of them, but I hope not. All right. Let's, let's go ahead and look, look at some of our answers here. And for those of you who, who joined a little bit late, I'm not sure if you can go back and see the, the previous questions, but if you weren't able to answer them live, you can still contribute to the discussion. So we're going to try to make this a bit more of a discussion and hear from, hear from all of you about how, how you're extending DHS to the challenges that you face. First half is going to be more on the technical side. Second half more on the financing and business model side when Scott and Magnus will, will join me. So right now we're talking a little bit more on the technical side of what, what challenges you face and how you, how we as a whole community can work together to make it easier and more efficient to build these applications. Okay. Cool. So people can, can put in their, their answers still on this question. So I want to highlight this. Second bar here. Yes. But we didn't use the app platform. So can anybody who, who answered that question. Answered the question with that answer, can you raise your hand and yeah, okay, great. Can you tell us why and what, what, what caused you to make that decision. Yeah, we have a microphone here and feel free to raise your hand if you're on zoom to contribute to the discussion as well. Introduce yourself to if you'd like. Introduce yourself to if you'd like. Yeah, basically for us, yeah, okay. Yeah, for us it was a couple of things and probably Alexis over there that is the developer kind of spring a little bit more in detail, but basically it doesn't fit too much into our current architecture that we are using in architecture. So the kind of hooks that you have, that you have this use date and these kinds of things were a little bit difficult to put into our architecture. Then from very long time we also have like a library to communicate with the DHS D2 API. So it was about throwing it away and using something new that is always a little bit painful. We also have like a library of component. There was D2 component, same thing was like after a lot of work. Then we are also a little bit scared because we're using TypeScript. And you tend to use, I know that platform is TypeScript as well, but you tend to use flow in general. It's a little bit scary to do this kind of movement when you have invested a little bit of time. Sure. Yeah, so just to address that last point specifically, that's maybe a little bit on the technical side for the audience here, but we do support TypeScript. I think we would like to think more about how people would like to use that, build types into our library. I was talking to Hendrik about that the other day as well, to basically make it easier to use with TypeScript. And we do use flow only in one application, I believe, in the capture application. In all of our other applications, it's just JavaScript at the moment. And so, yeah. That's all for us. We move into typing everything like a couple of years ago. And it has been like again changing for us, like in terms of testing, otherwise you need to have like a very good team for testing. We are not all big. So to have everything typed is particularly useful for us to detect changes, errors, and these kind of things. Yeah. Yeah. The capture app is also moving to TypeScript from flow as well. It's a longer effort though. Alexis, I don't know if you maybe want to add something else. And this is getting maybe a little bit technical, but I think it's interesting to hear the, yeah, people's opinions. And I think what, what I'd like to see come out of this particularly is we, we all are in, in this together, right? And we can all communicate more and talk about where, where those challenges are, where we see the challenge of like this introduction of this new tool, which maybe for some people makes things a lot easier, might also require or seem to require you to rewrite a lot of things that you already have for, or to reimplement things. And that's not what we want. So we, we need to talk all of us, the whole community more about that so that we can address those because there might be ways that we as a community can also make it the transition or the migration path. It's easier so that it's, it ends up in, in the right place. Well closer again. Yeah. I said it began building react applications maybe five years ago with the user extended up. So there was no application platform yet at that time. And we already had like a way to go and to build applications and our library components, et cetera. In the recent applications, we have tried to use the tool UI, the new UI library. And it's been quite great, quite not because of typescript because we don't have like the type safety, but we have built our own types on top of it for the components that we use. So we could partially use it. The biggest robot has been like the communication. If you recall two years or three years ago, when you began with the app platform, we tried to use the user query and data query in time. It's your technical, sorry. Come back for the second half when we talk about financing. We actually tried to use the data design and the, the hooks that you introduced. I think there's a commit from, from me on the original before using react query. Yeah. But we were using, we were developing D2 API at that time. And the API, it's not only about the component being typed. It's the actual response from the server, from the API that it's been sent. And right now, if we move where we try to use the hooks, it's like a few, it's unknown. You need to actually go to the documentation page, the stimuli page and check what's in there instead of having it on your code editor. So that's the main problem of using the app platform. It's not that we don't use it. We actually have the provider on top of it. We use the header bar there. We wanted, we could use the use alerts or different layouts that you are introducing right now or the offline support. But it's difficult for us to embrace it like a full. Yeah. Yeah. Those are all things that we've considered and that we have. We would like to support better. So typing of responses is something that's, I think, particularly interesting. And that's something that can be quite a challenge when you are working in a world where an application might talk to multiple versions of DHS to. So that's something that is, is a challenge, but it's something that would be, I think a big benefit going forward. Okay. And feel free to take it back and not make it, not make it in the, in the weeds with JavaScript and TypeScript, because we could go on for a long time quite possibly. There was another answer up here. Do you want to share the mic? Yeah. I'm Hayden from Oriole Global Health. I don't actually have a really interesting answer for this one. It's just that it was more just a case of time frame. And I'm absolutely going to be using the app platform in the future, but we had to get something out quickly. And I just didn't have time to familiarize myself with it at the time, but you know, it's all going to move over there. I'm looking forward to having something on your store one day and hopefully people using it. So, yeah. Great. Yeah, look forward to it as well. Anyone else have a comment here? If you, even if you answered a different answer to this question, I just, and would like to contribute to the discussion. Totally fine. So would anyone else like to share anything about development of web apps and DHS to. That's okay too. So now we're going to talk about Android applications, which is much fewer. But I'd like to actually ask the question here, whether you answered yes with, with the Android SDK or without the SDK, not talking about that at the moment, but what, what did you find appealing about making a, a mobile app or an Android application? And how did that serve your use case? Particularly. So was it the offline capability, the mobile form factor, the device that, that maybe frontline health workers already had with them? Why, why was that an attractive thing? So to feel free to raise your hand on zoom or in the room here. If you have built an Android application, if you think you might want to build an Android application in the future, why, why would you do that? Why would it be interesting? Anyone else? Okay. We can go start with you. Okay. So we have basically been like two different kind of Android application. Yeah. One of them are simply forks on the official Android application, where we basically implement like kind of. It's okay. Okay. Where we basically implement like kind of shortcuts that help like for clients that are not used to the edges, help them use the edges. Basically, I don't know, like a screen that you come into the app. But the first thing that you have is a way of scanning a barcode. And then you're straight into the regular flow. And the other kind of application are mainly related to logistic before the Android official app was capable of scanning barcode and this kind of things. We were working with some clients with PSI and so on, on basically scanning a pharmacy stock and this kind of stuff. And this is the typical use case for us. And then why, why, because the Android application was already there was the reason that you chose the Android platform rather than a web app, for example, in some of those use cases. For the use case, because it's basically isolated area, like flying capabilities as you said, when it is about logistic is usually more useful to have a mobile phone than a laptop. Yeah, exactly. And then also like a few years ago, when we were talking about the analytics capability, like they wanted to have charts and it was not there already. Yeah. Anyone else want to contribute to that discussion? Are we not not Android fans in this room? It seems like. Yeah. Yeah. Thanks. I'm going to repeat that for the, for the people on zoom, but basically said that haven't done it yet, but would do it for the same reason, which is offline capability. I think the, the logistics use case is a really interesting one. And that's something that our LMS team has, has been putting a lot of thought into. Because when you receive a shipment of a commodity or a drug of some, some kind, and you don't want to manually enter the barcode number into you, into DHS to, you can actually just scan that automatically fills out all of the information that then has checks, thumbs to make sure that it's actually entered correctly and all of these different things has offline capability. Another very interesting use case there is text to speech or speech to text. Sorry. So rather than going through and looking at your stock and how many you have left and then going over your computer and typing in and then going over or your Android phone and typing in the number, you could actually just say paracetamol five units or something. And that would actually enter that information into, into the system. So I think there's a lot of interesting potential for innovation there in the mobile space. Okay. So this one's going to be going to be interesting. So this is what people are building on top of DHS to as a platform. There's a lot of interesting examples here. If there's something that you'd specifically like to share or discuss and particularly if you have questions for the core team, but also more maybe even more importantly for the rest of the community here about what you're building, about how, what other people's experiences have been building something similar or if other people would be interested in that same thing. Let's, let's talk about that. And so I'm going to open it up. I think it was the geo. Yeah. Geo validation tool, which I think is a, is an interesting one that's a little bit different than some of these others. So we'll start there and then anyone else get, get your comments prepared so that you can raise your hand. Hi. Yeah. So. We, we've done a lot of like the specific assessment for entities. And during the data collection process, they take, you know, the, the latitude and longitude of where they're doing their survey. And then they, you know, collate all that data and give it to us and we bulk upload it into a, into our instance. And what we found when we then started mapping that information is that, you know, most of the data was great, but occasionally you'd end up with like three or four surveys that were in a hotel outside of the IU that they claimed the survey was done in. And obviously that started raising questions about the validity of that data point and things like that. So we did some searching to see if there was any way of sort of that, validating that data within DHIS too. And there are a few questions on the community. That didn't seem to say there was anything there. And I know that WHO had in their bulk upload tool, apparently they did have this feature, but that's since been removed because it wasn't reliable. So what we've done is like just build some scripts that basically do this outside of DHIS too. And that's fine for our purposes at the moment, but you know, if you start doing this on a huge scale, it just becomes really a pain to do. So the plan would be obviously to build an application that can either check data before you put it into DHIS too, or target a data set or some events or tracker, and essentially just look at where that data, what IU that data claims to reside in, and then look at a data element like a geo data element and just run a little point in poly check to see if it sits there or not. And then what we've done for, you know, our purposes is build like a very, very dirty little website that you basically put these incorrect values in and it just shows you the point where the data says the event took place and the IU that it claims to be in and you can just correct it and you can like do a little search, you know, for the do it. I don't know what it's called, an address look up and actually sort of see where it should be. And it just makes it easier to do this because a lot of the time you send this data back and you go to these geo coordinates are wrong and they're like, well, how do I fix that? And you go, go on Google Earth and find where it is. You know, and there might be 50 or 60 of these. So yeah, I've done some asking around. I don't think anyone else is doing it. I don't want to repeat work that other people have done. So far, I think I might have an original idea. Has anyone else had this problem? And are they working on it? Yes. Yeah, you can hear me. Great. Thank you. Is his idea original? Has anyone else done, has anyone else done or run into issues with basically validation or quality of geographic data in DHS too? So that might be org units, the org unit hierarchy itself, which can be a pain to manage. And there are that same exact problem can be found in facilities that are maybe their, their location, their point is outside of the district that they claim to be in the bounds of the district that they claim to be in. And if you have 500,000 facilities in your, in your org unit tree, it'd be very difficult to do manually, but being able to have an automated way to validate that is quite interesting. As well as events attracting these as well. Is that something that anybody else has encountered as a problem or would be interested in seeing if it's a problem in their own systems? Raise of hands if it's interesting. You don't have to speak. It's okay. It's okay. Cool. Interesting. And we don't yet. No, no hands online. I think that's quite an interesting, interesting use case. And it sounds like something that could be, could be of use to, to, to the larger community in my mind at least. So looking forward to seeing where, where that goes. I asked you to prepare things. Vincent. Yeah. Yeah. So I sort of have questions. There may be comments and questions in two areas, both, you know, the world, the web, the web apps and the Android app. Yeah. Yeah. When it comes to the web app, I think even somebody mentioned the challenge of, you know, having to move from whatever they were using before to sort of follow the standards that are there. Yeah. And it's really quite painful. Yeah. And especially, for example, for us, we built an entire ecosystem around, you know, Angular applications. Yeah. Transforming that into, into react, for example, has been really painful. Yeah. Yeah. So one approach that we took, we sort of thought that maybe, you know, Frameworks change here and there. So we sort of decided to kind of come up with a more, more of a native way of handling things such that if anybody is using any other framework, they can tap into that structure, let's say, without having to worry about, okay, this is react. This is anger and things like that. So we've sort of started creating like a JavaScript vanilla kind of thing, which you can put anywhere in Angular or React. That in itself has been painful regardless. Although we are trying to move in that direction so that, you know, Anybody in the community wants to sort of use whatever tools they want to use. It's easier to tap into that. And my question. Now there in comes the question. Right now we are looking into, you know, Porting the visualizations, you know, in the dashboard, the maps and all of that sort of create a vanilla type or vanilla type of framework. I would say, I wouldn't call it framework into that. We call it the two visualizer. I don't know if you have the same name. So they need to visualize a sort of ports, all of those, you know, small features in your charts and all of that. Not if you have a script, let's say. So we're wondering if, for example, we could get, you know, reusable components from the, you know, dashboards and all of that so we can put them in there. And if anybody wants to use them in whatever, you know, Whatever they are building or whatever, they can easily take it from there and, you know, do anything fast from there. So that is one, two. And maybe you have noticed we, we sort of adopted Flutter as a mobile. Approaching to developing apps in Tanzania. And I was wondering whether you guys are sort of looking into, you know, diversifying into, you know, mobile platforms depending on use cases because in our, for example, there are use cases where you sort of have to create apps for both platforms and things like that. So, yeah. Yeah, that's a very, very good questions. I think to address the first one, which was around framework independent use of in particular visualizations or embed embedding visualizations in whatever website or framework. That is definitely something that we're thinking about in the plugin encapsulation, basically logic that we have. I think there is maybe some different nuances to, to your question as well, because there's one part is how do you actually build those visualizations themselves? So build the SVGs in the browser with the interaction and all of those types of things. And then how do you embed one of those visualizations? Maybe that's like you have already on the, on the dashboard embed one of those visualizations, whether it's a chart from the data visualizer app or a map for the Maps app or a custom visualization that someone else has developed. How do you embed that into some other, some other system? And the embedding part is something that we're thinking a lot about right now with the work towards building secure and sandboxed encapsulated plugins that can be embedded in different systems. So what that sort of means is right now we have kind of a hodgepodge of ways that the plugins are embedded into the dashboard. And most of them are just pulling in additional JavaScript and rendering it into the React application that is the, the dashboard rather than doing that, we're moving to a model where we encapsulate that in a way that tries to sandbox it and allows it to have to do whatever it wants inside of that sandbox. So that could be Angular, it could be React, it could be whatever. There's no requirement across the border that they use the same framework. And that also gives us a really interesting advantage when it comes to app specific permissions, which is something that is on the roadmap that we'd like to introduce where when you install an application, ideally you should be able to grant that application specific permissions and not other permissions. So if you install a rich text editor plugin for your third, you want to be able to tell DHS to not to let that rich text editor delete metadata, for example. And that's something that will significantly I think improve the trust that can be placed in third party applications. And part of that also comes with the advantage of being able to encapsulate and then embed those visualizations in whatever other framework you might have. So React could be the framework on the outside, it could be Angular, it could be vanilla JavaScript, it could be Svelte, it could be whatever you want. I don't know if that answered your question specifically, but did that help? I'd very much like to look at the code. Yeah, of course. We won't pull it up here now, but another time. Yeah, sounds good. Yeah, and that's a work in progress. So that's not something that is in the application platform or the pooling that we do today. And then the second question was around multi-platform applications and specifically the use of Flutter. The approach that we've taken to that is basically to support PWA applications in our web framework. So being able to basically PWA for those of you who aren't familiar is Progressive Web App. It's basically a web app in your browser, but then you can install it as a kind of lightweight app on your mobile application. It can have offline support. It can be installed also on the desktop browser and things like that. There are some usability trade-offs in using that versus using something that's native or something like Flutter. But that gives us the ability basically to turn any web application into a cross-platform application. In terms of mobile apps and the Android SDK specifically, that is Android specific. I think there is, in the Android team, I wish someone from the Android team was here today to answer that question more in depth, maybe Marta or Jose. But the decision to go with Android was to give the best possible experience to the most number of users. So that's where the choice of the Android platform was made. And I think there is interest in expanding that to multiple platforms and reusing code across that. But right now it's Android specific. Okay. Thank you for the question. And we can talk about code later. Anyone else have a comment on things that they're building on top of DHS to? It doesn't have to be technical again. Remember, it could be use case focused. Something that they're building on here or something that they see on here that they didn't, maybe they didn't put in themselves that strikes them as interesting. Feel free to raise your hand and contribute to that discussion going once, going twice. All right, I'm going to pick one. And then we'll move on to the next fun activity that we planned. So new data entry app and facility attributes app. Can I ask someone to fess up and say that they entered that? Who was that? Yeah. Are you willing to talk about it? Okay. You can say no. That's okay. But I'm curious. Let's get the mic somewhere. Okay. So we're going to start with this. I support the path for program. The data instance. The data, which is the DHI students. And we're starting to talk about a new data entry app. Because even though the HTML forms are late dynamic and we've really pushed boundaries around there. We do know and acknowledge that the data entry burden is very great. So we're going to start with a new data entry app. And then we're going to start with a custom app that may address some of those issues and kind of revamp it to. Maybe also be more manageable. Just because everything changes every year. So that, that is. In very early stages. And then we are talking about facility attributes because. Just because the instance is so large. And then we're going to start with a new data entry app. And then we're going to have facility attributes such as. Is this public, private. A combination university. What are the hours? You know, just things like that. Because. They're starting to be a. Desire for analyzing that type of data with the types of facilities where. That far supporting. And so we're thinking of. Building a. Attributes. That type of update. It'll be a big lift. Beginning, but we're also hoping that. You know, as. I know like an OU hierarchy will never be stable, but with the. Facility attributes app. We want to be able to have. A few people within each OU add those types of. Without. Having broader. Permissions to. Mess other things up potentially. some of the use cases we have and we're considering another one I added but I didn't see it up there is we actually did just put together a dashboard management app after several years the amount of dashboards just curated dashboards that PEPFAR puts out for the field has grown exponentially and it's actually can be really hard to navigate and find and so we're planning to submit it back to the DHIS2 app hub but it's a very small quick custom app that's just like a dashboard landing page that we can now force our users to and then they can use that to easily like filter like I want this time period these datasets and then go to the dashboards that have been created for them as opposed to trying to read through every single little dashboard that's in the drop down on the page so just a few of the things we're doing. Interesting yeah I'm gonna I'll comment quickly on the dashboard management app because I think that might be something that could be could be quite useful to a lot of different people but then yeah yeah and then maybe Hendrik I don't know if I'll put you on the spot to comment after that on the anything about the new data entry app or yeah yeah so first on the dashboard management app which you just mentioned I think that's something that it kind of ties in with the facility the facility I see some parallels the facility attributes app as well it's kind of the opposite direction right rather than delegating the creation of things down you're you're kind of centralizing it up to in in data at least to the creation of those dashboards and I think that's a pattern that is not not uncommon and could be quite useful to kind of guide people to guide the end users to find where the data that they want to actually see is and you can create these beautiful dashboards but if people don't know how to get there or they they can't find it because there are 100 or 500 or 200 that could be quite powerful the facility on the facility attributes app side and and everyone feel free to raise your hand if you want to jump in on any of this because I think it's quite interesting and particularly interesting on the use case side and on the facility attributes app have you have you used or played around with any of the new functionality with facility it's called facility profile kind of mfl functionality or the metadata this is 238 so it's very very recent but the metadata proposal feature it's api only right now but that might be a an api that could be useful for that application basically where a lower level user could have the option to to propose a change to a facility the opening hours for example and then that gets approved by someone who actually has the authority to make that change in the maintenance app otherwise there might be some changes that we need to think about in terms of the authority that are granted to different users they might have authority to change the profile for a specific facility only for example is that something you've you've thought about or seen seen some parallels there I was in a session that was discussed and I made notes about it you're still going through all of our QA for Q.3 so it's in process and I haven't started building this yet either and I think our plan is to explore that with Q.3 yeah yeah cool I'm just going to comment on that do you want to use this or the or the mic up there I don't know if I can dig my mouth that cool thing should be on I think so this is a under digraph digraph the team lead for the platform team so with regards to the data and we have a team and I have been working on all the personal forms this is actually one of the things we started doing in a fundamentally different way with the plugin system so yeah I think it would be great maybe after this we could do something maybe discuss the requirement because I think it might be beneficial if we find a way to yeah address your requirements if possible in the core application and perhaps yeah have a collaboration on it and see if we can instead of having two data and we actually have one that addresses both yeah yeah cool yeah that that brings us to just a more general point where again let's talk because we're we're working on things at the global team core team level but also everybody else is working on things and if we don't talk we're going to be reinventing the wheel and so without any of the technical tools without any of the financial kind of overlap of things let's stop reinventing the wheel and let's let's talk about how we can how we can solve these problems together and not yeah not reinvent that wheel so we're just having Scott welcome we're just having a discussion about different things around extending DHS too I haven't gotten into the the technical presentation at all and we have oh we've been here for what about an hour almost no okay I'm going to turn it over to Scott in a minute to talk about sustainability financial sustainability and some of that but first I wanted to quickly show the the last few slides of the the plenary session that we had the other day Tuesday to talk about what we're looking at doing at the core team level to support extensibility and there's again kind of on the technical side but tie in with a lot of the and yeah supporting a lot of those innovations and making it easier and cheaper to build and maintain and then share and use those applications and so to get into some some specifics I mentioned public portals the other day gotta just see a show of hands who here has thought about or used public portals to give the public access to dhs2 data data that's collected in dhs2 yeah six or seven people okay um so that's a use case that comes up quite frequently it was especially popular during COVID to give basically the public real-time access to case numbers in public portals but there are a lot of technical challenges around how do you actually do that in a performant way how do you do that in a way that you don't need to build up your own visualizations maybe you want to embed the visualizations that dhs2 provides out of the box in this public portal maybe you want to dump that data somewhere else so there's a lot of questions about how that how that is done and there are other examples of this as well such as integration applications that we see over and over where as I mentioned data is downloaded from dhs2 into the browser and then pushed some external system or vice versa and thinking about creating documentation and kind of good practice guides for how to how we should do that as a community what the best way to build a public portal or build an integration with an external system is in the dhs2 space community engagement and support and developer advocacy is a continued area of investment for us and we have a developer advocate we also have the the core team is very focused on trying to engage with the community of developers that's several hundred people now on our developer Slack workspace for example and there's a lot of efforts going into building academies for fundamentals of building extensions and applications on dhs2 but also digging into the more advanced use cases and technical requirements for those developers in that community that's the advanced dhs2 extension development academies for example and then there's I think a burgeoning new area of collaboration with design labs the UIO design lab we've collaborated with for a long time but there's new ones such as the University of Dar Salaam and others who are really pushing the boundaries of what dhs2 can do and thinking about how to really be innovative and move things forward and I think there's a lot of room for collaboration between the core team those innovation centers and the global community as well so now a little bit more on the maybe more technical side we won't get into all of these details but your money of you are familiar with the app hub maybe you've found it useful to see what other people have built maybe downloaded an application maybe used it maybe you've built an application and uploaded it there there's a lot of things that it can do and that it enables but there's also a lot of room for improvement and what we can provide as that kind of infrastructure for sharing these extensions I mentioned earlier her application permissions so that's something that's kind of a core dhs2 feature but it's also something that would be beneficial on the app hub but more on the community side of the app hub is how do we increase the ability of people to get visibility into the the sustainability of these applications and how do we let the developers use the app hub as a tool to improve the sustainability of their applications to their extensions so I'll talk a bit more on the next slide about app feedback use of statistics and error reporting I think that's something that's very very interesting obviously there are considerations that need to be taken to make sure that that's opt-in from a user of an application for example so you don't want to automatically collect analytics or error reports but really streamlining the ability for somebody that's using an application to communicate with the developer of that application or that extension and particularly when there's technical errors or feedback from the users of that application to be able to feed that back to the developer similarly support for other types of extensions components than just application web applications so android apps being able to view different android apps that have been developed to deploy those to a dhs2 instance through the app hub to support more strict versioning of those applications those android applications through basically a in dhs2 distribution mechanism metadata packages being something that we have kind of there are files that you can download and install now but that could be something that could be significantly streamlined and improved through something like the app hub or metadata hub to be able to say I want to download this package these are the configuration options that I need to set to actually configure that package for installation into my system I then want to know which version I already have installed what customizations I've made so that when I upgrade that to a later version of that package of hiv surveillance or or covid surveillance or covid vaccination I can reapply those customizations and there's some other additional things here beta deployment of applications is something that we're looking at particularly for core applications to be able to get pre releases out into the wild and get feedback earlier in the process by allowing people to install beta versions of those applications and then test them and give feedback even if they already have a production version that they have installed and they want to keep most of their users using that production version they can test it with certain subgroups of users that is an incomplete slide apparently so this is improvements to the app based extensions that we have today and I think that events should actually be under larger architectural changes I'm not sure why that got up there we talked about plugin extension points here I guess yeah I'll talk about the events in a minute talk about plugin extension points and kind of encapsulation of plugins but there's also a need for additional places where you can put those plugins so right now you can put plugins on the dashboard and that's basically it but there are a lot of cases where you might want to just add a little something to the capture application or to the data entry application to be able to customize that functionality without forking the whole entire app or creating your own app for that for that use case so a good example of that is in the capture application we have what's called and this is the the new tracker functionality within the capture application we have what's called a tracked entity dashboard which is giving you an overview of a particular patient or tracked entity and then you can drill down into the the different programs that they're enrolled in or the different events that they that have taken place but on that on that dashboard you might be able to see for example you might want to see the height over time of a child program for example so you might want to see all of the checkups the the height of that child on a graph and that could be something that could be built as a standalone extension or standalone plugin and plugged into the capture application so that it doesn't need to be something that's available out of the box if you have a something else you want to to graph over time for specific people that are enrolled in specific programs or you have specific data that you're collecting you can build an extension that is just that simple small little piece can then put those together to create the tracked entity dashboard that actually suits your needs and there are other places where you might want to have customizations in data entry for capture or for aggregate data as well yeah the tracks entity the tracked entity dashboard is introduced in basically 238 with the capture application it's an opt-in functionality so that's Marcus mentioned that in the what's new presentation on Monday the extension ability of that is coming soon that's not quite there yet so basically being able to create a plug-in and put that on to that dashboard but that's coming soon um the question was whether that's there yet for those who couldn't hear um lots of other things here but one of the one of the most interesting I think um is integrated reverse proxy so this is something where when you're building an application a lot of times as I mentioned on Tuesday there's a something on the server or some external system that you need to interact with and so right now the the the most straightforward way to do that is just to have your your application running in the browser talking to that external thing but that has some challenges because you need to share credentials to be able to access that external service you're going over the public internet which maybe isn't the best idea um and it's it's difficult to kind of restrict what different dhs2 users can do in your application to talk to that external system maybe they each need to have their own credential with that external system or you need to store it somewhere which is problematic in its own right so this would allow basically it's a lightweight way to um allow applications to work in uh with server side things uh so basically the the app would continue to be able to talk just to dhs2 but certain requests would be able to be routed to some external service and that dhs2 would then be able to apply authentication and and authorization rules to that those requests to say only users with this specific authority authority can talk to the go data system that's that it's talking to behind the scenes or whatever that that external system is a custom custom backend service so this is something that's fairly lightweight fairly easy to implement but it a lot it opens up a lot of additional functionality there um and then this is supposed to be events and scheduled uh basically scheduled web hooks sort of so this is allowing when something happens in dhs2 allowing an application that's running on the server side to be able to tap into that and say whenever right now we have program notifications that can send an sms or an email when a patient moves to a certain stage in a program but you might instead of sending an sms or an email you want want to trigger some workflow in some external system and so being able to do that when when something happens in dhs2 or on a schedule to be able to say i want to run my uh interoperability job once a day at 3am or something like that um would be again kind of lightweight way to be able to unlock a lot of additional functionality on that server side um yeah granular permissions i talked about uh standard app configuration and settings management when you create a new extension or application oftentimes if it's generic it needs to be configured before it's usable and so thinking about ways that we can standardize how those applications and extensions are configured provide the tooling so that somebody that's installing an application always gets the same interface for how they configure it um how they the different things they set where that's stored how they uh the application is enabled or disabled based on what whether it's been configured yet um could also kind of streamline the um the workflow and prevent people from needing to reinvent the the wheel of of creating a configuration workflow and interface for every single application or extension that they build um bundled documentation and localization another thing that's very cool that also would allow uh potentially the separate the installation of a localization or translation of an application from the installation of the app itself so particularly for core applications if you we have full coverage for french and spanish but maybe our arabic coverage isn't as good as as as you would like or swahili or whatever whatever language you're uh you're needing and you don't want to wait for the next core release of that application you might be able to install basically just a language pack uh to translate that to another language and interestingly that also allows a particularly uh interesting type of um use case localization where you could actually say i'm going to use the capture application but i want to kind of rebrand it for uh education for example or for some other use case or some specific thing where you don't want it to be called attract entity you want it to be called student or something like that um and so you can actually change and you don't want to be to be called maybe enrollment you want to be to be called something else so you can actually change all of the text in the application without actually developing anything yourself or changing any of those applications so that could unlock a lot of uh sort of making apps able to be more generic and reused in different ways i'm not going to talk much about this last one but there's there's a few other things that we'd like to move into in the longer term to be able to unlock a lot of this functionality um through larger architectural changes in making dhs two more modular allowing it to be extended uh across both front end and back end and mobile applications and all of that full stack extensions and additionally some more control around how you can use the data store and that custom uh kind of database with schema enforcement and migrations between versions of extensions so that you don't have to do all of that again in the browser as it as it currently stands anyway so that that is a very quick oh i wanted to talk about this real quick um scott i'm sorry i'm taking up all your time uh the feedback usage statistics and error reporting i think is something that's particularly interesting um this allows the extension developers or the application developers to answer some questions that are currently very difficult to answer which is after i i release my application i put it on the app hub what happens like how do i know who's using it how do i know how they're using it how do i know if they're running into errors and breaking for everyone i i don't know today unless i have a very strong outreach to those users myself and so giving the ability to basically integrate some of that feedback and those um answering those questions through uh tools that the users of those applications are provided to give that feedback through the app hub and through the the dhs two platform uh would be helpful there and then it's also very beneficial for extension users because you can give you can understand if you if we're collecting this feedback from users of the application you can understand who's used this before maybe who how has it worked for other people in the past what is the sustainable plan for an application so that's passing in being able to kind of communicate in in in more ways with the developer of that application and who do i contact if i have a problem so right now there there might be an email address somewhere buried on the app hub but you it's it's not very clear how you engage with the developer of an application and particularly how you escalate problems that maybe your users your end users are seeing in that application and and escalate those to the developer of the application uh i think this is quite an interesting area of exploration as well with that i'll turn it over to anybody for questions i know that was a a huge uh that was supposed to be three minutes at the end of my last presentation so i i kind of would have rushed through it anyway but hopefully that was interesting if anybody has any questions or wants to say this is a terrible idea or a good idea or things that are particularly exciting raise your hand now and then i'll turn it over scott maybe to talk quickly at the end or maybe we can do questions later yeah sure yeah that sounds fine okay you want to talk yeah because we don't have much time we only have 10 minutes yeah oh shit yeah i'm just gonna start talking i don't have slides so that's good i do have slides but i'm not gonna put them up but um i want to that's a good slide just leave it that looks nice all right okay uh i'm gonna it's a hard pivot okay from that but it's all it's all relevant are related so um we've been we've been building out this app ecosystem a tons of apps tons of innovation you're gonna see some of that later really incredible apps solving really big problems generically they can be used in any country you know apps that are being made that are as good if not better than our core apps right um coming out of places like udsm university dar salon uh all the his networks uh pep far you know lots and lots and lots of innovation and so what so the next question is what happens to it right and we've been conducting interviews with essentially all those people for profits non-profits his groups ministries we conducted 15 interviews interviewed some of the folks in the room here and we were i was really praying that someone had some kind of secret about making these apps sustainable that someone had figured out some kind of model some kind of business model for lack of a better word there wasn't any literally none no one had a solution and so what do we i mean we've got all this stuff we can build apps but if none of them are sustainable we're basically just our own platform for pilotitis right this is i think this is kind of like a bit of a gut check moment where we've got to figure out how do you as an app developer manage you know some apps don't have to be sustained some apps are like one-off projects things and you just solve us you solve a problem you do it maybe a little bit more custom fine no no worries but the apps that need that the community can galvanize around how do we keep them alive how do we distribute the support to them how do we keep a revenue stream and when i say revenue stream i think we are somewhat being tied in by the concept of global digital public goods right extra good you know broad sweeping you know defining perspective but and the core will always be free and open source but i think we need to get a little bit more creative about how we are positioning our innovations on the peripheries so that they can be sustained i mentioned it in the last presentation that i did where we asked you know 15 different organizations how they want their apps to be sustained and all of them said that it has to come back to the core that's just not going to happen i mean some of them could potentially come back to the core maybe but that's not a realistic solution so we've got to come up with some more alternative and all that being said we don't have an answer for it right now right we are just starting to play with some ideas there were some ideas suggested um oh make it i have a statement man there were some ideas suggested so i mean things like austin pointed out being able to communicate a lot more on the app hub having collaborations between multiple parties everyone is constantly reinventing how to import data via excel into dhi's too it's like five apps a year for the app competition on how to import data via excel we have solutions what we need to like work together on it as opposed to working in isolation maybe we have one solution that everybody works on that would be like the dream of open source come to life right um uh that's just and then and then so communities of app developers shared problems shared solutions but then also people using those apps right so people who are all working towards or all using that import app or something for example and maybe they're able to share up the burden of maintaining that app right so we need to form collaborations communication and we think we need i think we need to get kind of a little bit more realistic about um revenue streams right so not all apps just have to be put out there and you know global good anybody can use it because clearly there's not really a sustainable model for that right um so let's think about like bundled services you know charge for support i know these are kind of taboo concepts but right now we need to we need to be uh we need to be creative we need to explore um so all that to be said if you have ideas please please tell us um so that we can kind of work through this together it's not going to be a top-down thing where University of Oslo kind of says this is a thing it's going to be you guys on the front lines who are actually making the app saying i want to keep this app alive what's and and trying to innovate and experiment not just you know in the app itself but in kind of how how to keep it going so if you have ideas if you have um and if there's any way that we can support those ideas please let us know the other point is if you're in this process and you're kind of early days we want to follow you from like a research perspective we want like a longitudinal case study from kind of concept for an app making an app into release of the app and trying to sustain the app over time because right now we're just getting snapshots of many different apps in different places and it's kind of we're kind of building this collage of an image but it's it'd be really nice to follow a life cycle a full life cycle now that's all i'm going to say so just more we should talk more as Austin said um now we are all going to not stop in here and we're all going to go straight over to because it starts at 12 so just go from here now can i can i make one one comment on the app oh yeah Austin make one comment yeah one comment on the on the on the app front is that it's also important to note that not not every single app needs to be shared and and global right so there there is a huge benefit also to using the the tools to make it easier for people to just customize their specific instance of dhs2 and their specific workflow even if no one else will ever use it or if they will never share with anyone else so i think there's uh that that is also an avenue uh is to make just use this infrastructure to make it easier to customize a single instance of dhs2 but we really get to the the network effect of this whole infrastructure for extensibility and dhs2 as a platform if people are sharing and are able to share and sustain the the the innovations that they're building and and and uh share those with other people and then that other country doesn't need to build the same app that somebody else built which happens today all the time so that's that's where we want to get to and we like to explore the sustainability options for that and last thing to say there are people who have deep pockets there's money in this community all right we just got to figure out how to get it from them to you through the apps i heard gavi is is just giving up yeah well gavi but even like private there's private sector folks in this community who actually have a lot of money and they don't know how to and they want to improve efficiencies and we just need to make sure that what your solutions are on their radar and that they ended it's you know everybody's kind of uh working together anyways okay so please don't stop here just go go straight across just right across because we're starting from thanks thank you all sorry i didn't leave you much time