Last week I had the pleasure of sitting down with Eugene Vestel to record an episode of Out of the FHIR. Afterwards, I thought I would try to put to writing the core ideas I wanted to communicate in this interview. The full conversation explores these themes in much greater depth—you can find the second part of this episode on Eugene's Substack, FHIR IQ Playbook.
The 2025 Reality Check
As we move deeper into 2025, the regulatory momentum around healthcare data exchange has never been stronger. The CMS (Centers for Medicare & Medicaid Services) 9115-F rule mandates payer patient access APIs, while the upcoming CMS-0057 prior authorization requirements promise to reshape how providers and payers interact. Yet the recent CMS RFI responses paint a stark picture: interoperability gaps remain the number one complaint across the industry.
Our latest State of the Payer Patient Access API Report provides concrete data on these implementation challenges, while the regulatory progression from CMS 9115-F to CMS-0057 shows how we got here and where we're headed, and our own RFI response paints a picture of where we can improve.
After connecting to over 300 different FHIR endpoints—what we believe is one of the largest private third-party FHIR networks—we've learned three critical things that most people miss: first, terminology is the healthcare data (and the biggest source of implementation failures); second, there are genuine reasons to be optimistic about where we're headed; and third, some of the most promising opportunities are being completely overlooked by the industry.
Terminology Rules Everything Around Me
Most healthcare technology discussions focus on APIs, standards, and compliance checkboxes. But after building connections to over 300 different FHIR endpoints—what we believe is one of the largest private third-party FHIR networks—we've realized that the most important building block is terminology. In a real sense, terminology is healthcare data.
Think about it this way: FHIR is essentially a sophisticated container system for transporting healthcare concepts. But those concepts only matter if everyone agrees on what they mean. When a payer translates legacy X12 transactions (like 837 claims) into FHIR ExplanationOfBenefit resources, they're not just moving data—they're interpreting decades of coding standards, from ICD-10 to HCPCS Level II codes.
Our deep dive into FHIR vs X12 837 claims data illustrates exactly how complex this translation process can be and why it's a source of so many implementation inconsistencies.
Here's where things get messy at scale. We've seen hundreds of different institutions implement what should be the same standard in subtly different ways. One common error that perfectly illustrates this? The ValueSet URL confusion. Many implementations use the literal canonical URL for a ValueSet as the system URL when coding. This creates ambiguity when ValueSets contain multiple coding systems—imagine trying to distinguish between CPT codes (starting with numbers) and HCPCS Level II codes (starting with letters) when the system identifier is wrong.
You can see this problem in action across our comprehensive payer endpoint directory, where we track implementation inconsistencies across hundreds of payer APIs.
The Compliance Trap
Sometimes I wonder if the payer space exemplifies everything wrong with our current approach to interoperability. Most health plans treat API compliance as just another regulatory checkbox—something to build cheaply and stuff into a corner of their technology stack.
This is precisely why we built end-to-end interoperability testing for CMS-9115F and CMS-0057—to help organizations move beyond checkbox compliance toward implementations that actually work.
This checkbox mentality creates a cascading problem. When hundreds of payers implement FHIR with varying levels of conformance testing and terminology consistency, the result is a network that technically works but practically struggles. Every downstream application—whether it's a health app, analytics platform, or clinical decision support tool—inherits these inconsistencies and must build expensive workarounds.
The irony? The underlying claims data was already somewhat interoperable through X12 standards before FHIR entered the picture. We've essentially created a new layer of potential failure points without dramatically improving the underlying value proposition.
Payer-to-payer exchange represents the first interoperability initiative where payers get immediate, tangible value. The chart chase—that expensive, manual process of assembling patient records when someone switches insurance—costs the industry billions annually and can take 30 days to complete.
When payers can act as both producers and consumers of FHIR data, suddenly the business case shifts dramatically. This isn't just about compliance anymore; it's about member experience, operational efficiency, and competitive advantage. The member experience team—which is a growth center, not a cost center—suddenly cares about interoperability quality in ways that the compliance team never could.
The emerging AI landscape offers another compelling path forward. We recently published FHIR-specific AI evaluations that test how well large language models can extract data from FHIR resources and generate valid FHIR bundles from clinical narratives. Our comprehensive benchmarking of LLMs on FHIR shows that specialized, smaller models trained with reinforcement learning could soon outperform general-purpose foundation models on healthcare-specific tasks.
What makes this particularly exciting is the potential for verified rewards through FHIR's built-in validation operations. Unlike reinforcement learning from human feedback, this approach could use the FHIR validator itself as a reward signal, creating models that generate consistently valid, conformant resources.
Combined with computer use capabilities, this could finally automate some of the administrative burden that still plagues healthcare—from that dreaded clipboard sign-in process to complex prior authorization workflows that might not even be solving the right problem.
Sneakernets
Perhaps the most underutilized piece of health technology today isn't a sophisticated API or AI model—it's the SMART Health Card. These QR codes, born from the COVID vaccination verification era, represent a brilliantly simple solution to a complex problem: how to make patients natural transporters of their own data.
Imagine getting lab results with a SMART Health Link QR code printed right on your receipt. Scan it immediately, and nothing happens—results aren't ready yet. But bring that paper to your next doctor's appointment, and suddenly you've solved the perennial problem of missing lab results without requiring any system integration. Your doctor scans the code, maybe asks for a PIN, and has immediate access to your complete results.
This "patient sneakernet" approach could actually out-compete traditional health information exchanges by making data transport universally accessible. The eldest person in your family can use it as easily as the youngest, and it works regardless of which EMR systems are involved.
What This Means for Your Roadmap
Interoperability isn't an end goal—it's an enabler for insights, efficiency, and better patient outcomes.
For health tech leaders, this means investing in conformance testing, terminology consistency, and user-centered design and finding rational reasons to exceed regulatory minimums. For payers, it means seeing interoperability as a competitive advantage rather than a cost center. For the entire industry, it means acknowledging the barbarians at the gates—and patients themselves—need consent-driven on-ramps to access.
Ready to see how teams get claims data in under 60 seconds? Get a demo and experience the difference of our single API connecting to 300+ health plans.
