 the roadmap and prioritization process. So the idea here is to give you an idea of how the D-Tries2 Roadmap, so the software development roadmap, is developed and prioritized. And to talk a bit about how you can request feedback and provide input on the roadmap. So a bit about how we're thinking from the University of Oslo side about the software development. So of course D-Tries2, now used by a lot of countries. We're getting a lot of requests in my country. We're working on this project. We need this feature. We need to have the user interface slightly different. We need to be able to import data in a certain way, etc. So there is a lot of requests for features, functionality coming in. So managing this and coming up with the roadmap is of course a complicated total task. And the main thing there is that we're trying to look at sort of the specific requests, feature requirements coming in and trying to see if we can find generic ways of solving them, so that those solutions can be used other places. So generic care is referring to making something that is adaptable, flexible to be used for different purposes. So sort of from the beginning of D-Tries2 development, sort of the slogan of the development team has been generic solutions to local requirements. We're also, D-Tries2 is recognized as what we call the digital public good. This is a sort of global initiative to identify software solutions that meet certain standards. For example, that they're relevant for the SDGs, Sustainable Development Goals, that they're open source, that there is a clear ownership, platform independence, that it is documented. It has mechanisms to extract the data being managed, that it adheres to privacy laws and standards, follows best practices and do no harm by design. So some of these principles for those of you who are into open source software, it has a similar list of criteria specifically for open source, we do no harm, don't discriminate for different uses, etc. But this is, there is now a digital public goods alliance that is working to identify software solutions that meet this criteria. And D-Tries2 was one of the first ones to be identified there. So a bit more specifically on how the roadmap process works. So the typical start is around September of each year. We have this process where we invite some key stakeholders to present their main priorities for the coming releases. So this includes ministries of health. It means the HIST groups, which typically are the ones representing the Ministry of Health requirements in these meetings. It's the team at the university who manage different D-Tries2 projects and the HIST-BIO management who are sort of setting the more strategic direction of where we want to take D-Tries2. So based on this, we have a team of product managers who are responsible for different parts of D-Tries2. So we have a product manager for mobile, for analytics, for the sort of overall platform and for trackers specifically. So this team sits down, looks at all the requirements coming in from the different stakeholders, and they try to sort of combine what requests are actually more or less the same. What can we combine into the same specification and come up with one list of all the requirements coming in from different places. Based on this, they produce a list, which is looking at how many people actually requested this, what is the level of effort to implement this by the development team. And then we have a meeting again where the stakeholders can provide input again on this consolidated list of requirements. And of course, as you start the development team starts working on features, they might realize that this will take longer time than they plan. So they have to change things, maybe there are some urgent things that pop up that needs to be added to the roadmap later. So there is often some adjustments to the prioritization on the way. And in terms of how we tried to prioritize requests coming in, the first priority is the country implementations, ministries of health. And that's sort of our top goal. And then from the University of Oslo side, we also sometimes have deliverables with global partners to develop certain things. So those need to be high in the high in our prioritization, because that's how we fund the whole development of DHS too. So it could be for example that we have a deliverable to make a toolkit that requires a certain software feature. Then we need to put that in the roadmap so that we can meet that deliverable. Third on the list is more sort of the technical maintenance. Sometimes we need to introduce new frameworks because old ones are no longer supported. We need to make sure the basically maintenance of the source code of DHS too. And then on the fourth on the prioritization is sort of other requests coming in from people organizations using DHS for other in other contexts, people just posting on the community of practice, for example. We also look at those and try to pick up feature requests that might make sense. But they're of course prioritized lower than what we're getting directly from ministries and that we have deliverables on. So this has been for the last few years through the process. Like I said, we have this annual prioritization once a year. It's been in September for the last few years, where we're then planning for the next two releases typically. And then the more detailed planning for the second release of the year is happening in March. And the actual releases are in April and October. September meeting is open for the September meeting. So I don't remember exactly how what sort of the process was there, but I think a lot of it is through the HISPs groups. So we asked the HISPs to talk to the ministries that they support to sort of what are the what are your priorities and they try to compile that for the ministries that they work with. So it's coming through the HISPs. But then of course, from the University of Oslo side, we also work directly with some countries. So we have an idea of what the priorities are also from the projects we are engaging in. But I think so for this region is of course something that we need to figure out how we do this. Just I'm thinking loud that if something for that countries or the country context has, for example, like Palestine largest scale implementation and they are in opposition that there is many features, urgent feature, like for example, decision support system, multiple advance feature in the tracker. So just I'm thinking about, shall we put it on the community of practice in first, then go to the JIRA for make it more visible for the developer or channel through the HISP or UIO. So we have just in my mind, I have several ways and channels to communicate. So what is the best way to do that? I have connection, for example, in Palestine, I have connection with ODE. But maybe for me, it could be community of practice, then HISP, then waiting or what kind of process. It's always good to make JIRA issues. I'll come back to JIRA. This is the system we use for actually collecting all the feature requests and defining the software features that are being developed. But I would say in general, it's important to not just make it as a JIRA. If it's something that's really important for your implementation, you need to try to explain it to someone sort of more directly as well. Because there are just so many things coming into JIRA that it's difficult for the product team, the product managers to actually understand how important something is for an implementation. Of course, if it's a feature that is very important for a national implementation, we need to understand it so that it can be prioritized. But if it's just coming into JIRA, it's not necessarily something that is picked up. But I think going forward, I think one way is through then the HISP so that when we have the next prioritization process, this region will be represented there, which it hasn't happened before. And then of course, if it's something urgent, so on the global team, we are also inputting into this process, like myself and my colleagues. So you can also always approach us and say, this is really important for us. People are not picking it up on JIRA. So can you help us sort of promote this and then explain, we can try to explain why this is important. And of course, there are often things that we sort of personally, I think this should be higher on the roadmap. But I'm not always able to convince the people managing the software that this feature is important. We will specify our list, the wish list and the urgent list. And we'll share it to Abdelrahman and Hanid. Yeah. I think it's something, of course, there are, like I said, so many requests coming in. So including us in the, in Oslo, we're not always able to push for what we think is the most important. So it can be a frustrating process, of course. What is new this year is that we're not doing two releases. So this year, there will be a new release I think next week to 0.40. And then there won't be any new versions until probably April next year. The reason for this is that the development team feel they have quite a big backlog of things they would like to sort out, including upgrading all the applications to new frameworks, etc. So a lot of sort of maintenance tasks and some bugs, etc. They want to prioritize rather than having a new release with new features this fall. So this year there will only be one release. I think next year they're still not 100% sure whether they will continue with just one release or they will do two releases. I think most likely it will from now on be just one release per year. Most likely, but not confirmed after next year. One reason that they can reduce the number of releases per year is that we're moving towards what we call continuous release of the applications. So D-Tries 2, it has the first it's installed on the server, the main application, and sort of the core functionality. But then as you saw this week, we've showed a couple of examples of installing new apps from this app hub. So what we're moving towards is that the sort of server back-end side of the D-Tries 2 is getting less frequent releases, but that the apps can be updated more frequently than D-Tries 2 itself. So it's a bit similar to what you have on Android or iPhone, big updates maybe once a year, but your applications Facebook and Google Calendar and all those things they can be updated with new functionality more frequently. So it's the same thing we're moving towards with D-Tries 2. Fewer releases of the or D-Tries 2, more frequent releases of the individual applications. So just a couple of quick things at the end. We have this web page D-Tries 2.org slash roadmap which gives you an overview of what is currently being planned for the coming releases. So you can go there and then you can look at what is being planned and you have these different filters here. So you can look at specifically for analytics, what are the new features for Tracker, for the Android application, etc. So that's where you can look at what is being planned. For those who are following specific sort of functionality that has been reported and you want to track our people, have people started working on it, maybe you want to ask someone what is happening. We have this Gira platform that we use for specifying software requests, the new functionality, etc. and assigning it to developers. You can communicate, sort of specify the details of features if the developers are asking, etc. And this is also where you report any bugs that you might find. Bugs, features, everything should be recorded here. And then in addition you might have to follow up with someone to make sure they understand how important it is. So I really encourage you to have a look both at this roadmap page, just to have an idea of what is being developed as well as making an account here and you can report things and keep track of what is being done. Yeah, like I said, this is also where you can, if you report a feature, a developer has a question about this, the communication will happen here through Gira. Okay, so to summarize, DJI's to itself is being developed based on this roadmap process I've described, public roadmap process where we try to gather in all requests, consolidate them, prioritize with the ministry implementations being the top priority. Okay, you can follow the roadmap and what has been sort of picked up for the roadmap on this web page, djs2.org slash roadmap. And if you have feature requests or want to report a bug, you do this through Gira. Any questions before I give the word to Anna? Just maybe a question about the management part or decision support system. So do you have anything, do you have any thought about that for the future to be part of the core djs2? Because functionality for as a decision support system part of the functionality, not only the, you know, the program rule, you can make a right widget about the feedback, but we need the care provider to have a section for management to improve the quality of care. So maybe I understand previously that it will be part of the coming release, but I don't know if you have an idea about the, if it's this year, next year. No, not really. How we can make it a priority on the agenda? I think you need to then compete with all the other things people want for the What if we put a Gira on the do voting on that and make it I think it's good to have that kind of, that you really make sure that Mike has a tracker product manager understands that it's the top priority for you and he's supporting that totally. But I think like the, like I said, there are so many sort of backlog of things we would like to do before we start working on new things, sort of improving performance on some of the program indicators, for example. So I think that's one reason for slowing down with just one release is to do the maintenance, do the performance improvements, etc. before working on the new. So we will have a bilateral meeting with Mike, maybe we can activate this issue more. Yep, thank you. Any other questions or comments? Since it's an open source, I'm asking, is there any different branches from the HS2 or it's all being done by Oslo University? For example, if I need to do a country specific thing, not available in the HS2, but using the HS2, can I hire a company, use the code, do our own development without referring to Oslo? Yeah, thank you. You can and people have done it and it's usually not gone well because you end up with your own branch and then after two years, you realize it's very expensive to merge all the new things being developed in the main branch into your branch. So I think many countries have done it and all of them have stopped because it's just not sustainable in the long run. But technically it's possible. The source code is there and you can take it and do it. But that's also the reason we have the app hub because the idea now is that to avoid having to make a fork of the HS2 itself, you can get the company to make an app that runs on the HS2 with the functionality you need. And then you just need to maintain that app and use the main core HS2. So that's what we encourage rather than making a copy of the HS2 itself. You make an app that runs within the HS2 and then what you need to do is just to make sure that just that app is maintained over time. So that was actually the main reason for making support for apps was to avoid having these forks because they're very hard to maintain in the long run. Other questions, comments? Maybe just a comment on this because this is an important point. So to work on the source code directly, like a fork product, this is not recommended at all, just you will lose the support from your IO and the regular release unless you do an app like he mentioned. The application is compatible if you do it in a way that compatible the HS2. But if you have like a fork product, if you play with or work with the source code, it's going to be painful for you in the future. So it's good to have like the standard HS2 rather than work on the source code unless you have a capacity and resources to do application inside the details too. Thank you. Okay, then I give the floor to Anna.