Calculation type
Applies Medicare's standard multiple-surgery reduction: ranks charges whose ASC-data rollup (MedicareDataASC.MultipleProcedureDiscount, matched by bare procedure code) equals the qualifying code ("Y" for the Medicare variant, base class default "T") and pays each successive ranked unit at a configured percentage of its per-unit amount.
affected = charges (i=1..NumCharges-1) where !IgnoreCharge and rollups[i]?.Code == adjustment.QualifyingCode ("Y"), rollups resolved via medicareAdjustmentRepo's IMultipleSurgeryScheduleRepo implementation (MedicareDataASC.MultipleProcedureDiscount, keyed by bare ProcedureCode with no modifier awareness) — then ordered via calculationEngine.GetChargeOrder(context, affected, SortBy). adjustedIndex and percentage are shared state across all affected charges (not reset per charge), starting at 0 and 1 respectively. For each affected charge: units = Math.Max(charge.Units, 1) (guards zero-Units charges, unlike the sibling MultipleProcedureAdjustment); unitAmount = detail.Amount/units; for i in 0..units-1: if adjustedIndex < Percentages.Count, percentage = Percentages[adjustedIndex]/100 (else keeps prior value); chargeAmount += MoneyMath.Multiply(unitAmount, percentage); adjustedIndex++. detail.Adjust(chargeAmount, adjustment) if chargeAmount != detail.Amount.
| Key | Meaning |
|---|---|
| QualifyingCode | Overridden constant "Y" (`public override string QualifyingCode => "Y";`, base class default is "T"); confirmed at MedicareMultipleSurgeryAdjustment.cs:12 |
| SortBy | Ranks affected charges before Percentages apply; not overridden by the Medicare constructor, so it inherits the base protected constructor's default AmountAllowed |
| Percentages | Not overridden by the Medicare constructor either — inherits base class default {100, 50}; last value repeats once the list is exhausted |
| ScheduleType | Explicitly set to null in the Medicare constructor; also cosmetic since medicareAdjustmentRepo's IMultipleSurgeryScheduleRepo implementation ignores the scheduleType argument regardless |
Gotchas
(1) Unlike MultipleProcedureAdjustmentCalculator, this calculator guards zero-Units charges with Math.Max(charge.Units, 1), so a qualifying zero-unit charge is priced as 1 unit rather than zeroed — but it still consumes one Percentages/adjustedIndex slot for that phantom unit, shifting every later charge's rank down by one. (2) The qualifying-code rollup for this type comes from a DIFFERENT data source than Procedure/Endoscopy/Radiology use: MedicareDataASC.MultipleProcedureDiscount (ASC data, matched by bare ProcedureCode only, no TC/26 modifier awareness), not MedicareDataRVU.MultiProcedureCategoryCode (RVU data, modifier-aware) — a reimplementer assuming all four Medicare Multiple* adjustments share one rollup table would get this one wrong. (3) ScheduleType is forced null in the constructor, but that's cosmetic — the injected repo ignores whatever scheduleType value it's given, same pattern as the other three types. (4) MedicareMultipleSurgeryAdjustmentField's constructor calls `base(nameof(CalculationType.MedicareMultipleEndoscopyAdjustment))` instead of MedicareMultipleSurgeryAdjustment — a copy/paste bug (MedicareMultipleSurgeryAdjustment.cs:54) that gives this UI Field's underlying Name the wrong calc-type string. DataField.Name is what GetChild(name) matches on elsewhere in CustomerSchema.cs, so this is a latent schema/UI-serialization defect distinct from (and not affecting) the correctly-wired runtime dispatch in CalculationEngine.cs.
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/MedicareMultipleSurgeryAdjustment.cs:9
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/Calculators/MultipleSurgeryAdjustmentCalculator.cs
dispatch · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CalculationEngine.cs:774-777
CORRECTED — the draft's QualifyingCode override, Percentages/SortBy inheritance, formula, and dispatch site all checked out against MultipleSurgeryAdjustment.cs and MultipleSurgeryAdjustmentCalculator.cs. It missed that the qualifying-code data source (ASC vs RVU) differs from the sibling Medicare adjustments, the zero-Units handling difference from MedicareMultipleProcedureAdjustment, and a real copy/paste bug in MedicareMultipleSurgeryAdjustmentField's constructor.