Most teams building AI assistants in healthcare start in the right place. They focus on the workflows they want to automate, the clinical problems they want to solve, and the data they need to do it. They get an assistant working in a sandbox. They run a pilot. The product looks promising.

What they don’t see, at least not yet, is the constraint that shows up later.

AI assistants in healthcare are fundamentally different from traditional software. They don’t retrieve data once and move on. They reason continuously. They loop. They re-check the state. They trigger follow-up actions. And every one of those behaviors amplifies how often the system interacts with the EHR.

That’s why EHR data access isn’t a solved integration problem. It’s a systems problem. And the cost of getting it wrong doesn’t show up during demos or pilots, it appears only after the assistant proves useful and adoption begins to scale.

By then, the architecture is already locked in.

The Cost Problem No One Sees Early Enough

On the surface, EHR connectivity looks straightforward. Use FHIR. Pull what you need. Move on.

In reality, EHR data access costs vary wildly depending on the vendor, the access method, and how often you hit the system. Some EHRs charge little or nothing for certain APIs. Others meter aggressively. Some support event notifications. Others require polling. Most fall somewhere in between.

Two systems can pull the same data and end up with 10x different costs depending on how they’re designed.

The problem is timing. Early on, usage is low. The assistant runs occasionally. Costs are manageable. Everything looks fine.

Then adoption grows. The assistant runs continuously. Background checks increase. Reasoning loops multiply. And suddenly, what looked like a reasonable integration becomes one of the most expensive parts of the product.

This isn’t a billing surprise. It’s a design consequence.

Why AI Assistants Make This Worse (By Design)

Traditional healthcare applications operate in predictable patterns. They pull data when a user clicks a button or loads a page. Usage scales roughly linearly with users.

AI assistants don’t work that way.

They:

• reason across multiple steps
• check and re-check state
• trigger workflows based on conditions
• run in the background
• operate continuously, not transactionally

Each “thought” can trigger additional data access. Each follow-up action can result in more EHR calls. Each attempt to stay “real-time” compounds cost.

An AI assistant that isn’t cost-aware at the data layer will bankrupt itself through curiosity.

This is why cost isn’t just an infrastructure concern, it defines what an assistant is allowed to do. Over time, teams are forced to:

• reduce polling frequency
• batch updates instead of reacting in real time
• limit features
• throttle usage
• redefine what “real-time” actually means

The assistant still works, but not as it was originally envisioned.

Cost Is a Systems Design Problem

Most teams think about cost too late, because they treat it as something to optimize after the system works. In healthcare AI, that’s backwards.

Cost must be part of system design from the beginning.

That means making deliberate decisions about how data is accessed, not just what data is accessed.

Caching Is Not an Optimization, It’s Survival

If every request results in a live EHR call, the system will not scale. Intelligent caching reduces redundant access and stabilizes cost without sacrificing freshness when done correctly.

Events vs. Polling Is a Tradeoff, Not a Preference

In an ideal world, EHRs would notify you the moment data changes. In reality, event support varies widely. Some systems require polling. Others support partial notifications. Most require a hybrid approach. Each choice has cost implications.

One Access Method Is Never Enough

FHIR alone is rarely sufficient. Proprietary APIs, event subscriptions, and bulk exports all play a role. Effective systems mix and match access strategies per EHR to balance freshness, performance, and cost.

Identity Consistency Is Non-Negotiable

EHRs often return different IDs for the same entity across access methods. Without internal ID normalization, AI systems reason incorrectly, or duplicate work. Correctness and cost are tightly coupled here.

None of this shows up in a demo. All of it shows up at scale.

What This Means for Anyone Building or Buying AI in Healthcare

If you’re building an AI assistant, you are building infrastructure whether you intend to or not. Ignoring this layer doesn’t make it go away, it just pushes the consequences further downstream, where they’re harder and more expensive to fix.

If you’re buying an AI assistant, this problem is still yours, just indirectly. You may never see the EHR API bills, but you’ll experience the outcomes:

• “real-time” becoming delayed
• pricing increasing as usage grows
• vendors saying “that’s not supported yet”

The right question isn’t whether an assistant integrates with your EHR. It’s whether the system underneath was designed to support scale and performance.

Why We Built XCaliber the Way We Did

XCaliber was built with the assumption that AI assistants would be agentic, continuous, and deeply embedded in clinical workflows. That meant treating EHR data access as a core systems concern from day one and not an afterthought.

We designed for:

• cost-aware data access
• hybrid event and polling strategies
• aggressive but safe caching
• identity normalization across access methods
• agent-friendly architectures that don’t collapse at scale

Not because it’s elegant, but because without it, AI assistants can’t become what they promise to be.

The Bottom Line

EHR connectivity isn’t just about getting data. It’s about whether your AI system can afford to think, reason, and act at scale.

The teams that recognize this early don’t just save money. They preserve the ability to build assistants that remain responsive, capable, and real-time as adoption grows.

In healthcare AI, infrastructure decisions don’t just support the product. They define it.