IBM Bluemix Technical Workshop — Part 2

Originally published on HHOttawa’s blog on Medium.
Written by Hacking Health Ottawa Volunteer Kevin Dick

Hacking Health Ottawa’s own Haidee and Mohamed kicked off the March 9^th event with the inspirational Hacking Health video followed by the event road map leading up to the event. The next few weeks comprise a number of panels and workshops to keep teams engaged and on track on the road to the Hackathon!

This week’s workshop featured the return of Laura Alkhoury and the IBM team who kindly volunteer their time and expertise in teaching Hacking Health enthusiasts about different technologies. Laura began by briefly recapping the previous IBM Bluemix Workshop, indicating how today’s focus was on the remote acquisition of diverse sensor data. Polling the crowd revealed a majority of newcomers to the Bluemix platform. Today we were to learn about navigating a diversity of sensor data. There is a multitude of sensors and anything you might want to measure, you can find a sensor that would suit your need.

Today’s workshop used a single Raspberry Pi, setup with three types of sensors: a photoreceptor, pressure sensor, and flex sensor. Laura motivated the application of each in healthcare applications: a photoreceptor as a means of remotely detecting whether an individual enters an area, pressure sensors as a means of tactile sensing an environment (e.g. if a patient moves, or determining an individual’s pace while walking), and the stress receptor could be incorporated in various fabrics to determine how an individual moves or responds to different therapies. The innovations are endless and one might envision several ways of incorporating sensor arrays to acquire all types of data, however a stream of data is useless unless converted into information, and this was the theme of today’s workshop.

Peter Djeneralovic briefly explained the circuit setup and went into some details about how a sensor’s voltage is built up into capacitors and subsequently discharged at a given interval. This process can be varied based on the frequency with which you take readings: a higher rated capacitor would be used in cases where you take readings at longer intervals as charging the capacitor requires more time (perhaps useful to measure slow physiological processes life breathing) whereas a lower rated capacitor would be useful in cases at which high resolution readings within very small time intervals are ideal (perhaps useful in cases of very fast processes such as tracking eye movement).

Now conceptually primed, we were ready to jump into the code! Each of us connected to the Raspberry Pi and nano’ed into our own python scripts. Laura walked us through each line (no non-coder left behind!) explaining its purpose.

We chmod’ed the scripts to an executable form (“sudo chmod +x my_code.py”) and then ran it, passing in a numerical parameter as the GPIO pin number we wanted to acquire data from.

It was exciting to see the stream of values from the flex receptor pouring. The values generally hovered around ~160, however when Laura flexed the sensor, one could immediately see the values spike up to ~300. When increasingly flexed that value could rise to upwards of 500 until reaching a saturation limit, as defined in the sensor specifications.

On the contrary, when streaming data from the pressure sensor, there was no “live” stream of data. Instead, one had to actually apply a pressure to the sensor in order to initiate the data stream. Interestingly, the harder one applied pressure, the SMALLER the value became up to a 20 lb limit (according to the sensor specifications) at which point the sensor streamed a value of 0. Increasingly lighter pressures would result in spiking values at times reaching the value of thousands at a feather’s touch.

To reiterate the take home message: this data is meaningless unless it can be processed and analyzed to generate meaningful information. Even getting a sense of the variation and noise in the data stream was difficult without some means of graphing the data. Unfortunately, the Raspberry Pi was not outfitted with any large graphical packages; cue creativity!
To hack together a semblance of a graph to generate a sense of variation in the data I thought to convert the numerical value into an array index to symbolically represent that information in a more intuitive context than a simple value. This would allow one to interpret trends in the data.

Since the values were generally within the range of [0,300], I initialized an array of 300 underscore symbols: [_,_,_,…,_,_,_] . When joined together as a string and printed, this would give a straight horizontal line across the screen. I could then replace a single index of that array corresponding to my sensor value with another symbol, such as an asterix. For a value of 160, this would result in a complete array of underscores of size 300 save for the 160^th position which would have an asterix.

When launching this modified script, I suddenly saw a vertical streaming graph:

Now playing with the sensors really provided an intuitive interpretation of the changing sensor values.

I began to think about the types of sensors which might be useful to establish a new process to diagnose sleep apnea? How sensitive might these sensors need to be? How does one account for noise in the data stream? From the previous Design Thinking worshops our ideation sessions promoted the primary objective to develop some technology to enable remote diagnosis. This means defining the right set of sensors, but not only retrieve the data, but to convert that raw data stream into something meaningful. That information could then be used to establish when a sleeper had “normal” breathing patterns versus one experiencing sleep apena symptoms. This would amount to establishing certain thresholds in the data, so if the values were within a certain range for a certain period of time an alarm might be triggered to inform medical specialist about the potential breathing interruption during sleep. To motivate this idea, I came up with a bit of a game using the new graphing technique I had implemented.

By setting a vertical “boundary” on my graph at the 100^th and 200^th position, I made a game out of the sensor. If the sensor value was below 100, or above 200, the player’s score would remain at zero. However, if the player could keep the sensor value between 100 and 200, their “score” would increment. The challenge became a matter of keeping a very fine touch on the pressure sensor to try and achieve the highest score possible.

Here is an example of a player winning the game by applying a “Goldilock’s pressure”: not too high and not too low. This could potentially apply to a sleep apnea patient: shallow breathing patterns might correspond to light sleep, deep breathing patterns corresponding to deep sleeping patterns, but perhaps too much time spent between light and deep sleep patterns might correspond to a phenomenon seen in sleep apnea patients. If that Goldilock’s period reached a critical threshold, say 100, this could be some evidence for sleep apnea symptoms in a patient. A medical specialist might be alerted about this occurrence and a potential diagnosis reached from this evidence.

This data offers a number of exciting possibilities, particularly if a machine learning layer could be implemented to analyze this data stream. Everyone enjoyed the learning process and found great utility in this workshop; it established the technological foundation for many ideas churning in anticipation of the upcoming April Hackathon!

Applications for the Hackathon are open! Should your team develop the winning solution, you will have the unique opportunity to implement your project in conjunction with teams at CHEO-OCTC, turning your conceptualized project into actionable change in the world. There is already huge demand so if you are reading this now, take a moment to register here.

Are you a developer, designer, policy analyst, artist, or engaged citizen with a vested interest in healthcare? We invite you to get involved, and look forward to seeing everyone again as we gear up and get ready for our Hackathon with our anchor partner CHEO-OCTC.

Sign up here for the Hacking Health Ottawa newsletter and to stay up to date on all upcoming event details.