 Okay. Hello. Okay. Good. So yeah, welcome. So I'm Morten. I'm working for the integration team in Oslo. I've been leading that together with a guy called Bob Joyev. So today we're just going to talk a little bit about what we've been doing lately, a little bit about future developments and maybe get some feedback from you guys also. Yes, as I said, our team is relatively small. Most of you probably know Bob Joyev. He's been around for a long, long, long time. If you've ever done anything for a server, he's always been around there for a long time. I'm also leading that with him. And we have a full-time engineer called Claude, which some of you might have seen in the annual conference. And then we have a new guy called Yuan, who should just join us a few months back. And obviously we're also trying to use the Hisp network itself. And some of them are coming with their own expertise. For example, Sam, who's been working on the RapidPro before. He was very, very useful when we were doing that project. And Clifford was doing a lot of fire stuff. And I think these websites have been mentioned before, but I just want to put that link again. So these are kind of our main entry points for integration and the fire websites. And especially the fire website will be updated soon again. There have been quite a lot of new stuff happening there. So I'm going to go through a couple of new features coming in version 40. Well, when you upgrade to version 40, that's available for you. Again, those are a little bit more technical. So I will try to not go into too much technical details. But the first one I'm going to talk about is what we call the root API. So the root API, it's basically a proxy, right? So it allows you to reach out to other services. You can imagine reaching out to an ICD-11 service, for example, to get some terminology list. And you can do, if you have your own little gateway that you want to do some kind of working on the data and then get that back into DHS2 through your custom app, it will allow that. You can even talk to other DHS2 instances. So, for example, if you want to pull some organets from a different DHS2 instance, you can do that using this API directly in your app. So it does allow you to kind of have this kind of real-time connection to other systems. Yeah, so a little bit more technical details, but it will also tell you the user that initiated that call, right? So if you have a user called Morton or admin or system, that will be added to the request itself, which allows your service to then react to that. So, yeah. So I have a small demo of that, which I now just have to find the right. So this is just a very, very simple app that my colleague from his Vietnam helped me create. So it has, in this server already, there exists now a very simple route that goes out to a web service that will provide some data for us. It's not DHS2 in this case. It's a different service, but this is just like a showing of what you could do. So in this case, we will select, it doesn't get data on us, actually. We should rename that, but we're clicking fetch now. So this request, this data is not coming from DHS2 at all. And actually, it's coming from, I can maximize the window a little bit. It's actually coming from a small service I made in Python. Now, this is a very simple example. We're just getting some simple data, but I could also do a post and process some data, send it back. I could do a client lookup, for example, right? So if you want to talk to another system, say, we have this client there. You could do that, and then you can import that into your app. And then that's a very nice way of not being kind of tightly connected and having to duplicate a lot of data. So you can kind of allow you to search in other systems. So just to verify, as we'll see now, I can just show that. Anyways, it's a very simple route. And it's, if you want more details about this, we have documentation for it. There are also some slides I showed on Tuesday Talk, which are quite a bit more technical. And then you will see how to actually do that and how to create your own routes that you want to do. So the next one is called event hooks. So through the time, we had multiple versions of this in some way or another. If you've been around a long time, you know, we had RabbitMQ at some point. We even had Kafka. We had a few different versions of this exact thing. But this is kind of a re-implementation of that. This is something completely new that we have now in version 40. And it's not tied to a specific system itself. This is something that's happening internally. And then you define, you really want to send it yourself. So that could be a web hook. It could be a queue, a queueing system, like Apache Artemis or actually MQ. It could also be Kafka, if you want. That's also supported. And you could even put that directly into the console. So right now, we are supporting two types of events. And that's metadata, which is probably the one you will be using quite a lot. And it's a scheduler. So by having these two, this will allow you to know whenever an organic is created, updated, deleted, whenever a data element is updated, whenever a data set is updated, and so on. And you will get an event to that destination that you selected. It could be a small service or it could be a queue. And then you can act on that and you can react to that. And it is opt-in. So make sure that you do enable it if you want to work with it. I'm not even sure if this is the only apply-play service to be honest, but at least if you do it on your own, you can update your DHS conf. So yeah, so as I said, we have gone through a periodous period of transition. If you know anything about internal DHS2, you will know today we are using Artemis for this audit logging. That's going away, hopefully, and being replaced now with a system that is not tied to specific technology. Again, just some examples of what you can listen to. As I said, we have the scheduler and we have the metadata. You can listen to everything. So you create an event hook that just says metadata. You will get every single update to your metadata in the system. Or it can be more specific. In this case, organization unit. Or you can do data elements. Or you can do indicators or whatever you want to do. And that will allow you then to react just to those changes, right? You can imagine synchronizing organize from a system to another system. Then you just want to listen to the metadata. And you can, of course, create multiple event hooks also. So you can put specific use cases, maybe specific targets. So you can create many of them. So regarding a little bit of future plans for the event hook system, as I said, we do not support the aggregate and track it today. We are hoping to further increase support for this in version 41. Exactly how much and where we will do that, that's still being a little bit talked about. But I think especially for a tracker, this can be very, very useful. You can imagine creating a new patient. You can have another system react to that. You can update an enrollment, completing an enrollment, same with events, right? So it can be very, very useful that you have other system reacting to that. And it's been a much requested feature for a long time. And we are looking into actually adding more targets, but that we will do when we get the request for it. So whenever you, if you start using this, when you actually upgrade to version 40 and you see, oh, I wish I had this target or this target, maybe you want to talk to Elastic Search, for example, or you want to, in the database even, we are open to adding more targets. And it's actually not a huge job for us to add more to targets. So I also have a small demo of that. So in this case, I have two instances of this as two. So one is running on port 901 and one, one time 2002. And you see, they are both on the serial on database, so they kind of look the same. But in the background now, in this system, I have created an event hook that will send an notification about data element changes. And I have a small script that will take that information and then you'll post it back to this other system. So I will just create, I just do A because it's, then this will get on the top. So get the element and then selecting aggregate, that, you see that's on top here. And now it's already in the other system, right? So you can get real-time updates like that without any delays. You could, of course, also batch them so you can kind of put it in a queue when you get every 10 minutes, you can push that to the other system. But there are many ways of doing that. And this was done with a script that has 10 lines of code. I mean, it's just very, very simple, very, very easy to react to these kind of things. You could even go in and then we call it data element 123, save it, update data element 123 and the other system, right? So it really allows you to do a lot of things like that. In this case, it's DHS to DHS2, but that doesn't have to be the case, right? There could be any other system for that. And it's really, I think it's a really powerful feature that I really hope you guys will start using in the future. Again, if any feedback, anything, we are very, very open to that because it is a very new feature. Might even call it a little bit experimental, both this and the root API at this point, but we are very open for input and what works and what doesn't work. So a little bit about our current projects. There are always other projects also going on. I just want to highlight a few of them. We are creating a SDK for DHS2, a Java SDK that you can use in your own integration projects as long as you are Java. We are focusing on Java since we are basically a Java shop. So of course, we are free to use whatever you want in integration projects, but what we are using is Java. And we are also creating what's called a camel component. How many people have heard about Apache Camel? Probably not too many of them or less have heard about it. So it's basically an integration framework that allows you to do stuff like get some data from this system and then push it to another system, get some data, massage some data, even sending out some messages, telegram messages. It has components for all of those kind of things. And we have actually created our own component that we have put into that and it's now part of the official camel release. And that allows you again to very easily talk to DHS2. So just in one line, you can get some data from DHS2 and then you can do something with that. Get some organets. You know, similar to what I did in my demo before. But that's a real time, but maybe you would do this every night or something. You would do some other thing. And you could have schedules and all kinds of things. If you are interested in Java and integration, you can just search for Apache Camel and you will get a lot more information. We are also with the help from UNICEF, created by the pro connector, which allows you to send aggregate data and a few other things from DHS2 into DHS2. And also allow you to synchronize users from DHS2 into DHS2. Again, it's on our GitHub. There's a lot of documentation around it. So if that's something you're using in your country, I would welcome you to have a look at that. I think it will also be extended to Tracker in the future, although I'm not sure if we will do that or not. And the last one is something that, I believe it's happening in India. This is based on the API pro connector. So Johan, our new guided team, he's working on WhatsApp support for program states self-reporting. So that means a user can report their own data. And this is using the new WhatsApp, I think it's called business plan or something. It's a new API from WhatsApp that actually allows you to do this. So again, this will be merged into the main API pro connector story. And it's all open source and it's all freely available and documented. So if that's something that's interesting for you, please have a look. And this is just an overview of our stack. Again, we talked about this already, but it's kind of what we are currently using. And I'm not going to go into the details so much about that, but we are using, again, the common component Java, a queuing system, and spam all, and this is Spring Boot, this is also another Java framework. And we are doing a lot of testing also. So all of our integration projects now are more or less automatically tested, and they have been run automatically, like the business to itself is. So this is a new one. So we have been doing fire for a very long time. I think not a lot of people know that we have been doing that. I think maybe we got a little bit bad reputation sometimes when it comes to fire, but we have actually been doing fire for a long time. But there haven't been many projects for us to actually actively be involved in, because, you know, five years ago there wasn't that much fire in Asia or in Africa. It's something that's been coming up more and more, right? So we are starting to focus more and more on fire, and that's something that we will continue doing. How many know what fire is? I have a few slides about introduction to what it is. Okay. So there's a lot of text there. I'm not going to go through all of this text. You can have the slides later and have a look at it. But basically fire is a new standard, not so new anymore, actually, but it's a standard for exchange of health data, right? So it's JSON-based. Well, you can use XML, but most people use JSON. It has a restful API, so it has the same thing that you can do searches and filtering and so on. Fire is also supporting that. It has what's called a maturity model, which is kind of important. That means, I can show you that. I have it here. So this is kind of important when it comes to fire, is that they have a lot of resources, right? So for example, an organization or a location, right? And you can compare that to our organization units. But you see there's a number between, after all of this. And that just means the level of maturity. So it started zero, which is highly experimental. And it goes up to four. And then when four is done and they are okay with it, then it ends up being normative and it will not be changed again. So patient, one of the kind of the core resources of fire, of course, is normative and that will not change. So that's something you can use very, very freely. Again, not too much details. So I have a lot of text on these slides. So when you start kind of doing your own fire, right? Because fire can go back to this one. Fire itself is not of the box, not something you can use. It's in some ways very similar to DHS2 in that way. Like if you just start up an empty database of DHS2, what can you do? Nothing, right? So you start creating your organics, you start creating your data elements, your data sets. There's a whole process, right? And that process also exists in fire and they're calling it profiling. So you're kind of creating, say, you had, for example, the patient resource I showed you, what's required of that patient resource is nothing. You can send an empty patient with absolutely no properties and it's legal out of the box. So you have to go to a step called profiling. You say, for example, oh, I require a name. I want my patient to have a name. Okay, okay. Then you profile the patient and say name is required. Oh, but you also want data birth. Okay, you can add that. So that's very similar to DHS2 in that way because we have attributes that you can add to your entire entity, for example. And but here is a bit more formalized way of doing it. Other than that, they also have what's called extensions that I'd like you, for example, to take an example that we have in DHS2, we have some called attribute values for metadata, right? So like an organization unit might have additional data added to it. That's not a concept they have in fire. So we create an extension point for that to allow you to also have that in fire. And I will quickly show you our for that later. Yeah, I talked about this a little bit already, but yeah, it's basically customization of fire. And yeah, Bob won't want me to talk about this. I don't know how much I'm going to work the details. So logical models is basically how you start developing your fire profile. And I will show you some very simple examples of that. But it basically allows you to create a version of your model like DHS2 without thinking too much about fire itself. So for example, short name doesn't exist in fire, but using a logical model, I can still map that in without having to create extensions for it. So it's a very nice way. It's usually the starting point of creating a profile basically. And it's something I really recommend. If you're starting on fire, I would really recommend starting looking at logical models because that's everybody's using those these days. And it's actually very, very powerful tool. Again, profiling, again, that's coming after the logical models. And here you go and saying, oh, I will require this, I will require that. For example, our organization units has a property called level that doesn't exist in fire. So we create an extension for that. I added it to the profile. And now we can support levels. And for example, we have ID and code. Well, okay, but then we have to also add that to our profile. And I will show you that very soon. And again, the last step here is what's called an implementation guide. And so implementation guide, and I will show you how it looks. We can do this one. So this is ours. This is one we are making. This is very much work in progress. But this is not only the profile. As you can see, there's an entire website. And that website is built by some tooling that they have provided us. And using that, you can see we have now full overview of all the things we have defined in the system. It's not that much yet. We'll be a lot more later. But you will see that, for example, for our HIV package, we have patient sex at birth. And you will see here now, we have defined all the codes we require for our HIV programming dishes, too, as part of the Dolly Show metadata packages that we have created. And you will see we also have translations. So this is the implementation guide. And this is more of the profile. I promise not to show too much of Jason. So this is the actual profile part of it. But the website and everything around it, all the tooling, everything is called an implementation guide. So that's usually where you have all the documentation. You have all of this stuff cobbled together. And this is why it's this tooling around the fire is really, really, really great. I mean, that's one of the things that really brought us into the fire to start with, because we were kind of impressed by the tooling. And it allows us to really create good implementation guides. So that's something we will be looking at more. Let me just go back to my slides. Just a couple of very, very quick resources that we are using actively a lot. One of them is the code system. So that's basically option sets. So you can have these option sets are code systems, basically. And we have defined also our own version of that. And another one, a very typical one that a lot of people are using is called a questionnaire. So questionnaire is basically a form. It's kind of the simplest of the simplest way of doing it for fire, because it allows you to define a form, basically. You can imagine having a data set with aggregate data that you're collecting, saying, okay, for this input element, this is the boolean, this one is text, this one is an integer, and so on. Or maybe we were even pointing to a different code system. So you have a dropdown and with different values. And then when you have that defined, that's kind of the definition of the metadata if you want, then you have the questionnaire responses which you can compare to events or data value sets that you're sending data into the system. And then those are validated against each other. Again, this is a tool in the providers, Fish and Shushi, it's an interesting name. But it's basically a common, a new language they have created to kind of more easily create those implementation guides. I have a couple of links there. One is the official fish school, which is just kind of a series of tutorials you can go into. And they're quite useful if you've never used it before. They tell you how to install the tooling, how to do all of that kind of stuff. And you need a couple of things like Ruby and Java and everything. But it's all explained in those things. And I'm not going to go into that. This is what we are also using. So that's somebody's already. But one thing is that I want to just emphasize this. We have actually been working on fire for many years. Again, I don't know sure people know that. We have been working with OpenHAE to implement some of the profiles they created. One is MCSD, which is for organization units. The other one is SVCVM, which is the shared value sets, which are basically option sets. We have support for that. The repositories are still in our code, but the uptake has been, nobody is using it. So we also had the fire adapter, which has been adopted or adopted by a few companies. I think OpenHAE is using it. They're also using it in Zimbabwe, I believe. But from our side, this is now deprecated and end-of-life. Part of the problem with the other approach was that it was extremely generic to the point where it was kind of hard to use and hard to understand. It was a very nice engineering piece. It was very good in itself, but it got too generic in a way. So what we want to do now, we want to focus on specific use cases. So there are a few things we have started already. As I said, we have defined our organets and our option sets in a fire profile, kind of the building blocks of these as two. And Johan has been working on the HIV program. That's not done yet. It's a it's a work in progress. It will be for a long time. Another one we are also working with or will start working with is Sri Lanka on this role diabetes compass. That's been mentioned a few times already, I think, in the conference, so I'm not going to get into that. But that's something we are actively working on. We're hoping to also now start integrating with Indonesia in the new system, the fire system. So that was presented on day two, so maybe on Tuesday, so maybe not everybody was there. But it was basically a new fire system they had developed using Google Cloud. And now they want to take that last mile into DHS2 so they can do aggregate and dashboards and so on to visualize the data. So that's something we will be working on in the future. I also have been working with PAHO in Latin America on ASAVI and AFI. And again, this is using the approach we mentioned before, the questionnaire response. So they have defined a huge questionnaire. And now for DHS2, we are pulling out the data we require and we are creating a response to that that we are sending into their fire system. And then we have a connected account on coming up in Chile in January where they will be testing out and see how it works. The last one, almost the last one, the smart guidelines project is also something that we are involved in now more and more, especially Bob. They have kind of been changing through the years to be honest. So a smart guideline created two years ago or one year ago is not the same as they do today. But they have released a new one for measles, measles and immunization. And that's what we will focus on. We're kind of going to just focus on that. When the other guidelines are updated at the point, we will also look at implementing those. But for now, we will focus on one and kind of get a bit of experience around that. And then we will see the other ones later. But we will also be creating our own implementation guides, of course. And please, please, please, if you have any questions regarding fire, integration, especially fire, if you have any kind of country project up and coming, you need some help, you need some guidance, please reach out to us. We are actively looking for projects that we can get involved with fire to kind of broaden our own experience. So if there's something that's happening in your country, you know something that's up, maybe you have a question, maybe people ask you, does teachers who support fire, it's not a yes or no question necessarily. It's something that needs to be kind of explained in a different way. So please reach out to us if you have those kind of questions. We do also have a weekly Friday call. It's called an integration community call. Again, if you want to be part of that, if you want to be part of that calendar invite, just send us an email and we will add you to the list. So then you can join. Some weeks, we have a very short meeting, there's nothing, no topics. Other weeks, we will have a longer meeting where we have a specific topic that's been announced before. For example, we had, we had the people from, yeah, open the barriers. We had at least one, one Simon. We had a few, few other people also, but yeah, so from time to time, we will have some invited guests that represent kind of the system that they have been creating. And we are hoping to do that a lot more in the future. So a little bit about the roadmap. Yeah, I have 15 minutes left. So we are, this is done, some of this is done already. We have updated now most of our code to be using kind of the new releases of software as DHS2 has. We kind of run to the same level. We have also, how many people know what open API? A few, a few. So we have started now creating our own open API specification, which is auto-generated by the system itself. I just want to quickly show it off. It's very, very nice. As you see, there's a lot here. It's a bit overwhelming, but if you know what you're looking for, for example, oh, I want to create an organization unit. This is a good place to start. In this case, it's just a category, but if you, this is different, this is not the, for example, the internet isn't also the best, but yeah. So here you can see, in this case, we're creating an organization unit group, and you will see there's some example payloads and some talking about, you know, for example, this is all the strategies you can do with the importing. If it's a crate, create an update or just update or even delete, you can see that. And then, and there's also some examples, seriously, of how to create one. And you will see, this is a typical response. Or in this case, but that depends on what you're doing. So this is a very, very useful tool. I hope people will start looking into this. We are definitely going to start using it in the integration team. So that's, yeah, there's a link there, so please have a look if you want. The other thing is, of course, the two APIs I mentioned, event hook and the root API. We also want to integrate that into our SDK. Right now, that's just existing as its own API, but we want to make it easier for us to do that in the camel component itself. So we want to kind of integrate those things together in a bit better way. And then one of the things we have been talking about a lot, and this is not coming soon, to say the least. We are talking about one to two-year project. We want to create something more generic middleware. So we have been creating, you know, we have the Power Project, we have an ICD-11 extract, we have all of this kind of different software, but they all live in their own repositories separated. So there's not a one thing, right? So we're kind of reinventing the wheel a little bit every single time. But we want to go away from that model and create an actual DSH2 middleware that you can start up next to your DSH2 that will allow you to, we have some functionality built in, but it will also allow you to extend it and kind of continue on that. But again, very new. We are hoping to get something started at least next year, but it will take some while. And we will have some, we have some use cases for it already. So in the start, we'll probably focus on fire for quite a bit. But again, you will see. But it's something that's hoping. It's a little bit similar like OpenHim, but it's not OpenHim, okay? It's a very different kind of system. It's a very different kind of system. And there's also going to be a UI for it, which we kind of have to have, right? So it's user-friendly. Again, fire. These are done already, basically, which is great. We do want to look into generating questionnaires. As I said, those are kind of that form, but we should be able to auto-create those forms based on an existing dataset, for example. So you can just point to your DSH2, point to this dataset, and we'll get the questionnaire. Then you can give that questionnaire to somebody else, and they will create a response to it, and now you can import that into DSH2. So that allows people to use fire to also send data into us. And another thing is the IPS. So that's called the International Patient Summary. It's basically just abbreviated version of your health data, like for your own sex. So if you're traveling, for example, it can contain like your vaccine, reporting and everything like that, or any kind of medication you're taking and different kinds of hands. And then, yeah, again, more and more and more we're using this tooling to generate. Another thing that's kind of missing in DSH2, or at least it's not great, is identifiers. So of course we have the ID field, and we have the code field, and we have kind of attributes, but it's not really the greatest way to do stuff. So we are looking into working with the platform team to adding more functionality for adding additional identifiers. This is especially important if, for example, you are synchronizing your organization units, for example, right? So different systems will have different codes, most likely for the same organization. So you want to define your organization unit to have all of these codes, and you can do it kind of today, but it's not ideal the way it's implemented. And then the last one is terminologies. As you probably know, option sets and options are not the greatest model in the world. It's something we have to live with, but we are hoping to create another version of that in DSH2 that will support stuff like hierarchies and stuff like that, but at the same time we will convert them into option sets for actual visualization and so on. So that's what we'll do. We are also having academies. This is something very, very new for us. We had one in Rwanda in March. We are definitely having one next year also. We are actually looking into having one in Asia this time, but that will be announced on our website. So if you have developers in your team and so on that want to learn more about integration with practical examples, and it's more of a workshop than an academy really. So please reach out to us or just watch our website. It will be announced on the community of practice when it happens, and that will be decided probably by the end of this year. Hopefully we will decide the venue and the dates for that. So probably sometime after the summer, summer for us, or maybe September or something, August or September. You will see. Okay, so I have seven minutes left. So questions and then we are waiting for our time. Yeah, thanks Martin. Should we expect this webhook stuff available for data as well? Sorry? Should we expect webhook stuff available for data as well? Yes, yes, yes, yes. So we are really, really hoping to have in version 41 support for Tracker. That's kind of what I would say is what you have to do. How much of the Tracker that involves we would have to see. We can create 100 hooks inside the Tracker, or we can create, kind of focus on create, update, delete, and so on. But yeah, there's something that's definitely on the roadmap for 41, but we are kind of running out of time a little bit, so we have to assume, should we kind of decide on where to put all those things. Other than that, for also for aggregate data, it could also be interesting. So for example, when a data value is added to a data element, you maybe want to listen to that and react to that. This could also be interesting, for example, in cases where you want to update other systems. For example, if you want to put something in an elastic search or something, that you can just push that into that system. But yeah, that's definitely something we're looking at. And potentially, we could have hooks anywhere in the system. So that's up to you, guys, when you update the latest, you see, oh, and I really wish when I did this, in this just you, that there was an event hook going out somewhere and doing something. Send us a Jira request, future request. It's probably, as long as we can agree that it's a good idea, it's a very small implementation detail. And it's something we can do very, very quickly. Yeah, hold on. Two things. One is the route API. So I understand that you say we can call it from inside DHS to any external systems. So for their authentication and others. So how could we get this configuration so that we can, for example, for NID verification on any other external API, specifically, we had issues during the COVID. This is the first one. Second one is what Judge Jubair says, so I don't repeat that question. For other systems like, say, OpenSRP, the fire profiling, the world diabetes compass. So is that possible, is available to lower versions, say version 36 or 39? When there, that's, we could move to newer version. No, so for the coming up to fire, all of that support will be done outside of the DHS too. So we will be able to target N version, basically. There might be some API differences from version, say, 37 to 40. So you might have to do some adjustments. But if that's a request for somebody say, oh, this doesn't work with this API, we probably can make that work anyways. Because it's, a lot of the integration stuff you do is not in DHS too. So that's why we want to create this middleware. We have a service to start up alongside DHS too, and kind of communicate with DHS too. And maybe even have a UI inside DHS to configure that middleware and kind of do something. So yes, that should be possible. That should be possible. When it comes to authentication, I promise not to show Jason again, but we support multiple types of authentication. And this is all encrypted and stored locally. So this is great, because then when you do this stuff, this is very simple. Of course, but when you do this kind of request, the user who runs it is not allowed to see this. You can only run that route. And when he runs that route, all this authentication stuff is added automatically. And we also support API tokens for that. And you can add, I'm not sure if you have an example of that. But you can also add custom headers, complete custom headers that you can also add to the system. Yeah, that's definitely possible. Yeah. Okay, thank you. Okay, any other last questions for Morten? All right, big thank you to Morten for his presentation. Right, so the tea is ready outside. But just before we break for tea, one announcement. So those of you who have not collected your conference package, so the bag with the umbrella, the most important and everything else. So your conference package is ready at the registration desk. So you can go there and collect it. Right. So with that, I think we can break for tea and we'll meet again at 11. Thank you. Sri Lanka is ambitious, fun, fierce, fabulous, respirited, breathtaking, connecting, soaring, winning. Sri Lanka is fearless, curious, full of action, passion, fusion, fashion, vision. She means business. She is determination, timeless, full of kindness, luxurious, magical. Sri Lanka is art. Sri Lanka is crowd. Sri Lanka is heart. Sri Lanka is a feeling. She is healing, a love story, a lifetime story, a brand new story. Earth's favorite island is ready for you. So wild, so pure, so vibrant, so natural, so majestic. So Sri Lanka.