Keywords

1 Introduction

Health and fitness apps for mobile and wearable devices are proliferating. The majority of users use these apps in stand-alone and unsupervised mode, e.g. for own goal tracking, changing unhealthy habits or gaining awareness of own health and fitness. However, a growing number of Health Service Providers (HSPs) are also examining the potential of smartphones and wearables to deliver supervised health services. Examples include home- and community-based interventions to cope with chronic diseases such as diabetes [1], or assisting community-dwelling elderly in case of e.g. falls [2].

In order to facilitate developers and accelerate this popularity, platform owners –both commercial and research-based –have recently released a range of programming toolkits. A programming toolkit provides a set of programming tools to facilitate the development of a family of software products. Health and fitness toolkits support the development of applications to measure, view and manage health and fitness data.

Toolkits create a boundary between what the vendor of the toolkit has already implemented in the platform, and what the application developer can change and build upon. Toolkits are in this sense open innovation tools: “In this emerging new approach [of using toolkits], manufacturers actually abandon their increasingly frustrating efforts to understand users’ needs accurately and in detail. Instead, they outsource key need-related innovation tasks to the users themselves, after equipping them with appropriate ‘toolkits for user innovation’” [3].

At the same time this division brings with it tensions related to e.g. data ownership and vendor lock-in. These tensions become particularly important when we move from the realm of stand-alone health and fitness apps to that of supervised health services provided by e.g. hospitals [4]. Issues such as where data are stored, what investments in hardware and software are needed, how open and interoperable the toolkits are, all become important for HSPs who invest in costly innovation projects.

Although the number of research articles evaluating health and fitness mobile applications is growing, no studies have evaluated mobile health toolkits. Existing evaluations of generic mobile platforms are often at a technical programming level, and focus on mobile devices in isolation from the service context, as in e.g. [5, 6]. In our research we are interested in generating new knowledge about similarities and differences among mobile health toolkits. We believe this type of knowledge is important to inform investments in health platforms, and to inform a dialogue with the vendors of such toolkits. We analyze health toolkit through the boundary resources they provide and their impact on service providers. Platform boundary resources are “software tools and regulations that serve as the interface for the arm’s-length relationship between the platform owner and the application developer” [7]. Examples can be an API (Application programming Interface), or a mandatory server to store health data.

Our research question is “How do existing mobile health toolkits for smartphones support HSPs in providing their services at home and community?” This is a long-term research question for us, whereas the current short paper address a preliminary part. In this paper we explore how three of the most publicized of these toolkits –Apple HealthKit, Google Fit, and Samsung Digital Health Platform (DHP) –support service providers through their deployment architecture, and what requirements they pose on HSPs with respect to deployment and data ownership.

In the following we first present our research method. We then provide a short overview of our preliminary findings, and discuss the implications of these findings.

2 Research Method

We use the case study design with a multiple-case setup [8]. Our cases are the three health toolkits as shown in Fig. 1. The context for the cases is that of developing supervised health services. This means services that are provided under supervision of professional HSPs such as hospitals. An example –which we also have used in our case study –is a simple service for home-based monitoring and online reporting of blood sugar levels to a doctor.

Fig. 1.
figure 1

The case study method used in our research

Full size image

We collected and used data from Internet sources –such as blogs, developer forums and vendor’s documentation. We collected and analyzed Internet data during a three-month period in the autumn of 2015. We analyzed the data in several iterations. We used actor network analysis to identify stakeholders and boundary resources for each toolkit. During the same period we developed three versions of a simple blood sugar level reporting service. This exercise was necessary in order to gain detailed knowledge about how each toolkit worked and what technical requirement they posed. For details about the collected data see [9].

3 Findings

In the following we provide an overview of each toolkit, its boundary resources, and its deployment architecture illustrating the role of the boundary resources. The deployment architecture is presented as a three-layer architecture –see e.g. Figure 2 below –showing, from left to right: (1) a health device such as a blood sugar level sensor, (2) a mobile device acting as app container and gateway, and (3) a back-end server containing the service provider’s service logic. For each layer and across layers, we show how toolkit vendor’s boundary resources (colored in gray in Fig. 2) and third party software and hardware (colored in white) interoperate.

Fig. 2.
figure 2

Service architecture based on HealthKit.

Full size image

Apple HealthKit.

Apple HealthKit’s main boundary resources that we have studied are the Health Store (HS), and the API to access HS’s content (see Fig. 2). HS is the data storage for all health and fitness apps developed for iOS. Apple’s own and third party health apps can store data in HS and share it with other apps on the same device. Strict access control mechanisms are in place. The data in HS can only be accessed locally. However, HS’s content can optionally be exported to Apple’s iCloud servers in form of an encrypted XML file for back-up purposes. Apple has a flexible policy with respect to data types that can be stored in HS. Third party developers can define their own data types and share them through HS. HealthKit, as other Apple products, is restricted to run on iOS devices. A small number of third party Bluetooth devices are certified to work with HealthKit. Moreover, although Apple does not play an active role in the supervised service side, the company has tried to develop partnerships with health service providers in order to promote HealthKit as a healthcare service front-end. Apple has reportedly started a clinical trial in cooperation with Epic Systems and Mayo Clinic.

Google Fit.

Figure 3 shows Google Fit’s deployment model. All fitness data is stored in Google Fit cloud server and can be accessed in Google Fit web portal and through a REST (REpresentational State Transfer) API. Using a REST API means any mobile device or other web service—e.g. in a hospital—can access the fitness data. Google Fit does not require Android devices. Google provides though an optional Android app, called Fit App, to facilitate application development on Android devices. Google has a strict policy regarding what data developers can share via Fit. Google Fit defines a set of fitness data types. If third party developers wish to share other data types using Fit, they need to inform Google and officially register the new data type. Google’s policy is that health data cannot be published.

Fig. 3.
figure 3

Service architecture based on Google Fit.

Full size image

Samsung Digital Health Platform.

Figure 4 illustrates Samsung Digital Health (SDH) Platform’s deployment model. The main boundary objects are the Samsung Health app (S Health) and SDH’s cloud servers. Similar to Apple’s Health Store, app developers can use S Health to store and access all their health data. SDH aims to play an active role also in the service end. Health data stored in S Health are synchronized with SDH’s SAMI servers (www.samsungsami.io) and can be accessed directly by other service providers using a secure API. SDH claims to provide an open platform at the device end due to their use of the open source Android OS. Samsung is also involved in developing SIMBAND (www.simband.io), a generic health device. This means both Android Wear-based and SIMBAND-based health and fitness devices can connect to SDH. SDH employs a similar model to Apple regarding its data model. App developers can use an existing set of data types, and can extend this set with own data types.

Fig. 4.
figure 4

Service architecture for Samsung Health Platform.

Full size image

4 Discussion and Implications

Our findings imply that choosing each of the three toolkits can affect a health service provider’s (HSP) long-term plans in different ways. Not surprisingly, toolkit vendors have designed their boundary objects in such a way to increase their own revenues. The tensions between the two business models –that of the toolkit vendor and that of the HSP –need to be studied in each case before HSPs invest in a platform.

Apple’s business model is around selling iOS devices and increasing app sales in their own AppStore. Apple is therefore using iOS as the main hub for their HealthKit. Using HealthKit implies that the HSP is restricted to using Apple devices. Moreover, third party apps need to be iOS-based. Although iOS devices are user-friendly, they are proprietary to Apple only. HSPs will have to rely on Apple in order to expand the ecosystem with e.g. new health and fitness devices from other vendors. Moreover, Apple devices are high-end devices. Justifying the costs of providing each user with an expensive iOS device can be difficult for many HSPs. On the other hand, service providers and users can be in full charge of the stored health data. All data are stored on the device, the user is in charge of giving access to this data, and SP can access the data via own backend services without any intermediaries.

Google Fit has a cloud-centric model. Google’s business model is about selling targeted advertisements. Google Fit is designed to collect and store fitness data from Google’s users. Google can then use these data for targeted advertisement. Consequently, Google Fit does not put any restrictions on the type of device used. Even running Android is not a requirement. So HSPs can choose among a wide range of user devices with different form factor and functionality. On the other hand, Google Fit requires integration with Google’s own Fit portal. Many countries have strict regulations for HSPs related to storage and access to health-related data, which can make it difficult to use Google servers to store such data. Additionally, Google Fit has a closed data model limited to fitness data, and excluding personal health data such as glucose levels. Healthcare service providers can find this data model limiting, although some service providers currently use fitness data for medical purposes [4].

Samsung’s toolkit seems to combine the approaches of HealthKit and Fit. If we consider the recent Samsung initiatives related to SAMI and SIMBAND as part of the company’s health platform strategy, we can see that Samsung is looking into the whole value chain. Traditionally Samsung is a device and appliance company, but different from Apple because of Samsung’s large variety of devices. This variation seems to have resulted in SIMBAND, an open hardware and device architecture. Samsung also tries to address the needs of service providers, though its SAMI cloud platform can face barriers in different countries due to privacy regulations. Samsung, with its boundary resources on all the three layers of their service architecture, promotes an integrated solution. One disadvantage of this approach is vendor lock-in, which means further technology-driven innovations become difficult due to the vendor-specific interconnections among the different parts of the architecture.

From a research perspective, our preliminary results have implications for the research on boundary resources [7] and platform literature in general. The fact that vendors’ products reflect their own business model is not a surprise. Despite this, the relation between business models and platform boundary resources is not studied in depth in the literature. The complexity of the ecosystem of mobile health solutions implies that a thorough understanding of the business models of both technology vendors and HSPs is needed in order to enable sustainable innovation in mobile health.

5 Conclusions

We have in this paper presented some preliminary results from our study of commercial health toolkits and their vendors. Our future work includes expanding the data we have collected, and adding new health toolkits to our analysis.