Every week I talk to a healthtech founder who's built something impressive — a clinical NLP model, a diagnostic AI, a coding automation tool — and now needs to get it into production. The model works. The accuracy is strong. The demo is polished.
Then they try to connect it to a health system's EHR, and everything grinds to a halt.
The problem isn't the AI. It's the plumbing. And in healthcare, the plumbing is interoperability.
The Data Problem AI Teams Don't See Coming
Healthcare AI products need clinical data to function. Patient records, lab results, imaging studies, medication histories, encounter notes. This data lives inside EHR systems — Epic, Cerner (Oracle Health), AllScripts, and dozens of others — behind FHIR APIs, HL7 v2 interfaces, and vendor-specific access controls.
Here's what most AI teams discover too late:
The data you need isn't always in the FHIR resource you expect. Clinical notes might be in DocumentReference, or they might be in DiagnosticReport, or they might only be accessible through a proprietary bulk export. It depends on the EHR and the health system's configuration.
Data quality varies wildly between health systems. The same clinical concept might be coded with SNOMED in one system, ICD-10 in another, and free text in a third. Your model needs to handle all three — or you need a normalization layer that does.
De-identification is harder than it looks. Names and dates are easy to redact. But clinical notes contain implicit identifiers — unusual conditions, specific locations, unique family histories — that require sophisticated NLP to detect and remove. At Phare Health, we built GPU-accelerated de-identification pipelines specifically because rule-based approaches couldn't keep up with the volume or catch the edge cases.
Access isn't automatic. Getting production access to EHR data requires Business Associate Agreements, security reviews, and often EHR vendor certification. This process takes months, not weeks.
Translation: your AI might be ready, but the data it needs is locked behind layers of technical, legal, and organizational complexity that most teams underestimate by 3–6 months.
What an Interoperability Strategy Looks Like for AI Products
An interoperability strategy isn't a FHIR tutorial. It's a set of architecture decisions that determine how your AI product consumes, processes, and acts on clinical data in production.
Here's what each layer does and why it matters.
Data ingestion layer. How does clinical data get into your system? Real-time FHIR subscriptions? Bulk FHIR export? HL7 v2 message feeds? The answer determines your latency, completeness, and operational complexity.
Most AI products need a combination — real-time feeds for triggering workflows, bulk export for training data. Getting this wrong means either stale data or an overwhelmed pipeline. There's no universal right answer, but there is a right answer for your use case, and it needs to be decided before you write integration code.
Normalization and terminology mapping. Your AI model expects data in a specific format. EHR data arrives in whatever format the health system uses. The normalization layer bridges this gap — mapping ICD-10 to SNOMED, standardizing lab units, parsing unstructured clinical notes into structured features.
This layer is often more complex than the AI model itself. It's also where most teams underinvest, because it feels like unglamorous plumbing work. It is. It's also the difference between a model that works in the demo and a model that works in production.
De-identification pipeline. If your AI processes data for analytics, research, or model training, you need robust PHI removal. This isn't optional under HIPAA. Build it into the pipeline architecture from the start — bolting it on later usually means rebuilding the pipeline.
At Phare, we learned this the hard way. Simple regex-based redaction missed implicit identifiers in clinical notes. We ended up building GPU-accelerated NLP pipelines to handle de-identification at scale. If you're processing thousands of records daily, plan for this level of sophistication.
Data validation and quality monitoring. These are two separate concerns, and you need both.
Validation gates are synchronous checks — does this record have required fields? Is the schema valid? Are code systems recognized? Records that fail get quarantined before they reach your model. This is your first line of defense against bad data.
Data quality monitoring is the observational layer — tracking completeness rates, distribution drift, and data freshness over time. We used SODA and Great Expectations at Phare to catch the subtle degradation that doesn't trigger validation errors but still erodes model accuracy. Without this, your model's predictions can silently degrade over weeks as upstream data patterns shift.
Translation: validation catches broken records. Quality monitoring catches the slow rot that's invisible until your model starts making bad predictions.
Output integration. Your AI produces a result — a risk score, a coding suggestion, a clinical alert. How does that result get back into the clinical workflow?
CDS Hooks for real-time decision support? FHIR write-back for updating patient records? HL7 messages for legacy systems? The output path determines whether your AI actually changes clinical practice or sits in a dashboard nobody checks. This is where many promising AI products die — not because the model is wrong, but because the result never reaches the clinician at the right moment.
Compliance and audit trail. Every data access event, every model inference, every result delivered needs to be logged, traceable, and auditable. Health systems will require this before granting production access. It's not a nice-to-have — it's a gate.
The Architecture Decision That Saves Six Months
The single most impactful decision you can make is to separate your AI logic from your interoperability logic.
Your AI model should consume a clean, normalized, internal data format. It should never touch raw FHIR bundles, parse HL7 segments, or handle EHR-specific quirks. That's the job of the interoperability layer.
This separation means when you add a new EHR, you write a new adapter — you don't retrain or modify your model. When you update your model, you don't risk breaking EHR integrations. Your data science team works in clean data; your integration team handles the mess. Testing and validation are cleaner because each layer has clear boundaries.
At Phare Health, this architecture is what allowed us to scale from one EHR to multiple EHR and payer systems without rebuilding the core data pipeline each time. The AI components — NLP, de-identification, coding automation — operated on a canonical data model. The interoperability adapters translated between that model and each external system.
Translation: one architecture decision saved us from rewriting our pipeline every time we added an EHR partner. That's months of engineering time, compounded.
When to Build the Interoperability Strategy
Before your first pilot. Not after.
The most expensive mistake I see is teams that build an AI product in isolation, demo it with synthetic data, raise funding on the strength of the demo, and then discover that connecting to a real health system's EHR requires 6–9 months of integration work they didn't budget for.
Your interoperability strategy should inform your product architecture from the beginning. The questions you answer in week one — which data sources you'll need, how you'll handle terminology variation, where PHI will flow in your system — shape every engineering decision that follows.
If you're past that point and already have an AI product that needs EHR connectivity, the same principles apply — you just need to be honest about the timeline and scope of the integration work ahead. Starting with a focused assessment of your current architecture against these layers is the fastest way to identify gaps and build a realistic plan.
The Bottom Line
Healthcare AI is an interoperability problem disguised as a machine learning problem. The model is the easy part. Getting clean, compliant, production-quality clinical data into and out of your system — reliably, at scale, across multiple EHRs — is what determines whether your product reaches patients or stays in the demo environment.
Build the plumbing first. Or at least build it at the same time.