 All right. Well, thank you, everybody, for coming. That's OK. My name is Theresa Covell, and I'm the co-founder of an early stage startup called Neopenda. And I'm going to be talking about our project, Leveraging IoT Biometrics and the Zephyr Real-Time Operating System for a real-world high-impact application, Neonatal Nursing in Uganda. So here's just an overview of what I'll be going through today. We'll start with talking about the problem that we're trying to address, then an introduction to what we're trying to do. Then we'll look at some of our stages of prototyping, the selection criteria, the process of developing with Zephyr, and then look at some test results in our Android app, and then the timeline of development. And we'll talk about some issues that have come up, and then end with the conclusion. So the problem that we're trying to solve with this device is high newborn mortality in the, we're trying to address, is the problem of high newborn mortality in the developing world. This is a big global challenge right now. How do we reduce deaths from preventable causes during the neonatal period, which is the first 28 days of life? So the scale of this problem is vast. There's 46 million newborns every year in the developing world that have complications at or around birth that require a special care and special treatment. So about 3 million newborns are dying every year in the developing world. And the WHO estimates that 80% of these deaths are because of causes that are deemed preventable and or treatable. So this is happening all over. It's happening in places like this special care baby unit in the National Referral Hospital in Uganda, where I took this photo last year. So what's going on here? Why are newborns still dying at high rates from preventable causes? Well, there's a lot of complex and overlapping factors that contribute to neonatal mortality from things like a lack of good prenatal care to difficulty getting reliable transportation to health facilities in time to actually getting high quality care in the health facilities themselves. So ultimately newborns are most frequently dying from three major preventable causes. And that's complications of preterm birth, complications of birth asphyxia or interpartum complications and severe infections like sepsis, tetanus, pneumonia, diarrhea, things like that. So we decided to focus on targeting that problem of getting high quality care delivered in these low resource facilities themselves. The problem that we see in these hospitals is that there's just so many critically ill newborns that need care and need attention and treatment and not nearly enough nurses and doctors and equipment and supplies to meet that demand. So in an over capacity newborn unit, you might see two nurses working at a time and they're responsible for 50 or 75 babies at a time. And that ratio is not gonna be good no matter what sort of resources you have, but the equipment that should be standard like vital signs monitors is often just prohibitively expensive in the first place. So given all these challenges, what can we do? Well, newborn mortality is a solvable problem. In fact, the UN sustainable development goal number three, it strives to end preventable newborn and child deaths by the year 2030. So this sounds pretty ambitious, but what it means for newborn mortality is getting that NMR rate down to at least as low as 12 out of a thousand life births. For reference, the rate in Uganda right now is 19 out of a thousand life births. So with this sort of current push for advancing newborn health, it makes visible a lot of opportunities for innovation, which I find very exciting as an engineer. So with the rise of like IoT and small low cost embedded technologies, that means that we can sort of reimagine what's possible in global health. So these new IoT technologies, they offer a lot of benefits like being easy to implement, scalable point of care and getting better and better at meeting the cost and power constraints of low resource settings. So where can technology make a difference specifically in newborn health? Well, most innovations and initiatives right now are focusing on preventing or treating specific disease states. So we've sort of identified a gap in between there in the continuum of care in helping facilities and nurses better manage the large quantities of patients that they have to deal with and help them make more efficient use of the personnel and supplies that they already have. So we know that early detection of distress is really key in newborn care to helping get effective treatment to the babies in time. However, right now in these settings, monitoring and diagnosis is a big unmet need. So to us, that means that there's a lot of opportunity for innovative tech to have a high impact. Excuse me, I think you're lagging or you're running against your microphone. Oh, sure, I'll take that, thank you. All right, let me know if there's too much feedback. I can kind of hear it. So basically that's what Neopenda is trying to do. We're an early stage global health tech startup. Our mission is to engineer innovative healthcare solutions that give newborns in low resource settings the healthy start that they deserve. So my co-founder, Sonia Sean, I started working on this project while we were graduate students in biomedical engineering at Columbia University about in early 2015. So we got some initial funding from Columbia to continue working on our device. And over that next summer, we formed our company and we went to Uganda to do a needs assessment and really understand the needs and conditions on the ground. After that, we were selected for an accelerator program in Washington DC called Relevant Health. And then this past spring, after we graduated, we started working on this full time and we recently spent some more time in Uganda and now we're based out of Chicago, Illinois. So our funding partners include Cisco and the Vodafone Americas Foundation. And our in-country partners are the Uganda Pediatrics Association and the St. Francis Hospital in the Sambia. And now we're excited to be working on this project with the Zephyr project to explore some, you know, exciting opportunities for our technology. We aim to be a part of transforming healthcare through the power of innovation and show the kinds of good that these cool, clever technologies can do when they're applied to really important problems. So how are we using IoT Tech for newborn health? Well, we're working on developing a wearable vital science monitor that's designed specifically for newborns in these low resource hospitals. So it's a wearable device that measures heart rate, respiratory rate, blood oxygen saturation and temperature. And we've validated with neonatologists both here in the, or both in the United States and in Uganda that these four vital signs are really important to track in critically ill newborns because they indicate dangerous signs in the baby when their condition is changing and they provide clinicians with more of a thorough picture of their health status. So the technology, it's using reflectance pulse oximetry. So it's gonna be located, it's gonna be attached to a baby hat because the literature suggests that the forehead is an optimal location to accurately obtain this suite of vital signs with these sensor types. So we wirelessly communicate from the wearable to a central monitor that's deployed on a tablet or a laptop or a smartphone. And then health workers can view the health status of all the babies that are being monitored in the room and be alerted in real time of newborns in distress. So this will enable health workers to better triage their patients and know when there's urgent emergencies that they need to attend to as well as just have more detailed information to guide treatment and diagnosis. So the key constraints for this product are that it needs to be wireless. So these devices, we know that there's sort of dozens of newborns in the ward that may need to be monitored and we want to be able to monitor them all with a single, with a single central monitor, which is kind of the most cost effective way to do that in these hospitals. As well as when you have babies in this sort of chaotic environment, having a lot of wires around can get hazardous. It also needs to be low power. Power is an important constraint in developing countries. We get power outages happening in these hospitals a lot and there's voltage in fluctuations and things like that. Affordability also very important. The price point needs to be low to deploy in a low resource setting, obviously. And then the ruggedness of the wearables themselves, I need to be able to withstand the sort of environmental challenges of dust and heat and humidity as well as the constant wear and tear. Lastly, scalability. So we want to be able to monitor many babies at once, like I mentioned, and then in addition to that, the system needs to be applicable to different types and sizes of hospitals as well as in different countries because we know that the need is very widespread. So with this vision and these constraints in mind, we started doing some prototyping. Our initial prototypes, we built with the Arduino hardware on Arduino Uno. Then we tried to cut it down to just the AT Mega 328 microcontroller and sort of breadboard the whole system with only the essential components and that's what's in the top right picture there. We initially were using the default Arduino software and for sensors, we built a pulse oximeter with just LEDs and photo detectors as well as a temperature sensor. And then we initially started off using WiFi for the communications because we are more familiar with it at the time and because of the extensive backing for WiFi. The communications architecture at the beginning, we were just sending these four part vital signs data packets over WiFi to an HTTP server deployed on a Windows PC. But there were a lot of things about these early prototypes that we knew we wanted to change. One of the main things is that we knew for the final product that we wanted to use Bluetooth full energy because it's just so much more appropriate for wearable devices, especially in terms of power consumption. So we're becoming more conscious of power management being a need for this product. It also really raises less questions about the risk safety risks with the amount of radiation that's emitted by WiFi. We're also wanted to start sending to different types of clients. So we don't want to be limited to a PC, but Android devices, smartphones and tablets and such. And then lastly, the size. So we know that this device ultimately needs to be very small because newborn babies, especially prematures are just very, very tiny. So we wanted to be conscious of that as with our decisions moving forward. So by partnering with the Zephyr project, we've been able to explore how cutting edge technologies like the Intel Curie module with the Zephyr RTOS can be used to get us closer to a deployable product that still satisfies the constraints of this application. So the prototypes that we have with us today, they're using the Arduino 101 Development Board, which includes the Intel Curie module, which is a low cost SOC designed for wearables and the Zephyr kernel. So Zephyr turned out to be very well suited for this application because of its modularity and its design for resource constrained systems. The sensors that we have on this prototype, there are a pulse sensor from pulsecensor.com, which we're using obviously to get the pulse rate. And then we also developed and implemented a algorithm to derive respiratory rate from that same pulse rate data. Then there is a lily pad temperature sensor, just a thermistor temperature sensor off the shelf. And then for pulse oximetry, we have breadboarded a sensor using red and infrared LEDs, as well as a light to frequency converter. And that's how we're getting the blood oxygen saturation measurement. We decided for this prototype phase to go with the off the shelf sensors in order to reduce the risk and so that we could sort of leverage the extensive amount of feedback that's out there from the Arduino community and the existing sample code that's out there. So these prototypes are using Bluetooth Smart, the CURY module has BLE integrated into it. So we're communicating over BLE to an Android based mobile application. So let's dig a little deeper into why we selected the CURY module and the Zephyr RTOS. So for CURY, it's low cost, low power module. It enables us to make accurate DSP measurements with the 12 bit analog digital converter using the sensor subsystem array. It also has a built in Bluetooth low energy radio, which I just mentioned on the previous slide, but it ended up being pretty advantageous for us because the sort of the interface between the host processor and the BLE was already there. And so we think that saved us a bit of dev time as well. There's also built in accelerometers and gyroscope sensors and a pattern matching engine. So that holds some potential for us for further development if we decide we want to measure additional things with those sensors as well. And then lastly, the size. So the CURY module has like an 11 by eight millimeter footprint, which is pretty small. And it's not going to be limited to the large Arduino 101 in the future. So we liked that it was pretty small. Next, the Zephyr kernel. So Zephyr turned out to be a big step up from just Arduino software for us because it can support the ArcCore, the DSP subsystem and the X86 host chip of the CURY module concurrently. Whereas Arduino can only run on the DSP subsystem. The Zephyr kernel also supports multi fibers and interrupts for complex sensor manipulation and communication. So it's able to cleanly handle the data coming in from across all these different sensors simultaneously, whereas with Zephyr we could only handle one single background task at a time. Next, the X86 chip, it has more RAM, ADK I believe for supporting complex BLA applications when you're dealing with multiple sensors. Again, Arduino, it only has the RAM available to the DSP subsystem. We also benefited from the rich support for drivers that are already embedded out in sensors as well as Zephyr's sample code and a reliable software development kit with cross-tool chain. So we'll look a little more at our experience of developing with Zephyr. So that Zephyr SDK, when using it we found that there's already a board support package for supporting the Arduino 101 with tool chains to compile for the DSP subsystem and the host processor at the same time. So this enabled a quick installation of the compilers and tool chains in just a couple hours. And we're also able to get the GDB debugger working with both the DSP subsystem and the host processor. We use the Eclipse integrated development environment running with the GDB for debugging. And then thanks to the open source nature of Zephyr there was a lot of sample code out there for us to look at for using BLE. We were able to use the peripheral HR sample, for example, as a starting point for getting our pulse rate measurement working. So we're able to start with that code that was originally just supporting the DSP subsystem and then expand that for our measurement. All right, so the measuring the four vital signs that we can go dig a little bit more into this. So the first two, the pulse rate and the respiratory rate were both calculated from the AD measurement using the pulse sensor.com sensor. We used the ART core, the sensor subsystem to measure the analog input using the ADC driver. And we did have to do some adjustments to the AD measurement to support the 12 bit AD resolution. Next for temperature. So we took those measurements with the lily pad sensor like I mentioned before, the MCP 9700 sensor. We partitioned the ART system so that it would support multiple tasks. So we split the pulse rate and the temperature rate measurement into separate tasks. And we also had to do some calibration adjustments to support the 12 bit AD resolution. Next, the pulse oximeter. So remember this is the not quite off the shelf one. We breadboarded the red and infrared LED and the TSL 235 light to frequency converter. That's the part that actually measures that it reads the light intensity. So we multiplexed between the two LEDs to calculate the absorption ratio and use the GPIO driver and its callback API to calculate the frequency. And on Zephyr, we were impressed with the repeatability of the driver in getting that frequency measurement from the TSL 235 part. Whereas with Arduino, we saw a lot of variation with that measurement. So I've diagrammed the data flow here so I can kind of walk through it. We start with those three sensors that I've just described. And then on the ART core, we're doing all the calculations for those measurements. And then we use the IPM driver to communicate and send the data from ART core to the x86 processor. The x86 processor is responsible for sending that data to the BLE stack. So for the Bluetooth communications, we use the heart rate service for sending the pulse rate measurement. And then we just appended onto that, the respiratory rate measurement as well. Next, the health temperature sensor. Obviously we use that for transporting the, or for sending the temperature measurement. And then we added on a new Bluetooth GAT service to support the Bluetooth specs for the pulse oximeter measurement as well. So this is all ultimately getting to the Android app on the Android devices. So we use the NRF 51, NRF 51 tools app to receive and verify all those measurements. All right, so how did this work out? Here's some preliminary test results for the pulse rate and the blood oxygen saturation. This is as they're displayed on the Android app. We did this testing just by putting the sensors on adult fingers for now. And we determined the accuracy by comparing to just a commercial pulse oximeter and a commercial thermometer. So pulse rate, we found that our readings were pretty much identical to the commercial pulse oximeter. And then for respiratory rate, there's still some assessment for this one, but we're seeing a consistent 20 to 30% offset from the true value. Next, for temperature, we are finding a variance plus or minus two degrees Celsius when compared to that commercial thermometer. And then blood oxygen saturation. We're still toying with some stability issues with this one, but we're seeing the resolution be about the same as on the commercial pulse oximeter, but it doesn't track as well at low levels right now. All right, so this is all being visualized on the Android app. We were able to get a basic Android app running pretty quickly. Its main functionality is just to receive and visualize all that sensor data. So the three main functionality of it right now is the first panel is just visualizing the sort of active devices. We're hoping right now it should be supporting up to 10 what would be patients. And then it also needs to display the real-time sensor data and display trend plots of the historical data points, which will ultimately be very valuable to clinicians. One of the next steps for the app is gonna be implementing an alerting protocol. So we wanna be able to initiate audio and visual alerts when the vital signs go outside of a preset threshold range. So that'll be one of the next steps as well. So we included a timeline to sort of give an idea of the amount of development effort that went into this. We did complete this project in under three months. It took about a week to ramp up on Zephyr. Getting the pulse rate measurement going on Zephyr was about a week as well. And then adding the respiratory rate onto that was another couple days. The temperature measurement on Zephyr was about a week as well. And then pulse oximetry, since we had to do more hardware work with that one, it was about a week and a half. And then to communicate and display the measurements for all four of those on the Android app was about two and a half weeks total. So we had to look at some of the issues that came up during development or that we anticipate with this device. The first is the overestimation of arterial oxygen saturation in subjects with dark skin. So the literature suggests that there's a predictable overestimate in the oxygen stats in subjects with darkly pigmented skin, especially during hypoxia. And with hypoxia we mean in the blood oxygen level is low. So we're gonna be seeing this a lot in the field with the newborns, because a lot of them have, you'll suffer from birth asphyxia or they're premature with underdeveloped lungs. So we wanna anticipate those challenges. The, an additional, a related challenge that we foresee is that there's evidence that cerebral pulse oximeters may induce more variation during hypoxia than the finger pulse oximeters. So without, they see a dynamic change in the absorption ratio during hypoxia, which requires some additional adjustments to the calculation. So these, these first two issues, there with their need to be solved in the software with calibration once we start to collect more data. So we think that we'll need to implement a calibration protocol where we can sort of get a stable measurement on each new wearer to maximize the accuracy. The next issue is the complex sensor and data manipulation. So for this one, I kind of touched on it earlier, but it has more to do with the device requirements and the selection of the hardware and software platforms. Since we're running three sensors in parallel, there's, we're using a lot of the functionality of the RTOS that we thought this might be an issue because we have so many concurrent tasks like reading the data from the sensors, sending the data between the two cores, pushing it over to Bluetooth. So we're concerned that this could be, you know, using too much of the capacity of the RTOS and kind of reach its limit. However, we chose Zephyr because of its sufficient sensor driver support like I talked about earlier and its software can support these multiple sensor measurements and simultaneous background tasks. Next, the, or lastly, the power consumption and extending the battery life. So I've talked about how power is an important constraint with this project and there's still a bit of work to be done with power as well. I skip Bluetooth, I'll go back. So with power, we're, these prototypes are currently running on the, on just a nine volt batteries, which we know we don't really want in the long run. We want the, in the final product, we aim for it to be able to last for like five days of intermittent to continuous use. But for now it's been fine while our priorities have been implementing Zephyr and getting the, all the sensors working. So back up to BLE. So that was the next issue, BLE stability and connection control. We're still refining, fine-tuning the BLE system. There's some work to be done in improving the ease of discovering and connecting to the sensor devices as well as ease of installing that BLE monitoring app on the Android devices. We also still need to assess how many BLE connections the app can feasibly manage at one time, as well as work on just improving the stability of maintaining those connections. So we're looking forward to working more on the testing and ultimately to deployment of a completed solution. My co-founder and I have been working a lot with clinicians in Uganda and we're excited to be partnered with the Ugandan Pediatrics Association and St. Francis Hospital in the Sambia for planning and executing pilot studies, hopefully starting sometime next year. Our plan is to demonstrate the feasibility and the impact of the sort of solution first in Uganda and then expand to other low-resourced settings in East Africa and around the world that have similar needs. So with that, I guess I invite you guys to all come see our demo prototypes at the Zephyr Project booth in the next couple of days. I'd love to speak more with people who are interested in our mission in newborn health and interested in healthcare solutions that use clever elements. I'm excited to learn from all of you and I hope that we can leverage innovative tech to reach vulnerable and underserved populations. Thank you. Take any questions if there are any. Developers, do you have working? You showed your timeline, was that all yourself or were there other people working on those at different stages? There were other people. Do you know what the size of the team was, Scott? This is a couple. What was the other? Cisco. So while we were students, we presented at the Rice Business Plan competition in Houston and that's where we got a prize from Cisco from their corporate social responsibility arm. And then Vodafone is a grant that they offer called the Wireless Innovation Project. So we applied for that last, I guess last spring it was awarded in June and we ended up winning first place in that project. So we started in Uganda because we had some connections at hospitals there and then by going to Uganda twice, we ended up meeting just a lot of people in the newborn health space there which turned out to be pretty small so we've gotten pretty well connected there. I think some of our physician advisors introduced us to people at UPA. So now we're partnered with them. They do a lot of clinical trials and things like that. I'm not extremely familiar with that process. Maybe Jeffrey can help out. The question was, what does the... Eclipse. Or the Eclipse. Yeah, please come by, sorry. Do you need any certifications for who may be able to go further? Once we, for commercialization we intend to go through CE mark. For clinical trials in Uganda, we need the IRB approval for those studies as well as approval from Uganda National Council of Science and Technology. But we do intend to go through CE mark before we commercialize obviously rather than FDA since we're not commercializing in the United States, at least not yet. For some of our prototypes, we've been just extracting those waveforms directly and doing that manipulation ourselves. Ultimately it will be the other way around, hopefully. Once we get the refinement a bit better. Yeah, we can plug it in here too. What's your partner's background, your co-founder? She's a biomedical engineer as well. She's our CEO, so she's been doing a lot more business side than I have. But we both have an engineering background and are kind of wearing a lot of different hats. We're hoping to expand our team pretty soon to include some other expertise. Is this applying to adults? Yeah, so we think there's a lot of opportunities with this sort of technology to expand to different patient populations. We're starting with newborn health because that's sort of our passion and what we think there's a big need in. But we think we could easily adapt it for peeds, for surgical applications, different patient populations for sure. In Uganda? No. The sort of competition for this is just kind of manually measuring vital signs. There's other low costs like pulse oximeters and things that don't measure the full suite of vital signs continuously. And their price points tend to be a bit higher. We would definitely have competitors in like a United States or a European market. But we do have some different advantages with sort of cost and what we can do with our monitor. What is your route to the price point? Hard to say right now. We're aiming to be in the ballpark of about $50 per unit. The problem is like respiratory, attracting the respiratory rate. Can you just explain a little bit about that? I thought that was interesting. Yeah, so we've sort of developed these algorithms based on assisting literature. And so we're still kind of playing with those a lot. It, we're tracking over like 10 to 15 seconds right now. So there can be fluctuations that we don't capture or that too many fluctuations in that period. So we're not really capturing everything that's happening. But you're using the heart rate to calculate. Yeah, so from the heart rate, we get that the plasmagraph waveform. And then there's detectable modulations in that waveform that correspond to respiratory rate. So for example, like the baseline changes in the plasmagraph over multiple heartbeats. And we can correlate that to the respiratory rate. So there's, we're playing with, you know, we might need to add in four year transforms and things to get a more refined respiratory rate. Because it's sort of, it's, don't want to get too much into the algorithms, but it's sort of a weighted average of three different types of modulations in the plath waveform. And so we're still playing with the best way to do that accurately, if that makes sense. Do you ever think of combining the accelerometer with your algorithms to try to prove the accuracy? We haven't tried that with this, with the Curie module. That's an interesting idea actually. On the forehead, I'm not sure if the accelerometer would pick up the respiratory rate changes. We are planning on testing out the device in different locations around the body. So perhaps if we did it as like a chest band, we could capture the respiratory rate from the chest expansion as well. Is that sensitive? If it was over the lungs, I'm sure it would be. I mean, it could be a lot of noise. It could be a lot of noise, but then if you correlated with, you know, probabilistically, if you combined the two, you might be able to get some, some, some clarity out of that noise. Yeah, that's an interesting, interesting idea. I mean, I can have an accelerometer pressing on my desk and somebody walks by and I can see it. Wow, yeah. Cool. Sorry, in the actual heart rate, how much, what's your resolution? Are you capturing the actual waveform? Yeah, so we're getting the, it's measuring all the peaks of the PLETH waveform. Just the peaks. Essentially, while we're counting the peaks, that's how we're counting the pulse rate. Okay. Yeah. Is this a steel device? Do you like charge it with a proximity charger? Ultimately, we want to, it'll probably have to be some sort of plug charger. We're hoping to use the phone port. I forget what it's called. That is in most cell phones that people use over there. So that if they lose the charger, they can use their phone charger. But I think a, like a conductance charging or something is not really feasible at this time for just based on cost. I'm still moving too much. All right. Thank you. Everybody, for your questions. Thanks. Thank you. Thank you. Thanks everybody. For your questions. Thanks.