Born out of a vision to create a real-time, global health map to forecast the flu season, Kinsa Health’s smart thermometer is now proving useful in scouting out COVID-19.
David Gal, CTO and VP of Engineering at Kinsa Health, was responsible for taking the company’s smart thermometer from concept to a commercialized, regulated medical device in less ten months. He talked to FierceElectronics about the diabolical challenges of developing a connected product under a super-condensed timeframe and extreme cost pressures.
FE: Kinsa Health’s smart thermometer, the “Quickcare,” which was introduced in 2018, has been getting a lot of press recently because the data collected can be used to track cases of Covid-19. What was the vision behind the original concept?
Gal: Our Founder, Inder Singh, comes from a public health background and his goal from day one was to create a real-time map of human health using a widely deployed sensor network of digital thermometers. The illness signals we show on our map can be used to help public health officials track and curb the spread of infectious illness.
Our sensor network allows temperature and symptom input data to be collected, anonymized, and aggregated in order to identify trends in influenza-like illnesses. With enough sensors in a given geography (county, state, country), you can use data science techniques to extrapolate the data we collect and make inferences about the rest of the population in that geography.
FE: What were the primary design goals for the device?
Gal: Our goals were to make this product super affordable and make sure that users got the best temperature-taking experience possible. So, we knew that our thermometer really needed to look, feel, function, and cost like a regular thermometer, but with the added value that comes in our app. Here in Silicon Valley, there's been a lot of companies making things “smart” just for the sake of making them “smart” or connected. But we felt in our case that any added features, like BLE connectivity, could not distract or detract from the core user experience.
FE: Engineers who design connected products like wearables talk about the need to keep the hardware costs as low as possible, because all the value of the device is in the software and the apps. Was that the case with Quickcare?
Gal: Cost was drilled into my head on day zero—even before I took the job! I have worked on low cost products and super low-cost products, but I have never worked on anything as totally cost-constrained as this one. In this case, cost was such a big driver because our mission depends on getting lots and lots of units in the field-- it’s a statistical sampling issue--and in order to do that the product needs to be inexpensive so that it is affordable to users.
At $34.99, Kinsa's smart, Bluetooth-enable Healthcare thermometer is designed to be affordable and work just like a regular thermometer.
FE: Is a thermometer in and of itself all that complicated to engineer?
Gal: A thermometer sounds like it’s a simple device, but it turns out it’s pretty complicated on the inside. Whenever you are designing a measuring instrument for a person, there is a challenge with usability. How do you get a reliable measurement? How quickly can you get that reliable measurement?
But I think for us the two biggest challenges were cost and space constraints –the product needs to be affordable and the PCB is tiny! Had space and cost not been such huge considerations, there were a lot of things design engineers could have thrown in there, no problem. But we had to look at every aspect of the design and bit of extra functionality and ask ourselves, “At what cost?” and “How do we do this for less money?”
For example, we knew that we needed to time stamp every temperature, but we didn’t want to have to pay for a real time clock. Another example is that we wanted to drive this LCD, but we didn’t want to use a discrete LCD driver; There were countless other examples of things that you would find in a traditional product that we had to rethink and find a different way to do. There were several examples of things that you would find in a traditional product that we just got rid of by doing in firmware instead. Hardware and firmware were joined at the hip.
FE: Trying to keep the costs of a product super low can involve some pretty ugly trade-offs; we’ve all been burned buying a cheap product only to have it perform poorly. How did you approach the design process and avoid impacting the overall product quality?
Gal: I think our success ultimately had to do with approaching the design by thinking about the entire process from end-to-end. What can happen, especially with larger companies, is that they have a design team, a manufacturing team, and a supply team. They work together but they don't really work together.
Having all of our engineering and manufacturing resources work closely together really helped us because we could think about cost and quality more holistically. For example, we would ask questions like, “If we put a connector here, is it going to be easy to manufacture and assemble?” A lot of times nobody is going to even consider whether putting a part like that on one side of the board or the other might actually be easier for the operator on the line to deal with.
FE: A lot of companies have an almost maniacal focus on the BOM [bill of materials] cost, was that the case here?
Gal: The BOM cost was of course important – we looked at every component in the design and asked questions like whether we could do the PCB in two layers instead of four and could we use higher tolerance passives to save a few pennies or could we save a label on the packaging. But we also looked at things like the labor cost and how long it would take to assemble the device. We knew that every second we could take out of the cycle time would shave money off the ex-factory price. Design engineers often think about BOM cost and not ex-factory price.
Quality is incredibly critical—there are going to be serious consequences if the thermometer produces inaccurate measurements. We check more parameters about our temperature sensor than you can imagine. We calibrate, we test, we test more, and we test again. If at any point the unit fails a test, the thermometer’s firmware renders the device incapable of continuing on the manufacturing line.
We thought about opportunities to automate many of the manufacturing tests. It is really common, for example, to have an operator on the line perform some test and visually make a ‘go’ or ‘no go’ judgement call looking at, for example, a meter’s display. We decided instead that where possible we would leverage the device itself to determine 'go no go.’ Automating these kinds of tests in the device’s firmware has several advantages: Tests are faster, reducing cycle time, and it reduces the potential of an operator pushing out a unit that should have been rejected. The worst thing you want from a quality perspective is a return merchandise authorization for a product that doesn’t meet the required specs.
By time we went to China for our first build, we were very familiar with what it would take to manufacture the product, and I think that was instrumental to our success. We didn’t just throw it over the wall to our supplier.
FE: Were there any other strategies for reducing cost, either directly or indirectly, you can share?
Gal: I think you can’t underestimate the value of a great partner. We used Nordic Semiconductor’s processor, primarily because of their Bluetooth stack and excellent documentation. They have been a great partner, helping us out with a lot of the challenging problems like supply and making little tweaks in their stack that we needed.
FE: You are dealing with health information; how do you keep the data secure?
Gal: As far as data security, our whole company is structured around protecting people’s information right down to the product level. It’s important to remember that we’re not interested in an individual’s data. What we care about is population level health data – it’s aggregated and anonymized. The way we do our data science we don’t have a way to associate the data we’re looking at with an individual, and we have designed our backend system to intentionally lock ourselves out of user data. We deal with data in the aggregate, and that is the data we show on our health weather map, which tracks influenza-like illness.
Although the risk is low on hardware side—the product is used in your home and hopefully there aren’t people breaking into homes sniffing other people’s temperature data—we have taken steps to make sure it is secure on both the firmware and software side.
FE: Your product seems to be sold out everywhere, which on the one hand is a good thing because that means there is that much more data for your models. But how challenging will it be to meet the demand?
Gal: There has been a massive surge in demand—in early March we went almost overnight from 50 times and then 100 times the normal demand for these products. This exponential increase was not something we saw coming, and while it is not trivial from a supply chain perspective currently, we are actively working very hard to scale up.