Illustration Full FHIR Server
Health Interoperability
8 Min Read

Integrating FHIR with your data architecture – an overview

Photo of Alexander Zautke
Alexander Zautke

Subscribe to our newsletter

Subscribe

Whether your main motivation is compliance, future-proofing your data architecture, or opening up for data exchange with third parties, the central challenges are the same: what’s the best way to implement and integrate FHIR? How can you get FHIR data in and out of your database? Should you be using the FHIR API with a full server, or would a FHIR facade better meet your needs?  

Firely Server can be implemented in both ways, and we’ve created plugins and tools to make either scenario easy. But how can you best decide which setup to choose and which plugins to use?  

Your starting point will usually be considering your use cases and working practices. In this blog, we’ll guide you through the different options, so you can make an informed decision about what works best for you.  

Image Facade vs Full server

FHIR Facade or full FHIR Server

Implementing Firely Server as a full server means storing your data in FHIR. Implementing Firely Server as facade means implementing it as a layer, so the FHIR interface sits over your proprietary database.  

You can see right away how crucial it is to decide where you want to store your data and whether or not you want to maintain a duplicate database.  

If you’re planning to be completely FHIR native, with your FHIR data as your primary data, the full server route is the way to go. But in reality it’s far more common to add FHIR to existing architecture, and in that use case the full server will require you to duplicate all or part of your data, while a facade directly connects to your proprietary database. That may sound like a facade is always the best option… but it’s not quite that simple.

How will you map your data to FHIR?

If you want to start exposing your data via FHIR, you need to map your data to FHIR. That‘s essential whether you choose a full server or a facade – the difference is where and how you do it. 

Choosing a full FHIR server

If you opt for a full FHIR server you’ll store your FHIR data in a FHIR native database, and you’ll need to map your data before you ingest it into your FHIR database – which also means you can use your tool and programming language of choice.  

Once your FHIR data is ready, the most efficient way to get it into your FHIR dataset will probably be Firely Server Ingest (FSI), a command-line interface (CLI) application that writes data directly to the Firely Server database, allowing mass ingestion of FHIR resources at high speed. 

Illustration Full server
Full FHIR server

The facade option 

If you choose a facade, mapping your data to FHIR takes place on demand within Firely Server, every time FHIR data needs to get in or out of your database. Compared to a full server, the main differences are: 

  • You don’t need to map all your data upfront  
  • Firely Server is  .NET based so your mapping code will need to be written in C#.  
  • As your resource types and search parameters grow in number, so does the burden of maintaining your code. Dependencies between search parameters may start to occur, until a tipping point when it’s more practical to choose a full Server.  
Illustration Facade
Facade

How much FHIR data exposure?

How much of your data needs to be exposed to FHIR and how many interactions do you expect? If you have a large dataset that needs to be available when requested, but you don’t expect a lot of interactions, a facade may be all you need. It will allow you to expose data when needed but save you the effort of an extensive upfront mapping exercise on all your data.  

The same applies if you only need to expose a limited set of resource types. The same applies if you only need to expose a limited set of resource types. But if you expect so many interactions that the performance of your primary system will be affected, the full server is probably your best option. 

Read-only or read-write?

Many regulatory use cases only require you to make data accessible, for example the CMS interoperability Rule (Patient Access API, Provider Access API, and Payer-to-Payer Data Exchange).  

So is your use case limited to making data accessible in FHIR, or do you want the option to write FHIR data in your database? A facade provides a data access layer that works in both directions: you simply write the mapping code to expose your data via FHIR, and to receive FHIR data that need to be stored in your proprietary database.  

With a full server your FHIR data is already available to be exposed. But what if you want others to create or update data via the FHIR API? If your FHIR database is not your primary database (it can be, but usually isn’t), you need to find a way to get that data to your proprietary database.  

Firely’s new PubSub Messaging plugin makes it super-easy to keep your proprietary database and your FHIR database in Firely Server in sync, with a native message bus, using an asynchronous subscription model to notify your services of changes to the data in Firely Server – and vice versa. We call this our Firely Server sidecar, and you can read how it works in this blog. 

What about Bulk Data Export?

Bulk Data Export (BDE) comes into play when you need to export a lot of data from a system or database in one go, to support a corporate process or meet regulatory criteria such as §170.315(g)(10). With Firely Server as a full server, the process should work ‘out of the box’, but if you want to use BDE with a facade you’ll need to implement additional code.

Firely can help

This is a complicated topic, so even after reading this article you may still have questions about adding FHIR to your architecture – especially if your use cases seem to fit several different set-ups. 

You can test all your options by downloading a free trial of Firely Server and practicing building a facade – or simply get in touch to discuss your use case with our experts.  

Want to stay on top of Interoperability and Health IT? 

Subscribe to our newsletter for the latest news on FHIR. 

Post a comment

Your email address will not be published. Required fields are marked *