 working on, thank you for the recording Alice, working on this LMIS approach for in DHS2. And again, welcome to everybody for participating. I'll quickly go through the agenda and the different points that we'll be discussing throughout this four week academy. Thank you for taking the time for taking part, but I'll go through each section and you'll know what it is we'll be presenting and what we'll be sharing at each point. And then I'll hand the word to some of my colleagues who would also introduce themselves and present some more content. So quickly here is the agenda. Just to confirm that you can all see my screen. Yes, we can. Thank you Alice. So for day one today, we'll start with again reviewing this agenda here now and going through some general housekeeping and how we'll be managing the academy throughout the week. We'll then hand over to Mike Frost, who will be giving opening remarks and I'll allow Mike to introduce himself at that time as well. And then followed by Kasim will introduce some community related content. And at the end of this session, we'll then have a group picture where we'll all turn our cameras and we'll take a picture to be posted and shared. Mike will be particularly talking about the approach that we've had with DHS2 LMIS and how we fit into the broader picture, the information management picture within a national system. Immediately after I'll go into the specific LMIS vision and methodology that we've developed and how that works, how it should be used and perhaps not be used, some of the guiding factors. After that we'll have a short break at 1130 to 1145 at which point we'll start a session on DHS2 and integration, a large part of what we'll be presenting and what we're showing here is related to integration, connecting last mile logistics to a central system. So our deputy tech lead, Austin McGee, will be presenting that. We'll then have another short break and then we'll have Pear Kronzle from the Medexas LMIS presenting both their software, their LMIS system and an integration use case with DHS2 in Mali. At the end of the day we can have a short Q&A and I remind everybody also to use the Slack channel and Alice will go through this to come with questions throughout the presentations. Day two we'll start with a recap of the points in day one through a Mentimeter so it will be everybody participating together in a Mentimeter survey to review the content. We'll then have George McGuire who works closely with me on LMIS. He's the LMIS technical advisor going through stock reporting and transaction based stock management using DHS2. This will be very much hands-on demo where he'll be demoing and showing the system live. There will be so much PowerPoint slides, actually very, very few and then after the break we'll go through a demo configuration while I'll actually go through and show how this can be done and how you can do this. We'll also have an open Q&A if you have any questions. At the end of that day we'll also have a presentation from Msupply who will be presenting their system and some of the integration cases we've had and then ending the day two with an expert lounge. So we'll have a full hour and perhaps even a bit more time where we can take your questions and answers. You can connect with each other and with us we can have breakout rooms and this is really just a prolonged session where we can discuss specific questions and use cases all right. So day two will be stock day. Any comment Alice or is that fine? No please go ahead fine yeah. Day three we'll do again start with a recap and then go into biomedical equipment life cycle management. Also cold chain equipment inventory management both demo and configuration and in the afternoon and then later having a temperature management using blue maestro temperature monitors and at the end of that day we'll have belida ELMIS and presenting their ELMIS system again followed by a Q&A to finish the day. Day four again starting with a recap and then going into GS1 data matrix and potential use cases George will then present an LMIS performance management frameworks or really connecting the data the analytics and this approach to then decision making how that can improve supply chain management and how decision making can be influenced and lastly we'll have then DHS2 and analytics and some of the different analytics features and capacity within the system and then we'll have again end of day Q&A we can maybe finish that and then have the break we don't need to have a break before a short Q&A and then lastly on day five we'll go through different considerations for an assessment for an implementation implementation planning and then we'll have specifically a session on Android so using the Android capture app and how that can be used to leverage some of these different features particularly targeting low resource sites at the end of the Friday we'll also have a longer meant to meter recap from the full week to ensure that everybody has gotten the different concepts that we've presented how you should or should not be using DHS2 to support your supply chain management and taking also any final questions or comments that you may have so that's the agenda for the for the five days I'll give the word now to Alice who will go over some practicalities over to you Alice thank you so much Bruno um could you stop sharing your great thank you so now I'm going to present Slack so basically this is the academy Slack workspace just a minute do you all see my screen we see it okay cool so normally as participants you all have been added to Slack if not I've just posted in the chat the link to join Slack so this is the dedicated Slack workspace for the academy and this is the main tool to communicate with the facilitators so if you open Slack you will see that you have three channels three different channels that will be mainly using if you cannot see the channels the only thing that you have to do is to go here to click on the plus browse channels and then you will have all the channels that are accessible so we are so the first channel is the announcement channel so basically we are mostly using it to provide some information like for instance I have posted the links to Zoom the agenda and I will be posting daily reminders here and also as Bruno has mentioned the academy is recorded and the recording will be available the same day so once the recording is available on the DHS to YouTube channel I will also inform you by writing a message in the announcement so this channel is mainly used by us facilitator to provide key information and then we have the second channel it's the introduce yourself channel I see had that actually many people many participants have already started using it to introduce themselves so if you have not please do not hesitate to write a short message your name surname organization you're working from and where you are based and then the final channel which is actually the super important is the questions ones so basically this one if you need any clarification any more information from from facilitators related to the sessions or or any supports do not hesitate to ask like to basically write your message on this channel so and we'll make sure that one of us actually reply to your question so it's very important to use this channel if when you want to when you need some support or you need some to ask any questions related to the academy whether it's before the session starts during the session starts during the session sorry or after the session we are always available so yeah don't hesitate to use it one quick note it would be great if you remind if you try not to send direct messages to the facilitators the reason for that is that when you are using the main channels you can be sure that one of us will see the message but for instance if you are sending a direct message either to me or to Breno or to George we basically it would it may be more difficult to get a quick answer so really really try not to send direct messages and use only the channel the question channel to to reach out to us and then the second yeah so I think this is it for Slack if you need any any more any more information related to Slack you can you can either send it well the best way is actually to use them the chat on zoom but normally as I said you are all part of the LMS Slack workspace so it should be okay but if not if you cannot join Slack you can you can let me know on the chat on zoom and I will make sure that you have access to the workspace and then the other thing you will see in the chat also that I posted a link to the academy folder google drive folder so basically this is the main folder we'll be using to add all the responses related to the to the academy for instance if you click on the link that I shared on in the chat on zoom I will also actually share it on on Slack when you click on the link you will be here like you will see basically a folder for every day so for instance let's take today's folder you have one folder with cold presentations and if you click here you will have access to the to today's presentation it's already available on the google drive so don't hesitate to click on the link that you will find on the in the chat so that you can already download the presentation of today right and then you have another document which is really important it's called important links so if you click on this document you will have two links the first link is the attendance form so what is the attendance form every day the facilitators will be sharing what we call the words of the day so basically it's a kind of nice way we have to make sure that participants attend every day sessions so on this on this document you click on the link here and you will have this form at some point during the session the facilitator will tell you now the word of the day is and then the only thing that you will have to do once you have the information about what is the word of the day is to click on the link on the attendance form write your name your email and then the word of the day which has been communicated by the facilitator so this will enable us to see basically to make sure that participants are attending every day session and then at the end of the of the academy it will be part of the certification process because you will have all the participants who are able to to give us at least four words of the day out of five will get a certificate of participation so it's really really important when you you attend the session that you fill in the attendance form with the correct words of the day and the and actually one more thing the word of the day will also be available on the recording so it's really easy to to to get it and then the second overlaying is the feedback form so every day we will be asking your feedback so it's really to help us improving the academy and making sure that the academy content is meeting your your needs and your your requirements so it's really really important it takes literally one minute and so to to fill it in so it's very quick so every day you will also have like reminders to share your your feedback using the feedback form so yeah so these are basically the resources that you can you are able to find in the in the academy content folder and I think I mentioned everything thank you so much all right thank you so much Alice and we'll go over then to Mike Frost we'll give some opening remarks and of course present himself and really situate us within this broader landscape so over to you Mike. Great thanks Breno and very good to see you all welcome to day one of the LMIS academy I'm Mike Frost I'm a senior advisor here at the University of Oslo I'm a product manager leading the the tracker software development team trackers the part of DHS2 that handles individual and longitudinal data and we'll be talking a bit about that throughout the week about how that will apply to the supply chain and and the logistics data that that we're interested in just to share really quickly I also previously worked for eight years as a supply chain advisor working on health systems and supply chain for malaria and HIV in particular so for me this is this is a subject near and dear to my heart so yeah happy to happy to be sharing with you all I'm just going to give a bit of a brief overview of DHS2 as a system and our own approach to logistics and supply chain data and how that fits in with the DHS2 ecosystem so just starting to share my slides now just briefly because I always think that it's important to ground ourselves into what what is this work that we're doing and what are we trying to accomplish so I'm taking us back in time to 1854 in London where there was a cholera outbreak and this really ended up being the the start of epidemiology and of public health a bit as a discipline and then all relied on data and in fact in this case kind of geospatial data we're looking at a map that Jon Snow created during the cholera outbreak at the time there was the theory that cholera was being spread through the air and Jon Snow didn't believe in this theory and ended up creating this map to try to find where all of the cases of cholera were and triangulated them around a central point here the the water pump that was on Broad Street and from that decided to take off the handle from the water pump and help to end this outbreak and the the reason I share this is to say that from the beginning public health and the approach of of trying to really improve the lives of of people living with the different conditions diseases getting access to medicines always has relied on data and since this time health as a field has kind of gotten hungrier and hungrier for data and there are many many competing demands and needs and ways to analyze this data so I'm throwing this up here just to give an example of of a single interaction of a child receiving a vaccine and the kind of data that is generated by that interaction with the health system and the kind of analysis and decisions that are meant to be made from that piece of information and this is to help us to understand why it is that the DHS2 software is interested in an integration point and linking in to logistics and having a shared set of data between health systems and logistics systems but hopefully as you're taking a look at this slide you're seeing the the many different groups that may be asking for this data that are involved with disease surveillance that are planning future immunization campaigns those perhaps that are responsible for following up on an adverse event following immunization there's always groups that are responsible for the population management managing population registers designing catchment areas and of course the topic that we're going to be talking about now the use of that vaccine the the way that it was stored how it traveled through the supply chain who ended up receiving it again if there was an adverse event perhaps being able to follow up and recall a batch of vaccines so there's a lot of information generated by every single health event and it's important to have a set of tools and approaches that are going to help the people that are responsible for providing health be able to focus more on health and spend a little bit less time on the data capture and reporting of this the problem with this of course is that where the clients are being seen is also the place where all the data is generated it's also where all the data is being requested from so many of you may be familiar with looking at the health sites the health posts health facilities clinics where they have all of this data sitting not just in the patient files that you see lining the walls here but also the many different requested reporting forms and registers that are coming from various different parts of the the national health programs or the national logistics system and i'm showing you what to me is one of the best organized sites that i've seen here from a picture i took in in zambia in 2010 it really can be much more chaotic and hectic than this and many of the the health workers and the people that are managing the storerooms that will be talking about those that are responsible for doing monthly balance and check of logistics are all the same people when you get down to these lower levels supply chain and the lower levels of the health system and they have competing demands on their time where the hope and desire is that they would be able to spend the majority of their time caring for clients and being able to help the health of the population that they're serving but they very often are spending significant portions of their day filling out reports doing aggregated weekly summaries tallying things up and registers and spending a lot of time on this information just wanted to give you a quick glance at what the information systems are and how they break down at these different levels what kind of responsibilities they have so i'm borrowing this actually from some activities that the world bank has been doing this year trying to map out the different information systems in country and what their areas of responsibility are and again we won't dive into all of these different pieces but what i did want to give you a quick look at was the top left corner here where we have the hms the health management information system which is covering health services but also contains information about medicine and supplies also contains information about who is working where and the human resources concept and also the trackers level which is covering direct point of care data information in many times providing decision support helping the health workers plan out their day and capturing information on what people are diagnosed with what they're provided in the terms of health commodities and you can see there's of course overlap with the kinds of data that are being collected and gathered in these systems with what is traditionally thought of as the lmis the logistics management information system so i just wanted to dive into this a bit more we're a diverse group and wanted to make sure that we had the same understanding of what hms is and what the data are and then talk a bit about the lmis so the the basic hms architecture again this is super simplified if you go to a single country and try to map out what the information flow is for an hms it's going to be a little more a little more chaotic than this but just giving you a list of the types of data being collected and where it's being generated you can see that whether we're talking about the z surveillance routine services for reproductive health a and c immunization whether we're talking about the population or the facility registry the the source of all of this data really is down at the facility and community levels and in fact what the health systems are trying to reach ultimately at the bottom of this chart are of course the clients and this is something that we can see repeated when we're looking a bit at again a very simplified version of a national lmis again if you were doing a better look at your national lmis it would look like a spider web of data going back and forth between all of these sites but just trying to break down the various levels here and the national lmis where it is operating well most often is covering the the supply chain from the port where things have been received traveling through their regional central warehouses where it enters into the health sector where it's entering into the hospitals the district warehouses down to health post health centers and community health workers but i've grayed out kind of the bottom part of the bar there that says national lmis because of course this is the most difficult part for the lmis is to capture the data that is further down in the supply chain and have clear visibility into how the commodities have been broken up between sites who is receiving those commodities where is their wastage where could there be transfers so typically the lmis has a much more complete set of data when it's hitting kind of the district level and above so we if we align these two information systems and take a look we can see there's a very clear alignment down here towards the bottom part of the information chain particularly looking at the facilities in the community level and of course ultimately trying to reach the same people whether with health services or with the health commodities we're trying to reach the same population at this last mile of course there is very rich data that can be used for the logistics system this is where you could get actual consumption data know who received what health commodity and based on what diagnosis at what point in time this is where issues happen from the storeroom to the dispensary in the health facility or from the health facility to a community health worker this is where it's most important that we have an understanding of storage and understand if they're being able to to keep the appropriate bounce and supply whether they're stocking out whether they're facing expertise and it opens up opportunities of things like transfer between sites where one has overstocked and the other is understock so this is really an area that for us is is a key focus for data capture but there's another area of course at the national level where these things coincide where if you're making planning for a future immunization campaign or you're trying to quantify for the malaria need then again equally you're going to need that information and be able to triangulate between the health services data and the logistics data and make appropriate plans for the future be able to respond to crises be able to respond to stockouts and so there's a higher point in the chain as well where dhs to and the requirements within a logistics information system align so now i'll take a step back from that kind of introduction and talk a bit about what dhs to is for those of you that are less familiar so we are referring to the united nations general roadmap for digital cooperation where they have outlined the concept of digital public goods as being something that are essential for reaching the sustainable development goals for providing the kind of support that are necessary and especially low and middle income countries to be able to get the information and make the decisions necessary for the sustainable development goals so we dhs to are meeting the the goals and needs of the this concept of a global public good this is really coming from three kind of tier summary definition and it's a definition for a public good that has been around for some time and is often applied to things like roads or water or electrical infrastructure that the concept being that for a global good it must be something that if used if consumed doesn't reduce the quantity it's something you can't prevent others from using using it's available it's freely available more or less worldwide the digital public goods alliance has taken this definition a step further and created a standard for what would be considered a digital public good this standard is supported by the Norwegian agency for development UNDP UNICEF and other groups and again this applies to dhs to in fact dhs to is one of the first digital products that they chose to register in the digital public goods handbook and demonstration of this specific standard so a digital public good is something that is relevant to the sustainable development goal it uses approved open licenses dhs to relies on the the three clause bsd license and is freely available can be downloaded and used by anybody there's clear ownership the roadmap and the software development for dhs to is managed here through the university of oslo at the health information systems program center i'll talk about that more in a bit in a bit more it has platform independence is properly documented you're able to extract the data and use that data for analysis you adhere to privacy and applicable laws adhere to standards and best practices do no harm by design and then further look at that ninth principle for data privacy and security again i won't go into all of the details of this but wanted to outline a bit what makes dhs to different than a lot of the other information system choices that countries can make the dhs to is not something that you need to have a specific partnership with the university of oslo you can download and use the software yourself again one of the reasons that we record these kinds of videos as we're doing in academy is to be able to share those publicly there are many guides and tutorials available there's the opportunity for for the country themselves to own the dhs to platform to install it wherever they'd like to whether locally or in the cloud and have their own staff working for the the various groups in the government that can manage the system over time and that's really the goal of what dhs to is so just going past this quickly showing that it's registered and listed within the digital public goods alliance part of what i wanted to show here is that this digital public good is meant to be useful the world over and oftentimes from kind of the global donor agencies perspective they're thinking of this going from the developed and and wealthier parts of the world to low middle income countries but i'm showing you a headline here from uh norway where they this during the covid crisis they also had to turn to dhs to and of course most of us won't speak norwegian so we'll do a bit of translation here showing that actually some advancements within dhs to that began with Sri Lanka and Uganda came the other way back to norway and ended up being the system that was used for a half of the country's health centers when it came to the covid contact tracing registration surveillance um and was something that ended up being really important for the efforts of norway to battle uh the the covid epidemic um again for us this is exactly what our hope is is that this dhs to platform is something that that consistently benefits everyone and can continue to improve over time and be used by by anybody that needs it and so again as we're looking at information needs and we're considering logistics and health these are actually just a couple of the areas that we cover we've also been asked to branch out and to cover more within the education information system sector and it's being used by many groups all over the world for various purposes whether environmental or monitoring of workforce or internal data systems for NGOs it's a very flexible platform with a very generic data model so just showing you a very recent quote that came from the prime minister of norway as he was addressing the general assembly of the un referencing the some 70 countries that are using dhs to as their national health information system and talking about the importance of being able to expand this to two others so what is dhs to now that we've talked a little bit about kind of the values and the intentions uh dhs to is a piece of software that has grown out of a 25 or more year collaboration with many partners around the world um it was begun in collaboration with the university of the western cape in south africa during the 90s where the emphasis was on starting to just be able to collect any data at all from district levels within the health information system since that point it has grown into dhs to as a platform the online version of this software that's open and available to everyone there'll be lots of links that are shared with you about where to access materials for dhs to it works whether it's in the web browser or on an android client it can be hosted locally or in the cloud as i mentioned and it's really designed with a focus on low and middle income countries and trying to support the needs of information capture it's used for clinical workflows as i've mentioned for a health aggregate kind of a summary recording into the hms but also many other purposes and is endorsed as a global public good uh the university of oslo has been managing the the development of the software um and doing two releases a year and being supported by a wider array of global donors many of whom are also directly supporting the supply chains in the the countries that we aim to support uh many of whom have kind of uh aligned interest in reporting and collecting data that can be used for better decision making when it comes to public health this is just to give you a snapshot of the global footprint of dhs to more than 90 countries use the software in some capacity there are 69 or more national scale systems um and it's supported by a large community as an open source platform we conduct uh many many different trainings regionally and globally um and have a large community that you can join there'll be a link for this the community of practice cop dot dhs to dot org um and that will be an area where you can speak to each other help support one another answer each other's questions when it comes to using dhs to for logistics um i'm showing you the other part of dhs to that part was looking specifically at kind of the aggregated hms kind of reporting but dhs to equally is being used very broadly by a large number of countries for tracker for individual level data collection and this is an area that much of the world is able to move to um that they're able to collect now data down at this facility level down at the community health worker level kind of client interaction or patient encounter one at a time be able to collect that individual data which is very powerful because you can use that data for all kinds of future analysis even analysis that you weren't yet prepared to conduct because you had set up aggregate forms the individual data can be disaggregated and combined in many ways and with the logistics uh information can be triangulated better with the health data and be able to have a deeper dive into what this information contains so from our perspective the this platform is adopted so widely and used by so many because of kind of these three approaches building unestablished approaches and partnerships many countries that already use this as a platform already have internal capacity within the ministry of health or within their id departments they have local networks and uh private vendors that they work with that support their dhs to system uh we think that further investment in the platform in these countries strengthens them overall for everyone so it's not just an individual investment or a vertical investment but it actually builds out the capacity and capability of the tools over time and that it leverages this local expertise and innovation who are often building past beyond what the platform currently does when they have a specific need and those developments can be gathered back into the main platform to be shared with the world they can be posted through an app hub that we host and shared with one another so again just a quick snapshot and then look at the the the benefits of using dhs to and why it ends up being a sustainable and usable solution in your countries this is taking a look at our annual conference this year where we had more than 800 people attend the coming from 118 countries with a really strong support from ministries of health this event is something that we're not able to have everybody join locally anymore and fly to norway so it's something that's become an online event with more than 500 organizations attending so part of the point of sharing this information with you is to know that if you aren't already in contact with someone in your country that is using dhs2 you probably could identify them and seek to work with them our idea would be that you would be adding to and strengthening existing capacity in the country and so you would probably already have somebody that is hosting a version of dhs2 that is supporting it through their hms that is using it for various health programs so a quick look here also at our regional support and there'll be some of uh this staff that are online we have a network of regional partners that all have this same name hisp the health information systems program uh we as the university of oslo do not directly work with all of the 90 countries mentioned in fact we usually try to have local groups that can be the ones that are supporting and working closely with the government you can see a list of those that are very closely associated with us these groups also in return are a part of the software development process they bring requirements back to us to work on in the platform they provide use cases they document challenges they report bugs and so again they would be a very significant resource for you as you begin to work with dhs2 and the logistics system there would be most likely a regional group in your area that could provide direct technical support that could troubleshoot that can help set up configuration that can work with you just to mention for the academy which you are currently aware of because you're attending one there is a website for all of the academies there's also an online academy to give introductory knowledge about how to configure and set up dhs2 and there's regional trainings held worldwide all the time at this point we've trained i think over 6000 users of dhs2 meaning that there's a large community that you can draw on in terms of receiving direct support just showing you a bit of the quick screenshots of the the website where you can download the software again you don't need to ask permission to do this this is freely available with all of the notes and supporting documentation many different guides that are available to show you whether you're an implementer a developer or a system admin how to support and use the dhs2 software and there's very specific guidance written also that's pertaining to different topic areas including information available about how to set things up for logistics and supply chain we also have an open roadmap so that if there are aspects of dhs2 that you are wondering if it's under development or would like to be a part of the the offered set of functionalities you can go to dhs2.org slash roadmap and see what we're currently working on you can break it down by different product areas and see what the analytics team is doing or the tracker team is doing and you can join our publicly facing JIRA as well where we submit issues we track our developments where you can report bugs and be a part of this platform and help to make it better for yourselves and for for all of the global users okay this will be kind of the final part of my overview here i just wanted to make a mention of dhs2 packages the University of Oslo we are a collaborating center with the World Health Organization and have been for some years part of what we have done working with the World Health Organization is to develop the concept of a package for dhs2 which focuses on a specific need a specific disease a specific health area and does a pre-configuration of the software to be able to capture all of the necessary data to produce the right kinds of analytics to show those visualizations appropriately to set up the appropriate kinds of reports mainly or basically just to give you a sense of what this is like we're looking at an empty box of lego with with many different pieces here this would be what you would get if you just download dhs2 you get a bunch of parts a bunch of pieces and you would need some specific knowledge about the domain area that you're working towards and dhs2 as a tool in order to be able to build something functional but the idea of having a pre-configuration of dhs2 with documentation is to give you something that is a bit more purpose-built that has instructions and that can help you to build something that will match kind of the vision that you have and the needs in countries so when it comes to logistics this means having pre-configured templates that are available that can be adapted for your country so they would have the key data elements defined they would have dashboards that contain the appropriate visualizations that have recommended approaches to doing validations of data that have guidance and materials about how to approach logistics as a topic and can be then adapted over time for your needs for the local supply chain configuration for matching the health system for matching the work processes in your country so this is our approach we create a global good that we share with everyone through the the University of Oslo we have many regional hubs and partners that we can refer you to and they can provide direct local support they most often already have a connection in your country and you can work with them and we try to support national implementations local ownership and sustainability in the country so all of these three concepts we think apply very well as well to the logistics space that it's an area that has the same often the same group of data collectors often similar data requirements and data analysis needs and often providing the kind of information that is needed for the decision makers at the the highest levels a quick look at how quickly these things can roll out in an existing country this is just to give you a look at the timeline for COVID we saw that early January 2020 Sri Lanka moved very quickly to create their own version of DHS2 for COVID-19 configuring it for the needs of that country that was well before even the WHO got around to producing the technical guidelines for COVID-19 surveillance late in February we worked with the Sri Lanka and Uganda configurations of DHS2 and put together one of these standardized configurations or packages and put that out to the community by May there were 27 countries that were using DHS2 as their national COVID surveillance platform so this of course was leveraging the existing infrastructure in the country working with the people that already knew how to set up and maintain and establish these information systems leveraging also the kind of global partnerships that the DHS2 community has working with WHO UNICEF CDC and other groups and being able to channel some of the flexible funding that they received for improving information systems again all of these we think are concepts that apply equally to the health supply chain to logistics reporting and being supported by many of the same groups so with that I think I'm going to round it out and show a bit of what scale looks like for DHS2 so that you can have a sense whether to support your country but we have systems at this point from using COVID that had up to 20 million plus users at this point this I took these numbers back in December 2021 I know Nigeria at this point has over 25 million individuals registered into their system so they can support very large and very transactional kinds of databases and systems that would be necessary for the many commodities that are being managed in your supply chain and the way that reporting works we have many tools that are available for how to implement we'll go over a lot more of this information in the week costing packages helping you to understand what it would take to roll this out in your country will give you a lot of guidance and information about how to do the implement implementation what are the kinds of things that you should plan for the the challenges that you might run into and ways that you can work with the platform and wanted to just mention that we also as an open platform are very interoperable we focus highly on this you'll get more information from Austin and others about extensibility in the way the platform works but just giving you a sense that we already are collaborating with many of the tools that are in the health space and the supply chain space you'll get a bit more information about this throughout the week as well so this is just a quick schematic to show you the kinds of interoperability that can be achieved with DHS to this is looking directly at the Norwegian system which the health implementers here set up themselves connecting to many different registers population register the clinical record system the immunization registry health data registry so it would be our goal as well working within the LMS space to be able to exchange data with the warehouse systems with the the open LMS system that you're using with whatever ERP systems that you have DHS to as a platform can be set up to exchange data with all of these various systems so with that I think I'm going to round out just posting a bit of the these bullet points that are repetition somebody has asked already for materials in the comments just to say that all of the slides and all of the documentation will be shared with you to be able to follow up on and we're excited to be with you in covering these topics and there'll be a lot more discussion throughout the week so thank you everyone and I will turn the the spec over to Brennell okay thank you so much for that mic that was really enlightening and I think this really sets the entire week I think in focus it sets the the big picture of where we will come in and from here on out we'll go deeper deeper into the DHS to LMS use case to Mike and as he said the resources and the recording will be available later the resources are available now so you can review it if needed we'll just hand over now to Ghassim who will present some community resources over to you Ghassim yes hello can you hear me and see the nice screen loud and clear and we see the screen great thank you Brennell and amazing presentation Mike it's just really full of the community spirit and which is what we what what we see from the participants here in the joining the academy I am familiar with many of them and the community practice and actually in the community posts for this academy announcement we have 12 people click the link from the from the post here and sorry here echo okay so welcome everyone um my name is Al Ghassim share for Dean I'm the community practice coordinator in the DHS to community and I'm just presenting very shortly and briefly for the community practice which some of you might already be familiar with this is the announcement for the LMS academy and as you can see here it was posted in the implementation category in supply chain and LMS with LMS tag and and so the community when you join the or visit the community practice site you'll find several categories which are really really if you pay attention and Mike's presentation are like it's where you can actually be part of that it's where you can share your stories where you can connect with people who are in projects around the around the world and and supporting global good global good projects as well and and also in the announcement category you'll be you you'll be receiving announcements from the core team and the new releases so it's a great chance for you to always be in touch and for the implementation I'll get more into that in the next slide but also you can share your stories or ask about the best practices for how to use DHIs to how to configure DHIs to really read about other people's stories and experiences and and learn from their or discuss discuss with them and another category is a support category which for example if you're facing a technical issue and you want to know how to solve it there are other experts in the community who are very helpful and and would like to help and of course the core team is always present and there are a few developer there's a developer category and a bunch of categories that you can check out but more specifically for the implementation category there is a subcategory called supply chain at LMIS which is congratulations I bet you've been waiting for this academy and this is a great chance for you to share share there share your ideas what your use cases are and how you what kind of features what kind of features would you like the core team to develop and in addition to this subcategory you can see a bunch of digital data packages here interoperability subcategory which which you'll find some examples of integration or you can suggest your own or if you have questions about that and want to know how to integrate between two different systems then that's that's a that's at least a place to start and raise the issue um also when you're participating you try to do community of practice we're always happy to tag on a monthly basis the helpful users active users and it's a cop monthly posts you'll be tagged in it and you're highly encouraged to have that action and participation in the project by being part of the of the community and also just a quick reminder here there's also subcategory for the connect category which is like for people of non-english speaker speaking countries right where you can if you want some more explanation from the docs and they're not translated or you want to translate something that that's a place where you can share and to continue this part of engaging in DHS community part of it is also showing the spirit during the academy so this is why we're sharing the DHS to academy badges and when you're completing for example of course you get you get the this badge and then during this academy we have a super active badge and super helpful badge as well as the completion badge um so after completion you get the badge and if you're super active in the community you're asking questions you are helping other users if you're so if you're helpful if you're they ask for a link for example and you share be the first to share it with them uh sharing resources um so you actually are going to be selected by the instructors and the facilitators and and you'll be granted the badge um so you know as soon as possible some of the courses we're still granting badges for them so they're still in progress so if you're expecting to receive a badge hopefully you'll you'll get one very soon and um this was a brief presentation but really if you want to learn more about the DHS to community practice there's a spotlight video and on our youtube channel which are share the link with you from on the zoom and um see you there and uh then also after the academy remember you can always go back to the community practice and continue asking questions and sharing thank you so much thank you so much Algassim that was really great and i hope everybody can connect and be active in the community practice also uh after this academy ask your questions share your experiences and um we'll be happy to engage with you there as well i think now we have uh group photo um i think Alice you know you know how we can best do this so over to you yes so this is the traditional group photo it's very simple what you will be invited to do so we're going to do it like in two times so the first attempt um you are always invited to take your mobile device and go on the android capture app so it's going to be very fun you just have to next to your yeah exactly like follow Bruno's example this is perfect so we're going to do one shot with the android capture app and another one with just your faces right just a minute i will let you know when i'm ready to start yes please switch on your camera everybody so that i can take the screenshot perfect yeah okay cool exactly okay yeah so grab your phone with the android capture app and just smile right okay i don't see many phones actually please don't be shy yeah that's better okay ready smile smile smile yeah okay let me see how it is let me do another one quickly sorry okay another one this one i don't see lots of smiles really please like you are super happy to be here perfect thank you so much all right thank you for that Alice that was great and thank you to the participants so far that was really a great introduction and a start what we'll do now is continue until the break at 11 30 and i'll go through the more specific then dhs to lmis approach or methodology so this is very much building on what mike began presenting providing a this broad picture of how the lmis approach fits into this broader landscape so now i will just dig a little bit deeper taking on then where he left off to saying what is it that we're working on now specifically for lmis within the dhs2 system all right and this will also set the stage for the coming days particularly day two three and four will do a deep dive into each one of these features so this is the overview confirming that everybody can see my my screen and presentation right yes so then i'll go through the dhs2 and lmis the why why this approach and why we're doing this now the how how we propose that this should be done and best practice that we're promoting the overview of the specific features that we're then building into the system and what you can actually use i'll quickly touch on some terminology and i think this is particularly for those coming into the dhs2 environment into the hispan dhs2 environment that don't have previous experience just two or three just a few terms that i think might be useful to keep in mind and then i'll quickly present the sandbox where you can actually already log in and try some of these different configurations and see how this works before we go into them in detail now to say that we are here you know george and i specifically working as dedicated resources in the lmis team at the hisp center in the university of osso due to a collaboration which is the stela center of excellence based in the university of basal and this was thanks to a collaboration between novartis university of oslo university of basal and swiss tropical and public health institute where we came together to work on a collaborative co-creative ecosystem looking to improve availability of medicines to support public health and this is a very broad partnership where we're looking to bring different stakeholders around the table to improve this aspect and at the university of oslo specifically in dhs2 we looked at features that could support that within this software quickly then jumping into the why of dhs2 and lmis and mike touched on a lot of these points but it's looking at the synergy of this existing platform and the system that has been implemented for hms management in many different countries there's an existing ownership by these countries that are actually running and maintaining the instances there's the the great resources within the hisp network that are actually supporting the implementations you have the capacity of the users you have resources within the system that are being used and shared you have users at this last mile level that have access to the to the system have their login credentials and have knowledge of how to use the system so what we were looking then to do is to capital capitalize on all of these existing advantages and then promote a proper good use of stock management practice within the platform there's a question of cost and implementation particularly when looking at last mile logistics there's a large number of facilities with lower volume transactions where the cost may be nearly prohibitive for implementing an end to end solution so we're also looking at bringing this data digitizing it and connecting it with the central system but through a cost effective way through a tool that's already known and used by the country and already in the hands of the health workers as again mike mentioned oftentimes are the same ones doing the store management and managing supplies as well as treating patients and doing many other tasks so this is really adding an additional program an additional data set to an existing tool that they already have access to and have a full support network helping them to to use that and that goes into the competence aspect that they do not need to learn or make use of an additional tool with staff turnover that makes it even more important to have an existing support network from a central level to provide training for new users, first line support and ensuring that they're able to access the tool and make it relevant for their day-to-day work. We then get into the LMIS landscape and this is something that we began doing at the beginning of last year so when George Maguire and I began within the HISP center in the University of Oslo we looked at what the existing solutions were and what was available in the market and there are quite a few solutions I write many more there but in a recent workshop we were a part of with UNICEF they went into the hundreds and even thousands of different solutions that they have found in specific countries all divided by programs and different areas supporting supply chain management so there are very many solutions available out there and we were then looking to see what kind of a gap or need could DHS to fill given that there were so many tools already available to quickly mention that there are quite a few implementation challenges that can come up when implementing this kind of solution end to end some of these include scalability and sustainability so the ability to implement it effectively at this last mile level in facilities also in terms of the costing and HR support and there's also the additional challenge of having low resource sites sites with limited power or mobile coverage and how you would actually digitize a site with those kinds of challenges and these are things that we learned and what we came to understand with this landscape analysis throughout the week as I mentioned we'll have some of these partners actually presenting at the end of the day so you can also post some of these questions and engage with them and ask and confirm some of these assumptions or findings that we have but this is the general kind of conclusion that we came to and what we saw as an existing landscape with certain challenges particularly at the last mile many different solutions of different very good features as I write there so not all of them will necessarily have a warehouse management module integrated or not so we saw many different solutions and this last mile really being an area where DHS to could come with some value added and improve the quality of supply chain management and also integrate for the purposes of triangulation of data so then we get into the how actually before we get into the how on the landscape questions many different many people ask once we touch on this question which ELMIS should I choose and this is a question which would always give back to the person and say this should be something that's defined according to your needs regardless of which one of the platforms we choose we will do our best and work together with them to integrate and to work together to bring this last mile data into their system and we have multiple examples and cases and some of them which will present during the week on how this can be done so we don't have any preference we really work with all of them we've tried to engage with every single one of these and we really have a agnostic approach to it where you define your needs and choose your system and then if it's viable to integrate we will work with them to find a good solution now moving on to the DHS to and LMS to how so now quickly to take a step back and also Mike briefly mentioned this but I think it's important to relate it to the stock data that we have three different data models within DHS to natively the first being aggregate data this is the model that we use for LMS reporting so if you're providing monthly reports on the amount of stock that you received in the site the amount of stock that was issued stock losses you're doing your end of month stock count and capturing that data we use the aggregate then mode and this is something which we'll get into in the presentation tomorrow we also have anonymous events so this is something that we used for logistics specifically for one example is acknowledgement of shipment received in an integration and this will be touched on later today when you have a shipment sent from a district level or an upper level going to a facility running DHS to you can use an event to confirm the reception of that of that delivery and then through the integration the central system the ELMIS can automatically populate the the data values for the amount of quantities received so that doesn't have to be done manually and each one of these receptions can be captured as an event in the event program and then lastly we have tracking so this is the tracker app which also Mike mentioned and this is what we are building a real-time stock program on so this is the transaction-based stock management tool which will be able to manage each transaction whenever stock is issued from your medical store and then this data can also be aggregated and used for reports but here you would have a more real-time solution for having you know what your stock position is at each site once you have this app running using transactional based a transaction based model we also leverage quite a bit the DHS to android capture app so this is really to focus on facility level ELMIS features it provides native online offline capability you have access to the analytics in the same way as you have on the web you also have all of the data entry capability and this is really one of the key aspects that we try to leverage for the low resource sites where you might have limited connectivity that you're able to still manage your stock transactions and then synchronize once you have a connection so this is another key aspect of the implementation it doesn't it can be done using a laptop or pc but we really encourage and promote the use of the android capture mobile app of course tablet or a or a mobile phone um and then not the least of which the the hisp partner so here is a quick rundown of all the different hisp groups and they're the key implementing partners for this approach i mean for a lot of the questions and for a lot of the the methodology that we're promoting we're working on this at the hisp center but the actual implementation the country level support putting this into action is really coming through the hisp groups and if you're new to the community if you're new to dhs2 then i highly recommend that you identify who your local or regional hisp partner is and connect with them and find out more about how you can work together with them they'll already likely be working with your hms teams so find out who they are as well who are the ones that are already using and know the dhs2 system in your country and connect with them and for us really the hisp groups are the the real experts of the software those they're the ones actually seeing it in action supporting uh you know production instances and really are the ones who have this competence to implement and support the countries so a note to them that the simple these implementations happen in large part through the hisp groups now for the dhs2 lmis approach we had this landscape analysis we looked at where we could fit in and add value to the to the existing landscape how was stock data managed and where were the gaps and now once we kind of identified this last mile as being an area of need we looked at also what were existing guidance and documentation industry standards that we should follow and we should adhere to and we came to multiple documents but these are two that we like to highlight it's the country guidance on selecting an lmis from global fund and gavi which has a list of some lmis which can be which have already been pre-approved and that you can consider for having as a central solution and then also the target software standards for vaccine supply chain information systems from gavi which is also endorsed by global fund for general medicine supply chain and now these provide a starting point for how we should engage in how we developed a lot of these features particularly the target software standards you'll have a very fairly detailed list of features and requirements for then an end-to-end supply chain lmis and what's important to note and this is something which we have then published on the website is we look to fulfill a lot of the features for this last mile having stock data available sharing this data with the central lmis making sure it's available for decision-making informing things such as demand planning and forecasting and demand planning also the ability to connect stock data with health data so this is already in dhs2 it's in principle a you know a given once you're using dhs2 for stock data so we meet a lot of these requirements and for where we see that the system does not meet these requirements we look at the integration approach to then fulfill those central needs to quickly list those then it's having the end-to-end visibility where we focus on the last mile within dhs2 it's having this availability of real-time data and that we meet with the transaction-based app so having the transactional and event-driven system but also being able to provide aggregate-based reporting which we we do that the interoperability with HIS as I mentioned having it in dhs2 you already have that data available and then cold chain monitoring temperature monitoring and some additional features which we are also working on so given this starting point on the landscape and then these requirements we came up with an approach where we look at the end-to-end supply chain nationally from left being at a central level to the right being a facility level as having a central system what referred to as the upstream LMIS providing your full-scale supply chain management and then at level as preferably using a mobile app to do your stock management either report based on transaction based having these cold chain management temperature chain equipment which means the assurance of those in one of the sessions using gs1 data matrix capability having the performance management dashboard so the ability to also have analytics indicators available to that health worker or that storekeeper who's collecting the data at the last mile that they're also able to access data and see that data in action and even make decisions rather than simply input feedback loops to their work to actually inform what they're doing so this is another key aspect and finally a simple product catalog which allows them to see what items they have available with any key information for the facility ability and integration yes it's breaking off sorry turn out is it fine just let me know i'll continue and then let me know if the if the connection is not good yeah it seems better now yeah okay so then i'll quickly give you a snapshot of the interoperability approach and this is something that is built into dhs2 at its core and again austin who will be presenting after the break will go into more details and you'll have the technical technical expertise to really explain that but on a very high level if we're looking at the a very generic structure within a national health system if you have your health information pillar on the right using dhs2 for both data collection analysis storage and analysis we foresee dhs2 only being used at this last mile level we're not looking to provide an end-to-end solution we're not looking to provide you know a warehouse management system within dhs2 we're not looking to provide order management we want to have this and promote having a central dedicated tool in elmi s or erp depending what the needs in the country are the scope and scale that you have this dedicated a specialized software and then you have an integration either system to system or through a an interoperability layer depending on what the context is in the country you're you're working that the data then from facilities are connected to the central tool i think one key aspect and something which then to connect to a thursday session so the session on performance management framework what we're really looking to do is provide data from consumption level and the importance of having this consumption level data for forecasting and demand planning oftentimes orders are made or assumptions are made on forecast based on what was previously shipped rather than looking at what was actually consumed so then having this data available for that decision making for that forecasting is one of the key aspects the ability to connect this to even advanced tools and even more advanced systems providing a you know machine learning or ai to inform you know this whole forecasting challenge is a key aspect that we'd like to to ensure that's possible but first you need the data to be available and a lot of the challenges that we see is having a paper based system which may be fine it may be a slow process to actually making that data usable available for decision making is a long process it may be months before that that's actually available for the decision makers at a higher level so the digitization and making data readily available is a key aspect at the same time what we're saying here and partly implied but what we should be explicit about it is again do not use dhs2 as an end-to-end solution that's not what we're proposing and that's not what the system is best suited for there is a limitation to what you can get out of the system and this is again why we're promoting this and really trying to cooperate and communicate this well to partners donors and to all of the elm is and ERP vendors that we're looking to fill a gap and this is a choice that we promote that countries make for themselves to see what is the best solution but if it is that you have this opportunity to digitize facilities with dhs2 that we're there to cooperate then with the vendors that you choose again just a quick snapshot and shown in a different way that you have your central warehouse the regional district warehouses running dedicated elm is and then you have your health worker community health worker health center or hospital using dhs2 mobile and then connecting that data to complete this end-to-end supply chain management one thing which should be and can be identified at the time of not implementation but project planning is where do you set this line where do you set the limit of how far down the supply chain do you implement your elm is and where is it more beneficial to have dhs2 in you know many sites with lower volume I think that's a key aspect of an implementation is in the assessment phase to identify what the threshold is for implementing one system or the other where do you get more benefits of having you know the open source solution and the dhs2 solution where do you have more benefit using a dedicated tool for the supply chain management this is something we can also touch on and we'll discuss in morning of day five on Friday where we talk about assessment and project planning and implementation now quickly moving on to the features and again this will just be a snapshot because each one of these will be a detailed session led by George McGuire will hold demo and show the configuration for each of these but first it's the report based stock management using the aggregate data model so this is really providing very clear guidance and best practice for using dhs2 for collecting stock data so reporting generally on a monthly basis but that can be customized we're looking it is optimized for we're looking to optimize it for mobile devices and really promote that approach to digitize the first data mile so the last mile of service delivery as George likes to refer to it the first data mile and then we're also coming with fairly clear recommendations and best practice for how to configure dhs2 for this purpose keeping in mind that we're looking to integrate with the central lmias dhs2 being a generic platform for data capture storage and analysis there are different ways of configuring it to capture your stock data however not every one of those ways will be best suited or most adequate for stocks it may be easier or it may be more convenient but what we're looking to do is really promote a best practice and that's what we'll go into why we should use for example data elements to map to your to your specific products or items secondly transaction based stock management so this is a tool that we're developing in the presentation you'll see also a link to a mockup of how this will look once it's integrated into dhs2 it's part of a informal cooperation with another organization which developed this tool and is already implementing to manage transaction based to do transaction based stock management and this will provide this real-time availability of data as it will have each transaction captured in the app going on we have cold chain equipment inventory management or biomedical equipment life cycle management now this is native features within dhs2 tracker where we manage an item or a piece of equipment from the moment it's installed at a site all of the different management cycles that might be relevant for that piece of equipment and these can be configured as needed all the way down to the end of life and this is something again that we're working together with different partners to promote and to have a broad acceptance that as an option for managing cold chain equipment where a lot of this is managed through either paper-based excel the data is in different places and you don't have data readily available for decision making so again it's part of providing this last mile tools for now equipment management remote temperature monitoring now we have an mvp with this specific blue maestro temperature monitoring sensor connecting it directly to the dhs2 app so we're looking to use a bluetooth connection and not going through the proprietary software trying to not be dependent on a subscription model but rather making tools that also can be cost effective and implemented at scale um this will then capture temperature from uh uh cold chain equipment transfer to the android app and then synchronize that with the server the two main use cases or two main purposes being for alarms if there's a temperature excursion and then for analytics to analyze the performance of the equipment and again we'll go into more detail on that on our session on wednesday gs1 data matrix something that we recently built into the platform the ability to parse the gs1 codes and all of the different uh program identifiers uh there are multiple possible applications of this and we're still exploring how it can be best used but this is something which will again elaborate on thursday as well product catalog so having some basic data to the end user for the items that they have available in their facility and providing relevant information for the end user and then last but not least it's the integrated dashboards on web or mobile and i think um one key aspect here is this ability to have the data available for decision making having it available for uh district level managers and other managers that are monitoring various sites being able to set feedback loops where if they have different information that they want to then communicate to a facility facility level user they can use tools within dhs2 to comment on the different charts or indicators and have follow-up to make that data actionable um also another aspect is having the user at the facility inputting the data and then within the same platform within the the dhs2 capture app being able to see this data being able to engage with it being able to have some actionable outcome of the data that they're reporting and not simply punching in data because they have to punch in data and making that a bit more relevant to their work and connecting it um when it comes to the integration also of the lmis and dhs2 another key aspect is triangulation of data so then it may be the case that some data from the lmis is being sent to dhs2 for the purpose of analysis and triangulation so here you have an example of having a showing a doses that have been administered and the amount of stock that has been issued and you can also have your wasted rates if you're talking about vaccines and making sure that that's within acceptable ranges so these are examples of having integration for the purpose of analytics and then not simply the improvement of supply chain management and improving the availability of medicines but also the quality of the of the health program quickly in dhs2 terminology now there's the aggregate data and there's an example and I have a link to the glossary at the bottom so if you go into the presentation you can go in and look at that but I just want to quickly really uh confirm that everybody understands this that you have aggregate refers to report base data so monthly reporting on stock issued stock received and so on so this is manual input of data in an aggregate form and then tracker is the application that's collecting longitudinal data so you have a tracked entity which may be a product a drug or a piece of equipment and then you have different events that are happening connected to that to that device and you have then data that's not anonymous but connected to that specific item you have your data elements which is the fundamental building block of dhs2 as it says and this is what we then map to the specific drugs or vaccines in the aggregate model or in the the tracker model so this is really how we promote the best practice then for configuring that you have this item being mapped as a data element which then connects to metadata which is then the logistics data which is applied to that that drug or item so this would be for example your stock received your stock distributed losses or your stock on hand so this is the metadata connected to that paracetamol 500 milligram for example we'll see examples of this and how it's configured how it's used and then configured in detail in tomorrow's session lastly you have the android mobile app which is called capture once you go into the play store to download that you'll see dhs2 capture on the left and on the right you also have the capture web app so once you go into the sandbox which I'll show you immediately after here you'll see the capture app and this is where you can access the different programs for example the biomedical equipment management they're both referred to as capture just to ensure that you know the difference between the two it's something that confused me as well in the beginning and now quickly the sandbox and I can leave this up during the break I see that we have just two minutes to go and then but I'll leave this up so you can connect to it and you can log in so this is pretty much a demo site or you can log in and test these different configurations which we've presented here again if you have many questions perhaps wait a little bit until tomorrow specific to them because George will be presenting them in detail and going through the configuration if you have more general questions where we're happy to take them but I just remember that we'll have specific sessions there but you can go to this site and already log in and you'll see all of these different programs and I'll just switch my screen here just let me know if you can see it yes great all right so here we're on the the sandbox the user is demo it says at the bottom and the password stock one two three exclamation mark then you're logged into your landing page then for dhs2 you have immediately some dashboards available a lot of these are empty we just have you know data that you can input and it's reset at the end of each day so you really can't break anything here so feel free to to click and change anything you see as you're learning and testing the system at the end of each day the database will be reset and it'll start from scratch the following day you have different dashboards that you can click on and again more will be configured over time one key thing as I mentioned capture you go into the apps icon here at the top right you can go into data entry the data entry app allows you to choose on the left from the organizational unit you can go down to the lowest level so the mahasot health center you choose a data set that you want to report on so for example your monthly stock report data recording you select your reporting period and then from the different tabs you have different groups of items which you can then report on your stock received stock distributed and so on I'm going through quickly but remember this the recording will be on youtube and you can review that and just pause at each point you also have the capture app where you can go into capture and you see the biomedical equipment lifecycle management this is the same as the cold chain equipment inventory management the same model of course the different stages can be configured so just to show that as an example you then choose your organizational unit that you're reporting for again we'll go to mahasot we'll go to our oxygen concentrator here and then you will have different stages which you can report on for this device all right so I think I will stop here we're one minute over we'll take a 15 minute break and then we'll be back at 1145 to start on the session on integration with Austin McGee all right thank you everyone and see you back here in 15 minutes exactly thank you for that recording Alice welcome back everyone so we're just past a 15 minute break so then we'll head into the LMIS and integration session just as a quick intro to this session it may get technical and there are two reasons for that first Austin McGee he's our deputy tech lead he is very smart he has a lot of competence and knowledge to share and then the subject matter itself will be it's technical in its nature so I think what we try to do for this session since it's an integral part of the approach is that Austin will go through quite a few different topics he'll give you insights into each one of these topics of course come with your questions and we can take some of those up either in chatting if we have time orally but this is rather a broad introduction to topics that will be relevant and then also that you'll need some technical persons working with you on this aspect it's not something that you will do on your own or you know completely independently as an LMIS team but rather that you'll be given some of the you know intros to two topics which you should consider some of this will also be mentioned again in the Friday morning session on assessment and implementation but specific to integration Austin will also mention some of those aspects so without further due over to Austin McGee floor is yours. Thanks Brenna and I haven't been called smart as an introduction before so I appreciate that one and I've also been told that I brought by Brenna that I have to make jokes throughout this whole presentation so I'm going to do my best and no promises about the jokes but I will also will try and try to make some promises about keeping this very high level so there are there is a lot of technical detail that we can go into for each of the different aspects of integration that we'll cover today and this will be a very high level overview of some of the considerations that you need to take into account some of the terminology that you might hear when dealing with integrations with with LMIS systems and with DHS too but it won't go into any of those details so to get into those details we do have a whole interoperability team who are willing to go available to answer some of those questions as you dive into the details of building some of these integrations as well as the LMIS team for the parts that are specific to building an integration in the LMIS space. So as Brenna said my name is Austin McGee I'm the deputy tech lead for DHS too so I oversee a lot of the extensibility and kind of architecture of the software that is DHS too and a small part of that but a big part in the DHS too world in general is integrations and interoperability with external systems and so that's what we're going to talk about a little bit today and specifically what we'll cover is in three broad kind of sections the first one is just going over some some fundamental terminology and an overview of things that need to be think thought about when doing these integration projects and the second will be some of the considerations that are important to keep in mind as you're designing those projects and designing an end-to-end LMIS system that includes both the facility level supply chain management their supply management but also or stock management sorry but also the upstream LMIS and supply chain management system and then third we'll talk about some some patterns that we see and we recommend in the integration space so how to actually design these integrations between two different systems so that they are reliable and timely and and have different trade-offs based on the the design that you choose and so we'll talk about these three different categories three different sections and over the next roughly hour or so but before we get into that let's talk about why why we have a section presentation on integration in in this academy and I'm going to steal Brenno's slide here which is the the overview of where DHS2 sits in the LMIS space and you'll see that interoperability integration is a big part of this this diagram because DHS2 can serve the needs of the the people that are out of facility that are delivering health services have their stock on hand of a particular type of drug and and putting supply chain information in front of them makes a lot of sense but that needs to then that information then needs to flow back to an upstream system that is managing the stock for an entire country for example and likewise the the information from that upstream system that national full-scale ELMIS in this in this diagram needs to flow back down to DHS2 when a new shipment is coming to a facility or when there's a for example there's a a shortage of a particular type of drug or those types of things there are many different types of information that need to flow between these different systems so this is why we're talking about integration in this today and I wanted to pull this slide the the Menexus team is is actually presenting next I think later today so you'll hear a lot more about this specific use case then and I'm not going to get into the details of what's actually in this diagram but this is an example of a real-life integration between DHS2 and an upstream LMS system that has an exchange of information using an API and this is the kind of thing that we're talking about when we talk about an integration so something happens in one of these systems you can see the red circles here in this diagram something happens in those systems so it might be a user presses a button it might be some some event happens like a a a patient is seen and given a particular malaria drug or something like that and that triggers a sequence of events that sends that information through the the the system where that event took place and eventually ends up in the other system and synchronized somehow or triggering an event that happens in that other system it can get quite complex and every integration project is a little bit different but this is what we're going to talk about how we can facilitate and how DHS2 is designed to interoperate with other systems in in this space this is a much more simple diagram of a particular workflow in that DHS2 to Medexus example this could be Medexus but it doesn't have to be Medexus could be any other LMS system in in the space it could be another system entirely as well and on this one I'll come back to at the very end just to show kind of how this demonstrates some of the topics that I'm going to cover in the in the preceding sections so we'll get into this right now but just to to give an idea of what this is what this actually is modeling is an event that happens at the facility level which is that a a health worker or someone at the facility receives a package with a shipment of drugs from the central supply depot so what then needs to happen is that person who has received that shipment needs to record that that shipment was received and we talked a little bit about the ability to do scanning of barcodes or just on one data matrix is another level of that and so that the the person at the facility might scan the label on that shipment that goes into DHS2 it gets recorded as a shipment that has been received and then that needs to be sent to the upstream system and that could happen immediately or it could happen maybe once once per day in the night it could synchronize all of the all of the shipments that have been received across all of the facilities in the in the country for example and but eventually it ends up in that upstream system where it can be confirmed that this shipment that was sent out a week ago or two days ago or 12 hours ago or something actually was received at its at its intended destination and didn't get lost somewhere in transit so now we have a complete idea of the shipment that was sent out it's now been received and now we know that at this facility there are these this this particular drug or this particular product that was sent there is now on hand for for their use and this gives the upstream LMI system an idea basically a picture of where everything is in the entire in the entire system whether that's in warehouse in the in the capital city or it's in a facility in a clinic in a rural rural village so how do we actually make this happen we saw some the pieces of that diagram where there are systems talking together to to get into that we'll talk about what is an API so an API is what is basically computers used to talk to each other and it's one way for computers to talk to each other and this may be review for some people so bear with me if this is very very simple for you other people maybe have never even heard the term API before so we're going to talk a little bit about just what it means and it stands for application programming interface and this means it's a way for code or computer software to have an interface to talk to another piece of computer software this allows one application which might be DHS to to talk to another application such as the upstream LMI system and typically both of these systems will have their own API so they all basically define kind of what operations someone can or another another piece of software can perform or ask that system to perform and there's a very high level and it can do a lot of different things but the basic idea is it's just a way to say these are the things that you can ask me to do and here is how you ask me to do them and that that thing might be update the stock of this particular vaccine or it might be give me all of the vaccines that you have on hand another key kind of fundamental building block of a lot of this interoperability work and and LMS in general is identifiers and code lists so it's important to think about how you refer to a specific drug or product it's important to understand who or which system maintains the list of those products and it's important to think about how those change changes to that list which when you're first designing a system you might think oh I'm just going to define this once and I'll never need to change it but then all of a sudden COVID happens and now there's a new vaccine on the market for COVID-19 or maybe there are 10 new vaccines for COVID-19 and you need to add those to your list and then you need to tell all the other systems that have a list of vaccines to update their list with these new these new ones or maybe the name changes or maybe one of those vaccines gets is disqualified from being used in the future or or something like that and you need to have a way to share that information with all of the different systems that are taking part in this in this process and there are ways to do this with some some standards but the important thing is within the architecture of a particular health system or a particular LMS system to have a single source of truth as much as possible for where that lives and where everyone can go to see what is the truth of what this list of vaccines is. That's all oftentimes difficult in practice and there's a lot of ways you have to kind of distribute that list and maybe have some slightly out-of-date lists sometimes but you have to be aware of that within your system and we won't get into the details of that too much here today. I would be remiss to have a presentation on interoperability or integrations without mentioning this book which is kind of the the holy grail of books when it comes to designing technical interoperability between systems. It's called Enterprise Integration Patterns and it's quite technical but it goes into detail about how systems talk to each other and the things that you need to think about when you're when you're designing those systems and the connections between those systems. I'll go over some very very basic patterns here today that are much more thoroughly documented in this book but that is something that you can refer to or your technical folks can refer to when they're doing these patterns. So here are a couple just examples from that book and it's an important important one here up to the top and to show that you have two different systems or two different applications application A and application B. They each have inside of themselves they each have a structure for how they model the data that lives within them. So in the DHS2 world you have for example you have data sets or data elements but another application an LMS system doesn't know what a data element or data set is because of the DHS2 specific thing. So each of those applications has their own structure which is actually how they store that information in a database. It has its own data types like a data element or a data set. It has its own representation of that data in the user interface and all of these at a technical level as well how you represent that information to a user or to someone that's interacting with that system and then you have a transport layer so and this is the API or the way that that application can talk to other systems and when it gets to the transport layer it's talking to another system that other system then needs to translate it into whatever it understands. So it might be products instead of tract entity instances in a LMS system. So there needs to be these arrows on this diagram here. There needs to be some translations between the data structures, types and representations in one system being transported to another system where it needs to then be translated back into the representation types and structure that that other system understands. So this is just some of the things that are gone into in much detail in the Enterprise Integration Patterns book. You can also Google Enterprise Integration Patterns and you can find quite a lot of examples of the different patterns that you might use. Down at the bottom here are some examples of specific patterns that are important. So you might have a mechanism to route messages to different systems based on the type of that message. You might also have or need some way to translate a message so that something that comes out of application A which might be DHS2 gets translated into something that the upstream LMS system can understand because it says data sets or data elements out of the box. It may be that upstream system doesn't understand it. So you might need a translator piece in the middle as well. Again, not going to get into the details of this, but it's just something to reference as you're looking at building integration patterns and particularly at the technical level how to actually build those systems. So now we'll talk a little bit about some of the considerations that are important when thinking about and designing interoperability between systems. But before I get into that, Brenna, I don't know if you wanted to pause for questions on each of these sections, or do you want me to just power through? Yeah, I wonder if there's any questions we can quickly take them, but I think we don't have anything in the chat here that I've seen so far. Again, these points will just be for presenting these topics. We can go more into detail once you have a specific case. I think we can maybe go on. Austin, I don't see any questions coming up yet. Okay, yeah, just let me know if anything comes in. Feel free to stop me. Okay, so first of all, resistance and fault tolerance. So this is very important in a integration situation. So you have a technical software system like DHS2, and you have a technical software system like your LMIS or ELMIS central server. And it's important to expect the best, but plan for the worst. So you might hope that DHS2 will never go down, or that the upstream system will never go down, or that they'll always be able to talk together because there's a good network connection. But we know that that's not the real world. In a lot of cases, something will go wrong at some point. Maybe it's in six months, maybe it's in three years or five years. There will be something that happens. Maybe it happens every day, maybe it happens once a month, maybe it happens every year, maybe it happens just once a decade. But something could go wrong, and it's important to have in place a system that can tolerate those problems when they happen. So for example, what happens if one system goes down for an hour? What happens to everything that is supposed to be kind of communicated to that system? So if an event happens in DHS2, and the upstream LMIS is down at that time that that event happens, do we just forget about that event? And when the upstream LMIS system comes back online, it has no knowledge of that event. Do we have to wait and send it later? Do we have to have some mechanism to make sure that we're always synchronized between the states of those two systems? Something that's important to think about. Also what happens similarly if a message gets lost in the network? So we're always connected with our phones and our computers and everything, and we assume that the internet is just there, and it always works. But sometimes, that's not always the case. So sometimes you have a bad network connection at your facility, or you might have even a network problem between two data centers, or Google goes down sometimes. It's very rare, but sometimes you can't access Google or you can't access Facebook for an hour or something, because something goes wrong. So there can be problems that happen in the network, there can be problems that happen at the service level, and it's important to plan for those. And when thinking about these, how we deal with these faults or these issues that might crop up, it's important to know that there's a trade-off, and there's often a trade-off between timeliness and correctness. So in the example I gave before where the upstream system was offline for one hour, is that a problem in your use case? And in some cases it might be, and in other cases it might not. So another example of an integration project with DHS2 was in DHS2, a COVID-19 vaccination event is recorded, and then that gets sent to an external system, which generates a certificate, which then gets sent back to DHS2, presented to the healthcare workers who can then print that certificate and give it to the person who's there in the clinic with them. So in that situation, if the upstream system that's generating those certificates goes down, then the person who's administering the vaccine can record the event that they've administered the vaccine, but they don't have a certificate that they can print in hand to the person right there. So in that case, it might be important that the upstream system doesn't go down and that there is a very fast synchronization between the DHS2 and that upstream, that certificate generation system. But there might be ways to think about the process from a non-technical level to also say, could we maybe send this certificate to that person by SMS or by email, or have them come back to the facility later to get their certificate. So that's something important to think about is how important is timeliness if we're trying to deal with situations where there might be a problem connecting those two systems. And the second part of this is to consider correctness. So maybe it's not important that within a minute you get the data is synchronized between these two systems. Maybe it's okay that it waits for a day, but maybe it's very important that the synchronization actually happens and that you know that if I'm looking at the end of a day, if I'm looking at the LMS system, it has a true view of everything that's happened during that day at the facility level in the DHS2 systems. So sometimes there's a little bit of a trade-off there. You can get the best of both worlds, but you need to think about it from an integration perspective. How do we actually ensure that we get information quickly when we need it, but we make sure that we're not missing anything and that we don't lose information because we're optimizing for quick delivery of that data. Another very important consideration when working on an integration project is security. So this is something that any project needs to think about. It's always important to think about security, but in an integration project specifically, you have two technical systems that talk to each other and DHS2 might have a lot of data on individual people, on the entire healthcare system that maybe shouldn't be accessible from the LMIS. So someone who's an operator at the supply chain warehouse shouldn't necessarily have access to the medical record of an individual person. And so it's important to think about when you're designing these systems, not only do you restrict the access as much as possible for each of those systems to talk to the other one, but also that you think about it at a technical level for where do you actually put the keys to these other systems. So we'll not get into the details of that too much, but you might actually be able to design an integration where the LMIS system doesn't have access at all to DHS2 directly. It's getting that information from an intermediary, a message broker that actually has the keys to that DHS2 system, or that is getting that information in an asynchronous way. We'll talk about that in a minute. But overall, it's important to think about security from a systems perspective, how does one system talk to the other, and how do you restrict as much as possible the access that those systems have to each other to only what they need and not what they don't need or what they shouldn't have access to. Another consideration is performance. So this was a big, as Mike mentioned, this is something that took the world kind of by storm with COVID-19 as well, is that all of a sudden you have millions and millions of people potentially in a DHS2 system, and they might all be receiving vaccination events at a similar time. So if you have a massive COVID-19 vaccination campaign, you might be processing thousands of events per minute, which is quite a bit of information and data. And then when you have two systems involved, you have to be very conscious of how much data or how many events are happening, or do you expect to happen, and what happens when that's too much for one of those systems to handle. When will the data be processed is another important thing. So in the previous example, in the first consideration, we talked about timeliness. So if the upstream system needs to respond within one minute, but you have thousands and thousands of events coming in at the same time, maybe that gets overloaded and it takes an hour instead of a minute to get that information back to DHS2. So that's one thing to think about, is that okay? Can we spread the events out over time? Can we reduce the need for them to be handled in a timely manner so that we can process them when there is capacity to do so? This gets back to that fault tolerance as well. So if all of a sudden you have 10,000 events that happen in one minute, your system should be able to, even if it can't handle those 10,000 events at that time, should be able to recover from that extra load that it wasn't anticipating. So thinking about designing for predictability, making sure that the system responds in an understood, understandable way, and for fault tolerance, so recovering from issues when they happen. This is a really important one as well. So from a non-technical level, an integration is only successful if it continues to work reliably. So you can design an integration between two systems that looks great on paper, maybe it works in a test environment, but it's only really successful if it's actually supporting a real-world use case. So in the case of LMIS or supply chain, it actually needs to translate to the drugs or the products that people need being in the place where they need to be. And in the place where they need to be, when they need to have them, and supporting real health outcomes so that the person that needs that drug gets access to it. And that's what matters at the end of the day. And in order for that to happen, it needs to continue to work. So it can't just work in a test environment and it can't just work for a month or even a year. It needs to continue to function and continue to support those real-world processes because the health programs are continuing or are ongoing. And so with that in mind, it's important when working on these integration projects to make sure that you're thinking about the maintenance of the long-term longevity of those projects and how are those going to be funded? What resources do we need to support this integration and make sure that it continues to work over time? It's not hire a developer for a week, have them build something, and then it will work forever. It's making sure that you have people that understand that system, technical people that understand that system, technical people that can adapt to that system as the requirements or the DHS2 metadata or the upstream system change, and that can fix issues when they come up because in a technical project, there always will be issues that need to be fixed after the initial development. So that's important to keep in mind. And that ties in also with budget. So that is something that you could maybe budget for hiring a developer for one week, but if that system breaks six months later and you don't have any money in the budget to fix that system, that's going to negatively impact health outcomes. So it's important to keep in mind that interoperability is two different systems that talk to each other, and you need to put in some work to make sure that they talk together well, and that they respect the actual use case needs for timeliness and reliability and correctness. And that requires oftentimes some investment. So it's important to weigh the budget and the costs associated with doing an integration project right and using some of those very scalable, very robust integration patterns against the consideration such as resilience, security, performance, and maintenance that you need to keep in mind, but have some costs associated with them. Associated or related to this also is something that George mentioned, and maybe he'll bring up again in one of the later sessions, but maybe in some cases it doesn't make sense to automate every single process. So things that happen every day or every minute, probably it makes sense to automate those because then you don't need to have someone that's manually entering that data in the other system or that has some potential for errors if they're entering that data on a daily basis or on an hourly basis, or if you need the information within minutes, then it makes a lot of sense to automate. But if it's a process that happens very rarely, maybe it's you need to update the list of products that are available in your system. Maybe you only need to do that once a year. And if you only need to do that once a year, maybe you have a system to import an Excel sheet, maybe you do that manually, or maybe you write a little script to do that for you. But that maybe isn't something you need to automate end to end to have an integration with an external system to do. In some cases, that might make sense, depending on the requirements in your particular situation. But maybe it doesn't and that is one way to think about the costs and the complexity involved is some things you might not need to automate and then you need to just put in the effort to do that manually when it's necessary. Another example might be recalling a single batch of a particular drug. Maybe that's something that happens very rarely and that you can do in a manual way by actually just picking up the phone and calling the facility and telling them that they have this particular drug that's been recalled. And you can do that in a manual way because you have information in the system. And that is where the automation to show where each shipment from a central warehouse went, where the facilities actually received it, and what stock they have on hand, all that information with the automation and the integrations is available in the system. So you can say, all right, I know that this batch of this drug needs to be recalled. I can look in the system to see where that batch went. For example, if you have that system set up to actually track batches through the system, and then you can pick up the phone and give that facility a call rather than building an automated workflow just for something that might happen fairly rarely. Okay, now we'll get into something that's a little bit more technical. It's not super technical, but it's some of the patterns that we see in designing these integrations between systems that support the considerations that we just talked about. Before I get into that, it doesn't look like there's any questions in the chat, but Brenna, do you want to jump in if there are any questions? Yeah, the chat is actually closed here. I didn't catch on that. So the questions are coming in on Slack. So if you have questions, please go to Slack and use the questions channel. But I have two for you here if you want to take quickly before you go on Austin. So one from my friend Nora Stoops in South Africa, her question is, does this mean that the API works all the time or does it only work when set up to connect? I'm not sure which slide particularly that was referring to, so Nora, feel free to clarify that. But typically, just when we're talking about APIs in general, a system will have an API or basically a language that you can use to talk to that system, and that will always be available. The API is, when an API exists, it should be available whenever that system is available. When you actually design the interoperability, you might use certain APIs in the different systems to connect to them. And that's maybe what we'll talk a little bit about in the patterns. But let me know if I didn't understand that question correctly. And I can try to do it again. I didn't understand APIs. It was the one where you had those two models next to each other. But I now understand what the API is and what it is. Is that one the next slide? Yeah, this one. Yes, this one, application A and B. Because I'm not technical, these things tend to fly over my head, but I actually was concentrating. And I now understand that they talk to each other all the time. And I didn't understand that before. So I'm sorry, I'm being blonde or Juliette. But I'm okay now with it. Thank you. Yeah, that's actually a very good question. So this line, the horizontal arrow here, between application A and application B, that might happen all the time. It might happen once a day. It really depends on the use case and some of those requirements that we sent. But the API itself, which is just kind of the language that an application speaks, that should always be available. So you should always be able to, another system should always be able to say, I want to get the list of all of the products that are in this, yeah, the catalog, and then get a response from the server. So that's where we talk about the API at this level. So the client sends a request to the server. The client might be one system, it might be just me. I ask the LMIS system, what is, how many, what, give me the list of all the products in your catalog. And it sends me back that list. So that's what an API is, is just kind of that language of communication there. And then this process of how often do we ask the system for its updated list of products. That might happen once a day. It might happen once a minute, depending on how are you doing it. So thank you for that question, Nor. Brenna, was there another question as well? Actually, we have a few more questions. Two are for me, I have to admit, but we have two heavy questions. So, Austin, either you may take it up in your coming section, so you can leave it to the end or you take them up at the end. So the first is from Robert Modi. He asks, besides the DHS2 API, are there some examples of existing interoperability tools that are open source or digital public good? So that's the first one kind of broad question. And then secondly, from Kosebi Lali, what methodology can we consider end-to-end API or using a mediator? What use cases best fit any of them? And I think each of these questions can be a seminar on their own, but you decide how you want to take them now or at the end. Yeah, we won't be able to dive into those completely, but I will actually cover both of those in this next section. So hopefully, if I don't get to answer that question sufficiently by the end of this next section, please feel free to ask those again. We'll give them your home number and address. Sounds good. You had two questions yourself, Bruno, or did you? Go ahead. We can keep those to the end. Just go ahead with the presentation, Austin. Sure. So this is actually very much in line with what those last two questions were referring to. Here we'll talk about some a little bit more technical kind of patterns for integration between two different systems. And these are fairly generic, so they're not specific to LMIS or GHIS2 and LMIS, but they are very useful in those cases. And we'll get back to the example that we talked about in the beginning to show how we use some of those systems here. So the first one here is point-to-point versus middleware in integration between two different systems. So point-to-point is as simple as it gets. It means that I'm talking to Brenno. Brenno has the answer that I want. I just ask Brenno what is the list of products in your catalog? And Brenno tells me the list of products in his catalog. So that's GHIS2 talking to one other system and just talking directly to that system. That's obviously the simplest to set up, but it can have some challenges for a number of different reasons. So first of all, what happens if Brenno isn't available? Then who do I ask? I can't ask anyone if Brenno isn't available. So Brenno is the server on the right here and I'm GHIS2. This is my joke, Brenno. And then the second question is what happens if Brenno needs some more information from me? I need to give him the keys through my house so that he can come and get some papers or something from me. So I need to give Brenno the keys to my house in order to have this exchange work. That's a metaphor for basically the other system, the other LMIS system, needs to be able to access GHIS2 directly and to have permission to read data from GHIS2. So that maybe you don't want that in all cases. Maybe you want to have a very, your GHIS2 system is very secure. It has a lot of personal and identifiable information. You don't want to give anyone the keys to that system. Then you might want to avoid this point-to-point system. Another situation where it might be disadvantageous or not advantageous to use a point-to-point design is that it might be unreliable. So you need to think about what would happen if one system, one of these systems went down. And another consideration is the longevity or the maintenance of this system over time. So you're basically talking or designing something that is very specific to these two systems and only these two systems. And if in the future either of those change, you need to change the integration as well. And if you want to swap out for a different ELMI system or a different health management system, it becomes much more difficult. So that's another disadvantage is that you're building something that's very specific to this particular communication between GHIS2 and one specific external system. So what's the alternative? The alternative is to use an interoperability layer or some kind of middleware between GHIS2 and this external system. So instead of talking directly to each other, there's someone in the middle who can say, all right, I have these questions. This is the example of all of you asking questions on Slack right now. Breno is my middleware. He is my interoperability layer because he is reading all of those questions, synthesizing them, maybe maybe deduplicating them. And then he knows that he needs to send certain questions to me and maybe certain questions to George in the next session. So he is kind of the broker of figuring out what everybody needs and who can serve those needs. So that's what an interoperability layer does or a middleware does. And there are a number of advantages to a system like this. Security is one. So you'll see that the key here is between the interoperability layer and GHIS2, which means that the external system doesn't need to have direct access to GHIS2. It needs to get the information that it needs from that broker, that middleware, but it doesn't need to have direct access or be able to request information from GHIS2 at any time that it wants. The second is scalability. So if at some point in the future, there are two or three systems on one side of this diagram, that becomes much easier when you have something in the middle, so you don't need to update GHIS2 to talk to three systems on the right. Or if you have three, even three different GHIS2 systems or a bunch of different heterogeneous systems that all need to talk to each other, they don't all need to know about everything else that's going on. This is an example of that where you might have, GHIS2 just talks to, so I just talked to Brenno, and Brenno talks to everyone else and gets information about the different questions that are being asked in that example. The third advantage here is separation of concerns. So the server or the system on the right here doesn't even need to know that GHIS2 is on the left. It just knows how to talk to this interoperability layer, this middleware. And it doesn't matter whether this is talking to GHIS2, this is talking to some other system to get information that it needs to answer this question. So this allows the systems to be independent and to separate themselves. Again, this is important for scalability as you increase the complexity of all the different systems that need to talk to each other, as well as if you all of a sudden have thousands and thousands of events and you need to have multiple systems processing those events, it becomes easier if you have a middleware. But it does require some additional design and some additional thinking to figure out how to design that interoperability layer in a way that will scale and that is agnostic to the specifics of the two different systems. So there is a trade-off there in terms of the complexity of a system like this and the amount of time that it takes to develop. I think I'm not sure if it was Robert or someone else that asked the question. But there are a couple examples of open source interoperability layers. Open Hymn is another one that's not on here. It's not exactly an interoperability layer that's more of a, yeah, basically an audit trail system for this. But there are some examples. Apache Camel is not specific to the health space or the LMS space at all. It's a generic software, but that is something that our interoperability team has been working a lot with to produce basically workflows for when something happens in DHS2 to send that information to different places. And it has some nice languages for talking to different systems. Open Function is another one that's more specific to the health space that allows routing of messages to different systems. And they have recently launched an open source version, so that is a DPG as well. Yeah, there are some others out there that you could use at this interoperability layer, but there are some options out there that serve as the basis. You still need to do some work in all of these cases to actually design the workflows that support your use cases. But there are some tools that can help you to do that. Just put some examples down here, or some links down here at the bottom. The integration page on the DHS2 website is a good place to go. What's for some of that, the links and descriptions of the projects that the interoperability team has been working on. And then even more specifically, there's some examples in a GitHub repository that show how to do specific workflows in Apache Camel that you can use if you need to, in reference. And additionally, if you are working on a project, particularly with Camel, but in general, you're working on a project to integrate with DHS2, please reach out because we can support you in figuring out what APIs to use and how to build those systems in a reliable way. So next, we'll talk about another kind of pattern that we see in interoperability. It's actually two different patterns here and what the trade-offs are between them or the differences are. So the first is polling or polling data. It's a little bit hard to say the difference there. But in this case, there is one system that is talking to DHS2. And in this example, there's no way for DHS2 to tell that system something just happened. So instead, the external system or the upstream LMIS needs to ask all the time, did something happen? No. Did something happen? No. Did something happen? Yes. And so the DHS2's way of communicating is in the response to a request from this external system. This can work. And this is actually oftentimes the simplest way to set up an integration project. But it's chatty, right? So a lot of times, the answer will be no, maybe. And so then you're sending a lot of requests, you're asking the question a lot, is there any new data? And the answer might be no most of the time. So in that case, it can be a little bit wasteful and a little bit untimely as well. Because if you're asking and you want to know when an event happens within a minute, you need to ask, is there a new event every minute? And so that can be quite a lot of information going back and forth. The alternative to this is pushing data. So this is hooks is one mechanism for doing this. But this basically lets the external system tell DHS2, tell me when my data is ready. So when an event happens, tell me. This is how you can find me. This is my address. So this is my phone number. Call me when something happens. And then you don't have to ask again, because you know that DHS2 will tell you when something has happened. And when that event happens, you receive a call and you know that information is available. And a lot of, this is kind of the callback approach, right? So sometimes you give someone a call, maybe give them a missed call, and then they know that they need to call you when something is ready or when something is available. And then you don't have to keep calling them every minute or every hour. They will call you when it's time. So that's another way to go about this. This is something that is not fully supported in DHS2 yet. So it should be coming in the next version in 240 to have a full-fledged webhook support, but it is supported in certain cases. So we do support notifications from programs and program stages to SMS and email, and also to webhooks. So that's something that we can do with programs, stage notifications, specifically something we added for COVID, but it will be even more supported in the future in DHS2 240. So what are some of the trade-offs between pulling data and pushing data? When you're pulling data, a lot of times it's more reliable, right? So you have to think about how you design this, but if you're asking, give me all of the events that happened in the last minute, and then you get a response, you know that that response should be complete. It should be all of the events that happened in the last minute. And maybe if you miss a minute, you say give me all of the events that happened in the last two minutes instead of the last one minute, and then the response should still be complete, and you should still get the entire list of all of the events. But it might be less timely because you might not want to ask every minute, maybe you're asking every hour every day instead. And so you won't necessarily get when an event happens, it might be 24 hours before you actually get that information when you ask for it. So that's a disadvantage or a trade-off that you have to think about when you're using a pull type of integration. The push type of information is a bit the opposite. So it's more timely, meaning that as soon as an event happens, the DHS2 can send a notification to the other system that it happened. That's a good thing. So you know that within a minute, maybe, of the event happening, it will be sent. But it might be less reliable. So if to use the telephone metaphor again, if I say, hey, give me a call when this is ready, and then you give me a call when that's ready, but I don't pick up the phone, I've missed that notification. And so then you need to call me back again later, or I need to call you and ask again kind of what is it ready yet. So it's less reliable if that notification gets missed, which is why we often recommend doing both. So this is kind of an integration pattern where you can get information pushed to you so that you get it as quickly as possible. But if you miss something, you have a mechanism to pull or to ask for all of that data and make sure that you have everything in the system so that the synchronization is guaranteed to happen eventually, even if one of the systems goes down or if the network fails or something like that. But there's some careful design that needs to happen to make this possible. Finally, and this is one that I'm not going to spend a lot of time on, there's a concept of a message queue where instead of sending a message and then pushing it to an external system immediately, you might put it into a place where you just have a queue or a line or a list of all of the messages that will need to get sent. And so then if the upstream system is down, the queue starts to get longer. And then when it comes back online or becomes available again, those messages start to get sent. So this is another maybe example of Brenno being my message queue for the questions that are coming in, because if I'm talking right now, so I can't answer any questions, but you can ask questions on Slack and Brenno is serving as that queue. So he's saying there's these 10 questions and I'll ask them in order when Austin's done talking. This is another pattern that you can use. You can implement this in the interoperability layer and there are some interoperability systems like Apache Camo and Open Function that do this for you. But it's an important thing to think about as well because it improves some of the reliability of the system as a whole. And the last pattern here that I think is important to talk about, and again, this is not really a technical concept, but it's important to think about having one source of truth for any specific type of information. So this might be that I know where to go to look up what the product code list is. And it might, there might be a copy of that product code list in every facility, but I know that the real one, the source of truth, the official one I can find by asking the upstream LMIS for that product list, for example. So when you're thinking about these interoperability projects or integration projects, it's important to think about where does that data, the canonical, the source data, the source of truth live. And then to refer back to that and make sure that you're synchronizing from that when you're designing these integration patterns. So now let's finally, we're wrapping up here. Let's get back to this example. So we had this example of receiving a package at a specific facility. I'm sorry, there weren't more examples here. It could have been more kind of contextualized. But in this case, we're seeing in practice, and you can, you can, I won't get into the details, but there's a kind of a workflow here where the health worker creates a package reception event in DHS2. Then there's a program notification web hook, which is pushing that data out to the upstream LMIS system. In this case, there's no middleware. So there's no interoperability layer, which means it makes this a point to point integration. So DHS2 sends that notification as a push to Medexus. And then also, every X hours or every day, the upstream LMIS system will ask DHS2 for all of the, all of the data that are all of the events that happened in the last X hours or last day. So this is both a push event, but if that push fails for whatever reason, if the upstream system is down or the network fails, then every day or every some number of hours, we can request and pull the data back from DHS2 and say, give me all of the events that happened in the last day. I want to make sure that I got them all. If I missed any, I'm going to update my system to reflect that. So we have both push for timeliness and pull for reliability here. And at the end of the day, after that pull has happened successfully, the information should be synchronized. So DHS2 and the upstream LMIS system should both know that this package was received at this particular facility. And that way we can keep that information in sync. And also important to point out that there are two different sources of truth here. And because they're a source of truth doesn't need to be the same source of truth for everything. It just needs to be the same source of truth for any specific thing. So in this case, the facility supply. So what the facility has on hand is kept in DHS2 because that's where the health worker is looking at the supply where they're for when they're trying to give someone a particular drug or updating it when they receive a package. But the packages, the actual resupply packages that are sent out from a central warehouse, that source of truth is the upstream system or mid-exus or the ELMIS. So there are two different sources of truth for different types of information. And the information is kind of duplicated between the two of them. But there's always one that is the most correct. And we know that that is the most correct for that specific type of information. So this was just an example of interoperability and integration systems. And some of the patterns that you might see and might need to think about things that you might need to think about when you're designing those systems with your technical teams. And maybe don't have time for questions, but I think that's about it. Thank you very much, Austin. That was really fantastic. A quick message to all of you. If this went over your heads, that's perfectly fine. A lot of it went over my head as well. I think the important thing is that this is a reference which we can go back to and refer to when we're actually working with the subject matter. It will be available on YouTube. And this is something that you can then refer to when you're working on the solution architecture. It's what we spent the most amount of time on, on the Medexus Mali case, which will be presented after the break now by Per Kronslev. So it's what we most spent time on was working out these workflows. How does the functional requirement align with the technical capacity, with the contextual then implementation of these servers and how that is actually functioning. So again, the expectation was not that you would understand everything in detail, but rather you would have an overall understanding and a reference place for when you're actually dealing with these issues. So I'll be somewhat strict with the time now. We're three minutes over. We'll take a break. We can come back three minutes past at the top of the hour, so in 15 minutes. And then we'll start with the presentation on Mali. I'm not sure if Austin will have time, but if so he can answer some questions either on Slack or part of the Q&A after Per's presentation. All right. So 15 minute break and then back with the Mali use case and Medexus ELMIS. Again, big thank you to Austin. Thanks, Rana. Yep. Happy to answer questions. Have a good one. Yep. So we started the recording. Thank you again, Alice. So Per will be presenting the Medexus ELMIS. So give a general overview of the system. Again, many people ask us which system do we choose and we say, you know, choose in here and every one of them. So we've invited Per and a few others to present. So this is part of that. And then he'll also present the Mali use case where we've integrated DHS2 and the Medexus ELMIS. And he'll go through that. And we can, of course, take more questions and explain some of the work and the decisions that were made there. It was myself, George McGuire, also Austin McGee and some others involved in that project. So I'll hand over to Per and we can take more questions at the end. And also don't hesitate to ask questions in the Slack channel. Over to you, Per. Okay. Thank you. So I've been asked by Brennan to present two things. First, the software in general, I'll use some slides. I'm not going to start going to the demonstration, but I'll use slides to explain what the software can do. And after that, I'll talk about the use case. And I'll leave some time after for questions. So I will try to keep this at maximum 25, 30 minutes or something like that. Yeah. Okay. So now I'll put the PowerPoint on. Yeah. There we go. I think this is going to work. Presentation mode would be good. Well, yeah, we see your screen now. Yeah, you don't see it in the presentation mode, I think. That should help. It's a presentation mode. Yeah, we got it. So okay. So first I'll go through what this software is and what it can do. And a little bit also about iPLas solutions. Yeah. And my name's there plus an email address. So my name is Pierre Kronzler. I am what they call a senior supply chain consultant. So I've been working in this world for quite a while in a number of countries. I think most countries in South Africa. Yes. So I'll go through the background, a little bit of the company, the designer indexes, equating all its features. So I'm talking about implementation, about dashboards, a little bit of a Brunner case study, and then we'll get to the Mali case study. So background. iPLas solution is a Dutch company, NGO. We are a major procurement agent for the Global Fund upstream. That means buying products for HV, malaria and TB and so on from a long range of countries. Downstream reduced in-country system strengthening. We work with Brunner, DRC, Mali, and Nigeria. We've got Training Park from the Academy. We work on raping and fading on data. And we have this ENRS component. Yes. So what's it about? What do we want to solve? We want to solve, we want to give this real-time visibility in the supply chain. The ability to see what's on stock, what's being delivered, what's being ordered step by step in the supply chain. And we are in 2022, and this is still actually a big issue in many countries because we've got the payroll-based systems, lots of places. This is what we want to solve with this software. So what is Midex? It's not that old. It was created around, started in like 2017. And the thinking has been to kind of start over, use the experience obtained over many years with various pieces of software with ways of doing things and create something simple and targeted the health facility and district level. So not, it's not starting from the top. It's not starting from the same purpose for going down. This is starting from the basis of how to manage a health facility, how to manage a district. That's where it starts from. And as I said, in 2017, it's cloud-based and it's Android-based. So it's made to be used on phones and of course can be used on a computer also. And it's thought as an end-to-end product, trying two means you can be able to track the products from the center medical store all the way to the health facility. It has various reporting capabilities and features. It's actually designed around also the vertical programs. That's another part of the thinking that was in it from day one. It must serve the managers of vertical programs, both at national level and at district level and so on and so forth. It's got these reporting capabilities. It's available as software, as a service, meaning that you can have it the way that it's all managed away from you. And it's simply a service you got. It's got multi-user interfaces. You can do some on smart phones and tablets and it's network agnostic. Now, it does not change right now. I do not actually understand. One moment. Okay, next one. So which kind of features does it go? Forecast and demand planning. So using the history to propose what's the forecasted demand in the future and give an idea of that and then you can, of course, work with it from there. It's got management of the expires and batch numbers, lots. You may choose if you want to do by FIFO, first expire first now, or by FIFO, first infos are. That's up to you. You can track and manage your batches in your expires. So your picking principles are up to you and this is all shown in dashboards. We also have what's called intelligent inventory management. What that means is, again, it's targeted these health facilities and the needs there. So we can track the programs and the donors. So if there's a given donor who wants to know what happened to the products which has been sponsored by this donor, then it's made for that and, of course, it's also made for that. If you want the malaria program to know what happens to everything they have, it can be filtered by that and be tracked down to the only malaria product. It can manage the observable stock, so how much is on creatine. And you can set inventory levels. That means that you will set it by program, you can set it by product, it's up to you. But what stock level is your target stock level? Do you want three months of stock and health facilities level? Do you want two months, five months? It all depends, of course, on the infrastructure and the challenges you have. But you set that level and then the software will help you calculate how much to replenish based on the stock level you've set. You can design your warehouses so you can have one or more warehouses at a given health facility or a district and then you can divide them by bins in the software if you wish to do so. Of course, the more you divide things, the more complicated it gets and that's not always a good idea, but the options there. You can set mechanisms for stock rationing, so you avoid to stock out or so you start rationing, giving you a two little product and system. So the most important feature is this real-time stock visibility. That obviously depends upon that everybody updates the system ongoing. But you can monitor the stock status and the system will also tell if you are approaching stock out. So it starts warning you when you have less than one stock left in your system, when you have two weeks stock left in the system at a given destination and warns you this is this destination and you're approaching to go stock out and therefore you should start doing something to replenish. There's mostly the pull or push for filling process. It's a choice you can have. I mean, so you can work with informed push, meaning that the system calculates how much to replenish, how much to ship to a health facility based on the stock level they should have. Or you can work with the pull system, where you let the health facility fill in an order form and then they ask for what they need from the district level or some level store. So next one. Yes, that's another feature. Co-chain management or management of co-chain equipment. Actually both. So you can set the volume, the physical volume of your freezers and fridges by each health facility in the system and then the system will not let you send more co-chain vaccines to that facility than there actually is freezer room for. So if you can use it to calculate your capacity needs, you can calculate I have so many cubic meter of freezer and fridge space and how much vaccine can I send through the system. You can also manage in it the equipment maintenance. That means that you will also register the age of the equipment, the type of the equipment, all that and the maintenance status. So you can manage that these and these piece of equipment need replacement. They get too old and you can hook the system up with the RTMDs, the remote temperature monitoring devices which is in the equipment. So Medexas will then tell that these and these specific freezers in that health facility is having frequent too much temperature preferences. So this is the co-chain features to monitor that. Now, transformment. So another thing, managing the transformer. Again this is a simple version because it's made for a facility level but also a health facility and district level. District level you often have distribution by milk so-called milk rounds by fixed routes. Or you can have that or you can also have of course routes which you improvise from time to time. But you can use this one to set routes by health facilities and then monitor that the transportation happens in this route. So you put the products on a truck tells it goes on this route. It goes out, the software knows and has gone out on the route and then when you get the proof of delivery back later you will then confirm yes I got the product actually reached the destination. On DHIS2, we're very happy that we've made, I think it was also mentioned in the earlier presentation and so on. But we make quite some effort to get integrated with DHIS2 and we are very keen on that. So we have a two-way integration meaning that we can get data from DHIS2, I'll get back to the implications of that, and we'll send data to DHIS2. So both ways and that has a number of advantages. One is of course that we should, any LMIS data should go, most countries to DHIS2 for national dashboards and surveillance. But there's also a lot of advantages in getting data from DHIS2 in terms of setting up solutions for the smaller health facilities. We can do budget and credit management meaning you can set budgets by health facility and then monitor that they only reach that budget when they buy from the district, for instance. So we have dashboards, some graphical user interfaces, so you can see a map of your country, region, what you need, and then comes out these little dots on what color they have. They're green, they're fine, red, they're not so fine. And you can of course regulate this, but in general it's of course obviously the red ones will basically go out of stock or overstocking, green ones adopt meter fine. So the various dashboards and then you can set the KPI's down here, stock art durations, percent of stock art, expiry rate, so on and so forth. The KVAS can be swapped depending on what you need, these are just common ones. More dashboards, stock levels can be set for a specific program, typically a value. Stock art analysis, stock art is a big issue of course, many places, so there's specific analysis for finding the places where they're stock art and then you can go, like this one shows here, you could go put your mouse on a given spot which has turned orange for instance and then you can see okay it's that product which is out of stock or going out of stock where this one's then close to be stock art. So you can, so this graphical user interface, you can find things and say okay here looks like it's a problem, what is the problem? You put the mouse on it, click on it and say oh it's that product, this program, so on. So it's a great thing on this stock art analysis. This is basically more of the same from Burundi stock art analysis, so there's some specific health facilities, I mean there are obviously many more health facilities but this is for the ones which has a problem and you can find these ones, do something about it, but the KPI is here to the right. Shipment calculation, yes it helps you set the milk balance, set the distribution pattern and monitor the shipments that things moved and that yeah that they have and that has been confirmation of the proof of delivery. Let's see batch recall, yes that can do too, you need to find out what happened to give batch, where did it end up and you can search on a specific package, specific shipment, various specific things throughout the software. Now let's say okay, here comes something, oh that was too big, sorry, yeah implementation. So if I keen on that this needs to be done with local help, ownership, so there are several things on this which are where we think are very important to emphasize. One is that we will have always a local software company involved in this as far as possible as well, so we get into it from the start but then we need when we leave it, it must be in the hands of local minister of health, local software people. This integration of DHIS2 gives us the opportunity to set up solutions at the lower level where we actually do not put our software out there necessarily but we can use interfaces with DHIS2 screens, DHIS2 user interface, which they very likely anyway already are in and this saves training, this saves money because one of the big issues around these LMS systems is to maintain them and to train people, that's why thousands of people and that's very costly. So if we can use this to have only the higher level using it, but lower level use DHIS2, that's a good thing. Fees, it's an ongoing issue and it's one of the big issues around the maintenance of these LMSs. So we've got two ways around this, one way is the traditional annual license fee but we also work with a one-off national professional license, meaning that you can get that paid, if that is paid under the project, under the implementation one-off and then that's it and from then on you do not pay for using it. So the next one, that was that on the DEXAS. Now I will switch to the presentation on the specific Mali case and then after that I think we should take some questions. This is great pair, we already have a few questions in the Slack channel but continue and we can take this up. Well maybe we should take those now then or what, what do you think? No I think you should go ahead with the presentation and we'll take them all at the end, I think that's best. Okay, your choice, let's see. Is it on the screen? Yeah, it's there now, right? Yeah, so you can see now right now it's on the screen? Yes, perfect, go ahead. So this looks a bit different but that's because it's, this project is a USAID project and there's a lot of formalities around this so there's also around the design of the PowerPoint. So now that's because we had a very concrete case where we have a part of a larger health project in Mali and in that context has been created a solution integrating deoxys and DHIs too. So that is what I would like to talk a little bit about now. So this is, it's a larger health project, it's called Kenya since it's in Mali and it is implemented by Palladium actually and we are a sub-component to this. So only one piece out of six important pieces there. Now the project itself, I will of course not begin to this but it's touching upon all sorts of aspects around the the management of the health system there for all these health facilities. It's specifically targeted health facilities and districts, that's the level. Now the objectives is to strengthen the management especially related to women and children in a number of ways including the supply chain and this one or the job, people who just have that, here comes it. Now let's start. So the big challenge we have is that we could say that these ELMA solutions, they're nothing new to them and they've been there for 15 years. We've seen them and it gets boring to tell the whole story but challenges are any solution has to work for thousands of health workers. These people have limited basic training and there's a staff turnover, many places 30% of the staff turns every year. So these solutions often work technically but they're complex for users. So this complexity demands training costs and training many people also because of the turnover. This is an issue and the ministers of health working on this, they don't have stable budgets for license fees either. So anything that demands an annual payment is a challenge. Now, so in Mali we worked on dealing with this. Yes, so therefore these ELMAs are costly to implement and costly to maintain. But like in Mali, DTIS-2 is operated at every health facility and we are there combining therefore the HMS and the ELMAs. And we have started this now and we hope to grow even further where we are now. Now, so the current situation in Mali which I actually think is close to the same as in DRC is that, well it's changing right now actually because we're implementing but then say a year ago the situation was that you had a fully paper-based flow of information, fully paper-based in terms of the products procurement. So paper-based ordering from health facility to the district level, paper-based ordering between the community health worker and the health facility and district also managed by and large on paper and then ordering on paper from city by bus. So that's all on paper, the product flow. But at the same time you got DTIS-2 implemented as an HMIS and you're having data being entered into screens, DTIS-2 screens every month gathered and shown in the national dashboard which in Mali is called OSP Santé. So that's the situation. Now, here comes the concept, what we're doing. So we want to use the existing DTIS-2 infrastructure to secure LMI status directly from health facilities. So we're going to take those screens they haven't anyway put in and then take that data and use that to work with the supply chain. And by that minimise the need for training. So we're going to pull data from DTIS-2 into the full EMS application indexes and generate orders for replenishment. So the architecture, well, I will not cover it, it will take far too long, but there are two steps in this. One, the most simple one is the health, the products which are for free, program commodities. There we get the data every month, it goes into Medexis and we are calculating this replenishment or a shipping data. Then there's a second step which is the products which are procured by the health facilities. Sorry, CSPLUM is a health facility in Mali. So that's obviously more complicated a bit because the health facility will buy the product, so there's a financial transaction involved, but that is also managing. Right now, we're implementing the phase one. And data will remain to go to the national dashboard. We're not touching the dashboard. It stays. Now, so the perspective, I know this is a business slide, but the perspective is that this update stays the same for short on paper between community health worker, health facility manager, things on paper, but they enter that data into DTIS-2 and that data is exchanged with Medexis. And then we can use that to calculate replenishment orders. So that's what we want to do. That's what we have set up now and are doing. Longer term, you can of course do more. Longer term, we can get the community health workers on mobile phones. So they get their data straight in. We do a number of things. This is also about development, about starting a process. But it's hopefully not something that's just like this and then it stays like this for the next 10 years. It's hopefully a path to a change. So, yeah, I know those were a bit too busy, but where are now? So we got the integration is there. We got the solution anchored with the local partners, local HISPs that's implementing. And they also maintain these things on the local server. And we got agreements with Minister of Health, local authorities, that's all in place. We passed this one. So we've done the pilot, we're rolling out now. Here comes something interesting to talk about. So one part is technically, figuring out programming, all that. Another one is the process and not to be underestimated. So here are some quotes on this, which I think I really learned, right? So it doesn't take that long to figure out a possible solution. As it says here, some months, but the dialogue to get moving takes more than a year. And I think that must be respected and must be done. Dialogue very important. And Minister of Health engagement is absolutely essential. And we, I guess, we are guilty, like other people also, to some extent. So we get very happy with this interesting solution. I work with the technical people and all that. But sometimes we forget to talk enough with the stakeholders. And that is an issue. And it must be made very important to keep these stakeholders, special needs of health, informed, engaged, so on and so forth, and use that energy. Working with the University of Oslo, Oslo has been essential for us, lots of good ideas, lots of nice work together, discussions, learnings. It's important to put together this technical concept before engaging the stakeholders. So these stakeholders can see in a few, but it's also important to keep them informed. And in the work process, I would say there is a risk that for technical people, they find it's more rewarding to spend energy on the technical solution compared to the organizational focus, the process part. But both things are very important. I think that's about it, Brenner. Let's see, yeah. Yeah, that's it. Questions? And so now I should get to the Slack channel. So I'll take down the presentation. Is that okay, Brenner? Yeah, that'll be great. Thank you so much, Per. Thank you for that input. So going over the Medexus ELMIS, the software, and then the Mali use case. So this was really great, I think, to share. There are quite a few questions already in the channel, and I can just ask them to you now when you can answer directly. But it would also be great if you can share with us the presentation so we can share with the participants that they can have access to that. And then you also have, you shared your contacts there. So just to share with the participants that you can reach out to Per, if you have also questions that we don't take up immediately here. But thanks again for sharing that. And we're still on this journey with Mali and the integration, but things are going well. And I think it's the showing the fruits of this collaboration. If I quickly go to some questions here directly to you and for Medexus ELMIS first pair, there's one from Gerald Thomas saying, our major problem with most of these technologies is internet connectivity. And I didn't see anything on Medexus talking about data capture through SMS channel. If you can say something about that. Yeah, okay. So yes, can choose an issue. But we have one answer, which is that the application can work offline. But obviously not a long time. That means that the way we've set this up now is that you can work with it on your mobile phone offline, but at some stage you need to get online. So we have not set this up for now to work through simple SMS capture. I know what you mean. But for now, you set this up so you can use your mobile phone offline. Then you can, which is many places, then you go somewhere and then you update, then it hooks up and update once a week or when you're able to. So that's what we can do now in that context. But yes, it's a great issue. I think though it should be mentioned, I think in that context, that we must remember that if you're talking about the management of the product flow of products here, if you're having like, if you capture a good deal of the sites, all the ones in the cities, you're having a very large part of the product flow. So I'm not saying the remote ones are not important, but I'm saying that even if you have all the ones where you can capture the information, you're having a very large control of the product flow. So anyway, yeah, can you take this one? I can take the next question while I do that. I'm just showing the word of the day on the screen. Can anybody, can everybody see that? Yes, it's there. All right. So the word of the day is canteen. I know that's probably been the most asked question so far today. So there you have it. But the other question, Pair, I think it's more, it's a broader question. And I think it's very important. And I gave quite a long answer in the Slack channel. So then I'll give it to you, but I can comment on it afterwards as well. But the question was from Alex Watila asking, some of the features for facility are overlapping between what Madexis can do and what DHS2 can do. What can we say to that? So I posted a long answer, a long reply, which I can comment on as well here. But I wanted to just have your thoughts here as well, as you did share some of these aspects in your presentation. Okay. Well, I'll say first of all, when you do that, actually implementations, you have to of course, watch out. I mean, you don't want to give the users double work. That's the last thing you want to do. Don't do that. So what you do is you would take care that a given data only is put in into one of the applications. And if you have an integration of DHS2, well, you might as well get it from DHS2. You definitely don't want the users to experience that they have to put the same data in two places. That would not be good. But that is fixable. I think that can be worked on. I don't know what, maybe what's your comment to the same? I had quite a few points. And I think it goes back to one of our first discussions we had, Per. Now this relates to the initial assessment. And for Mali specifically then, the data that you were looking to access, the stock data from facilities was already being entered in DHS2. The facilities and devices, users were already set up and using the system. The entire implementation, infrastructure, human capacity support was already in place. So the idea of implementing the Medexa system at a level, collecting the same data, which was already digitized and readily available, was already present. So I think that was one of the starting points that I think we had when discussing Mali is, again, back to your first point here, there's no need to develop then a parallel system with a parallel app, maybe device structure to collect the data that's already available there. So I think that was one of the key starting points in the assessment phase is to see what is the value added of using Medexa's ELMIS at facility level versus integrating with the data already being collected by DHS2. I think that was the key starting point. There's a few other things we can also elaborate on and discuss further, but I think that was the main aspect to consider. Another point that I also mentioned is that if it is a better solution, if given the requirements that the country has for their solution that implementing the ELMIS or ERP down to facility, both in terms of cost and sustainability, functionality and so on. If it is best suited to have that end-to-end solution, I mean by all means we support that. We're not by any means promoting this as the only option. We're trying to promote a solution that is implementable, realistic, sustainable, cost-effective. So there are all these advantages again that I mentioned in the beginning in the overview presentation where we look to maximize the use of DHS2, the existing implementations of DHS2, looking for these synergies to use a buzzword, and then how can we add to this ELMIS landscape? We're not proposing this as the only solution. I'll stop there. I think George, if I saw you, maybe had a comment for this as well. Maybe I lost George. Maybe he's muted. So yeah, it's a unique opportunity. Maybe George, are you there? Yeah, I think while we wait for George's comment, we can maybe move on to the next question or he can also reply on Slack. A specific indexes question then, Per, if an entity wishes to install Medexus on a server premise rather than in the cloud, is it possible? Yes, it's possible. We know that the ministers of health of various countries, they prefer often to have it on their own machine or their own server. We would, though, say that it's more manageable and easier to maintain if it can stay in the cloud. But yes, it's an option. But there's a number of good reasons actually for having it in the cloud. It is easier, substantially easier to maintain this whole thing around management and backup and all sorts of things, which are big advantages if it can stay in the cloud. But yes, you can have it on the whole server. It's possible. So we've got George back. Yeah, he's got his hand up. Yeah, thank you. Can you hear me now? Yes, we hear you George. Okay, apparently you have to be unmuted by the host every time. I just wanted to comment on the question about duplicating of data, which is very close to my heart. My clear advice on that is to avoid any duplication of data. So typically we see that despite Medex is keeping an exact record at the batch level of all the stock that is sent, the consignment sent from a warehouse to a facility that people are spending a lot of time recording the stock receipts at the facility level. So my advice is clearly, and that's our philosophy, core component of our philosophy is to at the facility level, to collect only the data that is available only at the facility level. And that is the stock on hand. And that is the monthly demand or the consumption, because that is not available in Medex or in any ERP system. But everything else like the stock that received or the request, everything else are clear recommendation. As you have seen Medex is a sophisticated ELMS system that is made for logistics. Keep it there. And this is by the way also a recommendation for the analytics. You can have some very simple dashboards that show tomorrow directly from the stock on hand from the consumption data in DHIS2. But anything else we recommend build the dashboard or use a dashboard in Medex and we are looking into ways of like maybe pushing scheduled reports to DHIS2. But this is a very, really an excellent point. We really are very keen on trying to duplicate any data. We really want to help workers to focus on providing services and collecting only the essential data that is otherwise not available. Thank you. Okay. All right. Thanks for that, George. I think that's also related to a point that we had another question from it was Gia Kani. I also sent a extensive, a long reply in the channel. Why we should not use DHIS2 for end-to-end supply chain management? Why do we need an LMIS at all? I think George touched on a few of those points there. We're focusing on this facility level and then relying on a dedicated supply chain management LMIS system to do all of this more extensive management of the supply. We're really looking to capture essential data at consumption level and not overstressing the DHIS2 system with features that it's not built or capable to manage. And I have some of those listed and we'll get into those also throughout the week. I think, I guess, in that context, what we mentioned is that there's several connections that people have done quite a lot to try to build things around DHIS2 to do this job because DHIS2 is out there. But I think it's been a general experience that it's not made for those transactional things. It's a data-catholic tool, right? So that's, yeah, it just doesn't have exactly that. Whereas you have a tool that's made for transactional work for the supply chain, it can do some other things. So integration is simply probably a better solution somehow. All right, I have another two questions for you, Per here. Maybe short answer. One of them is minimum requirements for the Medexus application and device compatibility. Mineral requirements, okay. So it's built for really low resource setting. So you can run it on an Android phone, quite totally normal Android phone. No problem. We'll do that. Of course, it's what we call the Medexus Lite version. There are limits. It's nothing else by the screen and by the data you want to move, but you can run it on an Android phone, the one used every day by millions of people. So that's, you can say that's a mineral requirement. There's certainly advanced stuff, if you need that, then you actually have to have a good functioning laptop. But it's a choice both ways goes. You said the other question was? You're on my mind, yeah. George has a comment, but let me just ask a quick follow-up. Does it also support bring your own device or do you need to have a device managed by the organization or agency? No, you bring your own device, yeah. You hear, you snap, yeah. That was another question. Over to you, George. You have another comment. Yes, thank you. I just wanted to briefly comment on the question why DHIS2 at a strategic level decided not to build another end-to-end ELMS. And there are several reasons. So one was already indicated or implied. DHIS2 has very specific data model, and it's not built for logistics management information system. It's built as an HMIS system. And we don't have time for details, but it's not really adapted to an LMIS. The second reason is we would just be reinventing the wheel. There's already excellent systems like M-Supply, Medexys, others that are recommended. Brenno has presented the guideline. And the third reason is personally I have worked in Excel. I have worked in an organization spending five years and developing a bespoke system from the scratch. It's going to take five years realistically. Huge amount of money and developers. You will need a whole team. So why should the University of Oslo, the HIST Center, invest in that where there's already several tools? And maybe the last point, I think Priya mentioned that people have already tried to develop a DHIS2 to make an LMS out of it. I think that the complexity of an LMS is totally underestimated. People think it is easy. It is easy just to report stuff, but it actually it's really complicated and it would take a huge, huge effort. So we definitely not going to go there. Thank you. Great. Thanks a lot for that, George. I think a lot of those comments, as he said, some of it was implied in the first two presentations both by Mike and myself on the DHIS2 landscape and the LMS overview. I've included quite a few of those in the Slack channel, but feel free to come with these questions again. I think understanding the general approach that we're trying to build something that adds to the landscape, adds to an existing gap, doesn't overlap with other solutions and can be implemented and sustainable. If you're simply checking off and ticking off the box of features, stock reporting at facility, short DHIS2 LMS and all of the different tools will check that box. But again, we're looking to add to a real-world implementation scenario. And I think the Mali example is a good example of that as Para has shown. And the discussion that we went into is how can this adapt to this existing context? They're already collecting data in DHIS2. The data is there. What is the need to implement a parallel solution to collect something that requires this integration? So it's the question of, again, level of effort for the value added to the supply chain system. All right. I think this is good. I don't see any new questions for Medexas specifically. I don't know, Per, if you have any final words or comments, or else I can just give a few final words before we end the session. We just have nine minutes to go or so. No, I just want to thank you for the opportunity. And then I'll ask you a question. So I send you the PowerPoint of what I do. I put it on the Slack, what I do. Yeah, you can share with me by email or Slack, and we'll upload it to the Share Drive. I'll show you a link to the Share Drive as well so you have access to all of the different resources. And I think all of the participants you should already have access to that. If you haven't seen it, we have the link in Slack as well. Okay. I wanted to also say that I think it's really great you're having so many participants. And I think there's so much opportunity, so much opportunity in getting these ELMS out there because just the pure value of the products going down those supply chains is very large. And that this is today still not quite under control. It's not good. And there's a huge potential in bringing this in savings, in the savings lives, and there's a lot to get there. So, yeah. Thank you for the initiative. Okay. Big thank you to Per. Thank you for the contributions. And we're looking forward. You're more than welcome to join with the other sessions as well. And we'll have this expert lounge open Q&A after the full day tomorrow. So, you're also welcome to join that and then people can connect bilaterally during that session. So, just to end for the day, a quick recap. We have this presentation on the HMIS and HIS landscape, so the information management landscape in a country where you have the health information and now the logistics data and how that can come together for triangulation for improving both supply chain management and health program management. With DHS2, you have an existing system that's been implemented at scale in up to 69 countries. And you have that references for that on the website of where it's been used. And then you already have it being used in many different ways to capture stock data. But then what George and I have really pushed is for using DHS2 in a best case or a best practice way that will support this integration that will maximize the existing DHS2 implementations, does not overuse the system or over stress what it's able to deliver, but rather fills a gap which is really digitizing last mile data. So, the first data mile at facility level. So, that's really the intention here is that we provide a solution that adds to the existing landscape in a very practical way. I think it's really, we push for this integration approach and there's a lot of implications and things to consider. It can be complex, but I think we have a good understanding from the start what the objectives are and we have this engagement from the technical teams on what can be achieved, aligning the workflows with the data flows and aligning the different stakeholders. There's a lot that can be gained. The presentation from pair, I think highlighted that in Mali and we have a few other examples that we can also point to. Where tomorrow we'll go more into the pure LMIS stock management in DHS2. So, the day will be dedicated really to that. Stock reporting, George McGuire will be leading those sessions providing both a demo and configuration of these different tools using DHS2. You can already go into the sandbox as I've already mentioned and test some of these things out. Try to use it with your mobile device if possible and that will really give you an idea of how it is to be in a facility and using this tool for stock data capture at that level. And then at the end of the day we'll have MSupply presenting their solution, their central LMIS tool and what their features include and implementation or integration example as well with DHS2. So, we'll be looking forward to that. And then at the end of the day, as I mentioned, we'll have a longer expert lounge where you can come with your questions, use case, and we'll give some extra time to engage with each of you. One last maybe comment, a general comment to the group. It's been really great to see so many people participating and connected. It's a partly diverse group. So, either you have from what we saw from the registrations, more of an LMIS supply team background and then you're maybe new to DHS2 or you have more of a DHS2 background. You've been working with some stock data but then this whole LMIS thing is partly new. So, we're trying to cater to both groups. You may fall out of these two groups. We're trying to cater to either the LMIS or DHS2. So, one or another topic may be a bit boring to you when we're repeating things that are part of your area of expertise. But bear with us. We're trying to make sure that there's a global and holistic understanding from all of these groups on how these features can be best implemented to support the LMIS landscape and the information management landscape in your contexts. All right. So, without any more delays, I just want to thank everybody for participating. Thank you for today and welcome back tomorrow at 10 a.m. when we continue on day two of this DHS2 LMIS Academy. If anybody wants to stay connected beyond this time, George and I are available and maybe a few others should take some more questions. So, stay connected and ask me questions.