What a home health coding audit is for
A home health coding audit is a structured review of a sample of completed charts against the code set, the OASIS assessment and the clinical narrative. Its job is to find the places where the coded claim and the record behind it disagree — a code without support, a diagnosis left at a generic level, an OASIS functional score that does not match the visit notes — and then to fix the cause instead of correcting the individual charts and moving on.
An audit is not the same thing as a denial review. Denials arrive after a payer has already disagreed with a claim, on the payer's sample and the payer's timeline. An audit happens on your sample, before the claim leaves, and it is the only one of the two that shows you a pattern while it is still cheap to change. Agencies that only look at charts after a denial are measuring the past; an audit is a control.
Decide what the audit is allowed to conclude
Three different questions get folded into the phrase coding audit, and they need different reviewers and different evidence. The first is whether the right code was selected. The second is whether the record supports the code that was selected. The third is whether the claim built from that code — the period dates, the discipline, the units, the OASIS responses feeding PDGM grouping — matches what was delivered.
Pick which question the audit is answering before the first chart is pulled. A review that tries to answer all three at once produces a single accuracy number that nobody can act on, because a failed check could mean a coder chose wrong, a clinician did not document, or a system field was populated from the wrong source. Those three failures have three different owners and three different fixes.
Build a sample that can support a conclusion
The unit of review is the 30-day period, not the claim line. Medicare pays home health by the period, the case-mix weight is assigned per period, and a period that groups wrong is a payment that is wrong even when every individual line on the claim is internally consistent. Pull the period, its OASIS assessment, its plan of care and the visit notes that justify it.
Stratify the sample instead of drawing it at random from everything billed. One stratum per coder, per payer type, per discipline where relevant, and per diagnosis cluster — start of care periods, recertification periods, and the clinical groups that carry the most revenue for the agency. Ten to twelve charts per coder in a quarter will show you a pattern; a hundred charts drawn at random across the whole agency will mostly show you your own caseload mix.
Write the selection rule down, including the seed or the date range, so the same quarter can be re-run and compared later. An audit whose sample cannot be reproduced cannot support the claim that anything improved.
The five checks every chart gets
Primary diagnosis support. The diagnosis the period is built on has to be evidenced by the narrative and the plan of care, not by the problem list carried forward in the EHR. If the note describes a codable condition the coder did not use, that is a coding finding; if the coder used a condition the note never addresses, that is a support finding.
Specificity. The code should sit at the most specific level the documentation allows: heart failure type, chronic kidney disease stage, diabetes with or without complications, laterality, wound stage and site. Generic codes are not always wrong, but a pattern of generic codes across one coder or one referral source usually means the documentation stops short.
Code-to-OASIS alignment. The diagnoses coded and the OASIS responses that drive PDGM grouping have to describe the same patient. A diagnosis that contradicts a Section GG functional score, or a primary diagnosis that is not the condition being treated in the plan of care, changes the grouping without anyone noticing on the claim.
Sequencing. The primary diagnosis has to be the condition most relevant to the plan of care for that period, and secondary diagnoses ordered by how they drive grouping and comorbidity adjustment. Sequencing errors rarely look like errors on an individual claim; they show up as a case-mix pattern that is lower than the documentation would support.
Active-condition documentation. A code holds when the record shows the condition was monitored, evaluated, assessed or treated during the period. That is a documentation test, not a coding test, and it is where most of the risk-adjusted revenue leaks in agencies that also carry Medicare Advantage work. Capturing every supported HCC at full specificity is the same discipline applied to risk adjustment.
Separate the two failures: wrong code and unsupported code
A wrong code is a coding decision that does not match the record. An unsupported code is a code that may be clinically right but has nothing in the record to carry it. The first is fixed with coder education and a second read on the diagnosis clusters that go wrong repeatedly. The second is fixed upstream, in the visit note and the query process, and no amount of coder training will close it.
Tag every finding with which of the two it is, plus a third category for process failures: the condition that was documented, the query that was never sent, the code that was corrected after the claim went out. Process findings are the most valuable output of an audit because they are the ones a template change or a workflow change can eliminate.
Score findings so they survive contact with operations
Report findings as a distribution, not as one percentage. For each failed check, say how many charts failed it, which coders or payers they clustered in, and whether payment was at risk. An agency told its coding accuracy is 92% has learned nothing; an agency told that nine of twelve wound care periods were coded to an unspecified site, all from one referral source, knows exactly what to fix.
Classify severity honestly. A severity scale that treats a cosmetic sequencing difference and a diagnosis with no support as the same kind of error will bury the second under the first, and the review will start to look like a formality. Keep a chart-level register — period, coder, finding, cause, owner, action taken — because that register is what you will be asked to produce when a payer or an accreditation reviewer wants evidence that you monitor your own coding.
Close the loop or the next audit finds the same errors
The most common audit failure is not a bad sample. It is a good sample whose findings are delivered as a report months after the charts were coded, to a manager who has no authority over the clinicians whose documentation caused the problem. Feedback has to be specific, attributed to the work rather than the person, and delivered while the coder still remembers the case.
When the same finding appears three times, it is no longer a person problem. It is a prompt in the EHR, a required field that is not required, a discharge or recertification template that does not ask for the stage of a wound, or a query workflow that lets a coder close a chart without sending the question. Check the aggregate findings against the templates before scheduling another training session, because the template is usually cheaper to fix than the habit.
Calibrate the reviewers before the sample starts
Two reviewers working from the same criteria will disagree on a handful of charts. That disagreement is data: it tells you whether the criteria mean what you think they mean. Have both reviewers score the same five charts and talk through every difference before the sample begins, then write the resulting rulings into the audit guide so the next cycle inherits them.
If the audit is outsourced, ask for the sampling rule, the review criteria and a chart-level findings file rather than a summary. An outside reviewer who cannot show you which charts were pulled and what was found on each one is producing an opinion. Outsourced coding and OASIS review is normally where this service sits, and the reporting format should be agreed in the contract, not after the first cycle.
A coding audit is not a documentation audit
A coding audit starts from the record and asks whether the code is right. A documentation audit starts from the claim and asks whether the record would survive a reviewer who was looking for a reason to deny it: homebound status supported by specifics, skilled need described visit by visit, orders signed and dated, the face-to-face encounter inside its window. Both are worth running, and they find different things.
In practice the two overlap at the point where a claim is denied for a reason the record could have answered. Agencies that run clinical documentation review on the periods with the highest denial exposure, and a coding audit on the periods with the highest revenue weight, cover more ground than one combined review that tries to be both. The clean claim checklist is a reasonable bridge between them: it lists the elements that have to be true before a claim is submitted, whichever review found the gap.
A first cycle that fits in a quarter
Weeks one and two: agree the question, the criteria, the strata and the sample size, and calibrate the reviewers. Weeks three to five: review the charts and record findings at chart level. Week six: deliver findings to the coders and to the clinical leads whose documentation produced them. Weeks seven to nine: make the template, query-workflow and training changes the findings called for. Weeks ten to twelve: re-run the same strata with a fresh sample and compare.
The comparison is the point. An audit cycle that ends with a score and no follow-up sample has measured the past twice and changed nothing. Between cycles, track the intermediate signals that move first — query volume per coder, the share of records returned for clarification, the diagnosis clusters that keep appearing as findings — so you are not waiting a full quarter to find out whether the fix worked.
What not to do
Auditing only the charts that denied teaches you about the payer's sample, not your coding. Auditing one coder, usually the newest, leaves the pattern in the rest of the team untouched. Changing a code without changing the documentation creates a record that contradicts itself, which is worse than the undercoding you started with. And treating the audit as paperwork that has to exist for an accreditation file, rather than as the control that protects the claim, is how an agency ends up with three years of audit reports and the same error count in every one of them.