If you’re implementing FHIR to meet a regulatory requirement, facades can look attractive.
The regulation specifies the data that must be exposed, often down to precise ValueSets. Chances are it can be met by exposing only a small number of resource types and search parameters. No need for a full FHIR server when a small team can throw a working facade together in a few weeks.
The problems start when your facade meets live requests in production.
Regulations generally have little to say about performance. There may be a throwaway line about responding in a “timely manner” but that has no teeth.
A facade can be fully compliant, pass any internal or external audit, and still take many seconds or even minutes to return results.
The reason for this is that every request is a live query against your source systems, generally mapped to FHIR on the fly. Your response time is dictated by your slowest legacy database or internal API – something your FHIR implementation team may have no control over. When a single query has to pull data from more than one system to build a Bundle, performance problems get worse.
Nothing in the regulation forces you to fix any of this, so it often stays unfixed, making the facade unusable.
A facade is defensible when all you’re doing is checking the compliance box. If you want other systems to consume your FHIR API for real, it’s usually not good enough.
~~~
Chapter 4 of my book, FHIR Architecture Decisions, goes into facades in some detail.
---
Download my “FHIR Architecture Decisions” book
FHIR Weekly
Join 1,100+ business and technical leaders.