Claims Adjudication Guide

End-to-end guide to claims processing in Cloud Health Office — from 837 EDI ingestion through auto-adjudication, clinical edits, work queue management, and payment/denial generation. Covers professional (837P), institutional (837I), and dental (837D) claim types.

Overview

Cloud Health Office claims adjudication spans four major stages, from initial claim receipt through final payment or denial output:

The auto-adjudication engine processes the majority of claims without human intervention. Claims that cannot be auto-adjudicated are routed to work queues where trained examiners resolve exceptions using the portal’s built-in review tools.

1. Claim Ingestion

Claim ingestion is the first stage of processing — receiving claims from providers and clearinghouses, parsing the X12 837 transactions, validating syntax, and creating internal claim records ready for adjudication.

Supported Claim Formats

Format	Transaction Set	Use Case	Claim Types
837P	X12 837 Professional	Physician office visits, outpatient services, lab, imaging	CMS-1500 equivalent
837I	X12 837 Institutional	Hospital inpatient, outpatient facility, SNF, home health	UB-04 equivalent
837D	X12 837 Dental	Dental services for plans with dental benefits	ADA Dental Claim equivalent

Ingestion Channels

Channel	Protocol	Mode	Typical Use
SFTP Batch	SFTP (SSH File Transfer)	Batch (scheduled)	Standard clearinghouse drops — files arrive on schedule (hourly, daily)
Real-time API	FHIR R4 Claim/$submit	Real-time	EHR-integrated providers submitting claims directly via FHIR
Portal Manual Entry	HTTPS (portal UI)	Real-time	Manual claim entry by payer staff for phone/fax claims
Direct 837 Upload	HTTPS (portal file upload)	On-demand	Providers or small clearinghouses uploading 837 files directly

Clearinghouse Connectors

Cloud Health Office includes pre-built connectors for the major healthcare clearinghouses. Each connector handles SFTP polling, file format translation, acknowledgment generation, and failover:

• Availity — Primary connector for commercial and Medicare Advantage claims; supports real-time 276/277 status inquiries
• Change Healthcare — High-volume connector with batch and real-time modes; integrated with Change Healthcare’s claims status and eligibility services
• Optum — Connector for UnitedHealthcare-affiliated providers and Optum clearinghouse clients
• Inovalon — Connector for Medicaid managed care plans using Inovalon’s NASCO clearinghouse services

Each connector supports failover configuration: if the primary clearinghouse connection fails, claims are automatically routed through a backup connector after a configurable timeout.

Claim Receipt Workflow

When a claim file arrives, the system processes it through a six-step ingestion pipeline:

1. Receive — File picked up from SFTP directory or received via API endpoint
2. Parse — X12 837 transaction parsed into individual claim records (CLM loops)
3. Validate X12 Syntax — Structural validation against the X12 implementation guide; segment counts, loop integrity, required element presence
4. Generate 999 Acknowledgment — X12 999 Implementation Acknowledgment returned to the submitter confirming receipt and syntax validation results
5. Create Internal Claim Record — Parsed claim data mapped to the internal claim data model with a unique ClaimId assigned
6. Queue for Adjudication — Claim record placed on the adjudication queue for auto-adjudication processing

SFTP / API Receipt → X12 837 Parsing → Syntax Validation → 999 Acknowledgment → Internal Claim Record → Adjudication Queue

Duplicate Detection

Duplicate claims are detected at ingestion time by matching on a composite key within a configurable time window:

• Match fields — Member ID + Rendering Provider NPI + Date of Service + Procedure Code + Billed Amount
• Time window — Configurable per LOB (default: 90 days). A claim matching all fields within the window is flagged as a potential duplicate.
• Exact vs. near-duplicate — Exact matches (all fields identical) are rejected automatically. Near-duplicates (same member/provider/date but different billed amount) are flagged for manual review.

2. Auto-Adjudication Pipeline

The auto-adjudication pipeline processes each claim through ten sequential steps. If any step fails, the claim is either denied or pended to a work queue for manual review. The goal is to auto-adjudicate 85–95% of clean claims without human intervention.

1. Eligibility → 2. Coverage → 3. Auth Check → 4. Coordination of Benefits → 5. Duplicate Detection → 6. Clinical Edits → 7. Fee Schedule → 8. Cost Sharing → 9. Payment Calculation → 10. Disposition (Pay | Deny | Pend)

Step 1: Eligibility Verification

The system confirms the member has active coverage on the date of service. It verifies:

• Member ID matches an enrolled member in the system
• Coverage is active (not terminated or suspended) on the claim’s date of service
• The coverage includes the type of service billed (medical, dental, pharmacy)

Failure action: Deny with CARC code 27 (Expenses incurred after coverage terminated) or 31 (Patient cannot be identified as our insured).

Step 2: Benefit Lookup

Identifies the member’s benefit plan, benefit package, and applicable cost sharing rules for the billed service category. This step retrieves the configuration described in the Benefit Plan Configuration Guide.

Failure action: Pend to work queue if plan mapping cannot be resolved (rare — typically indicates a data issue).

Step 3: Provider Validation

Verifies the rendering and billing providers are active, credentialed, and not excluded from federal programs. This step integrates with the ProviderVerificationService:

• NPI is valid and active in NPPES
• Provider is not on the OIG exclusion list (LEIE) or GSA SAM exclusion list
• Provider credentials are current (license, DEA, board certification)
• Provider is contracted with the member’s plan network (determines in-network vs. out-of-network tier)

Failure action: Deny if provider is excluded. Pend to “Provider Not Contracted” queue if provider is not in the plan’s network.

Step 4: Duplicate Check

A second duplicate check is performed post-ingestion to catch duplicates that may have arrived between the ingestion check and adjudication processing (race condition protection for high-volume environments).

Failure action: Deny with CARC code 18 (Exact duplicate claim/service).

Step 5: NCCI/MUE Edits

National Correct Coding Initiative (NCCI) edit pairs and Medically Unlikely Edits (MUE) are applied. See Section 3: Clinical Edits for full detail.

• NCCI Column 1/Column 2 — Checks for mutually exclusive procedure code combinations on the same date of service
• MUE unit limits — Validates that billed units do not exceed the CMS-published per-procedure per-day limit

Failure action: Deny the affected line(s) or pend to “NCCI/MUE Edit Failures” queue depending on configuration.

Step 6: Fee Schedule Repricing

The contracted fee schedule or regulatory rate is applied to calculate the allowed amount for each claim line. This step uses the FeeScheduleEngine:

• Professional claims (837P) — Fee schedule rate by CPT/HCPCS code, modifier, and place of service
• Institutional claims (837I) — DRG-based pricing for inpatient; APC or fee schedule for outpatient
• Multiple procedure reduction — Subsequent procedures in the same session are reduced per configured rules

Failure action: Pend to “No Rate” queue if no fee schedule rate is found after cross-schedule resolution.

Step 7: Coordination of Benefits (COB)

Determines the plan’s liability when the member has coverage from multiple payers:

• Primary/secondary determination — Based on COB rules (birthday rule, active employee rule, etc.)
• Other payer payment — If this plan is secondary, the other payer’s payment is subtracted from the allowed amount before calculating plan liability
• Medicare Secondary Payer (MSP) — Special handling for Medicare Advantage plans when Medicare is secondary

Failure action: Pend to “COB/Other Payer” queue if other payer information is missing or conflicting.

Step 8: Accumulator Update

The member’s deductible, out-of-pocket, and visit limit accumulators are read from Redis (see Benefit Plan Guide: Accumulators), and the member’s cost sharing is calculated:

• If the deductible is not yet met, the member pays the allowed amount (up to the remaining deductible)
• After the deductible, copay and/or coinsurance are applied per the plan’s cost sharing rules
• If the OOP max is met, the plan pays 100% — no further member cost sharing
• Accumulators are updated in Redis in real time to ensure subsequent claims in the same session reflect the latest balances

Failure action: If accumulator data is unavailable (Redis outage), claim is queued for retry with exponential backoff.

Step 9: Authorization Match

For services that require prior authorization (as defined in the benefit plan’s auth-required rules), the system attempts to match the claim to an approved authorization:

• Match criteria: member ID + service type + procedure code + date of service within the authorization’s valid date range
• Unit/day validation: billed units must not exceed remaining authorized units
• Authorization status must be Approved or Partial (not Expired or Voided)

Failure action: Pend to “Missing Prior Auth” queue. See the Prior Authorization Guide for auth lifecycle details.

Step 10: Final Disposition

After all nine preceding steps complete successfully, the claim receives its final disposition:

• Approve — All steps passed; claim is marked Adjudicated and queued for payment
• Deny — One or more steps resulted in a hard denial (e.g., not eligible, duplicate, excluded provider)
• Pend — One or more steps require manual review; claim is routed to the appropriate work queue

Pipeline Summary

Step	Engine / Service	Failure Action
1. Eligibility Verification	EligibilityService	Deny (CARC 27/31)
2. Benefit Lookup	BenefitPlanEngine	Pend (data issue)
3. Provider Validation	ProviderVerificationService	Deny (excluded) / Pend (not contracted)
4. Duplicate Check	DuplicateDetectionService	Deny (CARC 18)
5. NCCI/MUE Edits	ClinicalEditEngine	Deny line(s) / Pend to NCCI queue
6. Fee Schedule Repricing	FeeScheduleEngine	Pend (no rate found)
7. COB	COBEngine	Pend to COB queue
8. Accumulator Update	AccumulatorService (Redis)	Retry (Redis outage)
9. Authorization Match	PriorAuthMatchService	Pend to Missing Auth queue
10. Final Disposition	AdjudicationOrchestrator	Approve / Deny / Pend

3. Clinical Edits

Clinical edits enforce coding compliance by detecting invalid procedure code combinations and medically unlikely billing patterns. Cloud Health Office applies CMS-published NCCI and MUE edits, plus configurable plan-specific custom edits.

NCCI Column 1 / Column 2 Pairs

The National Correct Coding Initiative defines pairs of procedure codes that should not normally be billed together on the same date of service by the same provider for the same member:

• Column 1 code — The comprehensive or primary procedure (payable)
• Column 2 code — The component or lesser procedure (denied unless a modifier exception applies)
• Modifier indicator — 0 = no modifier exception allowed (always deny Column 2); 1 = modifier exception allowed (Column 2 payable if modifier 25, 59, XE, XS, XP, or XU is present)

When an NCCI pair is detected, the Column 2 procedure line is denied with the appropriate CARC/RARC codes unless a valid modifier override exists.

MUE (Medically Unlikely Edits)

Medically Unlikely Edits define the maximum number of units of service a provider would report for a single procedure code on a single date of service for a single member:

• MUE value — The maximum allowed units (e.g., CPT 99213 has an MUE of 1 — you can only bill one Level 3 E/M visit per day)
• MUE adjudication indicator (MAI) — Determines the scope:
  • 1 = Per claim line — each line evaluated independently
  • 2 = Per date of service — all lines for the same code on the same date summed
  • 3 = Per date of service, per provider — same as 2 but scoped to a single NPI

Units exceeding the MUE threshold are denied on the affected claim line.

Edit Overrides

Authorized clinical staff can override NCCI and MUE denials when clinically justified. All overrides are:

• Logged with the overriding user’s identity, timestamp, and reason code
• Subject to audit review — overrides above a configurable dollar threshold trigger a second-level review
• Tracked in the claim’s adjudication trace log for compliance and reporting

Custom Edits

Beyond CMS-standard NCCI/MUE edits, health plans can define plan-specific clinical edit rules:

• State-specific edits — For example, Texas Medicaid-specific edits that go beyond federal NCCI rules
• LOB-specific edits — Medicare Advantage plans may have additional CMS-mandated edits not covered by standard NCCI files
• Plan-specific edits — Commercial plans may define edits based on medical policy (e.g., genetic testing requires specific diagnosis codes)

Edit Types Summary

Edit Type	Source	Example	Default Action
NCCI Column 1/2	CMS quarterly release	CPT 58661 bundled with CPT 49320 (laparoscopy)	Deny Column 2 line
MUE	CMS quarterly release	CPT 99213 limited to 1 unit per day	Deny excess units
Custom — State	State Medicaid agency	Texas TMHP-specific procedure bundling rules	Deny or pend per rule
Custom — Plan	Health plan medical policy	Genetic test CPT 81235 requires ICD-10 C50.x	Deny or pend per rule

4. Work Queues

Claims that cannot be fully auto-adjudicated are routed to one of five standard work queues for manual review. Each queue targets a specific type of exception, allowing specialized examiners to resolve claims efficiently.

Standard Work Queues

#	Queue	Description
1	NCCI/MUE Edit Failures	Claims with clinical edit denials (NCCI pair violations, MUE unit limit exceeded) requiring clinical review to determine if an override is justified
2	Missing Prior Auth	Service required prior authorization but no matching approved auth was found; examiner verifies if an auth exists outside the system or if a retroactive auth is warranted
3	Provider Not Contracted	Rendering provider is not in the member’s plan network; examiner determines if OON benefits apply, if single-case agreement exists, or if No Surprises Act protections apply
4	COB/Other Payer	Coordination of benefits issues — other payer information is missing, conflicting, or the member’s COB order needs to be verified with the member or other carrier
5	Medical Review	Claims flagged for medical necessity review based on dollar threshold (e.g., claims over $25,000), specific diagnosis codes, or random audit selection

Queue Assignment Rules

Queue routing is configurable at multiple levels:

• LOB-level — Different LOBs can have different queue routing thresholds (e.g., Medicaid claims over $10,000 go to Medical Review; Commercial threshold is $25,000)
• Claim type-level — Institutional claims may have different routing rules than professional claims
• Dollar threshold — Claims exceeding a configurable dollar amount are automatically routed to Medical Review regardless of auto-adjudication outcome
• Random audit — A configurable percentage of auto-approved claims are randomly sampled and routed to Medical Review for quality assurance

Queue Workflow

Each claim in a work queue progresses through a four-stage workflow:

Status	Description
Assigned	Claim assigned to the queue; awaiting examiner pickup
In Review	Examiner has opened the claim and is actively reviewing
Approved / Denied	Examiner has made a disposition decision; claim returns to the adjudication pipeline for finalization
Closed	Claim fully processed; payment or denial generated

SLA Tracking

Each work queue has a configurable SLA target. The system tracks time from queue assignment to resolution and escalates claims approaching or exceeding their SLA:

Queue	Typical Volume	SLA Target	Escalation Rule
NCCI/MUE Edit Failures	5–10% of claims	5 business days	Auto-reassign to senior clinical examiner at 4 days
Missing Prior Auth	3–8% of claims	10 business days	Notify auth coordinator at 7 days; escalate to supervisor at 9 days
Provider Not Contracted	2–5% of claims	10 business days	Notify network management at 7 days
COB/Other Payer	3–7% of claims	15 business days	Send member COB questionnaire at 5 days; escalate at 12 days
Medical Review	1–3% of claims	30 calendar days	Escalate to medical director at 25 days

5. Payment & Denial Output

After adjudication is complete — whether through auto-adjudication or work queue resolution — the system generates payment and denial outputs for both providers and members.

Claim Dispositions

Disposition	Member Impact	Provider Impact	ERA Action
Paid	Member responsibility calculated (copay/coinsurance/deductible); EOB generated	Payment issued via FFS payment run; 835 ERA generated	CLP01 = 1 (Processed as Primary)
Denied	No member responsibility; EOB with denial reason and appeal rights	No payment; 835 ERA with denial CARC/RARC codes	CLP01 = 4 (Denied)
Partial	Member responsibility on paid lines; EOB shows paid and denied lines	Payment for approved lines; 835 with line-level dispositions	Mixed CLP/SVC status codes
Adjusted	Updated EOB reflecting the adjustment; refund or additional payment if applicable	Adjustment payment or recoupment; corrected 835 ERA	CLP01 = 22 (Reversal) + new payment

CARC/RARC Reason Codes

Every denied or adjusted claim line includes standardized reason codes per the X12 835 standard:

• CARC (Claim Adjustment Reason Code) — Explains why the payment amount differs from the billed amount. Examples:
  • 1 — Deductible amount
  • 2 — Coinsurance amount
  • 3 — Copayment amount
  • 18 — Exact duplicate claim/service
  • 27 — Expenses incurred after coverage terminated
  • 45 — Charge exceeds fee schedule/maximum allowable
  • 197 — Precertification/authorization/notification absent
• RARC (Remittance Advice Remark Code) — Provides supplemental information. Examples:
  • N362 — Missing/incomplete/invalid service authorization number
  • N657 — This procedure code is not payable with the billed procedure code per NCCI
  • M15 — Separately billed services/tests have been bundled

EOB Generation

Member-facing Explanations of Benefits (EOBs) are generated for every adjudicated claim and include:

• Provider name, date of service, and services performed (plain-language descriptions)
• Billed amount, allowed amount, plan payment, and member responsibility breakdown
• For denied services: plain-language denial reason (translated from CARC/RARC codes), the specific plan provision that applies, and appeal instructions
• Accumulator summary showing current deductible and OOP max progress

EOBs are available in the member portal and can be delivered via email notification or physical mail based on member preference.

835 ERA Output

Provider-facing Electronic Remittance Advice is generated as part of the FFS Payment Run process. For full detail on 835 generation, payment batching, and disbursement channels (NACHA ACH, Stripe Connect), see the Finance Guide: FFS Payment Runs section.

Appeal Rights

Every denied claim includes appeal instructions that comply with state regulation and ACA requirements:

• Internal appeal — Member or provider can file an internal appeal within 180 days of the denial notice (ACA standard; state-specific timeframes may vary)
• External review — After exhausting internal appeals, the member can request an independent external review by a state-approved review organization
• Expedited review — Available for urgent/pre-service denials where standard timeframes could jeopardize the member’s health (decision within 72 hours)
• Provider appeals — Providers can appeal on behalf of the member with the member’s written authorization

Getting Started

Recommended setup order for a new health plan implementation:

1. Configure clearinghouse connectors — Set up SFTP connections for Availity, Change Healthcare, or your primary clearinghouse
2. Load NCCI/MUE edit files — Import the latest CMS quarterly release of NCCI physician/practitioner pairs and MUE values
3. Configure fee schedules — Load rate tables for Medicare RBRVS, Medicaid, and commercial contracts (see Fee Schedule Guide)
4. Configure benefit plans — Set up plan structures, cost sharing rules, and accumulators (see Benefit Plan Guide)
5. Set up work queue routing rules — Configure queue assignment thresholds per LOB, claim type, and dollar amount
6. Submit a test 837P through the pipeline — Use the Direct 837 Upload or the API to submit a sample professional claim
7. Review the auto-adjudication trace log and generated 835 — Verify each of the 10 pipeline steps executed correctly and the ERA output matches expected results

Related Documentation