How Do You Build an AI-Native Custom EHR?

Epic launched native AI Charting in February 2026, embedded clinical documentation that listens to patient visits and drafts notes. athenahealth unveiled an AI-native EHR redesign and is piloting a Model Context Protocol (MCP) server for AI-to-EHR communication. DeepCura announced itself as the first “agentic native” healthcare company eight days ago.

The biggest players are treating AI as architecture rather than a feature. And here’s what that means if you’re building a custom clinical platform: if you design AI into the system from day one, you’re ahead of Epic. If you bolt it on later, you’re behind Athenahealth.

We say “every custom EHR we build is AI-native from day one.” This is the piece that explains what that actually means.

I. What Does “AI-Native” Actually Mean for a Custom EHR?

There’s a meaningful difference between “AI-powered” and “AI-native.”

A. AI-powered (bolted on):

• EHR built first, AI features added later
• AI operates as a separate service calling into the EHR via API
• Data must be extracted, processed externally, and results pushed back
• AI can’t react to clinical events in real time
• This is what most “AI EHR” products actually are

B. AI-native (designed in):

• AI capabilities are part of the data model and event architecture
• Clinical events trigger AI processing automatically (no polling, no batch jobs)
• AI reads and writes FHIR resources directly
• Structured data is designed for AI consumption from day one
• PHI handling, audit trails, and compliance are built around AI workflows
• This is what Epic, athenahealth, and we are building toward

Speechmatics (2026) put it well: “2026 will mark a decisive transition from transcription as a standalone feature to Voice AI as the foundational intelligence layer within AI-native EHR platforms.” The shift isn’t adding AI. It’s rebuilding the architecture around AI.

C. Five categories of clinical AI in custom EHR:

1. Ambient clinical documentation — AI listens, drafts notes
2. Clinical decision support (CDS) — real-time guidance at point of care
3. Predictive analytics — risk scores, care gaps, deterioration alerts
4. NLP for unstructured data — coding suggestions, chart summarization
5. Intelligent workflow automation — smart routing, auto-scheduling

The advantage of building custom: you choose which patterns to implement and design the architecture around them. Off-the-shelf EHRs retrofit these patterns onto existing databases. Custom builds design the database for them.

II. What Are the 5 AI Architecture Patterns for Custom EHR?

Each pattern solves a different clinical problem. Most AI-native EHRs implement 2-3 from launch and add others post-deployment.

A. Pattern 1: Ambient Clinical Documentation

What it does: Listens to the patient-provider conversation, generates structured clinical notes (SOAP, H&P, progress notes) in real time.

The problem it solves: Physician burnout peaked at 62.8% in 2021 and was still at 45.2% in 2023. A quality improvement study across 6 health systems found ambient AI reduced burnout from 51.9% to 38.8% — a 13-point drop. Mass General Brigham saw a 21.2% absolute reduction in burnout prevalence.

The numbers on time savings:

• 8.5% less total EHR time for clinicians using ambient AI
• 15% decrease in time spent composing notes specifically
• 35% decrease in after-hours documentation at St. Luke’s
• 15% increase in face time with patients

Architecture:

Audio capture -> Speech-to-text (Whisper/Speechmatics/vendor) 
  -> LLM processing (structure into SOAP/FHIR) 
  -> FHIR Encounter note (DiagnosticReport/DocumentReference) 
  -> Provider review UI 
  -> Signed note stored in EHR

Custom EHR advantage: In an off-the-shelf EHR, the ambient scribe is a third-party integration. In a custom build, it’s native — the transcription pipeline writes directly to FHIR resources, the provider review UI is designed into the charting workflow, and the note structure matches your clinical templates from day one.

Our proof: We built a custom clinical platform for a functional medicine practice with AI-powered SOAP notes using voice-enabled transcription. 70% reduction in documentation time. Deployed in 90 days. The AI wasn’t an add-on — it was the reason for building custom.

B. Pattern 2: AI-Powered Clinical Decision Support

What it does: Provides real-time clinical guidance during the encounter — drug interaction alerts, diagnosis suggestions, care gap identification, HCC coding flags.

Architecture:

Clinical event (new medication, diagnosis entered, order placed)
  -> Event trigger (FHIR Subscription / Medplum Bot)
  -> AI logic (rule engine + ML model)
  -> CDS response (alert, suggestion, block with reason)
  -> Clinician UI (banner, sidebar, inline suggestion)

Our proof: We built a custom preoperative clinical decision support tool integrated with a major EHR platform. Missed labs dropped from 15% to 2% — not through more manual checks, but through automated CDS that flagged missing pre-op labs before the patient reached the OR.

C. Pattern 3: Predictive Analytics

What it does: Risk scores at the population and patient level — readmission risk, clinical deterioration, care gap prediction, no-show probability.

Architecture:

Scheduled or event-triggered batch process
  -> Pull patient data from FHIR store (Conditions, Observations, Encounters)
  -> ML model inference (readmission risk, deterioration score)
  -> Write RiskAssessment FHIR resource
  -> Surface in clinician dashboard or care management workflow

When to use: Population health programs, value-based care models, care management platforms. Not real-time at point of care (that’s Pattern 2). Batch or near-real-time for proactive interventions.

D. Pattern 4: NLP for Unstructured Clinical Data

What it does: Processes free-text clinical notes, scanned documents, and narrative reports to extract structured data — ICD-10 code suggestions, problem list updates, medication reconciliation from discharge summaries.

Architecture:

Unstructured text (clinical note, discharge summary, referral letter)
  -> NLP pipeline (entity extraction, negation detection, relation mapping)
  -> Structured FHIR resources (Condition, MedicationStatement, Procedure)
  -> Clinician review (accept/reject extracted entities)
  -> Structured data stored in EHR

Custom EHR advantage: The NLP pipeline writes directly to your FHIR data model. No intermediate translation layer. Extracted entities are immediately available in the structured record, not trapped in a separate analytics database.

E. Pattern 5: Intelligent Workflow Automation

What it does: Automates clinical and operational workflows based on AI-driven decisions — smart scheduling (match patient to optimal provider), auto-routing (referrals, lab orders, follow-ups), predictive staffing, intake prioritization.

Architecture:

Trigger (appointment requested, lab result received, care plan milestone)
  -> AI logic (matching algorithm, routing rules, priority scoring)
  -> Automated action (schedule appointment, route referral, create task)
  -> Human override (clinician can modify any automated action)

Our proof: We built a pediatric care platform with an AI-driven scheduling engine — provider-patient matching based on age, visit type, and location. 45% reduction in scheduling friction. 70%+ of families using the mobile app weekly.

III. How Do You Build AI into a Medplum-Based EHR?

If you’re building on Medplum, the AI integration pattern uses three native capabilities:

A. Medplum Bots for Server-Side AI Logic

Bots are TypeScript functions that run server-side in response to FHIR events. For AI:

• Trigger: New Encounter created, lab result arrives, medication prescribed
• Bot logic: Call LLM API (OpenAI, Anthropic Claude, open-source model), process response, map to FHIR resources
• Output: Write CDS alert, generate note draft, update risk score

Bots run inside Medplum’s event loop. No external polling. No webhook latency. This is the architectural advantage for real-time AI.

B. FHIR Subscriptions for Event-Driven AI Triggers

Define what events trigger AI processing:

• Subscription on Encounter create -> trigger ambient documentation bot
• Subscription on MedicationRequest create -> trigger drug interaction check
• Subscription on Observation create (lab result) -> trigger abnormal result flagging

C. LLM Integration Patterns

Three approaches, depending on PHI sensitivity:

1. Cloud LLM with de-identified data: Strip PHI, send to OpenAI/Claude, process response, re-associate with patient. Lowest latency, simplest architecture, requires robust de-identification.
2. On-premise LLM: Run open-source model (Llama, Mistral) on your own infrastructure. PHI never leaves your environment. Higher latency, more infrastructure, maximum data control.
3. BAA-covered cloud LLM: Use a provider with a signed BAA (available from some vendors). PHI in transit is covered contractually. Middle ground — verify BAA terms carefully.

PHI handling for AI is non-negotiable. Every AI interaction that touches patient data needs:

• Audit logging (what data was sent, to which model, what response came back)
• De-identification or BAA coverage
• Patient consent tracking (if applicable under state law)
• The same security architecture as any other PHI processing

Medplum’s 2026 roadmap includes MCP support and AI tooling — meaning the platform is explicitly building toward AI-native workflows. athenahealth’s MCP server pilot validates this direction.

IV. When Does AI in Your EHR Trigger FDA SaMD Classification?

This is the question every AI-native EHR builder needs to answer early. Get it wrong and you’re either over-regulated (wasting time/money on unnecessary FDA clearance) or under-regulated (shipping a medical device without clearance).

The baseline: EHR software is NOT SaMD (Software as a Medical Device). EHRs are specifically excluded from FDA device regulation.

The exception: AI features within an EHR may trigger SaMD classification if they independently analyze clinical data and provide diagnostic or treatment recommendations without meaningful clinician review.

January 2026 FDA guidance update: The FDA revised its CDS guidance to be more permissive. Key changes:

• Risk scores (e.g., cardiovascular event risk, post-op complication risk) now qualify for enforcement discretion
• Differential diagnosis suggestions qualify if a clinician review is required
• If only one option is clinically appropriate and all other criteria are met, the FDA will exercise enforcement discretion

The boundary in practice:

Architecture principle: Design every AI feature with a clinician-in-the-loop. The AI suggests, the clinician decides. This keeps you in CDS territory (exempt or enforcement discretion) rather than SaMD territory (requires FDA clearance). Build the review step into the UI don’t just add a disclaimer.

V. Why Is AI Documentation the Killer Feature for Custom EHR?

Of the 5 patterns, ambient clinical documentation has the clearest ROI and the fastest adoption curve. Here’s why:

The problem is massive and measurable:

• Physicians spend an estimated 2 hours on documentation for every 1 hour of patient care
• Burnout peaked at 62.8% in 2021. Still at 45.2% in 2023.
• 10%+ of US physicians have already adopted ambient scribing solutions (McKinsey, 2025)

The results are consistent across studies:

• Burnout: 51.9% -> 38.8% across 6 health systems (PMC, 2025)
• Burnout: 52.6% -> 30.7% at Mass General Brigham (21.2% absolute reduction)
• EHR time: 8.5% less total time with ambient AI (JMIR, 2026)
• Note composition: 15% less time specifically (JMIR, 2026)
• After-hours documentation: 35% decrease at St. Luke’s
• Patient face time: 15% increase at St. Luke’s

The custom EHR advantage: In a commercial EHR, the ambient scribe is a third-party product (Abridge, Nuance DAX, Nabla) that integrates via API and pushes notes into the EHR’s documentation system. The note format is whatever the vendor provides, and you configure it to match your templates.

In a custom EHR, the ambient documentation is native to your clinical workflow. The transcription pipeline writes directly to your FHIR Encounter resources. The note structure matches your specialty’s documentation patterns from day one. The review UI is part of your charting experience, not a separate app. That’s why our functional medicine build achieved 70% documentation time reduction — the AI wasn’t fitting into someone else’s workflow. It was the workflow.