Before You Choose a FHIR Server

Every FHIR project has deal breakers. Requirements that rule out entire classes of servers.

Problem is, early decisions around server selection are often made before these requirements are fleshed out.

“What are your project deal breakers” is one of the key questions I ask in my book, and it’s a question you have to be able to answer in order to choose a FHIR server provider.

Here are a few I discuss in Chapter 3. You may have your own.

  1. Data Location
    Where are you allowed to store patient data? Can it reside in a managed cloud server in the US or Europe, or are you restricted to an on-prem server inside a hospital’s own IT systems? What’s allowed will differ country by country, and can often rule out managed cloud servers entirely. Talk to compliance and legal before you start the vetting process.
  2. Authorization
    Do you need Smart-on-FHIR v2? Don’t assume a brief mention of “Smart-on-FHIR” in the vendor’s documentation means you’re covered. Not all server providers support v2. Before settling on a server, ensure it does exactly what you and your users expect.
  3. Multi-tenancy
    If your project has a multi-tenant requirement, you need to do a lot of research before settling on a vendor. Most servers have no “out of the box” support for multi-tenancy. The vendor may have “suggestions”, which usually means implementing it yourself.
  4. FHIR Subscriptions
    Subscriptions are a key requirement for many use cases – especially apps and systems running inside hospitals. Yet not all servers support Subscriptions. Some vendors implement platform-wide features that work similar to Subscriptions, but what they don’t tell you is that using them requires custom work from ALL consumers. Can you sell that?
  5. Analytical queries
    Does your project have a requirement to run analytical queries against data stored in the FHIR server? If it does, you need to expand on those requirements before choosing a server, as there is no standard way of achieving this. Some vendors have processes to sync FHIR data with their own data warehouses (which you pay for). Others recommend using SQL on FHIR (which you have to integrate). These are sizeable projects, and that size will vary depending on the server.

The FHIR server decision is often made early in the project, when key requirements might not be known. By the time they appear, you’re left with switching server providers or redesigning your architecture.

I go into this in more detail in Chapter 3.

---

Download my “FHIR Architecture Decisions” book

Discover more from Darren Devitt

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

Continue reading