In a few weeks I’ll be giving a FHIR search tutorial at DevDays in Amsterdam.
A key requirement for tutorials, demos and presentations is reliable and fixed data. FHIR is no exception. The last thing you want on the day you’re presenting is to encounter changed or missing data that causes queries to fail or to deliver unexpected results.
With that in mind I spent a few hours preparing the data and the server. The steps are easy to emulate if you have some technical ability.
Step 1. Spin up a new FHIR server on Microsoft Azure
You can use another server provider. I chose Azure because it allows me to demo the Oauth bearer token flow as well as the search queries and because it uses a pay-as-you-go pricing model which means it will not cost much. Try not to use a public server such as HAPI or Firely for this, as their data can change at any time.
Step 2. Download some solid test data
For a good demo or tutorial you need rich and interconnected data. I used the Synthea patient bundles from 2019. There’s a download link on this page: https://darrendevitt.com/fhir-patient-test-data/
There are 1,000 patient bundles in the zip file. I extracted 50 bundles of moderate size (500kb). I chose to exclude larger bundles because I know Azure’s FHIR servers have a built-in limitation on bundle size.
Step 3. Modify the resources in the bundles
While the Synthea data is great, it has a few limitations that would have made the tutorial more difficult. I wrote a script to parse each of the 50 JSON files and modify all the dates so that they reflected recent years instead of pre-2019 years.
I also modified all human names to remove the numerics that Synthea add to them. “Florentina759 Hahn524” became “Florentina Hahn.” This affected all patient and practitioner names. It’s a minor detail but it makes for better demos.
Step 4: Create a Postman collection to populate the server
The collection included 50 POST requests to the Azure FHIR server — one for each Patient bundle. It handled the OAuth bearer token flow by way of a pre-processing script, and took about 20 minutes to set up. Add on a further 5 minutes to run the collection into the FHIR server.
One of the advantages of setting up a Postman collection like this is I can easily re-run the same data into any FHIR server. This is great for demos where you may want to “reset” the data each time to ensure it’s the same.
Step 5: Create a delete collection in Postman
Following on from the previous step, my delete collection runs a series of hard deletes for all resource types added to the FHIR server. This means I can wipe the server clean and re-run Step 4 at any time.
All told, this took me 2-3 hours. The bundle modification step took about an hour and a half, but I feel it was worth the time as the data is stronger and more visual after the changes.
I’ll make the scripts available for download after the tutorial in June.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.