What Is HAPI FHIR Server? How Do We Deploy It?

HAPI FHIR Server

HAPI-FHIR is a Java software library, facilitating a built-in mechanism for adding FHIR's RESTful Server functionalities to a software application. The HAPI FHIR Java library is open source. The HAPI RESTful (Representation State Transfer) Server is based on a Servlet, so it should be deployed with ease to any compliant containers that can be provided. Simple annotations could be used to set up the server on the large part. Conclusively, it should be possible to create an FHIR compliant server in a short time span.

The first step in the creation of an FHIR RESTful Server is the determination of one or more resource providers. A “resource provider” is a Java programming class that is capable of supplying exactly one type of resource to which the service can be provided. For instance, if you need to enable your server to deal with resources like Patient, Observation, Medicines, Location, blood group, it will require you to use five resource providers.

The resource provider class should utilize the IResourceProvider  interface. There should be one or more methods regarding it. It also should be annotated with particular annotations, pinpointing a RESTful operation that a particular method supports.

You can add a large number of methods to your resource provider. The next step is creating the server to keep the resource providers and deploy them.

After the resource providers are created, the next step is to declare a server class. HAPI provides a built-in class called RestfulServer that is a dedicated Java Servlet. Server creation requires you to simply create a class that extends the RestfulServer.

The resource provider definition should not exceed more than one per resource. It is a great strategy to keep code readable and easily-maintained. It will also enable the insertion methods for multiple resource types in a provider class.

If the method directly returns a resource or multiple resources, the type of resource has to be deduced automatically. When the method returns a Bundled resource, it becomes vital to clearly indicate the resource type in the annotated method. Please take a look at the following example:

Example

As an instance, data will be returned by the server in multiple places that will include the complete "identity" of a resource. “Identity” in this situation means the web address that a user can utilize to gain access to the resource.

For example, if your server is hosted at the URL (web address) http://xyz.com/fhir and your resource provider returns a Patient resource with the ID "01234," the server should translate that ID to "http://xyz.com/fhir/Patient/01234."

The server will attempt to find out what the base web address has to be, based on the request that it gets and the way it looks, but if the expected address is not being achieved, you may wish to use a different "address strategy."

The easiest way to perform this is to configure the server with the base URL that is hardcoded, which implies that the server would not try to determine the "http://xyz.com/fhir" part of the URL, but it will, instead, attempt to use a fixed value that the programmer will provide.

Method of Deploying the FHIR Server

Once the creation of resource providers and the RESTful server class are done, they can be arranged in a WAR file. After that, it will be deployed to any JEE container (WebSphere, Glassfish, Tomcat, etc.). Servlet has to be bundled into a WAR file.

The HAPI FHIR RESTful Server is able to export a capability statement on its own (or a conformance statement), according to the requirements of the FHIR Specifications.

The statement will be automatically generated, and it will be based on the various annotated methods that were provided to the server. The server processing can be changed by creating a new class, containing a method annotated with a  @Metadata Operation. After that passing, an instance of the class to the  setServerConformanceProvider  method on the server will do the job.