How do you bring FHIR into your organization?
Let’s assume you need to expose data via a FHIR API. Maybe your business is responding to regulations or legislation; maybe you have data sharing requirements of your own and decide that FHIR is a good way to achieve your objectives.
Where do you start? What are the different options available to you?
The first point I want to make is that there is no “best way” of exposing data via FHIR. There are many different approaches that can be taken. One approach might be perfect for your use case but not be feasible at all for another organization.
If someone is advising you on a single course of action, and presenting this course of action as the “gold standard” for FHIR, they are wrong. There is no “one way” or “best way” of delivering data using FHIR.
Secondly, I want to point out that there is a healthy diversity in the FHIR server market. You have a LOT of options to choose from if you decide to use a commercial FHIR server. Again, there is no ONE provider that stands out as being better than all the others. Each one has their strengths and weaknesses. Don’t let anyone tell you different.
I see 5 approaches when it comes to implementing FHIR. In some cases the differences are small, in others very large. Which one you choose will depend on your unique requirements.
Again I want to stress that no one approach is inherently better than the others. Treat with caution any advice that suggests otherwise.
Approach number 1: Managed FHIR servers
A managed FHIR server is a commercial server that is sold “off the shelf”. The FHIR API is fully implemented and the underlying database is managed for you by the server provider. Generally speaking you will not have direct access to the underlying database.
The only way to see the data inside the server and to add data to the server is via the FHIR API itself using GET and POST requests. Generally these servers are in the cloud and can be spun up as “fully functional” FHIR servers in only a few minutes.
Examples of managed FHIR servers are those provided by Microsoft Azure, AWS and Google Cloud. And by smaller vendors such as Health Samurai, Medplum and Oystehr.
Expect a “pay as you go” pricing model – as is common for most cloud services. These servers are very popular, especially if your use case involves integrating with existing cloud services in the same platforms such as Azure or AWS.
Managed FHIR servers are a very common choice for businesses kick starting their first FHIR project.
I’ll talk about them in a lot more detail in a a future episode.
Approach number 2. Enterprise FHIR servers
Examples of Enterprise FHIR server providers are Smile Digital Health in Canada and Firely in the Netherlands. I use the term “Enterprise” here because the sales processes and pricing models of these companies align with the enterprise sales models we’re probably all familiar with.
The process tends to involve a lot of sales calls and will often involve a paid for POC. This is generally accompanied by a lot of hand holding that leads to a contract many months later. Servers are typically priced per production instance and accompanied by consulting support to help and advise you as you build out your solution.
The servers are typically installed into your own infrastructure — wherever that might be — and managed by your own technical team.
Expect to pay somewhere in the high 5 figures or even 6 figures per production server.
Approach number 3. Larger “all encompassing” solutions
Up to now I’ve talked about individual FHIR servers that your organization’s apps interact with directly. But there are larger application suites out there that contain FHIR servers or FHIR APIs as one component part of a much larger infrastructure and solution.
Examples here are Enovacom, Infor and InterSystems. In each of these cases a FHIR server might sit at the centre or off to one side in an architectural diagram, receiving or exposing data via FHIR to a host of other applications.
You’re not buying a FHIR server, you’re buying the much larger solution. You should also expect an enterprise sales process from these companies, but I’m not prepared to comment on the potential costs here as there is much more involved in the sale than just a FHIR server.
In a similar but different vein, you have FHIR APIs that are accessible from EHR vendors such as Epic and Cerner. In these cases you’re not paying for a FHIR server at all, you’re paying for the extra functionality or module that exposes a very selective subset of data via FHIR. A very different thing entirely.
Already, it should be clear that the differences between approaches 1, 2 and 3 are so great that it will almost never be a direct choice between them. Your use case probably already dictates which of these approaches best fits your requirements.
Let’s look at the next 2 approaches.
Number 4. Open source FHIR servers
You don’t have to pay an up-front cost to a commercial vendor for your FHIR server. If you have the technical ability within your organization you can use of one of the many fully-featured open source servers out there.
Popular examples are the HAPI server, which is essentially the same server as the commercial offering from Smile Digital Health. And Microsoft’s FHIR server which also mirrors their commercial offering. There are a few others as well.
There are real advantages to fully owning your server and all the code that comes with it. Implementing new features that are not provided by the commercial versions becomes possible. And direct integration with your own custom applications and workflows is easier.
Obviously this is a lot more work than clicking a button in an AWS portal and waiting 10 minutes for your server to be provisioned. But if you’re thinking long term and have done a lot of research in advance, this is a very viable option that you shouldn’t discount.
It’s far more common than you might expect.
Approach number 5. A FHIR Façade
Let’s say you want to expose your data via a FHIR API but that data resides in one or more existing databases or data warehouses. For whatever reason you don’t want to synchronize this data with another database that feeds your FHIR API. You don’t want a copy of your data sitting in a FHIR server.
In this case you might choose to implement the FHIR API yourself and pull the data directly from its source, constructing and populating the FHIR resources on the fly. This would involve a lot of development work — especially in the data mapping layer that you’d have to build — but it comes with the significant upside of maintaining a single source of data.
A common way to get started in building a FHIR façade is to use one of the existing open source servers I mentioned earlier, and customize it to your requirements. They already provide the API as well as the FHIR resource objects and FHIR data type objects that you would need.
It’s worth bearing in mind that you would only need to expose the FHIR resource types and search parameters that meet your use-case. This could be as low as 5 or 10 resource types and the supported search parameters could be equally small.
While building a FHIR facade is big project, the size of that project would vary project to project.
There is a sixth approach that I’m not going to go into today as it really requires an episode all of its own. That’s the “hybrid” approach and I’ll be talking about that in a future episode.
I hope I’ve demonstrated that there is a wide variety of approaches to bringing FHIR into your organization.
- You can use Managed FHIR servers in the cloud
- Enterprise Servers that you maintain yourselves
- “All encompassing” solutions of which FHIR is only one part
- You can build on the back of open source Servers
- Or you can choose to implement a FHIR Facade
Which one you choose should depend on your individual requirements.
I want to re-iterate what I said at the beginning — that no one approach is inherently “better” than the others. Be very wary of anyone who tells you different.
What worked well for one organization or one use-case will not necessarily work well for yours.
~~~
Episode 2 of “The Business of FHIR” podcast, where I talk about the different FHIR server implementations and the options open to you when choosing a server approach.
---