APIs and the App Ecosystem: Healthcare Tech Grows Up
Staring at the computer screen, Dr. Billy Ruben sighed. Line after line of the dozens of lab tests cluttered his screen, not unreadable but certainly unwieldy. He wondered how he’d get through deciphering all the data when he thought back to the conversation he’d had with his pediatric colleagues at lunch.
“Man, the new lab curve app has made my life so much easier!” his friend had said. “You all should try it out!”
Dr. Ruben clicked the icon in the corner of his desktop for EHR App Store and typed in “pediatric labs”. Within seconds, he found, downloaded, and was using the embedded visualization tool to pull lab data from his EHR and show it in curves to diagnosis and prevent jaundice in children.
He was startled. For years, getting access to a simple tool would have been nearly impossible, a series of hoops of technology, security and project management to jump through that no doctor had the time or effort for. How could it be so easy now?
Healthcare Tech Begins
The story above is not the story of healthcare today, but it’s the story of what it could become. Healthcare tech (and correspondingly, healthcare startups) is somewhat unique among technology industries. It’s a narrative not yet of disruption or revolution, but a slow evolution more akin to a Microsoft Word than an Uber. Integration is at the heart of that narrative.
Despite what doctors might say, hospitals historically needed software. The growth of the electronic health record (EHR) has revealed usability concerns impacting how our providers can effectively and efficiently care for patients. Nevertheless, that doesn’t negate a core fact that healthcare is driven by science and science is powered by data. Compiling, cataloging and correlating data is provably important and valuable to enhance care providers’ own abilities and knowledge.
The first phase of this effort is to simply record all this data. EHRs have had this purpose in mind, but, with the saturation of integrated, hospital-wide systems nationwide, only recently is this effort seen as near completion. With these single systems, healthcare organizations believe that they now have the comprehensive record for their patients. With this data in hand, many see the second phase arising, to utilize the data in a fashion to create meaningful conclusions to improve treatments, behaviors, and outcomes. This is where most vendors and start-ups are gearing their efforts. Analytics (deriving better meaning from the data at hand) and visualization (displaying data at hand in better ways to enhance understanding) are at the crux of many new companies and certainly of existing vendors’ initiatives.
However, jumping to this second phase represents a fundamental mistake or misunderstanding. While consolidation within the hospital walls has led to incredible data aggregation, these new companies will consistently hit the same wall, a stark realization that large data aggregation does not mean easy access.
Healthcare data access follows a fundamentally different pattern than most industries. It’s a story of standards, not services. This stems from the history of most hospitals and their IT, as the consolidated hospital-wide system is relatively new. The traditional healthcare organization in the previous decades was a fragmented series of semi-redundant information systems, best-of-breed programs tailored for a specialty or, worse, specific task or person. Cobbled together by file-drops, manual duplication and other error-ridden integration techniques, this ecosystem was fragile and too reliant on IT.
Standards as a Start
The healthcare information community recognized this problem and created a collaborative solution: data exchange standards. HL7 was developed by vendors and organizations to define a common vocabulary for these varied applications to converse with, simplifying (in theory) the exchange formats which a developer might need to adhere to. Understanding a format and developing against it could be done with simple online resources and therefore could be scaled in a vendor-agnostic way. In a best-of-breed world, this breakthrough allowed rapid growth in the communication between hospital applications and, therefore, growth in the variety of applications themselves.
Standards, though, have their drawbacks. Collaboration across competitors entails petty politics, ensures drawn-out decision-making, and impedes innovation. Adding a new data point to exchange may take months or years, a glacial pace in the modern DevOps world.
Furthermore, standards rarely guarantee compliance. Loose standards (HL7v2 with its Z-segments, for instance) necessitate longer implementation periods at organizations, as interface project managers align data definitions, code sets, and value ranges. This is overhead that small development shops or lightweight applications can’t afford to do or can’t do at scale. Implementation time and complexity kills sales and ruins timelines. Avoiding integration complexity is absolutely desirable and should be pursued at all cost. However, stricter standards (like many based on HL7v3 or CDA) require more rigorous development and potentially certification by third party organizations (which oftentimes are not skilled or resourced well enough to adequate provide support, testing or certification) to ensure compliance. This is a different sort of overhead that, again, may be beyond the means of niche applications.
This is where HIT’s past and present come into direct conflict. As mentioned before, the core competency of many new and exciting applications is not technologization of an existing workflow, such as laboratory tasks or surgical procedures, as these for the most part have been defined and their respective markets saturated. Instead, new products are aimed at advanced analytics or visualization. To do these things requires data and therefore data exchange, but the overhead of implementation or certification is a barrier most smaller companies are not equipped to deal with. Therefore, standards do not adequately address the fundamental data dependency that apps require.
From Web to Hub
There’s hope on the horizon. Healthcare technology is converging so that the organizational landscape is no longer a patchwork quilt of programs each delivering a small percentage of the capabilities, but a hub and spoke model with a single vendor delivering 80% or more of the capabilities, such as Cerner, Epic, and Athena, supplemented by niche products that augment the capabilities. This change in system level paradigm necessitates a similar change in integration. To scale no longer means scaling at the vendor level (how many vendors am I compatible with?) but scaling at the customer level (how many organizations can I reach and get data from?).
Luckily, the solution is readily available by looking at other industries with dominant, market leading players. When start-ups look to integrate with cloud services, for instance, they don’t develop against cloud service standards and then do customer level deployments. Instead, they look to develop against the API environments of Azure, AWS, and other vendors. Likewise, for mobile applications, developers program with Android or Apple APIs, allowing seamless deployment for those established customer bases at minimal implementation cost.
This is the shift coming to healthcare. It seems impossible at this point, but it’s no coincidence that suddenly we see a rapid creation and deployment of healthcare app ecosystems, such as Epic’s App Orchard, Cerner Open Developer Experience, Athena’s Developer Portal, or the Redox network. These systems drastically improve interface development, with more highly skilled resources dedicated to test and support integrations outside of the context of a customer than ever before. This is the revolution healthcare has been waiting for, allowing the shift to the second phase to finally occur.
Apps and APIs driving Innovation
App ecosystems can allow pioneering healthcare vendors to push development and testing prior to implementation and deployment, creating the potential of software personalization the provider level instead of the organization level. Companies that effectively leverage this new methodology will be successful. Those that do not will be left behind or struggle to compete. App ecosystems offer a new possibility to frontload the nuance previously built into implementation, shortening implementation times from months or years to days. Development can be done in advance of deployment, divorcing the two in a way that removes dependencies that typically plague installs today.
With integration simplified, end user features can be the sole focus and core competency for these companies. When installation is as simple as clicking a button in the app store, sales conversations with C-level executives will no longer be clouded by questions of servers and security, but can be focused on the return on investment, the benefits to providers and patients, and the lives saved. Furthermore, it shifts vendor relations to a business-to-business-to-consumer (B2B2C) model, allowing vendor developers to pay the EHR vendor for access to sell their product to their user base (sometimes still healthcare organizations, but now possibly providers or even patients). This alignment of business goals between developers, vendors, and customers is in stark contrast to competing priorities for implementation time and resources seen too often in the previous model.
For organizations, the benefits are readily apparent as well. The shift to apps means greater innovation with quicker timelines at minimal cost to security. Implementations can become installs, with a few decisions and clicks being the new status quo for deployment. Correspondingly, simple, easily deployable applications require less oversight, delivering another benefit in the form of less administration and therefore less staff needed at an organization. App support can be funneled to the developing vendor or EHR vendor, helping reduce organizational IT costs. The end user, whether a provider or patient, will get what they want faster and with less red tape. Given that the app has been vetted by the ecosystem owner, security concerns are minimized and, when they do occur, the quicker development and deployment cycles allow for timely resolution. Additionally, for organizations with large IT presences, the ability to push their innovations to market through app ecosystems becomes an easy path for improvement to care or extension of their brand.
For EHR vendors, there is a strong draw to build a robust, easy-to-use ecosystem by offering an easy-to-use set of APIs, a customer friendly App Store, and sustainable business models for outside vendors. In doing so, they can draw more developers, utilizing their innovations for persistent, passive income while putting their own in-house development efforts into the things that matter. Furthermore, they silently establish more control, in that their hospitals will be incentivized to use third parties developed in the app ecosystem over traditional standards-based third parties due to the quicker implementations and lower costs.
In short, there’s the opportunity to become the first healthcare vendor to see and reap the benefits that come from offering their development as a platform instead of a product: demand-driven multi-sided networks with decreasing acquisition costs. User acquisition becomes easier as it drives more developers to join the platform. Likewise, developers clamor to add their products as the user base grows, as they can scale much more easily.
What next?
This revolution comes with caveats. Developers need to investigate and weigh the respective ecosystems’ benefits and drawbacks (just as you would with Android or Apple).
- Company health: Where is that ecosystem heading? What is the attached userbase? What is the predicted userbase?
- Cost: What are the fees of operating in that ecosystem?
- Competition: What protections for intellectual property are built into that ecosystem? What is preventing your vendor from developing a direct competitor?
- Complexity: Is it easy to develop in the ecosystem? Are the APIs simple to use? Is the functionality available through the APIs?
- Care: What support is given by the ecosystem to help your product? Will the ecosystem develop new features at your request (prior to a shared customer commitment)? How well documented are the web services?
Based on the numbers, Athenahealth’s Marketplace appears to be the market leader, with hundreds of apps available and a clear vision of creating a disruptive app ecosystem. Epic’s App Orchard follows closely, with over 100 applications available in a clean, easily understandable marketplace. Cerner, lags behind in both quantity and display, showing a small overview of 23 apps on their App Gallery page. But Epic and Cerner both have a large established user base of sprawling, multi-hospital organizations for whom developers will certainly want to their apps to be available to.
Redox offers an alternative paradigm, abstracting out the EHR layer and offering a single data model and API for developers to utilize. This is akin to Steam creating a platform layered on top of operating systems, a valuable differentiation from EHR vendors’ platforms. They didn’t have the benefit of the established user base that the EHR vendors do, but given their listed healthcare organizations and signed-on developers, they’re already seeing rapid success by offering a better development experience. Their critical challenge, however, will be whether their ecosystem truly offers the same functionality gains compared with EHR APIs and whether their model can reduce implementation overhead in the same way.
This is a shift that may be resisted. Standards did not entail additional costs, so the idea of paying to utilize methods of data exchange may be irksome. EHR vendors and others may still limit the potential of app ecosystems if they do not create and utilize them correctly. Additionally, standards are entrenched in existing healthcare organizations and many may view the app approach as a competing or duplicative strategy.
However, standards still serve a purpose in the new paradigm, further simplifying the development strategy. If Apple and Android shared a common API for similar functions, developers would certainly prefer that. The new requirement of these standards, however, will be that it is usable, testable, and scalable in advance of customer deployment, with dedicated vendor support. Experienced EDI implementers will rightfully question whether HL7v2 can be deployed in an app ecosystem given the organizational level variety of code and value sets. Newer standards purport to offer more of an API mindset (FHIR is specifically designed as a RESTful API), but it will remain to be seen whether they will be truly implementation-agnostic. Similar to HL7v2’s Z-segments, FHIR has the concept of extensions, which adds a questionable and potentially problematic flexibility.
Regardless, change is coming. If app ecosystems can deliver even a fraction of their promise, it will inject new life into a stagnant industry. At its best, it promises to bring health and the corresponding wealth of discrete data to the forefront of tech.
If you found this post interesting, it would mean a lot to me if you could click on the “claps” icon below to let me know. Let me know through the comments your general thoughts. For more in-depth discussions, feel free to reach out via email at brendanjkeeler@gmail.com. For developers, I’d love to hear about your experiences in using any and all of the app platforms out there, both for development but also in regards to implementation simplification (or not!).
If you enjoyed this content, I also recommend reading about general Aggregation Theory and more generally the posts on Stratechery, which a colleague pointed me to while editing this post.
