HL7 vs Smart On FHIR: Which is the better choice?

Healthcare organizations around the world depend on electronic health record (EHR) systems to manage patient data. These systems use different data exchange standards, such as HL7 and SMART on FHIR, to ease the process of exchanging data between systems. 

Both of these standards serve different purposes, and hence not in the field directly when it comes to being the better choice. This blog will explore and provide technical details about each standard.

hl7 vs SMART on FHIR

What is HL7 (Health Level Seven)?

Messaging standard, HL7, is used to transfer medical data across various platforms. It has been several years since Health Level Seven International created this standard, and it has evolved to accommodate the varying requirements of the healthcare sector.

There are two message formats covered under this head: 

  • The HL7 v2.x messaging format uses a message structure that includes segments delimited by pipes (“|”). Each segment contains one or more fields delimited by a caret (“^”). HL7 v2.x messages are exchanged over a network using the TCP/IP protocol.
  • The HL7 FHIR (Fast Healthcare Interoperability Resources) format is a newer standard that uses a RESTful web services architecture, thus, designed to be more flexible and easier to use than HL7 v2.x. FHIR resources are represented as JSON or XML documents, which can be accessed using standard HTTP methods (GET, POST, PUT, DELETE). 


HL7 v2.x is a legacy standard and a complex messaging format that requires significant expertise for use and even requires specialized software for handling. In contrast, HL7 FHIR is more user-friendly.

What is SMART (Substitutable Medical Applications and Reusable Technologies) on FHIR?

The SMART on FHIR standard offers a framework for creating secure and functioning apps linked with EHR systems. SMART Health IT is behind the development of the standard and based on the HL7 FHIR standard.

Authorization and authentication are done through OAuth 2.0. The apps must be registered with a SMART on FHIR authorization server to obtain an access token before accessing patient data.

The SMART on FHIR API includes several key components, including the Launch Sequence used to launch apps within an EHR system. The Launch Sequence involves several steps, such as obtaining an authorization code, exchanging the obtained code for an access token, and redirecting the user to the app.

What is the basic difference between the two systems?

The primary difference is the process involved. HL7 is a messaging standard, while SMART on FHIR is an API standard. An API defines how software sends and receives service requests, while a messaging standard configures the process of sending information from one system to another.
In short, HL7 aids the exchange of messages between systems, while SMART on FHIR helps develop and deploy apps that can access patient data from EHR systems.
HL7 offers a framework for the sharing, retrieval, integration, and interchange of electronic health data. SMART on FHIR is a platform that uses cutting-edge web technologies like HTML5 and JavaScript to give developers a standardized interface for creating and deploying software that can be used with electronic health record (EHR) systems. It enables programmers to create software that can run inside EHRs and communicate with patient data using FHIR (Fast Healthcare Interoperability Resources).

The technical difficulty in implementing the two processes

HL7 has evolved with time, thereby different versions are in use, making it challenging to ensure compatibility between various systems. Similarly, SMART on FHIR is a relatively new standard and is continually developing, and there may be compatibility problems between various versions.
So, it’s necessary for developers to stay current with any new innovations. Additionally, ensuring the security and privacy of patient data is a challenge when implementing SMART on FHIR because the built apps have access to sensitive patient data.

Sample Implementation

We will discuss similar instances with the two standards to show the implementation process.

HL7 using Express.js and React.js with functional components

  • Setting up the Express.js Server:

 We first imported the HL7 package and the express module, then created an Express.js app and an HL7 server. The server.on() method was used to listen for the message event, which was emitted whenever a new message is received. Next, we simply logged the message to the console, started the server, and listened for incoming connections on port 3000.

Setting up express.js server
  • Creating the React.js Client:

We developed a React.js functional component named App. To control the message and response’s state, we used the useState hook. When a user inputted text in the input field, the handleChange() function updated the message state. 

The handleSubmit() function was invoked when a user submitted a form. Inside this function, we created a TCP socket using the net. createConnection() method, and sent the message to the HL7 server using the client.write() method. 

We then listened for incoming data on the socket using the data event and updated the response state with the ACK message. Finally, we rendered the form and the response in the component.

creating react.js client
  • Sample response
The response from the HL7 server was a string containing the ACK message in HL7 format. Here is an example of an ACK message:
sample response
In the React.js component, we rendered the response as a pre-tag to preserve the formatting of the message.

SMART on FHIR using Express.js and React.js with functional components

  • Setting up Express.js Server
setting express.js server in functional component

In this case, we first imported the express, cors, and FHIR client modules. Then we created an Express.js app and used the Cross middleware to allow cross-origin requests. We then defined two routes: /launch and /redirect. 

The /launch route initiated the SMART on FHIR authorization flow. The redirect Uri, state, and client parameters were defined. Then, the authorize() function was called from the FHIRclient module to obtain an access token. We then redirected the user to the authorization server using the client.tokenResponse.url property. 

The /redirect route handled the callback from the authorization server. We sent an HTML file with JavaScript to extract the access token from the URL and pass it back to the React.js client. Finally, we started the server and listened for incoming connections on port 3000.

  • Creating the React.js Client:
creating react.js client in functional component

We started by creating a functional React.js component called App and imported the React, useState, useEffect, and fhirclient modules. We then defined a state variable called patientName using the useState hook. The useEffect hook defined an asynchronous function called launch, which initiated the SMART on FHIR authorization flow using the FHIR.oauth2.init() function from the fhirclient module. 

Once the access token was obtained we made a Patient request using the client.request() function and set the patientName state variable to the patient’s name. Finally, we returned some simple JSX that displayed a welcome message with the patient’s name, or a loading message if the patient’s name is not yet available.

We needed to install the express, cors, fhirclient, and React modules to run this app.

install express

To extract the access token from the URL and pass it back to the React.js client, we needed to create a public/redirect.html file with the following code :

redirect.html file

Once everything had been set up, we started the Express.js server, followed by the React.js client:

start express

Now, we were able to navigate to http://localhost:3000 in our web browser and saw a welcome message with the patient’s name.

So, which standard is a better choice when it comes to exchanging data from EHR systems?

Realizing the full potential of electronic health information systems requires enabling the seamless flow of healthcare data among apps and systems. HL7 has long been a well-liked alternative. However, because SMART on FHIR APIs are more streamlined, contemporary, and adaptable than HL7, all the major EHR systems, including Epic, Cerner, and Allscripts, have integrated it into their platforms. 


Predominantly, the individual use case and requirements of the relevant healthcare organization will determine whether to use HL7 or SMART on FHIR. Both are data standards and by implementing them together, we can get an answer to the interoperability conundrum.

Still unsure which would be the perfect choice for your app? Talk to our experts.
Related blogs and articles