Back to Pilotfish Home

Our Blog

icon

Here an API, there an API, where an API?

Will FHIR dominate as the Open Standard API?

Interoperability, Application Programming Interfaces (APIs) and Fast Health Interoperability Resources (FHIR) – HL7’s promising standards-based open API – are ubiquitous in healthcare conversations, but not so much in healthcare organizations.  Plus, the feds have been pushing hard to give developers and patients ways of accessing EHR data through APIs. Simply put, there’s been a lot of excitement, progress, experimentation and hype.

An API specifies a software component in terms of its operations, inputs, outputs and underlying types. They are lightweight services – so systems can consume them on the web, cloud, or mobile. A common API analogy is to a recipe or contract where a set of specified data can be accessed under specified conditions by developers. Practically speaking, they operate as a common ‘gateway’ into exposed features and functionality of a product, thus simplifying data access.

FHIR, a leap forward from HL7, uses sets of data known as “resources” to represent  granular clinical domains within EHRs – such as diagnoses and medications and other clinical entities. These resources can be built on top of standardized data types and are utilized in a Restful API similar to those that app developers already use across the Internet.  FHIR describes the content of data being exchanged and the query API to be used. The API describes the FHIR resources as a set of operations (known as “interactions”) on resources where individual resource instances are managed in collections by their type.

Where’s the Healthcare API Action?

Stay tuned! The Health IT Policy Committee’s API Task Force has been working with others to catalog where and how APIs are being used, but that work has only begun. In 2016, the task force worked within one encompassing goal: to “focus on read-only access to a single patient’s record for disclosure to an app selected by that patient, and used to access data elements defined in the Common Clinical Data Set.”  In June, the joint Health IT committee only narrowly approved the  API Task Force recommendations on the ONC mandate on patient access— by a 13-10 margin. Many on the committee expressed skepticism about unreliable apps and reliance on private sector, voluntary measures.

Large academic institutions such as Duke, are leaders in API development for internal applications and external data exchange as well as in implementing FHIR well ahead of the market. However, not every hospital or clinic (to put it mildly) has the resources of the large academic centers and will be relying on their EMR vendors.

Athenahealth has been a leading EMR vendor in developing and giving API access to its system to developers –  just recently focusing on FHIR and then, only to parts of the spec it thinks are workable.  SMART on FHIR is an open source framework that allows for interoperable health care applications using FHIR data. It is supported by many as a natural, incremental path forward. While it doesn’t represent the full power of either SMART or FHIR, it will help these technologies to gain a foothold in production use -to quickly bring value to the healthcare industry. You can see the current efforts in its Gallery.  SMART is run out of the Boston Children’s Hospital Computational Health Informatics Program and the Harvard Medical School Department of Biomedical Informatics.

The behemoth EHR vendors are beginning to talk a good game and offering API support. The day may come when they open their systems and offer true API ecosystem platforms. On another front, it remains to be seen if FHIR will dominate as the Open Standard API.

Concern about APIs being over-hyped as an all-purpose solution to interoperability problems is lately being heard from healthcare execs, patient advocates, start-ups and even from Graham Grieve, the FHIR product director and champion, in his blog post entitled #FHIR and the Gartner Hype Cycle.

Another Data Point: HIE Provider and Payer Users Still Playing Catch Up

A recent Black Book survey, which questioned over 2,000 provider HIE users and 2,300 payer HIE users, reported that “…83% or physician practices and 40% of hospitals say they are still in the planning and catch up stages of sending and sharing secure, relevant data. … 63% of hospitals and hospital systems report they are in the active stages of replacing their current HIE system, whether private, public, homegrown or EHR-dependent with a variety of options including middleware and more advanced HIE systems. “   According to the survey, a growing number of hospital systems and IT leaders frustrated with HIE poor connectivity and other issues are pursuing interoperability middleware.

Meet You in the Middleware

If you’re hoping to sell your devices or solutions to healthcare organizations, you immediately discover that meeting HL7 standards, specifically HL7 2.x, is a requirement.  And moreover, you are way behind the curve when you don’t have an integration strategy as part of your story and go-to-market plan. Also, any next gen product or innovation can’t scale without EHR integration.

Integrating with EHRs is something we deal with every day. PilotFish software is adept at accepting or extracting ANY information that is made accessible and has proven strategies for determining how to integrate with EHR systems. We employ these strategies to determine the best available means for getting data into or out of the EHRs. These include using:

  1. Standards-based messaging (e.g., HL7 over LLP, cCDA via Web Services, FHIR, EDI)
  2. Proprietary APIs (JSON or XML REST-style services or other)
  3. Proprietary extracts (custom delimited or fixed-width formats via FTP or other)
  4. Machine-readable reports (user-scheduled output that can be pulled and parsed)
  5. Direct database access (SQL or NoSQL using JDBC or other drivers)

The bottom line is, if the EMR vendor provides access to the data – we’ve got you covered and so should any other middleware vendor you put to the test. For providers of cloud services, software applications, equipment or devices, rapid implementation and integration of your solution has never been so critical to your success.

The New Sexy: The Integration Engine in Your Healthcare Integration Strategy

Interface engines and middleware aren’t new but you may have noticed their role has achieved new respect and recognition by innovative startups in digital health care as well as from existing solutions now under competitive pressure to integrate. They are here. They are now. And proven.  But don’t get us wrong. As an integration company, we are proponents of Open APIs in healthcare (see our API blog), and very early on, we offered HL7 FHIR support. However, we too are keenly aware that expectations for APIs for interoperability are outstripping realities. The maturity and the ubiquity simply aren’t there yet.

In your strategy – you want development, maintenance and enhancement of an integration capability off the critical path so you can focus on your core business and growing revenue.  A successful integration strategy for medical equipment and solution providers is built on the guiding principle that the customer should be required do as little as possible. Adapt to them and don’t count on the reverse.

 

Tags:
Monika Vainius

Written by: Monika Vainius

Executive Vice President of Applied PilotFish Healthcare Integration. Monika has extensive experience with systems interoperability. She combines this experience with her professional passion for healthcare and healthcare technology to comment on current healthcare and IT news. Website

This is a unique website which will require a more modern browser to work! Please upgrade today!