Calculation type
For physical-therapy charges identified by a fee schedule, the single highest per-unit-ranked unit across all affected charges is left at its own computed amount and every other unit is replaced by a flat schedule Amount; the recomputed total is applied only if it is lower than the charge's current allowed amount (a decrease-only gate, not a per-unit cap).
records = GetFeeScheduleRecords(context, calc.ScheduleType); affected = charges (i=1..NumCharges-1) not IgnoreCharge'd with records[i]!=null, tracking affectedUnits = sum(charge.Units); if affectedUnits <= 1, return (no-op). affected = GetChargeOrder(context, affected, SortChargesBy.AmountAllowed) - hardcoded, not a configurable SortBy field. unitIndex starts at 0 and increments across ALL units of ALL affected charges combined; for each affected charge: x = detail.Amount/charge.Units (or detail.Amount if Units==0); for each unit: if unitIndex++ == 0, s += x (the one exempt unit keeps its own computed per-unit amount); else s += record.Amount (the flat schedule amount, which can exceed x). detail.Adjust(s, calc) only if s < detail.Amount.
| Key | Meaning |
|---|---|
| ScheduleType | Inherited from ScheduleTypeCalculation; used to look up a flat-dollar FeeScheduleRecord per charge code via GetFeeScheduleRecords (a plain fee lookup, not a rollup/CodeScheduleRecord as the other Multiple* adjustments use). |
Gotchas
1) SortBy is not configurable on this class - sorting is hardcoded to SortChargesBy.AmountAllowed inside CalculateMultiplePhysiotherapyAdjustment (CalculationEngine.cs:1840), unlike MultipleProcedureAdjustment/MultipleSurgeryAdjustment/MultipleEndoscopyAdjustment/MultipleRadiologyAdjustment which all expose SortBy. 2) Non-first units are REPLACED by the flat schedule Amount, which can be HIGHER than the charge's own per-unit computed amount x - there is no per-unit ceiling; the only safeguard is the final `s < detail.Amount` gate on the recomputed total, so a misconfigured (too-high) schedule Amount can only fail to apply, never increase the allowed amount. 3) The whole adjustment is a hard no-op (return with zero effect, no marker) unless the total Units across all matching charges exceeds 1 - a lone single-unit PT charge with no other matching lines is left completely untouched. 4) A code comment at CalculationEngine.cs:1839 explicitly flags that same-service-date charges should be distinguished from different-date charges for this rule, but that filter is not implemented ('we don't support that yet') - charges from different dates of service are pooled as if from one encounter.
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CustomerDataModel.cs:1006
dispatch · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CalculationEngine.cs:783-785
CORRECTED - the draft's `formula` field was accurate per the critique's own spot-check, but its `summary` field used 'capped' language that the critique correctly flagged as misleading (the per-unit substitution can raise the running sum; only the final total-vs-original comparison prevents an increase). This record's summary/formula reconcile that distinction explicitly.