Chapter 4: Medical Records and Documentation: The Clinical Foundation of Every Code

"The chart is not a record of what happened. The chart is what happened. Everyone who was in the room will be gone, and the chart will still be there." — constructed; said in some form by every auditor who has ever trained a coder

Overview

Three chapters have discussed at length what a service is worth and who decides. Not one of them has looked at the thing all of it rests on.

A code is not a description of what a provider did. A code is a description of what a provider wrote. Those are different, they are frequently different in ways that cost money, and the entire professional discipline of coding lives in the gap between them.

This is the hardest idea in the book for people arriving from clinical work, and it is worth stating without softening. A nurse who becomes a coder can look at a note, know exactly what happened in that room because they have been in that room a thousand times, and be forbidden from coding it. Not discouraged. Forbidden. Because the code is an assertion about the record, made to a payer, under a certification — and if the record does not support it, the assertion is false regardless of whether the underlying care occurred.

This chapter teaches you to read a record the way a coder reads it: for what is documented, what is implied, what is missing, and what an auditor sitting in a different building two years from now would say about the difference.

It also contains the note that the rest of this book is built on. The March 14 office note for Account 10-4471 appears here in full. Every code assigned in Parts II and III comes out of it, the appeal in Chapter 30 is won on its contents, and the risk-adjustment lesson in Chapter 36 turns on a sentence it does not contain.

In this chapter, you will learn to:

• Identify the sections of the major document types and what each contributes
• State the signature and attestation requirements, and recognize the defects that void a claim
• Distinguish a compliant amendment from an improper alteration
• Recognize cloned documentation and explain the risk it creates
• State what the record must contain before a code may be assigned
• Write a compliant query and identify a leading one
• Read a note line by line, extracting what is supported and naming what is not

Learning Paths

🎓 Certification — §4.4 and §4.9 are directly examinable; signature requirements and query compliance appear on every credential. §4.7 is the conceptual foundation for every coding question you will ever be asked.

💼 New Coder — This is the most important chapter in Part I for you. §4.10 is the skill. Read the Encounter's note until you can see its structure without effort.

💵 Biller / AR — §4.4 and §4.5 explain a whole category of denial you will otherwise find baffling. Skim §4.2 and §4.3.

🏥 Practice Manager — §4.6 (cloning is an organizational problem, not an individual one) and §4.9 (the query process is something you build, not something that happens).

4.1 What a coder is actually reading

A medical record is the collection of documentation about a patient's care. In an electronic health record it is not a document at all but a set of linked data: notes, orders, results, images, medication lists, flowsheets, messages, and a great deal of automatically generated material that nobody wrote.

A coder does not read all of it. A coder reads the documents that establish what was wrong and what was done about it, for a specific encounter.

Two structural observations before any of the detail.

Outpatient coding is encounter-based; inpatient coding is stay-based. An office coder reads one note and codes one visit. An inpatient coder reads a stay — days of documentation from many authors — and produces a set of codes describing the admission as a whole. The skills overlap; the reading does not. Chapter 33 covers the inpatient discipline.

The note you are reading was not written for you. It was written to communicate clinical information to other clinicians, to satisfy a documentation template the provider did not design, and — increasingly — to satisfy an electronic health record that will not close the encounter until certain fields are populated. None of those purposes is "help a coder select a code." A great deal of what follows in this chapter is about reading around that fact without ever inventing what is not there.

4.2 The anatomy of an office note

The traditional structure is the SOAP note — Subjective, Objective, Assessment, Plan — and although modern electronic records rarely label the sections that way, the underlying architecture is almost always still there.

⚠️ Where Claims Die

Coding from the chief complaint.

A new coder reads "chief complaint: chest pain," codes R07.9, and moves on. But the assessment says "gastroesophageal reflux disease, likely cause of presenting chest pain." The chief complaint is the patient's reason for coming; the assessment is the provider's conclusion, and in the outpatient setting a confirmed diagnosis replaces the symptom that led to it.

Chapter 9 §9.6 gives the rule precisely. The habit to build now: read the assessment first, then read backward to see whether it is supported. The assessment is where the diagnosis lives; the rest of the note is the evidence for it.

4.3 The operative report, the H&P, and the discharge summary

The operative report

The document a surgical coder lives in. A complete operative report contains:

• Preoperative diagnosis — what the surgeon believed before the procedure
• Postoperative diagnosis — what the surgeon believed after, which may differ and, where it does, usually governs
• Procedure(s) performed — the surgeon's own naming, which is a starting point and not a code
• Surgeon, assistant(s), anesthesia type
• Findings — what was actually encountered
• Description of the procedure — the narrative of what was done, in order
• Estimated blood loss, specimens, complications, disposition

The heading is not the code. A surgeon who writes "Procedure: laparoscopic cholecystectomy" has told you very little. The body of the report tells you whether a cholangiogram was performed, whether the procedure was converted to open, whether adhesions required significant additional work, whether a second procedure was performed through the same incisions, and whether anything was biopsied. Every one of those changes the coding, and none of them appears in the heading.

Read the body. Always. Even when the heading looks obvious. Chapter 17 §17.3 builds this into a method.

The history and physical (H&P)

Required before most surgical procedures and on hospital admission. It establishes why the patient is being admitted or operated on, what their baseline is, and what comorbidities exist. For inpatient coding it is where a great deal of the secondary-diagnosis picture originates — Chapter 33 §33.3 shows what a documented comorbidity is worth.

The discharge summary

The narrative of an entire admission: why the patient came in, what was found, what was done, what happened, what the diagnoses were at discharge, and what the plan is.

It is the most useful single document in an inpatient record and it is not sufficient by itself. Inpatient coding is done from the complete record, because a condition documented in a progress note on day three and omitted from the discharge summary is still a documented condition. A coder who codes only from the discharge summary will systematically undercode.

The rest of the record

Six more document types, each with a specific thing a coder takes from it and a specific way it misleads.

That nursing row deserves a second look, because it is the most commonly misunderstood rule in the table and it comes up constantly in inpatient coding.

The general principle is that code assignment is based on the documentation of the patient's provider — the physician or other qualified practitioner legally accountable for the diagnosis. The Official Guidelines carve out narrow exceptions where a specific detail may be taken from another clinician's documentation. Pressure ulcer stage is the standard example: a wound care nurse's staging may be used, provided the provider has documented the pressure ulcer itself.

The shape of the rule is worth memorizing because it recurs: another clinician may supply a detail; only the provider may supply the diagnosis. Chapter 9 §9.10 gives the general form, and Chapter 33 applies it where it matters most.

⚠️ Where Claims Die

Coding a definitive diagnosis from a pathology or radiology report in the outpatient setting.

The sequence is always the same. A lesion is excised on Tuesday. The operative note says "lesion, nature undetermined." Pathology returns Friday: malignant.

The temptation is obvious and the answer is not. In the outpatient setting the diagnosis coded for the Tuesday encounter reflects what was documented and known at the time of that encounter. The pathology result supports the diagnosis going forward and, in many circumstances, is coded on the encounter where the results were reviewed and acted upon.

The trap is that the wrong answer feels more accurate. Coding the malignancy on Tuesday describes reality better than coding the undetermined lesion. It also describes a fact that was not known, was not documented, and did not drive Tuesday's care. Chapter 10 §10.4 works the neoplasm case in full; the habit to build now is to ask what was documented at the time of this encounter, not what turned out to be true.

(The inpatient rules differ, as they do on uncertain diagnoses generally. Chapter 9 §9.5.)

4.4 Signatures, dates, attestations, and why they void claims

Here is a category of denial that has nothing to do with clinical content and destroys claims anyway.

Documentation must be authenticated. The provider who furnished the service must sign the documentation, and the signature must be legible or identifiable, dated, and attributable to a specific individual. In an electronic record this is generally satisfied by an electronic signature with a name, credential, and timestamp.

The failures that generate denials:

Missing signature. The note exists, the care happened, and nobody signed. On review, the service is treated as undocumented. Some contractors permit a signature attestation statement — a separate signed statement identifying the author and attesting that they furnished and documented the service — but attestation cannot be used to add content, only to authenticate it, and it cannot be used to supply a missing signature on an order, which is a distinction contractors have been explicit about.

Illegible or unidentifiable signature. More of a paper-era problem, still alive in scanned documents.

Stamped signatures. Generally not acceptable for Medicare.

Signature after the fact, undisclosed. A note signed weeks later is not automatically invalid, but one back-dated to appear contemporaneous is a different thing entirely. §4.5.

The order problem. For many services — diagnostic tests, therapy, durable medical equipment — a signed order from the treating provider must exist, and its absence is a separate defect from any problem with the note. A laboratory or imaging provider whose claim is reviewed and who cannot produce the ordering provider's signed order will lose, no matter how appropriate the test was.

⚖️ Compliance Check

Signature requirements are set out in the Medicare Program Integrity Manual (Publication 100-08), and they are among the most mechanically applied standards in medical review — a reviewer does not need clinical judgment to determine that nothing is signed.

Three practical consequences:

This is the cheapest audit finding there is, which means it is the one contractors find first, and a pattern of unsigned documentation invites a broader look.

The remedy is prospective, not retrospective. You cannot fix a signature problem discovered in an audit by signing everything now. What you can do is fix the workflow so it stops happening, and disclose and repay what was billed without support. Chapter 37 §37.9.

State law and payer policy add requirements, including on who may sign what and on scribe documentation and its attestation. Verify with your compliance officer and the primary source; do not rely on a summary, including this one.

4.5 Amendments, addenda, and late entries

Records get corrected. There is a right way and a way that ends careers.

The governing principle: you may add to the record and you may correct the record. You may never make it appear that the record always said something it did not.

An electronic health record makes the technical part easy and the ethical part harder, because most systems will happily let a provider edit a note and will silently keep an audit trail that the provider has forgotten exists. The audit trail is discoverable. An amended note whose metadata shows it was altered the day after a records request arrived is not evidence in your favor; it is evidence of something else.

⚠️ Where Claims Die

Amending in response to a records request.

The sequence is always the same and it is always a disaster. A payer or contractor requests records. Someone reviews the chart before sending it, notices the documentation is thin, and asks the provider to "add what you remember."

Even where the addendum is entirely truthful and properly labeled, the timing is now part of the record, and the reviewer will see it. Where it is not properly labeled, the organization has moved from a documentation problem to a potential false statement.

The rule: send what you have. If documentation is deficient, that is a finding to accept, repay, and fix going forward. It is not a finding to paper over. Chapter 37 §37.7 covers responding to a records request properly.

4.6 Cloned notes, templates, and the copy-forward problem

Cloned documentation is content that is identical or nearly identical across encounters or across patients, produced by copy-forward, templates, macros, or automatic population.

It is not inherently improper. Templates improve completeness and legibility. Copying a stable problem list forward is reasonable and saves time. A normal review of systems genuinely is normal most days.

It becomes a problem in three specific ways.

1. It documents things that did not happen. A template that auto-populates a complete review of systems and a comprehensive examination produces a note asserting that fourteen systems were reviewed and a full examination performed. If they were not, the note is false — and the provider signed it.

2. It obscures change. A copied-forward assessment that reads "diabetes, stable" for eleven consecutive visits tells a reviewer nothing about the eleventh visit, and it tells a clinician nothing either. This is a patient safety problem before it is a billing problem.

3. It creates a detectable pattern. Identical notes are trivially found in data. A provider whose notes are indistinguishable across a panel of patients is a natural target for review, and the defense — that the care was individualized even though the documentation was not — is a hard defense to make.

📞 On the Phone

This conversation is difficult and worth rehearsing, because a coder raising it is telling a physician that their documentation is a liability.

What not to say: "Your notes are all cloned and it's going to get us audited." True, accusatory, and it will end the working relationship.

What works is specific, non-accusatory, and about the record rather than the person: "I'm looking at the last four visits for this patient and the exam section is word-for-word identical, including the knee findings — which changed between visit two and visit three, because you injected it. I don't think the exam was actually identical. Is there a way to get the template to leave the musculoskeletal section blank so you fill it in? Right now the note is underselling what you're actually doing."

Note the move: the complaint is that the documentation understates the work, which is both true and the version a busy clinician will act on. The compliance risk is real, and leading with it makes the conversation adversarial. Leading with "your note doesn't show what you did" makes it collaborative — and the fix is the same.

4.7 What the record must say before a code can exist

The operative principle, stated as a rule:

A code may be assigned when the documentation, read by someone who was not present, supports it without inference about what the provider must have meant.

That standard rules out three things coders are tempted by.

Inference from the diagnosis. A patient with diabetes and chronic kidney disease does not thereby have diabetic kidney disease. The relationship must be documented. Some conditions have an assumed relationship under the ICD-10-CM conventions — Chapter 9 §9.7 covers the "with" convention in detail — and some emphatically do not. Knowing which is which is a substantial part of the diagnosis coder's skill.

Inference from the order. A test ordered is not a test performed, a medication prescribed is not a medication administered, and a referral placed is not a consultation obtained.

Inference from clinical knowledge. This is the hard one. A coder who is also a nurse knows that a particular procedure necessarily involves a particular step. The code still requires the step to be documented.

The specific documentation elements a code needs

🎓 Exam Watch

Certification exams test this constantly, in a specific shape: a scenario describes a service, the documentation is subtly insufficient for the obvious code, and the correct answer is the less specific code or a query.

The reliable tell is a scenario that mentions a finding only in the history or only in the patient's report, never in the provider's assessment. "The patient states they were told they have osteoarthritis" is not a diagnosis of osteoarthritis.

A second reliable tell: laterality. If a scenario carefully avoids saying which side, the answer is the unspecified code — and on a real claim, a query.

The specificity ladder

Most coding disputes are not about which condition. They are about how specifically it may be described, and the ladder is worth internalizing because it recurs in every body system.

THE SPECIFICITY LADDER — and where documentation stops you

   MOST SPECIFIC   ┌─────────────────────────────────────────────┐
                   │  the exact condition, site, laterality,      │  ← the code set
                   │  type, stage, acuity, and episode           │     can express this
                   ├─────────────────────────────────────────────┤
                   │  the condition, with SOME specifiers        │  ← most real
                   │  documented and others absent               │     notes land here
                   ├─────────────────────────────────────────────┤
                   │  the condition, UNSPECIFIED                 │  ← always available,
                   │                                             │     always defensible
                   ├─────────────────────────────────────────────┤
                   │  the SIGN or SYMPTOM only                   │  ← where no condition
                   │                                             │     is established
   LEAST SPECIFIC  └─────────────────────────────────────────────┘

   YOU MAY CLIMB THIS LADDER EXACTLY AS FAR AS THE DOCUMENTATION CARRIES YOU,
   AND NOT ONE RUNG FURTHER.

   Going higher than the documentation = inference (§4.7). Not permitted.
   Staying lower than the documentation = downcoding (Ch. 5 §5.8). Also an error.

Two things about that diagram.

Both directions are errors. New coders internalize the first rule — do not code more specifically than the record supports — and then over-apply it, defaulting to unspecified codes when the record would have supported more. That is the second error, and Chapter 5 §5.8 explains why it is not the safe choice. Code exactly as high as the documentation carries you.

The unspecified code is always defensible and rarely optimal. It is the right answer when the record genuinely does not support more. It is the wrong answer when the record does and nobody read carefully enough to notice. And under risk-adjusted payment it is the difference between describing a population accurately and describing it as healthier than it is — Chapter 36's whole argument, and the reason Account 10-4471's diabetes line comes back.

And the rung below the ladder's bottom is a query, when the documentation is ambiguous rather than merely unspecific. §4.9. The distinction: unspecific means the record does not say, and you code what it does say. Ambiguous means the record says two things, or says something that does not fit the clinical picture, and you ask.

4.8 The legal health record and the designated record set

Two terms that sound like the same thing and are not.

The legal health record is the record an organization declares to be its official business record — the set of documentation it would produce in response to a subpoena or a request for records. Each organization defines its own, in policy, and the definition matters because modern electronic systems contain enormous amounts of material (drafts, alerts, unsigned notes, messages, audit logs, decision support firings) that the organization may or may not consider part of the record.

The designated record set is a HIPAA term: the records used to make decisions about individuals, which patients have a right to access and to request amendment of. It is defined by the Privacy Rule and it is generally broader than the legal health record — it includes billing records, for example.

Why a coder should care:

What you produce for an audit is defined by policy, not by convenience. Chapter 37 §37.7.

Patients have a right of access, and a right to request amendment. A patient may request that a record be amended; the organization may decline, but must then permit a statement of disagreement to be included. Coders occasionally encounter this when a patient disputes a documented diagnosis — which happens more often than people expect, and now happens more visibly because of open-notes requirements.

And the audit trail is part of the story. §4.5.

4.9 The query: when to send one and what it may not say

The query is the coder's mechanism for resolving a documentation problem, and it is the most tightly constrained communication in the profession.

When to query

Query when the documentation is conflicting, ambiguous, incomplete, illegible, or clinically inconsistent in a way that affects code assignment. Concretely:

• The record documents a condition in one place and contradicts it in another
• A diagnosis is implied by findings and treatment but never stated
• Specificity the code set requires is absent — laterality, stage, type, acuity, linkage
• A procedure's documentation omits an element the code distinguishes
• The clinical picture and the documented diagnosis do not fit each other

When not to query

Do not query to obtain a higher-paying code. Do not query when the answer is already in the record and you have not looked hard enough. Do not query repeatedly on the same encounter hoping for a different answer. And do not query when the honest resolution is simply to assign the less specific code.

The rules a query must follow

It must be non-leading. It may not suggest the answer, name a code, indicate the financial consequence, or imply which response is preferred.

It must present the clinical evidence from the record that raises the question.

It must offer clinically reasonable options, including — where appropriate — "clinically undetermined" and "other." A query with two options, one of which is obviously what the coder wants, is a leading query with a fig leaf.

It must be documented and retained, and its response must become part of the record. A verbal query that results in a documentation change with no record of the query is a problem, because the change now appears to have arisen from nowhere.

📋 Read the Chart

text FIGURE 4.1 — "Two queries, one difference" [constructed teaching example] THE DOCUMENT Two versions of a written query to a provider, generated from the same encounter. Only one of them may be sent. THE CONTEXT An inpatient record documents a low hemoglobin, two units of packed red cells transfused, and an assessment reading only "blood loss." The coder needs to know whether acute blood loss anemia is being diagnosed, because it affects the code and, in this setting, the DRG. WHAT IT SHOWS Version A supplies the answer, names the consequence, and offers one real option. Version B presents the evidence and asks a question that can honestly be answered several ways, including "no." WHAT IT DOESN'T Neither version tells you the right clinical answer. That is the point: the coder does not have one and must not appear to. THE DECISION Send B. Delete A. If A has already been sent, tell your compliance officer today rather than hoping. THE LESSON A query asks what the record does not say. It never proposes what it should have said.

```text ─── VERSION A — LEADING. DO NOT SEND. ────────────────────────────────── Dr. —, The patient was transfused 2 units. Can you please document "acute blood loss anemia" in the assessment? This will support the appropriate DRG and prevents the account from being underpaid. Thank you! ──────────────────────────────────────────────────────────────────────── FAULTS: supplies the exact wording wanted · states the financial consequence · offers no alternative · asks for a conclusion rather than a clarification · signals the preferred answer

─── VERSION B — COMPLIANT ────────────────────────────────────────────── Dr. —, Clarification is requested on the assessment for this encounter.

The record documents: · Hemoglobin 12.9 g/dL on admission, 7.8 g/dL on hospital day 2 · Estimated blood loss of 700 mL documented in the operative report · 2 units packed red blood cells transfused on hospital day 2 · Assessment on hospital day 2 reads "blood loss"

Based on your clinical judgment, can the condition be further specified? ( ) Acute blood loss anemia ( ) Anemia, other — please specify ( ) Expected post-operative blood loss without anemia ( ) Clinically undetermined ( ) Other: ____

Please document your response in the medical record. This query is not intended to suggest any particular response. ──────────────────────────────────────────────────────────────────────── ```

⚖️ Compliance Check

Query practice is governed by professional guidance from AHIMA and ACDIS, by payer expectations, and — where a federal health program is involved — by the general prohibition on submitting false claims.

The specific exposure of a leading query is that it can be characterized as the provider organization manufacturing documentation to support a code, which is a materially different allegation from having coded something incorrectly. At scale, in a risk-adjustment or DRG context, it has been the subject of enforcement actions.

Two protections worth building: query templates that are reviewed before use, so an individual coder is not improvising the wording under time pressure, and retention of every query and its response, so the provenance of a documentation change is always visible.

Chapter 38 covers this in depth: the compliant query at §38.3, the concurrent review at §38.2, and the metrics that corrupt a clinical documentation program at §38.4.

4.10 Reading a note like a coder, line by line

Here is the method, and then the note this book is built on.

READING A NOTE — the order that finds problems

  1. SIGNATURE AND DATE FIRST.
     If it is not signed and dated, nothing else matters yet.

  2. THE ASSESSMENT.
     What did the provider conclude? These are your diagnoses.
     Write them down before reading anything else, so you are
     reading the note as evidence rather than shopping for a code.

  3. THE PLAN.
     What was ordered, prescribed, performed, referred? These are
     your procedures, and this is where risk lives.

  4. NOW READ BACKWARD.
     Does the HPI support each assessment? Does the exam document
     the site and laterality? Is anything in the assessment
     unsupported by the rest of the note?

  5. LOOK FOR WHAT IS MISSING.
     Specificity the code set wants: site, laterality, stage, type,
     acuity, episode, linkage. Dose. Time. Extent.

  6. LOOK FOR WHAT IS CONTRADICTED.
     The HPI says one thing and the assessment says another. The
     exam documents the left and the plan treats the right.

  7. DECIDE: code it, or query it.
     And if you query, code nothing on this encounter until it
     is answered.

📋 Read the Chart

text FIGURE 4.2 — "The note this book is built on" [Account 10-4471] THE DOCUMENT Progress note, Northgate Family Medicine, date of service Tuesday, March 14. Signed electronically the same evening at 6:42 p.m. Reproduced in full, exactly as the coder received it on day 1. THE CONTEXT Established patient, 58, scheduled chronic-disease follow-up. A new complaint was raised during the visit and a procedure was performed. This note is the sole basis for four claim lines worth $367.00 in charges. WHAT IT SHOWS Three chronic conditions each individually assessed with a plan; medications reviewed and continued; two laboratory tests ordered with stated reasons; a new problem with its own history, examination, and independent management decision; and a procedure note documenting site, laterality, technique, drug, and dose. WHAT IT DOESN'T It never states, in the assessment, that conservative therapy for the knee has been tried and has failed — that information exists, but it is buried in the HPI where a reviewer scanning the assessment will not find it. It does not link the chronic kidney disease on the problem list to the diabetes, in either direction. And it does not say anywhere that the decision to inject was made during this visit rather than scheduled in advance. THE DECISION Code it. All three gaps are real and none of them prevents accurate coding today. Two of them will cost something later. THE LESSON A note can be entirely adequate for coding and still be inadequate for defending the claim. Those are different standards, and the gap between them is where appeals are lost.

```text ══════════════════════════════════════════════════════════════════════════ NORTHGATE FAMILY MEDICINE [constructed example] PROGRESS NOTE Account: 10-4471 Date of service: Tuesday, March 14 Provider: family physician, MD Type: established patient, office (place of service 11) ══════════════════════════════════════════════════════════════════════════

CHIEF COMPLAINT Three-month follow-up of chronic conditions. Also reports right knee pain, worsening.

HISTORY OF PRESENT ILLNESS 58-year-old established patient presents for scheduled follow-up of type 2 diabetes mellitus, hypertension, and hyperlipidemia. Reports good adherence to all medications. Home fasting glucose readings mostly 120-150. No hypoglycemic episodes. Home blood pressure log shows readings in the 130s/80s. Denies chest pain, dyspnea, edema, polyuria, visual change, or foot lesions.

Separately, reports approximately six weeks of right knee pain, medial, worse with stair descent and after prolonged sitting. No known injury. No locking or giving way. Pain now interfering with sleep and with a daily walk the patient has maintained for years. Has been taking ibuprofen 400 mg intermittently over the past six weeks with only partial relief.

PROBLEM LIST (reviewed) Type 2 diabetes mellitus Essential hypertension Hyperlipidemia Chronic kidney disease, stage 3a Obesity

MEDICATIONS (reviewed) metformin 1000 mg twice daily lisinopril 20 mg daily atorvastatin 40 mg daily ibuprofen 400 mg as needed

PHYSICAL EXAMINATION Vitals: BP 132/84 HR 76 afebrile General: Well appearing, no acute distress. Cardiac: Regular rate and rhythm. No murmur. No peripheral edema. Resp: Clear to auscultation bilaterally. Feet: Pedal pulses intact. Monofilament sensation intact bilaterally. MSK: RIGHT KNEE - no effusion appreciated. No erythema or warmth. Tenderness to palpation over the medial joint line. Crepitus with passive range of motion. Range of motion full but painful at terminal flexion. Ligamentously stable: negative anterior drawer, negative Lachman, stable to varus and valgus stress. McMurray equivocal. LEFT KNEE - normal.

ASSESSMENT AND PLAN 1. Type 2 diabetes mellitus - stable. Continue metformin 1000 mg twice daily. Hemoglobin A1c ordered today to reassess control. Continue home glucose monitoring. Follow up 3 months.

2. Essential hypertension - at goal on current therapy. Continue lisinopril 20 mg daily. No change.

3. Hyperlipidemia - continue atorvastatin 40 mg daily. Lipid panel ordered today.

4. Right knee pain - new complaint this visit. Examination findings are consistent with a degenerative process; no definitive diagnosis established today and no prior imaging of this knee is available. Discussed management options with the patient, including continued conservative measures, imaging, and intra-articular corticosteroid injection. Patient elected injection today. Procedure performed - see below. Continue ibuprofen as needed. If symptoms persist beyond six weeks, will obtain radiographs and consider orthopedic referral.

PROCEDURE NOTE Right knee intra-articular injection. Verbal consent obtained after discussion of risks and benefits. Right knee prepped with alcohol and chlorhexidine. Using a lateral suprapatellar approach, a 22-gauge needle was introduced into the joint space. Methylprednisolone acetate 40 mg with 3 mL of 1% lidocaine was injected without difficulty. No aspirate obtained. No imaging guidance used. Patient tolerated the procedure well. Post-procedure instructions provided. Dressing applied.

Blood drawn in office by venipuncture for the laboratory studies ordered above.

Time was not used for level selection on this encounter.

Electronically signed: family physician, MD 03/14 6:42 p.m. ══════════════════════════════════════════════════════════════════════════ ```

Reading it

Apply the method.

Signature and date. Present, electronic, with credential and timestamp, same day. Clean.

The assessment. Four items: type 2 diabetes mellitus, essential hypertension, hyperlipidemia, and right knee pain. Note what the fourth one says and does not say — "no definitive diagnosis established today." The provider has explicitly declined to name a disease. That is a clinically honest statement and it has a direct coding consequence, which Chapter 9 §9.5 and Chapter 12 §12.8 will develop: in the outpatient setting, you code the symptom, not the suspected condition.

The plan. Three medications continued, two laboratory tests ordered, one procedure performed, one contingency referral described.

Read backward. Does the HPI support each assessment? Yes — glucose readings for the diabetes, blood pressure readings for the hypertension, six weeks of pain with mechanical features for the knee. Hyperlipidemia is thinner, supported by the medication and the lab order rather than by narrative, which is normal and adequate. Does the examination document the site and laterality? Yes, explicitly, both knees, with the right one described in detail. Anything in the assessment unsupported? No.

What is missing. Three things, in order of how much they will cost:

First, and this is the one that matters: the assessment never states that conservative therapy has failed. The HPI says six weeks of ibuprofen with partial relief. That is the conservative-therapy documentation, and it is in the wrong section. A payer's medical policy for an intra-articular injection commonly asks for documented failure of conservative management, and a reviewer reading the assessment for the justification of the procedure will not find it there. The information exists. The sentence a reviewer needs does not. Chapter 22 returns to this.

Second, the note does not say that the decision to inject was made during this visit. It says the options were discussed and the patient elected injection, which strongly implies it. Implication is usually enough. It was not enough for this payer, and Chapter 30's appeal has to build the argument out of surrounding evidence rather than pointing at a sentence.

Third, the problem list carries chronic kidney disease, stage 3a, and the assessment addresses diabetes without reference to it. Note that carefully and do not act on it. Whether those two conditions are related is a clinical determination the provider has not made, and a coder may not make it. It is an observation for now. Chapter 36 will come back for it.

🔢 Code It

What this note supports — first pass, before Parts II and III teach you how.

This is deliberately premature. The point is to see where the codes come from, not to justify them yet.

From	Supports	Because
Assessment 4	a pain diagnosis, right knee	The provider explicitly declined to name a disease. Symptom coded, not a suspected condition.
Assessment 1	a type 2 diabetes diagnosis, unspecified	"Stable," no complications addressed, no documented linkage to the CKD
Assessment 2	essential hypertension	Stated plainly
Assessment 3	hyperlipidemia, unspecified	Stated plainly, no type specified
Procedure note	a major joint injection, right, without guidance	Site, laterality, technique, and the explicit absence of imaging guidance
Procedure note	the drug, 40 mg	Dose documented — this is what makes the units defensible
Procedure note	venipuncture	Documented as performed in office
Assessment 1–3 + plan	a moderate-complexity office visit	Three stable chronic illnesses and prescription drug management

The plausible wrong answers, named:

• Coding osteoarthritis. The examination is consistent with it and the provider said so. The provider also said no definitive diagnosis was established. Coding the disease is inference, and it is the single most common error a clinically trained coder makes.
• Coding diabetic chronic kidney disease. Both conditions are on the problem list. The link is not documented. Chapter 36 explains what that costs and what the right response is; the right response is not to code it today.
• Coding a laboratory test. The A1c and lipid panel were ordered, and the blood was drawn here, but the tests will be performed and billed by the laboratory. Ordering is not performing.
• Coding a higher visit level from the length of the note. The note is long because the patient has four problems. Length is not a level. Chapter 15.

🗂️ The Encounter

🗂️ The Encounter

What this chapter contributes: the note itself.

Everything from here forward comes out of Figure 4.2. Chapters 7 through 12 will assign its diagnosis codes; Chapters 13 through 19 will assign its procedure codes; Chapter 15 will level the office visit from its assessment and plan; Chapter 22 will ask whether the injection was covered; Chapter 30 will win an appeal on its contents; and Chapter 36 will come back for the one line it does not contain.

The four elements that will justify modifier 25. Chapter 14 will explain what the modifier asserts. Chapter 30 will have to prove it. Here is the evidence, already on the page:

#	Element	Where it is
1	Three chronic conditions, each separately assessed with its own plan	Assessment 1, 2, 3
2	Prescription drug management — three medications reviewed and continued	Medications list + Assessment 1, 2, 3
3	Two laboratory tests ordered, each with a stated clinical reason	Assessment 1 and 3
4	A new problem with its own history, its own examination, and an independent management decision	HPI paragraph 2, MSK examination, Assessment 4

Elements 1 through 3 have nothing to do with the knee. That is the entire modifier 25 argument, and it is already documented. The payer will deny anyway, and the appeal will point at exactly these four things.

The one sentence that is missing. In the assessment for the knee: an explicit statement that six weeks of conservative therapy has been tried and has not adequately controlled the symptoms.

It is in the HPI. It is not where a reviewer looks. And the difference between "the information is in the record" and "the information is where the person judging this will find it" is worth real money — Chapter 22 §22.6 shows how much.

What this does not settle. Which codes. That is Parts II and III, and it starts in three chapters.

Open questions, updated:

• Q5 — What is wrong with the knee? The note explicitly does not answer this: "no definitive diagnosis established today." That is now a documented fact rather than an omission. Resolved in Chapter 22.
• Q6 — Why \$185.00? Untouched. Resolved in Chapter 23.
• A new observation, not yet a question: the problem list carries chronic kidney disease, stage 3a, and the diabetes assessment does not reference it. Recorded here. Not acted on.

Conclusion

A code is a description of what a provider wrote.

What was decided in this chapter. What a coder actually reads, and how outpatient encounter-based reading differs from inpatient stay-based reading. The anatomy of an office note, and the rule that the assessment is where diagnoses come from. That an operative report's heading is not the code and the body must be read. That documentation must be authenticated, that missing signatures are the cheapest audit finding there is, and that a signed order is a separate requirement from a signed note. The difference between a compliant addendum and an alteration, and the specific disaster of amending in response to a records request. Why cloned documentation is a problem in three distinct ways, and how to raise it with a physician without ending the relationship. The rule that a code requires support without inference — from the diagnosis, from the order, or from the coder's own clinical knowledge. What a compliant query contains and what a leading one gives away. And a method for reading a note that finds problems: signature, assessment, plan, backward, missing, contradicted, decide.

And Figure 4.2, which the next thirty-six chapters will keep returning to.

What remains open. Every code. The note is on the table and nothing has been assigned.

The bridge to Chapter 5. This chapter has repeatedly said that a code unsupported by documentation is a problem, and has been vague about what kind of problem. Chapter 5 is specific. Every claim submitted to a federal health program carries a certification, the False Claims Act attaches liability to knowingly presenting a false one, and "knowingly" reaches reckless disregard. The distance between a documentation gap and a federal case is shorter than most people entering this profession expect, and the thing that closes it is not a single error — it is a pattern. Chapter 5 is the law, and it is written for the person who will one day be told to code something they cannot defend.

Key Terms

Medical record — the complete collection of documentation about a patient's care, which in an electronic system is a set of linked data rather than a document. (Ch.4)

SOAP note — the traditional structure of a clinical note: Subjective, Objective, Assessment, Plan. Rarely labeled in modern systems and almost always still present. (Ch.4)

Chief complaint — the stated reason for the encounter, in brief. The patient's reason for coming, not the provider's conclusion. (Ch.4)

History of present illness (HPI) — the narrative of the problem: onset, location, duration, character, aggravating and relieving factors, severity. Frequently the only place conservative therapy is documented. (Ch.4)

Review of systems (ROS) — a systematic inventory of symptoms by body system. Since 2021, not a factor in selecting an office visit level. (Ch.4)

Medical decision making (MDM) — the complexity of the problems addressed, the data reviewed, and the risk assumed. One of the two permitted bases for selecting an office visit level. (Ch.4)

History and physical (H&P) — the document establishing the reason for admission or surgery, the patient's baseline, and existing comorbidities. (Ch.4)

Operative report — the account of a surgical procedure, including pre- and postoperative diagnoses, findings, and a narrative description. The body, not the heading, determines the code. (Ch.4)

Discharge summary — the narrative of an entire admission. The most useful single inpatient document and not sufficient by itself for coding. (Ch.4)

Signature attestation — a separate signed statement identifying the author of an unsigned entry and attesting that they furnished and documented the service. It authenticates; it cannot add content and cannot supply a missing signature on an order. (Ch.4)

Addendum — new information added after an entry was completed, separately dated and signed, with the original intact. (Ch.4)

Late entry — documentation of an earlier event recorded now, identified as such, carrying the current date and stating the date of the service documented. (Ch.4)

Cloned documentation — content identical or nearly identical across encounters or patients, produced by copy-forward, templates, or automatic population. (Ch.4)

Query — a written request to a provider to clarify conflicting, ambiguous, incomplete, illegible, or clinically inconsistent documentation. It asks what the record does not say; it never proposes what it should have said. (Ch.4)

Leading query — a query that supplies the answer, names a code, states a financial consequence, or signals a preferred response. Improper, and at scale an enforcement exposure. (Ch.4)

Legal health record — the set of documentation an organization declares to be its official business record, defined by its own policy. (Ch.4)

Designated record set — the HIPAA term for records used to make decisions about individuals, which patients may access and request amendment of. Generally broader than the legal health record. (Ch.4)

Spaced Review

1. A note's chief complaint reads "cough." The assessment reads "acute bronchitis." Which do you code, and what is the general rule?

2. (Chapter 3) A diagnostic test is furnished and the laboratory cannot produce the ordering provider's signed order. State what happens and why the quality of the clinical justification does not save it.

3. A provider asks you to add a diagnosis to a note from last month "because we both know that's what it was." Give the three-part answer: what you may do, what you may not do, and what the correct mechanism is.

4. (Chapter 1) Name the four elements in Figure 4.2 that support modifier 25, and say which section of the note each one lives in.

5. Write a compliant query asking a provider to specify the laterality of a documented knee injection where the procedure note says only "knee." Then say what is wrong with this version: "Please document that this was the right knee so we can bill it correctly."