One of the most useful strategies I’ve adopted lately to work with FHIR is to use Docker to test FHIR. Whether I’m testing that resources conform to an implementation guide, or I’m confirming that resources are valid against the FHIR spec using $validate, or I’m testing a digital quality measure using $evaluate-measure, running a FHIR server in a Docker container has a lot of value; especially with a feature-rich open-source FHIR implementation such as HAPI.
In fact, I felt so strong in this that I ended up setting up HAPI’s Docker Hub build environment to automatically build the Docker image and make it available via the hub.
Getting started
It’s easy to get started… All you really need to do to run a simple FHIR server is:
docker run -p 8080:8080 -n hapi hapifhir/hapi:latest
This does not persist any of the data to a database. This persists the data only in the files sitting in the container. As soon as the container is destroyed and re-created, the resources in the FHIR server are lost. You could change this by mounting the H2 database folder as a volume in Docker, but I haven’t had much need to do that, yet.
Also note that if you’re using Docker for Windows, the container may not automatically start back up when your computer restarts. It helps to name the container using -n hapi so that after restarting you may execute a command such as:
docker start hapi
Configuration
A bunch of extra configuration options is available that makes the HAPI container more valuable:
-e "hapi.fhir.allowed_bundle_types=collection,searchset,transaction,message"
By default, HAPI does not support storing a Bundle resource. This allows you to store Bundle resources of the specified types.
-e "hapi.fhir.client_id_strategy=ANY"
By default, HAPI requires that logical ids for resources start with a letter. This setting allows you to specify whatever format of the logical id you wish.
-e "hapi.fhir.tester.home.server_address=http://localhost:8012/fhir"
If you wish to change the port using, for example -p 8012:8012, and want to continue to have the UI that comes prepackaged with HAPI, you must tell HAPI what URL the FHIR API is exposed at so that the UI knows where/how to communicate with it.
-e "JAVA_OPTS=-Xms6G -Xmx6G"
Standard Java options to provide more memory to HAPI to work with larger and more complex resources.
-e "hapi.fhir.cors.allowed_origin=*"-e "hapi.fhir.cors.allow_Credentials=false"
Important if you want to allow your HAPI container to be accessed by web applications. This probably isn’t common… But, in my case, I created a web application to assist the process for testing digital quality measures, and the browser wouldn’t be able to communicate with my local Docker container for HAPI without these options.
-e "hapi.fhir.cql_enabled=true"
Set this option to add support for Measure/$evaluate-measure functionality.