Using The Internet of Things for Population Health Management - StampedeCon 2016

Editor's Notes

• #4: IoT is turning the way we think about healthcare inside out. For a very long time, the industry has been based on a model where patients come for services when something is wrong, and healthcare providers get paid when they provide a treatment for that ailment. Over the past several years, we’ve seen regulations and consumer expectations shifting toward a model that reward healthcare providers for keeping customers from having to come in for treatment. In the past, though, healthcare providers didn’t have any reliable or timely information about patient behavior outside of a clinical setting. Consumer IoT devices are making that possible. And when you do still have to go to the hospital for a treatment, IoT devices are making a huge different in improving the quality of care while you’re there.
• #5: Starting in the clinical setting…
• #6: Real-time location systems aren’t quite as hot a topic as they were 10 years ago, but because of wayfinding solutions from folks like Aisle411 (who’s also speaking here), RTLS is already moving from novelty or differentiator to an expected capability.
• #7: On of the most exciting areas in health IoT is all of the new clinical or near-clinical grade devices that are being made available for at-home monitoring. These are especially useful for patients returning home for recovery or people living with chronic conditions that need to be monitored closely.
• #8: This is a traditional Holter Monitor that an infant with a heart defect might wear at home for monitoring. A parent might be required to take their baby home wearing one of these for a week while data is recorded in a small box that the leads are attached to. After bringing the device back, only then can a clinician read the data and provide a diagnosis.
• #9: This prototype device provides similar data wirelessly.
• #10: The area that Amitech and Big Cloud Analytics are working together in, is the use of fitness data from wearable devices like these. Some of the most sophisticated ones track not only your motion and heartrate, but also perspiration through the electrical conductivity of your skin, your body temperature, and the ambient air temperature around you.
• #11: Finally, we’ve got what are probably the most intimate health IoT devices. These are things that you swallow and they go inside your body. There are also possibilities in nanotechnology that are still works in progress. Maybe someday, we’ll be getting a stream of data from a swarm of artificial immune cells attacking cancer cells, or repairing an ulcer in your stomach.
• #12: So, with all of the data available from these devices, we have to have technology to capture and process that data. In the streaming data space, we’ve go a slew of technologies that have different programming paradigms and technical strengths and weaknesses. This presentation isn’t about telling you how to pick which one is right for you use case. The point here is to encourage you to do some research, pick one, and try something out. Chances are good that in several years, you’ll have two or three in production, each being used very appropriately.
• #13: Spark is one of the hottest topics in big data right now, probably. Spark Streaming is the specific mechanism for real-time data processing, and while it’s technical “micro-batch” rather than “transactional,” a response time of a few seconds is still sufficient for many applications. Airbnb uses Spark Streaming to process and provide analytics on all of their incoming transactions.
• #14: Unlike Spark Streaming, Storm is a true transaction-level streaming technology. There are lots of companies using Storm for streaming data ingest and it’s topology of spouts and bolts is fairly easy to pick up. Here’s an example of the MedPulse topology at WebMD.
• #15: There aren’t nearly as many NiFi stories out there to talk about because NiFi has only been out in the public for not even a couple of years after coming out of the NSA and being sponsored by Hortonworks. In the time I’ve spent with NiFi, I think that it’s main strengths are the number of prebuilt processors and the strong emphasis on data provenance features. One of the early adopters has been Schlumberger, who provides equipment for oil drilling rigs. They’re capturing data from all of their remote devices and collecting them for multiple uses via NiFi. In fact, there’s a project called MiniNiFi that they are actually deploying out to the devices on the rigs.
• #16: Samza is similar to Storm in many ways. It provides the same transaction level processing and is probably a bit less mature than Storm, still. But it has the advantages of being a bit more flexible with how data is stored and is more closely tied to YARN for process management. Uber uses Samza as a major part of it’s real-time pricing calculations.
• #17: Flink also falls right in line with Storm and Samza. Two things that Flink does natively that the others don’t do as well are stateful processing and guaranteed in-order processing. The company behind Candy Crush (and other related games) uses Flink at the core of their data processing.
• #18: So, what are we doing with IoT and healthcare at Amitech Solutions? We’re working with a partner of ours, Big Cloud Analytics, to refine and scale a population health management platform they built over the course of 2015.
• #20: One of the place we know will have to scale is going to be the data ingest. While this part of the platform will never likely have sub-second latency as a requirement, it will be required to processing multiple readings per second from multiple sensors for every user every day. Every user generates more than 100kB of data per day, including as many as individual 432,000 transactions. Today, the ingest behaves in a typical batch mode. Every day we kick off a batch job for each client. It loops through the list of users who need to be processed, collects data from the vendor for their device, processes that, does some calculations, and stores the results in an RDBMS. Not show here is the web application on the other side of the databases, where users and program administrators can see progress and create targeted incentive programs for the users. I knew about Storm, Spark Streaming, and NiFi when I started looking at this. So, I thought I’d try it with NiFi first.
• #21: Let’s start with a little background on how NiFi works.
• #22: There are lots of different types of built-in processors (including HL7) and it’s an ever growing list.
• #23: Connectors enable not just the pass-through on success / failure, but splitting and routing in many cases.
• #24: And everything comes together in the Flow Controller, where connections are made between processors. For those of you familiar with traditional ETL, this can feel very similar to that.
• #25: What I wanted to NOT do was have to rewrite all of our existing code. The first thing I looked at was using the HTTP/REST, JSON, and string parsing features native in NiFi, but then I did a little research and saw how easy it would be to take my existing code and wrap part of it into a NiFi processor.
• #33: For my first demo version, I decided to just pass in the variables I need using a simple properties file. Eventually, we’ll have a trigger or queueing mechanism in the front here, telling us when to go get data for a particular user; or the user data simply flowing into NiFi from the vendor, though most of them don’t support a push model, yet.
• #35: Our output? 110kB of information about my activity on April Fool’s Day!
• #36: Our output? 110kB of information about my activity on April Fool’s Day!