 Thanks everyone and welcome to the team integration or the team in the realty track of the annual conference. So I'm not going to be speaking too much today. We have a couple of co presenters from the show and from the marriage in Uganda. See, yeah. So this is basically the split of today. There is an expert launch from four o'clock and going on until maybe five. Probably we will spend some of the time also for the panel depending on the needs and how much time we require. Other than that, it's a little bit of background on DGS2 and the integration team. As I said, this is how we talk about the goal data integration that they were doing with DGS2 and UPC. And then they will talk about how they integrated ICD-11 service into DGS2. So the team isn't big. It's currently just consists of Bob Jollif and me and none of us is working 100% on it. So we are both part-time involved in this, although we are hoping to grow and hire more people. We have weekly calls every week. You can join those calls if you really have something you want to discuss with us in person. Or we also have this monthly open HIE calls that you're also free to join. A bit more about that on the next slides. And if you have any kind of questions regarding DGS2 and inter-building in general, feel free to shoot our question to integration at dgs2.org. And we will get back to you quickly. So part of what we have been doing in the last few months is gradually getting involved in open HIE community again. Because we haven't really been much involved in the last few years, although we have joined some calls from time to time. So we have restarted, one might say, the involvement in the open HIE HMIS group, the health management information system group. That means we have a monthly call now talking about HMIS in general, although it's very much DGS2 centric for now. Although it doesn't have to be necessarily, but for now it definitely is. Topics that would be stuff like ADX and aggregate data exchange. We also seem to kind of, from time to time, also lean into organic exchange and option set exchange and all this kind of other stuff that's kind of related to it. And the other one we have been started also regularly joining is the facility restricting calls, MFL if you want, and this kind of basically organics stuff, right? And we're also getting involved in some emerging standards like MCSD, SVCM and ADX and a little bit more about that on the next slide. So it has been kind of hard for us to kind of know, seeing that we are a very, very small team, we have kind of tried to figure out exactly where our focus should be. So for now we are kind of narrowed it down to, so within the open HIE we are narrowed it down to using what we call the MCSD and SVCM. So MCSD is basically taking a couple of resources from FHIR, so FHIR is a standard for doing health and interability, right? But it's a very, very big standard and it's not kind of something you can just take out of the box. You kind of need to profile it or kind of take the pieces that you want from it. And one of those profiles is called MCSD, which is basically taking a couple of resources called the location and organization and a few others, and kind of allowing us to exchange organization units from DHS2 to into say for example a happy fire server or also taking happy fire resources from a happy fire service and putting it into DHS2 using a common format. And then SVCM is the same when it comes to option sets or any kind of grouped items or codelists. It doesn't have to be option sets necessarily, it can also be categories, category options, even organization groups and group sets that can also be a codelist. So any kind of codelist really that we want to get out of DHS2 and kind of exchange with a different system. And we have started a bit of work on a Python based tool to kind of help us with doing all this exchange. So that is not done yet. We have done some progress on that and hopefully in a couple of weeks, we will have something that's actually working. So the starting, the first release will support pulling out MCSD and also SVCM from DHS2 and then putting it into, first of all, a happy fire server or some kind of fire service. Hopefully we will also support taking data out of a fire service and then putting it back into DHS2 and then we can have this kind of full circle integration with that. So as I said, that is not done yet. It will be announced on the CRP when it's actually ready. And then hopefully people can try it out. The reason for using Python for this, I just want to mention that it's basically because it is very much a default when it comes to the kind of ETL exchange and it's also installed by default on Ubuntu and all kind of services or Linux distributions. So even Fedora and everything will have that installed by default. So you don't actually have to install a bunch of other packages to make that work. In the long term, you kind of want to expand on that and you want to create something that's called fire profiles or invitation guides. So what that basically means is that, so fire is a very generic standard in many ways in the same way as DHS2 is. So while there is a patient resource in fire, by default, nothing is required. So you only have to say it's a resource type is patient and that's it. That's already a fire compliant patient. So normally what you want to do then is kind of profile that and so you would say, okay, we also require the name, you have the date of birth, maybe the location, maybe the organization is linked to and so on. So those things are something that has to be done to kind of profile fire. Now this is quite a tedious work and probably you already have something in DHS2 that's called a patient. So you probably have a track entity already called patient that you're already added say you have some some type of the attributes for example you have the male female, maybe you have the date of birth, the name of course and so on and so on and so on. And then, then you need to so many of mapping that out of DHS2 and into fire basically. Now, this is not something that can be done 100% fully automatic for sure, but we are hoping to kind of expand on this tool so you can kind of point that tool into your DHS2 metadata. So for this program, I want to actually, as much as possible, generate a fire profile out of it. Now, again, this is just a starting point. And we are also hoping to kind of start with the WHO metadata packages. So hopefully in the future, all of the WHO packages will include some kind of fire profile linked to them. So yeah, so basically this tool will be output FSH, which is the fire short-term, and then you will compile it down to the fire profiles. Just a little bit about the ADX stuff Bob has been doing. So, I think you have to hurry up a little bit, but so basically Bob has been working on codifying some of these aggregate packages that we have for the COVID. There are some issues there and they kind of trying to not standardize the codes. So I don't think they're using any kind of global standard right now, but they're kind of making their own standardized codes for now. And so I sure Bob can talk more about that in the panel discussions if anyone want to have a bit more details around it. So that's something that's being worked on. It's been working for a few months. I think that's nearing completion at least. But so yeah, that's something that's also coming soon as part of the metadata packages that we have here. I think that's, that's, it's not time for panel, sorry, the final panel comes after. I think given that it's already 10 past, I think it's time to move over to Sarah. I just want to say that so we will now have 15 minutes we started talking about the goal data integration. It will be, then we will have the Daniel, we talk about ICD 11 integration and then there will be a panel and a question and answer session. So feel free to already now start thinking about topics for that session. If you have anything you want to talk about. There might be standards within the duration that might be just a general dishes to problem or some other insights you have. So please think about that while we're waiting for Sarah Sarah and then they all to go through the presentations. Thank you. Sarah, you can. Great. Thank you. Can you hear me okay. Okay, good. I will just share my screen. Okay, hope you guys can see my screen just fine. Good morning, good afternoon, good evening everyone it's really great to be here again at the DHS to annual conference and see some familiar faces or rather hear familiar voices. This continues to be a really important forum for us for shared learnings across organizations in context so thanks a lot for having us. Today, I will briefly be sharing some of our experiences in building an interoperability solution between the go data tool and DHS to my name is Sarah Hollis and I'm an epidemiologist within the health emergencies program at W I Joe. And today I'm joined by Peter Javonovic and Pablo Rodriguez, who are at the Polytechnic University of Catalonia, and they've been very instrumental and collaborating with us on this work during the COVID-19 response. Today, we don't have much time so I'll do a really quick overview of go data to get everyone oriented, and how the need for this project really came about. And then for the majority of the presentation I'll pass it off to Peter and Pablo, who are the real technical wizards of this and they will go through a more detailed technical description and demo the solution if we have time hopefully, and mainly to get feedback from the group and I'm glad we have the expert lounge after this so we can really hear your thoughts, as this is definitely a work in progress. And in addition, hopefully hearing from countries on who would like to pilot this and your own setting as we're kind of at the point now where we're looking to pilot this and in a country. Right Sarah if I can interrupt for a second. Yeah, update your display settings to the mirror selection right now you can see both recurrent and next slide in our screen. This is at the top under display settings display settings swap. Got it. Okay, is that good now. Yes, that's perfect. Good. Okay, sorry. Um, so yeah for those of you who are not yet familiar go data as an outbreak investigation tool designed and deployed among Gorn partners, global outbreak alert and response network, and coordinated by WHL, and it's made free for use by by member states by countries and institutions. And the tool and its final form today builds on previous WHO and Gorn partner experience in field data collection, particularly during outbreaks. It's worth noting and this relates to the theme of our discussion today, that this tool is not trying to be all things to all people and instead we've tried to keep a pretty well defined scope, focusing primarily on cases and contact related data and an outbreak sitting to inform contact tracing operations, and particularly in building and viewing chains of transmission. So here I'll just quickly give you a snapshot of what I mean. The platform enables the ability to view relationships between entities, whether they be cases events clusters contacts, and various ways to get to really spot patterns and space and time. We're also consolidating data across case investigation forms, contact listings, follow ups and other related longitudinal data such as labs and hospitalizations to try to track the journey of a contact or case over over their follow up or incubation period to allow the surveillance staff to really understand where they need to intervene on a practical level. So in terms of just a few high level key features that might be important to note for framing before we get into the interoperability solution. So this tool is meant to be configurable across settings and outbreaks. It can function offline online. We have an optional web app that functions or sorry mobile app that functions on Android and iOS. And granular user roles and permissions so that different users within the contact tracing workforce or public health surveillance system can perform different actions or access different types of data. So for instance, a field epi would be entering in case investigation details on the web app, while contact tracer would perhaps be performing daily follow ups on their mobile phone and then these would be interacting to produce the chain of transmission. Another thing important to note that is in this relates to to what she just introduced was sort of the standards that we've tried to integrate with this platform so we have defined templates for for different diseases COVID-19 being one of them that aligns with WHO guidance and also we've created ones for particular protocols such as the FFX protocol or the Unity studies so that countries can quickly deploy these protocols or just the core WHO variables quickly and easily to get going. So, in terms of data exchange with other platforms so so it's not a surprise us that there are other systems in countries being used for for surveillance already. And especially during for for COVID-19. So we we've really built this tool to inherently be flexible to to be able to interact with these other systems for either one way or two way data, data exchange. And there's a few ways that you could do this we do have extensive data important export features that are primarily file based. You could also connect through a MongoDB connector, but most of what we'll talk about and what we've explored so far would be through our API. This is a bit of a busy slide but I'll just set the stage before passing it off to Peter, but we, we've had multiple requests from countries since the COVID-19 outbreak started that they they wanted to be able to utilize go data perhaps for contact tracing but they were already using DHS to for their their event based surveillance and they wanted a way to exchange data between the two. We also want to find a way to be able to push summaries of what's being captured and go data to the existing national health information system oftentimes DHS to and countries where we're working. So, at this point I'll pass it off to Petra to kind of take it away with the more technical details. Okay. Thank you, Sarah. And hello everyone. My name is Petra, I'm from the University of Catalonia. And we are working with with WTO for many years now what generally on project of like chocolate disease but this project is specific to the COVID response. Do you see my screen. Yeah, we said. So as Sarah said, so when the when the COVID crisis started also multiple countries started requesting this interoperability solution between go data the tool that they are supposed to use for contact tracing and their national health information system. And on the other side at UPC we also started the COVID 19 project that is funded by by our UPC fund humanitarian humanitarian fund. And at that point we form like a collaborative project between go data team at WTO and also UPC. And the main goal of the project is these two enabling one internet interoperability layer between go data and national health information system in the country. As an example we took PGS to as it is the most present in the company in the underdeveloped and developing countries. And so that the countries eventually can strengthen their their systems, especially in the times of this is outbreaks and to contact track the contact tracing and analyze transmission chains. Why at the same time being able to have the overview of the COVID 19 situation in their national health information systems like the HS to. So, since since it's an emergency project, we were applying very, very strong agile project development. So, we had and this was the overall goal that I mentioned before but we had to go step by step and then we started started by allowing first go data and be just to to exchange, for example location metadata in terms of organization units, and also the main essential information on the cases between these two instances. And then with having this, let's say, first step implemented we started expanding incrementally to allow other kinds of information to exchange between the systems, like contacts contacts, follow ups lab results and also the relationships inside the systems. So, as I said, so this is an agile project so we started started developing piece by piece and with this we the first result that we obtained was highly configured configurable and also for now stand alone in an interoperability layer, which is basically set up of scripts based on react framework, and this this interpret on interoperability layer is is able to perform different exchange tasks that I previously mentioned. So, the, the main point is that, first, for the default configuration, we use the DHS to COVID-19 packages. But since, of course, many countries could adopt this, could take this DHS to original DHS to COVID-19 packages and adapt to their needs are customized to their needs, or the needs of their countries, we also enable configuration of the scripts so that they can adapt in terms of in terms of new variables and in terms of differences between the variables. But of course, this kind of setting for now requires more technical oriented personnel that will administrate this configuration and also to run the scripts. So, that's why the high the final objective of the project actually is to produce a DHS to application. So, incorporating these functionalities inside the DHS to application that will connect. So, connect to the GoData API and push data from DHS to GoData. So, in order to, so the countries that, for example, started collecting data in the DHS to they can push to GoData and continue contact tracing and then visualize, visualize contact, contact tracing, or also to get pull data from GoData to DHS to and in that sense, for example, they would prefer to collect some data from GoData to inside the DHS to either individual or aggregated data. So that their national health information systems, they have already have the situation at the country. So, this for sure will be a much user friendlier approach. So with the interface that most of the countries, especially in Africa are used to like DHS to familiar with the DHS environment so it will be easier learning curve for them to to start using this kind of functionalities inter-probability functionalities. And before I pass the slides to Pablo to show you a demo of our inter-probability layer, I would just like to go through some key takeaways. So first, as Sarah mentioned, GoData is meant to be an outbreak investigation tool. So it has a very specific purpose, unlike, I mean, other general health information systems. And the point of this project is to enable inter-probability between GoData and other surveillance systems of the countries, and especially we started by DHS to, as I said, as a most used system. The project is, the project development is agile and mostly due to the emergency requests by the countries and by WHO. So we are, that's why I mentioned we are enabling part by part of inter-probability with a final goal of building a DHS2 app with complete inter-probability functionalities between GoData. And as a final mention, I would like to invite all the countries that are in the presentation to contact us if they have similar kind of requests or similar kind of problems. And we can discuss and see how to exchange COVID-19 metadata they are using and to see how to adapt configuration of our inter-probability layer to their needs and start providing them with this inter-probability layer for them. So you have a contact email here, but after the demo I will also mention other contact information from all of us. So thank you very much. I will pass now to Pablo Rodriguez. He's also from Technical University of Catalonia. He was working on the development of this inter-probability layer. Hi everyone, can you hear me? Yes, yes. Okay, so I'm going to share my screen now. Okay, can you see my screen? Yes, yes. Nice. So hi everyone, I'm Pablo Rodriguez, as Petar said, a developer now in the University, in the Polytechnical University of Catalonia. And I've been working on this solution where you're building to provide inter-operability now mainly from DHS2 to GoData. So as Petar said, we are now in a stage of the project where we are focusing mainly on technical aspects, not that much on providing a usable app that the countries can work with, like the ones that you can provide in DHS2. So what I'm going to do is give you a small demo of what the scripts that we have developed do right now. So I'm working with the demo version of DHS2 for COVID-19 and for GoData I'm using version 33 installed in my own computer. So what we have for now is a series of different steps we can follow to send to GoData organization units, which are called locations, in GoData cases, contacts, and the creation of outbreaks, which is, well, let's say, a structure GoData uses that is not like that on DHS2. So what I'm going to do is execute these different steps for you. So we'll start by copying the organization units into an external file that you can see here, like output.json. This is because right now we have a problem with the identifiers of the organization units that we need to keep in both DHS2 and GoData. So the only way we can do that right now is by copying them into an external file and importing them in the application. This is only for the organization units, but it's nice to know. So with this, now we can go to the GoData application, which, as I said, I'm drawing this in my computer as you can see here. This is a clean installation of the GoData project, so there's nothing as you can see, no locations, no outbreaks, no nothing. So the first thing we're going to do is import our hierarchical structure of the organization units that we created right now from the scripts. Pablo? Yeah? You have two minutes left, just so you know. Yeah, yeah, yeah, this is going to be really, really quick. Thanks. So here we have our organization copy. Again, I'm using the demo version of COVID-19 from training land from the demo version of DHS2. And now we can continue by copying the other structures we can work with right now with this, which are firstly, the outbreaks. This is highly configurable and this can be adapted to create outbreaks for every organization unit or, which is the main case, one outbreak just for the entire hierarchical structure. So you can see all this information in the main page of the project. Now we can copy the cases. Once this is done, I can quickly show you just the result in the beta. This is now a development oriented version, so we are not focusing right now pretty much on the efficiency of the transmission and we are repeating some requests to the APIs just for doing this alpha version of the scripts. And lastly, I can copy information about the contacts and relationships. Yeah, that's all. So, if we, well, I have to log in again because I'm using the same user and password for this. Yeah, that would be all we have right now. As you can see here, we have now all of our cases copied and contacts and relationships. Yeah, so that's all I'm going to pass now the presentation to Petar, which is going to wrap up this. Okay, thank you Pablo. Thank you very much for showing. So as Pablo said, so this is the profanity that we have so far. So far it's a set of scripts that we can run and communicate between two APIs. The only issue we have is the video organization links, but this is for issue on the API definitions of themselves. So I would just like to end with just sharing with you information on how to contact us and web pages where you can see more information about the project itself. So here you have the web page of the project. You have contact information on the site of GoData and WHO with contact persons are colleagues. And then on the UPC side and the Team Research Group, I will be the contact person. Also, you can visit our GitHub page where we are commenting the code that is being developed. So that will be all from us. I will pass now the presentation and then you can continue and later discuss, I don't know if we discuss now or the questions or after the session is over. Let's do the questions after the time is over. Okay, I see that someone already has a question. So Dan, if you can continue. Thank you. Yeah, I bring your greetings from colleagues, Minister of Health in Uganda, as well as the WHO team that worked with us under the National Identification Regulator Authority. Are we sharing with you experiences we have had for integrating ICD-11 in the HIS-2? In the whole background, we are now estimated at 34 million people with a total fertility rate of 5.4 and a crude death rate of 6.4 per thousand. So currently we have an estimated 281,000 deaths in the community. But in the EHMIS we are recording 34,000. And the Regulator Authority is only able, at least for the last financial year, they registered and issued best certificates for 5,700. And so you can see we have a very big need to up our game in terms of mortality data capture as well as utilization. Then, by all background, we see that we've had a few opportunities that we have that can be used to rapidly roll out ICD-11. First of all, in the constitution is a right for all deaths to be registered. And so the government enacted an act of parliament that created the National Identification Regulator Authority to be responsible for all Syriac-Yes activities. We have had a history of introduction of startup mortality list but this didn't move far. We also have had a history of phobotopsy and ICD-10 in a number of projects, as well as we have had a number of our staff trained in ICD-11. And it's some very experienced across the community in phobotopsy, mainly through partners that have DHSs and also those ones that are doing a number of studies. The area that is rather advanced is the area of maternal and perinatal death reviews, where we have almost all health facilities able to do this work, but also students support. In looking at our status, we identified a number of challenges that impeded rollout of ICD-9 and 10 previously. And these are mainly around the fact that those ones were involved with their small research projects that usually did not proceed beyond their end time. And then also the engagement administrator at the time was limited and not aligned. And so coding of deaths was not aligned with its main priorities. We also didn't have enough local expertise or a scale up. And of course, as you know, previously ICD-10, we had these large books that often were costly and from a practical point of view were not very easy to use. And we did a reflection bringing on board a number of partners, both at the Ministry of Health, the National ID, National Regulatory Authority for Identification, and then the Uganda Bureau of Statistics. We acknowledge that we have variable experience with ICD-10, but none with 11. And a number of training institutions actually were still using ICD-9, particularly in the pathology departments when they are doing forced maintenance. And then the CRBS task force was present, but it needed to be strengthened. We also noted that the National Identification Regulatory Authority had different tools from those ones we are using at Ministry of Health to capture beds, both for notification and also the certification of cause of death. And then, as I mentioned earlier, we had a number of people who had been trained and so we use this as an opportunity to identify master trainers. And then in the beginning we had planned to start with the startup mortality list, but this app could not be run on the version of DHIS2. So we moved on to upgrade our DHIS2 and then the startup mortality app was integrated. A medical certificate of cause of death, which was based on the WHO International Certificate of Cause of Death, it was a point ahead and did standardization of tools between Nira and ourselves. And now this focus to the point of integration of ICD-11 into the DHIS2 and our electronic medical records. This happened at the time when the WHO had announced at the World Health Assembly for international rollout of ICD-11. So in terms of process, we conducted a requirements analysis for integration of ICD-11 API into the DHIS2 instance. And this informed the plan for software integration and the coding tool. Then we went on to integrate the module and this included the embedded coding tool into the national DHIS2 instance. And of course now this provides a smart search functionality accessible within the application. We went ahead to conduct a testing both offsite for the prototype and later on with the feedback that we got from the medical experts. We now conducted onsite piloting of the software and at seven IHS facilities. This now has been fine tuned into the DHIS2 and we are now at a process at the step of moving it from the testing environment to the production environment. When you access the DHIS2 and you go to the applications interface and click there, you're able to see all the applications and we have put it there as with an ICD-11 icon. And so this is where you would access the form. And when you do access the form, you will create the case as is normally the process. And what is unique about the data that you see is that we now have put a field for national identification number. And once we have completed the integration of the APIs between DHIS2 and the national identification register, you would for example just insert the national identification number of the deceased. And it will populate all the details that you need on this page, except of course for whether they were teachers and so forth if they have changed position that may be different. Also, we are able to, when you put the gender of the person, it will produce a dialogue box that will ask you, to make sure that you complete the, in the second part of the form, whether it was a maternal death or not. But also if you insert the date of birth and the age of the deceased comes to under one year, it will ask you to fill the part that is for infant deaths. So the good thing now with ICD-11 is that the embedded coding tool is provided smart search function. And once you insert the search term, it will give you a number of dropdowns rather than from which you can select the code and the cause of death. As contrary to just having a simple dropdown list. And you can see on the bottom right that this is just a preferred case that would appear like this. And you can see that the difference here we have included the field for cause of death free text. In case we do not have the phrase in the existing, the search term in the existing ICD-11 database. And so that means that we have arranged to have these new terms captured in the background so that we can continue to update our local search terms. Then of course at the extreme right, you have the time based on how the cascade of events happen. So would like now to show you just a brief example of how this works. So this is a certain linear old woman who procured, who had an induced abortion and died from septic shock and had a perforated uterus. So I'll go now through a brief demo and then we'll see how this works. So here we have preferred before this session would have the case number there. And then we'll have the national identification number. And what I wanted to show you about if, for example, this one was female. And once you put female then to give you that dialogue box up to show you that please remember to fill the section for women. This is while pregnant within six weeks of delivery. That is something that we added that we thought is very good. So for this particular case she had a septic shock. And so this would give you a drop down. And then, of course, for those of you familiar with the coding, you can see the button here with a plus that we are will require for mandatory post coordination, but I won't go into that for now. And so this lady. So the amount of time was in days she had spent 11 days with this. And then previously she had had induced abortion and a paraphernalia uterus. So we put paraphernalia. Sorry, in a bit. Yes, so we have the injury of the uterus. And she had had it was 16 days before she died. And then she had induced abortion that led to that led to the infection and so forth. So, so now we included a field which you don't find on the usual international form state the underlying cause of death. And you can see it brings you one of the rules that note that any values whose code begins with any injuries research cannot be used as a code of death. For the cause of death for this particular case, as you can see with this code. So briefly, this is just to take you through how the coding tool has been embedded within the form. And this is the kind of experience that we have. So I will now take you back to the rest of the presentation. Yeah, so. So basically we have some early lessons. We have for the facilities that the regional for us because where we have done the piloting. We have noted that there's a reduction need for paper forms, because if a clinician has been taking care of a client and she passes on they can straight away summarize the case and then go into the system and do this coding. We also have seen that we have done a number of training of trainers and we have been able to reduce the training to three days. And of course this comes with reductions in cost. The training is simplified, especially because of the standardization within that ICD 11, as well as the embedded smart search that enables us to have a high level of accuracy. We actually in the testing of the training participants we saw a high level of coding accuracy among other trainees, especially where we had also included our local. Diagnostic terms. And then of course now standardization of underlying cause of death is much easier, and we think that we'll see less errors in coding going forward. What you see on the right side of the slide is just an example from one of the regional for us that started to use this. Basically you can be able to access data has and when you need it. This is just one of those examples. In terms of our next steps, our major focus now is one to complete the integration between the DHS to and the national identification register so that we can have easy access to data on the details around the death from the national ID system. But also for the national identification register to be able to access the underlying cause of death so that they can be able to issue the certificates as is mandated by law. And then of course the next step now is to be a working on cast preparing for to do the cascade training supported by both colleagues in division of health information at Minister of Health, Nira and support from a World Health Organization. So thank you very much briefly that is what I hope to share with you. Thank you. Okay. Thanks so much. So yeah, so I think we have about five minutes left of the official time. And as I said, after that we will continue with the expert launch using the same zoom. The recording will stop and maybe the group will be a bit smaller. So, I think if anyone has any questions relating to the, to the topics we had so far, please come with them now. We will also go through the the CEP and see if there's any more questions there. Then maybe after, after the official and we can also continue with general questions if we have when it comes to interability. So, so Sarah and the team. There's a couple of. So I see already I reply to Sarah, but I don't know if you want to also do it on the call. So they'll be part of this about the gold data. Sorry, can you say that question again. I think you just, sorry, I'm just looking at the interability Q&A and I think you just reply to steal you but Yes, yes. No, I'm happy to reiterate if it's all. So, yeah, so the go data tool was built actually several years ago in response to two countries saying that they needed an easily deployable and free to use outbreak investigation tool that was really focused on contact tracing. But it has evolved quite a bit. So after its extensive use in North Kibu in the last double outbreak, and then now the during COVID-19. And so we are very focused on creating an environment and infrastructure where we can we can provide as much documentation about our API for any tool to interact with any organization, any platform. We had a repeated request about DHS to in particular we we were working with UPC on on this project, given that they had expertise in working with DHS to in the past, and had approached us with this idea. But, but no we it's not necessarily specific to DHS to we want to provide generic sort of interoperability support and vision and then any tool that needs to communicate with the platform we hope to be able to. To provide the resources that are that are needed to make that happen. Thanks Sarah. Maybe Dan, maybe you can elaborate a little bit about how are you making the request from your DHS to app and then into the ICD 11 service. Are you do you know that you are using a proxy or using course request or how are you actually interacting and doing the searches on the ICD 11 service. That could be interesting. I think we have Simon on the call Simon would you be able to respond because he was involved in the development. Simon. My mic can't be muted. We can hear you Simon. Yes, hello. Yes, I had the question. Oh yes. Okay, thank you. So right now. The way the way the application runs is that the API is extolled on the server that hosts is going to be. API is hosted on the same server that is running that demo. And so the requests are done from within the same environment so there's no actual cross domain referencing. And that also helps in accelerating the response responses between the call and the actual response itself. Okay. Thanks. Thanks. Yeah. More nice is another question from the community practice about it and interoperability whether that's available. I assume that's ICD 10. Yeah, so the only integration I know that when it comes to ICD 10 and we just do is that we have an option set. I know Nick is on the line but I know there is exists some semi official ICD 10 11 option set. I do not think the ICD 11 service supports ICD 10 but feel free to correct me if I'm wrong. I think that's ICD 11 only. I don't know if anyone knows the details of that. Maybe Simon, if you've worked with the ICD 11 service, do you know if that's also supporting ICD 10 or is it purely ICD 11. Well, to the best of my knowledge is ICD 11. Yeah. So, so there is, and I know there is an ICD 10 option set floating around I think it's also on our play the demo servers. So that that would be play these as to dot org slash demo. There should be an ICD 10 option set that you can actually download and use. I do not know if that's being updated and or who really manage it that but that's the closest as I know. I don't know if anyone has any more details before that. I think Robert has has details but he's been chatting in the group chat. Doesn't seem to be able to unmute himself. Max, I don't know. Can you, can you. Yes, you're going to take care of that now. Yeah, but thank you. So so the API can also do ICD 10 coding. But of course you don't have the, the wealth and the, the, the capacity of the coding engine that is behind the API of the ICD 11 side. And the other thing is that that one please should bear in mind that of course we we are helping countries to migrate to ICD 11. So it would be better not not to use this but in principle it's possible. I don't know if Chan is online. He's the IT expert who can give even more detail to this. Otherwise, we will need to do this offline. No, he's not there. And then that is Chan there. Chan will join at four o'clock. So there maybe we can defer this exactly to his presence. But the main point there is also that that it will be important to help countries to move to ICD 11, because the search, search functionality. Also, you can access 10 through the API. This is much more powerful. I'll stop here back to you. Thanks.