 on the next session, which is around architecture and interoperability. So I hope there's been some questions now during the week, especially around this interoperability, what do we do with legacy data and other systems etc. So I hope we can address some of those in this session. So I'll start by giving a bit of an introduction. Talking about what we, at least from the sort of his DHS2 side, see as the key things of an information system architecture. Also talking a bit about interoperability integration and what we mean by that. And then how DHS2 specifically can be sort of fitted into an information system architecture for a country. And how it supports different types of interoperability integration. So I'll start with an introduction on this and then we have a bit of a practical exercise. Where we finally get to use all the flip charts we have standing around the room. So that's the plan for this section. So I'll start with talking about information system architecture. So what is an architecture I think very often when you think of architecture you think of houses buildings, and then you think of this kind of blueprints. The instructions for how to build something. One of the different ways to define architecture one way is to say that it's all the different components that you have in the system and how they relate to each other that's one way to see architecture. Another definition is the design structure of system. As Anna talked about this morning, when we talk about the information system is not just about the technology is also about all the things that you need to have supporting the technology, the people and the processes, and then non technical elements. Information system architecture is not just about the databases and the devices and the internet. It's about the overall system and the people that are part of that system. And I think in some ways this kind of presentation of an architecture can be a bit misleading, because this is very static image. This is a picture of what, what do you think today that you are building. But in practice we see that information systems they are always evolving, they are changing. So this kind of drawing of the system that's snapshot, it can be a plan something you're building towards, but it's always changing. So this week, some of you will sort of think a bit differently about how you would want to structure your information system. So sort of on a month by month year by year, your definition of the architecture is evolving. So sort of talking about how things relate to each other in the system is a bit. It's a bit abstract. And we're talking about the information system, it can be how does the HMIS system you use for routine reporting of facility data. How does that link to your human resource system, how does it link to your lab information system. And what sort of what is the relationship between them if there is a link are they sharing data. Are you sharing facility codes in the master facility list, etc. So that's sort of from the his side what we typically sort of the way we think of health information systems and architectures. And of course there are people who have spent a lot of time trying to come up with this sort of best practice reference architectures for health information systems. How many of you have seen this drawing. You raise your hand. One or two. So this is, it's a bit old but it's a It's coming from a quite big initiative from around 2007 eight, called the health metrics network, which was sort of a double HL led initiative to strengthen health information system. So you can come up with this framework, describing sort of how you can structure and think of health information systems. What are the different types of data sources coming from the population coming from the institutions. The element of that tells him for health metrics network architecture was to have a data repository that everything is sort of feeding into a data warehouse. So that's one example of a sort of reference architecture. And your example is this open HIE architecture how many of you have heard about open HIE or seen this slide, a couple. So here it's sort of a different concept while the HMM framework was all about bringing everything into one data repository. The key here is that you have lots of different separate system is stick system you have a shared health record you have an HMIS you have a finance system separate systems supporting some standards for interoperability and then you have an interoperability layer that is connecting all these systems together. So this is sort of in some ways it's a complete opposite. So here it's about taking everything into one data repository. Here it's about having lots of different individual sort of components that you link together with some sort of interoperability layer, ideally then built on some standards. So what we can see sort of from again with our details to glasses on is that these kind of reference architectures whether it's the HMM data warehouse kind of approach or it's open HIE. They're very useful. So we're providing some concepts some examples. For example, trying to think of what are actually the different sort of domains that you need within your health information systems. So we are for example, one of the founding members of the open HIE community. So what we disagree with some people is that we don't think these are sort of the answer to the question how should your information system architecture look like. So these kind of reference architectures is useful to discuss to sort of have it improve our understanding of the different components. So they're a good inspiration but they're not a blueprint that you should build the country system based on. Building your national architecture you should look at what is actually what are the systems I have now. How do they work. What am I missing. What kind of resources do we have. What kind of people do we have that that's the kind of thing that should inform the national architecture. So these are useful for inspiration but they're not sort of the answer to what every country should try to develop. It's important to have some sort of plan to have a drawing saying this this is what I'm building towards. But then as I said initially, things change things evolve. So you shouldn't think of what you made last year, you developed your information system architecture and that's that will be there for five years until you make a new plan. So that you need to update. Over time. At least, I think it's very fun to make this kind of drawing say this is the system and it's linked to this system and then you can feed data from the system. But it's of course also a bit misleading is not just about making two systems talk. It hides a lot of other non technical issues. For example, we had the session this morning about governance who is actually the one deciding on the overall architecture who decides when we should add a new system who decides what systems to prioritize when we're looking at the integrations. So I think it's also important to keep in mind that this sort of concepts. Blind registry facility registry. Is not necessarily sort of directly translatable to one information system one database. So for example, what we see in many countries that use the tries to as the HMIS the system for routine reporting from health facilities. That is very often the most updated database of health facilities, because you can't report in an HMIS unless the health facility is in that system. So every month, or maybe even every week, people update the facility list in the HMIS, because otherwise they can't report. So very often the HMIS, for example, could serve the function as a facility registry without being a separate database, but just because there is an incentive to keep it updated. Another example that we see in many places now is that countries get support to set up what they call malaria data repositories. So bringing in malaria data from surveys from routine data from from estimates. And I say okay we need a new database a new instance to have our national malaria repository. Well in fact it could just be that you say well we have our HMIS it already has all the routine malaria data. So we can add the malaria survey results, and then we have our national malaria repository. It doesn't have to be a new database a new system, just because you have this new concept. So I won't go into the detail here but just a few examples this is one from Kenya. This is how they sort of define their architecture, where you have for example the medical record systems feeding into an aggregate system like this. You have logistics database feeding into this you have for COVID surveillance they set up a separate instance just for the surveillance work linked to the aggregate system. They have human resource system and you see here some of them actually specifies what sort of interoperability standards they use as well. So for example this is from Norway, where DHS2 was used for COVID surveillance, COVID contact tracing in a lot of municipalities. So they had the DHS2 tracker used as the system for the COVID cases for the contact tracing. And then they linked DHS2 then to all these other systems that was already in place. So lab database, the surveillance database, population registry and the contact registry. So feeding in the demographic data based on the identifiers. So that was just a few examples of ways to sort of define the national architectures. Moving over to the integration interoperability. I think they're sort of very closely related. Because if you think of this kind of architecture is the different systems. You draw a line between them. That's of course a question of interoperability integration, the way the different systems are connected together. Sort of very simplified definition what we, at least I think of when we talk about interoperability and integration. Is that interoperability is about making two systems able to communicate exchange data or information. Whilst when we talk about integration, it's about making the system function as one making two systems function as it as if it was one. So of course to have integration you very often need interoperability to do the work in the background to link the systems. And I think he when you think of interoperability. It's very easy to say well it makes sense that the system is connected to the system. But what is the actual benefits who who is going to use the output of linking those systems. And how does that compare to the cost, because interoperability projects is often expensive complicated. So we need to maintain over time to really need to consider are the benefits we get from doing this, greater than the cost. And of course another thing related to the architecture is what we have a new system in our plan for what we want the system to look like is actually what are the kind of integrations we are planning to have. And then also keeping in mind that when you're setting up this you're not setting it up I think I'm also talked about this morning you're not setting it up for the for nine months or two years. This kind of large scale information systems is there for many years. They typically outlive sort of project periods. So that's one part of the sort of infrastructure of the of the health system. One way to look at interoperability is sort of think of it as a something that is layered. And if you think of it sort of from in the time perspective the first thing is that someone needs to actually agree on making two systems interoperable or integrated. So the first political organizational thing, first and foremost, foremost, that's maybe the most complicated part of integrating systems is getting the people who are responsible to actually agree on doing this. The next level is defining what are we actually what is the definition what are we sharing between the systems. What are the concepts what is the definition of these different variables. And then at the bottom is the technical level what is this kind of technical standards we're going to use to connect the system. And the idea here is showing the complexity. Very often the focus is here what what kind of standards are we going to use, but that's very often the easiest part. The first part is getting agreement on what, what to do. So there is a comparison here from a telephone conversation the first thing is, do you want to talk. If you don't want to talk there's no point in going into the details. And then it's kind of actually understand each other do we have the same language. The technical level is do we actually have a phone with power and connectivity to talk. And if you really want to dig into this kind of thing this is from a book that a few of the colleagues professors wrote a few years ago it's getting a bit old but I think a lot of the concepts and thinking there is still valid it's there's a source in the slides that you have access to for the whole book. I think the top level is to a large extent that's about governance like we talked about this morning. When we get to the syntactic level sort of the definitions of what is being exchanged. That's a very critical component. One thing is that you actually need to agree what are the variables the data elements indicators that we want to exchange. How do we define them. What is actually what are the health facilities in the different systems the organization unit hierarchy. Do they have the same identifiers the same code so that we can actually share data. So if you're exchanging information about patients or people, do they have some sort of unique identifier that you can use to identify them in both systems. And aligning this to be done sort of by updating what is in in in the two systems or often you have to end up with some sort of middleware that maps what is in the system to what is in the other system. So the first the difficult thing here is that this needs to be maintained if you for as many years as you want this to work. Someone needs to be responsible for making sure that if you change something in one system. You change it in the other system otherwise it breaks. So this is something you need to have a plan for and maintain forever. Of course standards makes it easier to do the technical interoperability. So from the details to side, we're able to produce data in this fire format. I don't know how many have heard about fire. It's not so many it's quite new and a bit trendy. I do have the possibility of producing data in this format. But I don't think we have examples where it's actually being implemented in countries. We also support this aggregated data exchange format. This is another standard part of the this open HIE framework. But again I don't think it's very many implementations that actually use this. And then of course we have the the choice to can import and export CSV files etc Jason files. But these are the standards we have built in. But like I said in practice. Especially if you're thinking of linking these guys to two existing systems that are maybe a few years old. They will typically not have this from before. So then it doesn't really help that you have it on the details to side, because you would in any case need to have some sort of custom technical solution. I just wanted to take sort of go through one scenario and look at what are the alternatives in practice. Let's say you have you have your HMIS with your monthly reporting coming in from facilities. So every month facilities report data into the system. And then in parallel, you have an API system where the facilities report just the immunization data. So there is maybe half of the immunization data is also part of this but not all of it so they still want to have this data. How many of you can recognize this kind of parallel reporting from your countries where you have multiple systems collecting the same data from health facilities. Can you raise your hands. No one. Okay, it's at least in I would say in 90% of the countries we work with, you have the situation, multiple reports coming from facilities with the same data. So what are the options if you want to do something here. One option is of course to not do anything. So just continuing with the parallel reporting. But that's not so interesting to talk about here. The other alternative is to figure out the way for these two systems to exchange data. Either both ways or one way. Why would you want to do this well maybe maybe this system also has data on maternal health and deliveries, it would be useful to be able to triangulate that with your immunization data. And logistic so you could look at your vaccine logistics together with the vaccines provided. So I think there are many ways, many reasons for wanting to do this. And then the third option is stop using this and including the information in this API report. So what goes into the system. And how do you decide on what makes sense. I think there are a few few things that we see are important in deciding this coming back to this all the time governance ownership. If you are the API department, this is your system. Maybe you don't want to just say okay we'll stop using our system will just use your system. The system that they own and manage to do what they want. It might not be easy to convince them that this is more efficient way of doing it. Even though there are sort of rational reasons. Another factor here is the cost. Typically that's a factor that is sort of to the advantage of getting rid of one of the systems so if you have one system. You can maybe have one server instead of two servers you can have one team that is trained instead of two teams. You can train end users in one systems instead of two systems. You can have one device in the facilities instead of two maybe so there I think there are lots of abilities of resource saving. Third factor is of course the functionality. Maybe this system has some functionality this system has. Maybe it's critical maybe it's not but that's will influence what you end up doing in the end. If you really have something in this system that this system cannot do for example in terms of analytics. Then this is your only option if you want the systems to work together. Final thing is of course how difficult is it to make the two systems exchange information. Like I said initially it's often the key consideration what is the benefit of doing this versus what is the cost. And what is the complexity maybe it's quite easy maybe it's very difficult technically. I've been using API here on purpose because that's a very good example we've seen with the choice to. The choice to has been used for many years as the HMS, including the immunization data, but the immunization programs have been very reluctant to give up their parallel system. And this parallel system in many, many countries have been based on Excel or Microsoft access. So the cost is not really a big argument because most if you have a computer in the district you probably have Excel so there is no huge maintenance costs to the system. For a long time there was also some functionality that was missing in the tries to. We were saying well if we move from our Excel system to the tries to we can't do monitoring charts anymore. I don't know if you know this vaccine monitoring charts looking at the cumulative numbers of vaccinated children from January to December. There was some specific features. That they couldn't do so they said well we can't use DHS we will keep our system. And of course this, in one sense it's very easy to do that with Excel, you can make a CSV file and important to DHS, but to have like a permanent interoperable solution with the between Excel and DHS is not so easy you changed at the row or column to Excel. It breaks. These are the reasons for a long time. Countries using the tries to stage mice they kept on this parallel EPI reporting, even though it would be very easy to set this up in the tries. Another important reason for that is that the tries to now supports this special visualizations that the EPI programs couldn't do in the tries initially. There's also been some questions this week from from you around sort of historical data from other different systems, how can we get that into the tries. So this is where you're sort of going from this, your stop, you'll stop using an old system and you're start integrating it in the DHS in this case. That's quite the common scenario so we have different tools that allows you to do this. More applications of the tries to is what we call the import export up. So if you have your data you can transform it into CSV file, or Jason file that can be imported to the user interface, assuming that you'll be able to map all the variable names and codes and everything of course. So you have a web API, which lets you post this in a more sort of programmatic way, rather than through the user interface. We haven't really talked much about this app hub that we have for the tries to where people can develop apps and make them available for other users, similar to what you have on your phone with app stores. And there are several applications developed by in the details to community for doing data import. So I've linked there to one app called the data import wizard, for example, so we'll, we'll give you a quick demo that later. So of course, this is sort of the technical, yeah, and then you could also just put it in the database, but we don't really recommend that because that will then not do a lot of the validations and integrity checks that is happening when you do the other use the other methods that sort of a last resort. So this is very easy if you have everything using the same identifiers or names or codes, both for the data and organets but typically there is a process in between there where you need to see sit and map and fix the spelling mistakes of all the health facilities because it's not like this in the system it spelled it differently here. So, I'm not going to say it's very easy or pleasant task but it's doable as long as you're able to do the, the data mappings that you need. So generally about the chest in interoperability I mentioned this API, which is what this very often used, I would say, always used. If you're doing custom interoperability solutions if you're making some sort of tool that is linking to systems on the details to side, you would use this API. So we have examples of this being used to link it to population registries, for example for demographic data for human resource systems for connecting with com care open MRS or decay etc. And what we often see of course is that a lot of the legacy systems don't have an API so on the details to decide you can push data to the API. So that's something else on the source system, whether it's exporting to CSV and then converting it to or it depends. Yeah, this is, again, just in a way repeating what I've said earlier about the meta data mappings you need to make sure you have the same definitions the same same codes and maintaining it over time. Well, if you're planning on having a system architecture with lots of integrations lots of separate systems, a bit like the open hie kind of approach. You could consider also then setting up this kind of middleware, which is a system that has as his only job to link all the other systems together transform the data in the way that ways that are needed. So I will just open this. If you want to read more. We have this dedicated page on integration interoperability. I'm showing this mainly to just show some examples you can find lots of examples here. These are two of the sort of middleware solutions that can connect to the choice to so this open function open him. And then this is a overview of other tools. Where there has been work on making the, making them interoperable with the choice to sign off for example rapid pro has been mentioned earlier. On this website, you will also find what we call the his principles for integration interoperability, which I think is sort of a summary of what I've been talking about here. First principle is that the project should support country goals. The challenge sometimes with this reference architectures is that there will be partners who really want to get countries to use this nice thing that has been grown up. So there's often a lot of pressure. You should do it this way. Which sometimes is good for the sort of aligned with the country plans but sometimes it's not. I think first principle is that whatever you do in terms of interoperability should be actually aligned with what the country wants not some partner pushing their best practice architectures. The first principle is that whatever you do in terms of linking systems it should actually benefit the users and there should be some clear value. And related to this, the value should be greater than the cost, because we know that this interoperability is often expensive and complicated, and it's something you have to maintain for years. So interoperability should be done. Sharing of data should be done because there is some benefit of actually sharing this data for in terms of data use. So what is useful as a starting point when you're discussing linking systems is actually discussing with the people who will be using the data and asking them what what is it actually that you want. You shouldn't be started by the technicians to say well we could, we could link the systems technically it would be quite easy. So the starting point should be what is the outputs. What is the data you want to be able to use in an integrated way. The systems and architectures, like I said they should be designed locally for the country not trying to replicate some abstract ideas. So I encourage participation in this community that are working on the architectures on concepts, etc, because it's useful they come up with useful concepts, they come up with standards that can be used etc. Okay, I'll give you a break from just talking. And then I'll actually do some examples of some of this focusing on essentially getting different ways to get data into the choice. So we'll show a few different ways of doing that, so that you can actually believe me when I say it's possible and not just something I put on the slides. Okay, so first thing I'll do is to use this import export application that I was talking about. And please don't laugh it if it doesn't work. I know demos are a bit dangerous. So I'm looking in now with the database that you've been using just to demonstrate this. So what I'll do is just to show you a few different ways to move data into this the test instance. Okay, so a bit of both. So I'll have one example where we push and import. Okay, so I'm just using immunization as an example here. So just to prove that it hopefully works in the end. I'm now I just picked the health facility in our demo database for March. And as you can see there is no no data here. I will open the import export up. Let me I'll just change that. So I've cheated a bit. I have a CSV file ready with immunization data for March for this province of Laos. Excuse me. Can you repeat the last step please? Excuse me. Yes, I'm here. Sorry. I'm here. I'm here. Yes. Yeah, I see you. I'm sorry. Please repeat the last step. Could you please? Yeah, so what I've done is I made a CSV file in advance, which I'll import. It includes the data for March for one of the provinces in our database. Just to show you how that Yes, yes, I need the first step. The first step. Yeah, so the first thing I did was just to open data entry to prove that there is no data there now. And then I open this application called import export. I think with your demo user accounts, I don't think you have access to actually open it. So if you see access denied, that's because your accounts don't have all the admin functions. So you see here this app, it has supports import of data, of events, earth engine, which we talked about yesterday, which is the population estimates, organization units, GIS coordinates, etc. But what I'm doing is importing data. So I know this is very small, but this is a CSV file with all the columns that is needed for imports into the tries to actually only need I think four of them you need to have the this identifies the data element, the period, the health facility. These two are for disaggregations, they're optional, and then the data value. So there are basically four things you need. Yes, this is a predefined template for importing the data. And also this is something I made something human, but so I can, I can, we can share the link to the documentation. There is a specific format you need to have the columns in the right order. But then you populated sometimes I use just a scale database sometimes I just copy paste in Excel, but it needs to just have those the right order of the columns. Yes, the shared language, usually when we, when we use import and export, we built the template pre-made so you can just fill in the data as the system expected. Yeah, but you don't have the templates, but you have the guidelines. Yes. How the templates should be. Thank you. So in the documentation, you have this CSV data value format describing each of the columns, what the format is, and which ones are required. Okay, so I have my file here. This is, here you see what formats are supported. So we have JSON, CSV, XML, this ADX standard, and PDF, and this is not any PDF. This is PDFs created by the tries to be imported later. The first row is the header row. Then I can first do a dry run, which is just checking if it's, it has the right identifiers, et cetera. Success, it created 3000 values. So then I can do it for real. Okay, success again. So if I go back to March, I now have my values. So that was an example of using the import export app to import basic CSV file. Next thing I'll do is to use what we call the data exchange app. This is a new app that was released now for the latest version of the tries to. So I don't think it's been widely used many places yet. So this application is an application that lets you set up. Yeah, so now now this data that I imported, it's available as if someone had entered it. So what is, what is needs to be done now before this appears on our dashboards is that we have this analytics process that actually transforms the data from the source tables into tables that we use for analytics requests. Yeah, so background, it changes, changes to basically moves the data from one database table to another. That is more suitable for analytics. No, I can, if you want, I can start it. So typically this is for aggregate systems. This is typically done every night. So it's something you schedule to run every night. So that you have the data entered today is available for analysis tomorrow. Yes. So let me just do it now for the last year. So it's a bit fast. Yeah, so this, it probably takes a minute or two. We can come back to it. I'll jump a bit and then we can go back with this. Okay, so while this runs, I will show you this data exchange app. Like I said, it's a new app. The purpose of this app is to, it sort of serves two purposes. One is to move data within a details to instance. If you have case based data. And you define sort of aggregate numbers from your cases. So I want to know how many children were vaccinated today. I can set up a formula for counting that from our case based data. I can use this app. To save that number. As an aggregate data value that shows up in my monthly report, for example. The other purpose of this is to move data between different details to instances. So what I'll do now is I have the choice to running here. And then we have the. Online instance, which is running, I guess in Dublin or something. It's a cloud server. So I'll use this data exchange app to take some data from my laptop and push it to the cloud server. Okay, so this application is not actually bundled with details to it's something I need to download from the app hub. App store. So you see now there is no data exchange up here. But I can go to the app hub. And I can find the data exchange. And I can install it. So now I have a new application here for data exchange. I've cheated a bit and set up the sort of definition of what should be moved in advance. And I can show you what it looks like. I'm wondering about the application that exchange up. Is it available in a specific version of the choice to Yes, 239. 239. Latest version of 239. Because I have tried to check on 2.38. I didn't find it. No, so it's using some backend functionality that is only in 239. Okay, thank you. So this application it relies on specifying in advance what you're actually moving. So I made now a data exchange. I gave it a name. I said I want to move all these data elements. For this, I've only picked one facility just to keep it simple. And I picked March. So I'm now moving all these data elements. For this help facility for the month of March. This is what I'm taking out from my laptop. And I defined that the target for this data. Is academies, demos, slash import. I've set up this secure. It's like a password that is not the password. Which we used to secure the. Data import. And that's basically it. So I just defined what I want to move. And where I want to move it. So the one night. If you so I call this. External data exchange demonstration. I have it here within that. It's giving me a preview now of the data. I'm about to move. So these are the data elements. It's BCG doses. DPT, et cetera. And when I'm ready to move it. I click submit. I'm moving one report. To this server. For March. Now fingers crossed. Yes. So now. It imported the 26 new values on. This online server. So let me find that again. Into. This one. Oh no. Maybe it's. Was the wrong facility. So. March. 2023. These are the values that was transferred. These data exchanges. You can see this app. And you can see the. Numbers. BCG doses on the one one year. 19 above 11. Et cetera. This data exchanges can also be scheduled to run automatically. So you can say every midnight I want to move data from. This instance to another instance. Getting even more technical. I want to show one example also of using the API, just making a script and using the API to. So I'm going to import the first export data from my local database. And importing it into this online database. So now I'm. Importing into this. Facility here. So there is no data there now. This is my homemade. Script. I'm not a developer. So this is sort of not the professional way of doing it, but it works. For demonstration. Again, I've defined. This is my local. Laptop. Which is the source. I actually want to move it to. Online server. This is just to have a temporary file. And then. There's only really two lines here that does the export and import. So this line. It will. Log in to the server. So this is my local. Laptop. Which is the source. I actually want to move it to. The server. And fetch the data. This line will log into the online server and import the data there. So let's see if it works. Imported. I think I may be using the same. I'm importing into the org unit already has data. Let me find. You get the quick involuntary demo of some other features. This is the one I'm moving data for. It was the right one. Yeah, imported 21. Yeah, so that that's then. I know how data for this or unit. Which I imported using the API, just with a homemade small script. So that was the third third example. I'll now ask you should it. Who is hopefully ready to show you the last one. So what I've been doing is looking at. I've been moving monthly data. More or less the same could be done with aggregate data from the individual cases. But what should it will be showing it is how to actually import individual level data. So cases. Is it possible to share with us the data. The files for AB eyes. Just to see a dig deeply into it. Yep. Now we can upload it to model. So you have all the different examples for the. You connect. So as all of mentioned, what I'm going to show you is importing some kind of case based data in this scenario. And we're going to use one of the applications that all of mentioned this data import wizard. So you'd follow a similar process as he showed for the data exchange app. You install this through the app hub. It's not something that is there from the beginning. Just when you set up your DHS to system. So I'm just going to show the program that I'm bringing the data into really quickly. Just so you can understand the structure. Okay. So what I'm going to do is I'm going to bring data into this case based surveillance program. It is collecting individual data per case. So I'm going to show you the various surveillance purposes. I'll just open one up. Okay. So it has information on their diagnostics on their lab on their final classification. And the whole process starts by registering these various demographic details. Right. So we're actually registering each individual case. We take the first name, their date of birth, their sex. Okay. All these various characteristics, right. So what I'm going to do now is bring in some individual data. Okay. So just keep this in mind. What I'm going to do is I'm going to create a couple of new cases. And I'm going to bring in information for their diagnostic or clinical information and their laboratory request kind of process. So we'll create some new, what we call events inside of DHS to along with new kind of people as to associate for each of these cases. So the app I'm going to use is called the data import wizard. This is also available on the app hub. Okay. So if I go to another DHS two system. Without this installed, you know, I won't see it there normally. Okay. This is an extra app that you have to install on your system. Okay. So the way this app works, it works for both aggregate data. As well as kind of this tracker data. This case based data. And I'm going to focus on the tracker data in this example. Okay. The whole idea is that. You can basically use. Many of the methods that all of have just as discussed, you can still use JSON or use something through the API. You can also use a regular Excel spreadsheet. Okay. To bring this data in. And the whole idea is it kind of gives the user a bit of an ability. So in the files that all of the showing the data has to follow a very strict format. Okay. You have to map variables to very specific kind of characteristics in order to import the data correctly. In these files that can be a little less structured. You know, that's very common with Excel data in particular. Okay. It's still, for example, will break if you insert a bunch of columns and things like that out of nowhere. Okay. But the whole idea is, let's say, for example, you know, he talked about many examples of integration. Maybe you're bringing in old data. Right. So maybe you just do this once and you import, I don't know, hundreds of thousands of records or something. Okay. So just bring this in. So I also have pre-prepared my file. Okay. It has 10 cases on here, just as an example. And instead of aggregate data. This is individual data. Right. So we have name details. We have dates of birth. And then we have some different parameters in this case. I'm bringing in measles cases. Okay. So we have information. On the case itself, what kind of symptoms they had, et cetera. Right. Line by line for each individual case. So if you're using the format, some of the formats all I've showed you, it will look a little bit different. Okay. Don't have to focus. I know some of you want to learn more about that structure. Like I said, we'll post these online so you can have a look. Okay. So what I'm going to do, and I'll just go through the process to explain a little bit. So the whole idea is that within this app, you kind of take each parameter and you map it to columns in your sheet, or maybe if you have a JSON file, you would map it to the JSON file, but it tries to give the user kind of make it a little bit easier to understand. Okay. Rather than kind of using specific IDs and variables, which, you know, it's not the easiest for everyone to understand admittedly. Right. So in this case, I can just say on the left side. This is what's in my Excel sheet, maybe. And in the right side, it kind of lists all the organization units in my system. So I could say which organization unit or facility. I should say maybe I'm bringing the data into, for example, and we do this kind of mapping by selecting. I'll just go through a couple of more examples here. There's some more information on this page. For example, we have the. This is the name in the system. Jen given name. Jen family name is the last name. Okay, then I have my Excel spreadsheet. Here's the columns. It's actually grabbed the data from my columns, the headings from my columns, and I can just map the left side, which is my system to the right side, which is the columns in my spreadsheet. Okay. So I'll just kind of go through some of these real quick. Okay. Then we have all the different processes. I'm going, I know I'm going through this a little quick. I just want to show the process. Where we go through and we kind of identify, there's a lot of different individual variables, but same thing, right? On the left side are my system name. On the right side is the Excel spreadsheet. I just map everything between them and we do the same. Let me find one with options. Okay. We do the same for all the options, like the lists, the dropdowns. So when you have individual data, you might have dropdowns. You have to match all of that as well. Okay. Yes. Yeah. It's a good question. I'm actually going to import two stages. At the same time to show you guys. Okay. But you can do it all at once. You don't have to do it all separately. I know that's a common way with tracker data. Sometimes stage by stage, you have a lot of stuff. I would also say it depends on the size of your data. Like if you have millions of records, you probably want to parse them out into smaller pieces. Otherwise it's just going to bring your system to a halt. But you can theoretically do, do multiple stages together. Okay. So, okay, we'll ignore this error. So in this tool, it gives you a preview of what you're going to import before you actually perform it. So I have a couple of examples for example of cases. Here's this person, their details. It's mapped the columns in my, in my spreadsheet to the actual details of this person. David Smith, he's born on May 1st, 1990. He's male. These are his home address, his village, et cetera. Epid number he has measles. Okay. Just gives me a preview of all that information. Same with the events. You can see I'm bringing in data for two different stages here. The clinical one and the lab request. Okay. So I'm able to bring in data for multiple stages at the same time. And let's pray a little bit to the gods. Okay. And let's see where we're at. Okay. We have 10 successes. So let's see where we're at now. So I'm going to go to the place that I said I was going to import these through the user interface. Which was this one here. And I'll select my program. And here we go. I have 10 new cases. Okay. And if I open them up. So here's the data for one stage of this diagnostic and clinical information line by line. For that particular person. It's brought in some information. And I've just filled it in. And then we have the lab request. It's also brought that in. So I can see that I'm able to bring in large. Well, I know I just showed a very small piece of data. Just for example purposes, but you can do this with large pieces of data. It does take more time. Of course. You would probably want to separate your data out, especially if it's this type of case based information. Okay. So I'm going to go to the next slide. If you have a million records, two million records, whatever it might be, and that's the reality, right? You might have millions of records or cases or events. Okay. You typically break them down into smaller pieces. You know, maybe you bring in 10,000 at a time. Or something like this, right? And then you kind of let it go through its process. And then you go to the next 10,000. Okay. You wouldn't bring in two million records at once. But those details we can discuss. So we've seen a number of examples of aggregate data. You've seen it working similarly with tracker data. We have multiple models, multiple methods that we can bring in that data, either if it's historical data, or if it's maybe data that you want to kind of exchange on a more routine basis. I would definitely start testing first on your any with anything, but I think it's okay. Yeah. Yeah. If you test it on development and it's working, then of course, I think it's okay to use this app. This app has been around for a while. So yeah, especially if you're like a, you know, maybe it's like 10,000 records or something, not a huge amount. Yeah. I mean, I would definitely, but this app is a production ready. I would say. Yeah. Nick. Yes. Let's assume that we have a common data element. And it's used in two stages, like temperature, for example, temperature. It's available in stage one and available in stage two. How it can be represented in the same way. Because, because it's the same, the same data element. It's available here and here. Yeah, yeah, you could, if you're using Ola's method, you could use the same unique identifier. Yes. In this particular instance, you would just, because you're mapping the variables by stage. So if in the first stage, the temperature, you just say, okay, here's my temperature on the left column. On my right column, let me match it to temperature. If I go to my next stage, I would do the same thing, just to let the same temperature heading. And then it would just pull from the same source in both cases. Maybe the question about how viewing the same data element is replicated in several stages. For example, age or, you know, ages attribute. If you say that temperature, I need to see a different, the doctor screen and the screen. Okay. Sorry, did you want to. Turn it on. Thank you. So here we need to make sure we're not mixing up aggregate and tracker data because your question about repeated stages was related to tracker. And here we are dealing with the event. So there'll be no interference there, but whereas with aggregated data, you will just have the value in the period. So that's, that's should not be a problem whatsoever. And having heard when you mentioned the same data element in different stages here, we can also talk later about the new options that you could utilize the data in visualizations with the line listing apps and so on. But for this process of migration, it's it should not be a problem because the events they have their special you ID by themselves. So you will not mix up the values there. But on the data entry level. My question about the transaction. Why don't you. So. Yeah. So in tracker, you will have to configure program rules if you want to have the. Yeah, but it's good that you have specific concerns. Let's sit down and try to go through this. Any other quick questions before I hand it back to all of. Okay. Like I said, I know this for some of you, this might be, you know, it might be, it might be, it might be, it might be, it might be, it might be, it might be, it might be, it might be, it might be, it might be, it might be, like I said, I know this for some of you, this might be something you're not completely familiar with. That's okay. I think the main thing that we wanted to show you was that it's possible to bring in data from different sources using different methods in both of the, in the various data models that we have. Okay. So I'll hand it back to Olaf and you can continue. Thanks for it. So I'm actually. I'm done. Okay. So we have now. We're a bit, we've been a bit slow, but I think we'll just steal a few minutes or the next. But now we have a three part exercise. First part of the exercise is just spending. Four minutes. In an Excel sheet that we've shared on model. We've used a few places and that we find quite useful. When you're starting to sort of think of the architecture is just to quickly make an overview of the different systems, what they're used for. What is sort of the owner of the system? What is the technology? Does it have an API, et cetera? Because then that's sort of the building blocks. When you start later to think of what your system looks like. So I'm sharing the wrong. It looks like this. So since we're a bit behind on time, just take a few minutes to see now working on your own sort of implementation, your own country. The idea here is to say, okay, I have an immunization system. It's run by the API program. It's case based. It's used in these many facilities. It's used in the whole country. Data is coming from the primary healthcare level. So basically adding the different key systems. That is currently being used here. Just spend four minutes on that. And then the main, then the fun part is to. Yeah. But I think there's more time on the. So that's the first part. Just spending five minutes on that template. Then what we wanted to do is to sit together in the different. Country teams sort of. We have a couple of big groups. You can decide if you want to sit together or if you want to split into. But the idea is then to take. One of the flip charts we should have at least. One, two, three, four, five. I think we should have enough for those flip charts. To sit and then try to draw up. Try to make a drawing of your current architecture. What are the systems? Which ones are related to each other? Like a snapshot of the situation today. Of course it's not possible to get everything in, but as much as you are able to. That's part one. Second part is trying to think of where you want to be in two years. How do you imagine your information system will be structured. In two years. Is it clear so far? Good. So I think. Go on moodle and find the tool there. I will let you know in five minutes when it's time to move on. And then just grab one of those. So we have in the front in the back. And Anna has the markers. And try to make an overview. And what I suggested was just having a box with the system and then. Some arrows to see when there are systems that are actually linked either. Through some. Functioning interoperability mechanism, or if you're just sharing data manually. Any questions. So I think we'll. Okay, so I should have just had a good point. I was confusing the tea break time. Let's do the first assignment one. There are there's six minutes until the tea break at three. So let's spend the time until the tea break on the first one. And then when we come back three 30. We continue with the architecture drawing.