Build vs buy is really a complexity decision
A healthtech company evaluating EHR integration often starts with what sounds like a simple question: "How do we connect our application to the EHR?" The answer that comes back from engineering is rarely simple.
A production EHR integration involves patient identity matching, SMART on FHIR authorization flows, FHIR resource mapping, legacy HL7 v2 message handling, clinical terminology normalization (ICD-10, SNOMED, LOINC, RxNorm), data quality handling for missing or inconsistent fields, retry logic, error handling, audit logging, monitoring, EHR-specific implementation differences, changing API versions, sandbox testing, and ongoing operational support. A single integration with one EHR is manageable. A strategy spanning five or more EHR ecosystems, each with its own implementation quirks, is a sustained engineering capability.
This is the underlying problem that middleware is designed to address. But "FHIR support" from a middleware vendor does not mean the hard work disappears. It means the location of that work shifts.
The standards environment matters here. Under the 21st Century Cures Act, ONC requires FHIR R4 APIs in certified EHR systems for patient and provider data access. The HTI-1 Final Rule, which brought updated US Core Implementation Guide and USCDI v3 requirements, has compliance requirements taking effect January 2026. These regulatory developments have meaningfully expanded the FHIR API surface area of major EHRs, which changes the feasibility of both custom integration and middleware-based approaches compared to even two years ago.
It is worth being precise about what these requirements cover. They apply to EHR certification and to specific payer API obligations. CMS's Interoperability and Prior Authorization Final Rule (CMS-0057-F, finalized January 17, 2024) requires certain impacted payers, not all providers, to implement specific FHIR APIs by compliance dates beginning January 2026 for operational provisions and January 2027 for API requirements, with exact dates varying by payer type. These are payer-specific mandates. They do not translate directly into a requirement for every healthcare application or provider organization to adopt FHIR in a particular way.
What EHR/FHIR middleware actually does
"Middleware" in the healthcare integration space is not one category of product. Buyers encounter overlapping but distinct approaches: integration platforms and iPaaS tools, healthcare interface engines (which handle HL7 v2 alongside FHIR), FHIR servers, FHIR transformation layers, EHR-specific connector platforms, interoperability platforms, and API gateways. Understanding what any specific product covers is a prerequisite to evaluating it.
Broadly, a healthcare integration middleware layer does some combination of the following:
The middleware layer handles authentication and authorization (OAuth 2.0, SMART App Launch, backend service authorization), transformation between standards (FHIR R4, HL7 v2, C-CDA), data normalization, patient identity matching, routing, retries, error handling, logging, and in many cases monitoring and operational dashboards. It abstracts some of the EHR-specific differences behind a more uniform API your application can call.
What middleware does not do automatically is eliminate EHR-specific work. Each EHR implements FHIR resources differently, supports different resource types, enforces different permission scopes, and may require different implementation guides or profile constraints. An organization using middleware still needs to configure connectors, map data fields, write workflow logic, handle edge cases, and test against each EHR environment. The middleware reduces repeated infrastructure plumbing; it does not eliminate clinical and workflow-specific engineering.
What "custom integration" actually means
Custom integration is not a single approach. The scope varies considerably, and understanding what level of custom work a project actually requires is necessary before evaluating the build side of the comparison.
A custom connector builds the connection to one EHR or one interface. This is the narrowest form: a specific API client, FHIR resource handler, or HL7 parser for a single target system.
A custom integration service builds transformation, orchestration, authentication, routing, and workflow logic for one or more connections. This is meaningfully more complex than a single connector and becomes the beginning of an internal integration capability.
A custom interoperability layer builds a reusable internal platform that supports multiple EHRs, multiple standards, and multiple application consumers. This is the equivalent of building middleware, and it carries commensurate engineering costs and ongoing maintenance obligations.
A hybrid approach purchases infrastructure connectivity, FHIR transformation, or authentication handling from a vendor while building the healthcare-specific workflow, business logic, and application-layer functionality internally. This is often the most realistic choice for companies whose integration requirements exceed what a single middleware product covers but do not justify rebuilding the full connectivity stack.
The real tradeoffs: a direct comparison
| Decision factor | Buy middleware | Custom integration |
|---|---|---|
| Initial build effort | Usually lower; vendor provides connectivity infrastructure | Usually higher; all components require development |
| Time to first integration | Potentially faster if pre-built connectors exist for your EHR target | Usually slower; no existing connectors to start from |
| Control over integration behavior | Platform-dependent; some platforms are highly configurable, others constrain workflow | High; full ownership of every layer |
| Custom workflow support | May require workarounds or vendor professional services for unusual workflows | Full flexibility; build exactly what the workflow requires |
| Multi-EHR expansion | Faster if pre-built connectors exist; verify actual coverage before assuming | Requires engineering effort for each new EHR target |
| Maintenance ownership | Shared with vendor, but organization still configures, maps, and maintains application-layer logic | Fully internal; every change, version update, and fix is your team's responsibility |
| Vendor dependency | Higher; pricing changes, platform direction, and sunset decisions affect your integration | Lower; no external dependency on the integration stack |
| Internal expertise required | Lower at the connectivity layer; may still require FHIR and HL7 expertise for configuration | Higher; requires deep FHIR, HL7 v2, EHR-specific, and security engineering expertise |
| Monitoring and observability | Often built into the platform; operational dashboards typically included | Must be designed, built, and operated by the internal team |
| Migration away | May require significant rework if vendor-specific APIs or configurations are deeply embedded | More control; migration is an internal engineering decision |
| Long-term TCO | Depends on licensing, usage volume, connector count, and support tier; can exceed build costs at scale | Depends on engineering footprint, maintenance load, and operational overhead |
The cost model buyers should actually use
The most common mistake in the build vs buy calculation is comparing middleware subscription cost against developer salary. That comparison omits most of the relevant cost on both sides, and it consistently underestimates the long-term cost of custom development while underestimating the operational cost of middleware at scale.
The relevant comparison is 3-5 year total cost of ownership, not implementation cost alone.
| Buy: TCO considerations | Build: TCO considerations |
|---|---|
| Platform subscription (often scales by connections, volume, or users) | Engineering salaries, including FHIR and HL7 specialist time |
| Per-connector or per-EHR licensing fees | Architecture and design investment up front |
| Transaction or API call volume charges | Infrastructure (servers, messaging queues, storage, monitoring tools) |
| Implementation and onboarding services | Security design and testing, including penetration testing where applicable |
| Mapping, configuration, and workflow customization | EHR-specific testing and sandbox access |
| Vendor professional services for non-standard workflows | Integration maintenance as EHR APIs and implementation guides evolve |
| Support tier costs for production SLAs | Incident response and on-call operational support |
| Internal engineering time for configuration and integration management | Documentation, training, and knowledge transfer |
| Migration or exit costs if you move away from the platform | Technical debt remediation as requirements change |
When buying middleware usually makes more sense
Buy middleware when: your organization needs connections to multiple EHRs and does not want to build connector infrastructure for each one; your primary goal is reducing time to production; your team has strong software engineering capability but limited healthcare interoperability depth; your integration use cases are relatively standard (patient data access, scheduling, document retrieval); you want built-in operational tooling for monitoring, retries, and alerting; or your engineering resources are more valuable concentrated on your core product than on interoperability plumbing.
Before selecting middleware, verify that the platform's actual production connector coverage matches your specific EHR targets. "We support Epic" and "we have a production-tested FHIR R4 connector for Epic with US Core compliance, write-back capability for the resource types your workflow requires, and SMART Backend Services support" are materially different statements. Ask for production references from organizations using the specific connectors you need, not general platform references.
When custom integration makes more sense
Build custom integration when: your workflow requirements are highly specialized and unlikely to be supported by a general-purpose platform; you need a small number of strategically important integrations (one or two EHRs, long-term relationships); your integration layer is itself a source of competitive differentiation in your product; you have strict performance or latency requirements that a middleware layer would compromise; your team already has deep FHIR and HL7 expertise; or you are building a platform that will itself become an integration product for others.
Custom integration can be strategically justified when the integration layer is part of the product's differentiation. But the principle holds: once you build it, you own it. That means owning every future EHR API version change, every security update, every new standard requirement, and every monitoring and incident response obligation.
The hybrid approach: buy the plumbing, build the product layer
Many production healthcare integration architectures are neither pure middleware nor pure custom development. They are deliberate hybrids. A company purchases lower-level connectivity, FHIR transformation, and authentication infrastructure from a vendor while building the healthcare-specific workflow, business logic, and application-layer functionality internally.
The architecture looks something like this:
In this model the company avoids rebuilding commodity infrastructure: SMART on FHIR authorization flows, retry mechanisms, operational dashboards, connector maintenance. The engineering investment focuses on the layers that create product value: the clinical workflow, the proprietary decision logic, the user experience, the data model that differentiates the application.
The hybrid approach requires careful boundary design. Where does the middleware's responsibility end and the custom layer begin? That boundary should be defined before procurement, not discovered during implementation. If the core workflow requires capabilities that sit inside the middleware platform's configuration layer rather than in custom code above it, the organization may end up dependent on vendor feature development rather than its own engineering roadmap.
The hybrid approach is often the right starting point for healthcare SaaS companies moving from their first EHR connection toward a multi-EHR strategy. It does not, however, eliminate the need for healthcare software engineering expertise. The custom layers still require FHIR knowledge, clinical workflow understanding, security design, and testing against real EHR environments.