Synthetic FHIR data

Every fully featured application has a unique FHIR data model.

Not 100% unique, but unique enough to make off-the-shelf synthetic FHIR data inadequate for testing.

Data that’s 80% there or 95% there is not good enough. Not for testing real world applications. For that you need 100% accurate test data. And the only team who can produce that is the team that owns the data.

Synthetic FHIR data might work for simple apps that use a popular Implementation Guide. But none of the apps and solutions I’ve worked on are simple.

They’re all big, messy and complicated. Real world.

  • Richer data
  • Resources and elements not covered by IGs
  • Extensions
  • Uncommon ValueSets

My approach to generating test data is always the same:

  • Create a Bundle template that matches the data model
  • Populate it with all the resource types required
  • Use PUT requests with Identifiers for static resources
  • Use POST requests for new resources
  • Replacement strings for GUID IDs
  • More replacement strings for element values
  • Write code to populate those replacement strings with diverse data
  • Loop 100 or 100,000 times

There’s always someone on the team who thinks there’s a more elegant way. They’ll try to adapt Synthea. They’ll find an open source project that promises the world and fails to deliver.

They might even get 95% of the way there after a few weeks of work.

But 95% is not good enough.

It always comes back to Bundle templates and custom code.

I would love to be proven wrong here. How do you generate FHIR test data for your application?

---

Ways to Work With Me

Discover more from Darren Devitt

Subscribe now to keep reading and get access to the full archive.

Continue reading