Driving Innovation in Health Systems through an Apps-Based Information Economy

Abstract

Healthcare data will soon be accessible using standard, open software interfaces. Here, we describe how these interfaces could lead to improved healthcare by facilitating the development of software applications (apps) that can be shared across physicians, health care organizations, translational researchers, and patients. We provide recommendations for next steps and resources for the myriad stakeholders. If challenges related to efficacy, accuracy, utility, safety, privacy, and security can be met, this emerging apps model for health information technology will open up the point of care for innovation and connect patients at home to their healthcare data.

Six years into the US government's plan to spend $48 billion dollars on information technology for healthcare (health IT), electronic health records (EHRs) are about to be widely connected to modern-day software applications (apps) running on the web, local intranets, or mobile devices. These apps will give new life to data entered into EHRs and other health IT platforms by providing the ability to visualize risks, trends, and trajectories; mash up clinical records with external data sources; and deliver decision support to clinicians and patients during and between encounters. Apps will also create new flows of data from sensors, devices, and patient reports into EHRs. This tectonic shift toward 21st century IT, which mirrors changes sweeping across other industries, will change the experience of physicians and patients, dramatically increasing return on EHR investments. These shifts are occurring world-wide, with the first effects likely to be seen in the U.S. where the meaningful use program for certification of health IT (Blumenthal, 2009) drove substantial adoption of EHRs (Wright et al., 2013).

Beyond the Limitations of EHRs

EHRs principally show a doctor information she entered previously, but not the wide range of data and services that should drive cost-efficient care and decision making. Most healthcare organizations limit the technology platforms a physician must use—often to a single, recently purchased EHR—largely because integration with the EHR after purchase is an expensive, slow process that must be repeated for each new customer and each product. This walled-off market has posed insurmountable barriers to entry for startups and larger firms alike. It has also limited physicians' ability to customize EHRs in ways that improve care or workflows.

An apps layer will open the clinical encounter to third-party IT innovation. Often those third parties will be the healthcare personnel using the EHR-driven transactions and data in a way that others had not imagined. Fostering third party apps creates a market where innovations compete with each other for purchase and use by providers (and patients), thus reducing dependency on updates and specific functions made by an EHR vendor. Many vendors now see that nurturing this app ecosystem is essential to both continuous improvement of EHR modules and addressing the myriad specialized needs of our complex healthcare delivery system (Halamka, 2014).

Developing apps and integrating them for use solely with a particular EHR system may be done by EHR vendors. But this may not be the best outcome for many functions, such as automated dissemination of triage protocols in a spreading epidemic (Mandl, 2014) or genomic test interpretation, where authoritative rapid dissemination of practice are in the patients' best interest. In these cases, it may be more effective for an app to be implemented by one of the many smaller vendors constituting the long tail of the market's curve rather than only by one of the few dominant EHR companies.

Precision Medicine: An Illustrative Use Case

In his 2015 State of the Union Address, President Obama announced his precision medicine initiative to develop the science and evidence needed to personalize treatment decisions for patients in everyday practice. The first step in the initiative will be to recruit a cohort of a million patients consenting to be extensively characterized by whole-genome sequencing, RNA expression, and behavioral data all linked to their EHRs (Collins and Varmus, 2015). Similar to what was proposed in a 2011 landmark National Academy of Sciences report (National Academy of Sciences, 2011), these data would underpin a new taxonomy of disease, derived empirically from associations between genotypes and phenotypes. This new taxonomy sharply contrasts with the contemporary International Classification of Disease (ICD)-9 and ICD-10 systems, which are based on symptoms, microscopic pathology, and laboratory data.

Appropriately, these bold initiatives focus on data collection, discovery, and analysis—the “afferent limb” of precision medicine. There is ample precedent for linkage of EHR and genomic data to rapidly build upon. The National Human Genome Research Institute's eMERGE network, for instance, has been used to study cohorts of patients with bio-specimens linked to EHRs (McCarty et al., 2011). And even though EHRs are not designed to be used as input for data analytic engines, methods have been developed to extract, transform, and load EHR data into research platforms such as i2b2, which underpins national multicenter efforts in clinical and translational research (Mandl et al., 2014; Masys et al., 2012).

Translating this knowledge into clinical practice—the “efferent limb” of precision medicine—reveals the limitations of current EHR systems. How will the innovations from the President's initiative reach the doctor and the patient, and how will the new data types needed for precision medicine be integrated into medical decision making? EHRs are not designed for storage or display of genomic data nor for the computation that will no doubt be needed to eventually tailor therapy to a patient's genome.

Advancing Healthcare with Apps

Robust healthcare apps would facilitate the delivery of services that should be the lifeblood of accountable healthcare organizations seeking to improve care and reduce cost. In addition to precision medicine, apps could be used for population health analytics, integration of data from multiple devices that track fitness and activity, monitoring and improvement of medication adherence, chronic disease management, and identification of high-risk and high-cost patients and coordination of their care. Unlocking these services at national scale, without deep one-off integrations, would facilitate the work of public health agencies, enabling them to reliably alert clinicians about infectious diseases (Mandl, 2014) or post-market medication safety concerns.

An apps ecosystem could also advance healthcare by merging the clinical and research missions with tools that match patients to, and engage them in, clinical trials. The first apps based on Apple's recently released ResearchKit software framework use modular consent and mobile data collection to make clinical trials accessible to anyone with an iPhone. And Apple's HealthKit framework that centralizes storage and enables sharing of data from health and fitness apps, or something similar, could ultimately become a standard interface to a patient's medical devices, such as glucometers and cardiac monitors as well as sensors and wearables (Box 1).

Box 1. Wearables and Continuous Sensors.

The largest source of individual health data is likely to be from sensors that record information about a person continuously for days or even years. Many such sensors are being integrated into wearable devices to measure heart rate and movement or into objects in the environment, such as beds in a hospital's intensive care unit that measure intracranial pressure or beds at home that record sleep-time activity. Whether or not these data find their way to the institutional EHR or specialized storage for streamed data, clinicians and patients will expect to be able to view derived and or summary measures and also have decision support (e.g., alerts) driven from the primary or derived data. In principle, this task is no different than displaying or interpreting any other data in an EHR.

However, the reality of the growth in the “wearables” industry (e.g., Fitbit or Apple Watch) has vastly outstripped any standardization efforts (Redmond et al., 2014), which suggests that the initial sets of apps for these data streams will remain confined to their respective platforms and also integrate with EHR data in very limited ways. Patient-driven open data efforts (Chiauzzi et al., 2015) may be required to enforce cross-platform standardization.

Implementation of third party apps on an EHR platform will certainly raise a host of new issues regarding who pays for the apps and who vets or regulates them. Specifically who will be responsible for their accuracy, reliability, data security, and compliance with privacy regulation? Answers will be determined by who uses the apps and the particular context in which there are used. At this time, despite the emergence of apps in the healthcare work environment, these questions are largely unresolved.

Opening the healthcare encounter to apps would increase the impact of the Affordable Care Act by facilitating delivery of cost data to ordering physicians, supporting price transparency, and enabling automated identification of high-risk, high-cost patients for case management. Because no one solution will fit all, an ecosystem of diverse apps will make it easier to experiment with a far wider range of patient-management options. This breadth is necessary if healthcare is to be transformed much more efficiently. Ultimately, the ecosystem will comprise innovative third party apps that run for the physician in the context of an EHR, mobile apps that extend physician's workspace, and mobile apps that bi-directionally connect delivery system data to mobile apps that reach the patient.

An apps model enables rich data visualization well beyond the capabilities of any existing EHR. The value of this function alone cannot be underestimated. At Boston Children's Hospital, an app for managing hypertension, which simply displays a child's blood pressure over time adjusted for age by percentile, has been used tens of thousands of times over the past two years. As discussed below, a public software interface to health system data will enable deployment of this and other apps not as one-off projects but universally across healthcare settings.

Apps also permit integration of “big data”(Weber et al., 2014) from external sources—such as massive payor databases covering hundreds of millions of individuals, genomes inexpensively stored on the Google cloud (Regalado, 2014), or data from public health surveillance systems (Mandl, 2014)—to the point of care to drive decision making.

Hello APIs

An ecosystem of apps should be based on free, open healthcare application programming interfaces (APIs) that define how apps can connect to any EHR or data warehouse (Figure 1). In a report in 2009 (Mandl and Kohane, 2009), we made an analogy to the consumer technology space, where smartphones offer well-specified APIs to software developers, enabling an app market with incredible diversity and quality. Importantly, healthcare APIs would enable “substitutable” apps, meaning apps that can be readily added to or deleted from an EHR or a mobile device that draws data from an EHR. Substitutability enables a tailored end-user experience—contrasting with today's one-size-fits-all approach, in which gynecologists and dermatologists share the same EHR experience (or where specialists purchase custom full-stack products that integrate poorly across delivery systems).

Figure 1. Creating an Ecosystem for Apps.

The lower panel shows a classic EHR with a standard view of the data. Above is shown an ecosystem of apps supported by a uniform public application programming interface for healthcare data. A third party app written once can run anywhere. The app can be reused on multiple EHRs and other forms of health information technology. The end user can select apps from a gallery or “app store” and, just as on a smart phone, one app can be readily be substituted for another. Image courtesy of Rachel Eastwood.

Substitutable apps in healthcare are no longer science fiction, and a wave of activity around both technology and regulation is accelerating their adoption (Fisher, 2014; JASON and The Mitre Corporation, 2014). Major healthcare systems are implementing APIs on their EHRs. And proposed language for meaningful use stage 3—the U.S. regulations specifying requirements for health IT certification and consequent Centers for Medicare and Medicaid Services (CMS) payment—specifically embraces APIs as a strategy for engaging patients and enabling “data portability” for providers. To implement such APIs, technologists are converging on Health Level 7's (HL7's) Fast Healthcare Interoperability Resources (FHIR), an emerging draft data standard that greatly facilitates agreement about how to exchange healthcare data.

Taking up the mantle, the leading health data standards organization, several federal IT committee co-chairs, multiple major delivery systems, five major EHR vendors, and the SMART team that we lead recently joined forces in a project called Argonaut (Halamka, 2014) to initiate pilots supporting uptake of healthcare APIs and driving their possible inclusion in meaningful use regulation. To create an app that runs anywhere, an app developer must know precisely what to expect when making a data request. If an app asks for the medication list, the system should respond uniformly and consistently. The app developer should not need to know how the underlying data are stored or which brand of EHR it is running on. A standard, public, open API will define a new form of interoperability across systems.

Implications for Providers, Patients, and Researchers

How much does this techno-nerd tinkering and policy plotting matter to the average physician, health care organization, or translational researcher? A lot. Although it is now virtually inevitable that, as we recommended 6 years ago (Mandl and Kohane, 2009), many EHR vendors will implement APIs allowing access to health system data by third party apps (Epic recently announced that they will support an apps exchange [Monegain, 2015]), the devil is in the details. Worryingly, the ultimate benefit to the health system and physicians could vary widely, depending on how these APIs are implemented and whether customers of health IT become educated and exacting. If the health system can respond in a coordinated fashion, there will be a core set of open, widely adopted, well-specified APIs that allow apps to run across diverse health IT systems, creating tremendous economies of scale. But if we lose focus on this goal, the functionality of EHRs may improve, but the large market may never materialize to incentivize innovation, or app developers may need to create multiple different versions of each app for different EHR systems.

Patients will benefit from a uniform API that enables a new and different generation of mobile apps. The vast majority of the mobile apps currently available to smartphone users are disconnected from the care delivery system. With a uniform, public, standardized API, mobile apps can request data from the healthcare delivery system, and ultimately also write data back into EHRs and other forms of health IT. Data from sensors, devices, and wearables will be “mashed up” with clinical data such as laboratories and radiographs, and will also be written back into the official electronic record.

With a core set of common APIs, appsbased competition will drive robust, healthy market forces. Physicians and patients will enjoy a rich and ever-evolving ecosystem of apps, and they, rather than only technology vendors or government committees, will decide which health IT products are beneficial and valuable.

Immediate Next Steps

Physicians, practices, and larger healthcare delivery organizations, when seeking to purchase or renew contracts for health IT, should adopt common RFP language (Table 1), specifying and requiring inclusion of a uniform healthcare API. The SMART API, based on open standards including FHIR, OAuth2, OpenID Connect, RxNorm, SNOMED, and LOINC, is a good place to start. They should begin to hire app developers, partner with technology companies, or watch the market for new products.

Table 1. Resources for App Builders.

Resource	URL
FHIR API	http://hl7.org/fhir/	A resource-oriented healthcare API providing about 100 resource definitions, including clinical, administrative, and financial data, as well as a REST API defining Create, Read, Update, Delete, and Search functionality.
SMART API	http://docs.smarthealthit.org/	A health app platform based on open standards including FHIR for clinical data, OAuth 2.0 for authorization, OpenID Connect for single sign-on, and HTML5 for embedding apps inside of an EHR.
Research Kit	https://www.apple.com/researchkit/	An open-source framework that enables the development of apps for medical research, including consent workflows and data collection.
Health Kit	https://developer.apple.com/healthkit/	An iOS Core Framework for managing personal health data with a focus on measured quantities (e.g., step counts, home glucose readings, blood pressures).
Google Fit API	https://developers.google.com/fit/	A set of Android APIs for capturing and querying fitness-related sensor data including calories steps, calories burned, and nutrients consumed.
Validic API	http://validic.com/api	An aggregated API that normalizes and exposes data from health and fitness devices and applications. Data from multiple vendors are exposed in a consistent format.
2net Platform	http://www.qualcommlife.com/wireless-health	A platform for aggregating device data with a focus on wireless devices including glucose meters and inhalers, with a standalone home-based hub that aggregates and uploads data.
RFP Language for Buying API-enabled HIT	http://smarthealthit.org/2014/10/rfp-language-for-buying-smart-compatible-hit/	A set of recommendations for organizations purchasing health IT systems, with a focus on providing support for standards-based third-party app integration.

Health IT vendors should continue to voluntarily adopt open health data API standards and implement these standards in their products. Vendors should provide tools and infrastructure to support self-service registration of applications (as on smartphones).

Software developers, public health agencies, payors, pharma, and startups should request access to health system data through common, open APIs, instead of via expensive and often untenable one-off integrations.

Policymakers at the Office of the National Coordinator of Health Information Technology (ONC) and Centers for Medicare and Medicaid Services, if the meaningful use program is continued, should restrict future certification requirements to functionality implementable through EHR apps using a common, open set of healthcare APIs.

Research agencies, including the NIH, should fund researchers developing point-of-care innovations not to create one-off efforts fit to the peculiarities of individual healthcare institutions, but rather as generalizable applications that can run widely and transform healthcare.

Fostering Quality

At first blush, a free market for apps that encourages innovation and competition among companies and other contributors might seem best. However, even in the enormously successful Google Play and Apple App Stores, the medical apps are highly variable in quality, utility, and safety. The popular and lucrative apps are not necessarily the best or the most effective. Regulation and quality standards from one source, such as the government, often can result in inflexibility and slow progress. So how can we navigate between free market and the quality that we hope all apps will meet at minimum?

First and foremost, physicians, patients, and organizations running apps must be assured that the apps they run are safe and non-malicious. The US Food and Drug Administration's (FDA) foray into mobile medical app regulation caused concern over stifled innovation (Thompson and Brodsky, 2013). It appears that the agency will concentrate on apps that function as an accessory to a currently regulated medical device or which will effectively transform a tablet or smartphone into a regulated medical device (McCarthy, 2013). But even as the FDA backs down on regulation, the US Federal Trade Commission is cracking down on apps making unsubstantiated medical claims (Saxena, 2015).

Regulated or not, because apps will require access to health system data, they must be must be vetted not only for efficacy, but also for accuracy, utility, safety, privacy, and security. There will no doubt be calls for a formal certification process, but in the past, a single point of certification for health IT came under scrutiny for being too closely tied to industry (DoBias, 2006). End-users would be better served by a system with familiar, trusted sources of authority, including professional society seals of approval, patient and physician ratings, and quality checks and validations by expert organizations.

A major challenge now for a developer of apps outside the major health IT vendors is that they tend to lack access to high quality health system data for development and validation (Taylor and Mandl, 2015). Another is that most health IT vendors have generally pushed liability onto the health system users of the products (Koppel and Kreda, 2009), and it can be expected that app vendors will be asked to asymmetrically take on risk and provide indemnification. But clearly, in an apps-based health IT economy, there will be opportunities for alternative approaches that would improve product safety, including open and public sharing of data on performance and harms.

Standards for handling data privacy and security (Sunyaev et al., 2015) as well as rules for “good” app behavior will need to be developed—for example, an app should request the minimum data-set required to perform its function. And, in contrast to the vast majority of healthcare apps currently available for smart phones, clear and accurate privacy policies should be available to guide selection (Sunyaev et al., 2015).

Because the app may run on a computer outside the home institution housing the EHR, Health Insurance Portability and Accountability (HIPAA) business associate agreements (BAAs) may need to be in place between the apps company and the clinical entity running the app.

Ultimately, EHRs and other forms of digital health technology that can provide a highly usable apps framework, enabling concurrent use of apps selected from a variety of “best of breed” sources will be strongly advantaged in the marketplace. Vendors wishing to transform their EHR products into robust apps platforms may need to retool their products to support API calls and with sub-second response times. Recognizing the difficulty of doing so, startups are already arising to create platforms that run apps on high performance, distributed database architectures with data extracted from EHRs—what we call “side cars” (Mandl et al., 2014).

Conclusion

The US healthcare system now has the opportunity to widely implement substitutable apps, shifting the paradigm for sharing knowledge and know-how and greatly accelerating healthcare reform and efforts to contain cost. Currently, clinical knowledge is shared through publications, guidelines, and consensus statements triggering the beginning of long adoption cycles for new advances. In contrast, apps can transfer ideas, functionality, and workflow all in one package. A good app, distributed widely, could reshape practice overnight. An innovator's idea, whether to improve care through precision medicine or through payment reform, becomes implementable at the point of care across the healthcare system. Agreement on, implementation of, and adherence to a standard, public, free, and open API will promote a new form of interoperability transforming healthcare into a modular plug and play system, dramatically increasing the rate of progress while reducing the cost of change.