FitBit Raw Data Capture for Health Monitoring

This post discusses the use of the Fitbit device to capture a user’s data for later data analysis and pattern detection. The post presents a very summarised and very technical discussion on developing a solution to capture the data from the device effectively in order to obtain the data in its raw form. Such data involves heart rate, accelerometer and date/time of capture. This discussion is based on a real research exercise that involved the use of the device to capture patient data to detect and be able to predict seizures among sers.

The use of Fitbit devices for research and data collection in recent years has gripped the attention of enthusiasts and academic researchers in the Internet of things. The ease of using a wearable, such as a Fitbit, Apple Watch, or Google Watch, to ubiquitously capture behavioural data presents opportunities that have not be available in the past.

Nowadays researchers can engage with users and patients to record their daily activity data, and of course after completing the standard protocols, such as addressing regulatory requirements and concerns, obtaining user permissions, providing clarity as to the eventual use and storage of the data, and data anonymization.

The growth of the Internet of Things (IoT) has created awareness of how these devices can now be used to capture all forms of data. Wearables such as the Fitbit (which this post is about) falls into the category of wireless sensors. Wireless sensors usually represent miniature devices used to capture data from various environments and surroundings. In other words, a smart phone satisfies the requirements of a wireless sensor since it can capture all forms of data, such as accelerometer (used for fall detection), light, vibration, GPS, etc. Wireless sensors are used to monitor environments, gas, movement, factory operations, and are very much used in the military.

Back to the topic of this post. As mentioned, it is very short and brief. If you are interested in further information on the topic, you could get in touch with the author. The discussion covers the technical components that enabled us capture patient data.

Requirements

Our requirement was to capture patient data in order to analyse it and to detect patterns that indicated that a seizure was about to take place. In other words, we wanted to predict seizures in our patients. Necessarily, this could only take place after proceeding through a lengthy process of regulatory adherence and signatories to enable us use patient data. This process is not discussed in this post.

Tools

Essentially, in order to complete the task, the following components were required:

  • Web Application Server
  • Smart Phone that can install the Fitbit Companion app
  • Fitbit device – we found Fitbit Ionic to be the preferred device for this
  • Web browser – to develop the Fitbit application
  • Fitbit Account – obtainable from the Fitbit portal

Architecture

The architecture we eventually worked with is shown in the image below, and is discussed briefly afterwards.

Fitbit Architecture
Fitbit Architecture

The image is discussed based on the attached numbered circles.

  1. The Fitbit development studio enables the user to develop the Fitbit application for two components, the smart phone companion app, and the Fitbit device itself. The language used is Node.js
  2. The development studio enables the code to be run and deployed into both the companion app and the device. This is orchestrated via the Fitbit backend servers and is very transparent to the development with minimal latency.
  3. The code is installed into the companion app, which then pushes the device code into the device. Note that we discovered that the device does not have internet access directly and needs to go through the companion app to access the internet. See below how we used this constraint to gather the data.
  4. The Fitbit Ionic device gets the code installed and can show the app icon on the watch face. The user can click on the icon to start the app. Immediately the app will start to gather data and to push to the companion app, if the smart phone is within proximity to the device. Otherwise, it simply stores the data in memory. We discovered that we could get as high as 2GB of memory from the device for data storage. Each written record was less than 20kb and thus was not much data to store. Also, we realised that we needed to store data in binary form using JavaScript arrays in buffer arrays.
  5. The app server we used had the following tools installed – PHP, MySQL. We used PHP to develop REST APIs using PHP Guzzle, a popular HTTP client API . You can view the details on this link https://docs.guzzlephp.org/en/stable/. Thus, using PHP, we were able to store the device data into a MySQL database.
  6. The data stored on the web server enabled us to download the data into CSV or Excel format for later processing using JavaScript D3js library (https://d3js.org/)  for visualization.

That’s the end of this abridged discussion on this topic. A video discussion the process will be uploaded in the future so please subscribe to our news letter for further updates.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *