The electronic health record has served as the operational spine of clinical care for three decades. It was built to document, bill, and comply — not to think. That assumption is now failing in public.
The core argument
A new generation of AI-native EHR platforms — engineered around machine learning inference, ambient intelligence, and a FHIR-native data fabric — is forcing a question that cannot be deferred: is your infrastructure prepared for AI-first care delivery, or are you bolting intelligence onto a system that was never designed to carry it?
This article examines the state of AI-native EHR adoption across the vendor landscape, the regulatory and interoperability forces reshaping the market, and the operational risks leaders must weigh before committing to migration or modernization. It closes with Brandywine Consulting Partners' assessment of what this transformation actually requires — and why integration readiness, not vendor selection, is the decisive variable.
The inflection point: documentation infrastructure becomes cognitive infrastructure
For most of the 2010s, AI in healthcare IT meant an analytics add-on, a risk stratification module licensed from a third party, or an NLP layer stitched on top of a legacy EHR through a vendor-specific API. The architecture stayed the same; the capability was grafted on. The underlying system still thought in structured fields, discrete encounter types, and billing codes — not patient trajectories, probabilistic outcomes, or real-time clinical inference.
That model is collapsing under the weight of its own inadequacy.
The global EHR market was valued at roughly $33.4 billion in 2024 and is projected to reach $55.5 billion by 2033, driven substantially by AI-augmented platform upgrades. More consequentially, the global AI in healthcare market — $36.7 billion in 2025 — is forecast to exceed $505 billion by 2033, a 38.9% compound annual rate. Those figures do not describe incremental enhancement. They describe architectural displacement: AI is not a feature being added to healthcare IT, it is becoming the infrastructure.
The trigger is multifaceted. Clinician burnout, with documentation burden at its center, has reached a systemic crisis point. A 2024–2025 survey found that two in three physicians have adopted AI tools to streamline clinical documentation and workflow. Peer-reviewed studies document ambient AI scribes reducing documentation burden by 20–40%, with burnout rates declining 13 percentage points within 30 days of deployment in oncology settings. Capturing a single additional billable encounter per clinician per day recovers ambient deployment cost within 45–90 days in mid-market specialty practices.
These outcomes are not being generated by legacy platforms with AI modules attached. They are being generated by architectures where the inference engine is not a passenger but the pilot.
Defining "AI-native": architecture as distinction, not marketing
The term has been adopted broadly enough to lose precision. Every major EHR vendor now claims an AI strategy. The meaningful distinction is not the presence of AI features but the architectural relationship between the data layer and the inference layer.
Legacy AI-augmented (AI-bolted-on). The EHR was architected around relational database structures, HL7 v2 messaging, and discrete data models optimized for billing. AI capabilities are integrated as external microservices, third-party modules, or vendor-partnered overlays. Data must be extracted, transformed, and routed to the AI layer; inference outputs must be mapped back into proprietary structures. Latency, data fidelity loss, and integration brittleness are inherent to the design.
AI-native architecture. The system treats clinical data as a continuous semantic graph rather than a collection of discrete fields. The inference engine is embedded inside the data fabric, not layered above it. In practice that means:
- ▸FHIR R4/R5-native persistence — clinical entities modeled as FHIR resources at the storage layer, enabling native API access without transformation pipelines
- ▸Ambient inference as a first-class workflow component — voice-first or multimodal input with real-time NLP-to-structured-data conversion embedded in the encounter workflow, not called from it
- ▸Longitudinal patient modeling — a continuously updated semantic representation of the patient, not a record of isolated encounters
- ▸Predictive analytics as an operational primitive — clinical decision support generated from probabilistic models trained on population-scale data, not rule-based alert trees
- ▸Human-in-the-loop governance by design — outputs surfaced with provenance, confidence scores, and override pathways, never as directives
The practical test
Can the system's AI inference run without extracting data from the EHR, routing it through an external API, and writing results back? If the answer is no — if AI capability requires a pipeline orchestration layer to function — the architecture is AI-augmented, not AI-native, regardless of the marketing.
The five due-diligence questions that separate the two
Procurement teams rarely have the leverage to audit source code. They do have the leverage to ask questions a genuinely AI-native vendor can answer in technical specificity within one call:
| Question | What an AI-native answer sounds like | Warning sign |
|---|---|---|
| Where does inference physically execute relative to the clinical data store? | Inside the platform's own data plane, with no PHI egress required | "Through our partner's secure API" |
| Are FHIR resources the persistence model or a projection? | Resources are stored natively; the API is a read of the store | "We generate FHIR on request from our internal schema" |
| Is ambient documentation a workflow step or an external service call? | Embedded in the encounter state machine with structured write-back | Audio uploaded, transcript returned, clinician pastes |
| What model performance data exists by demographic subgroup? | Published subgroup metrics with monitoring cadence | "Our models are validated on national data" |
| What happens to your models if we leave in year four? | Documented export of features, weights, or federated retraining path | Silence, or "the models stay with the platform" |
The fifth question is the one most organizations forget to ask, and the one that costs the most later.
The market landscape: major players and strategic postures
Epic Systems: ecosystem depth over architectural purity
Epic remains the dominant platform by U.S. health system market share — serving over 300 million patients across more than 2,500 hospitals. Its AI strategy is not a ground-up rebuild but a systematic deepening of inference capability inside the existing platform, backed by arguably the most valuable clinical dataset in the world.
Cosmos, Epic's de-identified research database, contains longitudinal records from more than 300 million patients and 16.3 billion clinical encounters. Epic is deploying Cosmos as the training substrate for Comet, announced in 2025, which aims to simulate future patient health trajectories and generate probabilistic risk predictions embedded directly in clinical workflows. Epic also partnered with Microsoft to integrate DAX Copilot natively into Epic workflows; clinicians using it report a 70% reduction in documentation-associated burnout and fatigue.
The strategic risk is that a closed ecosystem, while providing deep integration, limits interoperability with third-party AI innovation and constrains organizations that want AI portability.
Oracle Health: the most aggressive architectural bet
Oracle Health (formerly Cerner) has made the most consequential architectural commitment among legacy vendors. In Q3 2025 it launched an all-new AI-native ambulatory EHR built from the ground up on Oracle Cloud Infrastructure — not a modernization of the Cerner platform but a clean-sheet redesign. An inpatient version is targeted for 2026.
The new platform is architected as a voice-first, semantic AI system, with a clinical AI agent coordinating tasks across care delivery and operations. Capabilities include AI-generated patient summaries at the start of each clinical day, voice-commanded medication reconciliation, real-time ambient documentation, and intelligent scheduling. Oracle describes the foundation as a "semantic AI" layer capable of reasoning across the full patient record without extracting data to external systems.
The critical unknown is adoption velocity. Whether health systems migrate, adopt in parallel, or wait will define the competitive landscape through 2027.
athenahealth: pragmatic integration at scale
athenahealth has deployed AI incrementally across its cloud-native platform rather than pursuing architectural transformation. athenaAmbient, part of what it calls a reimagined AI-native encounter workflow, layers ambient documentation, anticipatory clinical intelligence, and workflow streamlining into the existing ambulatory EHR. Roughly 30–40% of clients have fully opted into its AI-native feature suite.
Its advantage is that it was never a client-server system and required no ground-up rebuild. Its limitation is scale: it serves primarily ambulatory and smaller health system customers, ceding the enterprise inpatient market.
The challenger ecosystem
The most architecturally innovative activity is in the challenger segment — purpose-built platforms and AI infrastructure layers targeting specific care settings or workflow components.
| Platform | Position | Signal |
|---|---|---|
| Elation Health | AI-native EHR for primary care | Acquired Aster (2025) for agentic voice automation; 76% of surveyed clinicians reported higher-quality care; $108.5M raised |
| Canvas Medical | Developer-first "operating system for medicine" | FHIR-native APIs and scripting extensibility; targets value-based and direct primary care |
| Commure | AI-native enterprise RCM and ambient layer | 40M+ ambient appointments, $25B+ annual claims processed; 93.3 KLAS First Look score |
| Nabla | Clinical AI Layer inside existing EHRs | Deployed natively in Epic and others across 130+ organizations; Nabla Connect ships ambient to any EHR in days |
The strategic pattern worth noting: the challengers with the fastest traction are not asking health systems to replace their EHR. They are delivering AI-native capability as an embedded layer on top of the systems that already exist — which is a bet that the integration layer, not the record system, is where value now accrues.
The capability stack: what AI-native actually delivers
Ambient documentation
The most mature and measurable capability. Real-time speech capture during the encounter, NLP conversion into structured clinical content, and write-back into the record without a post-visit documentation session. The evidence base is unusually strong for healthcare IT: 20–40% documentation burden reduction, 13-point burnout reduction inside 30 days, and payback measured in weeks rather than fiscal years.
Predictive clinical decision support
Cosmos-derived tools, Oracle's Clinical AI Agent, and third-party risk stratification engines now deploy ensemble models — gradient-boosted trees and transformer architectures — trained on population-scale datasets. Deployed systems have demonstrated 19% reductions in ED utilization and 10:1 ROI on risk stratification platforms, along with material improvement in preventive care capture.
FHIR-native architecture
The clinical AI ecosystem is fundamentally dependent on FHIR. Models require longitudinal, semantically consistent, machine-readable data, and FHIR R4/R5 with SMART on FHIR authorization is the only standardized mechanism for that access across heterogeneous environments.
Projections indicate 90% of U.S. health systems have adopted FHIR APIs for patient data access. Adoption rate and implementation fidelity are not the same thing. The practical state of FHIR is version fragmentation (R4 dominant, R5 lagging), inconsistent resource completeness across vendors, and wide variation in SMART on FHIR authorization implementation. Any organization planning AI workloads on FHIR data should conduct an implementation fidelity assessment before assuming vendor API claims translate into inference-quality pipelines.
Population health intelligence
AI-native platforms extend prediction beyond the encounter into continuous population monitoring — identifying at-risk patients outside active care episodes to drive proactive outreach, care gap closure, and resource allocation.
Regulatory and compliance landscape
ONC HTI-1 final rule
Published in January 2024, HTI-1 established the most consequential AI-specific requirements yet imposed on certified health IT. Its most significant provisions target predictive decision support interventions — AI and ML tools that generate scores, classifications, or recommendations used in clinical decision-making.
- ▸Algorithm transparency — developers must publish source attributes and performance data, including training data characteristics, performance metrics, and intended use populations
- ▸Fairness and bias disclosure — known limitations must be disclosed, including performance disparities across race, ethnicity, sex, and age
- ▸User controls — clinicians must be able to disable or override predictive DSI outputs
- ▸Compliance deadline — certified developers were required to comply by December 31, 2024 for all deployed AI features
For health systems procuring AI-embedded capability, HTI-1 creates a due diligence obligation: vendors must demonstrate transparency compliance before those capabilities can legitimately be deployed in certified workflows.
HTI-2 and what follows
The HTI-2 proposed rule extends governance further into interoperability standards (USCDI+ enhancements), EHR reporting, and expanded information blocking provisions. The direction is unambiguous: AI embedded in health IT is not a compliance-free innovation zone.
FDA Software as a Medical Device
The FDA's December 2024 final guidance on Predetermined Change Control Plans establishes how AI-driven clinical decision support can modify behavior post-market without a new marketing submission for each change. As of August 2024, 97% of FDA-cleared AI-enabled devices moved through the 510(k) pathway. The January 2025 draft guidance on AI-Enabled Device Software Functions Lifecycle Management further defines expectations for post-market monitoring, drift detection, and bias surveillance.
The practical implication: any AI-embedded EHR feature crossing from administrative decision support into clinical diagnosis or treatment recommendation is potentially subject to SaMD oversight, and that boundary remains an active area of interpretation.
21st Century Cures Act and information blocking
The interoperability architecture AI-native EHRs depend on is directly enabled by the Cures Act's information blocking provisions. Vendors who obstruct FHIR-based data access for AI applications may be in violation. This is the primary leverage point for organizations seeking data portability from legacy vendors while evaluating a transition.
SWOT: AI-native EHR adoption
| Strengths | Weaknesses | |
|---|---|---|
| Internal | Ambient documentation demonstrably reduces burnout (13–40% in published studies); predictive CDS generates measurable ROI (19% ED utilization reduction, 10x ROI documented); FHIR-native architecture enables scalable model deployment; longitudinal modeling improves care coordination; purpose-built inference outperforms bolted-on modules on latency and fidelity | Immature platforms lacking the clinical depth of legacy systems; limited track record in high-acuity inpatient settings; integration engineering debt in multi-EHR environments; high implementation complexity without modern integration infrastructure |
| External | Opportunities | Threats |
| HTI-1/2 transparency requirements disadvantage vendors with opaque AI modules; FHIR mandates accelerating interoperable data access; $505B market growth sustaining platform innovation; burnout crisis creating urgency for ambient deployment; value-based payment incentivizing predictive risk stratification | Regulatory ambiguity at the FDA SaMD boundary creates compliance exposure; bias risks can amplify health disparities without governance; AI vendor lock-in may exceed legacy EHR lock-in; high migration cost and clinical disruption; consolidation may concentrate AI capability in one or two vendors |
Critical analysis: the risks, realities, and rhetoric
The narrative around AI-native EHRs is compelling and, in important respects, accurate. But the enthusiasm in vendor communications has outpaced both the evidence base and operational reality. Healthcare IT leaders deserve an unvarnished assessment.
The data quality problem beneath the inference layer
AI inference is only as reliable as the data it consumes. An estimated 20–30% of clinical data in production EHR environments contains errors, inconsistencies, or gaps sufficient to materially affect model performance. Data entered under time pressure, structured to satisfy billing rather than clinical accuracy, and fragmented across systems is a degraded input to any inference engine. AI-native architecture solves none of this; it assumes you have already solved it.
For organizations that have not invested in data governance — PHI classification, FHIR resource completeness, master patient index accuracy, cross-system patient matching — migration will not produce the outcomes vendors promise. The platform can only optimize what it can see, and what it can see is the product of a decade of documentation practices shaped by billing requirements.
Algorithmic bias is systemic risk, not theoretical concern
Peer-reviewed work from KFF, CDC, and Nature Medicine documents that models trained on historical clinical data systematically underperform for non-white patients, women, elderly patients, and patients from lower socioeconomic backgrounds. A 2024 systematic review found meaningfully lower accuracy for racial and ethnic minorities in sepsis prediction, readmission risk, and pain management.
The mechanism is well understood: training data reflects historical clinical decisions that themselves embody structural inequity. A model trained to replicate historical decisions will replicate the disparities inside them. HTI-1 transparency is a necessary first step and an insufficient one without active subgroup performance monitoring at deployment.
Vendor lock-in: the new dependency trap
The Cures Act was designed to prevent vendors from trapping health systems in proprietary data ecosystems. AI-native platforms introduce a newer and more durable form of lock-in: model dependency. When a platform trains predictive models on your patient data, those models become assets of the platform — reachable through its APIs, not portable to a competitor.
A health system that invests three to five years of patient data into a vendor-specific risk model and then migrates does not merely face data migration cost. It faces the loss of model performance calibrated to its own population. FHIR portability governs structured clinical data; it does not govern model artifacts, training parameters, or inference APIs. Negotiate model portability and federated learning provisions at contract time, when you still have leverage.
The labeling problem
Not every platform marketed as AI-native meets the architectural definition. Some vendors apply the label to near-legacy databases with modern API layers and third-party modules. The due diligence requirement is architectural, and the five questions above are the fastest way to establish where a platform actually sits.
The integration gap that cannot be skipped
The most underestimated challenge is integration. Health systems do not operate a single EHR. They operate an ecosystem: an acute care EHR, an ambulatory EHR, a pharmacy system, an imaging platform, an LIS, an HIE connection, a claims feed, and often a population health platform — each with its own data model, API capability, and HL7/FHIR version. An AI-native EHR delivers its value proposition only when it can see the full patient record, and that requires bidirectional, semantically consistent integration across every system in the ecosystem.
For most organizations that architecture does not exist and cannot be assumed. It must be engineered, governed, tested, and maintained.
An AI-native readiness scorecard
Before a platform decision, score the eight dimensions below. Any dimension at Level 1 is a program risk that no vendor selection will resolve.
| Dimension | Level 1 — Exposed | Level 2 — Developing | Level 3 — Ready |
|---|---|---|---|
| FHIR implementation fidelity | Vendor claims accepted at face value | Resource coverage tested for key domains | Profile-level conformance validated with production data |
| Master patient index accuracy | Unknown duplicate rate | Duplicates measured, remediation ad hoc | Measured, governed, and trending down |
| Clinical data quality | No structured assessment | Assessed in isolated domains | Continuously monitored with owners per domain |
| Integration architecture | Point-to-point interfaces | Partially consolidated engine | Governed transaction layer with observability |
| PHI governance | Classification incomplete | Classified, retention informal | Classified, minimized, retention enforced technically |
| AI governance | No model inventory | Inventory exists, review informal | Inventory, subgroup monitoring, override audit trail |
| Model portability | Not addressed in contracts | Raised in negotiation | Contractually secured with export path |
| Clinical change capacity | Deployment treated as IT rollout | Champions identified | Workflow redesign owned by clinical operations |
A 90-day sequence that de-risks the decision
Days 1–30 — Establish ground truth. Inventory every system holding clinical data. Test FHIR endpoints against real patient scenarios rather than vendor documentation. Measure MPI duplicate rate. Build the AI model inventory you may not know you already have.
Days 31–60 — Model the target state. Define where inference should run, what data it requires, and which integrations must exist for that data to arrive intact. Price the integration work separately from the platform license; conflating the two is the most common budgeting failure in this category.
Days 61–90 — Prove it on one workflow. Select a single high-friction workflow — ambient documentation for one specialty, or one risk stratification cohort — and instrument it end to end: latency, data completeness, clinician override rate, subgroup performance. A platform that succeeds here has earned the enterprise conversation. One that cannot will not improve at ten times the scale.
The Brandywine Consulting Partners perspective
This is an integration problem first
Brandywine Consulting Partners operates exclusively in healthcare IT. Our work is defined by FHIR and HL7 interoperability engineering, Azure-native clinical data infrastructure, and AI/ML risk stratification model development — the specific capabilities that determine whether an AI-native EHR investment realizes its value or founders on integration debt.
That exclusivity gives us a clear view of a pattern we see consistently: organizations evaluate AI-native EHRs as a platform selection exercise when the determinative work sits upstream of the selection. The vendor decision matters. The integration readiness underneath it matters more, because it sets the ceiling on what any platform can deliver.
What we tell clients
- ▸Audit before you procure. Implementation fidelity, not vendor claims, determines what your inference layer can see.
- ▸Treat PHI minimization as architecture. The less PHI that must persist outside the system of record, the smaller the breach surface and the cleaner the governance story. This is the same principle behind our transaction layer work: move the data, don't accumulate it.
- ▸Buy inference, not lock-in. Model portability provisions are cheap at contract signature and effectively unavailable afterward.
- ▸Instrument fairness from day one. Subgroup performance monitoring is not a compliance artifact; it is how you find out your model is failing a population before a patient does.
- ▸Sequence for clinical adoption. Every reliable outcome in this space came from workflow redesign paired with technology, never technology alone.
Where we help
We support health systems and digital health organizations across FHIR and HL7 interoperability engineering, integration readiness assessment, clinical data quality and governance programs, AI/ML risk stratification development, and zero-retention transaction layer architecture that keeps PHI out of intermediate storage entirely.
If your organization is evaluating an AI-native EHR — or has already committed and needs the integration foundation to make it work — start a conversation with our team.
Frequently asked questions
Is an AI-native EHR migration necessary to get ambient documentation benefits? No. The strongest documented burnout and ROI results come from ambient layers deployed inside existing EHRs. Migration is a separate decision with a separate business case, and conflating the two inflates the cost of an outcome you can reach sooner.
How do we know whether our FHIR APIs are good enough for AI workloads? Test them against real clinical scenarios, not the conformance statement. Check resource completeness, historical depth, update latency, and authorization behavior under production load. Most gaps surface within a week of honest testing.
What is the single most common failure mode? Buying an inference platform for an ecosystem that cannot supply it with complete data. The platform then underperforms, clinicians disengage, and the organization concludes AI does not work — when the integration layer was the constraint the whole time.
Does HTI-1 apply to us or only to our vendor? The certification obligations sit with the developer, but the deployment consequences sit with you. If a vendor cannot produce transparency documentation, you cannot defensibly deploy that capability in a certified workflow.
Where does zero-retention architecture fit? Anywhere PHI would otherwise accumulate in intermediate systems to feed inference. Designing the transaction path so data moves without being stored shrinks both breach surface and audit scope. See our insights library for the full pattern.
Sources
- ▸Grand View Research, Artificial Intelligence in Healthcare Market Report, 2026–2033
- ▸Fortune Business Insights, Electronic Health Records (EHR) Market
- ▸SkyQuest Technology, Global Electronic Health Records Market
- ▸Oracle Corporation, Oracle Ushers in New Era of AI-Driven Electronic Health Records, August 13, 2025
- ▸TechTarget / SearchHealthIT, Oracle Health Releases AI-Powered Ambulatory EHR, 2025
- ▸TechTarget / SearchHealthIT, AI-Native EHRs: A New Era or Just a New Label?, 2025
- ▸Microsoft, A Year of DAX Copilot, September 26, 2024
- ▸Nuance Communications, DAX Copilot Embedded in Epic — General Availability, January 2024
- ▸Elation Health, Elation Health Acquires Aster for Agentic AI in Primary Care, 2025
- ▸Elation Health, Clinicians Disclose AI Is Helping Them Deliver Higher Quality Primary Care, 2025
- ▸Commure, Commure Ambient AI Scores High Marks in KLAS First Look Report, CHIME, 2025
- ▸Nabla, Nabla Launches Nabla Connect, 2025
- ▸HHS ONC, HTI-1 Final Rule, Federal Register, January 9, 2024
- ▸Akin Gump, ONC Steps Into AI Regulation — Predictive Decision Support Interventions, 2024
- ▸FDA, AI-Enabled Device Software Functions: Lifecycle Management (Draft Guidance), January 6, 2025
- ▸FDA, Clinical Decision Support Software — Guidance
- ▸PMC12492056, Use of Ambient AI Scribes to Reduce Administrative Burden and Clinician Burnout, 2025
- ▸JAMA Network Open, Ambient AI Scribes — What Is the Return on Investment?, 2025
- ▸Healio, Ambient AI Scribe Significantly Reduces Burnout Among Clinicians, November 2025
- ▸Advisory Board, Are Ambient AI Tools the Key to Reducing Physician Burnout?, February 2026
- ▸KFF, The Growing Use of Artificial Intelligence in Health Care and Implications for Disparities, 2024
- ▸CDC, Health Equity and Ethical Considerations in Using AI in Public Health and Medicine, 2024
- ▸PMC11542778, Bias in Medical AI: Implications for Clinical Decision-Making, 2024
- ▸Fire.ly, The State of FHIR in 2025
- ▸Epic Systems, Epic Showcases Industry-Leading AI, Genomics, and Interoperability at HIMSS 2025
- ▸Fierce Healthcare, Epic Unveils AI Solutions for Clinicians, Patients and RCM, 2025
- ▸Menlo Ventures, 2025: The State of AI in Healthcare
- ▸Hart Health, How to Reduce Vendor Lock-In and Maximize Data Portability, March 2025
- ▸Bluebrix Health, Who Really Owns Your EHR Data?, 2025
Ready to put this into practice?
BCP partners with healthcare and life sciences leaders to translate strategy into shipped, secure systems. Let's talk about your next initiative.
Talk to BCP