This is an open-access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.jmir.org/, as well as this copyright and license information must be included.
A transformation is underway regarding how we deal with our health. Mobile devices make it possible to have continuous access to personal health information. Wearable devices, such as Fitbit and Apple’s smartwatch, can collect data continuously and provide insights into our health and fitness. However, lack of interoperability and the presence of data silos prevent users and health professionals from getting an integrated view of health and fitness data. To provide better health outcomes, a complete picture is needed which combines informal health and fitness data collected by the user together with official health records collected by health professionals. Mobile apps are well positioned to play an important role in the aggregation since they can tap into these official and informal health and data silos.
The objective of this paper is to demonstrate that a mobile app can be used to aggregate health and fitness data and can enable interoperability. It discusses various technical interoperability challenges encountered while integrating data into one place.
For 8 years, we have worked with third-party partners, including wearable device manufacturers, electronic health record providers, and app developers, to connect an Android app to their (wearable) devices, back-end servers, and systems.
The result of this research is a health and fitness app called myFitnessCompanion, which enables users to aggregate their data in one place. Over 6000 users use the app worldwide to aggregate their health and fitness data. It demonstrates that mobile apps can be used to enable interoperability. Challenges encountered in the research process included the different wireless protocols and standards used to communicate with wireless devices, the diversity of security and authorization protocols used to be able to exchange data with servers, and lack of standards usage, such as Health Level Seven, for medical information exchange.
By limiting the negative effects of health data silos, mobile apps can offer a better holistic view of health and fitness data. Data can then be analyzed to offer better and more personalized advice and care.
Wearable health trackers such as the Jawbone UP [
Wearable devices and mobile phone health apps can and will change health care by empowering users and educating them to take control of their health. Users are embracing them; according to the Intercontinental Marketing Services (IMS) Institute for Healthcare Informatics [
There is an increasing amount of health- and fitness-related information that has been collected and stored in the cloud. However, the data usually reside in silos and in most cases health and fitness data are separated. For example, Fitbit stores all data generated by their trackers on their Fitbit server; the same applies to Jawbone, Withings [
Currently, there is no real integration of fitness-related data and health records stored in EHR systems. To provide better health outcomes and better patient engagement, a complete picture is needed which combines informal health and fitness data collected by the user, together with official health records collected by health professionals. By combining these two streams, the data can be analyzed using data analytics and health professional expertise to offer better personalized advice and care. There is good evidence that the integration can improve therapeutic management [
The objective of this paper is to demonstrate that a mobile app can be used to aggregate health and fitness data and can enable interoperability. It discusses various technical interoperability challenges encountered while integrating health and fitness data into one place. By limiting the negative effects of health data silos, mobile apps can offer a better holistic view of users' health and fitness data and give them more control over their data.
Since 2007, we have worked with third-party companies to connect our Android app called myFitnessCompanion [
myFitnessCompanion was developed for Android devices and offers personalized exercise tracking and monitoring of biometric data, such as heart rate, respiration, body temperature, weight, food intake, blood pressure, cholesterol, asthma, blood glucose, and many more. It supports 15 different languages and has been commercially available on Google Play since 2011. Prior to the Android app, we developed a similar app using the Microsoft Windows Mobile 6.x platform. At that time, Microsoft did not offer an outlet like Google Play to distribute the app easily and, more disruptively, Microsoft discontinued support for Windows Mobile 6.x devices in 2011, which forced us to choose a new platform. We selected Android over Apple iOS, partially due to our experience with JAVA/C#, but more importantly because of the excellent Bluetooth support in the Android platform compared to iOS at that time.
Our approach was to integrate off-the-shelf, commercially available devices. Simultaneously, we connected myFitnessCompanion with EHR servers, such as Microsoft HealthVault and Google Health (discontinued). These were the first EHR servers available to the general public. A major challenge was to keep up with the different Android operating system (OS) versions coming onto the market at a 3- to 6-month interval, resulting in a continuous process of updating the software to keep up to date with new Android devices and features.
Devices supporting open standard protocols (
Devices paired with myFitnessCompanion (
Closed and proprietary wireless devices (
Websites such as MyFitnessPal [
In this paper, we focus mainly on sensor-generated health and fitness data, but it is worth mentioning that 80% of myFitnessCompanion users enter their physiological data manually [
myFitnessCompanion ecosystem.
The main result of this paper is a health and fitness app called myFitnessCompanion. The results and discussions in this paper are based on our experience as an integrator of health data from various sources. The app has over 6000 users. Screenshots of the myFitnessCompanion app are shown in
Screenshots from the myFitnessCompanion app.
myFitnessCompanion has integrated a wide variety of wireless sensors ranging from universal serial bus (USB) cable devices to the latest Bluetooth low energy (BLE) devices. We focus on the most commonly used wireless communication protocols.
Devices that have been on the market for several years mostly use classic Bluetooth. Most mobile phones support classic Bluetooth, whereas only the later and more expensive models support BLE, the latest version. Classic Bluetooth supports different ways to communicate between a device and a mobile phone. We encountered all possible options, which resulted in writing specific software for each device. For example, the A&D weight scale and blood pressure monitor would only activate Bluetooth after a reading is taken. This means that the mobile device has to listen for Bluetooth requests coming from an A&D device and then establish a Bluetooth link. Other devices act as slaves where the mobile phone (master) has to initiate the Bluetooth communication. Yet other devices would alternate between master mode for configuration purposes and then switch to slave mode when data need to be exchanged with the mobile device. In order to integrate a Bluetooth device, we required the protocol specification from the vendor. Dealing with all these different Bluetooth communication modes made the software development complex. Once the Bluetooth communication was solved, the next challenge was to interpret the data received and the data to be sent to the device.
Without exception, all vendors developed their own protocol and data formats to retrieve data from the device or to send commands to the device. Some protocols were straightforward, using plain American Standard Code for Information Interchange (ASCII) text to send or receive data. The Tanita [
From our experience, devices using classic Bluetooth to stream data continuously (eg, heart rate) are the most reliable from a connectivity point of view. Devices that only activate Bluetooth after a reading have turned out to be unreliable, especially if a mobile device is not in the area. Often the device would not establish a Bluetooth connection on subsequent readings and the user would be forced to go through the pairing process again.
Example of a plain ASCII protocol (Tanita [
Example of a more complex protocol (OneTouch UltraMini [
The latest health and fitness devices use BLE (aka, Bluetooth Smart or Bluetooth 4.0). Fitbit and Jawbone activity trackers use BLE due to low power consumption while maintaining a similar communication range compared to classic Bluetooth. BLE is characterized by easy pairing with a mobile device and minimal or no user intervention required. Many BLE devices such as heart rate monitors start transmitting automatically when data are available. BLE is rapidly becoming the standard for wearable devices, pushing ANT+ to the background. BLE has built-in features to automatically reconnect to a mobile device if the connection is lost. This eases software development and improves the reliability of device-phone communication. The introduction of BLE, together with standardized protocols for data exchange, makes these devices easy to integrate and use.
However, several vendors such as Fitbit and Withings decided to use proprietary protocols, making it impossible for third-party developers to communicate directly with their devices. We believe that this will change in the near future with other vendors offering similar devices using open protocols. Android Wear and the upcoming Angel [
ANT+ is a lesser-known wireless technology. It is characterized by low power consumption and short-range communication. It is mainly used in sports-related devices, such as step counters, fitness equipment, and heart rate monitors. It is similar to BLE, but not many mobile phone makers integrate ANT+ communication into their phones, therefore limiting the popularity of ANT+ devices. ANT+ devices implement a standardized protocol, which makes it easy to integrate these devices.
We believe that over time the market will converge on BLE at the cost of classic Bluetooth and ANT+. BLE is a natural evolution of classic Bluetooth and already the latest mobile phones support BLE and not ANT+. This will force health and fitness device vendors to support BLE if they want to have a slice of the booming health and fitness device market.
myFitnessCompanion can support up to seven active sensors at the same time. It is not common, but customers do use multiple sensors simultaneously. For example, sleep apnea patients use a heart rate monitor and a pulse oxygen sensor concurrently, which results in duplicate heart rate readings varying slightly. Currently, our app records both heart rate readings and tags the source of the readings, which gives the user an indication in case of discrepancies. In future versions, our app will give the user the option to select which sensor should be used for real-time analysis and feedback. With the increase of data sources comes the need to be able to differentiate the sources based on their reliability, quality, and trust levels.
The reliability of the devices varies widely, partially caused by incorrect use by the user. This is a major concern for health professionals when customers present, for example, their blood pressure readings expecting a health professional to make a diagnosis based on self-collected health data. Devices made for the fitness market are not necessarily approved by the Food and Drug Administration (FDA) and, as such, are even less reliable. Currently, myFitnessCompanion cannot identify the quality of a sensor reading; however, it tags the source of the reading. Knowing the source of the data collected is beneficial for a health professional in his/her assessment of the data quality.
myFitnessCompanion can upload and download health data from various servers, such as Microsoft HealthVault, Google Fit, Jawbone, Fitbit, and many more. These servers offer an open API where (after authorization) health data can be exchanged. In this discussion, we focus on authorization and use of standards for the exchange of health data.
All servers use some version of open authorization (OAuth). OAuth is an open standard and provides apps like myFitnessCompanion secure delegated access to a server on behalf of the owner. OAuth specifies a process to authorize third-party access to the resources without sharing the user credentials. Once a user has given myFitnessCompanion permission to access health data on their behalf, the app can download and upload data without further user intervention.
Although OAuth is a well-defined standard, the actual implementation varied slightly for the different servers. For example, the FatSecret server supports the OAuth 1.0 specification, but in their actual implementation they used variable names that differ from the standard. The consequence was that off-the-shelf libraries for OAuth for Android devices could not be used and custom software had to be written to deal with these slight discrepancies.
Microsoft HealthVault uses yet another variant of OAuth and specific libraries needed to be used in order to be able to communicate with the HealthVault server. In addition, some servers implement the OAuth 1.0 version whereas others support OAuth 2.0. All this added up to additional complexity of the software to deal with the various servers. A positive trend is that servers are migrating toward OAuth 2.0, so we can expect in the near future to use one standard for authorization.
Screenshots of the OAuth for Fitbit (left), Withings (middle), and Google Fit (right).
Once the authorization hurdle had been overcome, the next challenge was to deal with the actual data to be exchanged between myFitnessCompanion and a server. Unfortunately, not a single server used an official standard for health data exchange. Without exception, each server defined its own specific data format. All the efforts made by the Health Level Seven (HL7) standardization group seem to be ignored and not taken into account. The API offered by Microsoft HealthVault is the closest to something that looks like an HL7 specification, but a specific subset has been used with proprietary modifications. The consequence was that each server-specific software had to be written to interpret the data.
On a positive note, most servers offer their data in either Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format, with JSON rapidly becoming the de facto standard. We expect that XML will disappear in the next few years. Fitbit has stopped offering the XML API in 2015 and will only support JSON. Only Microsoft HealthVault solely uses XML and does not offer JSON, which makes it much harder for developers to convert the data into a usable format for further processing.
Example responses using JSON (left) and XML (right).
myFitnessCompanion supports a two-way synchronization where data can be uploaded to, and downloaded from, a server. Dealing with one server is fairly straightforward, but issues arise when data need to be synchronized using multiple servers. Should data that originated from, for example, the Fitbit server be duplicated to HealthVault and Jawbone servers, or should the data only be imported to the mobile app and not uploaded to other servers? Because of the API specification of some servers, it is impossible to identify where the data originally came from, so if you upload it to another server it becomes a new reading and imported again into myFitnessCompanion, resulting in duplicates. To avoid this issue, when myFitnessCompanion imports readings from a server, it does not upload these readings to other servers. This means that the app becomes the central point where data from various sources come together.
The result of this research is a health and fitness app, myFitnessCompanion, which is able to aggregate data from multiple sources—activity trackers, wireless sensors, and servers—and analyze and present the data in a personalized manner. Over 6000 users use the app worldwide to aggregate their health and fitness data. It demonstrates that mobile apps can be used to enable interoperability. Challenges encountered in the research process included the different wireless protocols and standards used to communicate with wireless devices, the diversity of security and authorization protocols used to be able to exchange data with servers, and lack of standards usage, such as HL7 for medical information exchange.
In terms of interoperability, we have achieved three levels of interoperability: foundational (the app and EHR can exchange data), structural (the data can be interpreted at the field level of exchange), and semantic (the data can be exchanged and used by both the app and the EHR). If we refer to the six levels of the refined eHealth European Interoperability Framework (eEIF) model [
myFitnessCompanion has been developed for the Android platform. An Apple iOS and Windows Mobile version would be desirable to cover the majority of mobile devices. Currently, the aggregated data reside on a mobile device or are sent to private EHR systems. It would be desirable to have these data stored in government-controlled EHR systems. Unfortunately, tapping into official EHR systems turned out to be complicated. Efforts have been made to connect myFitnessCompanion to Australia's personally controlled EHR (PCEHR) system, but they failed. The PCEHR standards are too complex and difficult to implement. There is no support and no easy-to-use API to interact with the PCEHR. The new version, called My Health Record, may deal with this issue. Other official EHR systems have security and operational policies that are not coherent with other systems and they do not allow any third-party developer to tap into the system [
Acceptance by health professionals is another hurdle to overcome. From user feedback, we know that users show their collected health data (eg, blood pressure and blood glucose readings) to their health professionals. Some health professionals take this data into account for the diagnosis, but others reject the self-collected data and use their own (often far more limited set of data) for diagnosis. Reasons for rejection include the potential lack of accuracy and the extra time needed to go through the data [
Another survey of 1000 American health professionals [
There are a lot of health and fitness apps on the market, and some good state-of-the-art analyses of those apps can be found in various studies [
As stated in the “Introduction” section, a combination of informal health and fitness data and official health data stored in EHR systems is desirable to provide a complete health picture. myFitnessCompanion is able to tap into both the formal and the informal health and fitness data, and aggregate the data in one place. There are a lot of benefits in aggregating the data coming from wearable devices and sensors, especially, for example, for users with chronic disease, as their conditions need long-term monitoring. By combining health data with nonhealth data (eg, location, social media, and habits), one can make interesting correlations and suggest changes to the users’ habits and help in dealing with their chronic conditions. Our ultimate objective is to empower users and help them in monitoring their health and fitness in a personalized manner and to improve their quality of life [
Video showing the functionalities of myFitnessCompanion.
Advanced and Adaptive Network Technology
application programming interface
American Standard Code for Information Interchange
Bluetooth Low Energy
eHealth European Interoperability Framework
electronic health record
Food and Drug Administration
Health Level Seven
Intercontinental Marketing Services
iPhone operating system
JavaScript Object Notation
open authorization
operating system
personally controlled EHR
Universal Serial Bus
Extensible Markup Language
The authors are the owners of myFitnessCompanion Pty Ltd.