 So you've got four presentations for quite different projects and they were selected really from dozens of applications that came in, because there's only forward to be quite a, quite a brief bit of time we can give to each of them. We have the expert lounge tomorrow morning, where hopefully we can continue discussion that emerges from them. So without further ado, I'm just going to introduce very briefly the four speakers, and I will leave them, I will leave them to present so we've got. First off, Dr. John Stelling and Julius Sujan. John is, I think as I mentioned in the plenary before. He's the co director of the WHO collaborating center for surveillance of anti microbial resistance in Boston, former medical office with the WHO and anti microbial resistance containment unit. He leads the development of his a software called who net, which has been the sort of global gold standard used by microbiology labs in over 130 countries. He's been working together with Julius Sujan. Some of us have known for quite a long time Julius is, is from Bangladesh. He's done a lot of interoperability work training work and the like with with his spin the air with his Bangladesh and director of the university of Oslo. So they'll be talking about AMR. We've got a presentation on open MRS connectivity with DHS to from Grace Popma, Pumail, Ratnayaki and Jaya Sanka with a singer. I think Jaya Sanka and Pumail will be presenting. I'm really excited to hear more about where we are, the DHS to connector. So I'm going to start off with a historian trickling, who is going to present again the story. I think if I have it right of individual level data from the, from the periphery towards the, the DHS to its central level. Interesting project from from Burkina Faso. And finally, but not least, we have Ranga, Ranga Rai, who's a PhD graduate from from the University of Oslo. He's a developer, he's an intellectual, he's an entrepreneur. And he's the current custodian of the DHS to fire adapter and various innovations around that. So that's what we have ahead of us. I don't know if presenters are ready to go, but we wanted to start with John and Julius. Great. This is john, I can you hear me is the audio okay. We hear you great job. Perfect thank you so much everyone and we have a short period of time so I'll start directly. And the next topic is, I've already been introduced I'll just dive right in. The subject is surveillance of antimicrobial resistance and integration of our who not software, and the DHS to software and a pilot project in Bangladesh. And with my co presenter and collaborator to last to john. As you all know antimicrobials were one of the most important innovations of the 20th century for providing health, safe health care, curing infectious diseases, and we rely on them for so many things. But resistance is a growing threat and one of the main public health threats of the 21st century. The international surveillance activities, many of which do depend on the who not software at the local facility. National regional and global. Here are some of the regional and global activities, most of which have some dependence on who not. I do want to also highlight the first one from the United Nations, the UN interagency coordination group on AMR and the global leaders group like to point out that the co director the co chair of the global leaders group is in fact the DHS to Bangladesh, which also makes this another opera, another reason why Bangladesh is such an attractive pilot, as well as the very significant DHS to expertise there. The work I'm describing is funded by the UK Department of Health and Social Care through their Fleming fund initiative. I am part of two of the regional grants. People would like any further information about any of these activities. Feel free to contact us. There are other groups working with DHS to an AMR integration. And these are some that we are aware of. If other people are also active we would love to hear from you and seek opportunities for collaboration. University of Oslo and his India have been working on a tracker module find on an event program with the glass export glasses the WHO global anti recovery resistant surveillance system I mentioned that I showed it on the previous slide. This is an initiative in Senegal for using path tracker module for clinical reporting. And, of course, one of the standard WHO packages for DHS to, or DHS to packages for WHO is the tuberculosis project, which of course includes a module for DHS. There's also an initiative for Vietnam which started and then stopped. And one of the reasons they stopped stopped were because of limitations they found in DHS to, and I will come to a slide on that further in the presentation. This is a free software desktop software not a web software that our group has been developing. In fact, we go back to the 1960s with Dr. Tom O'Brien and, you know, the original dis diffusion, but we codified the name who net in 1989 as a desktop software that we've migrated over years. Currently we support over 3000 hospital food, animal health and no environmental labs in over 130 countries. The software is available in 29 languages. Primarily includes a laboratory configuration module so you can figure the software the way that you would need for your local purposes. data entry can be accomplished to either by manual data entry on a day to day basis by laboratory staff out of the notebooks, or through a data import module software. So if you have a lab information system and instrument database Excel. In most cases, it's possible to import those data, daily, weekly, monthly, yearly into who net to take advantage of the analytical features of who net. There's one example of interoperability. Bob gave some excellent points in those principles about the value of these and always coming down to the use the use case scenario how can we provide value. So people all over the world have live information systems with for clinical reporting purposes day to day operations, but without analytics. So that's where we come in to support analytics and data sharing data analysis I'll mention some examples and data exports. So who net is our, our software and we've integrated DH is two in three areas. One is exporting isolate level records into event program CSV files, or statistical aggregate statistics and analysis results into DH is to data set CSV files. When you export from who net it expects it exports along the associated required XML metadata files, so that you can import these into DH is to the exporter standardized all over the world. Well, once this is rolled out but whenever you export from who net it will always create the same set of UIDs. So if you are working with this in a variety of countries it facilitates the exchange of data among the DHS to databases, because the UIDs are all consistent across implementations. We've implemented the export in a set of predefined standard reports, click here that's the, that's the standard report you do this and then go to DHS to and you will always get the same thing with every instance. The really important one is the WHO glass export and you see in the lower right hand corner checkbox export to DH is to. You can also do interactive analysis with who net, you can output those results to the screen to excel to access or now DH is to below that it says configure output files where you would enter, for example, your high level organization unit, you ID. In the future we will also support Jason will work more closely with University of Oslo his India on their tracker module in integration, and with other people who would be interested in working together. We will also look at automated synchronization of the back ends. Right now, DHS to was new for us a year ago. So we're also it's a learning opportunity for us to take advantage of the richness of DHS to for bringing in our expertise and our international network on microbiology These are some examples of the output screens. You can do analysis of single antibiotics. Cross resistance with two antibiotics this is particularly useful for pharmacy studies about comparing drug a and drug be also quality control to these results make sense. Multi drug resistance tracking. This is very about we study resistance in part because of its public health importance and clinical importance, but antimicrobial resistance is also a useful epidemiological marker to facilitate strain tracking and outbreak detection. On this screen it's outbreak detection visually by looking at a graph. We have high I should alerts who net is showing you things that are clinical importance public health importance or quality control importance, suggesting a deficiency in laboratory practices. We also have statistical outbreak detection, we have integrated who net with the free sat scan software. You see an example here of Shigella in Argentina, and in red and outbreak that was confirmed initially by pulse field gel electrophoresis and later by whole genome sequencing. So it's very valuable again this interoperability. We have put the sat scan batch as a module within who net. So the user does not need to learn the other software. Also the glass export is an important one now as the temperature glass initiatives are getting out. So we did come across some limitations and we look forward to working with you to understand and address these. There's a lot of issues about duplicate counting if you have one patient in January one patient and that same patient in February. That's still one patient. So you should not be counting it multiply with data sets and events you end up with double counting with tracker you can facilitate you can count the number of people correctly. But it gets more complicated with antimicrobial resistance you want first isolate per patient per species for resistance pattern, perhaps per data stratification. So there are additional elements to how to do proper counting of events when we're looking for outbreaks, we're looking for outbreaks in a hospital setting on those isolates that are first isolates on hospital day three or later. There is some complexity there. People have often made mistakes in the interpretation of susceptibility test results. If you do it the easy way you'll get most things right, but there are a lot of complexities regarding hierarchies specimen type diseases, and it has to be maintained over time. So we're working collaboratively with CLSI in UCAS to make this plug and play as much as possible. There are human break points animal break points and also epidemiological cut off values, also known as microbiological break points. So for with DHS to we found a lot of wonderful things for the descriptive statistics and visualization, but for higher level analyses. That's where we find that integrating with who net can be of great value. And I'm talking about the who net, the core functionality of DHS to file sizes at one month of the data from a small hospital takes for us 140 kilobytes that same file in DHS to a 6.5 megabytes. And then records instead of 622 slow times and record limits. And these are some of the reasons why Vietnam stopped their DHS to that issues of performance flexibility. They did a lot of custom programming, and then they just went in a different direction. So this is important to keep in mind for further work. So I'm sorry just a warning you're on 10 minutes. Okay, great. Thank you. And I would now like to switch over to my colleague Jules. Thank you. This is Dr. Steling. Hello, my name is Jules. In collaboration with the communicable disease control department IDC and drug administration. We met a large number of public and private hospitals for engagement and initial assessment of laboratory for antimicrobial resistance surveillance in Bangladesh. Out of this we included 56 for on site assessments. We have provided training on who needs software over 140 microbiologist clinicians IT stuff and national Amr policymakers in Bangladesh who need has been installed in 31 laboratories thus far. We have been collecting three years of historical laboratory data from 41 governmental and private hospitals in eight divisions across the country. With a successful pilot. This will be sustained with prospective data collection and use as well as automation of file data processing. In terms of who need and he says to integration pilot in Bangladesh. We have a distance to pilot instance hosted in Amazon oil services for non confidential data with a successful pilot. In terms of development I mean DC assist will establish an Amr dedicated to server for both confidential and non confidential data with automated file transfers and synchronization of who need and he says to back in databases. Next slide. Next slide please. Julia sorry you're going to have to wrap up in about one minute so sorry. Yeah, sure. You need to jump straight to a summary. Okay, sure. We imported metadata data sets and events to decide to the necessary metadata available here you can see in the screen. Next place please. Next. Okay, this is the proposed architecture for the Amr data visualization platform in Bangladesh. And in summary, who need is widely used. Next please. Who need is widely used all the way to support local national regional and global Amr surveillance initiatives. On the other hand, this is widely used by national authorities for surveillance and program monitoring initiatives. So, this integration should support the development implementation monitoring and impact evaluation in near real time of national Amr contentment status is in Bangladesh. Next, please. Yeah, we would like to thank our government partners, especially Dr. Ron in the room and the program manager and Dr. Jackie days have you been a scientific officer ideas here. Thank you all for listening. Thanks very much Julius and thank you john. Sorry for rushing you through that that was really really fascinating. Lots of interesting questions particularly I think around the, the question of cohort counting versus head counting. We might get that theme might emerge again in some of the other presentations but otherwise we'll get the chance to take a few questions right at the end or in the expert lounge discussion tomorrow. Move on to next presentation, which is Jaya Sankar and Amal. I hope I'm pronouncing your name correctly. Yeah. Let me share my screen. Yep, we see it. Can he move. Okay, so thank you very much for the quick introduction. So I'm just a community developer at OpenMRS. I'm Puma and I'm also community at OpenMRS. So we are so happy to be a part of the digital DHS when working for us isn't it Puma. Yes, of course, yes, uncle. So we have developed a module at OpenMRS to integrate OpenMRS with DHS to without talking much, let's move into a quick demo. Let's assume that we have an OpenMRS instance in a hospital and we need to visualize COVID-19 patient data in DHS too. Okay, now I have set up a new data set using DHS to gather COVID-19 patient data. Yeah, I have patient counts based on gender and age. I have three age groups here. There are some affiliates, pardon me, just for the demo purpose. Also, I have created a new OpenMRS period indicator report to get the data that I need. So the data set is to gather monthly data. If I need to visualize this data, I have to run the report at the end of each month and copy those values one by one and paste them into DHS too. Pretty hard, huh? Here's the problem. If you have many complicated reports and numerous data sets, then the things get much worse. Here's the DHS to connect a module that comes to the picture. This module was initially developed by GenB, then it has migrated to the OpenMRS report. Had so of to GenB for developing this extremely useful module. Using this module, you can easily push data from OpenMRS to DHS too. Without talking much, let's move to the module. You can install this module from the module window of OpenMRS or just follow the setup instructions on the readme file. I'm going to connect the module with DHS to by adding the host, DHS to username and password. Before sending the data, we have to create a mapping. Mapping stores the relation between OpenMRS report and the DHS to data sets. We have to select the OpenMRS report from the left side and the DHS to data sets from the right side. This which will give you a nice drag and drop UI to do the mappings with the indicators of the report and the data elements and the category option of DHS too. Now I have created the mapping. Let's try to push some data. In the DHS to dashboard, I have generated some nice little charts for my data set. As you can see here, I don't have data for the month of September. Also, I can see on the data intuitive too. Now let's go back to the module's front report page. Select our report and the mapping. Select the relevant OpenMRS location and the DHS to open it. Select the month, in this case September. Also, notice the indicator changes according to the period type of the data set. We are ready to go. Let's click on the send button and wait for the response. Amazing! Seems we have done it correctly. Let's go to DHS to you and verify it. Now let's check back the month of September. Here we go. We have successfully pushed the data to DHS too. Let's see what happened to our charts. Before that, we need to do one thing. It's updating the analytics table. Okay, let's see how it looks. Now we can see data for the month of September here. Apart from that, the module has some nice set of features. You can manage these mapping, duplicate them or delete them. Also, you can export and re-import the mapping. Share them between the instance. Back up the DHS to API. Another nice feature that comes with the module is the schedule option. All you have to do is schedule in the report. The module will do the jobs for you. In that demo, you saw the things which can be done using the DHS connector module. Now these things are we are focusing on. You may notice that the user has to select the open MRS location and the DHS to organize into it when pushing data for DHS too. We thought to make it easier for the user. So we are going to implement a new feature called Automated Location Mapping. With this feature, users can save the matching location-organized sets for the future usage. And with the help of DHS to API, everything involving location-organized would be automated. Also, we are increasing the security of this module by implementing a user access control system. Here we introduce a new role-privilege-based access control system. So the open MRS admins can assign roles and privileges to the people who handle the module. In addition, this feature can greatly reduce the common mistakes made by the users. When it comes to UI UX, we keep improving the UI to provide a better user experience by making it simpler and easier. Also, we optimize the workflow of the DHS connector module to make the processes faster. Yes, uncle. So this module is also available in public. So you can easily download it by using open MRS identification. That's good news. As everything at open MRS, this is also an open source module. So you can contribute to this module to make it far better. Join open MRS talk today and let's continue the discussion there. If you have any questions, feel free to contact us in open MRS talk or DHS to community. Also, you can have a chat with us with the controllers as well. I hope you got an idea about the module. Thank you very much for listening. Thanks very much. Save lives. Thanks very much, guys. That was a really entertaining presentation. I like the musical interludes. It's really, really cool how you seem to have fixed all of the ugliness of the old DHS to connector module, the drag and drop interface and the like. It's exciting to see where it's got to. And I know there's a huge amount of interest in DHS to open MRS interoperability, more particularly again recently. So yeah, wish you all the best with, with, with the continued development diet. And thanks for sticking on time. Thank you very much, Bob. Now we have Florian. Florian, are you ready to roll? Okay, I'm ready. Thank you, Bob. Let me share my screen. Can you hear me? We hear you. Good. And can you see me now? It's okay. Can you see my screen? Yep, all good. Thanks. So hello, everyone. My name is Florian Triclin. And I'm really pleased to present Yeda, the digital health approach of TARDISOM. And it's complementarity with ENDOS and the HEALS data warehouse of Okinawa Faso, which is based on DHS to instance. In a few words, TARDISOM is the main organization for children in Switzerland. It is present in 35 countries around the world and had 4.8 million beneficiaries in 2020. TARDISOM is present in Mauritania, Senegal, Mali, Guinea, Okinawa Faso, Niger and Algeria in 3 main areas, which are access to justice, migration and health. In the health sector, TDH focuses mainly on 3 priorities. Maternal newborn and child health, strengthening of the health system. And digital health, which is transversal to the first two. In terms of digital health, TARDISOM has co-created since 2010 with the Ministry of Health in Okinawa Faso, a digital health approach whose primary objective is to improve the quality of care at the peripheral level. The first approach is based on four pillars. The first is a digital tool, which is called the REC for registre électronique de consultation in French, which is electronic consultation register, which I will come back after. The second pillar concerns the analysis and the exploitation of data resulting from the use of the tool. The third pillar, which is largely responsible for the success of the approach, is coaching at the peripheral level, which aims to improve the overall level of competence of health workers. The fourth pillar is e-learning through a platform that links health workers to training modules. In Okinawa Faso, the IMCI for children under five years of age was digitized in 2010 and implemented on the tablets made available in the Hill Centers. In this representation of the Okinawa Faso health system, we see that IEDA is now composed of several tools at the bottom of the slide. The IMCI, but also REC maternity composed of five forms, prenatal care, delivery, postnatal care, family planning, and post-abortion care. Two other tools complete the suite at the peripheral level, an EMR for those over five years of age, and a stock management tool. As we will see later, all these tools are fully integrated into the countries in IT infrastructure. The IMCI, the REC, let's say the REC for registre électronique de consultation, for IMCI within the IEDA approach is at scale in Okinawa Faso and currently covers nearly 85% of the country's Hill Centers. Full coverage will probably be reached by the end of this year or probably early next year. The REC records an average of 250,000 consultations per month. It contains more than 10 million consultations for five children, five million children, sorry. So this scale-up is leading to a transfer process that we are currently carrying out to the Ministry of Health and we hope to carry out equivalent scales up in India, Mali, and Niger, where we are currently conducting pilots. The diagnostic tool allows his workers to refine the analysis of symptoms and improve diagnosis and treatment through an algorithm that interacts with the his worker. The data is entered into the tool progressively by agents who are attentive to the patients. Regular checks are made on the data entered thanks to machine learning algorithms. These elements contribute to the capture of highly reliable data, not to mention the significant improvements in classification, in the case of the IMCI, and diagnosis that the tool has brought about. It's also worth noting the short-knit timeframe in which these data are made available. Indeed, the tablets containing the REC regularly synchronize their data with the central platform-based and com-care technology where 3G coverage exists. Statistics shows that more than 60% of PhDs upload their data in less than a week. This value increases to more than 97% in less than a month. So Yeda data is prompt and highly available. Finally, one last point regarding the Yeda data in the districts and PhDs where the Yeda approach is strongly applied. Almost all consultations are carried out with the tool. The data are therefore very complete. The fact that Yeda is at scale represents an additional incentive for district management teams and his workers to adopt the approach. The Yeda data are therefore highly available in a very short time and have a high level of completeness. I would now like to spend a few minutes on the process of aggregating and collecting the his data that we typically find in our healthcare settings. So in Burkina Faso, Burkina Faso is no exception to this rule. In general, consultations are recorded manually in a register kept in the health centers. This register is the source of the monthly reports prepared by the head nurses, which are then transmitted to the districts. In Burkina Faso, there is a decentralized data entry pilot in DHIS2. Thanks to the CAPTU application deployed on the Yeda tablets. Whether the data is entered in a paper report or in CAPTU, the aggregation operation in the register is manual, as is the data and trial. The data that reaches the district is then analyzed and validated by the district management team in DHIS2 to feed the country's decision making dashboards. Yeda's primary goal is to improve the quality of care. But it is clear that the value of such a system also lies in its ability to replace manual data and trial for monthly reporting by aggregating and transmitting the data collected during consultations in an automated manner. There is then very little to do for this aggregated data to be automatically transferred to the DHIS2. The Motec module performed this function by converting the com care forms into DHIS2 events. Through this association between Yeda and DHIS2, we quickly understand the complementarity of these two tools and the advantages of integrating a CDSA like Yeda from the design of a National Health Information System. CDSA data are exploited and constitute an extremely reliable prompt and complete source for the decision making tools used at the central level. His worker can focus on patient care. They save valuable time and his centers save money that they can reinvest in the medical equipment essential to their work. Yeda is a rare example of a digital health tool scaled up in West Africa that is fully integrated into the country's health infrastructure, improving the quality of patient care while improving the quality of the data that underpins the ministry's decisions. Thank you. The floor is yours, Bob. Thanks Florian. It was a really interesting presentation. I think there'd be lots of questions people might be interested to ask. Hopefully we'll have a little bit of time towards the end. I'm particularly interested in the handover process which you say is due to happen now in 2021. But yeah, let's move straight over to Ranga and let's see if we get a little bit of time at the end. Thank you, Florian. Thank you, Bob. I'm going to present on the work we've been doing with the DHIS to fire. I think you can see presentation, right? It's coming. Yeah, I see it. So basically, we're just going to talk a bit about DHIS to end fire and some of the progress that has been made within the community and implementing the DHIS to fire adapter, which is a very interesting component within this architecture. So I'll just get straight to the point. I've got many screens here. Can you see the next screen? Okay, so basically the background is this is kind of the architecture of the system if you want to think of it that way. So there's a set of Android applications that we developed. The first one we call register, which is basically for patient identifiable information. Then the second one is what we call freezing clinic app, which is basically the point of care system at the facility where clients are met. And the other one is internal referral for doing internal referrals or referrals from internal in an organization to other facilities that are outside than an external referral for referring clients inside. So that's kind of at least the user. What is interesting is that all these apps, they are basically customized on DHIS to then that's kind of the interoperability aspects of the apps themselves, DHIS to, but also in terms of sending data, we customize on DHIS to that means mental data is created on DHIS to, but we don't send data directly to DHIS to within our app. We now have to send the data to a file server. And also we have been implementing EpiFire, which is one of the largest fire implementations. So then this is kind of the picture, the Android app, which is freezing, which is basically a sort of apps. And then we have the fire layer. And we have DHIS to fire adapting DHIS to. So initially when you log on, the system goes through and gets metadata from DHIS to set up phones, you know that on mobile phones, depending on which app you're using. And then having done that, you capture your records, then they go through fire, the fire server, then through the DHIS fire adapting back to DHIS to. So basically, in terms of the Android apps and so that's a screenshot from from that. Basically, it's an Android, it's a native Android application. So it's, it's not really flexible to move to other platforms and we basically used native Android features and libraries. So that makes our system quite easy to set up on distribution platforms like Google Cloud and all that. And then it's full offline capabilities on the app. That means once you log in for the first time, you're offline also because it uses DHIS to or to, you don't need to enter a password again. So all transactions with the system throughout to then it's fire compliant, the Android app itself. So basically what it does, it takes DHIS metadata, then it converts it into a fire compliant format. Then it's the person who's entering data is basically entering fire compliant data. Then multi user support, you can have multiple users using the same device. Once you log in, you just need a pin. So you can have five, six users just entering the pins to log back into continue. And also because of offline capabilities and unavailability of the internet in some of these countries where Bluetooth exchange data offline. Then we have biometric referral system that you know, somebody can enter their fingerprint when you're referring the referral is created using a fingerprint then it's received on the other end using the fingerprint as well. So you cannot access the referral data if the person does not bring your fingerprints. So then, when you say interoperable with DHS to mean that we customize using DHS to checker. Then we also built on top of the DHS to authentication. They are so basically use DHS to auto authentication and even to authenticate to our file servers. Then what is critical is that we we also run the DHS to program rules on the app. So basically if you create program rules in DHS to on the app they will run on the system. Then also it's supposed to pretty large database because we are our client who we are currently working with there's maybe 8000 patients at a time so can be quite big in terms of amount of data that is accessible from the mobile device in an offline man. So, let me say that this is basically the mapping that we did from DHS to fire, what you call tracked entity type in DHS to it could be a resource and you know DHS to track entity types you never know what they are the person. It could be anything a world DHS to can track basically anything right. So in this case we have to specify what we're tracking. So in fireside we have to know that we're tracking a patient I was tracking a referral. I would check in something else so we have to specify. So in terms of the fields DHS to call them track entity attributes. On the fireside we specify we linked to the fireside using what's called fire part. So basically we decorate DHS to attributes with fire parts this compliant metadata so that we know that okay this name is actually a patient name or this field is actually a same name or this is a contact or this a phone number. So we do the mapping on the DHS to side. And of course in terms of clinical decision support in the DHS to side with program rules in terms of fire. We talk about clinical quality language this is a direction that we're going now but we haven't fully implemented secure. So in DHS to your own the program the fireside map that program into what's called a K plan. And of course what you call an event in DHS to is an activity in the K plan on fire data what you call it data element in DHS who can directly mapped to a questionnaire response on the fireside. But also that's just a generic approach to customization. There are many ways in which to dig deep into by standards and so on and so forth. And then of course indicator in DHS to is what's called a measure in fire. So in terms of how you specify DHS to system you probably need to have a data indicator dictionary of some sort in fire use what to call profiles so we've done all this mapping in the background. So the system just connects from one side to that. And I would say that our current application application of the system is the sex work program in Zimbabwe which is 80,000 either mobile clients across border is that the spelling border, not sure. But cross border, you know, they travel a lot and you need to track their many legacy systems for the client we've been working with and, for example, what's called coconut they've also been using all decay. They basically integrated all those different system into one system which is fire and DHS to compliant. And of course we've conducted the piloting and we fixed the bugs reported in the pilots. And now they just find the data to make sure because it's been quite a lot of legacy information. So that's that side of things and the DHS to fire that place working moving data from between DHS to and fire as you can see. We have a company called the migrator which basically takes data from their pre existing systems into the highest to into a happy fire then from a fire through the adapter to DHS to. So, I mean, we want to we've been, we've been using questionnaires a lot because they map easily to DHS to kind of questionnaires, but also want to go deeper into us that was using other types of resources started using other resources on fire. So that's called service request and we're basically developing the DHS to fire adapted to accommodate more resources, which are for compliance. And of course we've also been participating and working with a team in WHO, which has been working on what they call computer or care guidelines. So in this forum, we're participating in the project to develop what's called an Android Fire SDK, which will limit because originally we wrote our own fire SDK within our Android apps. So the teams Google and other stakeholders are inviting a new fire SDK which can be used across different Android apps and is by default compliant fire. So that's what we're using and also it's easy for you to receive what I call computer bouquet the guidelines, which will be distributed by double HL which will just run on the Android app. Then you have a five compliance implementation by just doing that. Of course we're also working and improving the DHS to fire doctor there's a lot of work to be done there. So so far is we're using it as it is, but the main ideas in terms of how to automate it how to make it easier to use a lot of people try to use the fire doctor, and coming to us and facing some challenges and maybe giving up along the way so hopefully in the process we improve that applicability of that fire adapter on the DHS to site. And of course we're working on integration on secure between. So basically once we start using the Android fire SDK, which is under development, secure is built in so we won't necessarily need, for example, to run the DHS to program is engine within our system. So I mean, basically, so the different partners that have been participating in this project, it's invested also, we've also been supported by innovation knowing session is my way has been key stakeholder in terms of development and requirements. And of course, we like we say we're participating in the computable key guidelines working groups, which have Google and the way we're developing was participating in the development of standards and distributable fire. guidelines basically then of course the team within our own company. So, I mean, there's a lot in terms of the fire system but I can just one minute show you exit a little bit. So this is what it looks like on the fire side of the background. And these are these are K plan like you said the program in DHS to then you have about a minute or two. Okay, okay. So, basically, if let me just slide floating meeting controls in. So you can look, for example, on the DHS to side if you look at a program it looks something like this right where you can add stages, for example, in this case you can add demographic details so on and so forth. Then in this case if you look at the same design on the fireside it's what's called K plan. So basically, each stage in the HHS to be like an activity. So this is a planned activity for the clients who for example this demographic details and other activities so this is what it looks like on the fireside. Then on the. On the Android side. This is what for example the system. So the device looked. So, for example, that's the device and basically the program is customizing the test tool. But that's what it looks like your program will support from the test tool. And into basically this entire customizations and DHS to. So you can enter whatever data section whatever it is that you're collecting in the field. So this, thanks for that. I think we're going to have to wrap up. Yeah, I think I'm done. So that's basically it in terms of the system that we've been working on in basically it builds on top of the DHS to fire that and we're developing and improving the documentation on these cases. Thank you, Bob. Excellent. Thanks. That was really, really fascinating. I mean, two things. I think, first of all, the, the work that's been done now on the resource mapping and moving moving beyond questionnaire questionnaire response to more than strongly typed mapping of resources. I think that's a huge advance. And it goes really interested to see what's going to happen with the CQL work and whether there can be any way of linking that with program rules and stuff in DHS to. But thanks for the presentation. And again, thanks. Thanks for being on time. Because everybody's been so disciplined, we've actually got, I think, five minutes to field one or two questions to any of the presenters before we get kicked out of here. I don't know how it goes. We'll be kicked out in five minutes. If we kicked out in six, seven, eight minutes, definitely we have another session starting here. So that's six, seven minutes. If anybody got a question they want to pose to the, to any one of the four presenters. Fire now. We fish from the chat. Just reading up. We have Richard Mitchell asking Ranga. That was interesting. They do you have it. You say you've set up three fire resources so far. How many more do you anticipate map. I mean, we are not using three fire resources we're using. Let me just look at the fire one organization location media episode of care patients. We have a question and response service request. One, two, three, four, five, six, seven, eight, eight fire resources. We use service request for the federal system. We use media because we have a fingerprint system. So we're using the media resource to store some, some, some cryptid based the fingerprint data for the clients. For an encounter when you enter facilities in episode of case or whatever in romance you get an episode of care. So it's seven eight resources and we're planning to use them. Does anybody have a question for one of the earlier Zen has I've just been working up through the chat. I'm sure we'll have them on the community of practice. If somebody wants to say something in the chat here we'll get it. Otherwise, what I will say you know we have the experts lounge tomorrow morning noon I think it is around interoperability and hopefully the presenters from this session, as well as as others will be available in there as well for any additional clarifications and discussions. I feel bad I rushed everybody along and we now have three minutes to go. Well, you had a question on the end of a process I think. Right. Yeah, yeah, I'm interested to know how. When is that going to happen and how has the preparation been and how do you see that going because the handover process is is always fraught with difficulty. Yeah, it's a long journey for this and over process and we are present in 85% as I said in the of the PhDs in booking FSO so the whole we are transferring the whole approach so I mean, the tool, of course, but also coaching processes. Data analyze. He learning, etc. So this is a long journey of two years, let's say, and it's not finished. The main difficulties is to try to to be sure that there is, of course, competencies in booking FSO but also and more organization for to receive this. There is an infrastructure that that can host come care instance and data and so on. So there is no really technical issue regarding that, but more organization of the agency that is hosting this platform and all the processes of coaching that we have developed. To be sure that the tool is well used, because we know that if there is no the whole approach and the whole process around the usage of the tool. There is no usage of the tool and can make a cross on the other so. Yes, this is a really complicated process but we are sure that we will keep a link with the DHS to this is a set. We are sure of that. We look forward to watching it. I'm sure the his WCA people are probably more familiar with that particular project. The DHS to implement missions typically we've tried to avoid this notion of of can turn key projects with a hand over because they are so far the difficulty. And tend to try to evolve, I guess the eventual system owners from the very, very beginnings of the system implementation and design, so that the transition is kind of less traumatic. It's good to hear that you have at least the technical parts of infrastructure support and like under control. That's a big one. I think I might have to wrap up so you can prepare the next presentations. Okay, so we have to wrap up here. Thanks very much. First of all to the presenters excellent presentations really interesting. Thanks a lot everybody for attending. And let's hope towards maybe we'll have a bigger interoperability webinar or something towards the end of the year we can have a little bit more time.