The autocoder reads the diagnoses out of the documentation. It selects the most specific code the documentation supports. It does not infer a diagnosis from a medication list, a vital sign, or a comorbidity.

## What counts as documentation

- A condition the provider wrote, circled, or checked counts. A pre-printed condition on a checklist that is not circled or checked does not count and is not coded.
- A circled or checked negation, such as "No CV Issues", documents the absence of the condition. The autocoder never codes the condition it negates.
- A diagnosis written as suspected, possible, probable, or rule-out is not coded as confirmed. The autocoder codes the documented sign or symptom instead.
- A BMI value alone never produces an obesity code. The record must document obesity as a diagnosis before an E66 code or a Z68 BMI code appears. When the provider documents an obesity class, the class code (E66.811, E66.812, E66.813) is used instead of unspecified obesity (E66.9).
- ICD codes the provider entered in a diagnosis field for the visit, such as "Diagnosis [Codes]" or "Preoperative diagnosis", are direct documentation. The autocoder reports every one of them. Bulk problem-list or past-medical-history imports do not get this treatment.

## Delivery outcome codes stay on the delivery claim

Outcome-of-delivery codes (Z37.x) and the normal-delivery code O80 appear only on the claim for the delivery itself. A post-delivery pain round, a separate procedure after the delivery, or a labor visit where the patient did not deliver does not carry them.

## Which diagnosis becomes primary

The primary diagnosis is the condition that explains why the provider performed the procedure. The autocoder prefers a definitive diagnosis over a symptom when the documentation carries both. When a definitive diagnosis is documented, an integral symptom or site-pain code is dropped rather than demoted. For example, abdominal pain (R10.x) drops when the record documents appendicitis.

When sources disagree about the procedure and its findings, the autocoder uses the highest-authority source. The order is the operative report, then the post-anesthesia note, then the intraoperative anesthesia record, then the pre-anesthesia evaluation.

Supporting diagnoses follow the primary. Comorbidities that support the ASA physical status come first among them. Family history codes (Z80-Z84) and status codes never take the primary slot.

## Combination codes

When the record documents two conditions that have a single ICD-10-CM combination code, the autocoder collapses them into that code. The four collapses are:

| Documented together | Result |
|---|---|
| Hypertension (I10) with chronic kidney disease (N18.x) | I12.0 or I12.9 |
| Hypertension (I10) with heart failure (I50.x) | I11.0 |
| Hypertension with both of the above | I13.0 or I13.2 |
| Unspecified type 2 diabetes (E11.9) with chronic kidney disease | E11.22 |

The chronic kidney disease stage code and the heart failure code stay on the claim as additional codes. If the combination code was already present, the autocoder drops the redundant standalone code instead. The combination code takes the primary slot when one of its members occupied that slot. When the documentation states that the two conditions are unrelated, the autocoder keeps the separate codes.

Every collapse produces a **Combination Diagnosis Code Applied** alert (`icd_combo_collapsed`, INFORMATIONAL, default severity 3). It is an audit record, not a question.

## Laterality and specificity

The autocoder matches laterality to the documentation. When the record does not state a side, it uses the unspecified code. It never infers anatomy, laterality, or an initial-versus-subsequent encounter from a code lookup alone.

## Billable codes only

A diagnosis code that is a category header, and not billable on its own for the date of service, is removed at claim build. The **Header Diagnosis Code Removed** alert (`icd_non_billable_stripped`, INFORMATIONAL, default severity 3) names the removed code and its billable child codes. Read the record and add the correct child code. When the removed code was the primary diagnosis, the alert says so.

## Diagnoses per line

The `max_icd_per_line_item` processing rule limits each line item to four diagnosis codes on anesthesia claims. When the limit drops codes, the claim shows an INFORMATIONAL alert that names the dropped codes. Your facility configuration controls the limit. Contact your Hank representative to change it.

In the standard configuration, a supporting procedure line on an anesthesia claim, such as an arterial line, a central line, a TEE, or an imaging-guidance code, carries the diagnoses documented for that procedure. The main anesthesia line carries the full supporting set. Nerve block lines follow the `nerveBlockLineIcds` setting.

## Related alerts

- **Primary Diagnosis Not Documented as the Reason for the Procedure** (`primary_icd_not_attested`, HARDSTOP, default severity 7). This alert asks a coder to confirm that the record documents the primary diagnosis as the reason for this procedure. It fires when the only source is a problem list, past medical history, a family or personal history entry, a medication or billing list, or a history of present illness with no stated link. The alert text states where the code was found in plain words. Your facility configuration controls this alert through `claimValidation.checks.primaryIcdAttested`.
- **Diagnosis Validation Returned No Result** (`icd_verdict_empty`, COMPLIANCE, default severity 5). The validation step returned no verdict. The diagnosis codes ship as extracted, so read them against the documentation.
- **Header Diagnosis Code Removed** (`icd_non_billable_stripped`, INFORMATIONAL, default severity 3). A non-billable category header was removed from a line. The alert asks a coder to add the correct billable child code from the family it names.
- **Removed Duplicate Ancillary Line Item** (`anes_duplicate_ancillary_line_removed`, INFORMATIONAL, default severity 2). An exact duplicate of a supporting anesthesia procedure line was removed. The alert asks a coder to confirm whether a second procedure really occurred.

## How this reaches you

What happens next depends on how your organization consumes HANK CODES. In HANK Claim Maker, a HARDSTOP alert places the claim in the review queue your administrators configured for it. Organizations that consume the coding API directly decide in their own workflow which alerts pause a claim, who reviews them, and when a claim is released.