The problem list tracks a patient's conditions over time. An encounter diagnosis records what you evaluated or treated at one visit. Claims and risk adjustment run on the encounter. A condition that sits only on the problem list has not been documented for that visit, and it will not hold up in an audit.
That gap is where independent practices lose money. Chronic conditions go unreported, diagnoses get carried forward without support, and coders end up sending queries. This guide explains the difference, shows where the two records drift apart, and gives you a workflow to keep them aligned.
TL;DR
- Problem list = cumulative, longitudinal record of active and significant conditions. Encounter diagnosis = the conditions addressed at a single visit.
- A problem list is not acceptable stand-alone documentation for risk adjustment. The visit note must show the provider considered the condition.
- In a study of Community Health Center patients, only 59.4% of chronic conditions appeared in both sources, so relying on either one leaves gaps.
- Use MEAT (Monitored, Evaluated, Assessed, Treated) to decide what is active, and review the list on a schedule.
- Auditing the two records against each other is the fastest way to find missed revenue and unsupported codes.
Table of Contents
- What each record is for
- The line between a problem and a diagnosis is blurry
- Why a problem list alone does not support a claim
- The two records rarely match
- How lists get stale
- Where the revenue and compliance risk sits
- A workflow that keeps both records honest
- Our perspective
- See your own gap in 30 days
- FAQ
- Sources
What each record is for
An encounter diagnosis is a time-bound record of the reason, outcome or treatment in a single clinical interaction. A problem list is a cumulative record of a patient's chronic, active or significant conditions, meant to support continuity across visits. One describes the "now" of a visit. The other describes ongoing status.
The idea is not new. The problem list traces back to Lawrence Weed in the 1960s, when continuity of care was its main purpose. Billing was never part of the design.
| Problem list | Encounter diagnosis | |
|---|---|---|
| Scope | Across visits | One visit |
| Purpose | Continuity, clinical context | Reason for visit, services, billing, quality attribution |
| Typical vocabulary | SNOMED CT | ICD-10-CM |
| Who maintains it | Any clinician with access, plus the patient history | The billing provider, in the note |
| Audit weight | Supporting context only | The documentation payers review |
The vocabulary row matters. The federal interoperability standards treat the two as separate data elements in USCDI. Encounter diagnoses drive performance measurement, attribution and the specific reason for a visit, while problems give longitudinal context. Practices need to map both correctly, or quality metrics and performance reports come out skewed.
The line between a problem and a diagnosis is blurry
Don't expect a clean binary. The openEHR Clinical Knowledge Manager describes the difference as a continuum rather than a fixed threshold. As supporting findings such as labs or pathology accumulate, a problem is promoted to a formal diagnosis. Different specialists may also see the same condition differently.
For your practice, the lesson is practical. A clinician can be right to put "fatigue" on the problem list on Monday and "iron deficiency anemia due to chronic GI blood loss" in the assessment on Friday. Billing needs the second statement, in the note, with the reasoning.
Why a problem list alone does not support a claim
Coders cannot assign codes from uninterpreted findings. Per AHIMA guidance, accurate coding requires a clear diagnostic statement from the provider. Many problem lists are filled by pick-lists that map automatically to codes that may not match what the clinician meant. An unvalidated, auto-populated list often needs a physician query before anyone can use it.
Risk adjustment is stricter. Citing a 2008 CMS Risk Adjustment User Group answer that still applies, one coding educator explains that problem lists are not acceptable stand-alone documentation. HCC capture requires a face-to-face encounter, and the note must do more than name the condition. MEAT is a common guide. The source is a secondary summary, so confirm current rules with the plans and programs you work with.
What MEAT looks like in a note
- Monitored: "Glucose log reviewed, fasting values 110 to 140."
- Evaluated: "A1c 8.2% today, up from 7.6%."
- Assessed: "Type 2 diabetes with hyperglycemia, not at goal."
- Treated: "Increase metformin to 1,000 mg twice daily; referral to dietitian."
One element is often enough to show the provider addressed the condition, but the assessment should still read as a clinical judgment, not a copied list.
The two records rarely match
A 2022 study of more than 1.1 million patients across 545 Community Health Centers compared the sources. Only 59.4% of chronic conditions appeared in both, 28.4% appeared only on problem lists, and 12.2% only in encounter diagnoses. This was a community health center population, not independent physician offices, so your numbers will differ. The direction is the point: each source misses things the other catches.
What that looks like in a practice:
- On the list, not in the visit. A patient with COPD on the problem list is seen for a sore throat. COPD is not addressed, so it should not be on that claim. If you did address it, the note has to show it.
- In the visit, not on the list. A new diagnosis of CKD stage 3 is assessed and treated, but nobody promotes it to the active list. The next provider never sees it.
- On the list, resolved in reality. A fracture, a pneumonia or a pregnancy from years ago still shows as active.
How lists get stale
AHIMA experts link much of the clutter to the Meaningful Use era. Systems were built to meet a problem list requirement without the functionality to keep the list useful. The result is lists stuffed with inactive, resolved or carried-forward conditions. The same guidance says EHR templates often prompt for body systems and history that support a high E/M level but do not prompt for diagnostic specificity or for promoting a condition to the list.
The fix AHIMA's authors point to is simple: treat the list as a dynamic document, managed with the same rigor as the visit note, not a store of every code ever assigned.
Where the revenue and compliance risk sits
Missed capture. If a chronic condition you manage never reaches the encounter diagnosis, it never reaches the claim. Our guide on 90 day HCC documentation planning covers how to find those gaps.
Unsupported capture. Codes pulled from a stale list with no visit support are the ones auditors question. AHIMA also flags a legal angle: system-generated abstractions can carry different legal implications than provider-authored documentation, so an unvalidated list is a liability in an audit or a dispute.
Vague specificity. "Anemia" on the list and "anemia" in the note leaves the coder guessing. AHIMA's documentation guidance stresses linking language such as "due to" and "manifested by". See our ICD-10 specificity guide for physician practices for examples.
Care management programs. Chronic care management and similar programs depend on a clear picture of the patient's conditions. Our piece on chronic care management documentation lists the records Medicare expects. The same discipline applies to transitional care management, principal care management and advance care planning: the program's own requirements must be in the visit or service record, not implied by the list.
A workflow that keeps both records honest
- Diagnose in the note first. The provider states the condition, its cause and its status in the assessment. Do not rely on a pick-list label alone.
- Code from the encounter. Only conditions addressed at the visit go on the claim. Use the problem list as context, not as a source of codes.
- Apply MEAT to every chronic condition you report. If you cannot point to the Monitoring, Evaluation, Assessment or Treatment, do not report it for that visit.
- Promote new diagnoses. When a problem is confirmed, add it to the active list with the same wording as the assessment.
- Resolve what is resolved. Mark conditions inactive or resolved, with a date, rather than deleting them.
- Review at set points. Reconcile the list at annual wellness or chronic care visits, and at intake for new patients.
- Audit the gap. Compare list entries to encounter diagnoses by provider. Large mismatches show where templates or habits need work.
- Govern the mapping. Review the EHR's code mapping on a schedule, as part of a yearly coding review, and keep a record that you did.
Quick example
A 68-year-old patient has "diabetes" and "kidney disease" on the list. At a visit for a foot wound, the note addresses only the wound. The claim should carry the wound diagnosis and any condition the provider also managed that day. If the provider adjusted insulin because of the infection, the note must say so, and the diagnosis should be specific: type 2 diabetes with the relevant complication, not "diabetes." Kidney disease stays on the list for context, but it is not reported unless it was addressed.
Our perspective
We look at this gap daily in practice data. The problem list and the encounter record are two views of the same patient, and when they disagree, the practice pays for it in one of two ways: revenue never billed, or revenue billed on thin support.
Most physicians are not careless. Their EHR makes the easy path the wrong one. A pick-list adds a code that was never the doctor's words. A template carries a diagnosis forward. The note looks complete and the coder still has no diagnostic statement to use.
So we do not ask physicians to document more. We compare what the list says with what the visit supports, per provider and per payer, quantify the difference, and draft corrections the physician can sign in one click. Fixing it as part of the normal day beats a retrospective cleanup after a denial or audit letter.
If you do one thing this quarter, pull ten charts per provider and check that every reported chronic condition has MEAT in that visit's note. You will learn more than from any policy memo.
— Elena
See your own gap in 30 days
If you want the numbers for your practice, our free 30-day Revenue Leakage Audit scans your EHR data for coding, documentation and charge-capture gaps before claims go out, and reports them per provider and per payer. You can also read how we work with practices on the HIMShield site.
For related reading, see how documentation shapes pay in why documentation affects reimbursement and what supports a claim in medical necessity documentation examples.
FAQ
Can I bill from the problem list?
No. Bill from the documentation of the visit. A problem list shows history and context, and for risk adjustment it is not acceptable as stand-alone support. If a listed condition was managed at the visit, document that in the assessment and plan.
Should every chronic condition be on the problem list?
Every active, clinically significant chronic condition should be. The list should not hold resolved or irrelevant items. Use MEAT as a test: a condition that is not monitored, evaluated, assessed or treated probably belongs in history, not the active list.
Who is responsible for keeping the problem list accurate?
In most practices it is shared, which is why it drifts. Assign ownership: the treating provider confirms entries, and staff flag changes. Set a review point such as the annual visit, and document that review.
Do encounter diagnoses and problems use different code sets?
Often, yes. Federal interoperability guidance expects SNOMED CT for problems and ICD-10-CM for encounter diagnoses, so both need correct mapping in your EHR. Claims use ICD-10-CM.
What should I do about a diagnosis I think is outdated?
Don't delete it silently. Confirm with the patient and clinical data, mark it resolved or inactive with a date, and note the reason in the visit record.
Sources
- Representing Diagnoses, Medplum
- Definition, History, and Use of the Problem List, AHIMA
- Encounter Diagnosis, Interoperability Standards Platform
- Evaluation Archetype: Problem/Diagnosis, openEHR Clinical Knowledge Manager
- HCC Coding: The Problem with Coding from Problem Lists
- Comparing ascertainment of chronic condition status with problem lists versus encounter diagnoses
- Curing Inherited EHR Ailments, AHIMA
- Cut Through the ICD-10 Noise with Documentation Guidelines, AHIMA