 Good morning, good afternoon, and thanks everyone for making time to be part of this session. Patrick O'Meel is my name. I work with the Health Information Systems Program, Uganda, as a DHIS2 implementer, and specifically I support development of packages, and so for this, I'm here to share with you the processes, the experience that we go through as a developed package, and this should be really in consideration of our plan to support development of community health and health information DHIS2 based on the global standards. So as a bit of background, this initiative of developing packages started way back in 2017, of course, with support of partners, and in the beginning, we're really looking at TB, HIV, malaria immunization, and then of course, RIM, NCH, and of course, the cause of death, and over time we've seen over 30 countries having these packages that we have developed installed in their country systems, and increasingly we are seeing demands for these packages, and so we're really working towards making sure we're able to expand this work. So just trying to help you understand where the community health data fits in, as you can see highlighted, it fits really where we have integrated health services analysis because as you know, community health data is close cutting, of course, programs, and so that's where we think it's going to be to really fit, and as you can see, this is so far what we have developed, we've so far developed immunization, HIV, TB, malaria, COVID, and then of course, the RIM, NCH, and again for this package for community health data, we will be starting with the first program, and that is the RIM, NCH. So then also, whatever is in progress right now with this development, a package development, as you can see for aggregate, we have the community health information system that's part of it, but there are these others, IDSR, rehab, NTD, and MCDs, these are all in progress, but of course on the right side, you can see the case based on what we call in video level development based on tracker, and here we have got malaria, TB, surveillance, HIV, and then of course, the VPD, surveillance ongoing. So again, I already mentioned this that we have over 30 countries that have adopted, and here to be more exact, we have 39 countries that have adopted this package, and here we're looking at really one or more countries having this package installed in their national HMIS. So also, we think that congregating community health information data in the package really help to provide standards for community health data and also help to integrate community health data into the routine health management information systems. So the way we've been doing this together is that of course, we have got the technical partners, that's WH or UNICEF and CDC, who have really been working on developing the technical content, but also working on the standards, and the guidance that we use really as a preliminary requirements to develop this package. And of course, based on those standards, we generate requirements that we use to configure this package, and then we go of course ahead, and once we build this package, we also do all the necessary technical guidance that will help implementation. And then we also work with the HIS groups to make sure that this package can be installed in country. Of course, MOH is the core user of whatever we're doing, although this is open for other people to use, but MOH is a core user of this. And so we, we, we, we, is a core user of this package. And so we definitely have to work with them to make sure that they're able to get this running in their system, but also that we're able to get lessons learned so that we can improve on our requirements. The HIS regional offices and nodes are also very key because they are closer to the users, the ministries of health. So the other ones work with the ministries of health to make sure that this is installed. And then of course, the implementing partners work closer to the ministry, and then the developing, I mean the funding partners help us to make sure we're able to actually go down and implement this. So in terms of the development life cycle, again, this life cycle is modular and it's iterative, so, but it all starts with the, the launching of the package. And so once it's agreed that we need this package, need the rises that need this package, it's agreed. And we say, let's get started to come up with a plan on how this should be done. And then we'll go ahead, dive in and start with the requirement gathering. And once we have gathered requirements, we then go ahead and use those requirements to start with the configuration. And again, we just wanted to highlight here that for community health information systems, we have started the process of configuration at a stage of configuring, of doing the configuration based on requirements that we have so far brought. And once we are able to do the configuration, of course, we do testing and feedback. And this can be internally, we get immediate feedback internally. And then once we are good with what we have in terms of the testing and the feedback, we then go ahead and we do the release. For us to be able to release, of course, we have to make sure we have all the necessary documentation. And then once we release and publish, and then the users can go ahead and do the implementation. And again, here we can support that process of implementation where we can work with countries and end users to make sure they're able to install this package. And then once you have implemented, of course, you need to have some levels of maintenance and updates to make sure that you are up to date with the course of 12 DHS too, but also if we have any new changes coming within the package. But again, on the left side, like you can see, we have got lessons that we've learned. And these lessons we can only get in the process of implementing. And that can actually later feed into the requirements. But also in the process of developing, doing the configurations, you get a lot of inputs on the field. And that's very important at that stage, because then we are able to have a product that can be owned, but also a product that has some requirements from the field. So how will we learn from the field implementation? And this is very, very important, especially for the community information system that is very diverse. It has different workflows. So, and again, it's important to appreciate the services that are delivered in communities that are also quite diverse. Health workers, the kind of report that they submit and the tools they use to collect data is also quite diverse. So these are all things that we will have to learn from. But so far, UNICEF has conducted consultations within few countries in developing the guideline. And we think that's very important that right from the guidelines, we're able to have countries consulted. And then we will, from the University of Oslo side, there has been intense extensive learning from health information systems. But again, even with this knowledge and consultation, we will go ahead and test this package and then do piloting. And that's in 2021. And there we'll have proper user acceptance testing with the community health workers. We will engage at the community, I mean, at the strict level in workshops and then, of course, piloting also video level data to aggregate. So this is really how we try and make sure that we're able to properly implement this. But most importantly, that we learn along the way, appreciating the challenges of the diversity of community health information system. So, so how do we develop this package? I've kind of touched a little in the process of, I mean, in the development life cycle. But when it comes to the actual development, of course, that there are specifics, and that's what I would want to highlight here that we start with focusing on the inputs, data capture of the inputs. So once we have those guidelines, the requirements are very clear, we're able to start focusing how do we use this? I mean, how do we develop the parts for data inputs? And that one, we're able to then, based on the requirements, we're able to go ahead and customize the part that focuses on data inputs. Again, typical for DHIS is focusing on what kind of data elements you have here. How is it disaggregated, what kind of options and all that metadata that's relevant for inputs. And once we have that, we're able to review, test and be sure that it's about to capture the data that we need. And then we then go ahead and also look at specific requirements for analysis. And here we able to base on and generate some more caps, visuals that other analytical outputs that is kind of expected out of the system. So we use that to develop the analytic items and then create dashboards. And then also generate some dummy data that helps us to further configure this and test to make sure that's all working well. And after that, of course, we do documentation to work on his package. And this documentation usually includes the installation guide, the design documents, and of course, the training templates or materials. And then we also go ahead to do the metadata translation using Transfix. And then, of course, once everything's done, we can export this into a format that can be installed and the format that we're using is really just a format. And then go ahead, publish and release the package for implementers and users to take on from there. So once that is again, once we're done with the development and we have released, of course, implementation comes in. And this is just a quick sort of process that we go through, or what core users will go through if they wanted to adapt this package with support from a University of Oslo or through his notes. And so the process together, technical assistance, of course, requires that a request be made through University of Oslo. And then if they have support for this, they're able to make up a team to go and support and offer these technical assistance to the user or the country. And then, of course, they have to go up in terms of reference prior to a visit. And then they go ahead and do the visitor. The visit usually lasts about two weeks. But this can be extended if there's need for more support. And then when they go in the country, of course, they have to have entry meetings with the stakeholders. They have to then quickly do rapid assessment of GHIS-2 implementation to be sure that what the way it's developed, the way it's implemented, can support these packages that we are bringing on. And then we do indicator mapping specifically when you're dealing with the dashboard package. And then we also go ahead and do the installation of this package and any other custom applications that come with these packages. And then we do training of trainers because you're not able to train everyone, pick a few people who train as trainers, and then we then debrief the stakeholders, and then we exit the country. So for development, so lessons that we've learned in development. And on the left side, of course, really we want to start by what has worked well for us. Over time, we have really developed a process that we think we can reuse and the resources that we think we can reuse in the process of developing this package. So a lot has been learned in that and a lot has really worked well for us in that area. But also the collaborative development with the field implementers. I happen to be one of the field implementers who is now actively supporting the development of this package. So that's really also very, very important that capacity can be built to actually support the development of the package and starting the implementers. Documentation has also greatly improved and it's been standardized. We've also seen that we can rapidly develop packages with the shorter cycles and a good example really with the COVID. We are going to quickly and rapidly develop a package that was used, I mean, that was released and it's now being used for the response. Of course, on the left side, the really areas that we think we can improve, of course, is with the requirement, gathering most times, not most times at some of sometimes we find challenges with the requirement, gathering process, information can be a bit of scanty and this can actually lay the whole development process. We also want to improve our release cycles so that it's aligned with the CoDHIs too. As we get new releases of CoDHIs too, we also want to make sure that the packages are released that are compatible to these new versions. The last one, which is really, I think, more important is really to strengthen, we need to strengthen the feedback loops from the field. Implementation really focus on feasibility, acceptability of this package and then that we think can feed into our development process. For implementation, and again, this I speak with a bit of authority which goes on as an implementer, really a lot has worked well for us because we've seen great improvement in data access and used by programs, really programs that install this package, really you feel that they are now able to actually easily access the data and use their data. We've also seen in the process of implementation that we've sort of extended support for CoDHIs too because beyond the package and again, this experience really coming from the field because sometimes you go to install the package and you find the need is beyond the package. So you have to do a little more to just help them maybe look into their server configurations, maybe look into their general customization of the tools that they use to collect data. This has also sort of influenced and influenced the process of review of the tools to try and align to standards and a good example of those we see was Uganda where there was HMI review and so with the package coming in, that sort of influenced the changes that were made in that section, especially for the ETI program. And we also saw a good example of the Madagascar where once we shared this package with them, they realized that there was a lot that was lacking and they went ahead also to make some reviews of their HMI. So we see this is already influencing changes on the HMIS and trying to make sure it's aligned to the standards. Of course, we see a lot of emerging needs which we think is really on a positive side to integrate data and to improve analysis and use. Yeah, so once we put this package and we do mapping of indicators and they see the gaps within their system, then you see the need to integrate data because sometimes you find data is in other systems. So and this is really good because to improve that analysis and use. We've also and this is just to note that we will be so fairly adequate infrastructure and HR at national and subnational level where that is entered and reported and that's also a good one. Yeah, so on the of course, on the other side, on the next side, the things that we think we need to continue improving of course is country coordination and leadership. It's very, very important that as we go take this package down that country, the country's well coordinated and we have strong leadership to make this work. We also note the need for clear plans and budgets to support rollout and subnational level. Once we install this package at national level, that's where we end, but it would be nice for countries to have these plans to take this package at subnational level. Again, along the implementation we noted of course the limitation of HMIS, which I already hinted on. And so we are not able to fully configure the packages and then the apps and again, this why we looked at it in a positive sense that it was able to actually influence the HMIS review and which is good because then people are trying to then align. Partner driven dashboard, we note quite a number in the field and this sometimes creates a feeling that we are bringing more of this dashboard. Even when we know that we are trying to just enhance our DHIS to have more features for analytics, sometimes it feels like introducing a new dashboard. And that has been a bit of a problem. We also note that the capacity enhancement is still needed in the country for DHIS too, so that they can support the core DHIS but also support these packages. And of course limited resources support translation of the kids to other languages. Much of this is in English and a bit in French. But yeah, it would be nice to have other languages but also in for French to have most of the content translated. So looking ahead, we so we really want to really see support for adaptation of adoption of integrated harmonized HMIS to include community health data. We want to see improvement in the field to headquarter learning and incorporate country implementation experience. This is very, very important. We think this will actually also improve data flow between communities, health facilities up to higher levels of health systems. So and this is very, very important that we keep looking there to make sure it works. We also want to sort of have a little more focus on individual level data. As you as you know that with the individual level data, you're able to have more powers in terms of analysis. So and so we want to also introduce this and specifically for the community level, where we think the HIS tracker can actually help to collect data. And then also, of course, have this aggregated into the community indicators for HMIS. And then of course, we want to make sure we have alignment of donors, partners, the ministry towards adoption of this health standards and indicators to streamline reporting. So thank you. And over to you, Alice, and and to the audience for any question. Thank you very much. So hi. I'm Alfredo Mushanga from Mozambique. I'm the lead developer at Digital HIS Mozambique. And I also work with DeGestool implementation. I'm also DeGestool implementer. And during this presentation, I will be sharing our experience related with the work that we're doing. Based on the KUNIT health information systems. And here I will I will be sharing our experience based on the Africa Luzofan countries. And during this presentation, I will have four steps. The first one, I will be a brief introduction to the health information systems in the Africa Luzofan region. Next, after that, I will talk about the similar and different points between the KUNIT health information systems and the global health management information systems. And after that, I will talk about our experience and final about the lesson lines and other points that we got in the field. So DeGestool was adopted by the Ministry of Health of the five Luzofan countries. I'm talking about Guinea-Bissau. That was the first one adopting in 2011. Mozambique come next, Angola Cape Verde. And finally, we got Saint Thome and Prince joining the KUNIT on 2019. And Guinea-Bissau and Mozambique and Angola, they are already implementing KUNIT health data. Guinea-Bissau is using the aggregated approach data. And Mozambique and Angola, they focus on individual level data. And of course, because they started at different moments, they are currently at different implementations stage. And what we got, based on our field work, is that all the countries are implementing the information systems based on the community intervention. They have the several actors that are doing the community activities. I'm talking about the KUNIT health workers, the activists, the matrons, the traditional attendance. All of them are involved on this process of getting data and addressing service to the community. And all of them doing it based on a standard procedures. And these standard procedures are tolerated by different organizations or by different entities from country to country. For example, in Mozambique, we have the APS and the APS, the health, the CHW at Mozambique, but they are under the Ministry of Health. While in Angola, we have ADECOS, they are also the community health workers, but they are coordinated by the Ministry of State Administration. So as you can see here, we have the same activities being done by two different entities. So this behavior forced us to start the best approach to implement the home health information system, assuming that we're dealing with different kinds of organizations. And when we're talking about the electronic side of these systems, we found that there exist several softwares collecting and processing data. And in the main countries, like the major countries, we have more tools to do data collections, but we have few tools to do data analysis. For example, in Mozambique is using ODK and Comker and in Angola is being used, ODK and CoB outlets. And all these platforms are managed and maintained by implementing partners with a very little intervention of the Ministry of Health teams. Did they exist a lot of electronic tools, but they are only being used at the local sites. This information or the information collected at this level doesn't flow to the national level. So this is a very common point that we found here, where we have the Ministry of Health doing a duplicated work to collect the same information that the implementing partners are already implementing at the site. So basically in all this summer that I made here, we designed an implementation approach. And this is an integrated implementation approach. And we have here three main stages or three main domains. And where we have here at the left side, we have the current common tools that they're using at the conference right now. For example, we have ODK, we have COBO tools, and we have different systems. And here at the national level, we have the DSS2-Based Communities Health Information System. So it means that we develop a common health information system based on DSS2 using the DSS2 guidelines to develop the common health information systems. And what we did here is to look at all these systems that are collecting data at the local sites. And we selected the main indicators. So the MOH selected the main indicators and these indicators are selected to be part of this DSS2-Based Communities Health Information System. And finally, we have here the Erotin Health Information System that is normally being used and it's already part of this ecosystem. And we didn't touch with these to implement our solution. So basically, the implementing partners implement the system. They're not forced to use DSS2, of course, because they have different systems that are being used. They keep using the system. But we implemented a service, we implemented an interoperability service that collects data from these systems to the DSS2-Based Common Health Information System. And basically, here it's taken all essential info to this site. In Angola, for example, we are taking or we are planning to take individual data for COBO collects. And this data is going to be taken individual to the common health information systems. And then the main indicators, the main aggregated indicators are going to be curated and sent to the Erotin Health Information Systems. It means that here this site has will have more people accessing these systems. We are just going to have aggregated data. And this data is going to be accumulated or aggregated, based on health facilities or other aggregation materials that are defined by the means of health. So having the same data that started here at the local sites flowing until the Erotin Health Information Systems will have all conditions to do and integrated data analysis. And this is the situation. So implementing this approach, we have here some points that are guaranteed. Oh, we implemented an effort to guarantee the sustainability of the common health information system, because as I mentioned before, DSS2 is being used as the base for this system. And the MOH, they are already implementing DSS2. So they know properly how to create the tools, how to create the indicators, how to do the user management, and other DSS2 related activities. So it means that they already have people prepared to work with the common health information systems. Then we have the second point that is the governance. Because the system is going to be integrated, the MOH has the entity that have to manage or to regulate this process, have more space now to talk about policies, to talk about roles that have to be expected when the implementing partner, implementing tools at the community side. And finally, because of this interconnectivity with the Erotin Health Information System, here is open space to also have an interconnection with other systems as logistic systems and human resource systems. For example, in Mozambique, where is implemented and interoperability between the logistic system, and this data is already at the Erotin Health Information Systems. So with the common information data, with data coming for the common health information system, it's possible here to do a complex analysis using the same tool at the same time. And there's something that is very important, and the means of health are taking advantage of this implementation. So in terms of learning of lessons learned, the best thing that we learned is that with this approach, we change the way has the organizations are seeing or we're seeing the the common health information system, because before it was seeing has a standalone system that going to flow in a different way, or a different approach of the normal, I can say normal, I'm talking about the health management system, but is different of the HMS. So with that, we found out that with this integration is going to be applied the same approach to make the all health information systems strong, not only one side or another side. The second point is related with the way has the actors have benefit of the common health information systems. For example, the national and local supervisors, now they have possibility to have a streamlined data visualization, because they will have data rated at the same repository and then they can create combined indicators. They have focus at health facilities, because they before they were using the normal, I'm saying normal, when I say normal, I mean the current health management information system, but because they already use this system with this implementation, they are going to take advantage of the common health information data in order to make a better tracking of the of the group service. And with that, they have better ways to take decisions based on the information that that is connected. And the last point here is related with the data analysis at the bottom side. Something very important that is being applied is the data visualization from the common health workers. Tools are being implemented at the common site in order to have reports being produced and used at the common site. On this way, the common health worker will have or have a possibility to see not on the data that he collected, but he can also do some competitions with the data that is collected by by the other common health workers around the zone that he is or around the area that is located. So basically, this is the what I had to present. And thank you. Thank you, Alfredo, for for his very nice presentation. So for any questions, do not hesitate to go on the community of practice. I think we have time to reply to a few of them actually. So Patrick, I have a question for you. So we have one participant who is asking whether there are any connections between the Uganda DHIs to HISP and the One Health various initiatives. Yes, we, HISP Uganda, at some point, yes, HISP Uganda was has been supporting the development of DHIs to for zoonotic and specifically, it was really to in line with that agenda of One Health. So they had an implementation that they were that they made it through with support from CDC. So they've been supporting that. And I think that is still ongoing. Personally, I've not been working directly with that project, but I know that we've been supporting that. Thank you. I have another question actually for the still for you, Patrick. For the CHIS package, is there a sample for Uganda only for the moment? Because the content of the activity package is often different from one country to another? Did I get that clear? Because we are yet to get we are just in the process of development. If you saw my presentation, we've just started supporting. We had a process we've just put all the requirements we need with it with the guidance that we got. And now we had a process of developing this package. So so we do we've not yet made any releases of this community health information systems package. And as soon as that is out, we'll let you know. Thank you so much. And then we'll have one last question for Alfredo. Alfredo, who managed the A2D interoperability service? And what does it take to keep this service running? Thanks, Alice. Today, service is a service that he's supposed to be developed in order to to connect the A2D with different systems. So, so file is a service that is managed by by by his Mozambique, but it is an open source service. And it's and it's it's helped this process of getting data from the the different systems to the A2D and to have this service run. Basically, we focus we focus in the run source systems, because we have a decay, for example, we have one service getting data for decay. So we focus on decay. We do the configuration and the data is automatically taken from one side to to to to to to other. So basically, this is a service that is is available and different actors or different organizations can use the service to to to make this connection which engages to and other systems. Sorry, I was muted. Thank you so much. And I will actually have one last question since we have few minutes left. We have a participant who is asking that. So basically, you said that oversystem can be integrated directly into the HM HMIS system. Sorry. Is there any interoperability? Sorry, layer that helps to connect these oversystems to DHS to Yes, yes, yes. We do have a layer that basically in all these countries, we we we created an interoperability layer. And this layer is not only for for the current health information system, because we have different systems that want to send or send data for the the main HMIS. So what we did is to create a layer that is able to to receive this data. And what we did for for the HMIS system is a mapping where we map it based on the structure and we send data to the system. So we created a layer to do the to do this connection. Thank you so much, Alfredo. So we're going to end the session here. So thank you to all our participants. I see that we are 56 in total, which is great. Alfredo, Patrick, do not hesitate to go to the COP to reply to all the questions that we have there so that we keep the discussion continuing. And also this session has been recorded. So we will inform you all once the recording is available. So thank you so much to everyone and hope to see you soon in another session. Have a nice afternoon. Thank you. Bye bye.