The national plumbing for health data finally carries real volume. The number of health records exchanged through TEFCA, the federal framework that links health information networks, grew from 10 million to more than 1 billion in less than a year, according to ONC’s June 2026 announcement. Your product is still not connected to any of it. Between those networks and the screen a clinician works on sits a decision: rent a healthcare interoperability platform, or build a custom integration against the systems you need.
Nearly every page that ranks for this question belongs to a company selling one of the two answers. Below you will find what the label covers (three different products share it), how the options differ on price, speed and exit cost, and which signals should decide it. A platform buys breadth and a custom integration buys depth, so the answer depends on how many systems you must reach and how far into each one you need to go. We sit on the build side as a custom healthcare software development company, so weigh our view accordingly. For plenty of the products we scope, a platform is still the right first step.
Four ways healthcare software gets connected
Vendors attach the label healthcare interoperability platform to three unrelated products, and a buyer comparing one against a custom build is often comparing against the wrong one. Integration and interoperability are separate jobs to begin with, as we explained in our guide to medical device integration.
A healthcare interoperability platform is software that moves clinical data between systems that were never designed to talk to each other, handling transport, format translation and patient matching so your team does not hand-write every connection. The name covers integration engines, unified APIs and access to national networks, and each solves a different problem.
Integration engines for hospital message traffic
A healthcare integration engine is middleware inside a health system that routes messages between its own systems: the EHR, the lab, radiology, billing, the pharmacy. Rhapsody (which also sells the Corepoint engine), Infor Cloverleaf, InterSystems HealthShare and Mirth Connect are the familiar names. Most of the traffic is HL7 v2, the event-message format hospitals have run on for more than three decades. The engine receives a message, reshapes it for the destination and retries when the destination is down.
Hospital IT buys these, and a digital health company usually meets one from the outside, as the thing its interface plugs into. Anyone running their own engine also learns that the license is the small part of the cost. The interface analyst who builds and maintains the channels is the large one.
The economics shifted in March 2025, when NextGen moved Mirth Connect to a commercial-only license with version 4.6. For years it had been the free, open-source default. Teams that built on “free” found a license negotiation in their next budget.
Unified APIs that reach many EHRs
A unified API gives you one interface and translates it into whatever each EHR speaks on the other side. Redox, Health Gorilla and Particle Health come up most often: Redox connects software vendors to health system EHRs, Health Gorilla focuses on FHIR-based record access (it is also a designated TEFCA network), and Particle pulls patient records from national networks.
Most people searching for a healthcare interoperability platform picture this product, and it answers a familiar problem for digital health founders. Your first ten customers run six different EHRs. Writing six integrations before the product has proven itself wastes money, so you integrate once with the platform and each new health system becomes a configuration project.
Each health system still grants access on its own terms: it approves your connection, signs its own agreements and runs its own security review. The platform's reach also ends at the edge of its supported EHR list.
National networks for record retrieval
The third product is access to national exchange: TEFCA, run through designated Qualified Health Information Networks, plus the older Carequality and CommonWell frameworks. They answer one question well. Given a patient, where else were they treated, and can you get those records? Retrieval is query-based and mostly read-only, and what comes back is often a C-CDA summary document that you still have to parse and reconcile.
You rarely connect to these networks directly. You go through a participant, often one of the unified APIs above, while federal pressure keeps building: more than 60 companies signed CMS pledges in July 2025 to deliver on its new interoperability framework in early 2026. Record retrieval still does not put a blood pressure reading into a chart, and that write step is what many products need.
Custom integration, built against one system
The fourth route has no product name, so it rarely appears on lists of healthcare interoperability solutions. You write code against one specific counterpart: a SMART on FHIR app that launches inside a clinic's EHR, an HL7 v2 feed from a hospital's engine over a VPN, a vendor's own REST API, or, more often than anyone likes to admit, a nightly file dropped on a secure file server. You own the code, the data mappings and every future change.
Across twenty EHRs that is expensive. Against one or two well-documented counterparts it is a finite piece of work.
| Integration engine | Unified API | National network access | Custom integration | |
|---|---|---|---|---|
| What it does | Routes and transforms messages inside a health system | One API translated into many EHRs | Retrieves records from other organizations | Connects to one system exactly as you need |
| Typical buyer | Hospital or lab network IT | Digital health vendor | Care coordination and record-retrieval products | Product team with one or two key counterparts |
| Main standards | HL7 v2, CDA | FHIR on your side, whatever the EHR speaks on theirs | C-CDA documents, FHIR growing | Whatever the counterpart speaks |
| Pricing shape | License per server plus analyst time | Annual contract by connections and volume | Per query, or bundled into a platform | Build cost plus 15–20% a year for maintenance |
| What you still build | Channels and mappings | Your data model, workflows and UI | Document parsing and reconciliation | Everything, and you own it |
Healthcare interoperability platform vs custom integration: the trade-offs
Put side by side, the two options part ways on four things. Cost as you grow, time to the first live connection, the standards spoken on the other end and the price of leaving decide more healthcare interoperability platform choices than any feature list.
Pricing models and the cost of growth
Vendors rarely publish prices, so procurement data is the best public benchmark. Vendr's figures for Redox, updated in February 2026, put the median buyer at $52,500 a year, with contracts running from about $12,000 to $148,000. Connection count and message volume drive where you land.
| Cost line | Unified API platform (Redox, per Vendr) | Custom integration |
|---|---|---|
| Getting started | Implementation fees of $10,000 to $50,000+ | Build cost, set mostly by the counterpart's API and documentation |
| Every year | Annual contract, median $52,500 | 15–20% of the build cost in maintenance |
| A new customer on a supported EHR | Configuration, then a higher tier as connections grow | A new integration project |
| A system the vendor does not support | Custom connector at $5,000 to $25,000+ | The same work as any other integration |
| Growth in volume | Overage fees and 3–7% yearly price increases | Infrastructure cost |
A custom integration is priced by the counterpart more than by your feature list. A documented FHIR API with read-only scope sits at the small end. A bidirectional HL7 v2 feed with a hospital, several data types and a slow-moving IT department sits far above it, and much of that gap is calendar time spent waiting and testing. Our breakdown of what healthcare software costs to build shows where integrations sit inside a full project budget.
Platform cost follows your success. Every new health system and every extra batch of messages adds to the bill, while a custom integration costs about the same whether it carries 100 patients or 100,000. A healthcare interoperability platform can be the cheapest option in year one and the largest line in the budget by year four. Model that crossover with your own growth numbers before you sign a multi-year contract.
Time to the first live connection
Speed is the strongest argument for a healthcare interoperability platform. If the health system runs an EHR the vendor already supports, ideally with another of the vendor's customers live, the first connection can go live in weeks.
A custom integration against the same EHR usually takes months. Some of that is engineering. Most of it is process: the EHR vendor's developer program, sandbox access, the health system's security questionnaire, a business associate agreement (BAA), test patients, a go-live window. Even directories assume you are already through the door: Epic's Connection Hub, the paid listing that helps health systems find your product, is open only to vendors that already have a working connection to Epic.
Security review and contracting sit on the platform path too. A platform shortens the technical part and leaves the organizational part roughly where it was, so when a hospital takes three months to return a questionnaire, switching vendors will not move that date.
HL7 v2, FHIR and the write-access problem
FHIR gets most of the attention, and in the US it has earned some of it. More than 95% of certified health IT developers met the Cures Act deadline of 31 December 2022, which included shipping standardized FHIR-based APIs to their customers. Payers are next: the CMS Interoperability and Prior Authorization rule requires Medicare Advantage, Medicaid, CHIP and federal marketplace plans to run four FHIR APIs, prior authorization among them, by 1 January 2027.
The traffic still runs mostly on the older standard. In its 2023 survey of health information exchange organizations, ASTP found that 90% routinely received HL7 v2 admission, discharge and transfer messages. Only about one in five sent or received data through FHIR APIs, which means an HL7 integration with a hospital usually starts from a v2 feed.
| HL7 v2 | FHIR | |
|---|---|---|
| Origin | Late 1980s, still the hospital workhorse | Early 2010s, the US regulatory baseline since 2022 |
| Shape | Event messages: a patient was admitted, a result is ready | Resources over a web API: Patient, Observation, Appointment |
| Where you meet it | Interface engines, lab feeds, admission and discharge streams | EHR developer programs, SMART on FHIR apps, payer APIs |
| Typical access | A feed negotiated site by site | Read access widely available, write access varies |
The word that decides most EHR integration estimates is write. Regulation pushed EHR vendors to open read access, so pulling a patient's problems, medications and results is fairly predictable. Writing back is another matter. A note, an order or a device reading headed for a flowsheet depends on each vendor's program and each customer's policy: some EHRs accept FHIR writes for specific resources, some want an HL7 v2 message, some only take a PDF attached to the chart. A healthcare interoperability platform can write only where the EHR allows it, so settle what the target system accepts before you compare anything else.
Lock-in and the price of leaving
Every healthcare interoperability platform contract carries an exit cost that rarely gets quoted at signing. Your field mappings, patient-matching rules and message transformations live in the vendor's configuration. Leaving means rebuilding them, retesting every connection and often getting each one re-approved by the health system, the slowest step of all.
Pricing adds a second layer. Vendr reports typical yearly increases of 3% to 7% for Redox, plus multi-year discounts that reward staying put. Mirth shows the extreme form of the same risk: a healthcare integration engine chosen partly because it cost nothing became a license negotiation for anyone who wanted updates.
Compliance is the third. A healthcare interoperability platform that touches protected health information is a business associate, so the vendor and every subprocessor it uses join your BAA chain. Most vendors sign BAAs without fuss, but it is one more contract to review and one more party in your breach response plan, as our guide to HIPAA-compliant app development explains. Lock-in is a fair price for speed if you know the exit cost going in, and an expensive surprise if you first see it at renewal.
Choosing your integration route
No single threshold settles this. Most projects show signals from both lists below, and they usually end up with a hybrid.
Signals that point to a healthcare interoperability platform
A platform earns its fee when breadth and speed matter more than control:
- Many EHRs, soon. A pipeline spanning Epic, Oracle Health, athenahealth, eClinicalWorks and a handful of smaller systems is what a healthcare interoperability platform is built for, since each new customer becomes configuration instead of code.
- Your use case is mostly reading. History, medications, lab results.
- You sell in the US, where connector catalogs are deepest.
- Your team has never shipped an EHR integration. Paying for someone else's experience costs less than acquiring it on your first customer, in front of a hospital.
- A live pilot is due this quarter. An early-stage company that must show a working connection to raise its next round should rarely build its own HL7 integration layer.
If most of those fit, start on a platform and model the renewal price before you sign.
Signals that point to custom integration
The case for building rests on depth, ownership and scale:
- One or two counterparts carry most of the value. A single hospital system, a specialty group, one EHR that dominates your customer base. Depth there repays faster than breadth you will not use.
- You need to write, and often. Each write path gets negotiated with the EHR either way, and owning the code means you control how failures and retries behave.
- The other side is niche, legacy or local – behavioral health systems, lab software, a regional EHR, anything outside the US.
- The data model is your product. If analytics, risk scoring or an AI layer sits on top, you want structured data in a shape you define, and a platform's normalized output was designed around everyone's needs at once.
- Volume turns fees into your largest cost.
- Integration is what you sell. Renting the connection would mean renting the thing customers pay you for.
Some clinical programs narrow the choice for you. Chronic care management requires patient data in certified EHR technology and a care plan that can leave the practice on request, as we showed in our build-vs-buy analysis of chronic care management software.
Outside the US: GDPR, EHDS and systems no platform reaches
The big unified APIs were built for the American market, and their connector lists show it. In Europe the systems on the other end are national e-health platforms, regional hospital software and local clinic tools, few of which appear in a US catalog. European teams build the integration layer themselves as a matter of course, and a healthcare interoperability platform from the US rarely enters the conversation.
Regulation is pulling Europe toward common formats, on a long clock. The European Health Data Space regulation entered into force on 26 March 2025. Cross-border exchange of patient summaries and ePrescriptions must work in every member state by March 2029, with medical images, lab results and discharge reports following by March 2031. EHR systems sold in the EU will have to support the European exchange format for those categories, which should eventually give platforms a common target. Until 2029 at the earliest, plan for custom work.
GDPR adds the question of where data is processed. A US-hosted platform handling EU patients' data needs a lawful transfer mechanism, and many European hospitals will ask for EU hosting anyway. A custom layer running in your own EU cloud account answers that before procurement asks.
The hybrid architecture most teams end up with
Most products that last mature into a mix. This sequence keeps the platform where it earns its fee and builds where ownership pays:
- Define your own data model first. Patients, encounters, observations and care plans live in your schema, and every connection maps into it. A later change of vendor then touches the mapping layer and leaves the product alone.
- Use a healthcare interoperability platform for breadth. Connect the long tail of EHRs and national record retrieval through one vendor while your customer base is small and varied.
- Build direct integrations where volume concentrates. Once one or two EHRs carry most of your patients or messages, a direct connection removes the per-transaction cost and gives you control over the workflow.
- Keep the platform for the long tail. The tenth and twentieth EHR rarely justify their own build, so the platform stays, on a smaller contract.
Device data follows the same logic. A patient-facing mobile app we built integrates eight medical devices, none of them through a platform catalog, and we have built the full remote patient monitoring stack, from device sync through alerts to billing logic. Map your counterparts before you talk to any vendor: which systems, read or write, and how many patients each one carries. That list tells you where to rent and where to own better than any demo will. When the answer includes a custom layer, our healthcare software development team can scope it with you.
FAQ – healthcare interoperability platform
What is interoperability in healthcare?
Interoperability in healthcare is the ability of different systems to exchange patient data and use it without anyone retyping it. HIMSS describes four levels of it: foundational (the data can move), structural (it arrives in a known format), semantic (both sides agree on what the codes mean) and organizational (the policies, consent and workflows exist to make exchange routine). Most projects that fail do so at the last two levels, long after the connection itself works.
What is EHR integration?
EHR integration connects an outside application to an electronic health record so data flows between them automatically. The app reads demographics, medications or results from the chart and, where the EHR allows it, writes notes, orders or readings back. The connection can run directly against the EHR's API, through an HL7 v2 feed, or through a healthcare interoperability platform that manages it for you. The most polished version launches your app from inside the chart, so the clinician never logs in twice.
What are HL7 and FHIR standards?
HL7 International is the nonprofit standards body behind most clinical data exchange, and its standards come in generations:
- HL7 v2 – short event messages, one per admission, lab result or appointment
- CDA and C-CDA – whole clinical documents, such as the care summary sent at a referral
- FHIR – individual data resources exchanged over web APIs, so an app can ask for one patient's medications without receiving a whole document
Most real integrations touch at least two of them, because a health system that exposes FHIR for reading may still send its events as HL7 v2.
What are some healthcare interoperability companies?
Vendors of healthcare interoperability solutions split by product type:
- Integration engines: Rhapsody, Infor Cloverleaf, InterSystems, NextGen with Mirth Connect
- Unified APIs: Redox, Health Gorilla, Particle Health
- National networks: TEFCA's designated networks, such as eHealth Exchange and Epic Nexus, plus the Carequality and CommonWell frameworks
- Cloud building blocks: AWS HealthLake, Azure Health Data Services and the Google Cloud Healthcare API
Which category fits depends on whether you route messages inside a hospital, reach many EHRs from outside, or retrieve records across organizations.
How much does EHR integration cost?
Compare three-year totals, because first-year prices flatter a platform. Procurement data for Redox shows a median contract of about $52,500 a year plus implementation fees, while a custom build trades that subscription for an upfront cost and 15–20% of it every year in maintenance. Some EHR vendors also charge partners for API programs or marketplace listings, and those fees land on top of either route.
What is an example of interoperability in healthcare?
A patient goes home after a heart failure admission. The hospital's EHR sends a discharge message, the follow-up team's system picks it up within minutes, enrolls the patient in remote monitoring and books a check-in call, and readings from a home blood pressure cuff flow into the clinician's view. Every step where someone phones, faxes or retypes instead is a place where interoperability broke down.
