EHRs as Platforms: Has The Time Come?

Introduction

With electronic health record (EHR) adoption in the U.S. nearing 100 percent among hospitals and ambulatory providers, the industry is increasingly turning its focus from adoption to optimization. While other sectors have seen technology transform the way they do business, even turning long-established business models on their head, the healthcare system has in many ways failed to achieve the transformation promised when EHR systems were first introduced. Consequently, the industry’s focus is shifting towards optimization.

One such optimization is the potential for EHR systems to serve as platforms for building a health IT ecosystem of tools and apps that will allow clinicians to practice medicine more effectively and improve patient outcomes. In other industries, the movement towards platform as a service or PaaS has enabled the rapid development of applications and tools that have transformed the way business is done, often allowing for the creation of tools that make formerly difficult or manual tasks automated and easy to do. Salesforce and Facebook are two widely known examples. A movement towards PaaS in healthcare could enable not only new tools that clinicians can use within their EHR systems but the ability to take in data from outside sources and make it actionable for clinicians as they provide care.

The broader impacts of PaaS have been profound. For instance, it has been an enabler of the gig economy, helped to create brand new industry segments, and enabled a whole generation of innovative startups to break into industries previously controlled by a few large companies. In healthcare, the development of modern, RESTful application programming interfaces (APIs) (predominantly FHIR)[1] are setting the stage for the same transformation, but will PaaS EHRs be the next big thing? If the answer is yes, how can healthcare organizations capitalize on this movement?

Current State of EHRs

EHRs are the primary method used to capture clinical data about a patient; therefore, they contain the most comprehensive data set about a patient within a given healthcare facility. Today’s EHRs are predominantly transaction-based systems focused on ensuring data is captured during an encounter so that the provider can bill appropriately and accurately for the services rendered. EHRs are typically built to access and display the most recent data about a patient as quickly as possible, rather than to provide a longitudinal and historical view of the patient’s health.

Rich, standardized metadata are a necessary precursor to creating the kind of API-driven interoperability that enables a system to function as platform. Metadata is data about data, e.g. who created the data, when was it created, when was it updated, etc. In an ecosystem where there are hundreds of EHR vendors, standardized metadata are imperative for building applications and tools that can work with any EHR.[2] However, today’s EHRs frequently do not use a standardized set of metadata for the key values/records they contain, making it difficult to build and use standardized APIs that will function in all EHR systems. Further, since today’s EHR systems were built for providers to chart patient data in the quickest manner possible, the systems often do not create or maintain sophisticated metadata of any kind, making it difficult to integrate with third party applications and products the way software systems functioning as platforms in other industries typically do.

Finally, a surprising number of the leading EHR vendors today use a program language that was developed by Massachusetts General hospital in the 1960s called MUMPS.[3] Less surprising, given the technology’s age, MUMPS-based database structures were not built with an API first mentality, but have proven remarkably capable even today of processing complex data quickly. Consequently, the FHIR APIs make the interfaces to EHR systems easier to build and maintain by a third party, but still require significant work to ensure they can interface with the legacy database structure of EHR systems.

Platform as a Service (PaaS)

PaaS is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure typically associated with developing and launching a full-scale software or app. As mentioned previously, Salesforce may be one of the best examples of a PaaS, serving a diverse market with a thriving marketplace for third-party developers and solutions. Salesforce is also similar to an EHR, in the sense that it has an underlying data model to service its core set of customer relationship management (CRM) functionalities. However, unlike a traditional EHR, Salesforce does not try to be all things to all users—or even anticipate who all its users might be and how the data could be used. Instead, Salesforce uses its core customer data as a resource upon which third-party apps can interact in a range of innovative and value-adding ways. To create this ecosystem, Salesforce is structured quite differently than a traditional EHR, but in a way that holds lessons for moving towards PaaS in health IT.

From the beginning, the founders of Salesforce took an “API-first” approach, meaning that development of APIs for a new feature always took priority over things like the user interface. Consequently, from day one, all new features are built with an eye towards third parties being able to access and use the features via APIs. An API-first approach also means that all data in Salesforce’s underlying data model use complex and standardized (for Salesforce) metadata tags, which support the development of standardized APIs. Creating a system where third parties can easily access and make use of data is the primary focus, not an afterthought.

Salesforce offers four types of APIs, each supporting unique use cases: 1) REST for mobile and web apps; 2) SOAP for server to server interactions; 3) Bulk for loading large amounts of data (50k records or more); and 4) Streaming which uses pub/sub capabilities to notify a system when changes have been made. Rather than trying to fit every use case into one type of API, Salesforce ensures that it has multiple options to best support the use case upon which a third-party developer is focused.

Challenges to Migrating towards PaaS EHRs

There are technical, policy, and market barriers to moving towards a health IT ecosystem where EHRs function less like transactional databases and more like PaaS. From a technical standpoint, the FHIR APIs enable a limited set of clinical data to be accessed. This data tends to be both narrow and deep. The Common Clinical Data Set (CCDS, being renamed by ONC to U.S. Core Data for Interoperability or USCDI) is built into the current version of FHIR (version 2 is the most commonly available version) and includes only 20 unique data elements, meaning that third parties looking to create new apps and tools using FHIR will be limited to what they can do with those 20 data elements.

Further, as noted earlier, rich metadata are vitally important for using APIs for more than simply reading data (though they are also important for that functionality), and the industry is lacking a standardized metadata model for the majority of data elements. Because both the data that is available via FHIR APIs and metadata are limited, third parties must use the EHR vendor’s proprietary APIs in order to tightly integrate with an EHR system (i.e. integrate into the clinician’s workflow and not only read but also write data into the EHR). This requires third parties to rebuild their APIs for each EHR vendor, making it difficult to scale their products.

The lack of richly documented, standardized APIs makes the work of interacting with EHRs much more people-intensive than it should be. Standard “triggers” do not exist within most EHR systems, let alone across EHR vendors, so third parties have to work with each vendor individually to understand how their app or tool will be activated when a user is navigating through an EHR’s workflow. Additionally, each EHR vendor has a different graphical user interface (GUI), which they often consider proprietary. Consequently, they do not publish or make available screenshots or pictures of their GUI, leaving app developers guessing at things like how much screen real estate they will have to work with. Third parties have to work directly with the EHR’s developers to understand all of these details before they can even build their app, creating an entry barrier.

And these are just a sampling of the many technical, policy, and legal barriers that exist. The picture they paint is of a market that is at best struggling to adapt and evolve, and at worst concluding that there are still few incentives to do so.

EHR Vendor App Stores

To date, the biggest effort EHR vendors have made to foster third-party access and innovation is the app store concept, as popularized by Apple, Amazon, Google, and other personal device makers. At least four major EHR vendors currently have app stores available (Allscripts, athenahealth, Epic, and Cerner), with the other major vendors launching their stores soon.[4] These four vendors offer both FHIR-based APIs and proprietary APIs to developers. Most of these vendors provide tiered services with varying price points to developers, ranging from no support (lowest cost) to a high level of programmer support (highest cost). For most vendors, prices include the upfront cost to get in the door, annual fees, and revenue sharing or royalty requirements, with pricing based not only on the level of service requested, but also the annual revenue level of the third party with non-profit organizations paying the lowest fees.

Thus far participation in the app stores of the two largest vendors is low as shown in the chart. athenahealth and Allscripts have much higher numbers, but compared to Salesforce’s more than 3,500 apps,[5] the numbers are still low. As noted earlier, building context-specific apps within EHRs is tricky and most often requires help from the EHR vendors themselves, which could be a contributor to lower numbers in their app stores as they need to have internal resources available to assist third parties.

Strategies for Success

As the industry works to optimize EHR systems, a movement towards PaaS EHRs seems like a logical step to providing innovative, easy to use tools within the systems clinicians are currently using. While there are a number of challenges to moving to a health IT ecosystem that is modular in nature with third parties providing apps and tools, both EHR vendors and third parties can take steps to overcome these barriers, and health information exchanges (HIEs) may be well-positioned to partner with third parties to overcome these challenges.

EHR vendors are understandably unlikely to rebuild their underlying data model to make it more API friendly. Too much time and money have been invested in their current structures, and the structures are optimized for use at the point of care, which is the primary use for EHRs. To support the broader set of use cases that rely on data liquidity and allow for an API first approach, EHR vendors can build API gateways that provide a layer of microservices surrounding their native database structure. Such gateways and microservices could use standards-based approaches to making data available, most notably the FHIR-based APIs. These gateways would enable EHR vendors to retain their native data model, while making large sets of data easily available via APIs, and could enable the security components necessary to allow APIs to write back to the EHR. Similarly, HIEs that also have access to large amounts of health data can use API gateways to enable easier access to their data and make it easier to build apps that can be integrated into an EHR system’s workflow, allowing HIEs themselves to begin to function as PaaS.[6]

PaaS providers and app stores such as those run by Apple and Google have built their stores to be self-service oriented, enabling developers to build new apps without having to interact with the PaaS developers. These organizations have gone far beyond a single document that specifies their APIs to provide build packs, scripts, and very specific documentation that enables developers to build their apps and know that they will work with the PaaS. EHR vendors could take the same route as PaaS providers and build out self-service tools, including a standard set of triggers for apps of a certain type, standard information about the GUI and recommendations on how an app should look when used in context, and an easy method for third parties to provide directions to the EHR vendor’s end users on how to install and use the apps.

The Case for HIEs

It will take time for EHR vendors to implement API gateways and build out self-service options for developers, and it is unclear if the terms and conditions required of developers will ever change from their current draconian form. There are, however, a few innovative ways third parties can partner with HIEs to build and deploy apps and tools that will make clinicians lives easier and improve patient care. First, HIEs often have the trust of the health systems and providers in the geographic area they serve. As discussed earlier, any app available in an EHR vendor app store, still must be installed and used at each individual health system or provider office. Many third party vendors have taken an approach of individually reaching out to various health systems to sell them on their apps/tools with varying levels of success. Though the varying success can be attributed to many things, including a lack of resources at the health system, it is also due in part to a lack of trust between the health system and third party that may be an unknown quantity to the health system. Partnering with an HIE possessing a strong relationship with the health systems it serves can provide an avenue for third party vendors to demonstrate the value of their tools to providers.

Second, HIEs have access to and, depending on their architecture, store a large array of health data. While the FHIR APIs are limited in the data they can provide, third party developers can work with HIEs to supplement the data, in real-time that their tool or app would need to provide innovative services. For example, many HIEs have access to Prescription Drug Monitoring Program (PDMP) data and are developing data sharing relationships with prisons and behavioral health. If a third party vendor wanted to develop a new algorithm that used not only the prescribing history from the PDMP, but also used other data about individuals from these other sources (only as allowed within the law), they could partner with an HIE to provide such data in real-time that would enable the algorithm to calculate risk scores and then provide such risk scores in the provider’s workflow when prescribing. These types of partnerships can provide a wider variety of data to enable a wider range of tools.[7] The Chesapeake Regional Information System for our Patients (CRISP), the HIE for Maryland, Washington, D.C., and West Virginia has been successful employing this model. CRISP recently deployed a Smart on FHIR app with critical HIE data across all the hospitals in Maryland to help support the state’s unique total cost of care model.

Third, as non-profit organizations, HIEs often receive preferential terms and conditions even in EHR vendor app stores. Some of the terms relate to the revenue sharing and royalties required in the developer contracts. HIEs have a wide range of business models that differ from those of software product companies. The typical business model is for a health system or provider to subscribe to the HIE, paying a flat fee, and receiving multiple services. Such a structure is ideal for an app store construct, where the app becomes part of the range of services a health system is paying for under a flat rate. HIEs can work with third parties on revenue sharing models that are beneficial to all parties while also being cost effective particularly for smaller vendors.

Finally, while HIEs can certainly partner with third party vendors to help deploy the tools they develop, HIEs themselves can develop innovative tools that make it easier for providers to access and use data. HIEs have long struggled with adoption by providers because the data they provide is not integrated into workflows and requires individuals to log in to a separate portal. Building out an infrastructure that includes an API gateway enables HIEs to provide their data in-context to providers, including alerts/notifications, PDMP data, lab results, etc. Further, HIEs typically have a governance structure that includes health systems and clinicians. HIEs can work collaboratively with their participants to understand the needs of clinicians and work with them to build innovative tools that will enable them to practice medicine more effectively.

The Case for Health Systems

Like HIEs, health systems may be uniquely positioned to build and deploy apps that meet the needs of their clinicians. Some of the challenges mentioned earlier include a lack of knowledge and resources that allow third parties to build apps, such as information about the user interface, the amount of screen real estate needed, and triggers for the apps/tools. Health systems have all of this knowledge within their clinical and IT groups. Their IT departments can work collaboratively with their clinicians to understand what tools would be helpful and what the best triggers might be for the tools they build. Further, health systems are often intimately familiar with the data models used by the EHR system, and they are aware of the data mapping decisions they have made and maintain over time. This knowledge allows them to work with the data in ways that third party developers cannot and build tools that use their own data in innovative ways. They also will know how best to integrate external data with their own systems, since they maintain data mappings. Health systems have the opportunity to partner with organizations who are experienced at building apps and supplement the knowledge gap that such vendors often encounter in working with EHR systems.

Conclusion

While it’s clear that a movement towards PaaS is necessary to enable a true health IT ecosystem of innovative tools, it is not clear at this point how quickly EHR systems will move towards PaaS and away from a structure that is transaction and encounter based. While there has been significant progress in the development of the FHIR APIs, the industry has quite a way to go to get to the API first approach of PaaS organizations. As we wait for that day to come, third party developers and HIEs should strongly consider innovative business partnerships that can capitalize on the strengths and benefits of each organization. By working together, these organizations can put new tools into the hands of providers now, enabling safer, more effective and efficient care of patients.

[1] Fast Healthcare Interoperability Resources (FHIR) is a standard developed and maintained by HL7. https://www.hl7.org/fhir/index.html

[2] http://library.ahima.org/doc?oid=106378#.W6UYKGhKiEs

[3] See https://motherboard.vice.com/en_us/article/3dkmg3/meet-mumps-the-archaic-health-care-programming-language-that-predicted-big-data-2

[4] Data as of July 2018 from Healthcare App Stores: Status and Outlook Market Scan Report. Chilmark Research. September 2018. https://www.chilmarkresearch.com/chilmark_report/healthcare-app-stores-status-outlook-report/

[5] App count is as of September 2018.

[6] See HIE.Next: Building an API-centric Infrastructure for Health Information Exchange. https://static1.squarespace.com/static/57049e5eab48de4f15507a08/t/5b50d3e5f950b7631b6c346d/1532023782277/HIE.Next+API+White+Paper+-+Final+.pdf

[7] Note that all such arrangements would need to follow federal and state laws and the HIE’s participation agreement.

To learn more about how Leap Orbit can help guide your organization’s API strategy contact us at info@leaporbit.com.

To download the white paper as a PDF, click here.