FHIR Facade or Repository: How to Choose

FHIR Façade or Repository: How to Choose the Best One

First of all, if you're asking if a façade is better than a repository, you're looking at the decision the wrong way. You wouldn't ask a carpenter if a hammer is better than a screwdriver. Or if a finishing nail is better than a galvanized screw. The carpenter couldn't answer you because one isn’t inherently better than the other. While they accomplish similar goals—connecting things—they do so very differently, for specific, strategic purposes.

The same is true about Fast Healthcare Interoperability Resources (HL7® FHIR®) server models. While they accomplish a similar goal, which is to make healthcare data more accessible, they store and handle the data differently for specific, strategic purposes. So the question isn't if you will adopt FHIR, but how.

Let’s look at the differences between façade and repository models through some sample use cases to understand what strategies should be employed when choosing one over the other. Be sure to take a look at the compatibility table at the end to see which model might best suit your needs.

Façade/Hybrid or Repository: What's the Difference?

The primary difference between these two models is the location of the data.

In a façade model (aka HAPI FHIR Plain Server or Smile Digital Health's Hybrid Provider), data remains in its existing source system. When queried, data is mapped to FHIR on the fly and delivered in real-time from existing data sources.

Data stays in place
A translation layer exists
At query run time, data is converted to FHIR and returned to the client

In the repository model (HAPI FHIR's JPA Server or Smile's CDR), a new asset is created to store a copy of the data separately—a native FHIR clinical data repository. This way, the data can be converted to FHIR before any query is made, establishing a connection to the purpose-built repository rather than the back-end data sources. The critical difference is that the repository model houses a FHIR copy of all data so that any relevant information can be immediately sent to the requestor.

Data is copied to the repository and converted to FHIR at that time
Query talks to the repository
Data from the repository is returned to the client

Use Cases for FHIR Façade and FHIR Repository

The following examples are fictionalized, based on a collection of real-life design considerations. They aren't meant to encompass the full breadth of design considerations that go into each model.

When to Use a FHIR Façade (Hybrid)

Company X is a mobile app that helps patients send messages and updates to their mental health provider. They are cautiously optimistic about the adoption of FHIR to develop more integrations and improve the user experience (UX), but their team is otherwise very comfortable with their current database. They already have a rich set of data services that predate FHIR and want to leverage their existing investments into their service-oriented architecture (SOA).

As they explore FHIR, Company X creates a list of must-haves:

easy integration
shorter timeline
soft transition
ability to test what their other resources could look like in FHIR.

After reaching out to a FHIR expert (Smile Representative), Company X realizes the façade (Hybrid) model is right for them. Here's why:

They want to—and still can—maintain their own database and take advantage of it in a new way;
They appreciate the simplicity of a single source of truth for data;
They can map data to FHIR with their schema to preview what their resources will look like in FHIR;
When they preview their resources in FHIR, they can identify challenges in data migration and determine any other difficulties with their schema on a much smaller scale.

Company X is also comfortable choosing a façade model because it can be a decision “for now.” They know that they can move to a repository model at a later date if the façade limits them from developing more advanced FHIR features and capabilities.

When to Use a FHIR Repository

Company Y gives patients access to their electronic health records (EHRs), syncs with their wearable devices, offers appointment scheduling and facilitates virtual care appointments. They have a large and complex library of data and are eager to adopt FHIR. Because they store so much sensitive data, however, they are especially cautious about any data exposure during the transition to FHIR.

As they explore FHIR, Company Y creates a list of must-haves:

minimal data exposure
reduced time/cost to maintain complex data
meet any and all upcoming ONC compliance requirements

After reaching out to a FHIR expert (Smile Representative), Company Y realizes the repository model is the most strategic solution for them now and years down the road. Here's why:

Data in the repository can be limited, minimizing data exposure. For example, the data copied to the repository can be limited to only the last two years, or limited to a specific type of data. All other data would remain "untouched" or "unseen" by the FHIR query, making them a less attractive target to hackers;
They're comfortable copying their data into the repository, even though it takes a good amount of time and effort with very low margin for error. They also have sufficient storage for their volumes of data;
Smile will maintain their extensive complex data on their behalf, manage upcoming FHIR compliance requirements and manage search functionality. Company Y will save significant time, energy and cost by avoiding the complex demands of maintaining two separate databases and the unnecessary expense of writing custom search functionality for their data;
Settings can be tweaked to match their risk profile.

Smile Digital Health’s FHIR Compatibility Tables

You may have recognized that your company aligns with some qualities or must-haves of Company X as well as Company Y. So how do you know which FHIR deployment model to choose?

While the best, most accurate, method to determine your company's database compatibility is to chat with a FHIR expert, you can start on your own by browsing through Smile’s FHIR compatibility table:

Façade/Hybrid Database	Repository Database
Your team is comfortable using your existing database You want to continue scaling your database with proprietary schemas	You’re focused on scaling the database Smile uses, not your own
You're prototyping an application programming interface (API) and need to see what your resources look like in FHIR	You want to limit your maintenance time because you have a large, functionally complex database. The thought of Smile taking care of the data and libraries is a relief
You want to identify challenges in migrating data ahead of time	You want improved performance as your data set increases
You’re okay with handling the difficulties that arise in testing when dealing with two databases	You want to make testing easier for you or your team
You want to take incremental steps to full FHIR readiness by creating numerous façades	You want to take advantage of Smile’s powerful out-of-the-box search functionality and focus efforts on mapping data into the repository instead of rewriting search scripts that have already been completed

Now, after reading through the compatibility table, what's your conclusion? Is a repository model right for your company, or is the better choice a façade/hybrid model?

Either way, Smile is HAPI to help.

How? Review our façade vs. repository model comparative table to learn more about the functional differences that separate the two databases.

And if you still have more questions, hop on a call with one of our FHIR experts. They'll help you identify the other questions you need to answer and explain in more depth the technical details that go into making this decision.

	Repo Model	Hybrid Model
Scalability & Performance	Focused on scaling the database Smile uses. This method does not require real time responses and therefore greatly improves performance of the system	To scale, clients must look at both Smile and their own source database. Hybrid impacts the performance of an operational database, as it requires near real-time data importing and may affect system performance.
Maintenance	Smile is responsible for maintaining the data and the database that contains it.	Clients must maintain the database, hybrid provider (mapping of source data) and Smile Instance which can become a costly endeavor as they increase their data in size and complexity.
Search Functionality	Leverage Smile’s existing, out-of-the-box search functionalities without any necessary custom development. Data will be duplicated to exist both in its current source system as well as in Smile.	Custom search functionality can be expensive and time consuming to write. Smile has a number of search functionalities made available to clients. Clients may be rewriting work that is already completed by Smile. No duplication of data within this model.
Typical Use Case with Timelines & Effort	Long term strategic goals usually involve mapping all data (or as much as possible) to FHIR. Implementations of this nature generally require more time and effort to complete.	Precision/tactical use case for mapping specific data. Implementations of this nature generally require less time and effort to complete.
Cost	Slightly greater Smile licensing cost, however Smile Digital Health takes the cost of ownership. Nominal impacts on operational systems.	Smile licensing cost is slightly less for a hybrid model, however, total cost of ownership for the hybrid model will likely be slightly higher than a repository model (as the database tier won't be as optimized and will have implications on other operational systems).
Testing	Only the mapping requires testing (as functionality is provided by Smile).	When completing testing around search queries, both the mapping and provider need to be reviewed.