Fee Schedule Guide

End-to-end guide to fee schedule configuration in Cloud Health Office — from Medicare RBRVS and Medicaid rate loading through commercial contracted rates, DRG-based inpatient pricing, and multiple procedure reduction rules. Covers the FeeScheduleEngine used during claims adjudication repricing.

Overview

Fee schedule configuration determines how much Cloud Health Office pays for every procedure, service, and inpatient stay. The FeeScheduleEngine evaluates each claim line during Step 6 (Repricing) of the auto-adjudication pipeline, resolving the allowed amount based on the member’s benefit plan, provider contract, and applicable fee schedule rules.

1. Rate Tables

Rate tables define the allowed amount for each procedure code, modifier, and place of service combination. Cloud Health Office supports multiple fee schedule types, each serving a different pricing methodology.

Fee Schedule Types

Fee Schedule Type	Source	Update Frequency	Typical Use
Medicare RBRVS	CMS annual release (Physician Fee Schedule)	Annually (January) + quarterly updates	Medicare Advantage, benchmark for commercial rates
Medicaid State Schedule	State Medicaid agency (e.g., TMHP for Texas)	Varies by state (quarterly to annually)	Medicaid managed care, CHIP
Commercial Contracted	Provider contract negotiation	Per contract term (typically 1–3 years)	Commercial HMO/PPO/POS plans
Per Diem	Provider contract (daily rate by service type)	Per contract term	Inpatient facility claims, SNF, rehab
Percent of Billed	Contract or fallback configuration	As configured	Out-of-network, fallback when no other rate exists
Case Rate	Provider contract (flat rate per episode)	Per contract term	Bundled payments (e.g., maternity global, joint replacement)

Rate Table Structure

Each rate table entry maps a procedure code to a payment rate using the following key fields:

Field	Description	Example
Procedure Code	CPT or HCPCS code identifying the service	99213 (office visit), 27447 (total knee)
Modifier	Modifier that affects the rate (optional)	26 (professional component), TC (technical component)
Place of Service	POS code where the service is rendered	11 (office), 22 (outpatient hospital)
Rate	Allowed amount in dollars	$92.33
Effective Date	Date the rate becomes active	2026-01-01
Term Date	Date the rate expires (null = open-ended)	2026-12-31 or null

Procedure Code + Modifier + Place of Service + Date of Service → Matched Rate

Example: 99213 + 26 + 11 + 2026-03-15 → $92.33

Geographic Locality Adjustments

Rates vary by geographic region to account for differences in practice costs:

• Medicare GPCI (Geographic Practice Cost Index) — CMS publishes three GPCI components per locality: Work, Practice Expense, and Malpractice. The RBRVS rate is calculated as: (Work RVU × Work GPCI + PE RVU × PE GPCI + MP RVU × MP GPCI) × Conversion Factor
• Medicaid locality factors — State-specific adjustments (e.g., Texas TMHP uses locality-adjusted rates for urban vs. rural areas)
• Commercial contracts — May use flat rates per provider/facility or apply locality adjustments based on the provider’s practice ZIP code

Rate Loading

Fee schedule rates can be loaded into the system through multiple channels:

• Bulk import (CSV/Excel) — Upload a file containing procedure codes, modifiers, POS, rates, and effective dates. The system validates the file format and identifies duplicate or conflicting rates before committing.
• API upload — Programmatic rate loading via the Fee Schedule API. Used for automated CMS rate updates and clearinghouse integrations.
• Portal manual entry — Individual rate creation and editing through the admin portal. Suitable for one-off rate corrections or contract-specific overrides.

Rate Versioning

Each fee schedule maintains a full version history. When a new rate is loaded for a procedure code that already has an active rate, the existing rate is automatically term-dated and the new rate takes effect on its configured effective date. Claims are always repriced using the rate that was effective on the date of service, ensuring that historical claims can be reprocessed with the correct rate even after rate updates.

2. DRG-Based Inpatient Pricing

Inpatient facility claims are typically priced using Diagnosis-Related Groups (DRGs) rather than individual procedure code rates. The DRG grouper assigns each inpatient stay to a DRG category based on clinical data, and the payment is calculated from the DRG’s relative weight and the facility’s base rate.

DRG Types

DRG Type	Grouper	Input Data	Output	Typical Payer Use
MS-DRG	CMS MS-DRG Grouper (v42+)	Principal diagnosis, secondary diagnoses, procedures, discharge status, age, sex	MS-DRG number + relative weight	Medicare, Medicare Advantage, some commercial
APR-DRG	3M APR-DRG Grouper	Same as MS-DRG + severity of illness (SOI) and risk of mortality (ROM) subclasses	APR-DRG number + SOI/ROM level + relative weight	Medicaid managed care, CHIP, some commercial

DRG Pricing Formula

The payment for a DRG-priced inpatient claim is calculated as:

• Base Rate — Configured per hospital or per line of business. Represents the standardized payment amount before DRG adjustment. Can vary by contract (e.g., Hospital A has a base rate of $6,200; Hospital B has $5,800).
• DRG Relative Weight — A numeric factor assigned to each DRG that reflects resource intensity. A DRG with weight 1.0 represents the average; higher weights indicate more costly cases. Example: MS-DRG 470 (Major Hip/Knee Joint Replacement) has a relative weight of approximately 1.74.
• Outlier Adjustment — Additional payment for exceptionally costly or long-stay cases (see below).

Outlier Calculations

Outlier payments protect hospitals from excessive losses on unusually costly cases:

• Cost outlier — Triggered when the hospital’s cost for the case exceeds the DRG payment by a threshold amount (typically the DRG payment × 3 or a fixed dollar threshold). The outlier payment covers a percentage (typically 80%) of the cost above the threshold.
• Day outlier — Triggered when the length of stay (LOS) exceeds the DRG’s geometric mean LOS plus a configurable threshold (e.g., geometric mean + 20 days). A per-diem rate is applied for each day beyond the threshold.

Transfer Pricing

When a patient is transferred to another facility before completing the full DRG episode, the transferring hospital receives a per-diem transfer rate instead of the full DRG payment:

• Transfer per-diem — Full DRG payment ÷ geometric mean LOS × actual LOS (capped at the full DRG payment)
• Transfer DRGs — CMS designates specific DRGs as transfer-eligible; non-transfer DRGs pay the full amount regardless of discharge status

3. Multiple Procedure Rules

When multiple procedures are performed during the same encounter, payment reduction rules apply to prevent overpayment. The FeeScheduleEngine applies these rules automatically during repricing based on the claim’s procedure codes, modifiers, and configuration.

Multiple Procedure Reduction

When multiple procedures are performed in the same operative session:

1. All procedures on the claim are ranked by allowed amount in descending order
2. The highest-valued procedure (primary) pays at 100% of the fee schedule rate
3. The second procedure pays at a reduced rate (typically 50%)
4. Third and subsequent procedures pay at a further reduced rate (typically 25%)

Reduction percentages are configurable per fee schedule and can vary by procedure category.

Rule Types

Rule Type	Application	Rate Adjustment	Modifier Exceptions
Multiple Procedure Reduction	2+ procedures in same session	100% / 50% / 25% (configurable)	Modifier 59, XE, XS, XP, XU bypass reduction
Bilateral Procedure	Procedure performed on both sides	150% of single rate (or 100% × 2, per contract)	Modifier 50 triggers bilateral logic
Assistant Surgeon	Assistant surgeon present during procedure	16% of primary surgeon allowed amount	Modifier 80, 81, 82 identify assistant surgeon claims
Co-Surgery	Two surgeons performing distinct portions	62.5% each (configurable)	Modifier 62 identifies co-surgery
Global Surgery	Pre/post-op visits within global period	$0 (included in surgical rate)	Modifier 24, 25, 57, 58, 78, 79 override global denial

Global Surgery Periods

Surgical procedures include a global period that covers related pre-operative and post-operative services:

• 0-day global — Minor procedures (e.g., lesion destruction); only the day-of visit is included
• 10-day global — Minor surgical procedures; includes the day of surgery + 10 post-operative days
• 90-day global — Major surgical procedures; includes 1 pre-operative day + day of surgery + 90 post-operative days

E/M visits billed during the global period by the same provider for the same diagnosis are denied as included in the surgical rate. Modifiers 24 (unrelated E/M during post-op), 25 (significant, separately identifiable E/M on the same day), and 57 (decision for surgery) override the global period denial.

Modifier-Based Exceptions

4. Cross-Schedule Resolution

When the primary fee schedule assigned to a member’s benefit plan does not contain a rate for a given procedure code, the FeeScheduleEngine falls through a configurable resolution hierarchy to find an applicable rate.

Default Resolution Hierarchy

1. Provider Contract Rate — Rate negotiated in the provider’s contract for the specific procedure code and modifier. Checked first because contract terms take precedence.
2. Plan-Specific Rate — Rate configured at the benefit plan level (e.g., a plan-specific override table for certain high-cost procedures).
3. Medicaid State Fee Schedule — State Medicaid fee schedule rate. Applicable for Medicaid managed care when the primary contract does not include the procedure.
4. Medicare RBRVS — CMS Physician Fee Schedule rate with applicable GPCI adjustments. Used as a widely-accepted benchmark rate.
5. Percent of Billed (Fallback) — A configurable percentage of the provider’s billed amount (e.g., 80% of billed charges). Used only when no other rate source is available.

Contract Rate (provider-specific) → Plan Fee Schedule (LOB-level) → Medicaid State Fee Schedule → Medicare RBRVS (GPCI-adjusted) → % of Billed Charges (fallback)

Medicaid Cross-Schedule

Medicaid programs frequently reference Medicare rates when the state fee schedule does not include a procedure code. For example, Texas Medicaid (TMHP) uses cross-references to the CMS Physician Fee Schedule when the TMHP fee schedule has no rate for a given CPT code. Cloud Health Office supports this cross-schedule logic as a configurable rule:

• Primary schedule: TMHP State Fee Schedule
• Cross-reference: Medicare RBRVS with Texas locality GPCI
• Adjustment: configurable percentage of Medicare rate (e.g., 95% of Medicare)

Rate Floor / Ceiling

Regardless of which fee schedule the rate is resolved from, configurable floor and ceiling amounts can be applied:

• Rate floor — Minimum allowed amount for any procedure (e.g., $5.00). Prevents $0 or extremely low rates from being applied to claims.
• Rate ceiling — Maximum allowed amount for any procedure (e.g., $50,000). Prevents erroneously high rates from being applied without review.
• Floor and ceiling can be configured globally, per fee schedule, or per procedure code range.

No-Rate Handling

5. Repricing API

The FeeScheduleEngine is exposed via the Claims Repricing API at cloudhealthoffice.com/pricing-api, enabling real-time rate lookup and repricing outside the claims adjudication pipeline.

API Interface

The Repricing API accepts claim line details and returns the resolved allowed amount along with full transparency into which fee schedule and rules were applied:

API Endpoint	Method	Input	Output
/api/v1/reprice	POST	Procedure code, modifier, POS, date of service, provider NPI, member plan, LOB	Allowed amount, fee schedule used, rate effective date, multiple procedure adjustments
/api/v1/reprice/batch	POST	Array of claim lines (same fields as single reprice)	Array of repricing results with per-line detail
/api/v1/reprice/estimate	POST	Procedure code, modifier, POS, provider NPI, plan ID	Estimated allowed amount (uses current date; no member-specific accumulators)
/api/v1/fee-schedules/{id}/rates	GET	Fee schedule ID, optional procedure code filter	Rate table entries matching the filter criteria

Request & Response

A typical repricing request includes:

• Procedure code — CPT or HCPCS code for the service
• Modifier(s) — Up to four modifiers that may affect the rate or trigger reduction rules
• Place of service — POS code (e.g., 11 office, 22 outpatient hospital)
• Date of service — Used for rate effective date matching and geographic adjustments
• Provider NPI — Resolves the provider’s contract and network tier
• Member plan / LOB — Determines the applicable fee schedule and cross-schedule resolution hierarchy

The response includes:

• Allowed amount — The final repriced amount after all rules and adjustments
• Fee schedule used — Which fee schedule in the resolution hierarchy provided the rate
• Rate effective date — The effective date of the matched rate entry
• Multiple procedure adjustments — Any reduction percentages applied (for batch repricing with multiple lines)
• Resolution path — The full hierarchy traversal showing which schedules were checked

Use Cases

• Real-time repricing during claim submission — Front-end claim entry screens call the Repricing API to display the expected allowed amount before the claim is submitted to the adjudication pipeline
• Provider contract modeling — “What if” scenarios comparing current contracted rates against proposed new rates for contract negotiation
• Network adequacy rate analysis — Batch repricing of historical claims against a proposed fee schedule to evaluate financial impact before loading the schedule into production
• Member cost estimation — Combined with benefit plan cost sharing rules, the repricing result can estimate the member’s out-of-pocket responsibility for a planned service

Getting Started

Recommended setup order for a new health plan implementation:

1. Load Medicare RBRVS rates — Import the annual CMS Physician Fee Schedule release as the baseline rate source
2. Load Medicaid state fee schedules — Import the applicable state fee schedule(s) for Medicaid LOBs
3. Configure DRG base rates by hospital/LOB — Set facility base rates and load DRG relative weights per hospital contract
4. Set up multiple procedure reduction rules — Configure reduction percentages, bilateral logic, and modifier exception handling
5. Configure cross-schedule resolution hierarchy — Set the fallback order, Medicaid cross-references, and percent-of-billed default
6. Test repricing with sample claims — Submit test claims through the Repricing API and verify the FeeScheduleEngine resolves correct rates
7. Verify rates match expected QNXT/legacy system rates — Run a batch comparison of repriced amounts against the legacy system to confirm parity

Related Documentation