Facade or repository: how to choose your path to FHIR

For most healthcare institutions, the question is no longer whether they will adopt HL7® FHIR®. Regulation, national single-record projects and pressure from clinical teams themselves have settled that debate.

The question that remains open is how. And that is where architecture decisions get made that are very expensive to reverse later.

The facade

A FHIR facade is a layer that exposes a standards-conformant API on top of a system that does not speak the standard. It translates between the FHIR format and the backend system's own format, so applications can query without knowing the legacy system's internal structure. The data stays where it is: when a query arrives, it is mapped on the fly and returned in real time from the original source.

That gives it two advantages the other path cannot match. It duplicates nothing, so there is no second copy of the medical record to maintain, back up and explain during an audit. And the data is always current, because what the query returns is whatever is in the system at that moment.

For an insurer that needs to expose a handful of read-only resources to third-party applications, the facade is the right answer. It makes no sense to maintain a full copy of the data to serve occasional queries.

The cost shows up on the other side. Every query hits the production system, so if the HIS is already stretched at peak hours, it now also carries the FHIR traffic. Response latency is the legacy system's latency: if that database takes eight seconds on a complex query, the facade takes eight seconds. And conformance becomes hard to guarantee, because translation happens at query time and there is no single point at which to verify that the entire dataset meets the official profile. Non-conformances are discovered one at a time, when they fail.

Response latency is the legacy system's latency.

The biggest cost is in the build. A facade is built by writing code: implementing resource providers on top of a base FHIR server, or customizing the service classes of whatever commercial engine was purchased. There are entire guides devoted to building one from scratch with Python and a relational database.

When the pattern is taken to national scale, the inventory becomes visible. Tanzania's FHIR Facade implementation guide combines profiles, logical models of the legacy structures, transformation maps in both directions, ConceptMaps, integration mediators, a mapping engine and a dedicated validation server. That is an engineering team sustained over time.

The repository

The repository model creates a new asset: a copy of the data stored natively as FHIR resources. Conversion happens before any query arrives. The fundamental difference between the two models comes down to where the data lives.

The repository verifies conformance once and keeps it proven. Every resource is validated against the official Implementation Guide when it is loaded, so when the health authority asks for evidence, a report exists. Queries are fast and never touch production, because the repository is designed to answer FHIR queries and the HIS never notices. It also serves clinical analytics, quality dashboards, research and regulatory reporting, which a facade does not. And it absorbs multiple sources naturally: three systems from three different vendors converge on a single queryable surface.

The fundamental difference between the two models comes down to where the data lives.

What it costs is just as concrete. There is one more copy of the clinical data, with everything that implies for security, backup and governance. There is a staleness window between the source and the repository, which depending on the use case can be irrelevant or unacceptable.

And the loading process has to be built and maintained. Historically, that has been the strongest objection to the repository: ETL into FHIR is a development project in its own right, with mappings in code, a specialized team and technical debt.

The comparison

                      FACADE                 REPOSITORY
Where data lives      Source system          Native FHIR copy
When it translates    At query time          Before querying
Data freshness        Total                  Sync window
Duplication           None                   Yes
Load on production    On every query         Only when syncing
Conformance           Hard to guarantee      Verifiable and auditable
Multiple sources      One per system         Converge into one
Analytical use        Limited                Natural

What changed between the two columns

Read the comparison honestly, and for most institutions that need a unified institutional record, reporting to the authority and clinical analytics, the repository is the right destination. The case is strong, even if the debate is not closed.

The reason many institutions end up choosing the facade is rarely architectural. It is that the path to the repository looked too expensive. And that cost came from how the loading process was built: in code, by specialists, one mapping at a time.

Many institutions choose the facade because of the price of ETL, not because of the architecture.

That part has changed. A declarative engine flips the equation. Instead of programming the transformation, you define where the data comes from, where it goes, with which mapping and against which standard. The mapping is built visually, field by field, with validation against the official Implementation Guide as you build it. Translating local terminologies into international vocabularies is handled as versioned configuration rather than hard-wired rules.

The architecture stays the same. What drops is its cost to build and maintain, which was the only argument supporting the opposite decision.

Who is going to maintain this in five years? It is the most important question, and the one least often asked.

Five questions before you decide

• Do you need data that is accurate to the second? If the answer is yes for your critical use case, the facade has an advantage the repository cannot match.
• How many sources do you have, and how many will you have in three years? One facade per system scales poorly, while the repository absorbs new sources.
• Will you be asked for evidence of conformance? If there is a national mandate behind it, proving compliance resource by resource stops being optional.
• How much can your production system take? If the HIS is already tight, adding live query traffic has measurable operational consequences.
• Who is going to maintain this in five years? It is the most important question, and the one least often asked. If mapping knowledge lives in a specific team's code, the institution is exposed the day that team is gone.

About what we are building

At arco health we develop Harmony, a declarative interoperability engine that builds and maintains FHIR repositories without writing code, with real-time validation against the standard and terminology translation included. Processing happens inside the customer's infrastructure.

Harmony is not the answer to every case. When the use case demands live querying without copying the data, the path is different, and we will cover it in an upcoming installment of this series.

If your institution concluded it needs a repository and was held back by the cost of building one, revisit that assumption before budgeting again. Write to us at [email protected] and we will show you Harmony running on your own data.

The next installment takes a deep look at the facade: what actually has to be built, and in which cases it is still the right decision.

HL7® and FHIR® are registered trademarks of HL7 International.