Build Status
Coverage Status
Maven Central
Apache 2.0 Licensed

This is the homepage for the HAPI-FHIR library. We are developing an open-source implementation of the FHIR specification in Java. FHIR (Fast Healthcare Interoperability Resources) is a specification for exchanging healthcare data in a modern and developer friendly way.

Note that this is the home for the FHIR version of HAPI. If you are looking for HL7 v2 support, click here.

Demonstration/Test Page

A public test server is now operating at This server is built entirely using components of HAPI-FHIR and demonstrates all of its capabilities. This server is also entirely open source. You can host your own copy by following instructions on our JPA Server documentation.

Commercial Support

Commercial support for HAPI FHIR is available through Smile CDR.


Jan 13, 2018 - HAPI FHIR 3.2.0 Released - The next release of HAPI has now been uploaded to the Maven repos and GitHub's releases section.

This is a fairly light release, with only a small number of new features, and a few bugfixes. See the changelog for a full list of changes.

  • Support for using SearchParameter resources to define custom parameters in the JPA server has been backported to DSTU2, meaning that DSTU2 servers can now user this functionality (previously only DSTU3/R4 supported this)
  • Several tweaks and enhancements to the server interceptor framework have been added
  • Multitenancy support has been added to the server framework (note that this is only the plain server framework at this point, not the JPA server)
  • The R4 structures have been synced to the latest definitions in anticipation of the January FHIR Connecathon (see Downloads for version details)
  • Several bugfixes have been made

Thanks to everyone who contributed to this release!

- James Agnew

November 23, 2017 - HAPI FHIR 3.1.0 Released - The next release of HAPI has now been uploaded to the Maven repos and GitHub's releases section.

This release brings several interesting things:

  • Support for Android has been restored, and improved while we're at it! The use of a special "uberjar" with its own classifier is no longer required, hapi-fhir-android works as a normal Gradle dependency in your Android build. See the HAPI FHIR Android Integration Test for an example.
  • Support for the Cache-Control header has been added for JPA server searches, allowing a client to request that cached results not be used.
  • A number of bugs were fixed and performance improvements were made (see the changelog for a full list)
  • Spring has been upgraded to the 5.0 series.
  • Some initial refactoring has occurred towards enabling ElasticSearch support in JPA server. Note that any existing JPA projects will need to add an additional property in their Spring config called See this line in the example project.
  • Support for Spring Boot has been added to many of the modules of the libaray. See the Spring Boot Samples for examples of how to use this.

Thanks to everyone who contributed to this release!

- James Agnew

Sep 27, 2017 - HAPI FHIR 3.0.0 Released - The next release of HAPI has now been uploaded to the Maven repos and GitHub's releases section.

This is a massive release, and includes a huge number of enhancements, fixes, and new features. Unfotunately it also brings a few breaking API changes so we are calling it version 3.0.0 (we are also moving to SemVer versioning).

As always, the changelog has the full list of changes in this release. I am outlining a few of the important ones here:

FHIR R4 and DSTU1 Support

Support for FHIR R4 (current working draft) has been added (in a new module called hapi-fhir-structures-r4) and support for FHIR DSTU1 (hapi-fhir-structures-dstu) has been removed. Removing support for the legacy DSTU1 FHIR version was a difficult decision, but it allows us the opportunitity to clean up the codebase quite a bit, and remove some confusing legacy parts of the API (such as the legacy Atom Bundle class).

A new redesigned table of HAPI FHIR versions to FHIR version support has been added to the Download Page

Module Restructuring

HAPI FHIR's modules have been restructured for more consistency and less coupling between unrelated parts of the API.

A new complete list of HAPI FHIR modules has been added to the Download Page. Key changes include:

  • HAPI FHIR's client codebase has been moved out of hapi-fhir-base and in to a new module called hapi-fhir-client. Client users now need to explicitly add this JAR to their project (and non-client users now no longer need to depend on it)
  • HAPI FHIR's server codebase has been moved out of hapi-fhir-base and in to a new module called hapi-fhir-server. Server users now need to explicitly add this JAR to their project (and non-server users now no longer need to depend on it)
  • As a result of the client and server changes above, we no longer need to produce a special Android JAR which contains the client, server (which added space but was not used) and structures. There is now a normal module called hapi-fhir-android which is added to your Android Gradle file along with whatever structures JARs you wish to add. See the Android Integration Test to see a sample project using HAPI FHIR 3.0.0. Note that this has been reported to work by some people but others are having issues with it! In order to avoid delaying this release any further we are releasing now despite these issues. If you are an Android guru and want to help iron things out please get in touch. If not, it might be a good idea to stay on HAPI FHIR 2.5 until the next point release of the 3.x series.
  • A new JAR containing FHIR utilities called hapi-fhir-utilities has been added. This JAR reflects the ongoing harmonization between HAPI FHIR and the FHIR RI codebases and is generally required in order to use HAPI at this point (if you are using a dependency manager such as Maven or Gradle it will be brought in to your project automatically as a dependency)

Package Changes

In order to allow the reoganizations and decoupling above to happen, a number of important classes and interfaces have been moved to new packages. A sample list of these changes is listed below. When upgrading to 3.0.0 your project may well show a number of compile errors related to missing classes. In most cases this can be resolved by simply removing the HAPI imports from your classes and asking your IDE to "Organize Imports" once again. This is an annoying change we do realize, but it is neccesary in order to allow the project to continue to grow.

  • IGenericClient moved from package to package
  • IRestfulClient moved from package to package
  • AddProfileTagEnum moved from package to package ca.uhn.fhir.context.api
  • IVersionSpecificBundleFactory moved from package to package ca.uhn.fhir.context.api
  • BundleInclusionRule moved from package to package ca.uhn.fhir.context.api
  • RestSearchParameterTypeEnum moved from package to package
  • EncodingEnum moved from package to package
  • Constants moved from package to package
  • IClientInterceptor moved from package to package
  • ITestingUiClientFactory moved from package ca.uhn.fhir.util to package

Fluent Client Search Change

Because the Atom-based DSTU1 Bundle class has been removed from the library, users of the HAPI FHIR client must now always include a Bundle return type in search calls. For example, the following call would have worked previously:

					Bundle bundle =
					.where(new TokenClientParam("gender").exactly().code("unknown"))
This now needs an explicit returnBundle statement, as follows:
					Bundle bundle =
					.where(new TokenClientParam("gender").exactly().code("unknown"))

Thanks to everyone who contributed to this release, either by submitting pull requests, suggesting new features, or filing bug requests!

- James Agnew

What is HAPI FHIR?

HAPI FHIR is a simple-but-powerful library for adding FHIR messaging to your application. It is pure Java (1.6+ compatible), and licensed under the business-friendly Apache Software License, version 2.0.

Some Ways You Can Use HAPI FHIR

HAPI is designed with one main intent: providing a flexible way of adding FHIR capability to applications. We at University Health Network developed HAPI-FHIR to allow us to build up our own unified FHIR RESTful server which exposes data backed by a number of systems and repositories, so it is designed to be flexible above all else.

The library is designed to support several main usage patterns:

Fluent Interface

The HAPI API is designed to allow interaction with FHIR model objects using a convenient Fluent Interface.

Patient patient = new Patient();



Encoding Support

Both XML and JSON encoding are suported natively using a simple API to pick between them. XML support is built on top of the lightning-fast STaX/JSR 173 API, and JSON support is provided using Google Gson.

FhirContext ctx = FhirContext.forDstu2();
String xmlEncoded = ctx.newXmlParser().encodeResourceToString(patient);
String jsonEncoded = ctx.newJsonParser().encodeResourceToString(patient);

Easy RESTful Client and Servers

Creating clients is simple and uses an annotation based format that will be familiar to users of JAX-WS.

public interface MyClientInterface extends IRestfulClient
  /** A FHIR search */
  public List<Patient> findPatientsByIdentifier(@RequiredParam(name="identifier") IdentifierDt theIdentifier);

  /** A FHIR create */
  public MethodOutcome createPatient(@ResourceParam Patient thePatient);

Using this client is as simple as:

MyClientInterface client = ctx.newRestfulClient(MyClientInterface.class, "http://foo/fhir");
IdentifierDt searchParam = new IdentifierDt("urn:someidentifiers", "7000135");
List<Patient> clients = client.findPatientsByIdentifier(searchParam);

Back to top

Reflow Maven skin by Andrius Velykis.