FHIR integration services · United States
FHIR R4 APIs, SMART on FHIR apps, bulk data pipelines and CDS Hooks services for health tech products, payers and providers. We build to US Core 6.1.0 and SMART App Launch 2.0, put FHIR facades over systems that never spoke it, validate every profile and prove conformance with Inferno before your customers test it.
A database, an HL7 v2 feed, a legacy EHR or an existing API holds the clinical data.
Map to US Core profiles, bind LOINC, SNOMED CT and RxNorm, authorize with SMART and validate every resource.
EHR-launched apps, patient apps, payers and analytics read by REST, bulk export or CDS Hooks.
The short answer
Nirmitee designs, builds and tests FHIR integrations for health tech companies, payers and providers. We build FHIR R4 APIs that conform to US Core 6.1.0, SMART on FHIR apps and backend services on SMART App Launch 2.0 with granular scopes, bulk data export pipelines, CDS Hooks services and FHIR facades over legacy databases and HL7 v2 feeds. We validate every resource against its profile, run the ONC Inferno test kits and publish our own work openly: our headless EHR passes all 47 (g)(10) SMART App Launch tests and our Da Vinci CRD, DTR and PAS servers are public with their Inferno results.
FHIR standards
Published and required are different things. These are the versions US buyers are held to in 2026 and what each one means for your build.
| Standard | Version | What it covers | What we design for |
|---|---|---|---|
| FHIR R4 | 4.0.1 | The base release used by US regulation, EHR APIs and payer APIs | R4 as the contract, with the mapping layer kept separate so R5 or R6 later is a translation, not a rewrite |
| US Core | 6.1.0 (USCDI v3) | Profiles, must-support elements and search parameters for US clinical data | The version required for ONC (g)(10) certification from 1 January 2026, with must-support handled as optional data, not guaranteed data |
| SMART App Launch | 2.0 | OAuth 2.0 authorization for EHR launch, standalone launch and backend services | Granular v2 scopes such as patient/Observation.rs, PKCE, asymmetric client authentication and token introspection |
| Bulk Data Access | Flat FHIR $export | Asynchronous export of populations as NDJSON at system, Group and Patient level | Backend services authorization, _since for incremental exports and pipelines that isolate export from live traffic |
| CDS Hooks | 2.0 | Decision support services called from the EHR at points such as patient-view and order-sign | Response time budgets, prefetch templates and cards that clinicians act on |
| Da Vinci guides | CRD, DTR, PAS, PDex | Prior authorization and payer data exchange under CMS-0057-F | Payer APIs due from January 2027, with CRD on CDS Hooks and PAS mapped to X12 278 |
| HL7 v2 to FHIR | v2-to-FHIR guide | Mapping ADT, ORU, ORM and other messages to FHIR resources | Event feeds in v2, queries in FHIR, one model underneath |
R5 (5.0.0) is published and R6 is in ballot, but US regulation and EHR APIs run on R4. We build R4 today and keep the path to later releases open.
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.
A hybrid is the right 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 costs far less than arriving at it after a rebuild.
The wrong way to arrive at an answer is to start coding before this conversation has happened. We settle it in the first two weeks, in writing.
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.
One patient, now. The default, and the right answer more often than people admit.
Anything driven by a user looking at one patient. Chart views, decision support, a clinician opening your app. Latency matters, volume doesn't.
_include and _revinclude quietly turning one call into thousands of rows_lastUpdated because nobody built subscriptionsDesign 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.
$exportPopulations, not patients. Analytics, quality measures, risk, training data.
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.
_since was never wired upIncremental 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.
“Tell me when something changes”: the pattern people assume exists, and often can't get.
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.
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.
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.
Your app opening inside the chart, already knowing the patient and the user.
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.
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.
Include these scenarios in testing; successful sandbox requests alone do not establish production readiness.
Everything is fast against sandbox data. The first real patient has 900 Observations and eleven years of history, and the chart view times out.
A conformant server returns nothing for an element the UI assumed was always present. Blank screens, and an argument about whose bug it is.
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.
Offset paging works for three pages and collapses at three hundred. Usually found by whoever built the export, at the worst moment.
The same person arrives under different identifiers from different systems, and quietly becomes two patients in your product.
An over-broad scope set sails through development and fails a customer's security review after the registration has been locked.
What we build
Pick the workstreams your product needs. Each ships with a specification, tests and an owner.
Conformant R4 APIs on HAPI FHIR, a managed FHIR store or your own service, with US Core profiles, search parameters, paging and a CapabilityStatement that tells the truth.
FHIR R4 · US Core 6.1.0 · CapabilityStatement
US Core implementation guide →A FHIR API in front of a database, legacy EHR or HL7 v2 feed, mapping on request or on ingest depending on latency, search and bulk export needs.
Facade · repository · hybrid · HL7 v2 to FHIR
FHIR facade architecture guide →EHR-launched and standalone apps and backend services on SMART App Launch 2.0, with the smallest scope set that supports the workflow and app listing support for Epic and Oracle Health.
SMART v2 · PKCE · private_key_jwt · OpenID Connect
Epic SMART on FHIR →Incremental $export pipelines into your warehouse or lakehouse, with resumable downloads, checksums and de-identification where analytics needs it.
$export · NDJSON · _since · Group
Bulk FHIR export from Epic, Oracle Health and athenahealth →Decision support services called from the EHR at patient-view, order-select and order-sign, including Da Vinci CRD coverage requirements discovery.
CDS Hooks 2.0 · prefetch · cards · CRD
Building your first CDS Hook for Epic and Oracle Health →Profile validation in CI with the HL7 validator, Inferno test kit runs for (g)(10), US Core and Da Vinci guides, and realistic synthetic patients for load testing.
HL7 validator · Inferno · Touchstone · Synthea
Testing a FHIR API with Inferno →Buyer decisions
Buy the storage, build the mapping. These are the options we deploy most often, and where each one fits.
| Option | Best fit | Strengths | What to plan for |
|---|---|---|---|
| HAPI FHIR (open source) | Teams that want full control and run Java | Complete R4 server, validation and search, widely used | You run it: database tuning, upgrades and on-call |
| Managed FHIR store (AWS HealthLake, Google Cloud Healthcare API, Azure Health Data Services) | Teams already on that cloud | Managed scaling, bulk export and integration with the cloud's analytics | Each service's search and profile support, and cloud lock-in |
| Commercial FHIR server | Payers and large platforms with complex conformance needs | Vendor support, advanced search and tooling | License cost and the vendor's roadmap |
| FHIR facade over your database | Products whose data already lives in their own model | One copy of the data, always current | Latency, limited search and expensive bulk export |
| Interoply (our platform) | Products that need FHIR, HL7 v2 and X12 behind one API | Mapping, connectors and monitoring in one place | Fit with your hosting and data residency rules |
The architecture decision (facade, repository or hybrid) matters more than the server brand. We decide it with you on your data and volumes before anyone writes code.
Integration boundaries
FHIR projects stall on access and ownership, not code. We write the split down first.
Epic, Oracle Health, athenahealth and others own app registration, scopes and production enablement, and each health system decides whether to turn your app on. We prepare the registration, security review answers and test evidence.
Owns the data model and the workflow. We map every field your product needs to a profile and list the ones FHIR does not carry.
Server or facade, profiles, mapping, terminology, SMART authorization, validation, bulk export and monitoring. Defects in this layer are ours to fix.
ONC certification is granted through an accredited test lab, and CMS-0057-F obligations are confirmed by your compliance team. We build and test to the named guides and hand over the Inferno evidence.
We sign a BAA, design least-privilege scopes, encrypt in transit and at rest, and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything below lands in your repository and your runbook.
Facade, repository or hybrid, decided on your data, volumes and roadmap, in writing.
Every required field mapped to a resource, profile, element and terminology binding.
Server or facade configuration, mappings, SMART setup and infrastructure as code.
HL7 validator results in CI and Inferno test kit reports for the guides in scope.
Load tests with realistic patients, paging, _include limits, token expiry and outage behavior.
Endpoint documentation for your customers, monitoring, alerts and an upgrade plan for new US Core versions.
Delivery phases
A US Core FHIR API over existing data typically takes 10 to 16 weeks. A SMART app connecting to one EHR typically takes 6 to 10 weeks, and the EHR's app review sets much of that date.
Weeks 1 to 3
Architecture decision, mapping inventory, profile and version choices agreed
Weeks 3 to 10
Server or facade, mappings, SMART authorization and bulk export built with validation in CI
Weeks 8 to 13
Inferno runs, realistic load tests and security review answers prepared
Weeks 12 to 16
Production enablement with the EHR or customer, monitoring live and runbook handed over
Cost drivers
You get a fixed scope and price after one scoping call. These are the factors that move it.
The number of US Core or Da Vinci profiles in scope drives mapping and testing effort.
Clean, coded source data maps quickly; free text and local codes need terminology work.
A facade, a repository with ingest and backfill, or a hybrid each carry different build and run costs.
REST reads, bulk export, subscriptions and CDS Hooks each add their own design and tests.
App reviews with EHR vendors and (g)(10) or payer conformance testing add formal cycles.
Server licensing or cloud costs, monitoring and on-call are priced per environment.
Proof
Client names are withheld. The code and test results linked here are public.
Our open-source headless EHR serves FHIR R4 and passed all 47 tests in the ONC (g)(10) SMART App Launch STU2 standalone patient app scenario in Inferno on 11 June 2026, including SMART v1 and v2 scopes and asymmetric client authentication.
View the headless EHR on GitHub →Open-source servers for coverage requirements discovery on CDS Hooks, documentation templates and prior authorization support, tested with the Inferno Da Vinci test kits.
View the CRD server on GitHub →For a digital health company we built a provider platform in which every patient, appointment, care plan, lab result and invoice is a standard FHIR resource on a FHIR server, with no private schema.
Our platform runs FHIR, HL7 v2 and X12 connectors behind one API, with mapping, monitoring and replay built in.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
FHIR integration services design, build and test the connections that exchange healthcare data using HL7 FHIR. The work covers architecture, mapping your data to FHIR resources and US Core profiles, terminology binding, SMART on FHIR authorization, bulk export, CDS Hooks, validation, conformance testing with Inferno, EHR app registration and production monitoring.
Build to FHIR R4 (4.0.1). For US clinical data use US Core 6.1.0, which ONC (g)(10) certification requires from 1 January 2026 alongside USCDI v3 and SMART App Launch 2.0. Payer APIs under CMS-0057-F add the Da Vinci guides. R5 and R6 are not used by US regulation or EHR APIs today.
Buy or adopt the server and build the mapping. HAPI FHIR, managed cloud FHIR stores and commercial servers solve storage, search and the REST surface. The part no one can sell you is the mapping from your data to the profiles your customers expect, and the operational discipline around it.
A FHIR facade is an API that translates FHIR requests into queries against your existing database or system on every call. It keeps one copy of the data and is always current, but inherits the source's latency and makes rich search and bulk export expensive. A repository that maps on ingest suits scale, search and export. Many production systems use a hybrid.
SMART on FHIR is the OAuth 2.0 based authorization framework for apps that launch inside an EHR, run standalone for patients or act as backend services. SMART App Launch 2.0 adds granular scopes such as patient/Observation.rs with category filters, requires PKCE and supports token introspection. Asking for the minimum scopes is the fastest way through an EHR's security review.
Bulk export is asynchronous. A backend service calls $export at the system, Group or Patient level, polls a status endpoint and then downloads NDJSON files per resource type. Production pipelines use _since for incremental exports, resume interrupted downloads and keep export load away from live traffic.
CDS Hooks let the EHR call an external decision support service at defined points in the workflow, such as opening a chart (patient-view) or signing an order (order-sign), and show the response as cards. Da Vinci CRD uses CDS Hooks for payer coverage requirements discovery under CMS-0057-F.
No. ONC certification is granted through an accredited test lab against specific criteria, such as (g)(10) standardized API access, with specific profile versions. We build to those criteria and run the same Inferno test kits the labs use so the formal test holds no surprises.
Every resource is validated against its profile in CI with the HL7 validator. We run Inferno test kits for (g)(10), US Core and Da Vinci guides, load test with realistic synthetic patients rather than three-resource test patients, and test paging, _include limits, token expiry and outages.
A US Core FHIR API over existing data typically takes 10 to 16 weeks. A SMART app connecting to one EHR typically takes 6 to 10 weeks, with the EHR's app review setting much of the date. Bulk export pipelines and CDS Hooks services fall between those.
Cost depends on the resources and profiles in scope, source data quality, the architecture, the access patterns, EHR and certification testing, and hosting and support. We give a fixed scope and price after one scoping call.
No. Everything is built in your environment and your repository, and you get the source, the profiles, the mapping inventory and the documentation. Teams take the work in-house, and that is a fine outcome.
Next step
An engineer who has passed these tests replies with the architecture that fits your volumes, the conformance you need and a fixed scope.
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.
Iselin,
NJ 08830
Baner, Pune,
Maharashtra 411045
You'll hear back within one business day, from someone who has built this.