 So, thank you everyone for joining, I'm Mike Frost, I'm a senior advisor here at the University of Oslo responsible for product management around tracker. And very excited to talk to you today and actually listen more from some of the country examples about how they have set up their architecture around supporting the COVID-19 response and vaccine delivery. I'm just going to do a fairly brief intro to give you some insight into how we, from the platform perspective approach, the idea of architecture interoperability integration. The first thing to mention of course is that COVID-19 as you've heard throughout the conference has been, of course, a massive effort over the last year and a half. It's put a lot of strain on health systems and on health information systems. And we had many countries quickly adopt some of the COVID-19 packages that we published around contact tracing, test reporting, port of entry, and now of course the vaccine packages. And so we've also learned a lot during this time about what kinds of systems need to be linked together to support these efforts and have also learned some kind of new and innovative ways to connect such systems together. So we'll hear a bit from three different approaches. Marcus, who is the technical lead for tracker will talk to us a bit about Norway, which has used DHS to for the first time ever in their health system over this last year and a half. Then we'll hear from Rajabu from his Tanzania, who will talk to us about the efforts they've done there, and then Marie is from Rwanda. What I wanted to do first is share just a little bit of one of the kind of legal definitions around this concept of architecture at the global level when we're speaking with many of the digital health global groups. There's often an emphasis on what is called enterprise architecture. And this term is, you know, it's of some value to think about in terms of what does that mean for any given country. The reason I've highlighted the definition here is because what I think is really important is that we're talking about more than the technology. So connecting two systems on a technical level is one thing, but there's much more that goes into this concept of what your architecture should look like for health information systems. We are, you know, particularly interested in identifying what are the processes you're trying to support what are the decisions that you want to make with your data, where do those data live, who are the people that enter them who are the people that should analyze them. To stay out of this definition that you're seeing on the screen. Many countries, I think right now are focused on kind of points, two and three, in terms of they they know what information they want, and they focus on the technology. But maybe there's there's less emphasis that's placed on what is kind of the strategic side of this what are the transitional processes that need to be in place. And is there some larger overarching plan that the country is working towards in terms of having some comprehensive architecture. And, and I think that's fine because I also know from the literature that you know enterprise architecture as a concept really only succeeds about 10% of the time. There's a lot that must go into this in terms of planning and thinking, but these principles behind it and the ways of thinking about, you know, what systems are you trying to link and why I think are incredibly valuable. And I think that does lead to more successful integrations and we'll hear from some of those from from our country examples today. We here at the university have recently launched a dedicated webpage towards our approach for architecture and interoperability integration. I put the link here in the slides which are available on schedule for you to download if you haven't gone there previously. But for us we, we really have some key principles that we try to focus on when we're being asked to do interoperability and linking between systems. It's very important again not to be focused on the technology but look at the goals that you're trying to achieve, what would be the value to the users in terms of this data that you're trying to combine together. Think about the cost and benefits. It can be incredibly costly and and not ultimately result in something positive when you're doing an integration. And the idea is that rather than focusing on the software focus on how the date will be used. Key to I think all of this and in fact key to the reason why many countries use DHS to is that it can be done locally. So trying again to have an approach to collecting health information and linking health information systems together. One that can be supported and replicated and last in the country where it is being being used. We, the University of Oslo, try to engage in global collaboration and promote these principles and and try to develop tools to support you all with them. Of course, through things like this our conference but also in some of the international and global communities open HIE, which some of you may be involved with, and also IHE International. And we tried to again be an advocate for what we see as working in the countries that we are supporting and that are using DHS to and always are trying to learn more from these these different ways of setting up your DHS to infrastructure and linking it to others. I just wanted to highlight again some of the tools that we have focused on up to now to try to make these these efforts possible. These are again laid out in more detail through the website there's of course a lot of software documentation behind them but but we see first and foremost we have always put emphasis on having a very open and robust API. We want you to be able to to set out using the API tools, the kinds of queries and pulling of data like we work within the standards community so we have supported and help to get adopted the ADX data format for aggregate data exchange. We're building as you can see in the bottom of Python integration toolkit where you're going to see more and more tools supporting some of the other standards like HL7 fire, or those related to ICD 10, ICD 11. We also always have tried to promote a flexible data model that allows you to enter in the codes for other systems like SNOMED, MEDRA, etc. All of these things we know are difficult and integration interoperability are very different but we're constantly trying to find the best ways to support you and your countries and where they are. So I won't spend too much time on this there are more interoperability sessions that you'll see throughout the conference. Tomorrow we also have a plenary session where we'll discuss a bit more DHS to within kind of the framework of structure or ecosystem within the country. And I just wanted to put this out there as an introduction as you're looking at the different tools that these country implementations have used to create a robust COVID-19 system that also speaks to other systems in the country and makes use of those those connections. So with that, I think I will turn it over to Marcus as our first speaker talking to us about the Norwegian implementation. Thanks, Mike. Let me share my screen here. There, I think you can see my presentation. Yeah, so I'm Marcus. Marcus, right now I think we see everything except your presentation. You see your Slack screen, we see a schedule. Alright, we're about out. Yes, much better. Alright, thanks. Yeah, so I'm Marcus Becken. I'm the tracker team leads at the UIO. And in the last Yeah, a little bit over a year we have been involved from the university in the Norwegian COVID, COVID response. I managed to invite a friend. Helge is also on the chat there, so maybe Simone, if you could make him a cause so he can unmute and correct me if there is anything. Or anything he wants to comment. Sure, what's his name? His name is Helge. He's working with one of the main partners that's doing COVID surveillance in Norway. Okay. In Norway, this contact tracers is not a very common sight. And when we got COVID, there was a responsibility that had to be taken very seriously. And that we had very little knowledge about in Norway and very little traditional history for contact tracing. Contact tracing would be something that you would do in very desperate situations where you would have a very rare condition that you needed to trace, for example, an HIV infection, a known HIV infection. And sometimes there would be a TB case, but those are so rare here in Norway that it's almost something that you never do. And suddenly all the 360 municipalities in Norway had to make teams for contact tracing. And everyone was running. In Norway, every municipality has an enormous amount of self-governance and there isn't such a thing as a national solution for almost anything. The municipalities will make their own or buy their own solutions from third parties or build their own. In Norway, we ended up with three main separate solutions for COVID response for contact tracing. Oslo in the capital, they built their own. They have a custom system that was entirely built for this purpose. There is another system that is called the RAMIN. They started with the DHS to core, but they did a lot of customizations on top and wrapped APIs and built a custom UI. But they started with DHS and they were using cores of DHS. At least they have been using DHS. And then the solution I'm going to focus most on and the solution that Helga in the chat works for is CoS fix. And this is a standard DHS to running with a tracker capture app fork. But otherwise it's, there's no customizations apart from configuration. So for the rest of this presentation, I'm going to talk about the other contact tracing solutions, which will then cover Oslo and the other RAMIN solution that we don't have so close ties to. And I will be speaking about this from the perspective of the CoS fix instance. So in this instance, the architecture from the beginning has been evolving very much and it started up as an initiative from just two of the municipalities to reach out directly to the URL and started working with the metadata package for COVID. That had been just made and translated into Norwegian. Then CoS fix picked up this work and hosted a minimum viable products for index and contact tracing. So they started out with a very bare minimum and have been expanding into other use cases and some expansions to better support the existing use cases for the contact tracing. So in the Norwegian COVID response, I'm going to go through the architecture here now and talk about the different solutions as they were built on. And it was really, it really started out with just a very simple bare minimum and we built on or CoS built on more and more on this framework. So we start with our contact tracer here and there was two tracker programs that was created for index and contact tracing. This was two standard tracker programs and there were relations between the indexes and contacts. There was dashboards and indicators and everything that you would know from a standard DHS contact tracing scenario. And what CoS did was that they already had a platform over here that most of the Norwegian municipalities had access to. So in this platform, they had several APIs, which is the box at the bottom here with the ring, and they had solutions for other things that the municipalities needed. And they had a user management tool and everything that would be needed for a municipality to start using and creating their tracker team user, for example. So what CoS did was to put the DHS to installation on this already existing platform and they would get user management and use some sort of user buy-in from the very beginning. And it is up to each individual municipality, as I mentioned, whether or not they want to use this tool and there was around half of the Norwegian municipalities uses this solution. The first thing we had to do and build with them was that this OpenID Connect support. And there has been some support for this before. But when these contact tracers were going to log into the system, they would need to use a third-party provider, which is called the HealthID or HealthID. However, there was an OpenID Connect support that was expanded to be better with the DHS to. And the fruits of this labor can be harvested in 236 and you can now use OpenID Connect in most cases because of the work that was done here back in 234. And these contact tracers would log in using their already existing HealthID to the system. Now the next thing that was built was the civil registry and lookup. And this was to make it faster to work in the system. Now, Martin, for some reason, you've just muted yourself. Oh, sorry. There's a scary button on my Jabra that I seem to have touched. So thanks for letting me know. So the civil registry lookup was the first thing that was built after the very first bare minimum of the index and contact tracing programs. And this is a lookup that was done into the civil registry in Norway to make it much faster to deliver or register indexes and contacts. And we were playing with the idea of putting all the contacts and index or all the population into the database upfront, but we weren't able to do it like that. So this index and contacts programs are doing a lookup based on based on need while registering. And this is what the tracker capture was first forked for to be able to do this lookup with a button right inside tracker capture. And the next thing that was built was the vaccine lookup and sorry the lab DB lookup the lab DB was was built as an API in in the KS platform and the contact tracers could make a lookup into the lab DB to find the lab results directly in the tracker. The next part that was built on was the self registration of contacts, the contact tracers were using a lot of time and calling indexes and asking about their contacts. And this was not easy to transfer over the phone. There was spelling mistakes and it took a lot of time. So there was there was built a citizen portal where the citizen could log in with their with their ID and register their own contacts. So an index would log in and register their contacts and this these contacts were pushed to the to the contact program in DHS using the standard standard standard APIs for for adding tracked and instances and events. We built a program for cluster management, which is sort of a grouping that these contact tracers could use to to cluster indexes and contacts together. This was another program in the DHS instance. On the side, the public health institute FHI in Norway had built a notification web application that required every index case to be registered in this application as well. And so even if the contact tracers had a digital digital system they would have to enter data into the notification web portal. And they were doing a lot of double entry for this for this notifications. Therefore, the data already entered in the index was we co has built another API to be able to send the data directly from this index program and into the notification database at FHI, which was tremendously well received that contact tracers that that were used to adding data twice. Another feature that was built by the Bureau of the central Bureau of security in Norway was the point of entry web application where the another kind of user point of entry agent will be able to log in and see all the people traveling into the country into their municipality. And these agents had a bit of a new job as well. This is not something that has been done very often in Norway and there was a lot of pension police officers and this kind of thing that would would now pick up the role of following up the people that comes into the municipality and checking that they're doing their quarantine, for example, as they're supposed to. But they had their own web tool on the very side of well with their own login at the central Bureau, but just last week cause built a API for retrieving this data and also a tracker program to to work with the point of entry data. And now this point of entry agents can use DHS and follow up the point of entry cases, whereas the contact tracers will also see the point of entry data when when it's useful. Can point out at this stage that, of course, this is one DHS instance that contains all this data. And we of course made sure that there's only one track entry instance across contact index and point of entry. So, in theory, one track entry instance might be enrolled into the contact program. He might become an index, and then he would have an enrollment in both those programs. And if he had any points were entered and entered the Norwegian borders, he would also be in the port of entry program over here. So these contract tracers now have a pretty nice picture of the of the persons and their movements. The other contact tracing solutions also are using the architecture that is set up by by cause. All these four boxes at the bottom here are API's that is used by the DHS to system, but they are also used by the other contact tracing solutions, for example for notifications sending notifications, or retrieving lab data or interior also receiving data from the civil registry. They would also be able to connect to this API for point of entry. And I think there is plans for at least some of them to connect to this this API that was built. I also put vaccines at the bottom here and I added that right before representation right before I started so it shouldn't have shown up until now. I was going to mention that the vaccine data database is also being accessed through this API's probably starting next week. So the contact tracers and agents can see vaccine data through the same the same system. I already mentioned here at the end the self registration that I talked about was a custom solution built by cause and they were simply putting data in through the users API. There was also some work ongoing with the Norwegian citizen health portal called Helsen Norge. They were working on a self registration form that didn't end up being finished but still worth mentioning because we were working then on the fire standard to melt the Helsen Norge sending data on the fire standard. It wasn't a great implementation of the fire standard to be honest they were using the message type and more or less transferring the forms without really mapping them to the fire resources for health data but still these messages was following the message part of the fire standard. Helge if you're able to unmute you can maybe comment if there is something I forgot or that you want to expand on. No, if not I will just continue. There was one crux that was apparent I want to mention here at the very end that that probably is going to be a problem for many instances and I want to mention it because we're working on the solution on the software side and there we came up with a workaround on the on the COSFIX project as well. What of course happens when when indexes are asked to self register their contacts and these are directly into the system is that there will be a lot of duplicates. In a class for example if you send ask all the three indexes in that class to register their contacts then you know that most of the children in the class is going to be registered three times. The same problem can arise through the point of entry where the point of entry is a different system that is run on the border. And they're sending the data into DHS and at the point where this data is being pushed into the DHS API here. The person the track and instance might already be existing in the system and the point of entry would be pushing in a duplicate. So for this there was a specific duplicate program that was built and this API down here will make sure that for this job that will push the data into DHS will make sure that that the duplicate. Well, it will make a search into the system and see whether the person being inserted probably exists or not. And it will decide whether to create a new person or add data to an existing one or whether to ask the user and create a possible duplicate in a different program. And then these possible duplicates would have to be handled by the by the contact tracers and port of entry agents manually. The same strategy workaround will be built in the self registration program, the self registration portal where these possible duplicates will end up in a duplicate program and a contact tracer or point of agent point of entry agent would be selecting whether they want to merge the duplicate or whether they want to create a new person from the possible duplicates. I want to mention this because we are working on the application and the application now in the 236, 237 release and we're working on the services that will allow this to happen more seamlessly in the DHS system and does not have to be built as a separate job on the outside to check for these duplicates before inserting. And that is however my last slide so thanks everyone and I will hand it over now to I don't remember is it Maurice next. No, it will be a raw job from Tanzania, but thank you Marcus and again just to point out there's a link in the chats where you can ask questions that would be preserved in our community practice. We'll answer questions not only during the session but we can continue afterwards. And just one one thing to mention about the Norwegian experience we often are asked as we're entering a new country about is DHS to used in Norway. We're very glad to be able to say yes it is and we're also very glad to report that it's just as challenging to do health information system architecture properly in Norway as it is anywhere else. Hopefully you you've got the sense from Marcus's diagram there that this is not some beautiful elegant, easy to implement solution in Norway, any more than it would be anywhere else. These are complicated issues, connecting to all the correct systems and having a, you know, a sensible sensible workflow is challenging. And it was, I think, good for us to be closely involved in this implementation here. It's been helpful to learn from that as well. And again, the duplicates issue that Marcus mentions is something will help us to push forward in the coming releases. Anyway, thank you Marcus. So I think, Rajab from Tanzania we're going to ask you to be sharing your screen and presenting next. Hello. I'm Rajab. I think you can see me from his Tanzania. I'm one of system developer also involved in truck implementation specifically on COVID monitoring supporting the Minister of Health of Tanzania. So I will be sharing my screen. I hope you can see my screen. I think you are seeing the zoom. So right away to my presentation. You can see my screen, I hope. Yes, we can see your slides now. Yes, yes, yeah. So basically, I want to talk a little bit on digital health. My use case is more focusing on the work that has been done or is actually being being done in Tanzania on copying or solving some of the COVID implementations. So basically, from our side, I can give a little bit of a background. Since when the COVID broke out in March, where, when our country as much the same as other country actually watched it to sort of follow the WTO travel restrictions and at that point the travel bands, international borders were closed. But soon after our late president sort of opened the borders and more like allowed some of the travelers to come in or out of our country. So at that time, it was really necessary for the country to more like ensure that despite the movement of people, the country actually controls the outbreak. Through that, so the government implemented a sort of mechanism to make sure all travelers are being tested and given certificates so that when they are going out or coming in the country, they can be verified. At that point, by then the testing or the sample that travelers has to be tested, they are being collected at one place, which is National Public Health Laboratory, located in one of the major cities in Tanzania. So at that point, there were a little bit of more challenges, including long queues, travelers were waiting at the National Lab to more like take samples to more like be tested. Also, they actually have to go back and get back again to the National Lab to collect their certificate when they're ready. So it was a little bit of a challenge when it comes to more like ensuring that travelers are given a right certificate. But also that actually brought about an emergency or a problem of a forged certificate. So in a way, there was no a little bit of clear or best way to verify, you know, the certificate of whether this person is negative or not. So that was another problem. And again, as you know, in our country or in this African country, these testings have to be paid for in order to more like pay for those instruments that are used before testing and etc. So as well, also payment was a little bit of a challenge for that travelers has to stay and to use a lot of time in the National Lab actually paying for testing fees all together with taking some point collecting certificates. So that his Tanzania in collaboration with me, University of Jerusalem also as because we are supporting the Minister of Health, collaboratively we thought of no more like coming up with why to more like ensuring or simplify this process or more like minimizing the challenges that had had had been seen through these COVID testing operation. So this is a sort of what we kind of came up about with the Ministry and the idea was we have to find a way for more like to minimize the movement of travelers. So travelers were actually have to book for COVID-19 testing and because the testing had been being paid for we had to find a way or a solution of how best we can actually perform payment and then how best we can collect. So as I said earlier the collection of samples were done at one place but now because travelers may actually come from different areas across the country. So that we sort of try to find a solution where these samples can be collected in information about the sample can be transferred into that central center which is National Lab and of course the sample themselves can be transported there. Also now again as in the flow we sort of tried to find a way where the testing can be done and resulting in documented within the system and also the certification process now can come about where the validity certificate can be issued to travelers so that to cap that issue of forged the certificate. But also as much as the certificate out we also had to find a way of more like for immigration officers or port of entry officers to more like verify those provided certificates. So in this way what we came about is sort of a system that is more like developed under the National HIS platform which is based on DHS2 which we call Pima COVID application. So the application more like is covering the workflow or the flow of when the traveler wants to book for a testing so a person would actually have to go to a public portal using a tablet PC or mobile application and actually book for a COVID test. So essentially we were able to make sure that travelers from across the country at least can book for a COVID test anywhere or at any point they are and then more like for the book to date they can actually go to the facility for testing. But before that they had to do a little bit of payment as I said earlier this test is supposed to be paid. So in that we also actually had to figure out a way of connecting these payment processes with other payment systems around the country so as to seamlessly simplify the process of payment. So essentially as in the flow will talk a little more on the payment later in the flow a person has to actually book for a COVID-19 test and then will be sent a message either SMS or email. Then from the email it will be information for details for payment so a traveler will actually go to pay for the test and then when the payment confirmation comes in the traveler will actually go to the testing site where the samples will be collected. I said now simply because we have introduced the system now the testing site where a little bit extended to 64 as opposed to what before was just one testing site that was National Laboratory so travelers actually goes to those testing site and take samples and of course those samples will be transported to National Laboratory for testing. The reason is that the government of Tanzania wants to centralize all the testing testing for COVID-19 in one place so that the information that is given out is actually reliable and the government is sure of the results. So essentially after the traveler has been tested in many cases the traveler would actually have to wait for test results to be ready and essentially a traveler will be sent with another more like email notification bearing the link to traveler certificate provided the traveler is negative. So a traveler can actually receive an email or SMS in that manner and on the SMS he or she will actually download the certificate which the certificate will be shown at the POE or at the immigration officers when the traveler is actually going out of the country. So essentially this whole process also covers the part where the samples are collected so the lab managers are able to more like register the sample details for a traveler into the system which then when the results comes out the lab managers also can more like register the results and once the results are registered automatically the email or the notification will be sent to travelers. Of course for travelers that are a little bit or that are not negative in a way probably they are positive or there may be something in their tests. Usually they are sent with also messages telling them to more like repeated testing some other time so that to confirm whether they are really positive or there is something wrong with the test. So a major strength of this workflow was that now because we are looking of best way to cover the payment scheme as I highlighted earlier there are many ways in our country for payments. So there is mobile payments, there is bank payments, etc. So we actually have to figure out a way to more like connect with other payment system around. Fortunately our country has what we call government electronic payment gateway which is GPG where the system actually offers to integrate with any other system to smoothly tackle on the problems for payment. So this is how it works is actually our system is sending a sort of a request to acquire sort of invoices or we could call them bill to the GPG. GPG automatically sends the bill information to our system we send the bill information to a traveler. A traveler goes to a financial station whether as I said mobile payment or bank or online and pay and automatically the bank already connected with this GPG system actually responds to GPG system and then also GPG system responds back to to our system and then we and there we know exactly this person has paid. So this has simplified a lot as when the traveler goes to a sample collection is quite easier for sample collector to know that this person has already paid for a test and the sample are being collected and the rest are actually going forward. Now this probably may be sample of notifications. I just wanted to give you a two minute warning just on timing but yeah. Oh OK. All right. Yeah sure. So basically these are a quick of a few not notifications that basically are given out for payment for payment confirmation or also for validity certificate because of time I think this is my last last slide. Basically as I said earlier this overall Pima COVID is built upon or sentry using DHS to so actually what we have done we have a little bit of some other modules like public portal where travelers will actually have to book for for COVID for COVID test also the that is where also they can print or they can view their certificates. But in the middle is sort of actually have sort of adaptor we call them mediator where they are public portal actually connects to DHS to sending information as creating in this case drug entity instance which we call booking and then also we have sort of GPG adapter which actually communicates with that payment gateway system and also the adapter also update the DHS to system actually in ensuring that payments are made. Also the DHS to within the DHS to system we had to actually construct custom applications were booking managers lab managers can more like interact in actually entering the results etc. Also just to finalize a little bit. There is also part of accountants as we said this system is linked with payment systems so accountants actually have to in any way in any case verify some bit of payments information within the system so there's sort of a payment reconciliation whereby for the details that we have received it from GPG and the details that accountants have for banking they can more like compare automatically within the system and actually bring about some of their reports which actually to them make sense in terms of verifying the payments. So basically as I said earlier this system has helped a lot the government to more like realize a little bit of many aspects for example we have largely reduced the turnaround time for COVID-19 testing at least 24 hours before it was more than 72 but also that helps also a government to decentralize the sample collection centers as I said earlier because we have a system now. Also as what is a major strength now the more like the government actually has seen or have a confidence of now through this innovation to be able to more like coming up with more use cases for example there is this implementation that is coming along now which is called the aphioms theory which is actually focusing on actually those passengers that are the people COVID was based on those which who wants to go out there of the country so based on this the government has a confidence that they can actually coming up with a aphioms theory platform also around the HS2 with all these interconnection across the system in that case. I think because of time probably this is my last slide. Thank you for listening. Also asante sana I actually may have to transfer my screen to I think is the from brand. Yes, I think can take over but asante sana. Thank you at Roger. That was great. There's at least one question for you in the chat if you feel like typing there. And I think that was a great example of what I was talking about about about considering kind of all of the different actors and what their information is a really strong example. And yeah, thank you. So Maurice, I think we're ready for you now from Rwanda if you're able to share your screen. All right, let me let me try to share my screen. Are you able to view my screen now. Yes. All right. Thank you. Hello everyone. My name is Maurice and my software developer at his brand and I'm very interested and happy to to present in this session about innovative. Texture to support COVID-19 response. At his brand. We have enabled the DHS to information exchange with other health information systems and throughout this period of COVID-19. We have had great experiences and we're about to share with you all about this. We did all this with the aim to facilitate and promote the data quality and data use to provide timely evidence based decisions. We also aimed at improving the availability of data and utilization of data in healthcare sector. You will see in the the following slides that we have used different materials including laptops and tablets which had all the tries to installed in them. These are the systems that I would be focusing on and on the upper part you will see different apps that his brand has created that also use DHS to API and on the lower part you will see the API as sometimes we were we made the challenges where we are supposed to build a custom API to help other institutions access DHS to data. For example, you will see the Percentage Alapaketa form, you will see self registration form which actually works somehow like the Norway version of it. You will see online portal and different mobile applications that has helped very much the public to to manage this COVID pandemic. Before I deep dive into the systems, we also have a look of the summarized the system flow of the of our instance. We have a DHS to patients registration and clinical diagnostic where we do manual data entry or also people can actually register without leaving their homes using online registration. Upon registration, people receive their SMS and emails telling them about the unique IDs that they will be using every time they need any services regarding COVID-19. Sample is received at the lab, they test it and after the results are available, someone receives another SMS telling them about the results status and also inviting them or encouraging them to check the results are online and generate their certificate. On the current status, we have a country wide system implementation, both Android and web version over 2000 active users, country wide and over 500 tablets and 200 smartphones in use right now. We have both web and Android and system updates are provided and continued support to the users throughout the country. Talking about the different systems, I will begin with self registration, which actually will show you the general someone from registration to getting the COVID certificate. This idea came when there were long queues on the testing sites where like thousands of people will queue to the testing sites just to be entered into the system. Then the system has been it's an online portal where people can come. I think someone can help me admit people because. Yes, don't worry, we're letting them in. All right, thank you. And during this process, this someone can enter the personal information, demographic information that the payment option actually now people don't have to carry cash to the sites where they're going to be tested. They have also an option to choose their payment option and pay online without leaving their houses. We're going to see how the system works. There's a there's a part there's a part where someone can enter their national ID. Then with the national ID, we can contact the national identification agency, get someone's information without manual internal data. Then someone can also input their demographic and the location and the person is taken to the payment page on upon the payment page. You can choose either to pay by the card. Also, we understand that not everyone has a visa or master card option or mobile money. Some people actually will struggle and prefer to pay back cash. This is still an option but people here in Rwanda they love online payments and this system has helped them a lot to fast forward this process. We had challenges implementing this system where people have wrong information. And when we compare to the DHIS2 tracker and the information they gave us, sometimes it's not correct. And some people don't have access to smartphones and sometimes high traffic will cause DHIS2 or DPO which was our online payments service provider. Sometimes it will fail, which it was not often but whenever they fail, we receive a few calls about the people not being able to register. There's a... Just a time warning. I would love to listen to you forever, but I know there's another session after this. We have about two minutes. I'm going to talk more about the online portal. The online portal basically what it does, it helps people to come and check their results online. Then when their results are available, they can generate certificate and also present the certificate anywhere. And this is the interfaces you can see. This is the view of... I can be a tablet or a phone. You see your test profile and different results that you've taken. And also you can generate certificate to present anywhere, airport or any venue. More to that, we have also with main challenges that actually are the same as the previous ones. And to fast forward, I'd like to talk about the certificate app scanner, which also is used at the airport and sometimes at any venues where people can come and present their certificate. Our QR code is encrypted, which is the reason why we have made a custom QR scan app to be used at those venues. There is a passenger locator form, which is used by... it's like a self-registration for the people coming to the country. It has also online payment or payment at the arrival. The challenges we had was that you could not validate someone's profile until they arrive at the airport. That was the challenge, and we worked so hard to mitigate this challenge by helping the people, by actually checking someone's information, whether they have registered before, the HIS2 or not. I think the last point, we had a hotel's dashboard. This was a challenge because people who come into the hotels forget to take their results and actually stay more days in the hotels. Now the hotels can actually view whether someone's results are available, then go in their rooms, tell them to check and generate their certificate to leave the hotel. We had also in regional electronic cargo and driver tracking systems where if someone's coming from Kenya, they don't have to register again. We can process their tests and update the system across the region. The last point, which was actually interesting. We didn't know this would work. It was helping the HIS2 to interpret between sporting events. We've had pro-basket last year and we had the basketball African League this year. We have their system also checking the fans or the spectators along them to enter the stadiums. It was difficult to know how and when someone has taken the certificate. I'll be happy to answer. I think the time is on my side, but this was an interesting topic and I would be happy to answer how we carried out this helping the NBA and their teams to help them get their people in their stadiums and it was really a successful implementation. This is the next steps where we want to develop an RBC, a random and medical center application, which is going to have all the systems including starting with COVID related systems. We have finished making a universal API where other institutions can connect to the HIS2 through that API. This one has been developed already and the last one is under development and it's 70% done. These are the systems and solutions we have done during this period and we thank you for your support, the HIS2 core team and other HIS2 implementers and we couldn't wait to present to you what we have done so far. Thank you so much. Thank you so much, Maurice. We'll have to end the session there. The links are there in the chat if you want to ask any additional questions. I think these three have been really great examples of kind of how complex these integrations can be and the types of tools that can be used to connect various different systems. I think there are just three of many of the countries using the HIS2 for COVID that could have presented here. There's been a lot of great innovation and really interesting approaches to this over the last year and a half. So I really thank our presenters for those of you that attended. Again, if you have more questions, please put them in the community of practice. We're happy to follow up. And with that, I think we have to end so the next session can start. So thank you so much everyone.