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.  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 integratio