By 2024, over 90% of private doctors’ offices and virtually all community hospitals in the United States were using electronic health record (EHR) systems according to the ONC. In 2026, these first-generation EHRs (that took over a decade to see near-universal adoption) are already showing their age.
Originally envisioned as a way to increase the quality of patient care by gathering multiple types of clinical data in one centralized location, EHR systems have faced criticism over the years, including for costing physicians valuable time [JAMA Internal Medicine, 2014]. A 2022 study reported “ambivalent assessments toward EHR” among physicians [Health Services Insights, 2022].
Today, AI-native EHR systems promise to overcome the shortcomings of “traditional” EHRs while capitalizing in a big way on all of the data that medical professionals have spent countless (sometimes overtime) hours collecting. AI-native EHRs can (among other things) generate notes by listening to patient encounters, automate medical coding and billing, and allow clinicians to review patient records through AI-powered chat instead of clunky user interfaces.
Keep reading to learn uses cases for AI in EHR systems, what makes an EHR AI-native (as opposed to AI-powered or AI-enabled), and why an AI native EHR matters in 2026. We’ll also guide you through the tough decision of build versus buy, share an engineering blueprint for building your own AI native EHR platform, and show you how the Intellias pragmatic approach to AI engineering can help your AI healthcare initiative succeed.
What is an AI native EHR?
An AI native electronic health record (EHR) — or electronic medical record (EMR) — system is designed around artificial intelligence from the outset. An EHR with AI at its core is meaningfully different from one that is AI-powered or AI-enabled:
| AI–native | AI–powered | AI–enabled | |
| Architecture | Cloud-native, single-instance/multi-tenant architecture | Traditional EHR architecture | Traditional EHR architecture |
| Role of AI | AI shapes architecture, data model, and UX
AI does the heavy lifting and asks clinicians to approve (documentation, coding, decision support, etc.) |
AI runs one or more key functions
AI offers assistance, but clinicians still do most of the heavy lifting |
AI as optional modules
Clinicians do the heavy lifting; optional AI add-ons may help with specific tasks |
| User experience | Voice-driven, conversational UX | Traditional UX + separate integrated AI dashboards/panels | Traditional UX + optional AI via plug-ins or separate dashboards/panels |
| Scalability | New AI features can be added seamlessly | Custom integration required for each new AI feature | Custom integration required for each new AI feature |
In an AI native EHR, AI is integrated throughout core workflows: clinical documentation, medical coding, appointment scheduling, revenue cycle management. Additionally, the AI native platform operates on a cloud-native, single-instance/multi-tenant architecture, which enables safe and scalable deployment of AI models across the entire system.
Why is an AI-native EHR necessary in 2026?
The healthcare industry continues to face significant challenges in 2026:
- While the American Medical Association reports a decline in physician burnout for the fourth year in a row, burnout among medical professionals remains an ongoing challenge [AMA, 2026].
- Administrative and regulatory burdens continue to plague medical practices, with the Medical Group Management Association citing prior authorization, Medicare Advantage requirements, and quality reporting as the main issues that redirect time and attention from patient care to administrative tasks [MGMA, 2026].
- Meanwhile, operating costs keep rising. Among respondents to an MGMA Stat poll, the average cost increase from 2025 to 2026 was 11% [MGMA, 2026].
In this climate, AI-native EHRs are a breath of fresh air. The next generation of EHRs that have true native intelligence promise:
- Ambient listening and summarization
- Automated coding and billing
- Real-time clinical decision support integrated into the daily workflow
- Built-in predictive analytics (individual patient and population-level)
- Chat-based access to patient records
- Faster, more flexible adoption of future AI capabilities
When considering what actually makes an EHR AI native, it’s important to acknowledge that the ability to transcribe and structure patient encounters is only the starting point — after all, this is something that can be achieved by retrofitting AI into a traditional EHR system. In terms of this particular capability, what differentiates an AI native EHR from a mere AI scribe is that passive listening becomes the primary way in which patient information is captured (as opposed to a clinician typing on a keyboard). Moreover, AI native EHRs can automatically transcribe conversations and create notes that meet billing and medical coding requirements.
But the benefits of an AI-native platform go even further. In an interview for the podcast HealthTech Remedy, Paul Brient, Chief Product Officer at athenahealth, explains how this works in athenaOne:
After we generate the note, we’ll list all the diagnoses that you might have talked about during that conversation and go back into the medical record and find any diagnoses that the patient had that you might not have talked about that should be part of the encounter. If you’ve suggested a medication, it will tee up the medication orders and any other orders or referrals that you might have discussed and have those all available
Meanwhile, Stanford Medicine has shown how care providers can chat with medical records through their ChatEHR software. It empowers clinicians to more efficiently track down patient medical data within the precious minutes they have available. As Nigam Shah, MBBS, PhD, Chief Data Science Officer at Stanford Health Care, explains: “ChatEHR is secure; it’s pulling directly from relevant medical data; and it’s built into the electronic medical record system, making it easy and accurate for clinical use.”
Convinced that an AI native EHR could help you mitigate perpetual pain points in the healthcare workflow? Let’s consider your options for acquiring one.
Is it better to build or buy an AI native EHR?
Once you’ve decided to go in for an AI native EHR, you’re faced with another dilemma: Should you pay for a commercially available platform or build your own from scratch, either in-house or with an experienced HealthTech software development partner?
When it comes to existing EHR platforms, there are three top incumbents: Epic, Oracle, and athenahealth. Let’s briefly look at how these platforms use AI, then consider the benefits and drawbacks of buying versus building your own custom software.
- Does Epic EHR use AI? AI is embedded throughout the Epic EHR system in the form of the Emmie assistant for patients, Art for clinicians, and Penny for revenue cycle and operations. These assistants are embedded into the Epic platform, but Epic is not truly an AI native EHR.
- Does Oracle use AI? In Q3 2025, Oracle released an all-new ambulatory Oracle Health EHR built from the ground up on Oracle Cloud Infrastructure. The company claims that it has a “sematic AI foundation” and offers physicians “AI-fueled intelligence.”
- Does athenahealth use AI? athenahealth markets their athenaOne EHR as both an “AI-native platform” and an “AI-powered EHR” with AI features that support the company’s “reimagined AI-native encounter workflow.”
Benefits and drawbacks of buying vs building an AI-native EHR platform
| Buy a commercially available platform (Epic, Oracle, athenahealth) | Build your own AI-native EHR in-house | Build your own AI-native EHR with a development partner | |
| Benefits | Fast to deploy, security/compliance is vendor’s responsibility, lowest upfront cost | Full control, IP ownership | Full control, IP ownership, fast access to talent, less risk compared to in-house development |
| Drawbacks | Vendor-locked, generic, limited differentiation | Scarce talent, expensive, slow and high-risk development process | Slower than buying a commercial solution |
Building an AI-native EHR with an experienced software development partner is often the best choice, as it gives you the advantages of a custom build without the downsides (and higher costs) of in-house development.
Why building an AI native EHR with a HealthTech development partner is often the right middle ground
Partnering with an experienced software development vendor to build an AI native EHR results in faster development, less hassle, and cost savings compared to assembling an in-house team with the necessary skills. At the same time, it gives you full control over and ownership of intellectual property and allows you to build an EHR that is uniquely suited to your organization’s needs.
When you rely on a third-party EHR platform, you likely cannot influence the vendor’s feature development timeline or strategic direction. Want to become an early adopter and try out the latest AI capabilities? You may not have that opportunity.
Another significant advantage of building your own AI native EHR with a partner is that you can seamlessly integrate it into your existing infrastructure. Interoperability can be challenging when working with a third-party platform, and you can’t predict how future updates may affect compatibility.
Regulatory and security requirements are an additional consideration. An experienced HealthTech vendor can assist you with meeting relevant compliance requirements. When combining AI and EHR technologies, you should pay close attention to matters of security, as AI in EHR has access to vast amounts of protected health information (PHI) as well as sensitive institutional data.
In short, there are many advantages to building a custom AI native EHR. Now, let’s look at a blueprint for building your own.
Engineering blueprint for an AI native EHR

Reference architecture
As a starting point, an AI native EHR should be built on a cloud-native, multi-tenant SaaS foundation (with a single-tenant option for customers who require dedicated infrastructure).
A multi-tenant SaaS model is ideal for an EHR/EMR because:
- A multi-tenant system can learn by identifying patterns across hundreds of clinics (while keeping PHI private). A single-tenant system trains (more slowly) on one organization’s data.
- Updates (including those that are security-critical) can be pushed to all customers instantly. Single-tenant requires maintenance on individual instances, which is time-consuming at scale.
- Infrastructure costs are spread across more customers, lowering the cost of access to an AI native EHR.
Data layer
For an AI native EHR to be effective, it requires a unified clinical data model, FHIR/HL7 interoperability, and real-time data pipelines.
First, data must be consistent. If blood pressure is labeled in different ways across different systems, for instance, AI won’t know that these fields represent the same metric.
Example: AI can clean patient-generated health data (PGHD) to reduce the volume of data streams and avoid duplicate records when integrating PGHD with EHR [AMIA Joint Summits on Translational Science proceedings, 2024].
Second, data must be shareable between platforms. This is addressed through FHIR/HL7 compliance.
HL7 is a set of technical standards for exchanging health information among software systems, while HL7 International is the organization that produces these and other standards. FHIR is a widely used API-focused standard for exchanging healthcare resources.
Finally, data needs to be shared in time so it’s available when and where it’s needed — thus, the importance of real-time pipelines. Data pipelines can process data in three ways:
- Batch processing on a schedule (nightly, hourly, etc.)
- Near real-time processing (within minutes, but not instantaneous)
- True real-time / event-driven processing (via subscription model)
Under the FHIR standard, a “Subscription” resource lets an EHR request to be notified whenever new patient data comes in. This avoids the need for the EHR to constantly recheck a database, and it makes sure that the AI can flag early signs of a medical emergency.
AI layer
The AI layer of an AI native EHR typically covers the following set of functionalities:
Ambient documentation
Ambient documentation is when AI passively listens to patient–clinician conversations, automatically generates structured clinical notes based on those conversations, and places those notes directly in the EHR for the clinician to review. This saves medical personnel from typing and clicking through templates.
Auto-coding
Auto-coding means that an AI native EHR automatically suggests or assigns the correct billing codes (ICD-10, CPT, HCPCS) based on documented diagnoses and procedures. It does this by analyzing clinical notes and patient encounters in real time, making it an extension of ambient documentation. Clinicians can review AI-suggested codes in a click. This process reduces manual coding errors and claim denials while accelerating revenue cycle turnaround.
Predictive analytics
Artificial intelligence and machine learning algorithms can rank and sort clinical and administrative tasks so that clinicians can efficiently focus their efforts. In clinical patient care, this can look like analyzing vitals, medications, and labs to predict complications; assigning patients to risk-based cohorts; surfacing relevant, time-sensitive data from patient histories; and sending only high-priority, contextual alerts to physicians in order to avoid alert fatigue. On the administrative side, AI-powered predictive analytics can flag claims at risk of denial as well as pending authorizations that may impede access to care.
RAG over clinical records
RAG, short for Retrieval-Augmented Generation, lets an AI model consult a patient’s medical records in order to provide informed responses. This happens in three steps:
- The RAG system requests relevant patient data from the EHR (for example, using FHIR APIs).
- The RAG pipeline injects this data into the AI prompt.
- The AI model uses the patient data when responding to the prompt and provides outputs that are verifiable and reference the patient’s medical records.
| Generic AI model | AI with RAG | |
| Knowledge source | Static training data with cut-off date | Live EHR data at query time |
| Patient-specific answers | No access to patient records | Pulls data from patient chart |
| Hallucination risk | High (invents facts) | Lower (grounded in retrieved data) |
| Updates | Retraining required | Instant via API updates |
Note: It is important that clinicians are able to verify the basis for any recommendation, which RAG can facilitate by citing source records.
Agentic workflows
An agentic workflow brings together all of the AI functionalities mentioned above into a cohesive system that operates autonomously in order to achieve specific goals.
Example of an agentic workflow:
- Start of the visit — When a patient arrives for an appointment, an AI agent queries the EHR via RAG and pulls recent labs.
- During the visit — An ambient documentation agent listens to the patient encounter and writes up clinical notes as it unfolds.
- After the visit — Yet another AI agent auto-codes the encounter, generates a prescription based on encounter notes, and sends the patient a message via the portal.
- Billing — An AI billing agent submits a claim with supporting documentation attached, monitors for adjudication, and drafts an appeal letter with relevant clinical evidence pulled via RAG (in the event of claim denial).
| EHR type | Can it support agentic workflows? |
| AI-native | Yes — AI has native access to all data, workflows, and APIs. Agents move freely across the system. |
| AI-powered | Partially — agents can access some AI tools, but legacy architecture creates seams. An agent might draft a note but can’t directly submit a claim or schedule a follow-up without hitting a legacy system boundary. |
| AI-enabled | No — the bolt-on AI features are isolated. There’s no unified architecture for an agent to traverse. |
Quick tip: Assessing performance of AI models for medical tasks
The Center for Research on Foundation Models (CRFM) at Stanford University has published the MedHELM framework to assess LLM performance for medical tasks. MedHELM is intended to provide “a more nuanced and medically relevant assessment of AI capabilities in healthcare settings.”
AI guardrails
In healthcare, decisions can have life or death consequences, yet applications of AI in the healthcare domain are often (still) experimental. Researchers at Duke AI Health note concerns “about the potential for malfunctioning AI tools to compromise quality and safety or to reinforce existing inequities” [Duke AI Health].
AI guardrails are necessary to keep AI EHR systems safe and ensure quality of care:
- Clinician-in-the-loop — AI-drafted medical notes, billing codes, and care suggestions must be approved by a clinician.
- Model governance — AI models should be audited regularly and retrained as needed to maintain performance and avoid model drift.
- HIPAA/HITRUST — Compliance frameworks set standards for data encryption, data access, breach notifications, and sharing of data with vendors.
- Security protocols and data security — Role-based access controls, multi-factor authentication, audit logging, end-to-end encryption, and network segmentation help to prevent unauthorized access or data breaches.
- Auditability — AI outputs and automated actions should be logged, with timestamps, sources, and user IDs.
Note: It is important that AI guardrails do not compromise the EHR solution’s usability, user-friendliness, reliability, customizability, and interoperability.
Now that we’ve covered the building blocks of an AI native EHR, we’ll show you how the Intellias approach to AI-native engineering delivers real business value — and clear outcomes — in healthcare and beyond.
The Intellias Pragmatic AI approach to AI-native engineering
Why do 85% of AI projects fail? Because AI is treated as an add-on for marketing appeal. The solution is Pragmatic AI — focusing on how AI adds real value every day.
Intellias takes a pragmatic approach to AI in healthcare. Our focus on delivering measurable clinical and operational value helps us avoid sinking time and money into AI initiatives that sound impressive on paper but ultimately stall and wind up among the 85% of AI projects that fail.
Intellias delivers pragmatic AI solutions through:
AI Pods
AI Pods are cross-functional, embedded delivery squads that own outcomes. At Intellias, AI Pods are lean, cross-functional teams of three to five people plus AI agents. In an AI Pod, every team member has a product mindset, and roles within the team blur. Designed for speed and outcomes, AI Pods replace traditional team structures, enabling faster iteration, reduced cycle times, and rapid delivery of working product increments.
Senior-heavy teams
Intellias has deep expertise in HealthTech and senior machine learning (ML) talent. Our teams are senior-heavy and ready to roll from day one.
Lifecycle partnership
At Intellias, we partner with clients throughout the entire product lifecycle. Intellias specialists will guide you through the full AI native EHR development journey:
Discovery → Architecture → Build → Scale → Ongoing evolution
Planning an AI native EHR or embedding AI into your existing health platform? Talk to Intellias Pragmatic AI experts.