 So finally Ivan, who works for the Manson Unit in the UK. Ivan, I think he needs a cheer too. One, two, three. Hi, so Ivan more or less the same space as Manuel, so I'm probably not going to spend too much time telling you about the context because it's the same one. It's the shouting over the fence problem. And there's a gentleman right here in this room, a medical doctor, who called me from Sierra Leone saying, among other things, I have this problem, shouting over the fence. So we actually approached the exact same problem in a similar way. Now, there were actually three different teams in MSF, and thank goodness for intersexual cooperation, we actually knew about each other due to the innovation fair because there was a team in Brussels that did an application that was almost as good as ours. As a matter of fact, when we discovered what they were doing, we changed our trajectory somewhat to be complementary because what they were doing was really solving the most immediate problem. It was a very simple, very fast cycle, and we felt very strongly that we should be actually steering away from duplicating that, and we actually shifted it about what we were doing in order to be complementary. There was another initiative in MSF Switzerland with something called a scan pen, a pen that as you write it scans your movements, and that was an even more possibly flexible system but more sophisticated. We felt somewhere in the middle between a very simple, quickly developed thing and a very complex thing, the scan pen that's perhaps appropriate for clinical trials and really complex information, and we felt somewhere in the middle. Now, the environment, there are a lot of people out there who are developing apps for Ebola. I think there were household pets developing apps for Ebola, but not that many people were really thinking about the constraints, the infrastructure that's needed. So I've been saying to our colleagues in the tech world, we don't really understand the realm of the possible and what can be done with today's technology and today's coding environments, but you have no idea what our constraints are. The people in the Google office think that the internet is like oxygen. It's everywhere. As a matter of fact, in our environment, it's quite difficult to come across reliable internet. All of the same constraints that were identified by the other projects we found as well. And of course, there's a user. So as a little preview, some of the people that we brought in the project were the people who developed websites for the visually impaired and the dexterity impaired, which pretty much is the case when you're working in an Ebola center. So our goal was very simple. The same currency that was identified by Manuel and his team was the same currency we looked for. It's PPE minutes. The amount of resources it takes to get somebody for one minute inside of a high-risk zone in an Ebola center who's capable of providing patient care. We don't want any one of those minutes wasted doing anything other than patient care unless it's absolutely necessary. So primarily, we were looking for saving in clinicians' time. Secondarily, sure, it should collect more and better data. But actually, there's a wonderful comment from the epidemiologist working on the Task Force, Francesco, saying, if you serve the clinicians well, then they will use it, so we will have data. So what we actually really aimed for was a clinical tool to help medics do their jobs, rather than an epidemiological tool to collect data. So again, this question of the realm of the possible that the developers know and the realm of the constraints that we know, we actually had a lot of parameters that we imposed upon them. No dependence on networks, graceful degradation. Somebody asked earlier about what do you do when the system breaks? Well, if one part breaks, the rest needs to keep working as much as possible. Develop everything modular, so if the server breaks, you've still got the information on the tablet. If the tablet breaks, you've got the information on the server or another tablet. That's what we mean by graceful degradation. Modular, make sure that we don't design a monolithic system that you have to take or leave the entire thing. If, for example, the OCG team with a scan pen wants a local server, we developed one. So you can take any part of what we did and use it. And by the way, everything we did was completely open source, hardware, and software. It's all on a GitHub. It's for anyone, any agency, anywhere to use. The GitHub is a bit of a mess right now, but we'll get there. But it's, in principle, open to everyone. So the three elements that we thought of, as I said, everybody's developing applications, but what are the actual layers that need to be involved here? Well, the first layer is infrastructure. This is our server. When I first hear about a server client architecture, I go, oh, geez, and dependence on the internet. No, no, we can have a local server. And I'm thinking, oh, good, 19-inch rack mount thing with an air conditioner and a fan and a great big cable that has to go to the generator that can never stop. Kind of like the stuff that I can see in that back window there, these great rack mount machines. Well, it turns out, no, there's a little server, which is called an Intel Edison, which is the size of my thumbnail, got a big thumbnail, but nevertheless, this tiny little server that's actually a full-fledged computer. That thing is running a full GNU Linux operating system. It's a fully-fledged computer, a dual-core Pentium 500 megahertz computer, a bit like your laptop from five or six years ago. So suddenly, that whole constraint, if you can't have a client server architecture so that things on one device can propagate to another, ah, now we have one. For the first time in my 12 years in this field, that I can say, that's probably reliable enough. You can actually say to a doctor or a nurse, this needs to be running for you to do your round. The only time it did go down was when somebody unplugged it to charge their mobile phone, but we solved that one as well. So that's the infrastructure layer, and the next layer is actually hardware. So we found this tablet. We went into PC World in London, wearing PPE, but the poor fellow at the PC went, oh, I'm sorry, sir, I'm going to have to call my manager. And the manager came, don't worry, we're just getting stuff for an Ebola sentence here on the on. It's fine. That was a fun visit, but we came up with a tablet, which is waterproof, but consumer-level waterproof for playing with your friends in the pool. It's the Sony that you see on TV, people jumping in the pool. And then, with the help of Google and some volunteers from the tech world, we actually developed first a 3D printed and then a polycarbonate injection molded case. Polycarbonate, you make bulletproof stuff out of. I don't know what happens if you shoot that one. Probably doesn't work, but it's really tough and flexible plastic, so we actually turned a consumer waterproof and rugged device into one that I'm not going to do what he didn't throw at someone, unless you really upset me. But we developed something which is actually quite robust, and we developed things like wireless charging so that we can leave the thing always in the high-risk zone. It never has to come out, and we're actually safe for the infection control. For that matter, you can actually dip the thing in 0.5% chlorine, enough to give you a good solid chemical burn for 10 minutes, and it comes out of it just fine. And so, the third layer, then, we have, first, the infrastructure, which is this wireless network and the local server. We have the hardware around this ruggedized tablet, and then we have some software. Well, the software is basically trying to replace this paper chart. Same problem we had over here. How do we take that writing on paper, at least not take any more time if not go faster, but then eliminate the step of shouting over the fence? So on the left, we have the paper chart that was used, and on the right, we have basically the dashboard of the application that we did. Now, for those of you who know a little tech, what we really did was take some open-source frameworks. One is ODK, Open Data Kit, which Laura talked about this morning. The other one was OpenMRS, Open Medical Records System. So, to put it really quickly, we strapped a pig to a dog to a whale. We took Open Data Kit, and then we strapped it onto OpenMRS, and in the middle, we put a custom Android dashboard. So that's a weird thing to do, and it takes a lot of work. One of the principles of this kind of work is it's really complicated to make it simple. But we did, in the end, quite simple great big green buttons that you can see quite well even through fog ski goggles and you can use and you can touch with even wet double gloves. We did a lot of testing in the Ebola training center in Amsterdam and Brussels to make sure that this would actually work ergonomically. And when we hit the field, it actually did, pretty much straight out of the box. Rather astonishingly, here we have really enthusiastic adoption by medics, including national staff who were immediately taken with, oh, this is faster. The very first patient that we saw with this gave some information about his family that he needed to be transferred. He was convalescing and he had to go out and he had to tell us how to reach his family. He gave us that information, the pen didn't work. The tablet did. So literally, the first patient that we saw with this, the tablet outperformed the paper. No, I wish I could say it continued that way, but there were ups and downs. Broadly speaking, when we arrived, our intake was tremendous. However, it's complicated to make it simple and it took us quite a while to get this rolling. And sadly, by the time we did the pilot, well, happily numbers were going down. Sadly, we didn't get there in time to really help the large numbers of patients. By the time we actually deployed, which we did in Mag Barracas Sierra Leone, we put in a final deployment that actually was supported remotely. The Watson actually volunteered to be the maintainer and every time there's a problem called Google they sorted it out over the phone and that actually worked. We developed a really robust update system where you could just put a thing from an email onto a USB stick, plug it into the thing and it would automatically update and propagate to the tablets in the high-risk zone. So, amazing support, but again, complicated to get there. By the time we did it, thankfully the case of those was pretty low. I wish we'd been able to help more people during this epidemic, but we certainly got the opportunity to build something that's going to be really useful if it ever resurges, or if it comes up somewhere else, or for other kinds of pathologies. So, because it's open source, we actually shopped around a little bit to see who can help us with this, who can actually keep this from moldering on a shelf. So, Harvard Medical School very, very flatteringly said to us, what you've done with great big green buttons is going to revolutionize the health information system to industry. That was a quote from Eric Barakselis who has since actually volunteered to sort of lead a steering committee for this. So, there's a large open source steering committee, including ourselves, Google, the people who helped us build it, and the people who want to use it. So, Partners in Health is actually going to do a trial deployment of this since Sierra Leone. And interestingly, a lot of us in the movement are seeing the same other applications. For example, nutrition. Anything where you have a need to collect data, which ODK does very well, to see it right away and longitudinally track the process of a patient over time and in the back end be able to aggregate it, this is a system which can work for that. Nutrition comes to mind where there are tents full of shelves and the shelves are full of Tupperwares and the Tupperwares are full of records. So, this is the kind of thing that we're going to start working on over the next few months. I believe that we're about 50% of the way toward being finished here. We've got the application, we've deployed it. Okay, we're halfway there. Now it's time to generalize it. Make sure that users themselves can actually modify it for their new use cases. I don't want to have to call a developer to say, okay, we're going from Ebola to nutrition. An epidemiologist should be able to modify the forms in the back end database and the dashboard. That's still being specced out how we're going to do that. But it's definitely in the plans. And I think my favorite take home is that if we actually engage with the tech community, as products that we buy and deploy, we will fail. If we see tech as a community, as new ways of doing things and new ways of thinking and new ways of approaching solutions, and we work with them together as equal partners and we push and pull with them rather than just ordering things from them, we might not fail. In this case, we didn't. Yeah. We invested a little bit and Google invested a lot. So, unlike the previous project which was a modest investment, this was an enormous investment, but it was pretty much all from our partner who did not charge it for us and charge us for it and our donors didn't have to pony up for it. So, we got an enormous amount of free development and all of that is still in the public domain for everyone. It's all open source, even the hardware designs. If you like the tablet casing and the server casing, download the files and manufacture it yourself. So, that was an enormous piece of generosity from the technology world. And this is the kind of thing that I hope we can do more of. We also got a lot of assistance from around the movement. Jesse Burns from OCG actually put an enormous amount of work in ensuring that we were compliant with the standard Ebola dictionaries so that the data that we're collecting, even though it's in a very simple database, it's in the right format to interoperate with other people's stuff. So, we made some extra efforts for this to be extensible and to really work with other people's formats. And now we have it. So, questions, questions. Right at the back there, gentlemen in the black T-shirt, please stand up and introduce yourself. Hi, I'm Anas X MSF FLOG. I know who you are. Hello. Quick question. I know you wanted to keep things simple so that clinicians can use it. But in the data that you collected, was there anything that can be imported by the epidemiologists for a line list for contact tracing, etc. And if not, is that in the current plans for the future? Yes. You can actually access the tablets collected data. It syncs to the server. The server then syncs to all the other tablets and you can access it from a laptop. There's also a dedicated CSV export function which we consulted with the epidemiologists in the Madison unit, Jane Gregg who gave us the appropriate format to be able to be ingested by the EPI tools. We haven't fully implemented that but certainly it's built into the architecture from the very beginning that it should be exportable into standard data tools. Thanks very much. Questions? On the right-hand side. Please stand up. Introduce yourself. Anik Lenglet, OCA epidemiologist. Thanks Ivan. It's been great to see this because I haven't actually ever seen it. I have one here. I had a question. I think OCA missions in Sierra Leone are lucky in that there were a lot of epidemiologists on the ground. But if we translate this from Ebola to other settings and other projects most missions are not so fortunate to have that supply. You said that the Watson volunteered to take over the maintenance. I wonder how we should start thinking about project teams if we're going to start using this technology more frequently. I don't think we can rely on epidemiologists. I'm not smart enough definitely not to do this sort of stuff. So how do you see this being implemented in the field in a very practical way and mostly human resource-wise. It's not only for your presentation but for a lot of the things that were presented today. It's relying on a single person and a single motivation to get this stuff working. I think I still struggle to see how that can be scaled up. Good question. I agree it's usually problematic and it's usually problematic for a lot of the stuff that I work on. First of all I'm going to have to disagree with you on your own intelligence. I think that epis are all really brilliant and furthermore I feel that we should be systematically having a lot more epis in missions. When I was ahead of mission I always wanted to have a couple of epis around because boy it sure helps to understand what's going on in your context around you. That said like a good partner for us is because they have several billion users and no help desk. There literally is no one you can call to get help on their product so they must find ways to develop products that can be worked out by somebody out there in the world. We don't feel that we completely got there with this project but we think it's a good start in the sense that we put a lot of design work. Many of the people working with us weren't coders or programmers. They were artists and designers who actually sketched this thing out on charcoal paper so the attempt here is very much to create something that is usable by an epi, a medical team leader and maintainable. The sort of maintenance side by a Watson but the sort of medical data side it should be able to be managed by anyone who's able to manage the monthly medical report which is not necessarily a low bar but that's the intention. I think we're close. Please introduce yourself. My name is Mike. I work for Accenture in the Innovation Hub. Thanks. That was really interesting. Link back to what Kenneth talked about this morning and using big data. Have you thought about how we can use this data now that we're collecting and being able to collate more easily to help in future projects? One of the motivations for this was speaking with Armin Sprecher at OCB who's one of the important Ebola experts who said having had all of these patients far more than the total number of Ebola patients ever treated in the world prior to this outbreak we still know distressingly little about the disease itself. We're not collecting the data that could tell us all of the things we'd like to know. For example, at the time he says we don't even know if hiccups are a bad sign. They're a classic Ebola sign. We don't even know it's good or bad. We think it's bad. We do have a bit more information now. But the point is if we're not collecting that kind of information to troll with big data techniques, I'm not sure that big data techniques are that easily applicable to these kinds of data sets. But if we don't collect it, we'll never find out and then will we. So my hope is that one of the knock-on benefits, as I said, what I really want to do is provide better tools for clinicians to do their job on a day-to-day basis and save them time. But if at the same time that generates a better aggregate data set I hope that will be a knock-on benefit of adopting this kind of technology. Certainly when I was in the field, every project I was in I demanded that they put in place a digitization team. I wanted the registries from every clinic in Excel every day. For me it feels like you're flying blind if you're trying to make operational decisions without having the data in an accessible format and able to be queried. I have one last question. Please introduce yourself. Hello, good afternoon. So Clotille Rambeau from OCG. Hello. I'm very impressed by your work so thank you very much for this presentation. If I understood well what you did is somehow put in place a patient file an electronic patient file and I see what you did with the data management. One remaining question for me is did you add some decision support system, clinical decision like aid for clinicians to take better decision for the management of the patient? No, but I know there's somebody else in the audience who actually has a clinical decision making algorithm which is at least in the early version was based on some of the same technology so somebody perhaps you, Clotille, has actually built some stuff one of the reasons we chose OpenDataKit is we knew after having seen what you did and she built a system that you run through and actually guides a clinician to make better decisions and she'll tell you about that one of these days I was aware of that because of the innovation fair thank you, Maya and so that was one of the reasons why we chose ODK, knowing that it has the capacity to also add that kind of guidance and algorithm based medicine which has a lot of promise so that's certainly in the works that we can incorporate those kinds of things but stay open source as we said. Yes, I got it. Thank you very much.