FHIR Integration Services

"Integration" is used loosely in this market. For scoping purposes it helps to separate it from adjacent services: building your own FHIR API is FHIR API development, standing up a data store is FHIR server development, and integration is the work of making two or more systems exchange FHIR data reliably. Typical deliverables are:

• Integration specification: which resources, operations and search parameters each side uses, the profiles they must conform to, and what happens on partial or failed exchanges.
• Authorization setup: app registration with each counterparty, SMART scopes, client credentials or JWT key pairs, and secret rotation procedures.
• Client or connector code: reading, searching, writing and paging FHIR resources, usually wrapped in a service that isolates EHR-specific behavior from your core product.
• Data mapping layer: translating between your internal model and FHIR resources, including code systems such as LOINC, SNOMED CT, RxNorm and ICD-10-CM.
• Test evidence: validation against the target profiles, sandbox test runs, and production cutover checklists.
• Runbooks: what to monitor, how to reprocess failures and who to call at the counterparty when something breaks.

Most projects fall into one of a handful of patterns. Naming the pattern early tells you which specs matter and which skills your partner needs. For background on the API mechanics, see our FHIR API integration guide.

Timelines depend far more on the counterparty than on coding effort. App registration, security review and production credential issuance at a health system can take longer than the build itself.

1. Discovery: confirm the use case, the systems involved, the FHIR versions and IGs each supports (read their CapabilityStatement), and contractual access requirements.
2. Specification: document resource mappings, search strategies, paging limits, error semantics and data volumes.
3. Sandbox build: implement against vendor sandboxes or a local HAPI FHIR instance loaded with synthetic data.
4. Conformance and security testing: validate payloads against profiles, test token expiry and refresh, and exercise failure paths.
5. Customer-specific onboarding: each health system may have its own build, enabled resources and approval steps.
6. Go-live and hypercare: monitored rollout with a short period of heightened support before handover to steady-state operations.

Two integrations that look identical on a slide can differ widely in effort. The usual drivers are:

• Number of counterparties and EHR platforms. An integration with one Epic customer does not automatically work for the next, and a second platform such as Oracle Health means a second set of behaviors.
• Search and paging behavior. Servers differ in supported search parameters, page sizes and `_include` support. Robust clients follow the `next` link in Bundle responses rather than assuming one page.
• Data quality. Real records have missing codes, free-text units and duplicated entries. Mapping logic needs explicit rules for each.
• Identity matching. Linking a FHIR Patient to your own user or member record is often the hardest part of a patient-facing integration.
• Rate limits and volume. High-frequency polling may be throttled; population use cases usually belong on Bulk Data.

GET /fhir/R4/Observation?patient=12345&category=laboratory&date=ge2026-01-01&_count=100
Authorization: Bearer eyJhbGciOi...
Accept: application/fhir+json

Generic API experience is not enough. Ask questions that reveal whether a team has shipped FHIR integrations into production, not just demos. Our directory of FHIR integration companies is a starting point for a shortlist.

• Which EHR platforms have you integrated with in production, and did those integrations involve read only or also write-back?
• How do you isolate EHR-specific behavior so that adding a second platform does not mean rewriting the integration?
• Show us how you validate payloads against US Core or other target profiles during CI.
• How do you handle token expiry, 429 responses, partial Bundle failures and OperationOutcome errors?
• Who owns the counterparty relationship during app registration and security review, you or us?
• What do you hand over at the end: code, infrastructure-as-code, runbooks, test suites?

Integration work is usually sold as a fixed-scope project per integration, as time-and-materials for open-ended programs, or bundled with a platform subscription when the vendor sells an integration product. Fixed price works when both counterparties and the resource set are known; it becomes risky when health-system onboarding steps are outside either party's control.

Budget is driven by the number of distinct EHR platforms, read versus write scope, data volume, terminology mapping depth and ongoing support expectations. For illustrative planning ranges and a breakdown of these drivers, see the FHIR integration cost guide. Plan separately for run costs: monitoring, credential renewal and EHR upgrade testing continue after go-live and are often covered by a support and maintenance agreement.