Calculation type
Caps the Medicare technical-component (TC) allowed amount at the comparable OPPS ceiling: for MedicareRVU-priced charges with a positive OPPS candidate rate that are not professional-component-only and don't carry both TC and 26 modifiers, computes a post-MPPR TC amount (from an existing detail.PostMPPR split if an earlier ophthalmology/radiology MPPR step wrote one, otherwise from detail.Amount for TC-modifier charges or from a freshly computed technical/professional component split for charges with neither TC nor 26 modifier), and reduces the charge's total allowed amount by the excess of that TC amount over the OPPS ceiling (never below zero); the professional component, if already split out, is preserved untouched.
For each charge i=1..NumCharges-1: skip unless (base calc == MedicareRVU) AND detail.HasOPPSCandidate AND !IgnoreCharge AND !(HasCode("26") && !HasCode("TC")) AND !(HasCode("26") && HasCode("TC")). If charge has modifier TC: postMPPRTC = detail.PostMPPR?.Technical ?? detail.Amount; oppsTCCeiling = detail.OPPSAmount. Else (charge has NEITHER TC nor 26 modifier — i.e. a single unsplit/'global' line; charges with both modifiers were already excluded above): components = MedicareRVUComponentCalculator.Calculate(context, charge); skip if components.Technical is null or lacks an OPPS candidate; if detail.PostMPPR is already set, postMPPRTC/preservedPC come from that split, else from components.Technical.Amount / components.Professional?.Amount ?? 0; oppsTCCeiling = components.Technical.OPPSAmount. reduction = max(0, postMPPRTC - oppsTCCeiling); if reduction==0, skip entirely (no Adjust call at all — not even a no-op re-stamp). Else result = max(0, detail.Amount - reduction); detail.Adjust(result, adjustment).
Gotchas
The 'else' branch is NOT for 'combined PC/TC charges' as an earlier draft phrased it — HasBothComponentModifiers already excludes any charge carrying both 26 AND TC. The else-branch actually fires for charges carrying NEITHER modifier (a single unsplit 'global' line); true 26+TC charges get no OPPS cap applied at all. // When reduction==0 the method does an early `continue` with no Adjust() call whatsoever — unlike MultipleEndoscopy/MultipleRadiology in this same codebase, which deliberately re-stamp Adjust(unchanged) so their marker appears in Adjustments, a charge here shows NO MedicareOPPSCapAdjustment entry in its Adjustments list when the cap doesn't bind, which matters for any downstream code (e.g. MultipleProcedureAdjustment's interaction flags) that checks detail.HasAdjustment(...) rather than re-deriving eligibility. // adjustment.CustomDescription is mutated on the single shared MedicareOPPSCapAdjustment instance inside the per-charge loop — each iteration overwrites the previous charge's description text right before Adjust() snapshots it into that charge's own Adjustments record, so reading adjustment.CustomDescription off the shared instance after the loop returns only the last-processed charge's text.
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/MedicareOPPSCapAdjustment.cs:6
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Adjustments/Calculators/MedicareOPPSCapAdjustmentCalculator.cs
dispatch · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CalculationEngine.cs:734
CORRECTED - re-read MedicareOPPSCapAdjustment.cs and MedicareOPPSCapAdjustmentCalculator.cs in full plus the dispatch case (CalculationEngine.cs:734-737). Draft's formula, dispatch, category/level, empty key_attrs, and citations were all accurate, but its summary/formula mischaracterized the non-TC branch as 'combined PC/TC charges' when the code actually restricts that branch to charges with neither TC nor 26 modifier (true 26+TC charges are excluded upstream). Also added the no-re-stamp-on-reduction==0 and shared-instance CustomDescription gotchas the prior pass omitted.