 Hello, my name is Ivo. I'm working on the back end and the tracker team. And I'm going to start with a small presentation on the tracker back end and its changes. And then I think I'm going to hand over to Joachim or Eric for going through the front end part and the things that changed there. Let me share. Yes. So this is going to be fairly quick. You can interrupt me anytime. And yeah, I'll try to answer your question. So we're just mainly looking at the tracker back end and kind of the news. So the DHS2 release of version 42 is around the corner or still a bit still is going to be released. But an important thing for people using the tracker API is if you have been using the tracker API, hopefully, by now you have noticed that a group of APIs has been deprecated for some time already. And that in version 36, we released new endpoints replacing those deprecated ones. So these are out for quite some time. I'm not sure maybe someone correct me. At least three years, I would say. So yeah, they have been out. And so you can read about the changes in the docs more in detail. And there's also a migration guide. So if you have any custom apps or any scripts or so on that talk to the tracker APIs directly, then make sure to migrate. Yeah. And I just wanted to show briefly some of the changes. I mean, again, the details you can look up in the documentation. And if there's something missing, please let us know via the community of practice or maybe on GitHub. And also if you have some experience doing the migration yourself and there's something we can improve. Then let us know so we can help the next one doing the migration. I don't know if there is a question. Oh, OK. Yeah. So the main change, I would say, is before you had these different endpoints for importing, you could import track entity instances and enrollments and events with this one endpoint. But there were also the separate ones for enrollment events to import and update and delete any of these entities. But now they are all being replaced by this one endpoint. So if you want to import any of these objects, you would just use this one endpoint. And this also allows you to update and delete. And most of the functionality should remain the same. So I think the main changes are naming. You can see that we dropped the instances. So now our language and our code should just use like track entities, enrollments, events, and so on. So this is one of the changes. And then if you compare the payloads that you sent us, you also see these changes, obviously, in the payload. So there are some name changes that are also documented in the docs. So on the left, you would see the deprecated payload that you might already be used to. And then the near one on the other side. And yeah, these are the main changes. With export, I think it's fairly similar. So again, instances has dropped. And the new exporter endpoints, the get ones, they're just under slash API tracker. And before, they were just under slash API. But there's still one endpoint per entity you want to retrieve. And yeah, there's some renaming on the query parameters. And then obviously the fields in the response that you get. But this is also all documented in here with the changes in field names. And then there is also a list of request parameters that might have been renamed or replaced. So you can read up on that. And then obviously, if you would compare like a diff between what you get when fetching from the deprecated and the new endpoint, you would see that there are some name changes in the fields that are documented in the docs. So yeah, don't worry. That's just change in order, I believe. Yeah, I think that is mainly it unless is there any question? Anything in particular that you would like to hear? Yeah, just for the participants, if you have a question, you can type it in the chat because we have unmuting disabled for now. So until the end of the presentations, we'll do it through chat first. But there's no questions so far. I don't know if you're speaking, but. Oh, sorry, Eric, do you want to go next? I'll go next for your finished video. Yeah, sure. Let me get the screen shared. All right, hopefully we can see this. So yeah, I'm Joachim. I'm working on the tracker front end team. And I'm just going to say a few words before Eric dives into the exciting part there. So the capture up is, yeah, as some of you may know, the old tracker capture up has been coexisting with the new capture up for quite a while now. But now we're apparently at that point where we are deprecating the old one. So from verse and 41, you should be able to just use the new app. And there should be a way to do or accomplish the task you did in the old app in the new one. So if you find anything that is missing, please let us know. But yeah, I'll just mention a couple of things before Eric dives into plugins. Firstly, if you are familiar with the old app, we've got more granular deep linking now. So if you, for example, or you can, for example, link directly to an event in an enrollment in a tracker program, so if I, for example, take this link, just paste it in the new tab, we will open the event in view event mode. But you can also, there's also a way to open it in edit mode. So I'll just use the same tab, open it. Yeah, and then you have the event in edit mode. And you can, for example, also if you look at this one, you can see that we have a working list open, where we are showing tracked entities that have enrollment start and work for follow ups. So we can take this URL and put it in a new tab and it will open the working list directly. So the working list is the follow up pair. Yeah, so I think it's more granular and better than in the old app if you're familiar with that one. There was one more thing I wanted to mention. Yeah, we also got in the old app, you have this verbose logging for program rules. And this is something that many people have been asking about. So we re-added that a while ago. So you should still be able to see the program rules evaluation if that is something that you are interested in. So the way you do it is that you add the verbose through to the URL. So if I run this one, I'll clear this one here. And refresh. Then you will see the program rule evaluation in the console. So if you're interested in that, then we still have that. All right, that was basically what I was going to show. So I'll leave the floor to you, Eric, for the plug-ins. Great. So there is a lot of new and great stuff in the new version of Tracker. Of course, now, since this is a developer forum, we're only focusing on the things that we really think is relevant to your developers. And some of the things that you can mention is that. But also, the thing that I'm going to go through I think is super relevant for US developers. And you can briefly mention it, but it's called plugins. And from our point, our tracker side, we're really focusing on the different types of tracker plug-ins. So I'll go through what are the different plug-ins. How do you configure them and set them up? And also, I'll go through with you an instance to show how everything of this works. And I can just start by sharing my screen. And I can go into the instance here. So this is the new Capture App. Welcome to the Capture App. This is in an instance that I've set up myself. And this is an instance that can kind of work as like a playground and sandbox for you as well to test out the plug-in stuff. Just to explain the basics around it is that we on the tracker team, or we at the HS2 in general, know that all our core apps and all the things that we develop is only going to take you this far. It's only going to cover hopefully in 1995, 99% of all use cases. But in the last cases, there's always going to be things that you want to customize. There's always going to be things that can be very country-specific, that it's basically impossible for us to do generic. Everything we do needs to work in a facility level, both here and there. And everything needs to be super generic. So from a project, Samwise, and the release of V41, we've tried to tackle this in a completely different way than what we've done before. We know that a lot of people have forked the tracker capture app just to get some simple modifications here and there. And that is, of course, to some degree fine. But as you'll see, that when the other systems in the HS2 matures, then it's really hard to keep up with all the things that is also continued developing on the tracker capture app. So what we hope to do in capture and also all of the other core apps or some of the other core apps is that we're trying to build this thing called plugins. And what plugins is that you can still use the R regular core apps, but we give you entry points here and there where you can inject your own code and inject your own logic and functionality. And from there, you don't need to do any kind of modifications on the core app itself. And once you install a newer version of the core app, everything will be sort of compatible out of the box. You wouldn't have to keep this neural and GitHub repository and keep this up with the master version all the time. We know that that takes a lot of resources and a lot of energy. So in this instance, I'll just show you quickly that if you go to the app management app and you go to the capture version, you can see that I've installed the newest one. Plugins was secretly released some while ago. But if you install the newest one or use the one that's bundled with the V41 bundle, then you should be able to use plugins out of the box. So from the tracker point of view, we basically have two different types of plugins. And I'll show you the first one now. And if I just select the program and org unit, this is the serial on the database and click Create New Person, you will see the first type of plugin here. This type of plugin is what we call the form field plugin. It's basically a plugin where you can inject your own code into the basic forms that we use in the capture app. And from there, you can do a lot of exciting things. And all the implementation and all the logic is up to you. You decide everything. All we do is that we try to define what your variables are. We'll go a little bit into that later. But from your definition of what you need for this plugin, we'll give you everything you need to interact with the form. So if I just try to do this, this is a very simple setup of how a civil registry will look. So a civil registry is typically would input some sort of social security number or an ID or something. And from there, it would go to an external database and fetch some data. So what we can do here is just input a dummy that says a social security number and click Search. From there, this would actually fetch some information from an external API. So this is just a random user API. If I click something else, it would fetch a completely different name and gender. And this is all configurable and all this granularity is totally up to you. And this is just an example of how it looks like. And this is typically how we would picture form field plugins being used. Of course, we're only developers and we don't know all these cases. So we're very excited to see what you can build of this. To show a little bit how it works under the hood, I can click to show the plugin details under here. And this is just basically printing out all the things that is provided from the app itself. And you can see here that if I define that I need the metadata of first name and last name and gender, then we will try to provide this to you in the plugin itself. And from here, you can read all the metadata the capture uses to print out the form and basically use the form. So in this setup, I've defined it to send in the first name, the last name, and also the gender. And these are the three different tract entity attributes you can see down here. You can also see that under gender, we will also send in the option set and all the options that you need to do any custom logic and configuration. You can also see that we send in the different form values. So you can see that the first name here matches the first name over here if I change this to something. You can see that it also updates over here. This basically is for every type of tract entity or every type of attribute that you can put in. As you can probably understand, we also send in the address and warnings. We also try to put in if the form has been attempted to save or not. If I remove something that makes the form invalid, you would see that the save attempted is now true. We also pass in a couple of callbacks so you can interact with the form. And that is what I'm doing here to simulate that we're fetching some data from an API. And you can basically set the value and you can set the value with some type of attribute. You can set it with a warning. You can set whatever you want to do. And you can also set things around the context of the enrollment itself. So you can set the enrollment date. You can set incident date or occur that date. And you can also set coordinates and whatever. I can press the set coordinates here, which is just a button that I made. Then you can see that it's now filled in with the appropriate coordinates. So I'll just start over just to show you what the base flow would be. We would search for a patient. We would find and configure this to fill in the form. We just set the occur that date. And I can click save person. And from here, you're navigated to what we call the enrollment dashboard. And this dashboard here is where you basically interact with an enrollment within a track and today. So this is the enrollment that this Vaninderpai person has in the child program. From here, you can see all the different stages and everything. And this should look and feel pretty much the same as every other capture program. And also it should have some similarity to the old track and capture. You can also see that there's some things that are configured here. One of the main things about this dashboard is that everything is configurable. All the different widgets that you see here are configurable. You can set this up as whatever way you want it basically. That's on a program metadata level. So if you're a program maintainer, then you can set up how the dashboard wants to look. And it will be locked for all your users basically. So you can see at the top here, average control program. You can see that I have two widgets on the left hand side there and I have a lot of different widgets on the right hand side. This is when I'll show you some things in the way. If I switch over to the data store app over here, you can see that we have some sort of config in here. And this is highly documented. And I'll just briefly go through with you. But what we can see here is that for the config for this program, this is the program ID of the child program, you can see that I set up a left column, a right column, and I also set up a title. So the default title, for example, will be just enrollment dashboard. But I can overwrite this and I can write child program because that's simpler for my program context. You can see that I also set up, for example, quick actions and stages and events. You can see over here, let's just ignore this part for a while. You can also see that I'm printing out tracking into the relationships. I'm printing out the ad-word, the warning, the feedback indicator, and so on and so on. Now, this is what defines how your program looks like. If you don't have this config, everything will be fine. We'll just use the default configuration of how things should look. But from here, you can set both, should we display or hide certain types of widgets? In what order should they be displayed? For example, you can see in the capture up here that we have this widget called the person relationships here, which is the tracking to the relationship. And if I refresh, it's there and everything. If I go into this config and I basically just remove it from the form here and I click Save, you can see that it's now not displaying in the dashboard itself. So that means if a widget is not relevant for you or your program context, you can just remove it. And you don't need to display it. We can also take a look at the sorting and ordering. If I put this up here, just configure this JSON correctly and I refresh. You can also see that I changed the order of the two different widgets here. And this JSON is very granular and you can change whatever you want. And we really do feel like this is a good way to set things up, to also display what it will look like in any other program. This is the track, the tuberculosis program that we have in Sierra Leone. And you can see here that it's basically the same thing. We display a different type of disease surveillance, but everything else would be familiar. Any questions? OK, I'll direct you to one more thing. And this is the other type of plugin that we currently have. That's the other programs up in this corner. I've tried to add some spacing here and everything so you can see that there's something else with this widget. As I said in the configure here, we should skip this first part here, but we'll talk a bit more about it now. You can see that it's set up as a type plugin. And this box is not something that you'll see by default in the capture app. You have this functionality in the old track capture, which said other programs. But the other programs here is going to be replaced by something much grander and bigger that's called the tract into the dashboard, which is basically the dashboard where you can interact with all your different enrollments and everything. For now, though, for a way to display how this plugin stuff work, we have this other programs here. And I'm in this tract entity called Filono Rider. And this tract entity is also enrolled in all the other, some of the other programs. I'll just, yeah, sorry. And so this over here, as you probably figured out, this is a plugin. This is not a native widget that we display. It's a plugin. It's a totally different app that we're projecting in here. And all the logic is written by me, not by the capture core team. And you can see it feels and behaves like a regular plugin, like a regular component, like all the other widgets here. It feels very native. You can also click around with the buttons and this is a callback that we provide to the widget that saying that you can navigate around the app if you want to. And from here, I can sort of navigate between all the different enrollments that this Filono Rider person has. I can also click return to the dashboard. So when the dashboard is there, we'll be able to go right back to the dashboard and look at all the other different things. And this is not something that's going to be bundled or anything. This is something that you can set up and configure in your own program context. So that's the two different plugins that we have. We have ones that go in form and we have ones that go into the dashboards itself over inside an enrollment context. And this is also configurable for all the different enrollment pages we have. So we have the enrollment view, we have edit, and we have a new. Let's see if I can go in here and click new. So this is a new event. And for everything here as well, everything is configurable. If you want one widget to show up in the new and edit, but you don't want to show it up here, for example, it's totally configurable and it's totally OK. Let's see, I'm just trying to remember if I've done everything before we move on, but I think we're there. So I can also just briefly show you what this actually is. Oh, yeah, no, hold on. There's one thing that I want to show you. So all of this plugin stuff is really great. And we think that for you as an implementation, you can use this to use it for very specific things for your implementation. So things would be like a civil registry lookup. It's very specific to your country and probably wouldn't work in any other country. But we also can use this plugin to extend on very generic things that will work in a certain program, in a certain setting. But it wouldn't work across different diseases, for example. And one of the things that I'm really going to highlight is that since we're part of the academic community, we also have one group of bachelor students who are writing their bachelor thesis on this development and on this plugin frameworks stuff. And I really want to show what they've done. And this is a different instance that we'll probably give access to at some point where they've set up some metadata to basically do growth monitoring of a child. And from here, you can see down here that this is not something we could ever shape generically in the capture app. But this is the WHO growth charts or the capture growth charts, where we can look at how a child, if a child has a normal growth throughout a different set of periods, for example. So very typical is its head circumference, its length, its weight. So you can change between the different data sets and everything. And this is not something that my core capture team, this is a bachelor's group who will be releasing this for everyone to use, just like our custom apps. And the app app will have a place where we can put all these plugins and you can configure them for yourself and put it into your context. And it will really save you a lot of time and energy to set up all these different things when there's a community. That's what we're all for, right? So I was just going to show you this. And this is still in the early ages of development, but this is something that will be there and ready to go when probably you are ready to use capture. We can take a look at the two different plugin styles and how they're set up. And this is all very well documented and everything. And I'll just show you very quickly the code for it. What we do is that if you set up a new app runtime app, if you use the CLI and D2 create a new app and everything, and set up an app just like you would with a custom app, then you from here already sort of have plugins configurable in your .d2.config. You can set up a plugin entry point. And when you then run or build this app, we would release a plugin entry point where you can use your plugins. And from here, you can basically do whatever you want. You can see here that this is a React app that I've written, this is the enrollment overview plugin. So it's the other enrollments where you can switch around and please don't look at my code because it's not built for something to be sustainable, but it's just React. It's just a React application and you can do whatever you want. And you can see that we're sending in some different types of props that you can use. So in the enrollment overview, we're sending out all the props that you can use for getting which context that you're in and also a callback function for navigating around. And the same thing will be for the tracker plugin and I'll show you the config and everything for that later because it's a bit more complex. But this is basically just a mutation function that sends in a patient ID, fetches a random user and then you use the callbacks and everything to send it back into the form. And we've written some TypeScript types that will all be documented as well. And you can see what you can use and everything. And if you're used to doing any sort of custom development or even React development or even any kind of JavaScript development, this will all look and feel very familiar and it's very easy to set up. And this is platform-wide. This is the platform theme. It's not something that we're going to take all the credit for because this is a very big and very great thing about the news releases from the HS2. Yeah, just need to check the time. The last thing I'll go through is the config for setting up data and reforms, setting up the form field. You can define it by either the program ID or the program stage ID. And from here, you can define how your form looks and behaves. So from the program ID, it's an array and every object in this array is one section in the form. So I'll try to show you here. So I have two sections here. One that is called civil rotors, and one that is called personal details. And you can see that the name of this is civil registry and the name of this is personal details. In the personal details, I'm just mapping out the different attributes like you would in any other form. I say that it's a tracked entity attribute and I give it the ID and the app will configure this and set it up as normal, basically. In the plugin, it's a bit more complex because here you need to define some stuff but that's pretty much it. You need to define an ID. You need to define the plugin source, which is just a URL to your plugin and also the name and then plugin HTML. And you also need to define that it's a type plugin. And in this field mapping here, here you can define what attributes that the plugin should have access to and be allowed to change. So I've sent in the four different things that we need here, actually three different things. The last one is something else but it's first name, last name and gender. And from here, you can define that the ID from the app should map to whatever we call the ID in the plugin as gender. And you can see if I call gender here and map it to this ID and say that it's a tracked entity attribute. If I go to the plugin details here, you can see that this metadata for gender is called gender up here. So you can use this in your plugin and both use this to build really specific and cool things but also very generic things that we hope is going to benefit all of the community basically and everything else. So I think I've covered most parts about plugins. I also reiterate that this will all be well documented and it will be posted on the developer portal and we'll make a huge announcement about it and try to splash the water as much as we can but it will be there once you're ready to start doing this. If you want to try this out and test this out I'll also set up the instance itself. You'll see the URL over here that you can just log into and try out and I can probably also get Renee to post this to you and you can really dissect it and try to see how this works. But yeah, in general, we're just very optimistic to see what you're going to build on this great technology. So yeah, with that I'll give the word back to I guess Renee or Marcus. Yeah, thank you. I'm not sure Marcus, is there anything else that needs to be presented here or was this the presentation? Yeah, it's good to say thank you to the guys presenting here. Yeah. Very proud of this and as you see the main headline for 41 for Tracker is that we are now at Parity. Our focus for version 42 is to get rid of a lot of old code that is both in the backend and in the form of the Tracker Capture app so that is version 42 in one year. So right now we are very proud of this. We really hope you will adapt the new endpoint, make sure to, any new projects you start now should be on the new endpoint and we also look forward to adoption of the Capture app for Tracker scenarios and we look forward to see what plugins there might be coming from the community. There is a plan for a similar plugins hub in the app hub so that plugins that is made and can be used in the Capture app will have a place to be published as well.