About FHIR facades (part I) - two approaches

Why do you need an API facade for your healthcare app at all?


There are many reasons to let your software solution speak to others. Between interacting with other applications and extending your solution with new modules your solution needs to share data and perform operations by external requests. One common way of doing this is to provide API (Application Program Interface). Moreover, if you want your app to speak fluently with everybody else without hiring expensive interpreters, you should stick to the standard API, which is FHIR API.

Experienced developers of the new healthcare technology think about API from day one. Many of them are embracing the FHIR-first development process when a new solution's backend is built on top of the FHIR server. It uses the FHIR data model internally and supports complete FHIR API out of the box.

However, what if you developed your solution time ago, and it doesn't have an API layer? You need to allow your app to communicate with others, and this is what you use an API facade for - an interface added to your solution that gives other applications access to your solution's operations and data.

FHIR facade how to

Storage-less FHIR facade


One approach to a FHIR facade implementation is to translate FHIR REST calls to queries to the underlying database or services of the original system. You need to map your internal information model to FHIR - find what FHIR resources and attributes represent data structures in your system. Such a facade passes all the calls to the original database.

The implementation is straightforward for read-only API and can become complicated if you want to allow your users to write data back to the original system. Simple use cases can be solved with the mapping tools, and more complex implementations will require a lot of custom development.

FHIR facade with an intermediate FHIR server

The other approach is to use a generic FHIR Server for storing data that you are going to serve over API. You perform all the same mapping of your internal information model to FHIR but then synchronize data in your database with the data in the FHIR server that does the rest of the work. 


The FHIR server handles all the API commands without passing them to the underlying database of the original system. All the changes in the original database are timely passed to the FHIR server so that the original system and the FHIR server stay in sync.

Pros and cons

Both approaches are viable for different use cases and have different pros and cons. Storage-less FHIR facade works well for simple use cases when you need to implement a few individual API end-points. There is no duplication of data, and it uses minimal computer resources.


However, if you want your FHIR facade to host enterprise applications and enable population-level use cases then “caching” data in an intermediate FHIR server can be beneficial and sometimes even necessary. When a FHIR server handles all API calls, you control the performance of every call. You can achieve excellent performance at scale even when a FHIR server virtualizes data from several systems. The same API calls with a storage-less API facade might be very slow.


It’s important to mention the complexity of the FHIR search. It will be much faster with the intermediate FHIR server because you can support search with indexes which is impossible in a storage-less approach.


Even if your FHIR server gets many queries from external applications, it doesn't load the underlying system. The data is requested only once from the original system; the FHIR server supports all the API calls. If you use a storage-less facade, all the queries are going to the underlying database of the original system, and that might affect the performance of the original system and its users.


Using a full-blown FHIR server gives you one more advantage comparing to the storage-less FHIR facade. It allows you to build the whole new ecosystem of modern FHIR-first apps on top of it so that one day you can move on from your legacy proprietary backend to a new FHIR based future. Even though it requires more computer resources, you do not waste these resources. They provide you the next level of flexibility.


Conclusions

Which way to go with your API implementation is your choice. Health Samurai can support both approaches with its solutions and services. Send us a message or give us a call.

About FHIR facades (part I) - two approaches

Why do you need an API facade for your healthcare app at all?


There are many reasons to let your software solution speak to others. Between interacting with other applications and extending your solution with new modules your solution needs to share data and perform operations by external requests. One common way of doing this is to provide API (Application Program Interface). Moreover, if you want your app to speak fluently with everybody else without hiring expensive interpreters, you should stick to the standard API, which is FHIR API.

Experienced developers of the new healthcare technology think about API from day one. Many of them are embracing the FHIR-first development process when a new solution's backend is built on top of the FHIR server. It uses the FHIR data model internally and supports complete FHIR API out of the box.

However, what if you developed your solution time ago, and it doesn't have an API layer? You need to allow your app to communicate with others, and this is what you use an API facade for - an interface added to your solution that gives other applications access to your solution's operations and data.

FHIR facade how to

Storage-less FHIR facade


One approach to a FHIR facade implementation is to translate FHIR REST calls to queries to the underlying database or services of the original system. You need to map your internal information model to FHIR - find what FHIR resources and attributes represent data structures in your system. Such a facade passes all the calls to the original database.

The implementation is straightforward for read-only API and can become complicated if you want to allow your users to write data back to the original system. Simple use cases can be solved with the mapping tools, and more complex implementations will require a lot of custom development.

FHIR facade with an intermediate FHIR server

The other approach is to use a generic FHIR Server for storing data that you are going to serve over API. You perform all the same mapping of your internal information model to FHIR but then synchronize data in your database with the data in the FHIR server that does the rest of the work. 


The FHIR server handles all the API commands without passing them to the underlying database of the original system. All the changes in the original database are timely passed to the FHIR server so that the original system and the FHIR server stay in sync.

Pros and cons

Both approaches are viable for different use cases and have different pros and cons. Storage-less FHIR facade works well for simple use cases when you need to implement a few individual API end-points. There is no duplication of data, and it uses minimal computer resources.


However, if you want your FHIR facade to host enterprise applications and enable population-level use cases then “caching” data in an intermediate FHIR server can be beneficial and sometimes even necessary. When a FHIR server handles all API calls, you control the performance of every call. You can achieve excellent performance at scale even when a FHIR server virtualizes data from several systems. The same API calls with a storage-less API facade might be very slow.


It’s important to mention the complexity of the FHIR search. It will be much faster with the intermediate FHIR server because you can support search with indexes which is impossible in a storage-less approach.


Even if your FHIR server gets many queries from external applications, it doesn't load the underlying system. The data is requested only once from the original system; the FHIR server supports all the API calls. If you use a storage-less facade, all the queries are going to the underlying database of the original system, and that might affect the performance of the original system and its users.


Using a full-blown FHIR server gives you one more advantage comparing to the storage-less FHIR facade. It allows you to build the whole new ecosystem of modern FHIR-first apps on top of it so that one day you can move on from your legacy proprietary backend to a new FHIR based future. Even though it requires more computer resources, you do not waste these resources. They provide you the next level of flexibility.


Conclusions

Which way to go with your API implementation is your choice. Health Samurai can support both approaches with its solutions and services. Send us a message or give us a call.

About FHIR facades (part I) - two approaches

ReAD MORE

Two-phase FHIR terminology

ReAD MORE

First Fhirbase Release

ReAD MORE

FHIR Storage and Analytics in Baltimore

ReAD MORE

SQL on FHIR

ReAD MORE

Should you use FHIR resources as your data storage format?

ReAD MORE

The FHIR Guide for CTOs and technical leaders

ReAD MORE

FHIR and Machine Learning (ML)

ReAD MORE

Announcing the FHIRbase Dojo!

ReAD MORE

FHIR Starter 2018: Recap of the first FHIR conference in Eastern Europe

ReAD MORE

Using FHIR to Simplify Healthcare Application Development

ReAD MORE

FHIR: What's great, what isn't so good, and what it's not built to do

ReAD MORE

Moving Cardiovascular Disease Detection to the Cloud

ReAD MORE

FHIR Success Story: Narus Health Connects Patients, Families and Providers

ReAD MORE

Thoughts on the Duke University FHIR Applications Roundtable

ReAD MORE

Choosing Access Control Model for a Generic FHIR Server

ReAD MORE

Implementing FHIR in Dynamic Languages

ReAD MORE

Choosing FHIR for Laboratory Integration

ReAD MORE

Thoughts About Microservices

ReAD MORE

Meaningful Use Stage 3: ONC-certified API for your health care application

ReAD MORE

Transforming Healthcare IT

ReAD MORE

Starting a Health IT project with the FHIR standard at your healthcare organization

ReAD MORE

How do we build the best Convenient Healthcare Clinics?

ReAD MORE

Accelerating Healthcare Innovation with HL7 FHIR

ReAD MORE
415 S Sepulveda Blvd Ste 1000 Los Angeles, CA 90034
+1 (818) 731-1279
hello@health-samurai.io