Generating and Loading Synthetic Patient to FHIR Server using Azure Container Instances

Fast Healthcare Interoperable Resources (FHIR) is a new HL7 standard for exchanging information between healthcare systems. If you are a regular reader, you will have noticed that I have been working on setting up FHIR servers in Azure and loading data into FHIR servers. When testing FHIR servers and applications, it is important to be able to load synthetic patient data. The Synthea project has a great generator, which can be used to create large patient datasets with realistic but not real data. In this blog post, I will discuss how to orchestrate patient data generation and upload to a FHIR server, which uses Azure Active Directory (AAD) as an identity provider. Specifically, I will show how to create a Docker container that will generate the patient data, authentication with AAD, and upload the data to the FHIR server. You can run this Docker container locally on your own computer or deploy it as an Azure Container Instance (ACI). I have posted a GitHub repository with the code at https://github.com/hansenms/SyntheaGenerator.

The source code repository contains a Dockerfile, which installs Synthea and a .NET Core command line application. When running the container, a script will first call the Synthea tool to generate population of patients and it will then call the command line application to upload to a FHIR server.

 

 

The command line application requires some settings for AAD Authentication. They can be provided as environment variables:

[js]
{
"AzureAD_Authority": "https://login.microsoftonline.com/TENANT-ID/",
"AzureAD_ClientId": "ClientAppId",
"AzureAD_ClientSecret": "SECRET",
"AzureAD_Audience": "FHIR Server App ID"
}
[/js]

The application will use the client id and client secret to authenticate with Azure AD and try to obtain a JWT with audience (claim aud) corresponding to the FHIR server. At the moment, the command line application is effectively authenticating as the application with the provided client id and as such, it cannot be provided any specific scopes on behalf of a user/patient, but it would be assigned any application roles granted to the client application. The command line application could be modified to have a user sign in using the device login flow, but it would require a user to be present when initiating the application.

The Docker container needs the environment variables listed above and also FHIR_SERVER_URL and NUMBER_OF_PATIENTS. To run a pre-built version of the Docker image on a local computer, you can use a command like:

[shell]
docker run --name synthea --rm -t \
-e AzureAD_ClientSecret='AAD-CLIENT-SECRET' \
-e AzureAD_ClientId='AAD-CLIENT-ID' \
-e AzureAD_Authority='https://login.microsoftonline.com/TENANT-ID/' \
-e AzureAD_Audience='AAD-FHIR-API-APP-ID' -e NUMBER_OF_PATIENTS='100' \
-e FHIR_SERVER_URL='https://my-fhir-server/com/' hansenms/synthegenerator
[/shell]

You can also start the container in an Azure Container Instance:

[shell]
az container create --resource-group RgName \
--image hansenms/syntheagenerator --name ContainerInstanceName \
--cpu 2 --memory 4 --restart-policy Never \
-e AzureAD_ClientSecret='CLIENT-SECRET' \
AzureAD_ClientId='CLIENT-ID' \
AzureAD_Authority='https://login.microsoftonline.com/TENANT-ID/' \
AzureAD_Audience='FHIR-SERVER-API-APP' \
FHIR_SERVER_URL='https://my-fhir-server.com/' \
NUMBER_OF_PATIENTS='100'
[/shell]

In the GitHub repository, there is also a link to deploy the Azure Container Instance using a template and the portal. After starting the container, you should be able to monitor the progress of patient generation and uploading:

And that's it. You now have a fully automated way of generating and uploading synthetic patient data to a FHIR server using Azure Active Directory as an identity provider. Let me know if you have questions/comments/suggestions.