FHIR Facade Model: Is it right for your payer organization?

By: Charlie Provenzano

One of the many decisions payers must make on their journey to compliance with CMS Interoperability and Patient Access Final Rule compliance is how they will provide data to their FHIR server. The FHIR facade model implementation appears to be a shortcut: Rather than creating a FHIR repository to house the required data, the facade model data is fed directly from other repositories and converted to FHIR resources on demand. However, payers may be trading a short-term benefit for long-term value. Read on to explore the important pros and cons of the FHIR facade model as a viable option for healthcare data interoperability.

As deadlines for CMS Interoperability Rules approach, we’re getting a lot of questions from payers around what is commonly referred to as the FHIR facade model. There are two often discussed ways to provide data to your FHIR server. The first is to provide that data from a FHIR repository where all of the necessary data resides, already aggregated and converted to FHIR resources. The second is the facade model. In the facade model, data is retrieved from one or more back-end repositories and converted to FHIR resources on the fly to fulfill a particular read request.

I think that most people championing the facade model would do so for one reason. It eliminates the need to add and maintain a separate data repository. It’s a strong argument as well, particularly if your IT department has already invested time and money on processes around keeping an existing warehouse up to date. The biggest argument against the façade model is performance. In most cases, the overhead of collecting and converting all of that data to FHIR resources on the fly will risk exceeding the timeout limits of the FHIR server’s RESTful API call.

Evaluating the facade model for your organization

Even with the performance hit, for some, the pros of facade will outweigh the cons. Here are some things to consider:

• • • Does the data you need to supply for the Patient API reside in a single data repository, or is it stored across multiple repositories?

    • If it resides in multiple repositories, are they colocated?

    • Are all repositories updated at a minimum every 24 hours? If not, what is required to enact that state for each repository?

    • If the request from the API is for everything, how long does it take to compile this data under ideal circumstances? At times of high load? For a member with a large history?

    • Do you need to provide real-time updates to apps connected to your FHIR API? (i.e., do your apps need data that is refreshed MORE often than your FHIR repository?)

    • Do you use standard code sets (e.g., LOINC, SNOMED, etc.) or need to perform code translation or augmentation on the fly?

If your data resides in multiple distributed repositories, performance will likely be an issue with the facade model. You might still be able to stick with the facade model, but you may be forced to provide separate endpoints (and require separate requests for) separate forms of data. It’s likely that you would want to group those endpoints according to the repositories the data resides in. This also complicates interactions for third parties who might want to access your patient API.

All of the above considers only Read requests against the FHIR endpoint. Write requests, even internal ones, are not practical with a facade model. Imagine the logic required to reverse engineer a series of FHIR resources into various other standard formats, write each one and monitor the results for success/failure. Technically it’s possible, but success at scale is extremely unlikely. However, if the apps accessing your data need access to the source systems (as in the example above where data is refreshed more often at the source) the facade model might be your only option for those use cases.

When to consider a FHIR repository

If after answering the above questions you are concerned about performance, consider employing a separate FHIR repository as a sort of cache. Many of our implementations take this approach. The FHIR data is stored in a single repository as FHIR resources. Date retrievals are quick. Data integrity is maintained by piggybacking on existing data synchronization jobs to keep the FHIR cache current. There are many effective ways to approach this and easily maintain a high level of performance and scalability; it just depends on the needs and skills in your organization.