Skip to Main Content

Using HL7 FHIR for clinical information exchange and integration with Red Hat Fuse (Apache Camel)

In this article, we will explain what HL7 is, as well as what HL7 FHIR is for clinical information exchange and integration with Red Hat Fuse and Apache Camel.

We will include the following information:

  1. ¿What is HL7?
  2. ¿What is HL7 FHIR?
    1. Evolution of FHIR
    2. Advantages of HL7 FHIR
  3. FHIR Use cases
  4. FHIR data model
  5. FHIR exchange API 
  6. Red Hat Fuse and the Apache Camel FHIR component
    1. HAPI FHIR library
    2. Camel FHIR
    3. Example of implementation using Camel FHIR

1. What is HL7?

Health Level Seven International (HL7) is a non-profit organization founded in 1987 with the goal of developing a comprehensive framework of standards for the exchange, integration, sharing, and retrieval of clinical information in an electronic format for use in clinical practice and in the management, delivery, and evaluation of healthcare services. The organization has more than 1,600 members in over 50 countries, representing healthcare providers, governments, insurers, pharmaceutical companies, manufacturers, and consulting agencies.

It aims to ease the interoperability of clinical data at a global level.

2. What is HL7 FHIR?

HL7 Fast Healthcare Interoperability Resources (FHIR) is an interoperability standard which facilitates the exchange of clinical information between healthcare providers, patients, caregivers, insurers, researchers, and any other party involved in the healthcare ecosystem.

FHIR defines two aspects:

  • A health resource data model
  • An API for information exchange

2.1 Evolution of FHIR

FHIR is the evolution of several standards that have been produced by the HL7 organization over the decades, building on earlier versions such as HL7 2.x version and HL7 3.x version. Different proposals have been released since 2011, with Release 4 being the latest stable version.

  • October 2019: FHIR R4, First normative version
  • March 2017: FHIR R3, Standards for Trial Use (STU)
  • October 2015: FHIR R2 DSTU, Draft Standard for Trial Use (DSTU) (draft)
  • February 2014: FHIR R1 DSTU, Draft Standard for Trial Use (DSTU) (draft)
  • August 2011: Resources for Healthcare (RFH) (initial draft)

2.2 Advantages of HL7 FHIR

The main advantages of using FHIR are as follows:

  • It facilitates interoperability between heterogeneous systems, from legacy systems to multiple types of devices such as computers, tablets, smartphones, medical devices, etc., as well as between different applications, and facilitates the integration of new medical applications with existing systems.
  • It offers an alternative to document-based systems, allowing a greater degree of detail by being able to expose elements such as services. For example, basic elements such as patients, admissions, analyses, diagnoses, medications, can be consulted and manipulated individually through their own URL.
  • The standardization and granularity of the data model makes it possible to speed up its automatic processing, avoiding the transformation or preprocessing techniques.
  • It integrates easily with current applications as its API is based on REST technologies.
  • Open-source implementations are available for different languages such as Java, .NET, Ruby, Python, Delphi, Swift, PHP, etc.

3. HL7 FHIR use cases

The exchange of clinical information between different parties can lead to use cases such as:

  • Medication Interaction Alert: The system can alert professionals to medications that may interact with each other in a negative way if they are prescribed to the patient at the same time.
  • Reduction of waiting times: The data analysis of emergency assistance and hospital admissions can facilitate a better estimation and optimization of resources to reduce waiting times.
  • Epidemiological monitoring: Hospitals can publish their patients’ infection statistics so that they can be used by researchers and public health agencies.
  • Telemedicine: Transmission of measuring devices (blood pressure monitors, thermometers, glucometers, spirometers, etc.) from the patient’s home to the health service for monitoring and analysis.

4. HL7 FHIR data model

The key data in FHIR is the so-called resource. Some examples of resources can be admission, patient, history, medication, rehabilitation plan, discharge, etc.

We can define a resource as an entity that:

  • It has a unique identity (URL location) assigned on the server.
  • It belongs to a resource type among those defined by the FHIR specification.
  • It contains a set of structured data, depending on the type of resource.
  • It has a version that changes if the content of the resource is modified.

Each resource is composed of a data structure that can be primitive or complex in nature, or references to other resources.

Data structure HL7 FHIR

Source: FHIR v4.0.1 Datatypes Definitions

In the following diagram, we see the example of a patient resource, which is composed of an identifier, date of birth, marital status, contact persons, doctor, etc.

HL7 FHIR v4.0.1 Patient

Source: FHIR v4.0.1 Patient

The following example is a diagnostic report resource, which includes its identifier, status, category, referring patient, date, physician, remarks, conclusion, attachments, etc.

HL7 FHIR v4.0.1 Diagnostic Report

Source: FHIR v4.0.1 DiagnosticReport

The model is not limited to defining data types but goes beyond that. It also defines the extensibility of the resources, and how to extend them for additional data that we need and that were not initially foreseen. There are also other broader definitions in the data model. For example, we can group multiple resources into a clustedr called a bundle. Alternatively, we can create a profile that defines a use case and covers both the resource types required for that use case and the relationships between its resources.

5. FHIR exchange API

The API is based on current web technologies such as HTTP and the RESTful protocol, and can use XML, JSON or RDF formats for data representation. Generally speaking, a URI would have the format:

VERB [base]/[type]/[id] {?_format=[mime-type]}

where the server address, the type of resource, and its identifier are distinguished.

The main interactions with the FHIR API will use the usual HTTP methods:

  • POST Resource creation
  • PUT Resource modification
  • PATCH: Partial modification of a resource
  • GET Resource lecture
  • DELETE Resource elimination

The following diagram shows an example of a request to the server:

http request

And the server response:

Server response

6. Red Hat Fuse and the Apache Camel FHIR component

In real world, there are a multitude of medical applications and devices that do not use the FHIR standard. The origins or destinations of existing application data can be diverse:

  • Measuring devices.
  • Data in relational databases.
  • Web services in proprietary format.
  • File-based batch processing systems.
  • Apis rest (not compatible with FHIR)
  • Message queues.
  • SaaS applications in the cloud.

If we want to communicate with a FHIR server using the same infrastructure and existing applications, we have to adapt the data and the communication protocol in order for this to be compatible with the specification. One option is to use an integration tool such as Red Hat Fuse (Apache Camel), which automates this process.

Red Hat Fuse (Apache Camel) Automatización proceso HL7 FHIR

Red Hat Fuse is Red Hat’s agile integration solution. It is based on a stable set of widely used Open Source projects, but with the backing and support of a company like Red Hat. Based on Apache Camel to perform micro integrations and the possibility of deploying it on-premise or in a cloud environment through Red Hat OpenShift.

6.1 HAPI FHIR Library

There are several commercial applications in the clinical field that support FHIR natively, but if we need a custom solution that adapts to our applications, we can use a specialized library. HAPI FHIR is a Java Client and Server library that implements the HL7 FHIR specification, It’s open-source and available under the Apache Software License 2.0.

HAPI FHIR defines a class model for each resource and data type defined in the FHIR specification, which in turn can be encoded in XML or JSON, for exchange through REST APIs. The source code can be obtained from

The modules into which this library is divided are:

  • Core: Framework core library
  • Structures: Data models
  • Client Framework: HTTP client, including an Android version.
  • Server: FHIR specification compliant server
  • Validation: Validation of resources against FHIR Profiles

We can see a simple example of the Structures module, in which we can see how a new patient would be created with an identifier, gender, name, and surname:

Patient patient = new Patient();






6.2 Camel FHIR

The Camel FHIR component encloses the HAPI FHIR client and server libraries, discussed above, in the Apache Camel framework, supporting both its data model and communication protocol. The relevant documentation is available at:

To begin using it we only have to add its dependency to our Apache Camel project:


Within our projects we will be able to use both the data model through the HAPI FHIR library and manage communications between clients and FHIR servers.

The FHIR component is configured using the following syntax as the endpoint when we proceed to transmit the data:

fhir://endpoint-prefix/endpoint? [options]

Where endpoint-prefix corresponds to one of the possible operations:

  • capabilities: Query full server functionality, i.e., supported operations and resources
  • create: Creates a new resource on the server
  • delete: Deletes a new resource on the server
  • history: Consult versions and changes in a resource
  • load-page: Uploads a previous/next resource bundle on a paged set basis
  • meta: Adds, modifies, or deletes metadata of a resource
  • operation: Allows to extend the API with new operations
  • patch: Modifies a resource on the server
  • read: Reads a new resource on the server
  • search: Search for resources matching the search criteria
  • transaction: Sends a collection of resources as a unit
  • update: Updates a resource on the server
  • validate: Validates whether a resource conforms to the specification

In addition to indicating the operation, there are multiple parameters that vary depending on the operation to be performed, and that will allow us to adjust certain aspects of the operation.

6.3 Example of implementation using Camel FHIR

Let’s suppose that we have a file in CSV format containing a list of clinical records. We need to read those records and send them to a FHIR server. In order to do so, we will follow the following steps:

  1. Upload file
  2. Read content in CSV format
  3. Convert to FHIR Bundle format
  4. Send the bundle to the server

Since we are loading multiple records at once, we can use the transaction operation, which allows us to send a bundle or collection of records.

BindyCsvDataFormat bindy = new BindyCsvDataFormat(Record.class);

public void configure() throws Exception {
  from("file://{{}}?noop=true").filter(simple("${file:name.ext} == 'csv'")).id("readingCsvFiles")
      .log("Converting ${in.headers.CamelFileName}").unmarshal(bindy).log("body ${body}").process(new BundleProcessor())
      .log("Sending HL7 FHIR Bundle")
      .to("fhir://transaction/withBundle?inBody=bundle&serverUrl={{fhirUrl}}&fhirVersion={{fhirVersion}}&validationMode=NEVER").log("CSV imported")

Therefore, we can see an example of the use of FHIR with Red Hat Fuse and Apache Camel, indicated by the protocol fhir://. Using this prefix, the data is automatically sent through the FHIR component, which manages the communication and the sending of the bundle to the server defined by the serverUrl parameter, together with the reception of the response.

Project source code:

Talk to our experts!

Contact our team and discover the cutting-edge technologies that will empower your business.

contact us