The pros and cons of using a managed FHIR server

The big players here are Azure, Google GCP and AWS. Their managed servers are quick and easy to get up and running, but there’s a cost.

‘Managed’ means they’re essentially black boxes. They expose FHIR APIs for you to use, but you can’t see or interact directly with the underlying database or with the code that runs the servers.

New releases get rolled out without you knowing. Sometimes fixing bugs, sometimes introducing bugs.

Here’s a not uncommon scenario with managed cloud services:

A university hospital runs an application that periodically consumes and then aggregates Observation data from a FHIR server in the cloud.

Everything works fine for six months, until one Wednesday evening their main page fails to load.

A spinning hourglass.

Calls are made to vendors, emails sent to escalate things. Researchers sit idle waiting for data.

Two days later the problem is fixed — completely out of the blue.

Eventually an explanation flows down the chain from the cloud provider to the vendor to the hospital.

A problem with a server update from their cloud provider. What was supposed to be a performance improvement release broke certain complex FHIR queries.

But rest assured you’re told. The problem only affected a handful of users. You were unlucky.

This is one of the costs of using managed cloud services.

Questions you should ask your cloud provider before signing up and committing to their FHIR servers:

– Do they notify you in advance of server patches and new releases?
– Can you test them before they’re rolled out?
– Can you roll back to a previous version if something isn’t working post release?
– Do you have a direct line to technical support 24/7? At Microsoft, at Google, at AWS?

You might not like the answers to these questions.

Discussion

---

Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.