Skip to main content
PMC home page
AMIA Annual Symposium Proceedings logoLink to AMIA Annual Symposium Proceedings
. 2023 Apr 29;2022:942–951.

Investigating the Interoperable Health App Ecosystem at the Start of the 21st Century Cures Act

Tera L Reynolds 1, Meghna Kaligotla 2, Kai Zheng 2
PMCID: PMC10148309  PMID: 37128391

Abstract

The objective of this study was to investigate the state of the interoperable mobile health application (app) ecosystem at the start of the 21st Century Cures Act to understand the opportunities currently available to patients for accessing and using their computable clinical data. Thus, we sought to identify third-party apps in the Apple App and Google Play Stores that seem to be capable of automatically downloading clinical data via a FHIR-based application programming interface through a targeted review of health apps. We found that few of the apps in this review have this capability (1.4% of 1,272 iOS apps and 0.6% of 1,449 Android apps). Ultimately, our results suggest that this is a nascent marketspace. If barriers to app development are not identified and addressed, and efforts are not made to educate patients and improve discoverability of apps, it could mean that patients will not benefit from these interoperability measures.

Introduction

Providing patients with access to and control over their own clinical data is critical to empowering them to be partners in their healthcare, which research suggests has numerous benefits such as improved health outcomes.1 It also presents opportunities for patients to contribute these data for the benefit of society (e.g., public health surveillance, clinical research). Although the 1996 Health Information Portability and Accountability Act (HIPAA) gave patients in the U.S. the right to access their clinical data,2 barriers remained, including cumbersome processes and long turn-around times.3–5 Recent U.S. policies have sought to address such barriers. The 2009 HITECH Act, for example, not only significantly increased electronic health record (EHR) adoption among healthcare organizations (HCOs), but also required HCOs to provide patients with electronic access to their data.6–8 This was primarily achieved through web- and application (app)-based patient portals linked to HCOs’ EHR systems. Unfortunately, siloed patient portals provide very limited options for patients to combine their data across HCOs to have a complete record and to make effective use of these data.

To address these problems and in acknowledgement of the 85% of U.S. adults owning smartphones,9 the 2016 21st Century Cures Act (Cures Act), along with the 2020-2025 Federal Health IT Strategic Plan, emphasizes the importance of facilitating patient access to and use of their computable personal health information through an interoperable mobile health app ecosystem.10,11 A robust ecosystem could reduce administrative burdens such as manual data entry into apps, offering patients opportunities to more efficiently and effectively manage their health, as well as facilitating participation in public health and medical research efforts. To achieve this vision, certified EHR systems are now required to use the HL7 Fast Healthcare Interoperability Resources (FHIR®) standard to provide third-party health apps access to clinical data through application programming interfaces (APIs).11

While there are a number of existing studies on health apps, these are largely focused on self-tracking apps that collect data (e.g., steps),12–14 apps developed for research purposes and only available to study participants,15,16 the development and evaluation of information technologies that provide FHIR capability,17–19 or app marketplaces that are not used by patients (e.g., EHR-based marketplaces such as Epic App Orchard and Substitutable Medical Apps & Reusable Technology, SMART).20 These studies provide valuable knowledge, but little is known about third-party apps in open markets that can leverage the FHIR capability and import clinical data. Indeed, as Gordon and Mandl state, “Both manual and automated processes are needed to measure key provisions of the final rule and assess whether the Cures Act has produced a robust apps economy…”21

To address these gaps and to understand the status of the clinical data-driven app ecosystem as the Cures Act goes into full effect, we conducted a targeted review of health apps from the Apple App and Google Play Stores. We aimed to identify and characterize third-party apps capable of automatically downloading clinical data either (1) directly through a FHIR-based API (e.g., SMART on FHIR22), or (2) indirectly through a mobile, smartphone-based interconnected personal health record (miPHR) such as Apple Health Records (AHR)23 and CommonHealth24 (*NOTE: both AHR and CommonHealth download clinical data through a FHIR-based API). We were particularly interested in whether there are differences in the emerging iOS and Android digital health app ecosystems.

Methods

We used a three-stage approach to identify and characterize relevant apps: (1) sampling health apps in the Apple App and Google Play Stores, (2) categorizing all sampled health apps, and (3) identifying and characterizing the relevant apps among the consumer-oriented health apps in the sample. This approach also enabled us to get a broader understanding of the current health app markets, offering insights into opportunities for expanding the digital health app ecosystem.

Sampling health apps. We created two samples of health apps. The first from the Apple App Store and the second from the Google Play Store. To create an initial sample of iOS apps, and similar to previous research,12,25 we first focused on the most popular iOS health apps. We defined “popular” based on Apple’s “Top Free” and “Top Paid” health and fitness and medical category-specific charts;26,27 this resulted in a list of 1,399 apps. Additionally, early discussions of the digital health app ecosystem included four use cases for third-party apps that may be able to use imported clinical data to improve their functioning: (i) medication tracking, (ii) disease management, (iii) nutrition planning, and (iv) research.28 Thus, along with “medical record,” we also did targeted searches of the Apple App Store using the keywords: “medication,” “disease management,” “nutrition,” and “health research.” We decided to start with these use cases, because in addition to some aligning with what healthcare organization leadership saw as important use cases (e.g., creating a longitudinal medical record),29 we hypothesized that their role in early discussions might make them most likely to be developed first. Only apps categorized as health and fitness or medical in the app stores were included in the sample. This approach resulted in 279 unique apps added to the list for a total of 1,678 iOS apps.

We followed the same procedure for the Google Play Store. The initial list included 644 popular health and fitness and medical apps.30,31 We then did the same targeted searches described above and identified 1,147 unique apps for a total of 1,791 Android apps.

Categorizing health apps. We used a qualitative content analysis approach32 to categorize the sampled health apps. First, we created an initial coding scheme by reviewing iOS app descriptions and discussing emerging categories. We noted that not all apps were consumer-oriented health apps (e.g., medical training materials). We developed high-level categories to capture this: Consumer, Healthcare professional, Veterinary care, Not available (e.g., not in English), and Not health focused (e.g., aptitude test). Only consumer-oriented human health apps were eligible for further analysis. Second, we used a primarily inductive approach to identify emerging categories within the consumer app category such as ‘Administrative’ (e.g., health insurance apps) and ‘Standalone Telehealth’ (i.e., apps offering virtual care seemingly not associated with a physical healthcare organization) under Clinical Care and ‘Self-diagnosing’ (e.g., COVID-19 symptom checker) under Self-Care. However, we also include four of the five previously mentioned use cases, with the nutrition use case being combined with other lifestyle management apps such as those focused on fitness. Two authors [TLR and MK] used this coding scheme to independently categorize 10% of the iOS apps (N=168) and the Android apps (N=179). The Scott’s pi coefficient was 0.895, indicating substantial agreement.33 We resolved all differences through discussion and continued to refine the coding scheme accordingly. TLR and MK then each coded half of the remaining iOS and Android apps using the final coding scheme presented in Figure 1.

Figure 1.

Figure 1.

Open in a new tab

Health and Fitness and Medical iOS and Android app coding scheme.

Identifying relevant health apps. We first used an iterative, keyword-based approach to identify potentially relevant consumer-oriented health apps. Our goal was to identify keywords that were likely to be used in the consumer-facing descriptions of relevant apps, but that would not lead to a lot of unnecessary noise. After reading hundreds of iOS app descriptions and testing different keywords, we developed the following final list of keywords and their variants (e.g., “apple’s health”): “apple health,” “apple health record,” and “healthkit.” We focused on AHR-related keywords because it is one of the most widely available miPHRs,34 making it the most likely mechanism by which other iOS apps will gain access to clinical data. In addition, given our focus on identifying apps using clinical data and FHIR- based APIs, we included the keywords “medical record,” “fhir” and “api.” We also used these three keywords to search Android app descriptions and added the term “commonhealth.” We included CommonHealth because it is an Android-based miPHR with connections to a growing number of HCOs that, like AHR, also allows patients to grant other apps access to their clinical data. Of note, we did test other keywords such as “health app,” which was sometimes used as a shorthand for Apple Health in app descriptions but found that this created a lot of noise without any actual signals. Similarly, with the term “SMART” (as in SMART on FHIR), given that it is commonly used to describe technologies (e.g., “smart device” and “smart period tracker”), it would have introduced a significant amount of noise. To ensure that we did not miss relevant keywords, we took a 10% random sample of iOS and Android apps in our samples that were not retrieved through keyword search and reviewed the descriptions for relevance. We did not identify any relevant apps or new keywords through this process.

For apps with keywords, two authors [TLR and MK] independently reviewed the descriptions of all the apps and, if necessary and possible, screenshots of the app and the downloaded app itself, and judged whether it appeared to be able to automatically download clinical data directly through a FHIR-based API or indirectly through a miPHR. We discussed and resolved any differences in opinion, resulting in a final list of apps that seem to be relevant. Overall, this approach is similar to past research, which also used marketing materials on app store pages to determine relevance.20 Finally, we characterized these apps by extracting pre-defined elements, including average rating, number of reviews, types of clinical data used, method of clinical data access, and privacy policy.

Results

Figure 2 presents an overview of our process and results. Specifically, we found that 1,272 of the 1,678 iOS apps (75.8%) and 1,449 of the 1,791 Android apps (80.9%) were consumer-facing human health-related apps (e.g., for condition self-management, medication management, lifestyle management, etc.). Almost 430 of these iOS apps and 111 Android apps contained keywords, with ‘apple health’ being the most common (N=294 iOS apps). This makes sense given how many health self-tracking apps connect to Apple Health. Ultimately, after manual review, we determined that only 18 iOS apps (1.4%) and nine Android apps (0.6%) appear to be capable of automatically downloading clinical data either directly through a FHIR-based API or indirectly through a miPHR (referred to as relevant apps). In addition, one relevant iOS and two Android apps were no longer available at the time of data extraction and were, thus, excluded from the analysis.

Figure 2.

Figure 2.

Open in a new tab

Summary of research process and results. AHR=Apple Health Records.

Among all consumer-oriented human health apps, and as Figure 3 shows, self-care apps were the most common for both iOS (N=913) and Android (N=1,006). However, the distribution of apps within this category was different, with Android having a larger percentage of medication management and self-diagnosing apps and iOS having a larger percentage of lifestyle management and condition self-management apps. Relevant apps fell into five categories: access to medical records (iOS=5, Android=3), condition self-management (iOS=3, Android=1), medication management (iOS=2, Android=1), standalone telehealth (iOS=3, Android=0), and research (iOS=4, Android=2).

Figure 3.

Figure 3.

Open in a new tab

Summary of consumer health iOS and Android apps by category. The numbers in circles are category percentages (with the denominator above or below the pie chart). The numbers in gray boxes are the number and percentage of relevant apps identified in that category. For example, 7% of the iOS and <1% of the Android medication management apps were determined to be relevant.

Table 1 presents an overview of these apps and their characteristics. Three of the seventeen iOS apps were identified through the “Top Free” medical category list; none of the included Android apps were identified through the top lists. The remaining relevant apps were identified through keyword searches, with “medical record” being the most common search term. Included iOS apps tended to have higher ratings (iOS Average: 4.0, SD: 0.6; Android Average: 3.35, SD: 0.6), with iOS versions of Livongo (Average Rating: 4.8, N=13,200), MDLIVE (Average Rating: 4.7, N=53,400), and Medisafe (Average Rating: 4.7, N=49,200) being the highest rated apps with this feature. All relevant apps were classified as free in the App Stores; however, some offer in-app purchases (e.g., Medisafe).

Table 1.

Summary of iOS and Android apps that appear to be capable of automatically downloading clinical data directly or indirectly via a FHIR-based API.

App Name App Store App Store Category Category Originally Identified (Sampled) Keywords in Description Clinical Data Access Method Clinical Data Elements Imported Average Rating (N) Policy Mentions HIPAA?
Livongo35 Apple Medical Condition Self-management Top Free ‘apple health’, ‘healthkit’ Indirect (AHR) Lab results 4.8 (13,200) Yes
HealthAI – Skin Cancer36 Apple Health & Fitness Condition Self-management App Store Search ‘apple health’ Indirect (AHR) Medical records 4.4 (148) No
Health Champion – Health Guide37 Apple Health & Fitness Condition Self-management App Store Search ‘apple health’, ‘medical record’ Direct Medical records 3.5 (61) Yes
Health Champion Symptoms, Care & Records Manager38 Google Play Medical Condition Self-management App Store Search ‘medical record’ Direct Medical records 3.5 (128) Yes
Medisafe Medication Management39 Apple Medical Medication Management Top Free ‘healthkit’ Indirect (AHR) Medications 4.7 (49,200) Yes
Coral Health App40 Apple Health & Fitness Medication Management App Store Search ‘medical record’ Direct Medical records 4 (15) Yes
Coral Health App40 Google Play Medical Medication Management App Store Search ‘medical record’ Direct Medical records 3.4 (16) No
Andaman741 Apple Medical Access to Medical Records App Store Search ‘fhir’, ‘medical record’ Indirect (AHR) lab results, vitals, visit history, medications, immunizations 3.9 (14) Yes
Andaman7 Private Health Record42 Google Play Medical PHR App Store Search ‘fhir’ Direct lab results, vitals, visit history, medications, immunizations 3.3 (272) Yes
Human API43 Apple Health & Fitness Access to Medical Records App Store Search ‘medical record’, ‘API’ Direct visits, procedures, lab results, vitals, medications, diagnosis, care plans 4.3 (29) No
myFHR by Care Evolution44 Apple Medical Access to Medical Records App Store Search ‘apple health’, ‘medical record’ Direct medications, procedures, allergies, diagnosis, lab results, appointments 2.8 (25) Yes
MyID – Medical ID Profile45 Apple Health & Fitness Access to Medical Records App Store Search ‘apple health’, ‘apple health record’ Indirect (AHR) diagnosis, lab results, allergies, medications 4.8 (1,700) No
OneRecord46 Apple Medical Access to Medical Records App Store Search ‘medical record’ Direct vitals, lab results, medications, procedures 4.2 (105) No
My Health, Mobile47 Google Play Health & Fitness Access to Medical Records App Store Search ‘medical record’ Direct Medical records NA (NA) Yes
Medlio – Health Records48 Google Play Medical Access to Medical Records App Store Search ‘medical record’ Direct Medical records 2.2 (26) Yes
MDLIVE49 Apple Medical Standalone Telehealth Top Free ‘healthkit’ Indirect (AHR) Medications, Allergies 4.7 (53,400) Yes
DrOwl-Med Records & Telehealth50 Apple Medical Standalone Telehealth App Store Search ‘apple health’, ‘healthkit’ Direct Medical records 3.2 (27) Yes
Health Interface51 Apple Health & Fitness Standalone Telehealth App Store Search ‘apple health’, ‘healthkit’, ‘medical record’ Indirect (AHR) Medical records NA (NA) Yes
doc.ai52 Apple Health & Fitness Research App Store Search ‘apple health’, ‘healthkit’ Indirect (Human API, AHR) Lab results 3.9 (435) Yes
Research by doc.ai53 Google Play Medical Research App Store Search ‘API’ Indirect (Human API) Medical records 4.2 (5) Yes
All of Us Research54 Apple Health & Fitness Research App Store Search ‘apple health’, ‘apple health record’ Indirect (AHR) Medical records 3.9 (26) No
All of Us Research Program55 Apple Health & Fitness Research App Store Search ‘healthkit’ Indirect (AHR) Medical records 3.5 (111) No
MyDataHelps56 Apple Medical Research App Store Search ‘apple health’, ‘medical record’ Indirect (AHR) Medical records 4.0 (65) No
MyDataHelps57 Google Play Health & Fitness Research App Store Search ‘medical record’ NA Medical records 3.5 (112) No
Abbreviations: PHR= Personal Health Record, AHR=Apple Health Records, NA=Not Available
Open in a new tab

In terms of importing clinical data, eight of the relevant apps claimed to pull in laboratory test results, eight medications, and three allergy information. Fourteen simply stated that they import medical records, presumably meaning that they pull all available clinical data elements. About 65% (11/17) of the relevant iOS apps appear to use an indirect method to obtain these data (AHR or an app called Human API), with only six seeming to directly connect to HCO EHRs via API access. Five of the six Android apps that provide details on data access seem to directly connect to EHRs.

About 63% (15/24) of the relevant apps mention HIPAA – the legislation that restricts the sharing of protected health information by certain institutions – in their description or privacy policy. However, three apps did not provide any details of the data elements collected by the developer at all and four had broken privacy policy links. Details about privacy are not as visible on the Google Play Store as the Apple App Store.

Discussion

Through this study, we sought to investigate the current state of the envisioned ecosystem of health apps capable of automatically downloading clinical data via FHIR-based APIs at the start of the Cures Act. While a thriving ecosystem may have the potential to offer patients flexible, convenient tools for managing their health, as well as opportunities for donating their clinical data for public benefit,58,59 the results of our extensive search show that there are currently limited options for patients. Among the available apps with this capability, most use an indirect method of access via a miPHR such as AHR. This study has implications for HCOs, health IT developers, app stores, and researchers.

First, increased patient awareness of this service and discoverability of apps with this capability are essential to creating the demand that could encourage health IT developers to leverage automatic importing of clinical data. Existing research suggests that many patients may be unaware of the new approach (standards-based APIs) for accessing their medical records established via the Cures Act, as HCOs have not advertised it.29,60 While it is understandable that HCOs may not want to appear to be endorsing specific apps, and Neinstein et al. identified specific barriers through interviews with HCO leadership such as potential financial exposure for third-party app data breaches,29 it is unlikely that these provisions of the Cures Act will benefit patients without educating them on the new approach and the corresponding opportunities and potential risks. Some third-party apps seem to be taking on this role; for instance, one PHR app states in its description, “If you’ve visited healthcare organizations that aren’t in the app yet, just ask the organizations to connect to Coral Health and they will be legally required to do so.”40 However, the reach of such education efforts is limited. Thus, HCOs have a critical role in increasing patient awareness of these key aspects of the Cures Act.

In conjunction with these education efforts, app stores should consider adding a discrete flag for easier patient identification of third-party apps capable of leveraging FHIR-based APIs to automatically import clinical data. We found that it was difficult to identify apps with this capability in the Apple App and Google Play Stores, suggesting that patients may also have trouble finding apps with this feature. If, for example, a patient is deciding if using AHR is worth it for them, one factor might be what apps can connect to AHR and how they may be able to leverage the data stored in AHR. This information does not seem readily discoverable in Apple App Store. Including such a flag would improve discoverability of these apps for patients and also facilitate future research, which is critical for both Policy and technology evaluations. A public registry of trusted apps with this capability could also serve a similar purpose and make decision-making processes that are currently being carried out at every HCO individually more streamlined and transparent,29 but this may not be as convenient for patients.

Second, our results suggest that there may be barriers to health IT developers leveraging this capability in their apps. There are a substantial number of health apps available in the Apple App and Google Play Stores. However, few offer the opportunity for patients to use their own clinical data to personalize and improve the experience of these apps, especially for personal health management. There seems to be considerable room for growth. For example, only three of the 191 medication management apps included in our study seem to have this capability. So, why are more third-party apps that might be able to make use of clinical data not yet offering this feature? It is possible that some app developers do not see the value or have other priorities. Perhaps some are hesitant due to privacy concerns surrounding clinical data. It is also feasible that the fears outlined by Gordon and Mandl of HCO and EHR-vendor practices stifling innovation could be manifesting.21 Understanding the barriers to app development is a critical topic for future research.

Further, the Android options seem to be lagging the iOS options. This may simply be because AHR has been available longer than the primary Android-based option, CommonHealth. However, even many of the early adopters that download clinical data from AHR do not seem to offer this same capability for Android users. It is possible that these app developers are waiting for CommonHealth to have a larger user-base (although at the time of writing it had 100,000+ installs61). The CommonHealth website also states, “only approved applications will be allowed to request data from CommonHealth.”62 Although this may be important for protecting users’ privacy, perhaps this additional process is creating a delay for Android-based third-party apps hoping to download clinical data through this mechanism. To avoid digital health disparities, it is critical for future research to identify and address any Android-specific barriers and for Android app developers to make it a point to offer this feature.

Finally, in terms of use cases for third-party apps that may benefit from automatically downloading clinical data, there appears to be an emerging opportunity for making clinical data more accessible and useful for patients by importing existing patient medical records into standalone telehealth apps for use in the provision of digital healthcare services. This type of app is becoming more common and, uniquely, could offer the two-way flow of clinical data, with data produced during these virtual visits also flowing back into a miPHR. We identified numerous standalone telehealth apps, but most with data sharing capabilities currently seem to be focused on self-tracked data, with only three of the 127 iOS and Android telehealth apps in the samples integrating clinical data. Developers of this type of app should consider offering patients the option of incorporating clinical data as well. miPHRs should consider whether and how to include records from digital healthcare visits not associated with the traditional physical HCO model.

Limitations. This study has similar limitations to other studies of the dynamic app market.e.g.,12 First, over the study period descriptions of apps evolved and some apps became unavailable; thus, this study provides a snapshot and baseline at the start of the Cures Act. Second, while we did download apps and review websites for additional details when necessary and possible, we were primarily limited to what was stated in the app description and shown in the screenshots, which may not always be very clear or detailed. For example, in the case of several standalone telehealth apps, they stated that they connected to the Apple Health app to share data elements such as weight. Since weight can be manually input by the user, automatically input by a smart scale, or recorded by a healthcare provider and stored in AHR, we had to test these apps to determine whether they were relevant to our study. Since the author that tested this had weight data from clinical encounters in Apple Health Records but does not self-track weight (either manually or using a smart scale), it was possible to determine whether the data point referred to self-tracked or clinical data. Additionally, although past research has also relied on descriptions,20 it is always possible that some apps overstate their capabilities and are not yet able to download clinical data via a FHIR-based API, which would result in an overestimate of relevant apps in our sample. At the other end of the spectrum, it is possible that some apps do not include whether they are able to automatically retrieve clinical data in their descriptions, which would result in an underestimate. We feel that the latter scenario is less likely, though, given (1) the competitive advantage it could give the apps and (2) the push towards greater transparency in data collection and use across apps. Thus, we feel it is most likely that this is an upper estimate for this sample, supporting the point that few patient-facing health apps in the open markets seem to be offering this capability. Regardless, we urge app developers to be clearer in their descriptions about the flow of health data into and out of their app, especially clinical data, so consumers can make an informed choice based on their privacy and security preferences.

The other key question is whether the estimates are applicable beyond these samples. While our approach included apps designed for a variety of health and medical purposes and still enabled us to identify use cases beyond those for which we specifically searched, it is still possible that some relevant apps were not in our sample. However, any additional app store searches would also add apps to the denominator, and this study suggests that a significant number of apps need to be reviewed for every one relevant app identified. The highest category-specific percentage of relevant apps was 7% meaning that, at best, for every 100 apps reviewed, about seven may be relevant. This reinforces our point about the need for a mechanism for easily finding apps with this capability and is also the reason that we feel confident in our conclusion that the number of apps with this capability is low. There is also a need for continued discussion of what the denominator should be when measuring the progress in the interoperable health app ecosystem. In this study, it was all consumer-focused human health apps in our samples. An alternative may be considering all health and medical apps in certain use cases (e.g., those most likely to benefit from automatically incorporating clinical data), but these use cases will likely evolve over time.

Conclusion

Research is needed to understand why more app developers do not appear to be incorporating clinical data into third-party health apps and why the iOS and Android app markets seem to differ. If these questions are not addressed and the markets do not pick up, it is possible that patients will not benefit from the direct patient access interoperability measures of the 21st Century Cures Act and that the vision for an integrated digital health ecosystem may not fully come to fruition. Even worse, this legislation could end up creating digital health disparities by benefiting iOS users more than Android users.

Figures & Table

References

Articles from AMIA Annual Symposium Proceedings are provided here courtesy of American Medical Informatics Association

RESOURCES