01
Architecture review
Façade, repository or hybrid — decided on your data, your volumes and your roadmap, in writing.
1–2 weeksFixed price
FHIR Integration Services
FHIR Isn't an Integration. It's an Architecture Decision.
Standing up an endpoint takes a fortnight. Living with the choice underneath it takes years — how fresh the data is, what search you can support, whether you can pass certification, and what it costs at a million resources. We build FHIR the way we build product: the decision first, then the code.
R4 · 4.0.1US CoreSMART v2Bulk DataDa VinciInferno g(10)-validated patterns. ISO 27001. BAA available.
The decision under every FHIR project pick one, live with it
AFaçade over your existing databaseNothing duplicated. Every request costs a live query.BA real FHIR repository you populateFast and fully searchable. Now you own a sync problem.CHybrid — cached projection, live fallbackWhat most production systems end up as.Most teams pick A because it starts fastest — then hit search and Bulk Export, and rebuild. We'd rather you chose deliberately.
47/47
Inferno g(10) tests passed on a SMART server we built, first submission
52
Interfaces migrated from HL7 v2 to FHIR R4 with zero downtime
4.0.1
Still the regulated baseline. Not R5 — see below
Jan 2027
When CMS-0057-F APIs must be live in production
The comparison that actually matters
Façade or Repository. Everything Else Follows from This.
Not “which FHIR server should we buy” — that's a procurement question. This is the one that decides your latency, your search surface, whether Bulk Export is even possible, and how much of certification you can pass.
C is the honest answer for most production systems: a repository for everything that must be searchable or exportable, with a live pass-through for the few resources where a stale answer is unacceptable. Choosing that deliberately is very different from arriving at it after a rebuild.
What you're deciding
Façade
Repository
Read latency
Inherited from the source, plus mapping on every call. A slow query stays slow.
Yours to control. Indexes are yours to tune.
Freshness
Always current. This is the one thing a façade wins outright.
As fresh as your ingest. Minutes, or seconds, but never zero.
Search surface
Limited to what you can translate into the source query language. Chained and reverse-chained search is where façades stall.
The full specification, if you index for it.
Bulk Export
Expensive — every export re-maps the population, and it competes with live traffic.
A batch job over data already in shape.
Where the cost lands
Runtime. It grows with traffic, forever.
Build and storage. It's paid once, then amortised.
There is no universally right answer — but there is a wrong way to arrive at one, which is to start coding before this conversation has happened.
The second decision
Four Ways Data Leaves a FHIR Server.
Most performance problems in FHIR products are really a mismatch between the access pattern and the use case. Pick the wrong one and no amount of tuning saves you.
REST search and read
One patient, now. The default, and the right answer more often than people admit.
1 – 10³
resources per call
Where it's right
Anything driven by a user looking at one patient. Chart views, decision support, a clinician opening your app. Latency matters, volume doesn't.
Where it breaks
_includeand_revincludequietly turning one call into thousands of rows- Deep paging — offset pagination degrades badly past a few pages
- Chained search across resources a façade can't translate
- Clients polling
_lastUpdatedbecause nobody built subscriptions
What we do
Design the search parameter set deliberately and index for it, cap includes, use cursor-style paging, and load-test with a realistic patient — not the three-resource test patient everyone develops against.
Bulk Data — $export
Populations, not patients. Analytics, quality measures, risk, training data.
10⁵ – 10⁸
resources per job
How it actually works
Asynchronous by design — you kick off a job, poll a status endpoint, then collect newline-delimited JSON files. It is a batch pipeline wearing a REST interface, and it should be operated like one.
Where it breaks
- Treating it as synchronous and timing out the client
- Exporting everything, every night, because
_sincewas never wired up - Export competing with live traffic on the same store
- Group-level export assumed available — often it isn't
What we do
Incremental exports keyed on _since, isolated from the live read path, with resumable collection and a checksum on what landed. This is the pattern that makes a façade painful and a repository comfortable.
Subscriptions
“Tell me when something changes” — the pattern people assume exists, and often can't get.
Push
if your counterparty supports it
The honest state of it
Topic-based subscriptions arrived properly in R5 and are available to R4 through a backport guide — but support in real deployments is inconsistent. Never design a product around a customer enabling subscriptions until you've confirmed that specific customer can.
The usual fallback
Polling on _lastUpdated, which works and is wasteful, or an HL7 v2 feed for the event and FHIR for the detail — a combination that's less elegant than the slide deck and more reliable in production.
What we do
Build the event path behind an interface so subscriptions, polling and a v2 feed are interchangeable per customer. The product stops caring which one a given site can offer.
SMART on FHIR — in-context launch
Your app opening inside the chart, already knowing the patient and the user.
SMART v2
granular scopes
Three shapes, different reviews
- EHR launch — inside the clinician's session, with context
- Standalone — the patient authorises from outside
- Backend — no user, server-to-server with a signed assertion
Where it breaks
Scope design. SMART v2 splits read into finer-grained permissions, and asking for more than you need is the fastest way to fail a customer's security review. Registrations that lock after go-live make this expensive to correct.
What we do
Design the smallest scope set that supports the workflow, prove it in a sandbox, and validate the launch against conformance tooling before a customer's reviewer sees it. Vendor-specific paths are here →
Most products need two of these. Very few need all four — and building all four is how a roadmap disappears.
Versions
What's Published and What's Required Are Different Things.
This is the detail that separates teams who have shipped FHIR from teams who have read about it. Building to the newest guide is not the same as being compliant, and being compliant is not the same as being current.
Where things stand
The position
What we'd do
FHIR R44.0.1
The regulated baseline. US certification, payer mandates and effectively every active implementation guide sit here.
Build here. Not a compromise — it's where the ecosystem is.
FHIR R5trial use
Breaking changes, and adoption that never materialised — reported around 5% of implementers.
Skip it. Investing here buys you incompatibility with the systems you need to talk to.
FHIR R6in ballot
Balloting through 2026 with publication expected 2026–27. Regulatory adoption follows separately and slowly.
Plan for it, don't build on it. Keep your mapping layer separable so the move is a translation, not a rewrite. Our R6 guide →
US Corethe certification floor
Certified health IT is held to US Core 6.1.0 / USCDI v3 from 1 January 2026 — while the published guide has moved on to STU 9.0.0, aligned to USCDI v6.
Know which one your customer is held to. Conform to the floor, design so the newer profiles are additive.
Must-supportthe classic trap
In US Core, must-support is not the same as required. A conformant server may legitimately return nothing for an element your product treats as guaranteed.
Never let a must-support element become a hard dependency in your UI or your logic. This one causes real production incidents.
The deadline that's driving budgets
CMS-0057-F: Four APIs, Live, by 1 January 2027.
If you sell to payers, this is the single biggest FHIR demand event in years. The APIs must be built on FHIR R4 with SMART authorisation, and CMS points clearly at the Da Vinci guides as the intended path.
Coverage requirements CRD
The moment a provider orders something, a hook fires and the plan answers in real time: is prior authorisation needed, and what documentation supports it.
Documentation templates DTR
A smart questionnaire handed back to the EHR, pre-filled from the chart — so nobody retypes what the system already holds.
Prior auth support PAS
Submission and decision: approved, denied with a specific reason, or pended. Seven calendar days standard, 72 hours expedited.
Access APIs Patient · Provider · Payer
Patient access, provider access and payer-to-payer exchange — the three that make the prior-auth data reusable rather than trapped.
X12 278 remains permitted for back-end transmission, so this is not a rip-and-replace of your claims stack — it's a FHIR surface in front of it. Which brings you straight back to the façade-or-repository question above.
What breaks in production
Six Failures We've Been Called in to Fix.
None of these show up in a sandbox. All of them show up at a real customer.
01
The three-resource test patient
Everything is fast against sandbox data. The first real patient has 900 Observations and eleven years of history, and the chart view times out.
What we doGenerate realistic synthetic populations and load-test before go-live, not after.
02
Must-support treated as guaranteed
A conformant server returns nothing for an element the UI assumed was always present. Blank screens, and an argument about whose bug it is.
What we doTreat every must-support element as optional in code, and degrade visibly rather than silently.
03
Terminology that never got mapped
Codes arrive in a local system nobody translated to LOINC or SNOMED CT. The data stores fine and is invisible to every rule you wrote.
What we doValidate codes on ingest and quarantine the unrecognised instead of accepting them.
04
Pagination that degrades
Offset paging works for three pages and collapses at three hundred. Usually found by whoever built the export, at the worst moment.
What we doCursor-based paging and bounded result sets from the first release.
05
Identity assumed, not resolved
The same person arrives under different identifiers from different systems, and quietly becomes two patients in your product.
What we doResolve on assigning authority and identifier type, and treat merges as a tested event.
06
Scopes locked in too wide
An over-broad scope set sails through development and fails a customer's security review — after the registration has been locked.
What we doDesign the minimum viable scope set up front and validate it before anything is marked production-ready.
What you can buy
Five Ways to Start.
Fixed scope and fixed price, except the last, which is monthly.
02
Most chosen
FHIR R4 API build
A conformant R4 surface over your data — US Core-profiled, searchable, and tested against the certification bar.
8–16 weeksFixed price
03
SMART app or backend service
Launch inside the chart, or server-to-server. Scope design, conformance validation, and the customer review.
6–12 weeksFixed price
04
v2 → FHIR modernisation
Existing interfaces brought behind one FHIR model, one at a time, with nothing going dark.
Per interfaceFixed price
05
We hold the pager
Monitoring, version and profile changes absorbed, and a monthly note on how it's running.
MonthlyPer environment
Payer teams working to CMS-0057-F: talk to us about the Da Vinci scope specifically — it's a different shape of project and the 2027 date is not moving.
Proof, not promises
Three We've Delivered.
Conformance
47 of 47 certification tests, first submission
A standalone SMART on FHIR server built to the g(10) standardised API criterion and passed on the first run — the bar an app must clear to launch inside a certified EHR.
47/47
tests passed
US Core
conformant
Modernisation
52 interfaces moved to FHIR R4, no downtime
A decade of point-to-point HL7 v2 feeds re-pointed at one canonical FHIR model, migrated in waves with both paths live during each cutover.
52
interfaces
0
downtime
Multi-site
A canonical layer across independent hospitals
Facilities sharing no infrastructure and no vendor, kept consistent through one FHIR model — reconciled continuously rather than overnight.
Live
not overnight
Multi
vendor
FAQ
The Questions Engineers Ask.
If yours isn't here, it's a better use of a call than an email.
Should we build a FHIR server or buy one?
Buy the repository, build the mapping. Storage, search indexing and the REST surface are solved problems with good open-source and commercial options — writing your own is rarely where your product's value is. What nobody can sell you is the mapping from your data to the profiles your customers expect, and the operational discipline around it. That's the part worth your engineering.
Can we skip R5 and go straight to R6?
That's what we'd recommend for most teams. R5 has breaking changes and adoption that never arrived, so building there buys incompatibility with the systems you need to talk to. R6 is still balloting and regulatory adoption follows separately. Build on R4, keep your mapping layer separable, and the eventual move becomes a translation exercise rather than a rewrite.
Does supporting FHIR mean we're certified?
No — and the distinction matters commercially. Certification is a specific criterion tested with specific tooling against specific profile versions. Plenty of systems speak FHIR correctly and would not pass. If a customer's procurement asks about the standardised API criterion, they're asking a narrower question than "do you support FHIR", and answering the broad question invites a follow-up you don't want.
Why is our FHIR API slow when the database is fast?
Usually one of three things: a façade re-mapping on every request, an
_include quietly multiplying the result set, or offset pagination degrading as clients page deeper. All three are architectural rather than tuning problems, which is why they don't respond to adding hardware. We'd want to see one slow request traced end to end before saying which it is — it's normally obvious within a day.We sell to payers. How urgent is CMS-0057-F?
The APIs must be live in production by 1 January 2027, on FHIR R4 with SMART authorisation. Working back from that through build, testing and a customer's own review, teams that haven't started scoping are already inside a tight window. The good news is it doesn't require replacing your claims stack — X12 278 remains permitted underneath, so this is a FHIR surface over what you have.
Do we get locked in?
No. It's built in your environment and your repository, and you get the source, the profiles and the documentation. Ongoing support is something you choose because it's easier, not because you have no alternative. Teams do take it back in-house, and that's a fine outcome.
Tell Us What You're Building on FHIR.
We'll tell you which architecture fits your volumes, what conformance you actually need, and a realistic date. Reviewed by an engineer who has passed the tests, not a sales queue.
+1 (669) 649 0706
hello@nirmitee.io
USA
Iselin,
NJ 08830
India
Baner, Pune,
Maharashtra 411045
Thanks — we've got it.
You'll hear back within one business day, from someone who has built this.