Every Arizona practice that has looked into connecting its EHR to a referral network, a specialist group, or a regional health information exchange eventually hits the same wall: nobody quotes a real number until you have already sat through a sales call. FHIR — Fast Healthcare Interoperability Resources, the data-exchange standard maintained by Health Level Seven International (HL7) — is supposed to make interoperability cheaper and faster than the older HL7 v2 messaging standard it is gradually replacing. It usually is. But "cheaper" still spans a wide range, and the practices that get burned are almost always the ones that never broke the FHIR integration cost down before signing a vendor contract.
This is a buyer’s breakdown, not a sales pitch: what actually moves the price, what a small single-site practice should expect to pay in year one and every year after, and where FHIR quietly saves money compared to a traditional HL7 interface.
What Actually Drives the Price of a FHIR Connection
Two practices asking for "the same" integration can get quotes tens of thousands of dollars apart, and the gap almost never comes from the vendor padding the invoice. It comes from scope decisions the practice made before it ever called for pricing:
- Number of interfaces. A single feed — say, sending referral summaries to one partner — costs far less than standing up admissions/discharge/transfer (ADT) data, lab orders and results, and document exchange as separate connections.
- Read-only vs. bidirectional. Pulling data into your system is simpler and cheaper than a two-way connection that also lets an outside system write back into your EHR. Bidirectional integrations carry more validation, error-handling, and security review.
- How many EHR vendors are involved. Connecting a second EHR platform into the same project is not a linear add-on — each additional vendor brings its own API quirks, certification steps, and sometimes its own licensing fees, and can meaningfully increase total project cost.
- Historical data migration. If the project includes pulling years of legacy patient records into the new interface rather than just exchanging data going forward, that migration work is usually priced and scoped separately from the live connection.
- How much native FHIR support your EHR already has. If your EHR vendor already exposes a working FHIR endpoint, a vendor mostly configures and tests it. If your system is older and only speaks HL7 v2, someone has to build or license middleware to translate between the two — and that translation layer is where budgets balloon.
The line item practices consistently underestimate is labor. Engineering and testing time, not software licensing, makes up the large majority of what you are actually paying for in a FHIR integration project.
Typical Cost Ranges, From Read-Only to Full Bidirectional
Published estimates vary by scope, but they cluster into a consistent pattern for practices sized like most independent Arizona clinics — single site, one EHR, a handful of interfaces:
| Integration scope | Typical cost range |
|---|---|
| Single read-only FHIR connection (one data feed, existing vendor endpoint) | As low as $15,000 |
| Basic FHIR enablement, small/single-site practice, minimal customization | $25,000 – $75,000 |
| Full year-one build, 1–3 interfaces, one EHR (small practice) | $45,000 – $120,000 |
| Complex bidirectional, multi-system integration | $150,000+ |
| Traditional HL7 v2 interface build (comparison point) | $50,000 – $750,000+ |
The comparison line matters: legacy HL7 v2 interfaces, built point-to-point and maintained individually, have historically run far higher than a modern FHIR API-based build for equivalent scope. That gap is the entire reason federal interoperability policy has pushed the industry toward FHIR over the past several years — it is not just a technical preference, it changes what a small practice can realistically afford to build.
HL7 v2 vs. FHIR: Why the Standard You Pick Changes the Bill
HL7 v2 is the older, message-based standard that still runs a large share of hospital and lab data exchange today. It is mature and well understood, but each connection tends to be custom-built and point-to-point, which is exactly what drives its wide, expensive cost range. FHIR, by contrast, is a REST-based API standard using JSON, closer to how modern web and mobile software already talks to servers — which is why vendors can often quote standardized SDKs and faster implementation timelines instead of bespoke interface code for every connection.
In practice, very few Arizona clinics are choosing one standard in isolation. Most sit in a hybrid state: legacy HL7 v2 feeds keep running for older lab or hospital connections, while new work — a referral portal, a patient app, a specialist network — gets built on FHIR, sometimes with an interface engine in between translating one format into the other. Ask any vendor quoting your project which side of that hybrid your practice will land on, because a bid that assumes clean-slate FHIR is not comparable to one that has to bridge an aging HL7 v2 system underneath.
The Ongoing Bill Nobody Mentions Upfront
The number that gets left out of most sales conversations is what happens after go-live. FHIR connections are not "set and forget" — interface definitions change, certificates expire, and API versions get deprecated. Typical ongoing maintenance and support runs roughly $3,000 to $15,000 per interface per year; for a small practice running a handful of interfaces, that adds up to somewhere in the neighborhood of $18,000 to $36,000 annually, on top of whatever the initial build cost. Any quote that only covers implementation, with no line item for year-two support, is an incomplete quote.
How to Get an Accurate Number Instead of a Guess
Before requesting a bid from any interoperability vendor, a practice should be able to answer these five questions — because every one of them changes the price:
- How many separate data feeds do we actually need (referrals, ADT, labs, documents), and can any be combined into fewer interfaces?
- Do we need bidirectional data flow, or is read-only sufficient for this use case?
- Does our current EHR already expose a working FHIR API, or will a translation layer be required?
- Are we migrating historical patient data, or starting the exchange from today forward only?
- What does year-two support cost, itemized separately from the initial build?
A vendor who can answer all five before quoting a price is scoping the work properly. A vendor who quotes a single flat number without asking any of them is guessing — and guesses tend to grow once the contract is signed.
Getting an accurate FHIR integration cost estimate starts with matching your practice to a vendor who has actually scoped a project like yours before, not the vendor with the lowest headline number. For an independent Arizona practice, that vetting step is often the difference between a project that lands inside budget and one that doubles in year two.