Calculation type

CaseRate

Sets the base allowed amount for a single selected charge in the account from a case-rate fee schedule (flat CaseRate plus capped per-diem overage), then zeroes out every other charge's base amount so the whole account's allowed amount is carried on that one charge.

62
uses
5
customers
Base
category
Account
applies at

What it computes

records = GetCaseRateScheduleRecords(ctx, ScheduleType); chargeIndex = GetChargeIndex(ctx, records) [Account mode: always 0; All mode: scan i=0.. for first records[i]!=null, default 0 if none found; Charge mode: scan i=1.. for first records[i]!=null, default 0 if none found]; record = records.ElementAtOrDefault(chargeIndex); if record==null: return (no-op, nothing zeroed); charge = Charges[chargeIndex]; if IgnoreCharge(calc, charge, ctx): return (no-op -- neither SetBase nor the zero-out of other charges happens); amount = record.CaseRate; if charge.Units > record.PerDiemThreshold: diems = min(charge.Units - record.PerDiemThreshold, record.PerDiemMaximum); amount += record.PerDiem * diems; Details[chargeIndex].SetBase(amount, calc); for i in 0..NumCharges, i != chargeIndex: Details[i].SetBase(0.0, calc)

Parameters

KeyMeaning
ScheduleTypeKey of the named case-rate schedule (CaseRateScheduleRecord rows: CaseRate, PerDiem, PerDiemThreshold, PerDiemMaximum, keyed by code) to look up
ModeCaseRateMode enum: All (scan all charges from index 0 for the first with a matching schedule record), Account (always use the account-level pseudo-charge at index 0), or Charge (scan charges from index 1 onward, skipping the account row)

Gotchas

CalculationLevel always reports Account (hardcoded, CustomerDataModel.cs:736) even though the calculator writes a single Charge-index line via SetBase plus zeroes the rest -- 'Account' describes the effective scope of the result, not which context.Details index is touched for Mode=All/Charge. The IgnoreCharge check on the *selected* charge fires after chargeIndex/record selection but before either SetBase or ZeroOutOtherCharges runs, so if the one line the schedule matched happens to be filtered by an ignore rule, the entire calculation is a true no-op -- no charge gets the case rate AND no other charges get zeroed, which is a materially different outcome from 'the case rate charge is zero.' PerDiemMaximum caps the diem *count*, not the dollar amount, so a very large PerDiem rate is uncapped in dollars. GetChargeIndex defaults to 0 both when Mode==Account (intentional) and when All/Charge mode finds no matching record at all (in which case records.ElementAtOrDefault(0) is then checked and will itself likely be null, causing the early no-op return) -- the same 'chargeIndex=0' value means two different things depending on why it was reached.

In the source

class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CustomerDataModel.cs:734
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Calculations/CaseRateCalculator.cs
dispatch · CalculationEngine.cs:668-669 (case CaseRateCalculation caseRate: new CaseRateCalculator(caseRate, this).Calculate(context)); note a second, separate CaseRate-specific code path exists at CalculationEngine.cs:1019-1021 (else if calc.Type == CalculationType.CaseRate) for a different purpose (schedule-record lookup helper), not an alternate dispatch of the pricing algorithm

CONFIRMED - class declaration read at CustomerDataModel.cs:734-750 (ScheduleTypeCalculation, IBaseCalculation; CalculationLevel hardcoded Account at line 736), dispatch confirmed at CalculationEngine.cs:668-669, full calculator algorithm read at CaseRateCalculator.cs:1-102. Draft's formula, key_attrs, and CalculationLevel-vs-scope observation were all accurate; added the post-selection IgnoreCharge early-return gotcha (draft's notes omitted it) and the PerDiemMaximum-caps-count-not-dollars clarification.