 Okay, so welcome everybody to the webinar on the DHS2 Rapid Pro Connector. I think before we get started we invited Remy from UNICEF to give a few brief opening comments and then I hope we'll all have an interesting webinar. Thank you Remy. Thank you Bob and dear colleagues, we are glad to have many of you join this webinar on Rapid Pro and DHS2 and interoperability. My name is Remy Muamba. I work with UNICEF in the health section and I'm part of the digital health and information system unit within UNICEF. So we all know that Rapid Pro and DHS2 are important parts of the digital ecosystem in many countries and we also know that strengthening information systems is essential to enable data space decision making. However, data systems in most countries are often fragmented and not interoperable sitting in different places and this makes it difficult for program managers to take action based on a comprehensive set of information. And since 2022 UNICEF and the investor of Oslo have collaborated to make Rapid Pro and DHS2 interoperable to respond to country needs. We know that there have been some attempts to integrate both systems using the scope of the spoke integrations but there's still a need for a more robust and scalable connector that can be transferable to a various country context. This is why we did this work. And the connector developed in 2023 this year then it's for aggregate data and it's part of this collaborative and it offers several advantages that will be discussed throughout this webinar. But I can imagine some of the advantages that include the fact that it is centrally maintained by a team of developers with EIO commitment to sustainability, quality improvement and security. It is also based on a free and open source software enterprise integration framework Apache Camel and also it offers extensibility and is suited for local customization. So this webinar is an information sharing session on the work done by UI UNICEF. The speakers will briefly provide an overview of the work followed by a detailed live demonstration of the connector for aggregate data reporting and then there will be a panel discussion. So thank you very much for your attention or for attending. I give the floor back to Bob. Thank you. Thanks very much, Remy. You've already given an overview of the programs. I don't need to go into this again. Just a brief introduction to the rest of us. My name is Bob Jive from University of Oslo on the DHIS2 team. And some of my colleagues here will be playing various roles at some point during the webinar. This is Sam from Hisp Uganda, Ranga from ATI Nordic, which is our Hisp Zimbabwe. And Claude who is our chief integration engineer. And we hope, I've not checked in the participants list, but we hope we're also joined by Evan Wheeler and Alfred Mokasa to contribute in the discussion section. So I'd like to give a little bit of mention to Jean-Paul Moutali, who's kindly volunteered to provide some support in the chat for our more francophone colleagues. Unfortunately the presentations will be delivered in English. But we do have a number of bilingual people working in the chat. Jean-Paul, as I say, is going to try to coordinate that. All right. So we're here to present work on interoperability between DHIS2 and RapidPro. There's quite a little bit of history to all of this. I mean, we know that Hisp Uganda, for example, have been using RapidPro with DHIS2 for the past decade. And you'll see, in fact, it's based on some of the historical work that Hisp Uganda have done that we got started with. We know that Hisp Rwanda, Ministry of Health in Rwanda, should say, have similarly long history with Rapid SMS and are in the migration process to RapidPro. The DHIS2 integration team actually reached out to RapidPro through Nyaruka back in May of 2020, it was a year before we started talking to UNICEF, and started some discussions about where we might work together then. But things really kicked off during the latter half of 2021, after the summer, where we had a series of meetings with the UNICEF team discussing different patterns of information exchange between two systems, different kinds of challenges, different approaches. And that culminated, I suppose, in a contract being signed between UIO and UNICEF in June of last year. And that contract was essentially, the work was essentially in two parts. The first part was to produce this connector to implement the aggregate routine data reporting. And the second part was to explore the deeper use of RapidPro with DHIS2 or old tracker use cases. We've talked a little bit about that work during the course of this afternoon. Why there is interest? Well, I think Remy has already at the start outlined really why it's important. I can say from the DHIS2 perspective, part of the reason we see it as important is that we've got a very basic messaging functionality built into DHIS2 currently can send SMSs, we can send emails, but we have a lot of challenges with that. Particularly countries struggle with setting up their SMS gateways. Functionality hasn't been intensively used. There are some notable exceptions and the one I'm most familiar with, for example, was the Rwanda COVID testing where test results and the like sent out by SMS. It's a number of other cases, but not as intensive perhaps as it could have been. And we don't internally support alternative channels like communicating via WhatsApp and Telegram, which probably have an important future in this field of messaging. And also within DHIS2, we've never had any kind of workflow chatbot type functionality and we're never likely to. That's not an area that we're thinking we're going into. Again, as Remy has pointed out before, RapidPro is used in a large number of countries which overlap with DHIS2 implementations. Mostly our understanding is that RapidPro is offered as a cloud service often facilitated by the UNICEF office in those countries. There's some implications to that which I think affect some of our future planning, but we'll talk about that in a later session. But the important thing I suppose is that there's a lot of common sense of purpose here, both from ministries of health, our own HIS groups, the DHIS2 team and also from UNICEF. The activity is just brief summary of what we've been up to, I guess, during the course of the year since we got into the contract in June. Immediately after the contract we had what was supposed to be, I guess, a requirements gathering meeting and discussion in Oslo that was piggybacked onto the June conference that we have there, the annual conference. And happened very early in the project, we gathered quite a lot of interesting material from some of the UNICEF representatives and ministry of health representatives that were there. But there was still quite a bit of work to be done after that. At the same time, our engineers were working hard on the development of the DHIS2 RapidPro integration engine. And Remy has talked about with initial support in that for aggregate or routine reporting. And that's currently been deployed. It's running in production in Zimbabwe since November 2022, completely managed by themselves. The usage being piloted in two districts that have not yet scaled up beyond that best of my knowledge. And again, there are some factors behind that we can discuss a bit later. Also, I guess the past year has been full of very regular bi-weekly discussion with the UNICEF team where we've bounced many ideas backwards and forwards and agreed and disagreed and slowly made progress, I think, on the various deliverables. At the same time, we've also been involved in a number of fact-finding discussions and interviews with various other players, our various other sources of wisdom, if you like, including top of the SRP team, our own internal DHIS2 tracker team, the Android team, I had some brief conversation with IntraHealth, also quite a lot of engagement with our country and regional HIST groups. So this part of the webinar, anyway, we want to focus on the DHIS2 RapidPro integration engine. That's the artifact. It's built on top of our Apache Camel integration tool chain. This is something that the integration team within UIO have built out as a kind of standard integration framework. To do all or most of our integration projects on. The benefit of taking a common approach like this and building on a common platform is that those core components that make it all work are being constantly reused and the whole thing is maintained then as part of our broader interoperability work. And that's an important part of sustainability. The other part that's really important is that we are able to provide training on how to develop new routes in the engine, how to deploy and run it and monitor it and secure it and manage it. In fact, we have an academy program coming up at the end of this month in Kigali, where this would be quite a major part of it. So, yeah, we want to develop something that people are actually able to deploy and use and we know we can maintain. For people who don't know Apache Camel, it's, well, we assume it's kind of technical details here. It's an open source integration engine. The way we use it really is that we have a DHS2 component where there are many components within which come bundled with Camel, some three, four hundred of them. We provide our own DHS2 component to make it easy to interact with the DHS2 API. And then through the use of different processes and transformations, we can translate items from our data model into formats and API calls that can be connected to various other systems. Another big focus on, for example, interacting with Fire APIs. In this case, we're interacting with a RapidPro API. A very important use case, in fact, is interacting with other DHS2 instances of DHS2 with a DHS2 API. The benefit of building this stuff out on something like Apache Camel is that you get a lot of stuff bundled in with it, including functionality related to routing and message queues and error handling and things like that, which just make for more robust implementations of integration routes. The routine reporting use case that we've implemented and which Claude is going to demonstrate shortly, Claude and Sam, is based substantially on the existing workflow that's used in Uganda. We started off looking at that because we knew it was useful. We knew they were using it. We knew they wanted it. And so we just wanted to implement parts of that in a better way, in a way that we would take responsibility for from the Oslo site. Also, the Zimbabwe Ministry of Health identified a very similar, almost identical requirement for what they wanted to do there. Essentially what it is, it allows community health workers to be able to submit routine reports from the field to DHS2. It involves a collection of routes, surrounding routes besides just the submitting of the reports. Anybody who's worked with integrations with RapidPro will know that really important part is how you synchronize and link contacts. There's the data collection itself using the RapidPro flow, which can be done either using a single encoded SMS or question and answer style and implementing posting of reminders for overdue reports. We can discuss a little bit after the presentation how this route in some ways, maybe it's a bit atypical perhaps of some of the other routes that we might consider going forwards, but still being very useful learning exercise for all of us and hopefully useful for folks who have this requirement. Claude, are you ready for me to hand over to you? Sure, go ahead. Okay, so what I'll do, let me stop screen sharing and I'll catch up from you. You're finished. Ah, alright, one sec. Hopefully, ah, go away. Hopefully, can everyone can see my screen? Bob, can you see my slide? Alright. Okay, so yes, as Bob said, I'm going to give a quick walk through of the major features of the DHS2 to RapidPro solution. I'll be demonstrating the synchronization of RapidPro contacts, the sending of overdue report reminders from DHS2 to RapidPro, and the transfer of aggregate reports from RapidPro to DHS2. Now, one sec, let me just tie myself to be sure that I don't take too much time. Yeah, so before I actually give a demonstration here, let me explain how this demo is set up. We have two servers running, one is RapidPro and the other is DHS2. On the DHS2 server, we have a number of users and also a dataset configured. This dataset has the code of HMIS033B. And we are, for this demo, we're interested in one of its sections, which is the OPD weekly attendance, the outpatient department weekly attendance. We're going to see in this demo that a user, a contact story called Alice, will submit messages via the telegram application. And these will eventually end up as reports as data value sets in DHS2. These reports are the outpatient department weekly reports. On the RapidPro side, the server doesn't have any contacts with something, but it does have a flow configured. This flow is decoding the telegram messages sent by Alice and other contacts for the OPD weekly reports. Now I'm going to hand it off to, oops, sorry about that. Now I'm going to hand it off to Sam from his Viganda so that he can zoom into the RapidPro flow configuration and give us a quick overview of what it is doing. Sam. Thank you Cloud. Let me quickly share my screen. A flow that we're using for this demo, it's for the outpatient department reporting, and it's just a summary report of just for data elements or indicators, if you will. And it focuses on, we look at the new attendance for every week. Then we look at the total attendance. And then we also look at indicators like the mothers expected on EMTCT appointment and then the mothers that missed their appointments. It's basically four data elements. And what RapidPro does is that once we receive that message, it's in the format of, we usually have a keyword with indicators separated by periods. And this is quite like we used to have in the good older Rapid SMS, which was the predecessor of RapidPro, if you will. And so with RapidPro once you receive the message, we typically trim off the, or we remove the keyword, and then we begin to split on the period for every data element. Once we split off the very first value, we follow on to the next, but we can also do some bit of validation. In the sense that if you expect you have some new attendees, and then the total attendance, you expect the new attendees to be either less or equal to the total attendance. So in the flow, within the flow we do some bit of validation, such that the user can be notified if they send a wrong message. So once we split out all those values, there's some additional work that we do that is well documented in the work we've done. We normally, the user who is interacting with our flow usually has an organization unit IED that they map for their reporting for within the DHIS2 system. So basically this sample flow was intended to just, it's the simplest that we have in our use case in Uganda with just four data elements. And we typically just split and get the different data elements that we are looking for. But as Cloud will mention, maybe for those who venture into looking into the documentation, we typically, once we pick out these values for the data elements, we assign them names that are the same as the codes of the data elements within DHIS2. That's the way we've designed it, such that we do not do a lot of mapping between the systems. That's one of the advantages we have in this implementation that we do not end up building a mapping, but it's done by the integrator. If you name your data elements correctly within the flow, by just assigning it the code of the data element on the other side. So this, I don't want to maybe do a lot in terms of what it is like, but if I make a copy and just add demo in my simulator, I'm just copying an example message. Basically, the simulator will just show you what the way it has split them. And I know right now my screen is not very good in terms of size, but when you look at my simulator, it tends to split each of the values. You see, the new attendees attend, the total attendance is 15 and the mothers were expected five and then three that missed the appointment. I don't want to, because we can share the JSON file for those who have access to it, but I don't want to go into too much time of the demo, but that's it. I think I can hand over to my colleague Cloud. Yeah, thanks, thanks Sam. And actually thanks for mentioning about mapping. I was not going to go into it. So let me share again the screen here. Okay. All right. So, okay, we have given you a quick glance at how the demos set up. Now I'm going to showcase each of these of the each of these applications features. The first one is contacts synchronization. Here, I will show how the HS total rapid for the connector copies. The DHS to you there's into rapid pro as contacts. When it copies the users home to copy the organization unit ID, the user ID and the telegram identifier. It will insert them into the into the rabbit pro contact. And also as part of the demo, I will configure the context synchronization to happen every 30 seconds. So quickly quickly. Yeah, just to show everyone that there are no contacts in repito. I hope that everyone can see my can see my browser the contacts page. You can see there are no contacts. But if you go into the DHS to users page can see there are some users as our goal would be to copy users from here to to rapid pro. All right, I will bring my terminal up. You can see that I have actually three tabs in my terminal. In each step I will showcase the different different feature of the of the application of the connector. So the first feature I will showcase as I said is the context synchronization. This is the command I will be running to launch the application. The HS to rapid pro jar is the binary the application self which I downloaded from GitHub. I will use it with a number of parameters and the rapid pro API URL, which points to the server. Same goes for the HS to API URL points of the HS to server. We're activating the context synchronization feature using this parameter here by default, it's disabled. And we're setting how often how frequently the synchronization should happen here where I'm highlighting. So this is the first expression and it's telling the application the connector to run synchronization every 30 seconds. Now I'm going to run the application. And let's give it a few thoughts. It's going to start. It's starting starting it's initializing slowly. Yes. Has started you can see that it has started because we had we're seeing this banner. Now, if you give it a few more seconds, it should initiate synchronization. So from the locks here, we can see that rapid pro context contacts have been created from the HS to users and that's going to synchronization completed successfully. We can confirm this by going to the rapid pro page, rapid pro context page and hit the refresh button. And voila. Here we have a list of contacts which correspond to the HS to users. Let's zoom into Alice wonderland which is the user which we are going to test with for this demo. And in it you can see some of the details that were copied from the HS to the organization ID, the HS to user ID, as well as the telegram identifier. So let's go back to my presentation. All right. The next feature I will demonstrate is the overdue is the sending of overdue reports reminders from the HS to to rapid pro search from the HS to the to the contacts. We can assume that for example that Alice hasn't submitted her OPD weekly report using telegram. So we need to send a reminder for that. An automated reminder for that. And to do that, we, we pass a new parameter to the HS to the connector which identifies the data set, which identifies the data set for which reminders should be sent for. Now, I apologize for that. So let me go now back to the terminal. Let me stop the application. I'll go on to the new tab. I'm going to start the application again. But this time, I will start the connector with this new parameter reminder data sets codes which denotes the list of data sets that the application should send reminders for I'll start it now. For the purposes of this demo, I will fire the reminders manually, but reality production. You would be sending the reminders in an automated fashion so you have a job here and you would be it would be running every so often automatically. Remember, if reminders need to be sent and it does it starts and the reminders automatically, there would, there wouldn't be there wouldn't be any manual intervention from your side. Okay, so I've started the application. And I just want to show quickly that that the user that Alice hasn't submitted the OPD. The OPD attendance report. So let's go from, let's go check the report from the previous week. And here you can see that the report is empty. There is no, no values no were entered were sent from Alice. She didn't send her report as the report as always not matters complete. Okay, so I'm going to send now I'm going to manually fire the trigger to send the connector to scan for reminders and if there are any reminders that in the sense to send them to rapid process that they're dispatched to Alice's telegram account. Okay, I have to look into the connector first. This is the default username and password. Okay, there's a problem with my, there's a problem with Chrome unfortunately because when I tested it with. Okay, it was sent. All right, so I got notification I think that's any reminders that were supposed to be sent were sent. So we go from this that we go over to Alice's telegram account. And, interestingly, they were not sent. Drag. Drag again. Okay. Okay, this time I received it. I think sometimes the, I think since I'm testing from my web application I'm getting some funny, funny behavior from telegram. But yeah, this time I received, as you can see here, this is Alice's telegram account and can see that she received a reminder to submit her report. Let's now demonstrate define the feature which is the most exciting one I think the aggregate reports transfer. Now that Alice has received a reminder she should send a report. Now I'll explain and we send a report by sending a period, the limited message like this one you see here and this example APT period three, period five, period five, period two. So yeah, let's send it from Alice's telegram account. Just going to copy it from here. I've sent the report from Alice's telegram account and you can see this response sent by RapidPro which shows that it has parsed the message and that it has and process and process it as well. Let's confirm this. We go on to the HS2. We go over to the week, the reporting week, and it's already here. So I just need to actually hit the refresh button. Oh yeah, sorry. I actually forgot a very crucial step. Sorry about that. I had to start the application again with some new parameters. Sorry for missing that. For the application I have to tell the application which flows it needs to scan for the data reports for the reports sent to RapidPro so I'm doing that here. Let me start it. I'll just write that again. That's why I don't like to give demos too much because I tend to forget stuff. So I'm running the application. Okay, it has started. It's going to scan RapidPro for the data that was sent to it. Let's give it a few. I'm waiting for it to be scanned. Yeah, all right. Cool. These logs showed indicated that the RapidPro flows were scanned for data. They found reports and that the connector puts these reports in, transforms them into data value sets and pushes them into the HS2. Now, if we go to our data set here, let's select it. HMIS 0233B and let's select the last reporting period. Let's zoom into the section we are interested in, the OPT attendance report. And here you can find the submitted values that Alice sent from her telegram account. And that's it. Hopefully it didn't take too much time. All right. Q&A, questions? Yeah, thanks Claude. I think we can take a few minutes for maybe to ask some questions clarifying some aspects maybe of what you've shown. If people want to ask about new things, then I'd ask them to hold on that for a bit because we're going to have some discussion about new types of flows going forward. But yeah, so we have some time to take a few questions now. A very good question I see from Paul on how would power outages of the HS2 server affect this process? Well, I don't know if you want to answer that. I can take it because I think it's quite interesting. You demonstrated something by accident there, right? Where Alice submitted her report on telegram, but the DHS2 server actually wasn't running. Actually it was the connector that wasn't running. It wasn't running with the right parameters. So I think that's similar to what Paul is asking. So what happens if the DHS2 server is offline? And the way, again I discussed a little bit of this afterwards, but if we were using our webhook to transfer the results of the flow and there's some benefits to that, then that webhook would have failed because the DHS2 wasn't there. So instead what we are doing and we can do in combination is DHS2, when it's online, will simply pull RapidPro for completed flows. And I believe those completed flows are kept around within RapidPro for 90 days, something like that. So Paul, the answer to your question would be once the DHS2 has come back online again, it would simply pull and pick up the message. And just to add to your answer, if the connector is running and was able to pull down successfully the flow executions, but the DHS2 is down and it can't dispatch the reports, the connector has that letter Q as well. So it will persist these reports into its own death letter Q and the administrator can retry the reports once the DHS2 is online again. Good. I see at least two hands up. Alfred, I think yours was first. Alfred, you're... People can unmute themselves, but I'm just going to click on them. Oh, sorry, Max. They can't unmute them, can I? I don't seem to be able to. Yeah, I can do it. If you click more, if they've asked unmute, they'll do it on themselves. Oh, okay. So I've managed to unmute now. Well done. Thanks for the demo. This is very clear the subset of functions that you've been able to do implementing this integration layer. I wanted to know, is there any additional functionality that was part of the Uganda integration that you left out for one reason or another or one that you did not, probably not necessary to be backed into the integrator that you think is still needed for a good integration solution? Is there any functionality that you can measure so that colleagues are aware that perhaps they might need to maintain that those pieces of functionality in another component or another result? Short answer, Alfred, yes. As you know, the integrator in use in Uganda is based around this thing called M-Track Pro, which Sam knows most about. And I suppose what we've implemented here is a subset of that. And I think the plan in Uganda, and it hasn't been executed yet, is that we'd simply implement that part, that part of M-Track Pro that is doing what Claude has shown. But it would still push the messages through M-Track Pro so that they could continue to use a functionality that they have. I think the important functionality that brought our attention was the ability to inspect failed messages and to, in some case, edit or correct them and replay them. In fact, we do have that functionality, but I don't think Claude has demonstrated it here. Claude, is that correct? Yes, yes. Since we had a short time window, there are many more features I would have like to demonstrate, which we don't have the time, but it's all into documentation. I think the big feature they had with M-Track Pro, there's some others as well I know, but a big feature was dealing with the dead letter queue. And yeah, we'll have to save that one for another time to demo it, but it's in the documentation. Nana, you have your hand up as well. Okay, thank you. Good afternoon, everyone. Thank you for the presentation and the work you are doing. I just have some few questions. The first question is, when we launch the connector, I'm seeing that there is some parameter there. Will it be possible to launch the connector with all parameters, something that can put on everything so that we can have options on the way we wanted to share information between Rappi Pro and DHS2? That's my first question, because I just observed that we come there two times. Is it possible to launch it just once and then use it as frequent as we want? That's my first question. My second question is about where the data is going when it comes from Rappi Pro to DHS2. Knowing that in DHS2, we can have many sources of database. Will it be possible to specify a specific database so that we send our record from the flow there, or we should create a specific database for a specific flow? I mean, if I have two flow on Rappi Pro and then I want those two flow to send that to DHS2, then it will be the end on the DHS2. Should I have one database or should I have two database based on the two flow that I used to send that to DHS2? Then my third question was about the contact. I already have an answer for that one, so it means that when we take contact from DHS2, we can track a flow to redirect all those contact to a specific group on Rappi Pro. That is possible. Thank you very much. Those were just two questions I have for you. Thank you. Thanks, Donna. I think Sam has answered your second question in the chat. I'm saying it's possible to run it with all the parameters tuned. Yes, I ran it three times just for demo purposes, but in reality we just run it once with all the parameters. The other question, Claude, was about the database. Currently we're using an embedded H2 database, but that is configurable, right? Yes, so we actually support all of the box H2 and Postgres SQL. The connector comes with the database because it needs to store the state. For example, for the dead litter queue for the success log, the reports which we are successful as well and so on. Yes, you can change the database to another database like MySQL, though we haven't tested it with other databases other than Postgres SQL and H2. And you would need just one database for all the flows, yeah? You don't need to have, if you have 10 flows, you're pulling reports from your 10 databases. You'd have just one database inside the connector, that's it. And there was the third question which I didn't catch. No, no, I think that was the three. All right, thanks. I see there's more questions building up, but I think we need to move on. We'll have a longer session to discuss that we've decided afterwards. So let's move along. And sorry for those who have questions burning. Hopefully they'll still get a chance to ask them before we are finished. Let me just try to now think back. Okay, so findings and learnings that we had from doing this. And some might argue relatively simple workflow. Well, we learned quite a bit from it. And one of the things I guess is any of you who've worked through the rapid pro documentation and examples, you see a lot of reference to using webhooks. And that was certainly how our initial implementation was working. It's the same way that the current system in Uganda is working. There are some downsides mostly related to reliable delivery of flow results. And so what we found is by actually implementing both, both report via webhooks and polling, we can achieve some of the advantages of both. The other fairly obvious learning, I suppose, is that human readable text messages are really suited for quite small and timely data collection. I was reading the marketing chatbot providers like to claim that 90% of people read the SMS within a minute of receiving it. So it's very good for urgent timely data collection and certainly for very small data sets. And using it for very large routine reports, just because functionally it's possible to do, is probably not a good idea to do. And I think it's one of the things we found, particularly when we were piloting in Zimbabwe, that they were possibly a bit ambitious in terms of the size of data set that makes sense to transmit in this way. A little bit about channels. I saw somebody in the chat was already asking about WhatsApp. The reason why we primarily used SMS for at least the implementation in Zimbabwe was that they wanted to use SMS because they were dealing with a large number of feature phones and also had quite poor internet coverage in summer regions. But as we know, WhatsApp in particular is becoming quite ubiquitous. Telegram is really nice, easy to work with. And the good thing I suppose from the perspective of the integrator and the perspective of the EHS2 side of it, it really doesn't make any difference. It's a configuration matter on the RapidPro side which channel is the most effective to use. What else? The Apache Camel integration engine that we worked on turned out was very straightforward to deploy on a Ministry of Health infrastructure. That was important. It took a couple of hours to get everything up and running, working together with the Ministry of Health, IT technician who's fully familiar with how to do that. And because it's based on a fairly standard process of DHS2 doing integration routes, we do much more training around that including in fact what will be happening in the integration academy in Kigali towards the end of this month. The other thing we found is Zimbabwe wouldn't like to use RapidPro running locally on their infrastructure. This question has come up a few times. And we know that the normal usage of RapidPro, if you like, has been through some sort of cloud service. There's lots of advantages of that. Running it locally, there are some cost implications to do it in managing your own SMS gateways and there's system configuration and system administration implications but still people want to do it and that's because particularly as you integrate I guess the system within your Ministry of Health architecture of systems, issues of privacy, issues of control may become more paramount. We'll talk a little bit later about privacy and how it may be possible to mitigate some of these concerns. But for the moment certainly Zimbabwe are quite adamant that they want to run it locally and that's what they will be planning to do. The other thing we found of course the notion of a user in DHS2 it could be mapped to a contact in RapidPro. The only reason why that's notable is because in fact it turns out there's other kinds of things in DHS2 that could be mapped to a contact that I'll talk about a bit later. Always good to do privacy impact assessment when you're doing these kind of projects there's always some privacy implications to integration flows. The thing with this one I guess is a very small amount of health work at PII is shared in contact creation. In my view that could be even less and I can talk a bit about that later. There's no PII shared at all or captured in flow variables so no particular concerns there. Some of the cases that we looked at in the slides this one we've learned ourselves from and not looked a lot of detail but it's kind of taking a broad sweep up there. We know that OpenSRP and RapidPro as part of BID project in Zambia have done an integration there in support of the emailization registry. I'll make a few comments on that in the next slide. We see a very interesting use case in Sierra Leone using compressed SMS reporting in the DHS2 Android client and RapidPro. Again I'll mention it briefly. We know that M-Hero the M-Hero project which essentially at its root combines RapidPro and IRIS is the health work and registry. I was quite significant I think in terms of some of the things that they tried to do in that and some of the the learnings and patterns particularly around the use of fire which I think are important to learn from. The other case which we're actually quite closely involved in and I think Johann is on this call as well. Johann is one of the tracker team from Oslo. He's working with Hisp India on a neonatal hearing loss program in India which again we look at a little bit more detail. Let me just quickly run through those with one or two points from each. From the Zambia electronic immunization registry what emerges I guess is this kind of enabling feature if you think of stuff which is additional or different from what we've done here is that enrollment in the registry triggers some kind of contact creation in RapidPro and that's really the thing which then allows or facilitates sending of reminders adverse event reporting or whatever. The other thing that's characteristic I suppose of that implementation is OpenSRP is now based on a fire repository backend so interfacing fire interfacing the RapidPro using fire is seen as advantageous in that deployment. The DHS2 Android client in Sierra Leone I'll say the reason why this was interesting is we talked a bit about the limitations of SMS and particularly if you're talking about it being human readable or human typeable making these complex SMS encoded messages is quite tricky but people have used SMS in more innovative ways I guess and one of the things that's actually supported out of the box with the Android client is where there is no TCPIP internet access it is actually possible to take very standard DHS2 payloads from the data entry form and simply compress them and layer them on top of SMS messages and send them that way we're familiar with this eHealth Africa led project I think in Sierra Leone where they created some kind of gateway program which decompresses and reassembles the incoming payloads but those SMSs are coming through RapidPro so you might ask what's the benefit of RapidPro in that because there's no real complex workflow involved RapidPro is not really dealing with the content of the message at all the flow itself is very simple it's simply forwards but where we saw the value in RapidPro in there was really the contact list because I think by having the contact list in there they had a sort of way of gatekeeping to ensure that only valid numbers were participating in the flow other than that it's possibly a bit of a peculiarity but it's an interesting case of novel use of SMS here I think it's probably one of the more interesting cases and we've not had an opportunity yet to discuss it on what the detail with the eHealth people started some discussion around this again a little bit like OpenSRP the later versions of IRIS is based on a higher repository back in IRIS being a health worker registry so by by synchronizing the contacts in RapidPro with the workers in the health worker registry much like the flow of user synchronization that Claude illustrated conceptually then it provides the MOH with the background infrastructure then to be able to communicate by direction with all the health workers in the registry probably the most important learning from that project and stuff to look at is is the work that they did around different approaches of mapping RapidPro flows and contacts to fire resources neonatal hearing loss program in India that I referred to this one is interesting in the sense it's a small project at the moment bit of an ongoing collaboration between UIO, Hisp India and the hospital certainly the background is it's there to help parents easily ask questions regarding the infant's progress in case of possible hearing loss so the integration allows neonatal hearing loss program to use WhatsApp as a channel better through questionnaires, questionnaires with a small queue then seemingly store and analyze the data in the HIS2 those questionnaires are very simple again well suited to short messaging applications simple yes no answers small scale 30 to 40 enrollments initially in the one hospital enrollment in the tracker program triggers creation of RapidPro contacts again that's a similar pattern like what we saw with the Zambia immunization registry the much larger scale this notion of enrollment triggering contact creation the RapidPro flows themselves I don't have all the detail of but they're modeled after the HIS2 program stages which in some ways analogous to fire care plans not exactly but so the flows different parts of the flow were modeled by different program stages in the HIS2 the interesting thing because this is a small scale and I think there is scope for these small projects which are not necessarily huge national rollouts but the question of RapidPro hosting come up it's obviously not something that the hospital would want to do just to support this particular thing the way that's probably going to work is that HISB India will perhaps develop and provide RapidPro hosting service which would be used by this hospital and then perhaps others the question of provision of services in the cloud or in the basement is something that comes up all over the kind of flows that we end up looking at these different types of cases they can be grouped a little bit what we did with the routine reporting essentially the contact is the health worker and I think you can characterize a whole number of use cases where the contact is the health worker and there has some implications in terms of privacy and security and that's the types of data as well besides aggregate routine reporting a health worker may also be reporting data captured during an encounter it could be an enrollment or it could be what we call program stage data or even anonymous event data similarly where the contact is a health worker there's kind of output messaging flows besides just data collection most of which many of which people may be familiar with and we've talked a bit about in some of the previous cases sending reminders sending out instructions requests to conduct a follow up visit that kind of thing where the contact is not a health worker but is a subject of care or a patient or even a citizen at large if you like there are also opportunities for data collection maybe around self enrollment but also self reporting self reporting of symptoms for example as in the case of that Indian hospital whatsapp application that's referred to and also opportunities for output messaging including again follow up reminders medicine adherence information test results etc clearly when you start looking at this right hand column you can see that there are more significant privacy implications of those flows so I'm going to talk a little bit about about those before we move on to our final session all integrations have some kind of privacy and security impact SMS in particular has got a number of fairly well known limitations if you like if you look at things like GDPR and the way it manifests itself I know in Ireland I was looking at guidance for GP practices for example using SMS the recommendation is really quite minimal quite strongly regulated opt-in consent minimal or no clinical information quite a bit of concern for young adults where perhaps messages are going to the parents and in some ways it's impossible to mitigate for all of these but I think there are things that we can think about and particularly in terms of creating contacts where we're creating contacts in rapid probe programmatically for example synchronizing program enrollments and stuff like that we should certainly consider minimizing the sharing of unnecessary identifying data beyond what's required to operate the flows for example in that use case that Claude demonstrated there was no need to put Alice's name into the rapid probe at all it would be worked perfectly well to create the contact anonymously with just the phone number or the telegram identifier or the WhatsApp identifier whatever it might be and this kind of pattern in terms of sharing contacts between DHS2 and rapid probe is something we want to pursue probably less so in the case of health workers certainly when we start talking about tracked entity instances patients, persons and the like the kind of pattern that we talk about with DHS2 would also be relevant I think in the presence of a more built out architecture if you like where you're perhaps dealing with a health worker registry or if you're dealing with a client registry there's no need to share all of the demographic data of the client from the client registry into the rapid probe contact keeping things minimal it's about simply sharing I think what in fire terms is called the contact point which is just that snippet that refers to what's required for the electronic communication I think a stronger concern for privacy is also a significant factor in terms of building trust Ministry of Health to make use of cloud-based message systems we think back to the reservations that we know for example Ministry of Health and Zimbabwe have a little bit more about fire I guess there's really quite a bit of history of fire mappings to rapid probe I know again probably the most significant work that I'm familiar with is the stuff that's been done through Nero also we know OpenSRP been very active I think there are different approaches particularly to mapping flows and flow variables to fire resources I think that's the central problem if you like the problem with RapidPro I suppose it's not electronic medical record it doesn't have clinical concepts within its typing model so initially depending on the use case it might make sense to map those flow variables to observations and I believe that's the way they started out with Nero but it turns out that some kinds of data collections you're not collecting observations you may be collecting details for enrollment for example maybe it's a self-enrollment message so we kind of fall back on the questionnaire response as the lowest common denominator which can map anything to anything that has that benefit but benefit is obviously limited by the fact that then that structured mapping still needs to be made it translates the loosely typed questionnaire response to more semantically strong fire resources in a fire repository or indeed to DHS DHS2 native model automatic creation of contacts from a fire personal patient practitioner resource using as I mentioned very minimal contact point information is already a valuable thing to do and people are doing it I don't know if an approach has been standardised around it consensus around it that would be a useful thing and relatively easy easier to achieve I think than standardising some of the many variations of low variables DHS2 and RapidPro themselves I guess for various reasons historical and where things are placed in the market they are both on the periphery I suppose of what's a growing network of systems which are fire repository based we can see the open SRP and the new iris as examples of these within that network obviously the free exchange of seamless exchange of fire resources is relatively straightforward on the periphery there are translations involved we within the DHS2 team are actively involved in the development of of prior translations progressively as use cases arise it's an ongoing effort from what I understand from the work that has been done and some of the efforts that were being tried around 2019 there are still some difficult problems to solve in standardising fire mappings to RapidPro I mean it's obviously possible to do and you can make translations but to make translations which enjoy a kind of broad community consensus which address a broad variety of use cases there's clearly quite a lot of work still need to go into that it's work that we're interested to participate in we're probably not well placed to lead that kind of work in the sense that we are like RapidPro ourselves a little bit on the periphery some of the problems that need to be solved in that are very similar to problems that we need to solve anyway in the meantime there are many ways that DHS2 can continue to be used with RapidPro without fire or until fire and we're not letting that hold fans with the DHS2 connector going forwards I was going to be planning to maintain the existing cold base as long as it remains to be used we've talked of a minimum of a year and a half but if it carries on being used beyond that then we would maintain it beyond that and support countries who are choosing to deploy and use it the other thing we found is actually quite important is to raise awareness of RapidPro potential within our own HISP community I think we were a little bit surprised that perhaps some of that awareness is not quite as much as we would have expected other than in particular areas enhancing the RapidPro contact synchronization this is something we've talked about quite a bit in the presentation but we've seen how we can make a link with DHS2 users who are essentially mostly health workers but very soon on the roadmap is including tract entities that would be required for example for that Indian hospital project also creating new data transformers to convert different types of flow results to different types of DHS2 data the other thing was exploring new ways of triggering those flows currently what we've seen with the routine reporting I think with the routine reporting it doesn't really need to be triggered people know they have to report every month and if they don't report every month they get reminded but other types of flows need to be triggered we have different mechanisms to trigger them alright so you've heard a lot from me I want to pause there and give folk the opportunity to raise questions make contributions we have a number of people here who have volunteered themselves to participate in terms of assisting with that discussion I don't know Sam or Anga Evan Alfred we can mute you so that you can respond to questions and I think we can open up the floor again to any responses to what you've seen so far or suggestions about potential ways forward to collaboration this is their opportunity stop staring for the moment and I can see people Alfred here I suggest probably first go through the questions that were typed I've been seeing a few questions but I changed the machine so those questions have disappeared for me but there were quite a few questions in the chat as you were talking unfortunately I was talking Alfred so I wasn't watching Alfred can you can you say you don't have them anymore sorry I changed machines I don't have them anymore but there were quite a few questions Carl I see you've been I see you've been commenting quite a bit about the Liberia EIDSR project Is there some comment or question you want to make about that I'm trying to find you somebody help me find Carl so we can unmute him I think I'm off mute now can you hear me I hear you Carl that was unmuted no I was just commenting that that pilot unfortunately ran out of money and couldn't go beyond the county as it was implemented in but we worked with eHealth Africa on that project it actually was very interesting because you know in Liberia there are challenges around smartphone use because of connectivity but many folks of course have dumb phones we had to find a solution that was available via dumb phones and SMS messaging which of course is common with some of the folks in the outer areas so for the health facilities to be able to submit an alert via SMS was critical and so UNICEF and InterHealth had already worked with USAID on this implementation during Ebola so we leveraged that work with DHS2 Tracker and I was living in country then so that's why I have this knowledge it was a very interesting application because it allowed that initial SMS to do many things so that initial SMS code we had developed this code and of course each component of it represented the disease and the specimen et cetera but it would go through RapidPro it would hit IRIS as a phone book so to speak and would pull information from IRIS healthcare worker who sent the code and so they would have to include that information that was being pulled from IRIS and it would pull the information from IRIS and take it into Tracker and start a pending case within Tracker and then it would send a notification to the appropriate District Surveillance Officer whose facility that was in and create a pending case on their laptop on what we call an offline tracker and that would trigger the investigation locally and then as part of that process when that SMS would go out the suffix was an N or a Y for yes for lab specimen or no for not for lab specimen but within IRIS it was coded, excuse me, within RapidPro it was coded by disease on whether specimens were required or not so if someone put a no for let's say Ebola it would auto send back a message saying why wasn't a specimen collected and they would have to respond to that. If they did say yes a specimen was collected then it auto SMS the Dispatch Office for Writers for Health would dispatch a writer to go pick up the lab specimen and would also auto notify the lab that Ebola specimen was in route and so it did many different aspects number one it triggered the staff to investigate number two it identified the leadership of the Ministry of Health and infill based on the case and of course not going to let the DG know about every case that's coming every suspect case of whatever it could be a dog bite or whatever but if it's a Ebola case or a loss of fever case then leadership wanted to know so that ability to route messaging based on disease and then based on specimens was critical is critical for them unfortunately with them we ran out of funds CDC we ran out of funds to expand that across the other counties World Bank was going to fund some additional work and then that stopped and then I moved back to Atlanta and then the work kind stopped so it's just sitting there now unfortunately but I thought it was a very novel use of integration of M-Hero in that case and RapidPro with DHS2 tracker over absolutely Carl I think even though that may have paused a little bit on that project I think there's such a lot of rich learnings to be had from it anyway I'll have their hand on anything if you look back through the chat there is a it looks like we got up to I think Nana you answered that was a 440 of the fever came in after that might be worth responding to one from Egypt I see that's asking about reporting multiple entry and unusual data for multiple users we're going to see that one from Motas Thanks for the PowerPoint Egypt RapidPro is already established on national servers very good we look into the deployment of DHS and I've heard of that using RapidPro as data entry modality Bob there's a question there Sage thanks for the presentation from one Susan says which is the authoritative source if a contact is deleted from DHS2 does the sync delete the contact in RapidPro Good question I could answer it but let me give that over to to Sam heard enough from me Sam or Claude I can answer that so that actually was a gap we've identified recently so the authoritative source of truth is DHS2 at the moment if the DHS2 user is deleted the corresponding contact is not deleted it remains there but yeah actually that Bob pointed out in one of our recent meetings and I think it's something we need to support very soon I think in an ideal setting neither system would be the authoritative sort of source of truth if you're in the presence of a health worker registry for example that can be the authoritative source and both DHS2 and RapidPro we'd feed off that Bob it's good that you brought up the registry because the earlier question I posted points to that in the use cases where there is a presence of a health work registry does this connector still work is it a matter of consideration or it's not handling those cases well Alfred I suppose if you look at all those cryptic parameters Claude was typing when he started up the RapidPro we had to set a parameter I started up the connector he had to set a parameter to enable the synchronization of users with contacts and I think in a setting where you have a health worker registry where those details are kept you would simply disable that parameter so you wouldn't have that root operating of DHS2 acting as the source of contacts for RapidPro and you could write an additional route which could synchronize contacts from the health worker registry to DHS2 and all from the health worker registry to RapidPro so at the moment if you had a health worker registry and that was already synchronized you would simply turn off the behavior that's currently implemented I'd like to go back to this question from the participant from Egypt because that's an interesting thing will the system support more multiple entry of individual data the multiple users inputting or visit data I'm not too sure whether you mean what multiple users multiple users sharing the same device for data entry I don't know Moza I think this might be something we have to take up with us afterwards not totally clear if anyone else has a thought about it Bo could you answer the question the one of can a device be reused by several health workers to submit I'm not seeing the question read me the question I'm just reiterating the question you asked I know it may not be exactly the same question asked by the participant from Egypt but the question you asked is very pertinent to get an answer I suspect I know the answer but it might be for the benefit of others can a device be reused by multiple health workers submit report through RapidPro and that gets synchronized successfully to GHS multiple health workers sharing the same device I suppose that can I give it a go Bo yes I'll give it a go I have some thoughts but you give it a go I think that's possible it depends on where the health worker is reporting maybe with what organization unit or facility health worker is reporting for because I think that reminds me of what Bo pointed out in the scenario in Zimbabwe where a VHT would end up reporting for a maximum of about 3 villages and that means they would even if they were using the same phone they could report for multiple locations so what we look at is most importantly where they are reporting from because that ties to the organization unit so even if they gave a phone to their wife and then they choose a different organization unit or village that they intend to report for that report will be received on the DHS2 side but in our implementation what we do is we usually take note of the channel all the details of the reporter essentially we take the URL and the URL and the telegram will keep a copy of that if they are using a phone number will keep a copy of that but I think it can be used by multiple people yeah the problem would be and I think this is part of why the GDPR have got issues with using SMS is that you know when you open the phone you got access to the SMS messages there are no further authentication required and so if you had three people sending an SMS from the same phone you would have to explicitly somehow indicate who it was that sending the SMS if you wanted to have a proper audit so I think the case you described Sam is the other way around in a way that way you have one user but reporting from all locations but if you have many users reporting for the same location for example it's a bit of a tricky problem partly because you don't re-authenticate yourself on the device so once you have access to the device unless you are going to explicitly identify yourself as part of the flow I can't see how it would discriminate don't know if anyone else has a thought on that Alfred you had said you thought you had or you had some thoughts my questions are done is one other is one other participant that's the other before you answer that I wanted to let you know that Remy pointed out that we're getting to the end of this event so I might think of wrapping it up okay thanks Max, I see we are alright well thanks very much for everybody who's participated and also of course everybody who's been involved in the field testing from Ministry of Health in Zimbabwe in particular we will have the recording available for people to look at and share the presentations as well as you can see from some of the latter parts of the presentation there's quite a lot of scope for more work to be done on this we've really just been scratching the surface Remy informs me that there's possibly a workshop coming up in Uganda in May I hope that he'll share more details with us all soon but thanks everybody for being here I hope it's been informative and please get in touch with any of us afterwards or any more clarification or just if you have anything interesting you want to bring to our attention Remy do you want to make any closing remark yes thank you very much it was a great webinar well we are now moving toward the next phase to also address individual passion level data which includes individual reporting and longitudinal tracking of health records looking at the ecosystem and trying to to leverage existing platforms and you Bob you touched on some open SAP CHT and others and also looking at triggering messages through the HS2 and other platform using RapidPro as a backbone messaging engine so this is going to be the next phase where we are planning to have recommend gathering workshop in Kampala in May and I know that Bob and Tim has been working on some documentation that will be fit into the process that will inform the process for the recommend gathering workshop so stay tuned and we will let you know and you will be informed and also we will be this design document will help us to really move to the next phase to develop a mediator for individual data level okay thank you very much and I hand back to you Bob just to conclude and then we can finish the presentation thanks Remy, thanks everybody thanks Max for the support I think we can wrap up now