01
Architecture review
Façade, repository or hybrid — decided on your data, your volumes and your roadmap, in writing.
Scope-ledFixed price
FHIR Integration Services
Clinical data your product can actually use.
Build FHIR APIs around the workflows you need to deliver. We help healthcare product teams choose the right architecture, map clinical data, validate profiles and prepare the integration for production.
For healthcare product leaders, engineering teams and health IT teams.
- 01
Source systems
EHR records · HL7 feeds · existing databases
- 02
Map and validate
Resources · terminology · agreed implementation guide
- 03
Deliver through FHIR
Authorized API access · search · error handling
Your product receives structured, traceable clinical data.
Illustrative delivery path · no patient dataClear scope.
Tangible deliverables.
01Architecture decision record
02Resource and profile mapping
03Validation and operating plan
What should we prepare for a FHIR integration scoping call?
Bring your target workflow, source-system details, required data elements and any implementation-guide requirements. Use synthetic or de-identified examples, never patient data in the enquiry form. We can then identify architecture choices, access dependencies and validation scope.
Technical reference: HL7 FHIR R4 overview ↗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
A published release used by many healthcare APIs. Confirm the release and implementation guide supported by your counterparty.
Match the target environment. Version selection follows the agreed API contract and applicable requirements.
FHIR R5published release
A separate FHIR release with differences from R4. Publication does not imply that a customer has implemented it.
Validate compatibility. Use it when the agreed use case and counterparties support it; plan any conversion explicitly.
Future releasesversion planning
Track the official release directory and implementation-guide status. Do not treat a draft or ballot as a production commitment.
Keep version boundaries explicit. Assess resource, profile and workflow changes before upgrading. Official FHIR release directory →
US Corethe certification floor
US Core profiles and certification requirements are version-specific. Record the applicable guide and criteria rather than assuming the latest publication is required.
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.
Check the profile’s cardinality and must-support rules. Handle permitted missing data explicitly in the product.
The deadline that's driving budgets
Payer APIs: scope the rule before the build.
CMS-0057-F introduces API development and enhancement requirements for impacted payers, with compliance dates generally beginning January 1, 2027. Applicability and timing vary by payer category; confirm them with your compliance team.
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
Plan request submission, status and decision exchange. Confirm the applicable response-time requirements separately from the API implementation.
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.
CRD, DTR and PAS describe implementation patterns, not four interchangeable mandates. Confirm the required standards and scope against the CMS final-rule fact sheet.
What breaks in production
Six failure modes to design for.
Include these scenarios in testing; successful sandbox requests alone do not establish production readiness.
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 doImplement the profile’s actual cardinality and must-support rules, and handle permitted missing data explicitly.
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.
Scope-ledFixed price
03
SMART app or backend service
Launch inside the chart, or server-to-server. Scope design, conformance validation, and the customer review.
Scope-ledFixed 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 API work needs its own scope. Confirm the applicable CMS requirements, implementation guides and deadlines with your compliance team before committing to a delivery plan.
Delivery acceptance
Make the data contract testable.
Agree on these outputs during scoping. Your team should know what it will receive and how to review it.
Resource coverage
A mapping inventory connecting your required clinical fields to resources, profiles and terminology.
Conformance evidence
Agreed validation results, representative test payloads and documented exceptions—not a blanket certification claim.
Production behaviour
Tests for authorization, search, pagination and failure handling, matched to the endpoint and workload.
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 — the trace and workload evidence guide the investigation.We sell to payers. How urgent is CMS-0057-F?
CMS describes API compliance dates generally beginning January 1, 2027 for impacted payers. Your specific deadline and obligations depend on the payer category and applicable provisions. Confirm those with your compliance team, then scope data access, implementation, testing and operational readiness.
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.