Perplexity Health Validates FHIR-First Interoperability

Perplexity Health Is a Signal: FHIR Has Crossed the Chasm

Perplexity Health running on top of b.well’s FHIR-powered network (spanning 2.4M providers) is more than a product announcement. It’s proof that a FHIR R4-based data substrate can support real-time, consumer-facing AI at national scale.

That matters for one reason: buyers—health systems, payers, risk-bearing providers—no longer debate whether FHIR works. They assume it does. The question is whether your platform is architected to take advantage of it.

For Series A–C digital health companies, this changes the roadmap. Interoperability is not an “integration phase” line item. It’s foundational infrastructure that determines whether your AI, analytics, care coordination, or patient engagement layer can actually function across ecosystems shaped by ONC Cures Act, USCDI, and increasingly standardized APIs.

The Buyer’s Real Problem: Data Access Is Commodity. Normalization Isn’t.

From the outside, the story sounds simple: FHIR APIs are available, connect to them. In practice, what buyers struggle with is:

• Inconsistent FHIR implementations across Epic, Cerner, and regional HIEs
• Partial profile support and missing extensions
• Patient identity matching across systems
• Medication, problem list, and lab normalization across USCDI versions
• Sustained performance at scale under real-world load

We’ve integrated with Epic and Cerner deployments across multi-facility provider networks, and the recurring issue isn’t API availability—it’s semantic drift. One system encodes smoking status differently. Another uses custom extensions for device data. Normalizing that into a stable internal model is where architecture earns its keep.

When Perplexity Health can query across a massive provider graph and present unified data, it’s because someone solved that layer cleanly. That’s the real work.

Four FHIR Architecture Patterns We See in the Market

If you’re building today, there are four dominant approaches.

1. Direct EMR Integrations

This is the pre-Cures model: build custom connections per client. It works for a handful of large enterprise deals. It collapses when you try to scale distribution.

2. Aggregator Network

This is what Perplexity Health effectively leverages through b.well’s network. You inherit connectivity across thousands of EMR endpoints abstracted behind consistent SMART on FHIR flows. Faster expansion, but you depend on the vendor’s normalization depth.

3. Hybrid Model

This is what we increasingly recommend. Use an aggregation network for coverage, but build your own canonical FHIR store and transformation layer. You control the internal model; you don’t blindly trust raw upstream payloads.

4. FHIR-First Platform

This is the long game. Stand up a FHIR server (AWS HealthLake or Azure Health Data Services), ingest from multiple sources, maintain strict profile conformance, and operate your own interoperability gateway. Slower to start, dominant at scale.

Why Perplexity Health Validates the FHIR-First Strategy

Three years ago, betting your product architecture on FHIR required conviction. Today, it’s defensive hygiene.

The bigger implication: AI-native products assume interoperability. Perplexity didn’t build a new integration fabric. They built an intelligent layer on top of an existing FHIR graph. That separation of concerns—data layer first, intelligence layer second—is strategic.

We’ve seen this play out in our own work. When our team designed a multi-facility clinical platform serving 160+ respiratory care sites, the turning point was decoupling ingestion from application logic. Once FHIR resources were normalized into a stable internal model, new analytics features shipped 3x faster because the data contract stopped changing underneath the engineers.

How AST Designs FHIR Architecture for Scale

We approach FHIR systems in four layers:

1. Connectivity Layer Authenticate via SMART, manage token exchange, monitor endpoint health, and log API performance per source.
2. Ingestion & Validation Enforce resource validation against target profiles; reject or quarantine malformed payloads.
3. Canonical Data Model Map inbound data to a normalized internal representation aligned to USCDI subsets and business logic.
4. Consumption Layer Expose stable APIs and event streams to analytics, AI, and applications without leaking source-specific quirks.

AST’s integrated pods own this end-to-end: engineers, QA, DevOps, and product lead embedded into your team. We’re not dropping in a FHIR developer; we’re building your interoperability backbone alongside you.

In one recent engagement, we replaced fragmented per-client integrations with a centralized FHIR gateway and saw integration onboarding time drop from 10–12 weeks to under 4. That’s what happens when architecture is intentional instead of reactive.

Decision Framework: Is It Time to Go FHIR-First?

1. Do You Depend on External Clinical Data? If yes, FHIR-first is not optional.
2. Are You Planning AI on Patient-Level Data? Invest in canonical modeling now.
3. Will You Sell to Multi-EMR Enterprises? Avoid per-client integrations; build a gateway.
4. Is Interoperability Core to Your Value? Own more of the stack. If not, use an aggregator plus normalization layer.

Perplexity Health is a proof point: intelligent applications now assume national-scale data mobility. If your architecture can’t support that trajectory, your product will feel isolated in an increasingly connected ecosystem.

FAQ