 So welcome to yet another session about interoperability. This one is really, really easy for me because all we did was collect abstracts in our abstract collection process and we're going to let them just do the talking. The donkey picture is not relevant, I just like it. So my name is Bob for those who haven't met me. We have, just click on it, right, we've got a fairly packed program, we've got six presenters, three of them are remote, the first three, but in the last three should be here, I hope by the end they should be here. Yeah, we have Comfort, we have Dung, I've seen Dung somewhere. Vincent, are you with us? We have Vincent, all right, so we're all good. So we're going to start off doing the first three remotely. We hope it goes well. If there's technical problems, if somebody's mic is not working or something like that, we'll probably just shift to the next one and let them come back. So yeah, welcome everybody and particularly welcome to the six presenters. I think without further ado, we're going to kick off, we'll do the first three, see how much time we have for questions, and then do the next three. So Mr. Mpatzi from Lesotho, I'm going to stop sharing and that should allow you to come in. All right, thank you. All right, thank you so much. Am I audible? Can you hear me? Yes, we can. Okay, thank you so much. Thank you for the opportunity for having us. So good afternoon, ladies and gentlemen, my name is Le Badrum Patzi. I'm from Lesotho, a very small mountain kingdom that is completely surrounded by South Africa, and I work as a computer engineering lecturer at the National University of Lesotho, and as I'm... Hello, Mr. Mpatzi. Hello? We are not seeing your screen right. Oh, the screen is not... We hear you though, right? The audio is working. Okay, let me try again. And we can see the screen on the zoom. Oh, we have it. We're perfect. Okay, please carry on. Sorry about that. Okay, thank you so much. So yeah, I was just introducing myself, and I'm here with my colleague from the National University of Lesotho, Mr. Hobata Stedemela. And we are actually working on a project for strengthening health information systems, which is actually funded by PEPFAR at iCAP Lesotho. So we are going to share our recent efforts and successes towards building a flexible and easy to use DHIS2 integration solution for Lesotho's HMIS ecosystem. So here we have an outline that actually shows the roadmap for my presentation. I'll first start off with the background, then talk about related works or solutions in the space of DHIS2 integration, proceed to talk about our design or the design of the customizations that we have proposed, talk about the implementation, testing, conclusion, and then talk about recommendations for the future. All right. So firstly, let's talk about briefly about the little background. So the Lesotho's Health Management Information Management System ecosystem currently covers 90% of health facilities nationally and is currently mainly used to manage HIV and TB programs. So in terms of data flow, patient transactional data is captured from two main point-of-care systems, which at the moment actually open MRS as well as the pharmacy system, which has been implemented using ORDO. And all of those systems or those two systems or those two point-of-care systems are actually accessible via the BAMNI interface. And of course, this information that is captured, be it clinical or at the pharmacy side, is actually captured at facility level and is routinely pushed to the DHIS2-based national data warehouse in aggregate format. And when it's on DHIS platform, then it is used for analytics purposes. So the two currently supported point-of-care systems, as I've already explained, actually dockerized as shown over here. And we are, of course, planning to have other point-of-care systems, for example, to digitize the lab component within the facility, which is going to be implemented using open LIS, as we hope. So yeah, a brief background. Now coming to the gap or the problem that we currently are facing with our ecosystem. To be specific, for us to push information from the point-of-care systems that I've already tried to explain at facility level to our data warehouse, which is implemented using DHIS2, we mainly use the open MRS DHIS connector module. And, of course, we also have another solution that we have adopted, which is the BAMNI DHIS2 integration app. And the main reason for that is because of the shortcomings of the DHIS2 connector module that I'll explain as I proceed with the presentation. But before I move on to that, maybe I should allude to the fact that the DHIS connector module is actually acquired a rich solution that is able to easily aggregate or actually integrate the point-of-care systems that we have, for example, the open MRS to DHIS2 so that we can easily submit scheduled reports in a flexible manner to the DHIS2 data warehouse. However, the DHIS2 connector module is actually tightly coupled to open MRS and it cannot be used, or it's quite difficult for us to use it to map data from other point-of-care systems. As an example, the pharmacy system that I said we've implemented using the portal, we have actually hit a wall in trying to achieve that, which actually led us to look at the BAMNI DHIS2 integration app, which is another solution, which is quite flexible and supports easy mapping of data from multiple different point-of-care systems. But then, however, it's still not yet mature and lacks some essential functionality. For example, automated submission of scheduled reports is a problem on that side, in the sense that submission of reports when using the BAMNI DHIS2 integration app, it requires manual intervention. In other words, the user actually has to log on to the BAMNI system and then click a button to actually submit the information, which is quite not practical for the production system that we have comprising of over 100 facilities. Thus, our approach was to enhance the BAMNI DHIS2 integration app to achieve a flexible and easy to use to integration solution for our HMIS context. Now, coming to the aid and objectives of our solution, the overarching aim of the project was to improve the DHIS2 integration app such that it can be able to flexibly allow us to submit information from multiple point-of-care systems to our data warehouse, which is implemented on DHIS2. Now moving on to the objectives. We have a number of objectives listed out here. Then I'll move on to the system requirements. So on this slide, we have a number of requirements that we thought are quite important for us to look at in order to implement or address the problem at hand. We have functional requirements as well as non-functional requirements. On the functional requirements side, we have the fact that we need to manage automation configurations for scheduled mapping of BAMNI reports to DHIS2 for various point-of-care systems, manage scheduled mapping of BAMNI reports to DHIS2, and also manage log reports for scheduled mapping of BAMNI reports to DHIS2. Whereas on the non-functional side, we have usability. The system needs to be usable enough for the users to find it easy to use the system. We also have security on the non-functional part as well as extensibility and the fact that we need the solution to be performant. Now coming to related works or solutions that actually do or partly do what it is that we want to achieve, which is pushing information from our point-of-care systems to the data warehouse. We have the DHIS2 connector module that I've already tried to cover briefly in the previous slides. As I've already mentioned, the main weakness of the DHIS2 connector module, according to our context, is that it's quite challenging to pose reports from other point-of-care systems that we have. As I said, currently, we have a point-of-care system that we are able to use the DHIS2 connector module with, which is the pharmacy module which has been implemented on Odo. Since in the future, we're looking at prospects of also having a lab information system, which will be implemented using open elix, it means we're still going to have a problem. Even though I have to allude to the fact that it's quite a mature application that is able to map a report for open MRIs very, very well onto the DHIS2. A minute. Oh, sorry. All right, so yeah, okay. Other than that, we have the DHIS2 integration app, which I said we are willing to modify to address the problem that we have. I guess I should also co-pass that and come to our design. Now, on the design of our solution, the main component that we have contributed is actually the Shehira Jimon onto the existing BAMNI DHIS2 integration app as shown in the proposal system architecture diagram. Whose main function is to automate the mapping of BAMNI reports, which would be either open MRIs, pharmacy, you know, the lab information system to DHIS2 accordingly, according to the user refined schedules. So several additional web application and web service and database enhancements have also be done in order to support the functionality that is required. Now, coming to the user interface, this is the user interface that we have proposed, that we hope will be quite user-friendly to our users. And of course, we have a number of tabs. As you can see over here, we can monthly, quarterly to support different periods that can be scheduled. We also come into the data model. These are the tables that we have proposed in order to support the functionality that we require. And moving on to the scheduling demo, which is the main contribution that we have done, this scheduling demo, all it does is to simply, you know, check according to the defined schedules that the user will have defined that I want a certain report to be submitted, say weekly or monthly or quarterly or yearly, and it will simply check if the report is due. If the report is due, it will simply push it onto the DHIS2 instance that we currently have as the data warehouse. Now, coming to the implementation, we actually made use of Scrum because it enabled us to be agile and also adapt throughout the lifecycle of the software development. Now, coming to the tools, on the tools, we actually made use of a number of tools, but I would like to make a special reference to particularly the DHIS2 web API, which we found to be quite useful, that we actually make use of for us to post the data that we wish to push onto the DHIS2 instance, which is actually encoded within a JSON payload, a Scrum over here, and the endpoint that we actually made use of is Scrum over there, that it's the... As you said, I think we're going to have to stop you there. It's great to see the way the DHIS2 connector modules from OpenMRS have developed over the years. I think people should be able to get hold of the presentation and go more into the detail, but at this point I think we need to move on because we've got three to fit in in the next four or two minutes. Thank you. Tuzo, are you with us? Yes, yes. I can hear you and I'm all set. Very good, Tuzo. You don't really have 10 minutes. Okay. Thank you very much. Let me know if you can see my screen. Good afternoon. Once again, my name is Tuzo. I'm actually working with this Tanzania as a senior information system advice. I will be taking you to the story of how we managed it to integrate Tanzaniaization registry, which is an economic and quality team with the DHIS2 that has been used for quite some time. In my presentation, I will be going through these four steps, the introduction, the methodology that we have used, but the result that has come up on the interoperability of these two systems, but as well as the conclusion of the way forward and where we are heading. Introduction, actually, we have this immunization information system that was digitized to actually collect information, but which is timely and it's actually being read by the program of the IBD. But before then, we have this, what we call Tua, Tua tools, that actually the register that each month need to be submitted in the DHIS2, which actually collected the same information about being in the aggregate home. But also we have another system called VIMS that actually pioneered the chain of the vaccination at the program, which actually where this immunization officer from district they can request the vaccine using that system, but also at the end provide data in the summary form in the aggregate home. So the challenge that was we have this parallelism of the system, where you can see that the same officer, health worker officer has to do in the both of the three systems, has actually register in the Tua tools that is currently used to feed in the DHIS2, but also has to use the team for registering individual children that has came to the facet to be immunized, but also use the VIMS the system for ordering and requesting the vaccination commodity to the particular facet. So that was kind of a burden to that healthy worker. So the only goal was to actually make sure that we integrate those three systems where the team actually had to communicate with the vaccine information system to kind of know the stock status of a given facility. And also that immunization registry has to vaccinate or has to record all the information of the children that has been vaccinated. And then at the end it has to feed the aggregate information to the DHS. So as you can see the structure here we have the data flow, the way how it is flowing from the VIMS and then it to the team and the way how team actually communicate with the VIMS to know the stock status before even the session of vaccinating the children has not started. But also at the end in order to use the burden to the health worker who is actually doing all of that, we needed to get the aggregate information pushed to the DHIS2. So we piloted or we did this for the two regions which is actually found in Tanzania, Mainland, which is in Moaz and the Key Manager for them to go paperless so that they don't actually use the register again to feed those into our tools which later has to feed data into the into the DHS2. So after integrating we actually used the available API of the DHS2 to make sure that the data has to come from the from the team to the DHS2 at the end of the end of the month. So with that being done as you can see the DHS2 now with the its capability of analytical tools the data manager or the manager at the level of decision makers they can use the DHS2 together with the other information that already existing in the DHS2 to make a kind of report that can help them in their in decision. So the success part of each of the result was that we have first we have reduced the burden of the health workers to make sure that they don't feel the pepper and then let aggregate or summarize them to the DHS2 but also we have reduced of instead of having many systems that the health worker has to interact with they can just interact with the only one team with the registration system and then at the end of those information will be pushed into the to the DHS2 and then which makes those decision makers be able to get the data on time since the system the system will be kind of communicating. So that's what has been done but as I said this has been piloted for for two for two regions which is actually doing good and as of now the plan that is there in that we need to scale up to the rest of the region we have actually 26 regions and so and they have piloted for these two regions so the main work is to make sure that we scale up this initiative to the rest of the the rest of the of the region. So another thing is that we are capacitating the user to make sure that even the health workers they just not only use the team but also they can use the DHS2 in identifying or checking the gates of the data that has been submitted between the two systems but also can help them in the planning or in making the monthly planning or quarterly planning when they are planning for the for for for for surfacing for a service delivered at the facility. So actually this is actually going to to make sure that our health workers they actually be able to interact with the DHS2 to get the analytical data of what they have been captured using their immunization registry. Yeah thank you that's it and welcome for the question. Thanks very much Tuzo and good to see you highlighting the the the role of this interoperability to improve the the work of health workers which is what it's about. Tuzo we said we're going to collect questions at the end of the three online presentations so if you don't mind sharing at this point we get Mahmoudal to come in. Yes I'm here Mahmoud. Hello Mahmoud welcome you can share your screen and go. Okay thank you let me try to share and then let me know whether you can see my screen. Share. Do you see a PowerPoint? Okay great good afternoon good morning and good evening to our participants you know slow and in the Zoom meetings. So I'm going to introduce I'm going to share with all of you the our interoperability experience how we improve the the performance of the interoperability in Democratic Republic of Congo. So I am the managing director of softworks we worked in this in this project. So only a brief about my company we were established in 2007 in Bangladesh we have around 22 staff majority of work as you have seen we have been working in the health sector for quite some time and in the DHIs to platform we have been working for more than five years in Burkina Faso, Benin, Botswana DRC and Mali. So these I mean this map shows the areas where our information systems have been implemented in and I will only focus on the at the DRC work as of today as of this discussion. So I'm moving to the next one so the it's about interoperability so it's about interoperability of DHIs too with an external logistics management information system which is called Informad RDC which is used in DRC as you all have understood now. So the system was developed using USAID funding and under a project which is the Global Health Supply Chain project the Francophone Task Order and my company Softworks worked to develop the thing. So what Informad do is the entry form the data entry formats of LMIS and some patient reporting is in DHIs too. So what Informad does is it periodically collects those data and then there are some other data collection points in Informad then all of this data are used for different visualizations and dashboards like that. Little brief timeline of how it is developed we developed the system in 2000 at the end of 2018 and it was launched from mid 2019 and the patient reports came a little later I mean importing of patient reports in fact then there were admin trainings and national rollout trainings like that and then it is still being maintained until September 2022 under our support services. Very quickly on how data is transferred if I can take the little pointer a little so the facilities who are very far actually not in the so at the lowest level they submit paper reports to the districts you can say these are districts then the district staff they have computers so they enter the data in DHIs too the monthly LMIS reports there are you know district warehouses and there are the central warehouse regional warehouses they also enter data directly to the DHIs too of their LMIS report and there are other sources of data as well so all of these data are periodically sent to that Informad platform where data visualization happens so this is a typical view of the LMIS data entry page for health facilities in DHIs too so it has the I mean some fields related to the stock management as you see the opening balance receive issue dispensing like that then there is this is a view of a typical national dashboard in Informad sorry okay now let's come to the main focus about our interoperability experience so initially to transfer data from the DHIs to to the Informad platform we were using the data value sets API and we were using the JSON endpoint because it is easy and it's I mean easy to manage and then it's my field names are there and easy to handle like that just to give you an understanding of the of the numbers so in DRC DHIs too there is more than 20,000 health facilities and in the LMIS entry form there are actually 114 products if we represent it in DHIs two terms its elements and category combinations so there are 1596 of that and some patient category combinations 68 we do also need for some reports so the maximum data points for a specific month can reach it will not reach to that definitely it has not reached but it can be 33 million data points that can transfer from DHIs to to Informad so this is a typical view of how the the JSON data looks so what we found that this is too much data when I said too much data means the volume of data every hour was so much that we had to improve so the first improvement what we did we transferred from JSON to CSV the data value sets API we said okay we do not want to do it using JSON let's do it with CSV as an example this is a case of example of all data that came to me and you can see the chart on the right side actually by date so you can see here that on the 10th of May on that day maximum hourly data it's I mean one hours of data 491 megabytes data was transferred only at one hour and it had 4.76 million data values and the total data that came was 4.58 gigabytes so you understand so when we move to CSV we reduce the data burden to 62 percent but that was not still enough because of the data that was coming in so then we had to do a second improvement so what we did was in our software terms we call it queue management system means we do not just execute the software we have to do some management of it you know as a as a bank queue as we go to the bank there are queue and then the teller serves us sequentially right like that so from DHS to we get the data in CSV but then we do not run or execute every data point we transform that data point so this is the typical data that is coming in from the DHS to so we read that in the software and then we change it to SQL commands because the other system it is based on I mean I mean SQL database so we transform this data to SQL commands so that number of number of executions are reduced then I tried to simplify this this is the simplest I can make so okay then we hand it over to this queue manager what it does is we have different types of data right we have the lmr's data from health facilities we have data from warehouses we have patient data so in the rabbit mq as they call the queue management system it has different queues means like a bank's queue so we hand over data to these queues sequentially so it goes in every queue data is coming in and it's as in coronas then what happens is there are consumer processes that runs parallely and then they take the the first one from this queue and executes and pushes the data into the informant so all these five in a way in simplest terms they execute the things parallely without putting burden on the system CPU as like you know previously there were millions of points coming through but they take one by one after the first one executes it goes there then it takes the second one until it doesn't finish it doesn't take the second one so the the the load on the server is always maintained it will never go up to like you know millions of data and the server box down it it doesn't happen in this scenario so this is how we managed to you know release the server's resources in terms of millions of data as it comes through we pass it through the rabbit mq manage queue management process and then it has improved our system so this is just a typical view of where you can come and say okay how many how many data point is there now under processing like that and then some challenges so the the I mean when you want to get data from an external system to from DHS to to an external system you definitely need to map the facilities and you also need to map the element category combinations with the products in an external system we did that the keeping sync of the facility catalog sometimes is a challenge because of the of the number of facilities as you understand there are a lot of facilities coming in every month and going out stopping like that sometimes the sync stops that creates issues and you have to check whether the rabbit mq process has stopped or not then the queue we had to we had to use sequential blocking queue so that if there is an issue we can stop and give an error and email is automatically sent to the administrator like that there are some issues with the CSV files like the the CSV file from DHS to is not fixed column it has varying number of columns we had to handle that and if there are remarks in the data set then it's sometimes break the CSV also had to handle that so that's from my side later I guess we can take some questions so as I went I guess a little too fast okay thank you Mando as you are perfect thanks thanks very very much for sticking to the time I know it's really tight it's really nice to see a presentation about performance because often it's when you do interactability that you realize things work a bit faster than when people are clicking on the user interface and we've got five minutes which is not a lot of time anybody quickly want to address something comment something to one of the speakers do we so what do we need to do so do something with the mics will you run the stairs or you want me to run the stairs up the top it's Claude she's switching me off Hi so I have a question actually about the data volume so originally it was in Jason yeah and then you changed this to CSV because the Jason was taking up too much bandwidth too much I think space in memory but I don't know I mean would have pagination solved that problem or I'm or was there another reason why Jason wasn't suited yeah okay can I answer that now just a moment yeah sure so it's not about pagination you see it's every hour we need all the data that had been entered into the dhs2 platform on those data sets yeah if we do it using pagination then we had to keep the process running like you know every 100 records and then we get the next page we execute get the next page rather than that I mean sometimes we found that it overlaps with the next hour thing because there is too much data as you have seen like there are sometimes millions of data points so even if you take 100 it would be 20 000 iterations executing it and then taking the next page so overlap happened initially that's why we had to reduce the load of the data volume which has transferred we take the total data and then as I said we convert it to a to number of uh I mean SQL commands which are less for that good thanks man I think there's a lot of technical detail okay probably could dig more into uh but I just want to see is there any question or remark somebody wants to make about one of the other two presentations if not we come back and interrogate you more Tuzo with his immunization register and the dhs2 connector module well otherwise I think uh thank the the three presenters who come in from outside it's always a bit awkward um I hope you didn't feel too far away from us we give you a warm hand for the three of and let's move to who we have here Vincent I think you're on I'll see if I can get your presentation off Mike is on thanks visit all right good afternoon good afternoon seems like we are we are too full huh yeah so my name is Vincent Minde I'm a lead software developer at the University of Islam dhs2 lab in Tanzania and I will be presenting a case for eye care you see eye care or integrated care yeah it's basically a hospital management information system that we developed at the University of Islam now I have 10 minutes so I'm going to move around a little bit fast and here I just wanted to give a little bit of history on how we're involved in a lot in the process of you know implementing some of the hospital systems in Tanzania or EMR systems in Tanzania so we're involved in some of the systems in design as the University of Islam we're involved in deployment of some other system called after care which was based in balmy and things like that we also managed to deploy a laboratory module on top of basically laboratory system on top of open mrs or on top of balmy for those who know balmy yeah and during all of that deployment there were a lot of challenges uh truth is we can't go through them all right now but I'll just mention a few uh one was the uh well there were challenges but there were motivations to us by the way we're innovation we're an innovation uh lab so we like to innovate so there are sort of motivations in a way number one was dhs2 integration most of the mr's that were being created really didn't have any integration to dhs2 and one problem we face is that after any mr has been implemented let's say in a facility then they you start realizing that they are not very much frequent in reporting data into dhs2 so that was a very big problem like somebody would just ask okay we really have this system why do we need to go into dhs2 again why don't they just you know talk to each other and things like that and this actually has been a very big problem in tanzania to a point even a ministry member once mentioned maybe in three years people may not be using dhs2 anyway so to us it was a motivation to change things uh of course there were other uh challenges uh you know deployment issues architecture issues called fragmentation user experience all of that i don't want to get so much into that that could be a session of its own uh if you have time maybe we can talk in private uh but here we we sort of set out to solve these challenges uh in all different ways and for the purpose of this uh session i'm only going to concentrate on the dhs2 integration uh so we sort of came up with a new framework uh well given all of those challenges first we sort of went down into the mud and created a new emr let's say uh a new hospital system and it is based on open mrs and with that we also figured we'd have to add the integration module because it was sort of the most important part on our end in terms of uh you know reporting that thing to dhs2 and so we went through the process of you know developing the emr uh following a certain set of journeys uh huh all right uh and in a nutshell you know the emr contains you know a passion journey uh the expectation is when a patient comes he goes through a certain process of consultation and all of that uh in our case in Tanzania they go through a process of registration building consultation laboratory pharmacy and you know things can move around in that manner depending on you know the the case itself whether it's inpatient or outpatient but our design was basically uh around that and for the most part uh we managed to sort of come up with a new design to address all of these issues and in our design we sort of chose open mrs as one of the bgd uh term they use nowadays we used open mrs and sort of created a module on top of open mrs and as you can see there is a bunch of things there you know bicycle all of that all of those are still too big to to talk about right here they require sessions of their own but i would like to concentrate so much on the dhx2 integration there is where i think this session is most probably all about uh so our idea of innovation is sort of uh if you've ever had the term kiss keep it simple uh we like to keep things simple so whatever we design whatever we put through we make it so simple such that uh it's easy you know for whether it's the user to use or anybody who is trying to use it to sort of get a feel of it without any issues and one of the problems that we face when we're integrating systems because we're we're also involved in integration of multiple other emr systems to dhx2 is the fact that people don't even people don't know much about the dhx2 api so you face a lot of challenges when you're trying to know for them to understand how dhx2 works share them with the apis you know things like that it was sort of a challenge so you know sometimes we end up creating mediators in the middle where we give them a data structure that is a little bit understandable to them and then maybe from there now you can translate you can extrapolate that and you know uh you know work uh in that manner but also that brings a lot a lot of other challenges you know like if things change in their system all of things that so many things that could go wrong that would make it problematic to sort of address that structure that you have created so what we decided to do is sort of within the emr that we created uh the integration module sort of works in a way that uh it it relieves the user from knowing the intricacies of dhx2 in a way so what it does first uh the tool downloads the metadata from dhx2 presumably if you have a dhx2 instance you probably have an aggregate form uh with its design and all of that so the idea is the tool downloads that metadata and then displays the form to the user and then now it's up to the you know whether it's the developer of the system or it's the uh you know the system administrator of the system who knows what the data is all about it's up to them now to perform a mapping of each individual data element to their database so essentially they say this data element and category option has this is the SQL that is going to fetch that data as simple as that they only need to know what data is needed and the SQL they need to write to sort of extrapolate that data and then the tool will take it from there it will just you know put the database on the SQL that of the mapping that has been made and then from there now it will send the data all the way to dhx2 so in a way we relieve the people who want to uh to sort of uh perform any mapping uh and one of the tools we actually looked towards the open mrs uh there is a tool for integration open mrs and dhx2 uh and the problem with that was you know transform transforming the architecture of open mrs didn't really cover every type of data that is needed in our dhx2 instance so it was better to sort of go the SQL way yeah so basically that is the basic design that we chose to go through and so far it's been working for us and yeah i still have one minute 37 seconds oh i was like yeah anyway but the juicy part i think the juicy part is over i mean what uh the next slide here was just how we went about deploying the system into the hospital uh systems you know here as well we're providing the training and the capacity building uh yeah and finally we are planning to create sort of an ecosystem around it uh we have deployed the EMR in about two facilities and we are way innovative so we sort of try to uh to sort of add features and throw them back if they don't work so we move fast in a way to sort of make sure we're not creating something that cannot be used or something like that so we are trying to create an ecosystem around other stakeholders the ministry of health facility levels the university community in terms of research and things like that but also the open source for me we haven't yet open sourced it but it's in the way to to sort of open source and yes on another point uh all right 30 seconds uh yeah anyway i think that's that's it asante son thanks thanks thanks very very much Vincent sorry for dragging you up the innovations coming out of these guys at UDSM it's quite incredible we could we could do a whole session just on UDSM innovation we need to share your screen then no we have to do it from what's on here um oh Vincent we could have left you here what is it called ah i feel so bad Vincent i've stolen a minute and a half do we have an agreement it's 1354 okay so hi everyone my name is yung from his vietnam with my colleagues here with john and sam so today we are very happy to introduce to you one example for the interprobability and the innovation innovation we did for lau pedia covid-19 and uh phi too okay so let's have a sorry that's our bit of the background that's we are currently having in law so we have a case by surveillance and a vaccination registry uh these are we took it from the tracker metadata packages so noting is special for this one so uh we have more thing that i'm going to focus on my presentation today the first one is the vaccination pre-registration and the national uh certificate vaccination certificate and vaccine certificate for travel and the mobile app okay so let's move to the first one the pre-registration for vaccination so what is this system so the system is one online web system where people can uh go there and book for their appointment in advance okay so and why do we have this system you buy the time lau start the vaccination campaign so many many people came through a vaccination site that was a very big crowd so um let's call the chaos okay so uh and then there were lack of the health worker who do the data collection so by having the pre-registration system we can reduce the pressure for the vaccination site and also for the health worker okay so um uh why i'm saying that because the when the people do the pre-registration they can enter the personal information by themselves so the health worker don't have to enter those data before that the health worker need to enter every data from the person okay so and what's the system content so it has three components the first one is the dh2 instant the second one uh dh2 instant with some customized app we have multiple customized app to implement the system uh the next one is we have the one customized service meet those service customized again so to uh connect the data from dh2 to the uh public portal and also for the certificate and the last one is the one uh online public portal so i will move to the next one so i think this is the most important slide for today's presentation so we have the graphs on how the whole system works so you can see on the left hand side the blue one we have the dh2 instant which is running on version 2.35 and in there we have the vaccination program and some customized app for the pre-registration system and also the national certificate and the travel certificate on the right hand side the orange one that is the public portal which have the address the vaccinate lab and the mobile app is working the same way okay so in this public portal any people can access to this one to do the pre-registration or to generate the certificate or request for the travel certificate okay so uh in the middle you have you see the green one this is the most important part in the in this in this graph so we have the middle service to connect the data from dh2 to the public portal and also get the data from dh2 to generate the certificate for the clients okay so that why do we have this middle system because from the public portal or from the mobile app we can request for the data directly from dh2 but it's not recommended because if we do like that there will be some chance that our some sensitive detail will be exposed to the public for example like dh2 url or username or the password so that's why we have this middle system and one more thing about this middle system is we also have the signing and verifying service which is used for the queue code i will talk about it later oh okay let's oh sorry go to the previous one so you have i have some green source on the pre-registration system so the first screenshot on the top is where the people can go there and input or their detail informations and then on the next screenshot on the right is where people can pick their vaccination site and then pick the appropriate date and the last one people can pick the appropriate time slots because we divide the time slot in one day because we don't want many many many people to come to the vaccination at the same time so that why we have the time slots okay so and then they submit it so after the submission we have the first screenshot there this is the pre-registration received in there we have one queue code and this is very simple queue code that queue code is for when people finish the submission they will take a screenshot of that receipt and then they come to the vaccination site they will show that queue code to the hair worker and the hair worker use the tablet with the hh2 on it with the customized app and they will scan that queue code and then can enter the data directly for that people okay so that's all for the pre-registration system so I will move to the national certificate so national certificate is the proof of vaccination then people can use this one to join the public activity like school hospital restaurant and something else so in the national certificate we have the personal information and vaccination data and the last one is queue code okay there are two types of national certificate there's a hard copy and digital copy for the hard copy people when they go to the vaccination site the hair worker will bring the hard copy of the certificate inside the HH2 okay so as you can see the journey for the hard copy and for the digital copy people will use the mobile app so they just go to the app store it will work with both android and ios they go to the app store download the app and then input the personal information and you will get the certificate okay so this is a screenshot on how the certificate look like we have some personal information the vaccination data and the screenshot on the rise is the functionalities in our custom app just to print the national certificate you can print either print only the first door or print only the second door or print the queue code only something like that yeah this is some screenshot for our mobile app so people can input the personal information and you see the third and the fourth screenshot is inside the mobile app you have the green background so that's been people fully vaccinated if you got only one dose and that will be in yellow color okay and last screenshot is people use the mobile app to verify the queue code i will talk about it later so and the last one is the vaccine vaccine certificate for travel so this is very similar to the national certificate but we can use this one internationally so in the vaccine certificate for travel we have something like the national certificate including the personal information and something else like passport number passport that of issuance and yeah and yeah and a QR code so so how people can how people can request for a travel certificate they will go to the public portal request for the certificate and we will have a team the health worker team to verify to verify their request there are two ways to forward people to get the travel certificate which is which are firstly they will come to the the pickup site and pick it or we have the email response the certificate we send via email to the person yeah i have some screenshot here on the right hand side is the list of on the request from from the people on the left hand side here when you when the health worker want to verify for one person they will click on verify button and we will have this screenshot if all the information is okay and then the health worker will click on verify and generate so when you click on generate the the travel certificate will be printed in the hard copy and if people choose to get the international sorry travel certificate by email and the email will be sent in this step okay this is how the travel certificate looks like okay let me talk let me let me explain a bit on the the the QR code so the our QR code is the cryptographically QR code and that cannot be cannot be fact and how do we generate the QR code we use a combination of keys the first keys is the private keys and the second key is the public key so the private key will be used to generate the QR code and the public key will be used to verify the QR code so for the private key we don't give it to anyone else and that is the top secret key if we give the private key to anyone then everyone can affect our QR code so the private key will be stored securely in our server so for the public key public key is used for the verification we can give it to any organization who want to scan our QR code for example we can give the public key to the organization within southeast asia country and they have their own verification and they will use that to scan our QR code and one more way to verify our QR code is to use the public portal or use the mobile app that also have the verification functionality yeah so yeah that's all from me thank you so Mona's making me feel very bad now I thought we had 90 minutes but we have two hours so I've been bullying everybody for nothing you know we have more time I can bring everybody back now my only way now is if I put Vincent on the stage and he knows he's got so long well I think I think we can have a good bit of discussion afterwards the the the QR code that that they did in in in his Vietnam because I was actually very interested in terms of the standards that were used it was based on the EU the EU specification that was released it's very nice um yeah can put what I should do is invite you up while I just get your slides up now Vincent you I feel really bad because I pushed you off and I didn't need to I'm sorry oh you're there yeah all right good so Simone if I hear you we have until three all right comfort take your time yeah be fair to others not really but you have like okay let's go to the bow you can have about 15 20 minutes and then maybe we can bring the other guys back up he hasn't fled where's Doom gone oh no he's just moved back after after comfort has finished his presentation maybe Vincent if you don't mind and Doom you can come and join us back up here and let's have a good chat all right you know how the mic is working I've just talked to that can you all hear me okay that's great uh good afternoon everyone my name is comfort manka I'm with uh his South Africa so today I'll be talking about uh interoperability work that we've done on the HRIS project that we're working on in South Africa so this is the outline of our presentation so I'll just give you a brief overview of you know where we come from with this and then I'll present the architecture like where we started and then the lesson we learned from where we started and the current you know update that we've made on the architecture and then we'll also talk about the next steps so we work with the national department of health in South Africa and there's human resources for health strategy 2030 and we use that as a guide in implementing this solution and with the HRIS or HRH system there are questions that we're trying to answer I mean for for the ministry like you know where are the health workers in how many nurses do we have how many medical you know practitioners can we work out how many nurses will need 2030 to achieve universal health coverage so basically these are some of the questions that we try to answer with the with the HRIS system so the HRIS system has four components or products that we managed to to to build so the first one is the registry so we are using happy server so it's a fire registry that is where all the health care worker records are and we use DHIS too as our data warehouse and we also have like the HRH portal so the portal right now is a DHIS app that we installed on the HR HR warehouse DHIS instance and we have we also have like the the the HRH you know plan a module I mean we started with the you know basic one and then we are moving into you know machine learning as we as we get more data to to be able to do predictions so these are the components as I've already highlighted this is the architecture that we started with like I said these are the data sources we get data from the PESA system PESA system is a system that is used by the ministry to to store data on you know all the government employees but our focus mainly is on health workers and then we have HPCSA these are our cancels for for doctors dentists and etc and then we have also nursing council and the pharmacy council and we also get data from municipalities that's data that is not on PESA and also get data from the private sector okay other data that we use or other sources are the DHIS too it's just for you know for the routine routine data and we also get data from the you know the MFL and like I said earlier I mean we we also have the the okay the registry so basically we get the data from from the sources we are using open him as the interoperability layer and then you know we push the data to the I mean to the warehouse I'll I'll I'll go into detail when when I talk about the the update that you've made I mean looking at the different components okay and the portal the portal I mean I've mentioned earlier I mean this is where the the ministry goes I mean to to look at the the data to look at you know who's where you get you know the the number of health health workers in different in different categories and we also have built mediators to allow the covid system to access data from the from the registry and even for vaccination they also get data from the from the registry I mean what we learned with the initial architecture was that we didn't have uh you know flexibility and to make changes it was taking us a bit of time and then the aggregation process as well was taking us time and and again in the warehouse to track back like if the the users want to know the the the records the individual records that led to the aggregate number we were a you know a challenge a challenge with that and we also learned that the fire registry is a it's a new or the fire rather is a new standard and we still have a lot of systems that are that can communicate using the fire the fire standard okay this is the the architecture update that we we had to make so I'll I'll go into details now just looking at the different components so with the data sources I mean they're still the same I mean we get the data from the the the cancels and and private sector and we also still use the the MFL and get data from DHS to routine uh system and then what we did like with the update we introduced uh what we call the dimensional model uh data lake there so basically instead of pushing the aggregated data directly to DHS too so what we've done we've introduced this middle piece uh to we push data from the ETL to to there and from there we we push that same data or the aggregated data rather we do aggregation in the dimensional model and we push that to to DHS too and we also push the individual records to to the fire the fire registry and we've also added the component for the machine learning because we've got the raw data in there with the aggregate data so we can do that uh in there okay so in terms of the the portal or the the visualization we we still have uh our dashboards on DHS too and then we still have the the web portal so that's where we do our visualizations and then we are uh trying to introduce uh advanced you know soft uh bi too uh right now we are experimenting with uh with superset uh we try we started with power bi but uh we had issues like with license especially for our our you know our our our our clients uh the ministry of health so we we're now trying to use uh superset to do our our advanced analytics so this is the full architecture so the only big change uh is with the introduction of the dimensional data data model so so yeah this has really uh uh improved uh but I'll just touch on that in the the next slide you know what benefits we got from the from the change and with the current architecture we are using the fire standard and we're using the you know the the HP server trying to use open software for this and we currently support the mobile care services discovery and then for aggregated data and you know we're trying to use adx as well to to to yeah to support that standard and then HPD as well so we're trying to use us as like open standards as much as we can and like with the update the benefits that we are we're seeing so far uh we've noticed that the if you make a change to the uh the data or introduce new data elements or or new variables that you want to report on uh it's easier to to do that now and then the queries are more optimized and then the machine learning capability we added that and also the uh the taking back to where the source data is so the the raw data you are able to to do that and uh also advanced and we're doing doing the in the previous architecture but but yeah I'm still doing that here so in terms of HRIS uh in in South Africa on the problem that we're working on I mean they are uh advanced that we are looking at uh like we are introducing machine learning and you know predictive analytics and then the uh you know the planning module and as I reported earlier uh we're trying to use uh you know BI tools uh as well for advanced reporting and yeah I would like to thank you know that the team that worked on the project and uh and and PEPFA okay this is uh information about uh his startup so thanks everyone I told everybody they had 10 minutes and in fact you have more teacher you know what I was saying this morning about architecture on fashion and I look at that die it's like everything that's in fashion is on that diagram fire repositories API mesh gateways all right so yeah sorry for cutting everybody short particularly Vincent I cut shorter than I should um but I think what I want to invite you Vincent and comfort and don't come back up um and have a reasonable opportunity to get properly grilled by people who want to ask questions we actually have half an hour if we we have more than half an hour we've been too good at this and I think the three guys are online twosome moments but see I think you're all there still yeah we are here are we allowed to comment online can you yes is that wrong yes it's wrong I don't know you don't have much security yeah please wrong I go ahead make a comment welcome I saw something about mcsb the mobile care services that actually can you get a beautiful explanation of how now it's implemented I think that was to you the mcsb who asked the question sorry that is wrong from Zimbabwe okay I wrong like we we are using the like the happy happy you know happy fire right and then it has resources you know that we're using we're using the the the the the location and then we are using the the practitioner resource and practitioner rule and those comply to the IHE if no mcsd standard so that's basically how we are we're currently using it okay because I'm thinking that you can specify the services that have been given by specific facilities right this is what I'm thinking so is it like possible to see which services are available in which facility or am I misunderstanding what mcsd is in this implementation I mean you would be able to like if you query locations I mean you'd be able to see or yeah you'd be able to see the services that are that are being offered or unless if I'm not understanding the question I think so maybe on the actual detail you might have to come back to come put afterwards but yeah you know mcsd you've got both locations and you've got services in the original original csd even had schedules if I remember correctly for appointments and the like but that's okay um maybe you can follow up after with comfort um okay thank you very much I'll do that yeah thank you here's a question from the back ah where is the like is that Alexa can you hear me okay um thank you all it was really fantastic to hear how your approaches to the solutions and thank you so much for sharing I have two questions one directed at comfort using open him um I was curious if you used a mediator from the open him library if you all developed a custom mediator to achieve your solution and whether the etl automation that you showed in your diagram was part of that mediator if that was handled by a separate platform okay for the mediator for sharing data with the the covid system that we showed we we developed a node you know a mediator in node j s and then we just install that on on open him and then it's right is it in the library now oh no it's not in the library it's a custom one that we we developed and then and then and set up or installed on open him so it's not on the layer so it's not on the library yet okay yeah it was something that we if you know others want a similar thing maybe something that we can push to the library it's not there yet okay yeah and for the etl tool we're using we're using airflow right so it's handled by by separate tool but but for the data it's just a pass through the open him and but but but the processing everything is done through the through airflow okay gotcha so profits are saying they're airflow and then routing it through the custom mediator on open him yes awesome and then for for vietnam and um Tanzania just questions for you all with with not using a central interoperability layer like open him how are you all handling central or not central but just logging and auditing of these transactions to monitor you know the success or failure of different sinks yeah in Tanzania we actually use open him okay so open him comes in the middle all the amounts of data to open him gotcha yeah sorry i missed that don't you reaching out to more how do you handle logging or auditing of the different transactions so if there is a failure or if you want to see an audit trail of the different sinks where does that manage how do you do that in DHS too now we must so even the back end just talking to DHS too but everything is happening the data is to be published it is talking to DHS as a service so that was the reason like the the middle layer was then we did is to just receive the data send the data to DHS we are not generating they're not storing any any anything outside the everything so okay so i'm not as familiar with DHS just to just to be more specific are you relying on like system generated timestamps on individual records to see when things have been updated and then like user login records to see when someone maybe initiated a transaction yes actually that's because all the projects are stopped locally like so even when the people are in the leader we just push through one particular username which is middleware okay we just send you the address to the channel notifications that's why they're working so it is initiated by this one but it is by finger again everything is stored inside you okay awesome thank you the service itself is also not visible necessarily in detail cool thank you i think there's a there's a general principle somewhere behind that question now we look at all the examples today first of all huge amount of variety and lots of different kinds of implementation and sometimes it's hard to see you know what kind of structural parts could be reused from one thing to another agent is that is is that you go ahead oh okay wait don't go ahead okay so my question is directed to comfort i understand you are using DHS to end fire so my question is how are you mapping fire resources to match the DHS to context now sorry in our case we were using the fire adapter so i just wanted to understand how we are you are doing doing the like transformations okay i mean all of that is done in airflow there's a like road like python script that that does that so yeah we do that yeah yeah we would like airflow like we built like did all the the mapping and yeah like in there okay i think that um lad has a question oh okay even though he didn't put his hand up about adx well well no actually no okay yeah i'll let you ask adx you are the father of adx at uio so you know i think most people who are in this room have dealt with interoperability and then you know the moving data across and what i've seen the the six presentations we are all basically creating custom solutions and have you looked in like existing products and like we're not able to find something that would do it for you and that's why you had to create a custom one or like what made you decide to basically come up with a custom solution because basically we keep on creating custom solutions and there's just no reuse a lot of times and it's not directed to specific team it's like whoever wants to answer yeah so for example in our case i would say we sort of looked on other solutions but the problem was whenever we try to integrate it's not only us who are supposed to it's usually somebody else they are they are the old vendors and they're supposed to send data to us so you find that they don't know most about the technology so it's sort of the problem to start capacity viewing them and all that so you find yourself in a situation where it's kind of infeasible let's say but one thing that i wanted to point out before Bob cut me out in my presentation yeah with the fact that the architecture that we have developed we actually trying to extrapolate it and then we try we want to try to build it on top of the of the tool that Bob and Morton used so that to allow the fire standard is involved in all of that the main thing we want to do at our end is such that because there are so many vendors who maybe they some of them are sort of reluctant to do it with standards for whatever reason we want to make it simple for them to sort of possibly not even worry about the standard so much and that's why we create that mapping which is easier now for the tool that we are creating to use the standards to you know extrapolate data to other systems that's our idea that from from our side there are not really many many tools out there to serve our environment so as you know making something to present during the pandemic that's where the taxidermy if we develop our own solution for the data integration between data to the end of the so we have a full control so that way then we can solve the issue very quickly so for example we are working on one solution and some some issues happen and we don't have any control that we need to contact the owner of the solution hey can you fix me about this and sometimes there will be much much more time difference and the issue needs to be solved immediately okay maybe like I can just add something yeah yes I mean for for us I mean in the architecture the tools that we've used are mainly open source right so yeah it's the mediator but if you look at the what I was the green part when I was talking about the dimensional we build that in sitters so and we're using GHIs too I mean even for the web portal I mean we're using open source tools I mean we're using charts we're using giflet and so basically we are it's just open source just using what is there and yeah the mediators sometimes you know like yeah there that would be custom but still we're using it when I open source tool that everyone is sort of all people are using out there yeah oh okay yes we had happy fire and then you had two dhs twos and the third one was the hisp the planning module yeah yes is that a app in dhs too or is it actually a separate application altogether so what we've done with that one we used I mean superset so we we used like norms I mean from WHO and so yeah I'd like to do some calculations to say you know maybe in a particular area how many you know professionals you know maybe nurses or you would need to meet you know maybe your targets or yeah so we use superset for that but going forward we are still you know exploring to and then we're trying to use you know machine learning we're trying to use ML flow and yeah so there's a lot of work that we're trying to do there but it didn't have enough data so but we are collecting more and yeah but that's where we are going but for now it's just we just build you know it's on superset we just build like yeah the calculations and that on superset yeah guys I know a little bit about the the hisp vietnam loud thing and I think the only is right in the end it was just something that needed to be done quickly and covid vaccination certificates were suddenly hugely in demand I know that it was early discussions around using open function together with dive oak there were complications around getting them off the ground and they weren't technical they were more sort of political and in the end I mean what they didn't they didn't actually quite go from scratch because the european union had produced its open source repository of how it was doing its vaccinations and deviants and what they actually did well they started off using the european union code base and then Morton rewrote it all as he does but under the open mrs stuff I'm talking about reusing open source software we had two open mrs presentations today from vincent and also mr impatsy who's still there online I hope and some of them referred to the old dhi s2 connector and they were all reasonably polite because I was very pleased to say it said you know this was pretty good but it wasn't quite good enough for what we need because because I wrote that thing 10 but about 10 years ago in a hotel room in in rwanda over a weekend it was never great but you know sometimes it's like that I mean the open source software is there perhaps it's not as well used as people imagine perhaps it's not quite as good as as you need it to be and people go off and and do something else I think what we're starting to see is more more efforts to try to converge around our all kind of integration frameworks I've seen you guys I've decided a patch a patchy airflow is something that gives you structure something to work with within our integration team I don't know if anyone was at the fire talk but more and more we're trying to encourage at least his groups who are developing instead of doing random python scripts to do stuff using our patchy camel tools and similarly I don't know what the open function folk are doing are building and enhancing the connectors for various systems including the dhi s2 one in a way that will allow people to easily take it up and without being religious about choosing between this this and that I mean the the fact that people are looking more towards using frameworks for interoperability instead of just these random ad hoc throw away scripts is a measure I think that we're maturing a little bit I hope how much is it working yeah okay so I have two questions one is actually for Bob Morton and the integration team and others for all of you who presented so I mean first of all to the integration team now we see a lot of new solutions integrations presented in this academy and this has happened even in the past so like what would be the way forward like is it just we hear these presentations and we may have few a community of practice posts around this innovation so are we thinking of any integrated approach to disseminate these innovations across the network because like I mean what we see is like every time I mean so it could be hisp so even other organizations who keep on creating their own custom solutions probably one may be the lack of knowledge on whatever that has been done of course like there were some justifications around we having control over what we have designed but that was more about COVID than when you require very rapid response I mean which was unusual scenario but moving forward what would be the solution that's number one number two again is for all of you like most I mean whatever the innovations that you have designed so far is there anything I mean there must be like what are the things that are preventing you from making all this code-based open source if there's any those are the two who is the second one director that you're all doing clue but but but dong is not doing any clue yours is all open source sorry first question yeah first question is for me yeah I suppose what we've started doing and it's kind of it's still a little bit internal sort of within the hisp group so you know chatura has been involved in that as well is trying to change the the way we have these interoperability discussion within Oslo which has been a little bit introspective we kind of just talking to ourselves three or four people every week and we're trying to blow that right open at the moment in terms it's now sort of a weekly meeting where all the hisp groups are working on integration projects can come together and converge not necessarily always just around tooling but also about about you know understanding the different patterns and the like the way for where we see that going two things I guess one is we've got plans we're going to do an integration academy that'll be exciting we haven't done that ever but also we got to get it out to just talking to his groups now we're going to get bigger in terms of I mean everybody's been talking about interoperability for the last couple of years but we haven't actually and as as hisp as dhs too what we've been doing is participating to some extent to rather you know the various groups and forums open hie and the like I think what we need to do now is to maybe open up some forums ourselves and say well this is this is this is a space that we need to be talking to a much wider community on so all that is happening I guess over the course of the the year ahead there's the other question why are you guys not making your stuff open source I think that was it was that comfort your stuff is it open source I don't I mean all the the tools that we're using open source right but with the mediators I mean we have a code I mean you know one keyed up I you know again I think we you try to stabilize the thing and and yeah I think that's the thing you know but at the end I mean this would be out in the open yeah because we use as much as we can to use standards and and others can easily adopt so I think that's the that's the goal and and using the open source tools I think is is an enabler it's like it's tools that we're moving towards that so nothing is actually really but the date of course you know it belongs to them but but but what we build like we stand as that we can definitely share with the community I think nothing's so you're not doing it yet no it's there on on your private repository on github yeah it's still like in close things because sometimes you're still fiddling with it and yeah but the the end goal is actually to share it yeah yes yes nothing is actually stroking us so that when you start you know yeah I mean it does it does raise another issue and I don't think that you want to pop in on this but one of the things that certainly concerned me over the last year or two is increasingly a concern around security yeah all right some of these little integration scripts and hacks and things uh sometimes leave a little bit to be desired um Alexa has pointed out for example the the the the importance of audit but there's also other things besides audit because it also opens up another layer of risk as soon as you start connecting to other systems security is a concern which hasn't really raised much of its head until now I think it's going to very much so but Vincent what are your open source plans about eye care yeah yeah so what's the what's the business model I think you're I think you're the last who could be just to you know innovation lab at the university we are basically open source enthusiasts we don't like to keep things to ourselves when it comes to the EMR unfortunately it's something that is still new and evolving and some of the concerns I think Bob has said there is the issue of security so we don't want to sort of open source it and you know why we haven't really considered all those other aspects of security and all of that as you know when you're creating a new product uh you you tend so much to to provide the functionality rather than looking these other what all these other aspects of security and all of that are taken care of but also there is the issue of you know what once we open source something wanted to be really good nice to read you know people can actually read it and things like that so it usually goes through you know refactoring process where you have to make sure really the community can read the code they can also contribute and things like that so for us it's just a matter of time although I presume the the the tool that we say we are going to extrapolate and create it as a tool of its own it could be fast because it's all it's going to carry minimal functionalities which I think we can open source it much faster than the entire EMR I would say yeah there's another argument against open sourcing it which might be interesting Doom might be able to respond to when they did this thing in Vietnam um they didn't have capacity to support the whole world right they just had a thing that was working for them and the big fear about making it very public and putting apps on app hubs and things like that was that if everybody took it up then you're going to be supporting you know potentially tens of tens of countries did you get that pressure Doom were there people asking you to to use your solution and and how did you do John maybe you you can answer this because it is open source as far as I understand anybody can yeah no actually like it's it is like we had a you were there we presented what Doom and Martin did and he converted it to GitHub because like Martin wanted it was to generate the QR code right the QR service the signing and the verification what Doom did was as to how DHRs to people can access it from the tracker to public portal and we made that code is already in GitHub and we asked Nick because Doom and his Vietnam team were a bit not so good in documentation so Nick wrote a pure good documentation on how to import it and how to install it and use it for their own DHRs to and that was made public so that like it can be used across and we did a demo for DHRs to global team and how we can try to do it and Doom also shared the same things with his Pruvanda with Andrew and he was the one who created his own solution for their Wanda base so there is some kind of learning and things are happening and what you're saying is to if we make this whole thing public right now so a few of the solutions like the the web portal the signing and verification service those are public what is not public is the mobile solution which we just are learning how to make the mobile solution for put it in the Google Play Store and App Store that's very specific for the country that is what we don't know how to even make it public. So there's much more to making something public than just putting it on GitHub right there was a clue they had to get people in the right documentation and tidy it up perhaps to an extent that they wouldn't have done otherwise. Can I comment is are we still on? Ranga we haven't muted you yet. Okay thank you so I mean I'm just wondering what is open source making something public is that making it open source because I think there's something there because you know when you make something open source you're now talking about maybe a little bit more than just putting your source called public it should be accessible to a lot of people people should you should be able to develop the community around the product the quality of the software so I don't think a lot of people have actually matured enough to produce open source software that's my comment. But some of your stuff is not open source Ranga I know that. Yeah because you know for example we don't know but the thing about it again be open source now or later because a lot of people are saying we saw open source which are open source but in my view an open source project is easier if it starts out as an open source project. Yeah instead of trying to reflect a lot of things later on. Okay that's my comment thanks. That's probably true I don't know Alexa do you have any thoughts about that you you've gone through a journey of taking something and making it open source so so what are the challenges around that in terms of the business model and you know what's difficult. Well for us right now you have a mic coming. I did but there's naughty boys at the back of the classroom. Hi everyone Alexa from Open Function so we have an integration platform that started off as a SAS but with an open core and particularly over the last couple years especially this year we've been taking a lot of what's in our proprietary platform and moving it over to our open source DPG. So for us the process has been interesting because there's a lot of stuff tied up in that platform kind of as Ranga said that it's not the best a lot of refactoring poor documentation stuff that really requires like our team to know what's going on there but also stuff that are maybe specific to proprietary functionality like billing but for us I think going open source has been a really good exercise and checking our work making sure that that it is readable and you know trying to really think about you know how easy is it for someone else to pick up and to extend and are you really setting up other contributors to success but something that we're certainly you know exploring and then trying to get better at is like how do you do that community building because again it's not just making a repo public but how do you create those forums to have these conversations to promote your work. For us one avenue that we've taken is that there's already a lot of really amazing open source communities particularly in the digital health space so for example we interact a lot in the open HIE communities and they already have standing calls regular weekly monthly basis that lots of people go that are interested in this thing so sometimes just by showing up at those and sharing your work it's a way of again not duplicating forums and communities but rather trying to cross pollinate and and those that exist so I think for the DHS2 community to be interesting to see you know like what existing academies or community practices can be leveraged to then promote open source work by individual implementations or his groups that are doing. Now it's a really interesting point about about quality I think that I mean sometimes when you get open source something you start to introspect a little bit and you think it is not quite as good as we'd like it to be it's actually quite good thing to do though because it does make you improve and I think it's also important from security perspective. So if you've got horrible little scripts with all the authentication in plain text in the top of the python script you know you can live with that if it's if it's proprietary if you're going to put it on a repository then you feel a bit ashamed I hope. I think I just wanted to add a bit on the community because I think Alexa was the first person to talk about it um but I think each project will need its own community because when you look at the global open source projects beyond the public outspace like the linux project and all of that they have their own core people within their belief in the project that commit their time to the project. So in addition to starting to project as an open source project from the beginning I think you need to find your believers people that believe in your idea outside of your organization. I think I read a few years ago Izida Open HIM it started in a project and that project ended many years ago but over time believed in it and they continue to work on it and develop it. So I think that approach can actually help. I see a lot of the presentations on the um integration and it's similar to what we are also doing in West Africa and I'm laughing privately like it would be nice to see the work others are doing so that I don't have to write connectors for 15 countries all over again. I can just take from what you have but these communities are missing so people are not really aware of what's happening around the world and I think a lot of thoughts need to be put into that and how to publicize them. Thank you. Yeah thanks Bob. Uh this is Dr Basharat from Pakistan. Uh yeah just a comment that while we keep and use it as an open source DHS too I think we should have strict SOPs for the for the security and safety of the data and it not be like this a randomly open source we may have the provision of data encryption by the by the uh the country or by the organization who is using it. I think this is these are two things to be taken into consideration while make it a source set so I mean sort of open source. No absolutely thanks for that um and I I think if I think about DHS too for example one of the benefits that we have at this point is because we have so many people using it there are a lot of penetration tests sometimes by our friends and sometimes by people who are not our friends but they share the results with us anyway and one of the advantages of being open is that you you do get looked at um and that's what we want to encourage. Um some of these small little scripts and things we don't know anybody has ever looked at them whether they whether there's any quality control in the sense of what you talk about you need in Pakistan but we can talk more. His Pakistan um I visited just three weeks ago was my first time ever in Pakistan but one of the areas the niche that they are looking at perhaps getting into because Pakistan is a little bit complicated in terms of many different implementers these focus exactly on these interoperability problem they want to position themselves as the the integration partner. So interesting talk to talk to Adnan and the his Pakistan people. Vlad is not going to ask it so I'm going to ask it okay Vlad ask it the last question of the day well I don't know I would probably ask it better but so we started using ADX five six here five years ago and you know when we started using it it was basically you know you could send 100 records to uh DHS too and if you had 200 it would take an hour and then you know you had 300 it would take three hours and so on and you know Bob and Jim Grace was not here were like very helpful get it fixed immediately but it's been still challenging you know and just how useful do you find using ADX and what were the challenges of using ADX for you know sending data along. Oh yeah no no we I think it's just something that we're starting to look into we haven't started using it yet yeah yeah I think it's just right now I mean yeah we're using fire and then we just do the aggregation and then we yeah for example we're not using we're exploring yeah seeing if there are benefits but I think there's a lot we can learn from you guys that yeah thank you my question is or not the question is the action point we've seen lots of presentation we need to cut it down and off so when will be your integration workshop where we have three four days where you can actually just take one example and just say you can modify this one and make it right and more on the and so on integration workshop. Yeah we should do like four or five days proper. But I think it's probably like Morton was thinking after Christmas is there still going to be workshops coming up for Christmas? January never works so he's probably February next year if I'm gonna it was our betting man I would say February 2023 one week integration workshop solve all the problems of the world.