I work with a lot of organizations using FHIR for the first time. It always starts with me challenging and correcting what they think they understand about FHIR and about FHIR servers. Many of their misunderstandings trace back to discussions they had with server vendors. They were not lied to, but they were never told the whole truth either.
The questions below pop up again and again on calls between organizations looking at FHIR and server vendors. The answers are often narrower than they should be. These are the short version. Real ones come with more caveats, but the caveats rarely change the picture.
Q: Should we use FHIR at all?
A: Yes.
This is the big question, and it doesn’t get asked enough. FHIR is not the solution to all problems. If you have an interoperability requirement, a regulatory obligation, or an expectation from your users, then FHIR is often the answer. If you don’t have any of these, it’s probably not. Vendors are happy to say yes, agree with your use case, and sell you a server. Don’t expect them to challenge you on this.
Q: Are we locked in to your server?
A: No, you can move to another server at any time.
This is true, technically. FHIR resources can be moved from one server to another without difficulty. But the architecture you built around the server cannot. Each vendor addresses FHIR architecture differently – custom ways to create FHIR operations, specific languages to build add-ons, custom interceptors for request handling, different processes for profile management, platform specific ways for syncing data. FHIR itself protects against data lock-in, but vendor lock-in is real.
Q: Will the server comply with my country’s regulations?
A: Yes, and you can always run a containerized instance if necessary.
The server itself does not make you compliant. If you have a specific Implementation Guide to conform to, you need to install and manage that in the server yourself. If there are data sovereignty requirements that govern which country or type of cloud the server must reside in, that’s on you to know about and on you to manage. Watch out for the “container” answer – this simple suggestion takes responsibility from the vendor and drops it 100% onto your team.
Q: Can it validate FHIR resources?
A: Yes, you can create as many profiles as you need.
This answer glosses over real complexity. Profile creation comes with a requirement to learn FSH, or a yearly price tag for commercial tools to create and manage profiles. If your organization is new to FHIR, you will not be creating and managing your own profiles any time soon. So many times I’ve seen FHIR profiles fill the data validation box in early architecture diagrams, only to have production releases ship without any data validation at all.
Q: Can we run analytics on the data?
A: Yes, we support SQL on FHIR, or you can sync with our analytical data lake.
Sounds like a positive answer, but let me rephrase it so that it says what it really means: you will have to build a process to export data out of the FHIR server and import it into another database or data warehouse. We’ll charge you extra for this, and you will need a project team to build the data pipeline and conversion process. As with validation, expect version 1 of your new FHIR solution to ship without this key feature.
Q: How does it perform under high loads?
A: We have organizations processing millions of FHIR resources a day.
They may have, but they’ve never tested your data, run your queries, or encountered your downstream users or the requests they will send to your server. If you want to know about server performance, you need to carry out a POC using your unique data model and expected request volumes – there is no way around this. Do not accept limited POCs that restrict the number of resource types or resource volumes that you can test.
The job of a FHIR server vendor is to sell their product, not to function as your project advisor. Unless you’re paying extra for their consulting services, but even then they will not recommend a competitor or tell you to use PostgreSQL instead. You need enough knowledge to know what questions to ask and how to understand their answers. Otherwise you risk buying the wrong server or misunderstanding the role that server plays in your architecture.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.