Claim Processing - Technical Specification

Medical claim validation and processing engine

Purpose

The Claim Processing module handles the intake, validation, and processing of medical claims against legal cases. It performs comprehensive validation including vendor verification, patient matching, NPI validation, procedure code verification, and financial calculations. The system processes both retail and contracted rates, manages claim statuses, and maintains detailed audit trails for compliance.

Key Concepts

Term	Definition
Medical Claim	Request for payment for medical services rendered
Claim Status	Current state in the claim processing lifecycle
Vendor Verification	Validation of vendor Tax ID and active status
NPI Validation	National Provider Identifier verification
CPT Code	Current Procedural Terminology code for medical procedures
DOS (Date of Service)	Date when medical services were provided
Retail Rate	Standard rate before contractual adjustments
Contracted Rate	Negotiated rate based on provider contracts
Claim Procedure	Individual line item on a claim
Prior Authorization	Pre-approval required for certain services
TPA Flag	Third Party Administrator medical necessity indicator

User Roles

Role	Description	Permissions
Claims Processor	Primary claim processing and validation	Create, Read, Update
Claims Supervisor	Oversees claim processing team	All claim operations
Financial Analyst	Reviews claim financials	Read, Calculate rates
Provider Relations	Manages provider issues	Read, Update provider info
Compliance Officer	Ensures regulatory compliance	Read, Audit access
System Administrator	System configuration	All permissions

Field Documentation - Medical Claim Entity

Field Name	Type	Required	Description	Validation Rules	Related Entity
ID	String	Yes	Unique claim identifier	Auto-generated CUID	Primary Key
Claim Number	String	Yes	Human-readable claim number	Format: CLM-YYYY-XXXXXXX	-
Legal Case	LegalCase	Yes	Associated legal case	Must be active case	LegalCase
Patient	Patient	Yes	Patient receiving services	Must match case patient	Patient
Vendor	Vendor	Yes	Billing vendor/provider	Must be active vendor	Vendor
Tax ID	String	Yes	Vendor Tax ID	Must match vendor record	Vendor
Clinical Provider	ClinicalProvider	Yes	Rendering provider	Must have valid NPI	ClinicalProvider
NPI	String	Yes	Provider NPI	10-digit NPI validation	ClinicalProvider
Service Location	Location	Yes	Where services rendered	Must be valid location	Location
Date of Service	DateTime	Yes	When services provided	Cannot be future date	-
Date Received	DateTime	Yes	Claim receipt date	Auto-set on creation	-
Claim Status	String	Yes	Processing status	Enum: Received, Validating, Approved, Denied, Paid, Hold	-
Status Reason	String	No	Reason for current status	Required for Denied/Hold	-
Total Billed Amount	Decimal	Yes	Total retail charges	Sum of procedure amounts	-
Total Allowed Amount	Decimal	No	Total contracted amount	Calculated from rates	-
Total Paid Amount	Decimal	No	Amount actually paid	After adjustments	-
Prior Auth Number	String	No	Authorization reference	Must be valid auth	Authorization
Diagnosis Code 1	String	Yes	Primary diagnosis (ICD-10)	Valid ICD-10 format	-
Diagnosis Code 2	String	No	Secondary diagnosis	Valid ICD-10 format	-
Diagnosis Code 3	String	No	Tertiary diagnosis	Valid ICD-10 format	-
Diagnosis Code 4	String	No	Additional diagnosis	Valid ICD-10 format	-
Place of Service	String	Yes	Service location type	Valid POS code (11=Office, 21=Hospital)	-
Accident Related	Boolean	Yes	Related to case accident	Default true	-
Rendering Provider Name	String	Yes	Provider who rendered service	From provider record	ClinicalProvider
Referring Provider	String	No	Referring provider name	Free text	-
Referring NPI	String	No	Referring provider NPI	10-digit NPI if provided	-
TPA Medical Necessity	Boolean	No	Requires medical review	From contract terms	Contract
TPA Prior Auth Required	Boolean	No	Requires prior auth	From contract terms	Contract
Validation Status	String	Yes	Validation result	Pass, Fail, Warning	-
Validation Messages	Text	No	Validation details	JSON array of messages	-
Created At	DateTime	Yes	Creation timestamp	Auto-generated	-
Updated At	DateTime	Yes	Last update timestamp	Auto-updated	-
Created By	User	Yes	User who created	Valid user ID	User
Updated By	User	Yes	User who last updated	Valid user ID	User
Claim Procedures	ClaimProcedure[]	Yes	Line items	At least one required	ClaimProcedure (1:Many)
Audit Logs	AuditLog[]	No	Processing history	Auto-generated	AuditLog (1:Many)

Field Documentation - Claim Procedure Entity

Field Name	Type	Required	Description	Validation Rules	Related Entity
ID	String	Yes	Unique procedure ID	Auto-generated	Primary Key
Claim	MedicalClaim	Yes	Parent claim	Must exist	MedicalClaim
Line Number	Integer	Yes	Line item sequence	Sequential from 1	-
CPT Code	String	Yes	Procedure code	Valid CPT code	-
CPT Description	String	Yes	Procedure description	From CPT lookup	-
Modifier 1	String	No	CPT modifier	Valid modifier code	-
Modifier 2	String	No	Additional modifier	Valid modifier code	-
Units	Integer	Yes	Quantity of service	Positive integer	-
Billed Amount	Decimal	Yes	Retail charge per unit	Positive decimal	-
Total Billed	Decimal	Yes	Units × Billed Amount	Calculated field	-
Allowed Amount	Decimal	No	Contracted rate	From rate lookup	-
Total Allowed	Decimal	No	Units × Allowed Amount	Calculated field	-
Paid Amount	Decimal	No	Amount paid	After adjustments	-
Diagnosis Pointer	String	Yes	Which diagnosis applies	1,2,3, or 4	-
Date of Service	DateTime	Yes	Service date	Same as claim or specific	-
Revenue Code	String	No	Facility revenue code	For facility claims	-

Workflows

Claim Intake Workflow

1. Initial Receipt

   • Receive claim electronically or manually
   • Assign claim number
   • Set status to "Received"
   • Create audit log entry

2. Basic Validation

   • Verify required fields present
   • Check date formats
   • Validate claim not duplicate
   • Set status to "Validating"

Claim Validation Workflow (Complex)

1. Vendor Verification

   - Lookup vendor by Tax ID
   - Verify vendor is active
   - Confirm vendor type matches claim type
   - Check vendor contract status

2. Patient Validation

   - Match patient to legal case
   - Verify patient demographics
   - Confirm membership active on DOS
   - Validate MRN matches

3. Provider Validation

   - Verify NPI is valid (10-digit, checksum)
   - Confirm provider is credentialed
   - Check provider specialty matches service
   - Verify provider location

4. Procedure Validation

   - Validate CPT codes exist
   - Check CPT-diagnosis compatibility
   - Verify units within limits
   - Confirm modifiers are valid

5. Authorization Check

   - Look up authorization by case and provider
   - Verify DOS within auth dates
   - Check units don't exceed authorized
   - Validate service type matches auth

6. Rate Calculation

   - Determine contract type (TPA vs direct)
   - Look up contracted rates by:
     * Vendor + Specialty + Visit Kind
     * Vendor + Specialty + CPT
     * Vendor default rate
   - Apply rate type (percentage or amount)
   - Calculate allowed amounts

Claim Adjudication Workflow

1. Financial Calculation

   • Sum all procedure allowed amounts
   • Apply contractual adjustments
   • Calculate member responsibility
   • Determine payment amount

2. Compliance Check

   • Verify medical necessity (if TPA flag)
   • Check prior auth (if required)
   • Validate against benefit limits
   • Review for fraud indicators

3. Payment Decision

   • Approve for payment
   • Deny with reason codes
   • Hold for additional information
   • Partial payment determination

Business Rules

Validation Rules

• Vendor must be active with valid Tax ID
• Provider NPI must pass Luhn algorithm check
• Patient must match legal case patient
• DOS cannot be before case date of loss
• DOS cannot be in the future
• CPT codes must be valid for DOS
• Duplicate claims rejected (same patient, provider, DOS, CPT)

Rate Calculation Rules

• Check for most specific rate first (CPT level)
• Fall back to visit kind rates
• Use vendor default if no specific rate
• TPA contracts may have different rate structures
• Percentage rates apply to billed amount
• Amount rates replace billed amount

Authorization Rules

• Office visits (E&M codes) auto-approved
• Physical therapy requires authorization after initial eval
• Imaging requires prior authorization
• Surgery requires prior authorization
• Authorization must be active on DOS

Integrations

System	Integration Type	Purpose
Legal Case System	Direct Database	Case and patient validation
Vendor Management	Direct Database	Vendor and provider lookup
Contract Management	Direct Database	Rate determination
Authorization System	Direct Database	Prior auth verification
Financial System	Direct Database	Payment processing
NPI Registry	External API	NPI validation
CPT Database	Internal Database	Procedure code validation
Business Central	API Sync	Financial posting

Common Issues

Issue	Description	Resolution
Invalid NPI	NPI fails validation	Verify with provider, update record
No Rate Found	Contract rate not configured	Use default rate or hold
Expired Authorization	DOS after auth expiration	Retroactive auth process
Duplicate Claim	Same claim submitted twice	Reject duplicate, reference original
Missing Diagnosis	No diagnosis code provided	Return to provider
Tax ID Mismatch	Claim Tax ID doesn't match vendor	Verify correct vendor

Screenshots Needed

• Claim Entry Form
• Claim Search Interface
• Claim Detail View
• Validation Results Screen
• Rate Calculation Display
• Claim Status Timeline
• Procedure Line Items Grid
• Audit Trail View
• Denial Management Screen
• Payment Processing View

Performance Considerations

• Validation must complete within 5 seconds
• Support processing 10,000 claims/day
• Real-time NPI validation caching
• Rate lookup optimization required
• Bulk claim processing capability

Security Considerations

• PHI protection for all claim data
• Audit trail for all changes
• Role-based access to financial data
• Encryption of sensitive fields
• PCI compliance for payment data

Notes

• Claims cannot be deleted, only voided
• All validation steps are logged
• Failed validations don't stop processing, allow override
• Integration with clearinghouses planned for Phase 2