Migrating HIPPA messaging to HL7 FHIR
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
|1||Receive HIPPA X12_05010 270 Eligibility Request from Provider|
|2||Transform Request to FHIR
|4||In parallel Insert FHIR
The following figure shows the steps in the Logic App.
|1||User Subscribes to new
|2||User Gets the
|3||User validates Request and creates the
The following figure shows the steps for this Logic App
Setup and Configuration
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).
CoverageEligibilityRequest is composed of the Resources shown in the following figure,
The primary Resources are:
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
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
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.