How is web API different from traditional HL7 and FHIR?

  • Post category:Blog
How is web API different from traditional HL7 and FHIR?

RESTful API are the backbone of many webservices today. Having the tools to integrate an not-natively-RESTful interface engine with this common standard opens a lot of possibilities. There will be hurdles for implementing tools like these, especially since some of core RESTful requirements are lost, namely: statelessness, cacheability, and code on demand.

Representational State Transfer (REST) web services are a popular method of providing interoperability between systems. There are six constraints:

Uniform interface: Resources are uniquely identified in requests by URIs, and the communication is HTLM, XML, or JSON representation of content from the database. When the server returns the representation of the resource to the client, the client holds enough information to modify or delete the resource on the server (security permitting).

Stateless: The state for handling a request is contained within the request itself. This helps with modularity because each request will have all of the information needed by the server to complete the request without relying on information from the server-client session.

Cacheable: Server responses must define themselves as cacheable when appropriate so that clients can reuse information rather than make subsequent requests.

Client-Server: There needs to be a separation between client and server, bridged by the RESTful API. This allows the client and server to be developed independently as long as the API interface remains the same. User interface and user state stays on the client, and data storage stays on the server.

Layered System: Because of the stateless requirements, a client will not be able to tell whether communication is directly with the server or with an intermediate resource. Since a request itself contains all of the necessary information to complete that request, an intermediate resource (e.g. a load balancer) can pass along the request while obfuscating the server-side process from the client.

Web API 2

Whereas, HL7 v2 is a well-established standard that works well within institutions to connect enterprise applications. Its design is limiting to modern devices and apps that are trying to leverage available patient data. Privacy and security are also difficult to implement. The FHIR standard presents an API designed with a more lightweight method of data exchange. The standard, which is being employed as the data standard by choice by all major EHR vendors for their open APIs, will designate a guide for data semantics that will break down many of the prior barriers to API interoperability.

Smaller mobile applications are typically not able to handle v2 messages and its requirement to be on the network with a persistent connection. They may only need or utilize one or two HL7 segments. API data exchange using FHIR allows lightweight applications to only request the data elements, packaged in resources, that is needed for the product’s function. Because EHR APIs across the industry will utilize the same FHIR standard, smaller applications will only have to worry about defining their data structure correctly one time—as opposed to HL7 v2, which allows for optionality in the way the data is presented by each EHR.

Security is also easier with FHIR because it utilizes RESTful web services, which, along with SOAP web services, is available in Corepoint Integration Engine. Web services has readily defined security protocols (HTTPS) along with commonly used authentication techniques such as OAuth 2.0. Being able to leverage widely used security standards makes implementation much easier than was capable with v2 integration. The powerful combination of the FHIR API with web services means that the future of healthcare technology could resemble integration that is familiar outside of healthcare, such as in social media newsfeeds.

API is More Efficient & Secure

APIs define security rules and transmissions more clearly and easily, enabling better connectivity between EHRs and other platforms. This helps EHR platforms avoid siloing their data in closed infrastructures and encourages seamless data integration with third parties.

APIs are also far more efficient as they allow data consumers to request information “on-demand”, as opposed to the HL7 model of subscribing to a feed that shares all data, regardless of whether it is immediately needed or not. By pulling data only when needed, the amount of information sent back and forth is reduced and focused on the task at hand. This, in turn, helps systems implement a “principle of minimum access”, not taking on more PHI than is absolutely required. The API approach also lets the requester authenticate as a specific user, providing accountability and transparency as to which specific user-requested or accessed a given piece of PHI. All this means there will be improved patient confidentiality without impeding the free flow of important PHI.

What’s more, APIs support FHIR, SMART, and other rising medical health portals. This connects EHRs with emergent health-tech platforms and helps to future-proof existing EHR platforms so that they can integrate with all types of health portals moving forward.

Web Services/API Integration
The Adoption of APIs in The World of EHRs

APIs are seeing increased adoption across the healthcare industry, particularly among newer entrants like Amazon and Apple. And the adoption will continue to become more widespread with the new FHIR (Fast Healthcare Interoperability Resources) standards and CMS (The Centers for Medicare and Medicaid Services) including APIs in its path towards overhauling Meaningful Use.

In the last couple of years, there’s been an increasing push of larger EHR vendors such as athenahealth, Greenway, and Allscripts stepping back from attempting to offer every single service themselves. They’re emulating retail commerce models like Target, who don’t attempt to re-invent the coffee shop within their stores, but rather partner with Starbucks, who are the experts in coffee.

Similarly, these EHR vendors recognize that they reign supreme on the clinical side of data management, but invite smaller specialty partners like Surgimate to provide high-quality add-ons in their own sphere of excellence. By building their own proprietary API into their platforms, these EHR companies are creating healthcare app marketplaces that present the best of breed surgical and medical apps across the board. And best of all, this API data sharing ensures seamless interoperability.

APIs Will Also Benefit the Patient

Smooth, free data sharing won’t only help the healthcare organizations operate more efficiently, they will also directly benefit the patient. Value-based patient care is all the rage these days, but so far lack of data interoperability has served as a huge obstacle. The rise of APIs presents a way around this problem, as it helps HCOs share data seamlessly and securely with each other and external partners – including the patient.

As EHR vendors increasingly build APIs into their platforms, and more healthcare app marketplaces are formed, surgical practices and other HCOs will be empowered to utilize expert third-party applications, without compromising interoperability. This, in turn, will lead the healthcare industry towards improved data-driven care throughout the patient journey.

How can Santeware Help !

Santeware has multiple years of experience in interconnecting and extracting data with the help of APIs of different EMRs on the industry. Please contact us to know more and if you have a project in hand which requires API assistance.

Leave a Reply