90. Saving Lives at Scale: Part Two

Alex: It's somewhat similar to in the United States, where if you have a very popular application, you're obviously trying to optimize it so it doesn't take up a lot of room on the device, so it's easier to download. We kind of face the same optimization needs, but for two different reasons. There, we're trying to do it really because you typically would build an application to like a monolithic file. Maybe you have like one JS file, one HTML file, and maybe a vendor file. In these situations, we really have to shard them because let's say even a one megabyte download, if that thing fails, it's going to have to start over. If you break that into 10 different files and it gets through three of them and then for some reason there's an issue with the connectivity, when the application picks back up, it only has to download the remaining seven files and not start back over.

Alex: So one of those is really understanding the challenges of kind of bandwidth and poor connections and optimization. Other challenges have been with state-level censors and what they'll allow through. We have to pipe all of our, everything that we use through the THINKMD domain, we can't include any libraries from anywhere else. Everything has to go through our domain because we ran into issues where for whatever reason, certain libraries or certain things that we were trying to include kind of dynamically wouldn't work. There's always some little twists, depending on where we are, that we kind of have to be able to make an adjustment for and figure out.

Greg: For sure. One thing that I clued in on was that there has to be an offline section to this application or offline experience, because you said when the app connects, you download these files and you get it set up. But that would mean that if I'm out in the field, maybe I don't have connectivity but I still need to use the application. I'm assuming that with connectivity, I download the files that installs the application, and then I can go ahead and go out in the field and utilize it without a connection. Is that true?

Alex: Yes, that's exactly true. It was designed to be an offline first app, so using the progressive web application technology and service workers in the backend, the whole app can be downloaded onto the device. You kind of get the feeling of a native application, that's kind of the idea. We have some access to system level components that you would, if let's say you were creating an Android app, not as robust but some of them, which allows us to give a pretty good experience in terms of having it offline and not connect to the internet.

Alex: It will go through the assessments, store those assessments on the device for as long as there is no connection. Then once ... so a typical case would be someone who would leave a clinic, go into the field during the day, not have connection, do fifty, a hundred assessments where they would get a full clinical analysis, walk them through all the steps, explain potentially what they could have, any steps they have to take, action items — you know, taking the child to the hospital, giving them medication. All that would be kind of at the point of contact so they would have an action plan right there.

Alex: Then the data is stored on the device until they maybe come back to the clinic later that day or night and once the connection was made, it would upload it to our servers so that we could do all of the reporting and epidemiology and clinical review of the data, because we're constantly looking to see, ensuring, are we making the correct suggestions? Could there be any problems or issues with this particular location? If we're in a zone that's very prone to malaria or during the malaria season, that's definitely something that we want to look at to make sure that we're not under reporting or misreporting any kind of conditions that we may be seeing in the field.

Greg: Yeah. Another thing that I was remembering is some locations, they don't even have full-fledged smartphones. Right? They have what are called feature phones. How did you approach that? I mean, do you have to build outside of the iOS and Android ecosystem?

Alex: Yeah, so that was one of our reasons for doing a progressive web app and not doing an actual native Android app. I mean, iOS is really kind of outside of the scope of things because it's not common at all in the places that we operate so we're really on Android devices. The reason that we chose to do PWA is to potentially have that ability to work on feature phones. A feature phone, you can kind of think about maybe the first phone that you had, like a Nokia, something like that, that's very basic, however, offers an incredible battery life. Also is less likely to break, doesn't require a lot of bandwidth to use, so it's can obviously be very, very attractive. For us, we've looked at one of the mobile operators called KaiOS. They provide an operating system for a feature phone where we've gotten MedSync to work on it.

Alex: Now, the kind of challenges here, and we also have an API that essentially drives all of the clinical logic. It would work much like a REST API that you would, like a typical REST API. In fact, what we do is we have the REST API that has all the clinical logic and that API is then compiled into a library that is then loaded onto the device. So that same logic that drives our API is actually on the device and being used offline. That's a solution we've kind of had to come up with to be able to make it work offline and online, and provide some partners with the ability to roll their own kind of front end and just interact with their clinical API.

Alex: For the KaiOS one, it works because they have a Chrome browser, it works natively on their device, so that was pretty cool. There are some adjustments you have to make because ... like scrolling is an issue for us, the kind of ... or on a smartphone, to be able to use your finger to kind of scroll is very intuitive and obviously works very, very well. Scrolling is not intuitive at all. It's actually quite painful on a feature phone so that's a consideration we had to make. We had to get into a little bit more of mapping, so making sure that since you can't click on a yes, no, or a condition or observation the individual might have, we have to kind of map it to keys. So one is no, two is yes, that kind of stuff.

Alex: Then also, there's some clinical considerations too, because at the end of the day, that also adds a little complexity to this whole thing. We have to have it so it's a high quality application. It has to pass pretty rigorous clinical standards. I mean, the two founders are doctors so there's, I would say, zero compromise when it comes to them saying this is clinically accurate and it can go. We can't be like, "Well, this is good UX," or, "This is that." It's like, they don't care, it has to be clinically accurate. We have to balance all of that as we were looking at a feature phone, which certainly has been a little challenging.

Alex: We also have another implementation where it's via SMS messaging, so going direct ... essentially there is some worry about sending the community healthcare workers into the field and potentially bringing it with them and so there's been an effort to kind of almost pre-screen individuals that may be having an issue they would like to see as a community healthcare worker. So they're able to actually interface with our system via text messaging, where they answer a series of kind of questions, integration, then calls the API and then says, okay, you may have this condition and then we're either going to send a CHW or they're going to give you a call. So we kind of have to keep all those capabilities, things to, building as a PWA and just kind of knowing that we would need maximum flexibility in terms of what the application can do because there are so many unknowns. There's so many cultural differences, there's so many application differences, there's so many technical challenges. The idea is to keep the application as flexible as possible and not to actually paint ourselves in the corner by maybe making an Android application that can do these things, so that we could be very reactive to what was needed on the ground.

Greg: Yeah. That makes perfect sense. I assume that when that offline component can reconnect, then you're talking back to an application running on Heroku, correct?

Alex: Yeah. The Heroku has been really great in terms of not only ... I mean, obviously there's the whole technical component and scaling and stuff like that, but also the kind of point and click dev ops that's offered through Heroku has been just great for us. I mean, a lot of the times, before we do an implementation, there has to be quite a bit of reviewing that goes on. Not only just the language stuff, because most of the languages, we have some language capabilities in the office, but we can't obviously cover all of those languages. So there has to be a pretty thorough link linguistic review, there has to be a pretty thorough review by the implementer to make sure it adheres to whatever standards there or whatever study they're trying to do, and then there has to be a clinical review by potentially one of the doctors that's part of that group.

Alex: Being able to spin up a review app, do all of our changes in that review app, and then provide that link to one of partners to review everything, knowing that everything that's encased in that review app applies to just this implementation, we can get it looked at, we can get it tested, we can have it fully reviewed and signed off before doing the integration into the code and then pushing it live is really, really great. We've definitely leveraged that part of it. Also, as a small company, not having to have a full dev ops person on staff and yet being able to have all that functionality has been just awesome. Me, from a pure technical level and I think all the other people in our company, the project managers, Barry, to review the clinical logic, everyone else I think has been very pleased with what we've been able to do in terms of leveraging Heroku to get our applications into the hands of the people that need it.

Greg: I'm sure these review apps allow you to do a lot of QA on not only the localization, but also, like you said, the clinical accuracy of what you're delivering.

Alex: Yeah, definitely. Then also having multiple applications running has also been great. For us, being based outside of the US for most of our implementations is kind of critical. The first instance of Heroku, of course, I made in the US because we were moving from an alpha to a beta build, and then we started ... and I said, okay, we're going to see how this works, because for the most part, the application runs offline. So the first time you do that initial download, it's on the phone and there is not a lot of interactions with the server except to give the data back. But started running into some issues, just some routing, latency issues, and so I said, okay, I need to move this into somewhere across the pond there to get a little closer to Asia and Africa. I mean, couldn't have been a simpler system. I just spun up a new Heroku app in that new region. I create a follower database to move the database over, and in a day, we were live in out of that, I think, your Frankfurt location. The next day, it was worked a lot smoother, that little bit of reduced latency made a huge deal on the ground.

Greg: What is the QA process look like? I'm sure it's pretty stringent, but can you kind of go into how stringent it is and what sort of guarantees you're giving to the local ministries that you're working with?

Alex: It's incredibly stringent, for multiple reasons. We're treating this as if it were a medical application and so therefore we're treating it as if we had to adhere to the USFDA standards in terms of testing and quality assurance. That means that there's definitely a lot more paperwork involved in it which is part of the quality process, ensuring that we're doing everything that we can to ensure a quality product. Having the proper sign-offs, having the proper review, having the proper structure in which we develop and release code to adhere to that.

Alex: There's also the idea that our software is out there in the field and can mean the difference between life and death for somebody. We also have kind of like that ... I would say the two founders are doctors, that Hippocratic oath, right, to do it as well as you possibly can and ensure that what we're putting out there is a quality product.

Alex: Finally, too, I think there's been a lot of issues sometimes with software that's not that good that has been kind of deployed into lower middle income countries that has not worked very, very well. It has been a huge problem. I think there's definitely a sensitivity to that, both on our parts and also that of our implementers and partners that they want to be sure that what they're going to be using is quality and good.

Alex: We've done everything we can on our end to ensure that. That's not saying that there's no bugs that get by and things like that, sure. But obviously, it's top of mind to ensure that what we put out in the field is of the highest quality. Besides adhering to the FDA qualities process, we have an incredibly rigorous series of tests on the clinical logic that test potentially every edge case, every potential combination of logic, every way that we can to try and, for lack of a better case, break it, to ensure that we never get a false positive in that we can be assured that when we do push it live, that the clinical logic is as bulletproof as we can make it.

Greg: That probably goes back to something we were talking about in the first episode where overcoming kind of the trust barrier and the cultural barrier, having that quality product, and being able to show that it does work and show evidence that it has worked in other locations can probably help push you over that trust barrier and get folks at least nodding that, yes, this is something that they want to explore more.

Alex: Yeah, for sure. The company is full of people that have been working in this field for a lot of years that have built up great relationships with NGOs, with the other implementers. We have, I think, a very good reputation out there based on the ones that they brought into the company and then the kind of the ongoing success that we've had with our implementations that help kind of build that.

Alex: We started off with a relatively small, I think the first few times we did our, we put MedSync out in the field, it was maybe a few hundred assessments, and every single time it's grown since then. We've used the data to validate the clinical logic, we've published numerous research papers kind of explaining and showing that what we have does work, that it can be trustworthy, and it's kind of grown from there. But certainly, trust is a big part of success, I think, in this ecosystem.

Greg: Another thought I had was that the localizations you have to do ... I mean, I've worked with some apps that are localized for different European countries and I've seen those customers of mine have had to spin up 30 different applications, each for a different locale because they were so different and the code bases would be slightly different. How do you approach that, being in all these different countries with all these different cultural norms and all these different languages, how do you approach that localization problem?

Alex: Localization is definitely nontrivial. Besides the just language part of it, you also have the numbers and digits, which can be a little challenging. When we built the app, we decided to use Vue.js to drive the front end. That has proved to be a very, very good decision between Vue and Vuetify, which is a wrapper around Google's material design, has really helped us with the localization part because the Vuetify kind of has built in right to left. So that solved that main issue of having to flip the entire user interface, the application, for those right to left languages. Not having to worry too much about the front end, knowing that it was kind of baked into the library that we're using allowed us a little bit more flexibility on the back end to think about, okay, how can we essentially do this right.

Alex: The long and short of it, the solution isn't perfect, but we're able to not only be able to translate the app into, I think we're at like 13 or 14 different languages now, but able to consistently add translations by having a very clear definition of what is kind of like generic language that's for the application and what's specific to partner implementations, and also being able to use a partner that helps us with the base translation.

Alex: Typically, what we'll do is if we know that we have to go into a country we don't have a translation, we can export all of the tokens in English or the application. Our translation partner takes the first pass, does as good a job as they can because some of the language is technical, some of the languag is clinical, but let's say they'll get 80% of it translated. Then we actually, as you say, we both hand that spreadsheet to the partner that we're working with so they can review, but then we put in the application also. So we load that up so they can actually see it within the context and then they'll go through and help us make any edits or changes that are specific to their local and region.

Alex: Knowing that there can be a lot of very nuanced changes, we built that into the application, the ability to be very, very specific about languages. We may have potentially two applications in two different regions of the same country and they may have, not a lot, but maybe like 15 or 20 different changes in the language. We're able to handle that and roll it out so that they can have really fine tuned localization of whatever language that they currently need or potential dialect that they want to implement in.

Greg: That's awesome that you're able to deliver that much of a targeted experience where you can, like you said, target two different regions that are fairly close, but have similar but different dialects. Do you have on the back end, do you have different applications that deliver each of these or are you using some sort of a abstraction layer across the single application?

Alex: No, this is a single application and it's kind of, modelled as a software as a service. So it really comes down to the configuration, right? The front end is pretty ... I mean, dumb is the right answer, it just has all the front end code and it's expecting a configuration file. That configuration file is what really drives the application. It sets up the languages, it brings in the translation, it will dictate what are the conditions and tracks, because there's different questions that you want to ask for maternal pregnancy, post-pregnancy versus a child versus a newborn. So those are often figured based on working with our partners, saying what their target is, what they're looking for, the conditions that they're looking for specifically. All of that's part of the configuration process and then gets sent to the app in a config file, which then drives the front end from there. In there would be the language choices too. In certain areas, we may just need two languages. In others, like for our COVID tool, we have in the 13 or 14 different translations. So that's all configurable for implementation.

Greg: Any advice you'd like to give to anybody who's looking at building a multi-regional application targeted at the sort of low latency countries like this?

Alex: Yeah, well, I think we just talked on it. Really understanding the language localization and building that in from the beginning is critical. Ensuring that there's a pipeline for not only adding languages, but getting them translated and updating those translations kind of has to be thought of from the beginning or it's going to be really messy because you're going to go back and having to constantly kind of fix. I say that because we rewrote the language thing, I think, three different times. I think this time, we finally got it, maybe not right, but we're probably one rewrite away from having it dialed in. That was a consideration that I knew going into it, I just didn't realize how complex it was, especially with all the clinical logic too, because all of the treatments and the dosings and stuff like that, they are also all can be localized.

Alex: That's definitely one step of it. The other consideration too, is definitely, as I was saying before, it's funny because the same needs for optimization of the code, the code base, the downloading the application, are needed in this ecosystem just as they are in a modern one, but for very different reasons. Right? So because of bandwidth, because of latency, because of bad connections in older devices — a lot of Android 5, Android 6 devices are still floating out out there. Kind of understanding what it means to really optimize an application and bring that to the forefront is kind of critical from the beginning because a lot of times we have a tendency, and I did also, of kind of building something first for functionality and then going back in and saying, "Okay, now I'm going to potentially optimize that."

Alex: The issue with that approach is sometimes you paint yourself in a corner. There's things that you should have really valued before you started building that maybe you pushed aside saying, "Oh, I can fix that later," and you realize that, "No, I really can't fix that." So really understanding that optimization has to come first, localization and cultural stuff has to come first when you're going into this, I think would wound up saving someone who's trying to do the same thing quite a bit of time moving forward.

Greg: Thank you joining us on these two special episodes of Code[ish]. I know that I learned a lot about the challenges of building a globally distributed platform with very low bandwidth requirements - sometimes unconnected bandwidth requirements. And also about the reasons for building such a platform. Til next time.

Alex: Thanks for having us, Greg. It's a pleasure.

Meg: Great. Thanks a lot.