Why Your EHR’s Pre-Billing QA Isn’t Enough for Home Health

Your EHR has a pre-billing QA step. Before claims go out, it checks for missing fields, validates code formats, and flags incomplete documentation. This creates a false sense of security. The claim passes QA, goes out, and gets denied anyway — because the errors that cause denials under PDGM are not the errors your EHR is looking for.

This post breaks down what EHR pre-billing QA actually checks, what it misses, and why home health agencies need a separate validation layer for CMS billing compliance.

What EHR Pre-Billing QA Actually Does

EHR pre-billing QA is designed to catch data entry errors. Depending on the system, it typically validates:

• Required field completeness: Patient name, DOB, member ID, NPI, date of service, diagnosis codes. If a required field is blank, the claim is held.
• Code format validation: ICD-10 codes have 3–7 characters. HCPCS codes are 5 characters starting with a letter. The QA checks that codes match the expected format.
• Code existence: Some EHRs validate that the code exists in a lookup table. If you enter a code that does not exist at all, it flags it.
• Documentation checklist: Physician orders signed, OASIS assessment completed, care plan on file. These are documentation completeness checks.

These checks are valuable. They catch typos, data entry errors, and obviously incomplete claims. But they are checking whether the claim is structurally valid — not whether it is compliant with CMS payment rules.

What EHR QA Misses

1. The CMS Unacceptable Primary Diagnosis List

CMS publishes a list of ICD-10 codes that cannot be used as the primary diagnosis for a home health episode. An unacceptable primary diagnosis triggers automatic denial. Your EHR does not maintain this list. It sees a valid ICD-10 code and passes it through. The denial shows up weeks later.

The unacceptable diagnosis list changes annually with the Home Health PPS Final Rule. A code that was acceptable last year may not be acceptable this year. EHR code tables are updated for code existence, not for CMS-specific billing rules. For the full validation process, see Home Health Billing Code Compliance Checklist.

2. Code-First Sequencing Requirements

Some ICD-10 codes have a “code first” instruction, meaning another code must precede them as the primary diagnosis. If you list a code with a code-first requirement as the primary diagnosis, the claim may be denied or grouped incorrectly under PDGM. Most EHRs do not enforce sequencing rules during pre-billing QA.

3. Terminated Codes

CMS updates ICD-10-CM semi-annually (October and April). Codes are added, revised, and terminated. A code that was valid six months ago may be terminated in the current update. Your EHR may not update its code tables on the CMS release schedule. If it is running last quarter’s code set, it will pass a terminated code as valid.

4. PDGM Clinical Grouping and Case-Mix Weight

Under PDGM, the primary ICD-10 code determines which of 12 clinical groups the episode falls into. Each clinical group has a different case-mix weight, which directly determines payment. An EHR does not evaluate whether your primary diagnosis is routing the episode into the correct — or the highest appropriate — clinical group.

This is not a coding error in the traditional sense. The code is valid, the format is correct, and the documentation supports it. But if a different, equally documented diagnosis would place the episode in a higher-paying clinical group, you are leaving revenue on the table. For a deep dive on this, see How to Optimize Your PDGM Coding.

5. Comorbidity Adjustment Accuracy

PDGM applies a comorbidity adjustment (None, Low, or High) based on secondary diagnosis codes. If clinically documented comorbidities are not captured as secondary codes, the comorbidity adjustment defaults to “None” — the lowest tier. Your EHR checks that secondary diagnosis fields are not empty. It does not check whether all documented comorbidities have been coded.

6. Real-Time Eligibility Status

The most consequential gap: your EHR’s pre-billing QA does not verify that the patient was covered on the date of service. It checks the claim data. It does not query the payer. Eligibility denials are the most expensive category because the revenue is permanently unrecoverable. For an in-depth look at eligibility denial costs, see Home Health Claims Denial Rate in 2026.

Two Layers, Not One

EHR QA and CMS billing validation are complementary, not redundant. Think of them as two layers:

• Layer 1 (EHR): Ensures the claim is structurally complete. Required fields present, codes formatted correctly, documentation on file.
• Layer 2 (CMS compliance): Ensures the claim complies with CMS billing rules. Codes are active, primary diagnosis is acceptable, sequencing is correct, PDGM grouping is optimized, eligibility is confirmed.

Most agencies only have Layer 1. They pass QA, submit the claim, and discover Layer 2 errors when the denial arrives. Adding a CMS compliance layer before submission catches these errors at the lowest-cost point in the process — before the claim goes out, before staff provides unbillable services, before the denial queue grows.

How ClientCare Adds Layer 2

ClientCare validates billing codes against CMS reference data that is updated on the CMS release schedule. The validation engine checks the unacceptable primary diagnosis list, enforces code-first sequencing, verifies code currency against the current ICD-10-CM and HCPCS releases, and evaluates PDGM clinical grouping for optimization opportunities.

It runs alongside your EHR, not instead of it. You continue using your EHR for clinical documentation and claim submission. ClientCare adds the CMS compliance layer that your EHR does not provide. No EHR integration required — upload a CSV export of your patient roster and the system handles the rest. For more on how this works with any EHR, see Automate Eligibility Verification Without Replacing Your EHR.