Calculation type
Legacy (non-Medicare) bilateral-surgery adjustment: for each distinct affected procedure code, prices one unit of that code by re-running the full base-calculation chain (not a flat fee-schedule lookup), applies a 1.5x multiplier when the code's schedule rollup indicator is "1", caps the result at the total charged amount across all lines carrying that code (account-level pseudo-charge included), then walks the charges in AmountAllowed order allocating the capped amount across them.
For each distinct affected charge code (charges with rollup.Code in {"0","1","2"}, not IgnoreCharge, scanned i=1..NumCharges-1, first-seen rollup kept): singleChargeAllowed = tempContext.Details[1].Amount after calculationEngine.CalculateAmountAllowedBase(tempContext) on a synthetic 1-unit charge of that code (full base-calculation re-run, i.e. CaseRate/PercentOfFees/whatever the account's actual base calc is -- not a schedule lookup); if rollup=="1": singleChargeAllowed *= 1.5. affected = all charges j (j starting at 0, i.e. including the account-level pseudo-charge) where Charges[j].HasCode(dim, code); c = sum(Charges[j].AmountCharged for j in affected); if c < singleChargeAllowed: singleChargeAllowed = c. affected sorted by SortChargesBy.AmountAllowed (hardcoded, no configurable SortBy). Walk sorted affected: if detail.Amount >= remaining cap, Adjust(detail, cap) and zero the remaining cap; else remaining cap -= detail.Amount (charge left unadjusted).
| Key | Meaning |
|---|---|
| ScheduleType | Key of the schedule used only to find the rollup indicator (via CodeScheduleRecord, restricted to indicators "0"/"1"/"2") and the ChargeCodeDimension; it does NOT supply a dollar fee -- the single-unit price comes from re-running the engine's own base calculation. |
Gotchas
1) GetBaseAllowedForSingleUnitOfCharge (Calculator.cs:104-118) calls calculationEngine.CalculateAmountAllowedBase on a temp context -- this re-executes the account's entire base calculation logic (e.g. CaseRate, PercentOfFees, whatever is configured), so a reimplementer who treats ScheduleType as 'the fee schedule to price against' will get the wrong number; ScheduleType only resolves the rollup indicator and ChargeCodeDimension. 2) The affected-code list is de-duplicated by charge code and the rollup indicator used for the 1.5x check is whichever line's rollup was encountered FIRST (ascending charge index) for that code, not e.g. the highest-ranked line. 3) The inner allocation loop over 'affected' charges for the code starts at j=0, so the account-level pseudo-charge (Charges[0]) participates and can absorb/contribute to the cap if it happens to carry the affected code. 4) Uses detail.Adjust (records a delta), consistent with category=Adjustment despite the class internally calling CalculateAmountAllowedBase (a 'base' calculation method) as a helper.
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/BilateralSurgeryAdjustment.cs:6
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/Calculators/BilateralSurgeryAdjustmentCalculator.cs
dispatch · CalculationEngine.cs:799
CORRECTED: the draft's formula said the algorithm 'prices a single unit of that code against a fee schedule' -- confirmed false by reading BilateralSurgeryAdjustmentCalculator.cs; GetBaseAllowedForSingleUnitOfCharge actually re-runs CalculateAmountAllowedBase (the full base-calculation chain), not a schedule lookup. This matches critique.md's independent finding on the same type. All other draft claims (rollup indicator set, 1.5x multiplier, cap at total charged, hardcoded AmountAllowed sort, dispatch site) were re-read against BilateralSurgeryAdjustment.cs and BilateralSurgeryAdjustmentCalculator.cs and confirmed correct.