The facade from the inside: what you have to build and when it is worth it
A facade looks like a thin layer until you build one. We walk through what the platforms solve, what stays with your team, and the cases where it is still the right decision.
In the previous installment we acknowledged that the facade has two advantages the repository cannot match: it duplicates no data, and it delivers that data current. This time we open it up, because in a demo it looks like a thin layer and in production it is a complete FHIR server that someone has to write and maintain for years.
A query that looks simple
GET /Observation?patient=123&category=laboratory&date=ge2026-01-01&_count=20To answer it, the facade has to know which patient in the HIS is 123, which table holds the lab results, and how to turn the ge prefix into a condition on the date. Then it pages the results, turns each row into an Observation with its LOINC code, and returns a link to the next page that still works while the clinician reads.
That covers a single search parameter on a single resource.
In a demo it looks like a thin layer. In production it is a complete FHIR server.
What the platform solves and what stays on your side
Several FHIR server platforms now offer a facade mode, and it is worth being precise about what they contribute. They solve the scaffolding: the REST API, parsing of search parameters, paging, security and auditing. That saves months of work.
What they do not solve is translating the query into the source system's schema, or turning each row into a resource that conforms to the profile. That half is written in the language of the platform you chose, and your own team maintains it.
PIECE WHO WRITES IT
REST API and search The platform
Security and auditing The platform
Query translator Your team
Per-resource mapping Your team
Stable identity Your team
Terminology Your team
Conformance Your teamThree of those pieces are almost always underestimated. If the HIS changes a patient's key when two records are merged, the references other systems already stored stop pointing at anything. If a test in the local catalog was never mapped to LOINC, it goes out with its own code and the error surfaces when the receiver complains. And since validating every response adds time to every query, most facades do not validate in production: when the authority asks for evidence of compliance, there is no report to hand over.
The cache dilemma
Every query to the facade is a query to the production system. If the HIS takes eight seconds, the facade takes eight seconds plus the translation.
The usual way out is to put a cache in front. A cache is a copy of the data with a staleness window. At that point the facade has lost the two advantages that justified choosing it, and it keeps the full cost of building it.
A cache is a copy of the data with a staleness window.
Analytics runs into something similar. FHIR bulk export walks the entire production database, so many institutions schedule it overnight and store the result. In practice, that is a repository built without planning one.
That code depends on two things the institution does not control: the HIS schema, which changes with every vendor release, and the Implementation Guide, which changes when the authority updates it.
When it is still the right decision
There are cases where the facade is the best option. When the value is in the current state of the data, such as open appointment slots or the active medication a clinician reviews at the point of care. When a legal restriction rules out keeping a second copy. When the exposure is small and stable: few resources, read only, one source and one consumer.
And before building anything, it is worth checking whether the HIS vendor already offers a native FHIR API. That API is a facade someone else maintains, and the question becomes whether it covers the profiles the authority requires.
Outside those cases, with several sources and a mandate for demonstrable conformance, the list above multiplies by each system.
What comes next
One scenario is still open: a clinician who needs to see, in real time, the history of a patient treated at four institutions that are not going to hand their data to a central database. There the question shifts from how one institution exposes its data to how a network is queried. We will come back to that pattern in this series.
The next installment goes into the problem neither the facade nor the repository solves on its own: terminology, the part of FHIR projects that gets budgeted least.
If your institution is weighing whether to build a facade, write to us at [email protected] and we will check this list against your case.
HL7® and FHIR® are registered trademarks of HL7 International.
