Here's what innovators really need from EHR makers to move healthcare forward

Healthcare is on the verge of open APIs and data, developer programs from leading software vendors, and an even bigger rush of upstarts and entrepreneurs looking to create digital health tools that usher in a new generation of care delivery fit for consumers by focusing on patient experience.

As exciting as that is, however, there are a few things innovators really need to overcome the prevailing sense that the industry must move faster.

Big electronic health record vendors such as Allscripts, athenahealth, Cerner, eClinicalWorks, Epic and most recently Meditech have third-party developer programs, with varying degrees of participation and success. In the meantime, innovators have the opportunity to create apps for other companies platforms as well.

Here, then, are some basic tenets of innovation that app developers need most from big EHR vendors.

A playbook

It seems so straightforward, but a widely-accepted playbook for app developers doesn't really exist relative to healthcare. "Other industries taking a more open approach look at developers as a customer," said Vince Kuraitis, a consultant currently working on a book, Platforming Healthcare: From Hoarding to Sharing. "There's a playbook outside healthcare about how to be developer-friendly. Apple, Google, they have this down."

Fair and transparent pricing

It’s not easy to know ahead of time how much you will end up paying an EHR company for taking part in their developer program. Some vendors initially took 30 percent of top-line revenue for participating in the developer program, which Tina Joros, Allscripts vice president and general manager of the company's Open Business Unit, said started because that's Apple's price for its own app store. But Allscripts has since changed its policy to offer three tiers, with pricing based on options and usage fees as measured by API calls in a live, production environment. Epic App Orchard Integration Lead Isaac Vetter said that its programs overall costs vary based on API complexity, transactions and how much support Epic provides. “Today the developer is typically charged a revenue share and an annual program fee,” Vetter said. “It is a relatively new program, and as such, we continue to evaluate our pricing structure in response to feedback from our user and developer communities.”

Clear terms of service

HIMSS Innovator-in-Residence Adam Culbertson said one key question destined to emerge from the app ecosystem is exactly what the terms EHR vendors offer developers should be, and will be. "Developer programs need to nail down clear terms of service so innovators can get started," Culbertson said. "The technology alone can't build viable businesses."

A single version of FHIR

The Fast Healthcare Interoperability Resources specification is full of promise. But as of now there are various iterations. "We're moving into the FHIR world but everybody's doing it differently," said Nick Hatt, a senior developer at Redox. "Everybody's excited about FHIR but not thinking about long-term implications of having two separate code bases. If athena or Epic has its own version, there can be out of band quirks." Many eyes are on the next incarnation of FHIR, version 4, to see if it will bring the ecosystem closer to a single standard.

Broader support for FHIR

An upstart developer real early in the process might have a handful of potential hospitals in its pipeline. But if one runs Cerner, another Epic and other Allscripts or athenahealth, the quandary is determining which EHR to commit to before singing that first test customer. "That's the big killer for startups," Hatt said. "It would be nice if you could do everything with FHIR at these places but it's just not the case." It's not like Apple vs. Android where developers have to write for both but then that's it, just the two.

Business side processes

Despite those FHIR challenges, technology can often be the easy part. That's true within developer programs, too. "The tech is only part of what it takes to actually connect a solution," said Tina Joros of Allscripts. "Developers might need help on the business side process, such as how to get the app installed at a client site."

A truly open mindset

EHR vendors have to treat developers as equals to really grow their platform – and that can be hard when their competitive posture is akin to their software being the center of the universe. History and the current state of interoperability would suggest that such a syndrome is more common than not, at least as of today. "The Amazon model is the mindset I'd hope the healthcare industry would aspire to, where you don't kick somebody out of your app store because they're a potential competitor," Kuraitis said. "Amazon is imperfect in the way it treats developers but the general concept of accepting a broad range of apps goes a long way."

Brian Murphy, director of research at Chilmark, said all these factors are gospel for developers, and some will in time be speed bumps that ultimately help EHR vendors and hospitals better serve clinicians and patients by more effectively collaborating themselves.

Until all that happens more widely in healthcare, however, startups will be hindered by the chicken-and-egg conundrum, an obstacle for both EHR vendors and startups alike: How can an EHR maker attract customers to third-party apps without having a bunch of developers building them? And, in turn, how can the company inspire innovators to write to its platform when before providing a range customers who will use the app?

Overcoming that challenge is critical. Because creating an ecosystem of outside developers that can bring new capabilities — writing apps that EHR vendors either don't have the time to add or would never even think of — is necessary, not just for the healthcare industry at large, but for the vendors' own good.

Twitter: SullyHIT
Email the writer: [email protected]

Source: Read Full Article