Foundation: Medical Coding, the Claims Lifecycle, and Healthcare Regulations

Lesson 1: How procedures get coded — CPT and HCPCS

Every billable thing a provider does — an office visit, a colonoscopy, an MRI, injecting a drug, fitting a wheelchair — is encoded as a numeric procedure code. There are two main systems:

CPT (Current Procedural Terminology)

CPT is owned by the American Medical Association and updated annually (effective January 1). It's the dominant procedure code set for physician services and outpatient procedures. Codes are five digits.

The codes you'll touch most often in AI products are the E/M codes (every office visit) and whatever specialty range matches your use case (radiology if you're doing imaging prior auth, surgery if you're doing inpatient predictive denial, and so on).

HCPCS Level II

CPT covers professional services. HCPCS Level II (Healthcare Common Procedure Coding System, maintained by CMS) covers everything else: drugs given by injection or infusion, durable medical equipment (DME), prosthetics, ambulance services, supplies. Codes are one letter followed by four digits.

Modifiers — small codes, big payment impact

A two-character modifier appended to a CPT/HCPCS code changes its meaning. AI systems that ignore modifiers will misprice, mispredict, and misroute claims. The high-frequency ones:

Lesson 2: How diagnoses get coded — ICD-10-CM

Diagnoses are coded with ICD-10-CM (Clinical Modification), maintained by CDC's NCHS and CMS, updated each October 1. Codes are alphanumeric, 3 to 7 characters, with very specific anatomy and laterality.

Three structural facts that matter for AI design:

1. Specificity is hierarchical. E11 is "type 2 diabetes." Adding digits adds detail (with kidney disease, with neuropathy, etc.). Coding to the highest level of specificity supported by the documentation is the coder's job — and a frequent target of clinical documentation improvement (CDI) and risk adjustment programs.
2. Laterality is encoded in the digit. S72.001A is the right femur; S72.002A is the left. Models that aggregate at the three-character level lose this.
3. The seventh character matters. For injuries, A = initial encounter, D = subsequent, S = sequela. Wrong seventh character is a frequent denial reason.

Inpatient hospital claims also use ICD-10-PCS (Procedure Coding System, 7-character alphanumeric) for inpatient procedures — entirely separate from CPT. If you're building anything that touches hospital inpatient data, you'll see PCS.

Lesson 3: The claims lifecycle and X12 transactions

When a provider bills a payer, the information moves through a defined set of X12 EDI transactions. HIPAA mandates these formats. If you're building anything that interfaces with a clearinghouse, a payer, or a provider's RCM system, you'll touch them.

The journey of a claim, simplified

1. Eligibility check — Provider sends 270 before the visit; payer returns 271 with active coverage, deductible status, copay.
2. Authorization (if required) — Provider submits 278 (or uses a portal / fax / phone). Payer approves, denies, or pends.
3. Service delivered, claim submitted — Provider's billing system creates an 837 with all the codes from Lesson 1 and 2, sends it to a clearinghouse, which forwards to the payer.
4. Front-door check — Payer returns 277CA saying "accepted" or "rejected" (e.g. invalid member ID, missing NPI). Rejections never enter adjudication.
5. Adjudication — Payer runs edits (NCCI, MUE, plan-specific), applies policy, computes payment. Days to weeks depending on plan and complexity.
6. Remittance — Payer sends 835 back with per-line payment, adjustments, and reason codes. Provider posts to AR.
7. Denials & appeals — Anything denied may be appealed (see Step 4).

Reading an 835 segment — the parts that matter

Real 835 fragment, simplified:

CLP*PATACCT123*1*450.00*135.00*50.00*MC*PAYERREF456*11~
NM1*QC*1*DOE*JANE*M***MI*MEM98765~
SVC*HC:99214*250.00*75.00**1~
DTM*472*20250915~
CAS*CO*45*175.00~
SVC*HC:90471*30.00*0.00**1~
CAS*PR*204*30.00~
SVC*HC:90686*170.00*60.00**1~
CAS*CO*45*110.00~

What this is telling you:

• CLP: This claim (account PATACCT123) was billed for $450, the payer paid $135, patient owes $50. Status 1 = primary claim, processed as primary. MC = Medicare claim type.
• SVC + CAS for line 1: 99214 billed at $250, paid $75. The CAS*CO*45*175 means Contractual Obligation (CO), reason code 45 ("Charge exceeds fee schedule"), $175 written off.
• SVC + CAS for line 2: 90471 billed at $30, paid $0. CAS*PR*204*30 = Patient Responsibility (PR), reason 204 ("Service not covered under patient's current benefit plan"), $30 to patient.
• SVC + CAS for line 3: 90686 (influenza vaccine) billed at $170, paid $60. Another contractual write-off.

CARC and RARC: the codes that explain payment outcomes

In the CAS segment, the reason code is a Claim Adjustment Reason Code (CARC). They tell you why a claim or line was adjusted (denied, reduced, or written off). Provider-side denial AI lives and dies on understanding these.

A Remittance Advice Remark Code (RARC) provides additional context. CARCs say what happened; RARCs say why or what to do next. Example: CARC 50 + RARC N115 = denied as not medically necessary, per a Local Coverage Determination (LCD).

Lesson 4: The Explanation of Benefits — what the patient (and the model) sees

The EOB (Explanation of Benefits) is the patient-facing document that summarizes how a claim was paid. It's not a bill. It maps to the same data as the 835 but is formatted for humans. Anyone selling or building patient-facing AI needs to be able to read one.

An EOB typically shows, per service line:

• Amount billed — what the provider charged
• Plan discount / allowed amount — what the contract reduces it to
• Plan paid — what insurance actually paid
• Your responsibility — copay, coinsurance, deductible, non-covered
• Reason code(s) / notes — plain-language explanation of any denial or write-off

When a member calls about a "denial," they're usually reading an EOB. When AI parses or generates appeals letters, it's often working from EOB text plus underlying 835 data.

Lesson 5: The regulatory floor every builder must know

Healthcare AI lives under multiple overlapping regulations. You don't need to be a lawyer, but you need to know what governs what. The four you'll bump into most:

HIPAA (Health Insurance Portability and Accountability Act, 1996)

Three rules that matter:

• Privacy Rule (45 CFR Part 164, Subpart E) — defines Protected Health Information (PHI) and the conditions for using or disclosing it. The 18 HIPAA identifiers (name, MRN, dates more specific than year, etc.) are PHI.
• Security Rule (45 CFR Part 164, Subpart C) — administrative, physical, and technical safeguards. Encryption, access controls, audit logs.
• Transactions and Code Sets Rule — why X12 837/835 and code sets like CPT/ICD-10 are mandatory.

If you're a vendor to a covered entity, you sign a Business Associate Agreement (BAA). Your stack must support BAAs if you want to sell. AWS, GCP, Azure, OpenAI Enterprise, Anthropic Enterprise, and most modern infrastructure providers offer BAAs — but not on all tiers. Confirm before building.

42 CFR Part 422 — Medicare Advantage

This regulates Medicare Advantage plans (the privatized Medicare programs run by Aetna, UnitedHealth, Humana, etc.). Recent updates that matter for AI builders:

• Two-midnight rule for MA (effective 2024) — MA plans must follow the same inpatient admission criteria as Traditional Medicare. This dramatically constrains UM auto-denial logic.
• Internal coverage criteria limits — MA plans cannot use proprietary criteria more restrictive than Traditional Medicare's National Coverage Determinations or Local Coverage Determinations.
• Algorithmic decision-making transparency (CMS final rule 2024) — MA plans using AI/algorithms for coverage decisions must ensure they comply with all coverage rules and cannot use them to deny care that traditional Medicare would cover.

CMS-0057-F (CMS Interoperability and Prior Authorization Final Rule, 2024)

Sometimes called the "Patient Access Final Rule." The single most important regulation for builders working on prior authorization. Key dates and requirements:

• Effective for impacted payers (Medicare Advantage, Medicaid managed care, CHIP, qualified health plans on FFEs).
• By January 1, 2026 — affected payers must send prior authorization decisions within 72 hours for urgent and 7 calendar days for non-urgent requests.
• Payers must provide a specific reason for denial.
• Payers must publicly report PA metrics.
• By January 1, 2027 — affected payers must implement FHIR-based Prior Authorization API (Da Vinci PAS implementation guide), Patient Access API for PA info, Provider Access API, and Payer-to-Payer API.

State-level laws to watch

Several states have passed AI-specific UM laws that bind any payer doing business in the state — and any vendor selling to those payers:

• California SB 1120 (2024) — health plans using AI for utilization management must ensure clinical decisions are made by a qualified human, AI cannot deny based solely on group data, and equity testing is required.
• Texas, New York, Illinois — variations on AI transparency and human-in-the-loop requirements.

The No Surprises Act (NSA, 2022)

Bans most surprise out-of-network billing and creates an independent dispute resolution (IDR) process for OON payment disputes between providers and payers. If you're building anything around OON claims or balance billing, you need to know the IDR mechanics — covered briefly in Step 4's Payment Integrity pod.