Migrating HIPPA messaging to HL7 FHIR

Use Case

I was recently asked to provide guidance on installing and configuring a HL7 FHIR Server.
The client was tasked with doing a POC for a Payer Organization.
The client wanted to see if they send a HIPPA 270 Eligibility Request to the FHIR server and receive a Response.


The following is a diagram showing the message flow .


We used the Azure Interrogation Account with two Logic Apps, one for each workflow.
We decided to use BizTalk 2016 to create the maps. The reason behind this is that we were planning on duplicating the POC in BizTalk.

There are two separate workflows


Step Description
1 Receive HIPPA X12_05010 270 Eligibility Request from Provider
2 Transform Request to FHIR CoverageEligibilityRequest
3 Post FHIR CoverageEligibilityRequest to FHIR Server
4 In parallel Insert FHIR CoverageEligibilityRequest to Repository and Data Lake Store

The following figure shows the steps in the Logic App.


Step Description
1 User Subscribes to new CoverageEligibilityRequest
2 User Gets the CoverageEligibilityRequest from FHIR Server
3 User validates Request and creates the CoverageEligibilityResponse
4 User Posts CoverageEligibilityResponse to FHIR Server
5 User Sends CoverageEligibilityResponse to be transformed to HIPPA X12_05010 271 Response

The following figure shows the steps for this Logic App

Setup and Configuration

Before I started the client had already decided on which FHIR Server they would use.
The server is Smile CDR, which is based on the Hapi Server.

Smile CDR provides excellent documentation. I was able to setup a Docker Sandbox on an Azure Ubuntu Server VM in under ten minutes.

Smile CDR loads the image into Docker using a command like
docker image load --input="/path/to/smilecdr-2019.05.R01-image.tar.bz2"
To make it easier to setup another server, I published the Docker Image to an Azure Container Registry. I later use the image to create an Azure Docker Instance.

Loading Data into the FHIR Resources

One cannot just start sending messages to a FHIR Server, especially for the CoverageEligibilityRequest. The request included PatientID, two Organizations ID’s (Provider and Payer) and sometimes the CoverageID. These must exist in FHIR Resources, otherwise you will receive an error.

The HL7 FHIR API validates the existence of every ID in the Inbound Resource against all the FHIR Resources for that type (Organization).

The CoverageEligibilityRequest is composed of the Resources shown in the following figure,

The primary Resources are:

  • Patient
  • Insurer
  • Provider
  • Coverage

Each one of these are composed of other resources. Let’s look at each one in reverse


Coverage has dependencies on insurancePlan. The InsurancePlan must be create first. We created the Resource with the minimum required data. The Contract Resource is also required and that too has created with minimum data.

Both the Provider and Insurer belong to the Organization Resource.

We only needed to include the name to create an Organization Resource for both.


The Patient Resource can be either the Subscriber or Dependent. In the CoverageEligibilityRequest there is no distinction between them. We decided to include the minimum amount of data to create a valid Patient Resource

CoverageEligibilityResponse Resource

This resource includes most of the data from the CoverageEligibilityRequest. The Insurance information is required,

The CoverageEligibilityResponse is an Event Workflow.

It is in response to the CoverageEligibilityRequest. You can read more about this here

Eventually the workflow can be automated with Subscription. For now we will need human interaction. We decided to create a Web Application on Azure as shown in the Architecture Diagram above.

Last modified: February 10, 2020



Leave a Reply