Introduction to HAPI FHIR: What is it, What does it do?

Written by:

Before we delve into HAPI FHIR, let’s first give an introduction to the FHIR standard. FHIR is an acronym that stands for Fast Healthcare Interoperability Resources. Let’s break that down.

  • Fast: The standard is designed to be quick to implement and easy use. It supports efficient, low friction healthcare data exchange and utilizes modern, widely used web based technologies like XML and JSON.
  • Healthcare: This standard is focused on the exchange of healthcare related data. This encompasses clinical decision making support, consumer facing health applications, and payer based use cases.
  • Interoperability: This is a key part of the standard. Interoperability means that computer systems will be able to exchange data regardless of the internal workings of their software. It doesn’t matter if underlying software runs on .NET micro services and a NoSQL database, a Java monolith and a SQL database, or a full blown EMR system. If all of these systems use the FHIR standard, they can all talk to each other.
  • Resources: Resources are the rudimentary logical structures upon which all things in FHIR are built. An example of this would be the Patient Resource. This is the basic blueprint for how to define a patient. This resource uses data types and code systems to explicitly define each part of a Patient. For instance, a Patient Resource contains a name field that is then defined by a type called HumanName. Within that HumanName type various fields like family, given, prefix, etc. are defined to make up a Patient’s name. It is the combination of these well defined resources that make up the FHIR standard.

HAPI FHIR is the Java implementation of the FHIR standard. This means that the standard is written out in Java code and is ready to be built and deployed onto a server for actual use to exchange healthcare information with other FHIR implemented systems.

Here are a few of the main parts of this project:

Modules

In the Github repository, the code is logically split out into different modules, each module being a directory in the root of the project. The project is designed this way so that you can import only what modules you need when building your own project. The only module that is mandatory is hapi-fhir-base, which contains all of the core functionality. This means that if you are working with a specific version of FHIR, for example R4, you only need to import the base module and the R4 module that defines the R4 models. No other versions need to be imported.

Client

The hapi-fhir-client module contains the implementation for the ability to act as the client in a client-server FHIR transaction. This means that you get to make requests of other FHIR servers. For example, if you are a healthcare app interested in retrieving a Patient from a hospital provider, you are acting as a client in this transaction and therefore would need to import the hapi-fhir-client into your project. In HAPI FHIR there are two types of clients, Generic and Annotation. Here is an example of the Generic client from the HAPI FHIR documentation:

Bundle results = client.search().forResource(Patient.class) .where(Patient.FAMILY.matches().value("duck")) .returnBundle(Bundle.class).execute();

Server

The ability to act as a server in a client-server FHIR transaction is split into two main modules, hapi-fhir-server and hapi-fhir-jpaserver-base. Acting as a server means you are going to take the requests of other servers against the data contained in your application. The difference between the two modules above is that hapi-fhir-jpaserver-base implements interactions against a database and hapi-fhir-server does not implement database logic. You would choose hapi-fhir-server if you already have a persistence layer you want to integrate with. You would choose hapi-fhir-jpaserver-base if you want HAPI FHIR to create a database for you on instantiation. Both of these modules will expose all of the FHIR resources as CRUD (Search, Create, Read, Update, Delete) endpoints needed for other systems FHIR clients to interact with your data.

Interceptors

Interceptors are built into the base of HAPI FHIR. They allow users of the project to hook into some point of the processing in both acting as the client and the server. In the HAPI FHIR Interceptor documentation, they use the example of wanting to log requests as a demonstration of when to use an interceptor. This interceptor inserts itself into the processing of incoming requests and logs them:

@Interceptor public class SimpleServerLoggingInterceptor { private final Logger ourLog = LoggerFactory.getLogger(SimpleServerLoggingInterceptor.class); @Hook(Pointcut.SERVER_INCOMING_REQUEST_PRE_HANDLED) public void logRequests(RequestDetails theRequest) { ourLog.info("Request of type {} with request ID: {}", theRequest.getOperation(), theRequest.getRequestId()); } }

Interceptors are a powerful tool to use when you want to “do something” with an incoming or outgoing request. Interceptors are similar to an AWS Lambda function in that they do not necessarily extend functionality of something that already exists, but inserts code into the processing of the data.

Validation

Part of the power of FHIR is that it defines a set of resources for exchanging information in an orderly and defined way. In order for that to work, we need to make sure to only exchange valid data that conforms to these FHIR resources. That’s where validation comes in. HAPI FHIR has that covered with a robust set of modules for validating resources from every version of FHIR to make sure you are only storing and exchanging resources according to the version of FHIR or FHIR profile you want to use. There are two main ways to validate in HAPI FHIR. Parser validation in which the raw FHIR text is validated as it’s being parsed into a FHIR resource object, and Instance validation in which a FHIR resource object is checked against a FHIR version or specific FHIR profile.

This was a brief overview of the FHIR standard and the HAPI FHIR project. In later posts I will go into more detail on some of these topics as well as give tutorials. If you have any questions, comments, suggestions or concerns, let me know!

One response to “Introduction to HAPI FHIR: What is it, What does it do?”

  1. AWS HealthLake: A FHIR Healthcare Cloud Solution Walkthrough + Pros and Cons – Chino Technologies

    […] How HealthLake works under the hood is quite opaque. For technical people this might be off putting. For some non-technical people this may actually be a plus. This means there is no ability to add business logic as well like you could with some open source implementations like HAPI FHIR. […]

Leave a Reply

Discover more from Chino Technologies

Subscribe now to keep reading and get access to the full archive.

Continue reading