How to Stop AI-Template Errors From Undercoding New Patient Visits

17 min read
Clinician Reviewing Visit Documentation Screenshot

Ever had a new patient note look polished, organized, and "complete", then the visit still gets under-coded? That's not bad luck. That's a system problem.

AI templates are great at producing notes that look finished. They are not great at making sure the documentation actually supports the level billed. I've seen this exact mess: a beautiful note, full ROS, tidy exam, neat plan, and weak MDM, generic HPI, or templated defaults that don't match what really happened in the room. The result? Lost revenue, coder frustration, denial risk, malpractice exposure concerns, and a note that won't hold up if anyone looks closely.

Educational disclaimer: This article is for education only and is not legal, billing, coding, compliance, malpractice, financial, or tax advice. E/M rules, payer expectations, audit standards, contract terms, and malpractice or regulatory risk can vary by setting, insurer, employer, and jurisdiction. For patient-specific, claim-specific, or organization-specific decisions, use your coding team, compliance lead, healthcare attorney, malpractice carrier, revenue-cycle leaders, and other qualified professionals.

This article is for educational purposes only. It is not financial advice, not legal advice, and not tax advice. Figures vary by individual circumstances, consult a qualified professional before acting.

Why AI-Template Errors Under-Code New Patient Visits, and Why It Matters

Here's the plain answer: AI-template errors happen when the note and the code stop matching reality.

In practice, that usually means one of three things:

  • Required elements are missing
  • Template defaults don't reflect the actual encounter
  • Documentation and billing logic don't map cleanly

That's the trap. The note looks full. The support isn't there.

Common examples:

  • HPI says "patient presents with cough" but leaves out duration, severity, failed home treatment, or worsening features
  • ROS says "reviewed" but doesn't include relevant negatives for the actual complaint
  • Exam is autopopulated with normal findings the clinician didn't specifically perform or document
  • Assessment and plan mention one level of concern, while the MDM reads like a low-acuity routine visit

Why does this matter? Because undercoding isn't just a reimbursement problem.

It creates:

  • Revenue leakage from billing below the supported level
  • Denial risk when medical necessity isn't obvious
  • Audit exposure when the billed level and documentation don't line up
  • Workflow drag because coders kick notes back and clinicians re-open charts after hours

The fix is not "trust AI less" in some vague way. The fix is operational.

Use:

  1. A reliable documentation-to-code checklist
  2. Better template defaults and prompts
  3. AI as an assist, never the authority

That's how you stop the undercoding.

The Billing Model in Plain English: What New Patient Visits Require

For new patient E/M visits, your level selection depends on the documentation framework your practice uses and how the encounter supports it. The major drivers are the familiar ones:

  • History
  • Examination
  • Medical decision making (MDM)

And here's the part people get wrong: a note can be long without being supportable.

A templated note may auto-fill:

  • past medical history text
  • ROS language
  • a normal multi-system exam
  • generic assessment/plan phrasing

That creates the classic false reassurance problem: looks complete, isn't complete.

If the note doesn't reflect what you actually elicited, reviewed, considered, and did, then it doesn't support the level. Period.

The biggest weak point is usually MDM. AI often softens complexity. It downgrades uncertainty. It turns "I was worried about pneumonia vs PE and ordered testing because this patient had worsening dyspnea and tachycardia" into "discussed options, monitor symptoms." That's not just bland writing. That's lost coding support.

Your standard should be simple:

  • AI can draft
  • The clinician must verify facts
  • The final note must support medical necessity
  • The selected level must match the documented encounter

Here's the workflow in one picture:

Where AI-Template Errors Enter: 7 High-Frequency Under-Coding Traps

These are the traps I'd look for first. They're the repeat offenders.

1) Generic HPI copied from template

This is the king of undercoding errors.

The note says:

  • "headache for several days"
  • "rash worsening"
  • "abdominal pain evaluated"

But it leaves out:

  • duration
  • severity
  • location
  • modifying factors
  • prior treatment response
  • progression
  • red flags

That strips context from the problem. Coding support drops fast.

2) ROS or exam sections are filled with "reviewed" language

This is lazy template behavior. Sometimes clinician-driven. Sometimes AI-driven. Always risky.

If the patient presents with chest pain and your note has a broad ROS but no relevant negatives like exertional symptoms, dyspnea, diaphoresis, syncope, or pleuritic features, the note may still look polished, but it's weak where it matters.

3) MDM is under-supported

This is the big one.

The note fails to clearly state:

  • problem complexity
  • data reviewed
  • tests ordered
  • differential considered
  • management risk
  • why the plan matters

If you started a medication, adjusted therapy, ordered imaging, reviewed outside records, or considered escalation, say so plainly.

4) "Bad defaults" make the encounter look simpler than it was

A lot of AI tools default toward:

  • minimal data
  • routine assessment
  • low-risk plan
  • conservative wording

That's a bad habit. If the encounter was more intense, the note needs to show it.

5) Assessment and plan don't match

Classic example:

  • Assessment says "bronchitis"
  • Plan orders chest imaging and documents concern for pneumonia
  • AI inserts "rule out pneumonia" somewhere else
  • Risk level reads as routine

Now the note is internally inconsistent. Coders hate this. Auditors notice it.

If your practice uses time-based or complexity-dependent rules in certain workflows, AI may omit the exact timeline or effort statements needed to support the chosen level. It's not enough to have "extensive discussion" if nothing specific is documented.

7) Template version drift

One attending uses Template A. Another uses Template C. The APP team uses an older AI prompt. Suddenly note quality varies wildly across the clinic.

That's not a user problem. That's governance failure.

The highest-leverage fixes are obvious:

  • Generic HPI
  • ROS/exam mismatch
  • Weak MDM

Start there.

Build a Clinician-First Quality Gate: A Documentation Checklist That Prevents Under-Coding

If you only do one thing after reading this, do this.

Build a short mandatory Quality Gate before the note is signed.

Not a 40-item bureaucratic monster. A fast, clinician-usable check tied directly to E/M support.

Your quality gate should ask 4 things

1. What is the presenting problem, and why is it new?

Document:

  • the chief concern
  • problem context
  • why this encounter required evaluation now
  • what changed, worsened, failed, or raised concern

If it's a new patient visit, don't let the note read like a refill check.

2. Did I capture problem-specific history and data?

Check for:

  • symptom duration
  • severity
  • progression
  • modifying factors
  • prior treatment response
  • relevant positives
  • relevant negatives

If the complaint is dizziness, the note should not read like a generic URI template. Obvious. Yet I see it all the time.

3. Is the exam relevant to the complaint?

The goal is not "more exam text." The goal is relevant exam support.

Ask:

  • Does the exam reflect the presenting problem?
  • Are abnormal findings documented if present?
  • Are the relevant normal findings included?
  • Did AI claim a system exam I didn't actually perform?

That last one matters. A lot.

4. Does the MDM explicitly support the level?

This is where undercoding usually lives.

Make the clinician verify:

  • Number/complexity of problems addressed
  • Data reviewed or ordered
  • Risk of management

And don't accept vague wording.

Bad:

  • "Discussed options"
  • "Monitor"
  • "Follow up as needed"

Better:

  • "Progressive unilateral headache with nausea and photophobia, refractory to OTC therapy, concerning for migraine vs secondary cause; neuro exam nonfocal; ordered imaging due to change in pattern and red-flag persistence."
  • "Reviewed prior urgent care note from 2 days ago and CBC from same visit; symptoms worsening despite initial supportive treatment."
  • "Started prescription therapy and provided strict return precautions due to escalating symptom burden."

That's coding support. Clean. Specific. Defensible.

Use explicit evidence statements

AI tends to soften or blur the exact pieces coders need. Force clarity in these areas:

  • Data reviewed: what, from where, when
  • Data ordered: labs, imaging, records, referrals
  • Clinical reasoning: why that test or therapy was chosen
  • Risk: medication changes, monitoring needs, urgency, escalation avoided or considered

Run a two-pass workflow

This works far better than expecting the first draft to be perfect.

Pass 1: AI drafts quickly

  • pulls structure together
  • organizes note sections
  • saves typing time

Pass 2: clinician runs the quality gate

  • fixes HPI
  • verifies ROS
  • trims fake exam language
  • strengthens MDM
  • confirms assessment-plan consistency

Simple. Fast. Effective.

Checklist Overlay on Medical Chart Review

A practical 8-point quality gate

Use this as your starting version:

  1. Chief problem is stated clearly
  2. Why today is documented
  3. Problem-specific HPI has enough detail
  4. Relevant positives and negatives are present
  5. Exam supports the complaint
  6. MDM names the actual diagnostic/management thinking
  7. Data reviewed/ordered is explicitly listed
  8. Assessment and plan use the same problem language

If even one of those fails, the note isn't code-ready.

Turn Templates Into Guardrails: How to Configure AI Prompts and Defaults to Match Reality

Bad templates create bad notes. That's not a mysterious AI issue. That's a build issue.

Here's how to fix it.

Stop using one-size-fits-all templates

A single universal "new patient visit" template is usually too generic to support coding well.

Use problem-based templates instead:

  • headache
  • rash
  • abdominal pain
  • dyspnea
  • diabetes follow-up
  • new hypertension evaluation

Each template should require clinician input for the details that actually determine support.

Change the prompt from "summarize" to "reconstruct from evidence"

This is the upgrade most teams miss.

Don't ask AI:

  • "Summarize this visit"

Ask AI:

  • "Build a note only from verified clinician-provided facts"

Required structured fields should include:

  • Problem 1, 2, 3
  • Status and change from baseline
  • Relevant history
  • Specific exam findings
  • Data reviewed
  • Data ordered
  • Decision rationale
  • Risk statements

Add refusal rules

This is non-negotiable.

Your AI should not:

  • invent ROS items
  • imply exam components were performed
  • claim records were reviewed if they weren't
  • label risk as low by default

Instead, configure it to:

  • ask targeted questions
  • leave blanks
  • flag unsupported sections

That's what a safe drafting assistant does.

Bind assessment to plan

If the assessment says "possible community-acquired pneumonia," the plan should align:

  • chest imaging
  • treatment decision
  • return precautions
  • follow-up interval

Don't let the AI call the problem one thing and treat another. That mismatch wrecks coding support.

Prevent automatic downshifting

This is a subtle but costly problem. AI often defaults to softer language:

  • "stable"
  • "routine"
  • "monitor"
  • "low concern"

If the clinician indicates urgent evaluation, worsening symptoms, treatment failure, or escalation risk, the AI should be prohibited from downgrading the tone or risk language.

Here's the ideal process:

MDM That Holds Up: Practical Writing Patterns to Support Correct Level Selection

If your team's MDM is vague, fix that first. It's usually the fastest route to better coding accuracy.

Use MDM evidence sentences

A strong MDM sentence should include:

  • problem complexity
  • data reviewed or ordered
  • decision made
  • risk tied to management

Examples you can adapt:

  • "New exertional chest discomfort with associated dyspnea and symptom progression over 1 week; differential includes cardiac and pulmonary causes; ECG obtained and chest imaging ordered due to change in baseline and red-flag features."
  • "Persistent febrile cough despite prior supportive treatment; reviewed outside urgent care note and prior CBC; started antibiotic therapy based on worsening clinical course and concern for bacterial process."
  • "Poorly controlled diabetes with recent home glucose escalation; medication regimen adjusted and short-interval follow-up arranged due to monitoring needs and risk of deterioration."

A few rules. Important ones:

  • If you ordered labs, don't say you already reviewed them
  • If you reviewed prior records, mention the source
  • If risk increased because you initiated or adjusted therapy, say that plainly
  • If you chose not to escalate care, document why

Workflow and Governance: Rollout Without Disrupting Care

Don't launch this clinic-wide on day one and hope for the best. That's how good ideas die.

Start with a pilot

Pick:

  • one clinic
  • one specialty
  • one documentation workflow

Then measure:

  • baseline undercoding patterns
  • denial reasons
  • coder escalation frequency
  • documentation-to-billing discrepancies

Run the new process for 4-8 weeks.

Create a real feedback loop

Your coders and billing leads know where notes fail. Use that information.

Ask:

  • Which section failed?
  • HPI?
  • ROS?
  • exam relevance?
  • MDM?
  • assessment/plan mismatch?

Then update prompts and templates based on actual misses. Not guesses.

Train clinicians on what AI gets wrong

Keep this practical. Nobody wants a lecture deck full of buzzwords.

Show anonymized examples of:

  • generic HPI that cost level support
  • fake-complete ROS sections
  • weak MDM language
  • inconsistent assessment and plan phrasing

That gets attention fast because people recognize their own notes in those examples. Sometimes painfully.

Define ownership

This part needs to be explicit:

  • Clinicians own clinical facts and final sign-off
  • AI assists with drafting
  • Coders verify documentation-to-code mapping
  • Leaders monitor compliance, outcomes, and template version control

Common Failure Scenarios, and Fixes You Can Apply This Week

Here are the quick wins.

Scenario: AI writes a complete-looking ROS but omits relevant negatives

Fix: Make clinicians select problem-specific ROS items, and force AI to mirror selections only.

Scenario: MDM says "discussed options; will monitor"

Fix: Require explicit documentation of:

  • decision points
  • data reviewed or ordered
  • why the plan was chosen
  • what risk drove follow-up or treatment

Scenario: Assessment and plan drift apart

Fix: Lock problem titles and map plan actions to those exact problem names.

Scenario: Undercoding continues even after edits

Fix: Audit a sample of missed notes and identify which E/M driver keeps failing. Then fix the template or prompt at that exact point. Don't rewrite everything if the real problem is just weak MDM language.

Get Your Team to Code-Ready Notes in 14 Days

Here's the plan.

Step 1: Today

  • Implement a short quality gate checklist for all new patient notes

Step 2: Within 1 week

  • Update AI prompts and templates so they verify evidence before asserting ROS, exam, or MDM content

Step 3: Within 2 weeks

  • Run a small pilot audit with coder feedback and fix the top failure point first

That's enough to start. You do not need a grand transformation plan. You need one checklist, better prompts, and a closed feedback loop.

Share the checklist internally. Schedule one coder-clinician review session. Pick one specialty to pilot. Start there.

Team Huddle With EHR Documentation Checklist
01 Why does my note look complete, but the claim gets under-coded?

Because complete-looking and code-supported are not the same thing. AI templates are good at filling sections, but they often miss the problem-specific facts and explicit MDM support that determine the level. If the note has generic HPI, vague MDM, or ROS/exam language that isn't tied to the complaint, the code drops even if the note looks polished.

02 Can AI drafting still be allowed if it sometimes changes clinical details?

Yes, but only with guardrails. The clinician has to own the facts, and the AI has to be limited to evidence-based drafting. If the source inputs don't support a ROS item, exam element, or MDM claim, the AI should ask a targeted question or leave the section incomplete. Anything else is sloppy and dangerous.

03 What's the fastest way to reduce undercoding without retraining everyone?

Use a short mandatory quality gate and a two-pass workflow. Let AI create the first draft fast, then make the clinician verify the HPI, relevant ROS/exam, and MDM support before signing. That change usually works faster than a giant template rebuild because it targets the parts that actually drive undercoding.

04 Our MDM is often vague, what documentation pattern actually improves coding accuracy?

Use MDM evidence sentences. State the problem complexity, what data you reviewed or ordered, what decision you made, and what risk was tied to that decision. "Discussed options" is useless. "Reviewed prior note, ordered imaging due to worsening symptoms, initiated therapy, and arranged urgent follow-up" is supportable.

05 How should we handle templates that include ROS/exam defaults?

Remove defaults that imply something was performed or relevant when it wasn't. Replace them with clinician-selectable, problem-specific items and make the AI reflect only what was actually provided. Default ROS/exam text is one of the dumbest ways to create fake completeness.


Keep reading

View more