Why Consider an FHIR Facade? Pros, Cons, and Challenges.


Are you struggling with a legacy healthcare records system that isn’t Fast Healthcare Interoperability Resources (FHIR) compliant? 

If so, in this guide, we will help you assess whether an FHIR facade is right for you by looking at:

  • Issues and Challenges
  • Usage and Benefits
  • Pros and Cons
  • Implementation Options

We’ve helped a large variety of worldwide customers become FHIR-compliant. We’ll help you determine if an FHIR facade is right for you.

Consider an FHIR Facade

Healthcare applications need to send and receive data in different formats. No two internal data models of any healthcare applications are precisely the same. The underlying data models are always different. Yet, it is important to standardize incoming and outgoing message formats. HL7 FHIR provided this standard for electronic healthcare information exchange.

Why would a company consider using an FHIR facade?

Many companies cannot make a full-fledged transition to the FHIR standard.

This is often due to the complexity of their legacy systems and the risks involved with converting them to the FHIR standard. One solution is to build an FHIR facade that works as a “wrapper” around the legacy non-FHIR system. This FHIR wrapper exposes an FHIR-compliant interface to the outside world. The FHIR facade connects to the legacy system’s storage. In essence, this creates an FHIR interface for the legacy database of healthcare records.

How does an FHIR facade work?

An FHIR facade works by transforming a legacy format into the FHIR standard. To the outside world, it is as if the legacy system was built based on the FHIR standard. An FHIR facade converts formats for retrieving information from the legacy system and saving information to the legacy system. The facade supports both requests for retrieving information in FHIR format and requests to store information that is already in the FHIR standard. Also, the information being retrieved could be from local or remote data sources, so it could be a facade for remote FHIR servers as well.

Issues & Challenges

As mentioned, it may be impossible for companies to make a full-fledged transition to the FHIR standard. Many reasons may block them from making the change, such as:

  • The legacy system is too complex.
  • The risk of making changes to the legacy is too great, as they cannot afford outages. 
  • The staff is no longer capable of making changes to the legacy system.
  • The data model of the legacy application cannot be changed to support FHIR.

Reports show that legacy systems burden organizations, causing many to spend 80% of their IT development budgets on support of legacy systems just to “keep the lights on.” They cannot consider making changes and putting their businesses at risk. Even wrapping their legacy databases with an FHIR facade may be beyond their capabilities.

Usage & Benefits of an FHIR Facade

Clearly, there must be a use case for the FHIR facade. First, we mentioned integration with a legacy back-end system; this is the most obvious usage for an FHIR facade, which acts as a “wrapper” around the non-FHIR system and exposes an FHIR-compliant API to the outside world. You might think of this as creating an FHIR interface directly on the legacy system. Depending on the request, the API layer intercepts incoming requests in the FHIR format and retrieves the appropriate information from the legacy database or stores the appropriate information. 

There is an even more important benefit of an FHIR facade. The FHIR standard changes on a regular basis. It is not reasonable to consider changing back-end systems at the same rate as the FHIR standard changes. An FHIR facade insulates back-end systems from changes in the FHIR standard. The facade is updated to follow the appropriate FHIR standards. The API and conversions for the legacy system are updated. 

In this way, the FHIR facade allows access to information from other applications. Healthcare record information can be accessed by external applications that are enabled to query via FHIR. Besides, information and healthcare records can be shared across multiple systems based on the FHIR standard. 

Even if the back-end systems are not FHIR-compliant, an FHIR facade will provide a mechanism for systems to exchange or share information, allowing for a combined view of healthcare records based on systems that have an FHIR facade or are FHIR-compliant. 

Finally, legacy systems typically do not support new interoperability standards like FHIR, but the vast majority of healthcare records are stored in legacy systems. To enable access to historical healthcare records, one solution is to incorporate an FHIR facade connected to the system’s historical storage, creating an FHIR interface for the legacy database of historical healthcare records.

Pros and Cons of an FHIR facade

The advantages of FHIR should be obvious. By implementing an FHIR facade, providers of healthcare data can ease the implementation of FHIR compatibility. 

FHIR provides a single standardized format for data exchange. This means a single external API can be ensured to be up-to-date with the latest standards. A single external API means that back-end healthcare record systems avoid being updated for each change in standards or compliance requirements. Subsequently, this lowers IT costs for support and maintenance.

Additionally, an FHIR facade can be connected across several back-end systems, providing a single view of healthcare records. Disparate systems can appear as a single integrated whole by combining information behind the FHIR facade. 

Patients, healthcare providers, and insurers will benefit from having a single view across many sources of healthcare records. Imagine having a single, lifetime view of all healthcare ever provided to an individual, from birth to death, including the integration of patient-generated healthcare data from smart watches and other personal medical devices. These benefits will result in better diagnosis, safer emergency medical care, improved medium-term follow-up, and appropriate long-term care.As mentioned, there are challenges to building an FHIR facade. Legacy systems are complex; it can be challenging to connect to the information required in the FHIR facade from a legacy system. Some organizations cannot devote resources or budgets to create FHIR “wrappers” for their legacy systems. Working with a legacy system is always risky; the majority of the “outages” we hear about among financial service organizations are those burdened with legacy systems in a similar manner to healthcare organizations.

FHIR Facade Implementation Options

There are various options regarding how to implement an FHIR facade. As mentioned, you should consider the requirements of the interface: 

  • Reading data, also called client read-only
  • Adding/updating data, referred to as client read-write

Besides the implementation options, there are other questions to be addressed:

  • How will your FHIR facade be used: is it for online application integration or batch-mode integration?
  • What are the constraints related to security? How will you protect an existing internal system from intrusion and exploits? 
  • What about performance? Will your legacy system support simultaneous access from several remote systems? Can it support concurrent database updates?

One approach is to translate FHIR API calls to queries on the underlying healthcare records database. This creates an FHIR facade for your legacy database of healthcare records. The challenge is that you will need a good understanding of your legacy database so you can map your internal data model into the FHIR model. 

Clearly, there are numerous implementation challenges in building your own FHIR facade.


Obviously, you can construct your own FHIR-compliant APIs, but isn’t that like reinventing the wheel? The experts have already developed FHIR facades. Focus your efforts on integrating these with your back-end legacy systems, rather than building an FHIR facade from scratch.

Consider using an expert who has already dealt with the requirements of securely retrieving electronic healthcare records through an FHIR facade. They can ensure that the appropriate FHIR-compliant information is obtained and that you are compliant with the FHIR standard. 

Also, this will allow data to only be converted “on demand” and avoid keeping a copy of existing data in FHIR format. You might not want to expose all of your data to external FHIR clients; an FHIR facade allows you to expose only certain parts of your data.


Edenlab is a provider of FHIR facades and custom solutions focused on healthcare data interoperability. Medtech is Edenlab’s core domain, providing extensive expertise in interoperability with the HL7 FHIR standard. Edenlab has helped healthcare organizations, application developers, and integrators build FHIR-compliant solutions with their expertise in FHIR facade development.

In addition, Edenlab’s Kodjin FHIR server provides a low-code/no-code approach to ease the user’s usage of the HL7 FHIR specification. The FHIR server uses a modern microservices architecture to ensure future-proofing of your FHIR facade implementation. The solution is adapted to specific business problems through configuration without coding. Feel free to contact us for details.

What Is FHIR: A Brief Overview of Its Role in Interoperability


With the Interoperability and Patient Access final rule from the Centers for Medicaid & Medicare Services (CMS), health care stakeholders must ensure more streamlined data exchange between patients, providers, and payers. It’s a challenge that healthcare organizations can overcome by structuring healthcare data and making it interoperable via standards — particularly FHIR (Fast Healthcare Interoperability Resources), as suggested by the CMS.

FHIR is a relatively new standard for describing healthcare data in resources and specifications that enable health records exchange via an API. The organization responsible for FHIR is HL7 (Health Level Seven International), which creates health care standards.

This article will cover the HL7 FHIR in a short overview and its use for health data interoperability. Before getting into what FHIR is, it is essential to understand interoperability in the healthcare industry and its issues. So, let’s dive in!

The Issue of Interoperability of Healthcare Data

The easiest way to explain interoperability is through phones. Take any two smartphones, and they can connect through mobile data, a wireless connection, or Bluetooth regardless of what manufacturer made them. Healthcare organizations need such a level of connectivity.

But here’s where healthcare interoperability hits a few brick walls.

Industry challenges

As in other industries, expectations for a healthcare product are higher than for a Swiss watch:

  • Higher requirements. Approaches such as patient-centric healthcare, data-driven healthcare, coordinated care, and value-based care require smooth data exchange.
  • Higher expectations. Patients have growing expectations regarding service quality, data privacy, and healthcare efficiency, meaning more accurate and secure information sharing requirements.
  • Growing volumes of data. Healthcare organizations need to support automated clinical decision-making and other machine-based processing, the growing demand for remote patient care, and the trend of telehealth. They need to produce, store, and exchange vast amounts of information, and the volume of data is growing enormously.

Request a custom price quote for your Healthcare challenge. Use the form to describe the project, and we will get in touch with you within one business day.

Data Privacy issue

Companies face strict requirements for handling personal data in many industries, but it’s especially true for healthcare. There’s more at stake — not only is this data-sensitive but mishandling it could cost lives.

Other pressing issues

While data privacy is always a risk, application bugs can increase the possibility of human error:

  • Misleading healthcare data and mistakes in data exchange. Prescribing the wrong medication can cause patient death or lead to patient care errors.
  • Lack of data exchange between different entities. Duplication of analyzes and increased costs for unnecessary examinations.
So, what can be done?

Overall, there’s a need for data interoperability, but data must be structured and standardized to satisfy the market demand and solve the issues mentioned above. Otherwise, healthcare systems won’t be able to exchange it correctly.

Precursors of FHIR — Why Earlier Standards Weren’t Good Enough

Standardizing healthcare data is a challenge because the domain is very complex, and data can have multiple contexts. For example, a diagnosis can have different attributes and use diverse code lists. Yet, standards are essential for interoperability in scale.

One of the organizations that develop standards is HL7. So, let’s see what it did previously and why earlier data interoperability standards could not satisfy the industry’s needs.

What is HL7?

HL7 is a non-profit organization accredited by the American National Standards Institute (ANSI), which develops standards and provides a framework for healthcare data interoperability. The standards describe how the information can be shared, retrieved, exchanged, and integrated to support the delivery and management of healthcare services. It affiliates with countries all over the world.

Standards provided by HL7

There are three primary interoperability standards in use: V2, CDA, and FHIR. There’s also V3, but it’s less widely used.

Let’s take a closer look at the standards preceding FHIR and their limitations.

HL7 Version 2 (V2) is a standard for messaging that facilitates data exchange between systems. It was created in the 1980s and is still widely used by healthcare organizations and IT vendors. However, this standard has a few logical gaps:

  • It allows for too much optionality and ambiguity.
  • It’s generic and doesn’t provide constrictions for specific-use cases.
  • There are gaps and overlaps in the standard.
  • Conformance is often not specific.
  • V2 requires site-specific installation parameters and coding.
  • There’s a lot of variance in the installation that’s not fully specified.

Since there is variance and limitation with V2, HL7 devised Version 3 (V3), which is more strict than the previous version. Unlike V2, V3 is based on XML and defines two types of objects: messages and documents. In the US, V3 adoption is slow, but some of its documents have been successful worldwide. The most notable is the Clinical Document Architecture (CDA).

CDA is a standard for clinical document markup based on XML. While it specifies the semantics and encoding of clinical statements, it also has some limitations:

  • It doesn’t offer rules for transmission.
  • It’s not constrained enough to represent specific-use cases of document types. With CDA, a healthcare system gets a structured document ready for exchange with another healthcare system.

Both V2 and CDA aren’t that easy to learn, with an almost flat learning curve. For example, earlier HL7 V2 isn’t human-readable and requires a lot of training for you to start developing with it. CDA utilizes read-only mode and large documents. It also doesn’t have modularity.

Thus, earlier standards:

  • Are too generic (like CDA); result in everyone implementing it a bit differently.
  • Are too strict (like V3); don’t cover all the use cases.
  • Have too much variance and too many logical gaps (like V2).

Any extreme ends up with customizations that defeat interoperability. FHIR should counteract that.
Let’s look at FHIR in more detail.

Increase your Interoperability of Healthcare Data

Read about our solution – Kodjin FHIR Server

Kodjin Whitepaper

Please, leave your email to get Kodjin White Paper

    Full name


    Your form has been submitted successfully.

    Find the Kodjin FHIR Server White Paper in a new tab.

    FHIR — Is It the Right Solution for Interoperability?

    FHIR was developed to answer the issues that surfaced from previous standards. What is it capable of that the other standards are not? Is FHIR a better solution? Let’s try to answer these questions.

    The inceptive idea of FHIR can be attributed to an active volunteer at HL7 — Grahame Grieve. Then, it was actualized by HL7 to connect the different entities that use healthcare data and allow a smooth transfer via an API.

    Domain experts that form various FHIR workgroups (e.g., financial, administrative, clinical) decide what data to define and how it should look.

    Standards provided by HL7

    FHIR is organized by resources — small independent components that can be independently queried, updated, extended, or adopted. Some examples are patient, procedure, and medication.

    Similar to V2 segments, each resource can act as a stand-alone so that a system can interact with them independently. But they can also be linked together. Each resource has a human-readable text representation.

    Resources are designed with the 80/20 rule in mind: focus on the 20% of requirements that satisfy 80% of the interoperability needs. The remaining 20% of needs have customizations to adapt the common, somewhat generic resources as needed for specific-use case requirements.

    FHIR technology

    HL7 took a fresh approach to standardization based on how web apps are built, so FHIR is designed for the web. FHIR uses web technologies:

    • FHIR resources are formatted in XML or JSON formats that are commonly used in web communication.
    • FHIR APIs are REST-full APIs that use the HTTP protocol — also common on the web.
    • Every resource has a predictable web URL.
    • For security, FHIR uses the OAUTH2 standard.

    Using such technologies means that developers don’t need much time to get started with the standard, unlike previous versions.

    FHIR implementation

    FHIR is designed to be easy and fast to implement because it has implementation libraries in many programming languages (e.g., Python, JavaScript, C#, .NET). Many resources are free and readily available in the XML and JSON formats, as well as free test servers. It also includes V2 and V3 mapping.

    FHIR has also achieved community support that offers professional events and online communication.

    Stay in touch


      Our team we’ll be glad to share our expertise with you via email

      So, is FHIR better than its predecessors?

      Data can and should be customized to ensure interoperability but in a standard way. FHIR does just that. It deals with the complexity of the healthcare domain by allowing you to customize healthcare data in a standard way.

      The overarching idea of FHIR is to give users just enough freedom to solve cases within the standard’s framework by using profiles, pluggable terminologies, and extensions.

      FHIR is not too strict — it provides options for describing data. It doesn’t cause variance that could lead to misinterpretation.

      FHIR’s Benefits for Patients, Care Providers, Insurers, and Governments

      The main benefit of FHIR is that it provides interoperability for healthcare systems. What does this mean for its users?

      The vision of interroperable health IT – imagine this…

      • Available information supports improved care. FHIR allows for creating personal health records (PHR) which ensure:
      • Better coordination among caregivers
      • Availability of more complete data to aid clinical decisions
      • Availability of data to more participants in the care process
      • Possibility to customize treatments based on PHR
      • Easier selection of insurers
      • Patient and caregiver engagement. FHIR simplifies access to patient data stored in different systems—an essential for the US healthcare system as the federal government requires all healthcare providers to grant patients access to their data. For FHIR, this means patients can access their data, and caregivers can contribute data and access it on time.
      • More efficient care, more value. FHIR ensures smoother workflows, fewer delays, and less redundant work.
      • Data is available to improve population and public health. In a national context, government agencies can access public records to be better informed about the population’s health to find ways for improvement. In fact, CMS recommends FHIR as a best practice for payers and app developers.


      Achieving interoperability in healthcare comes with a set of challenges, and it’s only possible if data is structured and organized according to specific standards. Despite the complexity and hardships, implementing the standards is the only way to go if you want to meet the increasing demands towards healthcare systems.

      Implementation can become less daunting, thanks to the FHIR standard. Though only 24% of US healthcare stakeholders currently use APIs, 90% believe they are critical for the future of healthcare and estimate that FHIR will be widespread by 2024. Currently, even industry giants like Microsoft and Apple use the standard. Example: Apple’s Health Records app.

      FHIR provides unification and structure to data and simplifies its sharing between healthcare entities and patients. It eliminates risks around data duplication, misinterpretation of diagnoses, reduces costs, simplifies patient management, and improves treatment.

      If you want to implement FHIR and utilize its benefits, Edenlab is an excellent option. We have already implemented FHIR systems with over 30 million accounts and worked for the Ministry of Health of Ukraine, Turbota, and Heals, just to name a few of our clients.

      We use cookies to provide the best site experience. The cookies cannot identify you. By continuing your usage of the website, you agree to the Privacy policy.

      I agree