The interoperability subscription is becoming a transitional artifact
There’s a category of healthcare IT spend that’s quietly aging out of relevance: the third-party interoperability middleware subscription.
For most of the last decade, this category existed for a clear reason — legacy EHRs didn’t expose structured data through modern APIs. If you wanted to send a clinical document to an outside provider, submit immunization data to a state registry, or integrate a new digital health tool, you didn’t ask the EHR vendor. You bought a separate subscription from a middleware specialist like EMR Direct, paid per connection or per transaction, and accepted that the interoperability layer would live structurally outside the platform you’d already implemented.
The architecture worked. The economics didn’t age well.
Three forces are now converging to make the middleware subscription a transitional cost rather than a permanent line item.
FHIR has moved from emerging to mandated
The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) established FHIR-based API requirements for payers in 2020 and remains the foundation. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), published January 2024, builds on it with four new FHIR APIs — Provider Access, Payer-to-Payer, Patient Access enhancements, and Prior Authorization — with operational provisions in effect from January 1, 2026, and full API compliance required by January 1, 2027. The ONC Cures Act Final Rule prohibits information blocking and requires certified health IT to support standardized API access — anchored by the (g)(10) FHIR Standardized API criterion. The HTI-1 Final Rule (January 2024) made USCDI v3 the mandatory baseline for certified health IT as of January 1, 2026, replacing the prior USCDI v1 requirement and more than doubling the number of required data elements. ONC is now publishing through USCDI v6 (July 2025), with draft v7 open for comment. And in December 2025, ONC’s HTI-5 proposed rule proposed removing over 50% of existing certification criteria while explicitly retaining and strengthening the FHIR (g)(10) criterion — described as “the backbone of the programme’s API-first direction.” The direction is settled.
EHR platforms are building FHIR natively, not partnering for it
What used to require a third-party adapter is increasingly an in-platform capability. Native FHIR modules eliminate the data hop, the per-connection fee, the second contract, and the separate audit surface. The integration question is shifting — not “how do we connect external systems?” but “why do we need an external system at all?”
The cost structure of middleware subscriptions is hard to defend in budget reviews
When the platform can do natively what the third-party charges for, the renewal conversation gets uncomfortable.
IT leaders who can show a like-for-like replacement — same outcomes, lower recurring cost, fewer vendor relationships — are doing exactly the kind of cost rationalization finance teams reward.
This is the broader market context for what blueBriX has built.
What native FHIR architecture actually changes
The architectural difference between a native FHIR module and a middleware-based interoperability layer comes down to three structural shifts.
The data path is shorter. Clinical data moves from the platform to external systems through the native module, with no third-party gateway translating in the middle. Fewer points of failure, no per-transaction fees to a separate vendor, and a single audit surface for security and compliance reviews.
The contract footprint shrinks. Customers using a native module don’t carry a parallel subscription for interoperability. The capability is part of the platform license. For blueBriX customers specifically, this has meant fully eliminating the EMR Direct subscription, with a measured 20% reduction in licensing and operational costs for the interoperability package — a recurring line that finance teams can audit against prior-year spend.
The roadmap is unified. Capability additions — new FHIR resources, new operations, new exchange partners, compliance updates — move on the same release cycle as the rest of the platform. There’s no waiting for a third-party vendor to prioritize one customer’s use case against their other accounts.
These aren’t speculative benefits. They’re the operational consequences of removing a layer from the architecture.
What's actually inside the blueBriX FHIR module
The module is FHIR-conformant and built on FHIR R5, the most recent published version of the HL7 FHIR specification. It supports 24 widely used FHIR resource types that cover the core clinical data model:
- AllergyIntolerance
- CarePlan
- CareTeam
- Condition
- Device
- DeviceUsage
- DiagnosticReport
- DocumentReference
- Encounter
- FamilyMemberHistory
- Goal
- Group
- Immunization
- Location
- Medication
- MedicationRequest
- MedicationStatement
- Observation
- Organization
- Patient
- Practitioner
- PractitionerRole
- Procedure
- Provenance
These cover patient demographics, clinical observations, conditions, medications, allergies, immunizations, procedures, care team composition, care plans, device data, family history, medication statements, and document references for unstructured content — the data classes that show up in nearly every interoperability workflow IT teams build against.
On operations, the module supports:
- Read operations across all 24 resources, for single-patient data retrieval — the standard pattern for clinical lookup and individual record exchange.
- Bulk Data Access ($export) across all 24 resources, for population-level data movement — the standard pattern for quality reporting, payer data exchange, ACO reconciliation, research extracts, and audit responses.
Together, these access patterns cover the majority of real-world FHIR workflows in US healthcare. A FHIR module without bulk export support forces IT teams into overnight database extracts and custom ETL pipelines for everything at scale, which is how technical debt accumulates in interoperability projects.
Public health reporting that's already live in production
Vendor claims about FHIR conformance are common. Live, automated submission to named state receiving systems is rare — and it’s the most operationally meaningful proof point because production systems enforce conformance in ways internal QA never will.
blueBriX’s FHIR module is in production with direct, automated immunization reporting to three state immunization information systems (IIS):
- Immunet (Florida’s statewide immunization registry)
- Florida SHOTS
- CAIR (California Immunization Registry)
The exchange uses the Immunization FHIR resource as the structured payload. Submission and acknowledgment workflows are automated inside the platform.
For organizations operating across multiple states — community health centers, multi-site provider groups, behavioral health organizations dispensing vaccines — this collapses what was previously a state-by-state integration project into a configurable workflow.
It’s worth being precise about scope: this is public health reporting to state immunization registries, not QHIN participation or TEFCA membership. Those are separate federal frameworks operating at the nationwide network layer. The distinction matters because any vendor claiming “seamless interoperability across the US healthcare network” is overstating what FHIR alone can do. What blueBriX delivers today is specific, defensible, and operationally valuable: live FHIR-based reporting to named state IIS systems through standards-based exchange.
How blueBriX handles the legacy exchange reality
There’s a tradeoff in the architecture worth surfacing for IT buyers evaluating native FHIR platforms.
The blueBriX FHIR module is R5-only. R5 is the most recent published version of FHIR, positioning the platform for where US interoperability policy is heading. But the operational reality of US healthcare in 2026 is that most exchange partners still run on FHIR R4 (which is what ONC certification under (g)(10), USCDI v3 implementations, CMS-9115-F and CMS-0057-F requirements, and TEFCA all reference today) and that legacy HL7 v2 and C-CDA continue to move the majority of operational healthcare data.
The way this works inside blueBriX: the FHIR R5 module handles modern FHIR exchange where partners support R5, while the platform continues to support HL7 v2 and C-CDA natively for everything else.
For an IT leader mapping this against existing exchange partners:
- Lab results, ADT feeds, and order flows continue through HL7 v2 — still the dominant format for these workflows across US healthcare regardless of FHIR adoption status.
- Transitions of care documents, referrals, and document-based exchange continue through C-CDA, which remains the operational standard for these use cases.
- FHIR-based exchange happens through the R5 module where partners support R5.
This hybrid pattern is the operational reality in 2026 — modern FHIR coexisting with established HL7 v2 workflows, not replacing them overnight. The strategic position is that R5 is the direction of travel, and the platform is built for it. The tactical position is that legacy format support means current exchange partners — including R4-using ones, who almost universally also support HL7 v2 or C-CDA for the same use cases — are already covered.
You're already asking these questions. We've turned them into a scoring framework.
Twenty-five vendor evaluation questions across seven dimensions — architecture, standards, production proof, cost structure, regulatory posture, security, and implementation. Each one paired with what a strong answer looks like.
Five questions worth asking in any native FHIR vs. middleware
Vendor pitches sound similar at the category level. The differences show up in the answers to specific architectural questions. These are five worth pressure-testing in any evaluation — whether you’re looking at blueBriX or considering renewing a middleware subscription:
- Is the FHIR layer native to the platform, or delivered through a third-party partnership?
- Which FHIR version is supported, and is Bulk Data Access ($export) implemented in addition to Read?
- Which public health registries, HIEs, or exchange partners are live in production today — not in sandbox, in production?
- What third-party interoperability subscriptions does the native module replace, and what’s the measured cost impact?
- How are legacy formats (HL7 v2, C-CDA) handled for partners not on FHIR?
For blueBriX: native to the platform; FHIR R5 with Read and Bulk Data Access; live in production with Immunet, Florida SHOTS, and CAIR; replaces EMR Direct with a measured 20% reduction in licensing and operational cost; HL7 v2 and C-CDA natively supported alongside FHIR.
These five questions are the starting point. A complete evaluation framework — including questions on conformance testing, audit trails, certifications, US Core profile support, security architecture, and roadmap ownership — is available as a downloadable checklist for IT and integration leaders running a formal vendor comparison.
