An Open API Movement Seeks to Create an App Ecosystem ONC makes push for APIs that are 'standardized, transparent, and pro-competitive'.
But regulators, health systems and innovators are working to bring such an app ecosystem to healthcare, making the open API movement one of Healthcare Informatics' Top Tech Trends to watch in 2018.
The 21 st Century Cures Act of 2016 calls for the development of modern APIs that do not require "special effort" to access and use. Rucker has argued that APIs need to be standardized, transparent, and pro-competitive. "Open and accessible APIs have transformed many industries," he wrote. "We think they can transform healthcare as well."
The fact that Apple is making a health records API available to developers and medical researchers signals that there has been considerable progress just in the past year.
Dave Levin, M.D., chief medical officer at Sansoro Health and former chief medical information officer at Cleveland Clinic, describes himself as an "API evangelist." He says that ONC (Office of the National Coordinator for Health IT) and the Centers for Medicare and Medicaid Services (CMS) have recognized that interoperability is the central challenge of healthcare IT today. "It is the foundation that so much else is going to have to rest on and a real barrier to innovation," he says. "I think they picked the right target."
The federal agencies also have realized that the rest of the digital economy has made huge strides by using API technology. "APIs are not new; they are just new to healthcare," Levin says. Work done by pioneering companies demonstrates that APIs, which work so well in other parts of the digital economy, also work quite well in healthcare, he adds.
One question regulators face is how to incentivize people to move in this direction. They have started to link reimbursement and EHR (electronic health record) certification to API use. The key to success may lie in the three words Rucker stressed: No special effort. That's because APIs could be done in a lot of different ways. Levin equates it with showing up in the United States with a European-style electric plug. "People will say, 'I recognize that is for electricity, but I don't know what to do with it.' This is what I see with some of the early offerings for APIs."
For example, he says, a developer might create a terrific third-party application and want to integrate that into a health system's EHR, where the clinical workflow occurs. The question becomes, whose plug to use? "If you show up with your app and some APIs, and say to a health system, 'all you need to do is adapt to my APIs,' that could represent a significant burden," Levin notes. CIOs will want your apps to have APIs that readily plug into their existing infrastructure. They don't want to have to make a special effort to figure out how to use your APIs or adapt them, he says.
Jonathan Baran has seen these issues from the app developer's standpoint. His company, Healthfinch, a Madison, Wis.-based startup, focuses on making clinicians' lives easier with software that automates or re-routes routine tasks in their EHR workflow. He says if ONC and CMS are looking to promote innovation in this space, open APIs are imperative.
Today, he says, working with EHR vendors requires that Healthfinch software engineers have domain expertise with specific EHRs to build applications. "We can't just hire engineers to interact with an EHR platform like you would with Facebook," he says. "That adds to the cost of innovation. Our expectation of a well-formed API is that I could bring someone in who has expertise and knows this space well, and they could work with a new EHR without having to understand a lot of the specifics about how that application works."
Baran is encouraged that ONC and CMS are focusing on APIs now. The challenge is that the timeline for startups and innovators and the timeline that ONC talks about rarely match up, he says. "We might have a year to prove a model is going to work or not," he says. The regulators' timelines are by necessity much longer. "It is going to be good for the industry, but it is hard for me to translate it into what it means for someone like us trying to innovate in the next 12 months. It probably isn't going to change much."
Standards under development such as HL7's FHIR (Fast Healthcare Interoperability Resources) offer ways of representing clinical data that are friendlier to web developers. In addition, EHR vendors, including Cerner, athenahealth, Allscripts and Epic Systems, have embraced the idea of creating app stores for their customers. Sumit Rana, Epic's senior vice president for research and development, believes the "app store" model will flourish in healthcare. Epic launched its "App Orchard" in 2017 with 13 applications and it is now nearing 100, he said. These third-party developers have access to APIs, documentation and testing tools.
Rana explains the genesis of the App Orchard this way: Customers started developing their own tools to work with Epic and asked the company to create a mechanism to help them share innovations. "We also realized this was a neat thing to extend to third parties and would standardize how our customers could discover applications offered by third parties," he says. "It lends a certain level of confidence that things will work well in the future, and in terms of considerations on security, privacy and scalability."
Epic's first App Orchard conference last year had 300 attendees. "This requires collaboration from the platform provider and developers but also the customers," Rana stresses. "We have a customer community that is very involved. The combination of all three parties leads to a better result."
Much of the work on APIs involves sharing data at the individual patient level, but ONC also is working with HL7 and the SMART (Substitutable Medical Apps & Reusable Technology) team at Boston Children's Hospital on the idea of a FHIR-based population-level data API. One goal is to create automated communication between back-end services and EHRs/clinical systems. The idea is that systems should be able to communicate with each other without a user having to log in once a connection is set up.
Possible use cases include:
* Exporting population level data to automatically compute quality measures.
* Gathering data required under CMS alternative payment models in a more automated way could be done more quickly and much less expensively.
* Using population-level data to identify the most appropriate patients to enroll in care management programs.
A writeup of a December 2017 meeting on population health APIs found that the most interest among EHR vendors, payers and providers involved instances where population-level data are already being aggregated, transferred and extracted, but doing so is difficult, inefficient and costly. Some EHR vendors expressed reluctance to spend time and effort where they have already created interfaces, but are open to a population-level data API for new situations where there is not an existing interface.
"Most of the effort with FHIR has been about sharing clinical information about an individual patient. That is a fine and logical place to start, but in healthcare we need to be able to identify cohorts of patients for a service or intervention," explains Sansoro's Levin. "It makes great sense that you would want an API that could show you a list of patients who just got critical lab results. You could take that in a lot of directions for population health, clinical research or optimizing scheduling. To me, that is a compelling use case."
In his blog post, Rucker points out that population-level data transfer that is aligned with HIPAA is "central to having a learning healthcare system, advancing many research priorities and use cases, and modernizing public health reporting."
Perhaps the most interesting business case-related question is whether the big health IT platform vendors will really be open to third-party apps that start to take on significant tasks.
Some developers have complained that although the large health IT players have committed to the FHIR standard, they still make it difficult for the startups to access their FHIR APIs or only implement some portions of the specifications.
"At some level, you can draw parallels to Apple and Android," Healthfinch's Baran says. "Android lets you change what you want. That creates one type of environment, while Apple is going to hold some things in its core and allow you to do other things. It is going to be specific to each EHR how open or closed they are going to be."
BY DAVID RATHS
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||TREND: The Move Toward Open APIs|
|Date:||Sep 1, 2018|
|Previous Article:||In the Fight Against the Opioid Crisis, Providers are Turning to Technology: Healthcare organizations are using health IT tools, including an...|
|Next Article:||There's Value in A.I., but Where Is the Value Greatest? The spotlight has been shining bright on IBM Watson of late as healthcare stakeholders ponder...|