Calculation type
Looks up a per-unit Medicare DME fee for the charge's procedure code (state- and modifier-specific, with a national wildcard fallback) via SQL, multiplies by units, then rescales by a RuleMultipliers match or Percentage/100.
ChargeLevelSqlCalculator.Calculate loops charges i=1..NumCharges-1, skipping IgnoreCharge. MedicareDMESqlGenerator.GetParameters: if StateCode is unset, resolve it from Facility's Entity/StateCode XML by @FacilityKey (stays null if that also fails); build @IncomingMods from the charge's first two Modifier-dimension codes as a '%+MOD%'-style pattern (lexically ordered if two are present). GetQuery: SELECT TOP 1 MedicareDataDME.Fee (CAST to MONEY) joined to a MedicareScheduleDME/MedicareSchedule map whose EndDate is computed per-state via LAG(StartDateEffective) DESC; WHERE Fee != 0 AND @BaseDate is within [StartDate,EndDate) AND ProcedureCode = @ProcedureCode AND @IncomingMods LIKE FilterString.Val (FilterString is a pattern built from the fee row's own ProcedureModifier1/2 -- so the row's required modifiers must be a substring of the charge's incoming modifiers) AND (@StateCode IS NULL OR row state = @StateCode), ORDER BY LEN(FilterString.Val) DESC (rows demanding modifiers beat the '%' wildcard row). ChargeLevelSqlCalculator.SetDetails then: amount = fee * charge.Units; amount = Math.Round(amount,2,AwayFromZero); amount *= matched RuleMultipliers[x].Multiplier if IHasRuleMultipliers finds a match, else *= DefaultMultiplier (=Percentage/100, default 1.0); re-round to 2dp AwayFromZero; detail.SetBase(amount, calc).
| Key | Meaning |
|---|---|
| StateCode | Optional 2-letter state code (declared directly on MedicareDMECalculation, StringField). Null triggers a facility-XML lookup; if that also comes back null, the query matches any state's fee row with no deterministic tiebreak beyond modifier specificity. |
| BaseDate | Optional override date (DateField, inherited from MedicareCalculation) selecting the DME schedule period; defaults to context.ServiceDate. |
| Percentage | Decimal, default 100 (inherited via ChargeLevelSqlCalculation/MedicareCalculationField<T>); feeds DefaultMultiplier = Percentage/100, used only when no RuleMultipliers rule matches. |
| RuleMultipliers | List<IMultiplierRule> (IHasRuleMultipliers); first matching rule's Multiplier overrides the Percentage-derived DefaultMultiplier. |
Gotchas
The type-specific case arm in ApplyBaseCalculation is actually 'case ChargeLevelSqlCalculation chargeLevelSqlCalc' (CalculationEngine.cs:703) -- it dispatches on the shared base class, not on MedicareDMECalculation by name; the real per-type routing happens one level deeper in SqlCalculationSqlGeneratorFactory.Get (case MedicareDMECalculation, SqlCalculationSqlGeneratorFactory.cs:15-16), which the draft never cited. Rounding order matters and was missing from the draft: fee*Units is rounded to 2dp AwayFromZero BEFORE the Percentage/RuleMultiplier is applied, then rounded again -- not one rounding pass at the end. The draft's formula also omitted the 'WHERE MedicareDataDME.Fee != 0' filter, which silently excludes zero-fee schedule rows from matching at all (they will not be picked even as a fallback). If StateCode ends up null after the facility-XML fallback, the query can return a fee from an arbitrary state (SQL Server's TOP 1 tiebreak is undefined when multiple states tie on modifier-pattern length) -- this is a real nondeterminism risk the draft did not surface. Charges with modifiers beyond the first two on the Modifier dimension are silently ignored (only ElementAtOrDefault(0)/(1) are read).
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Calculations/Medicare/MedicareDMECalculation.cs:6
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Calculations/Medicare/MedicareDMESqlGenerator.cs:12
dispatch · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CalculationEngine.cs:703
CORRECTED: the draft's overall description was directionally right (schema lookup + Percentage/RuleMultiplier scaling) but omitted the Fee != 0 filter, the round-before-multiply-then-round-again order, the state-tiebreak nondeterminism when StateCode resolves to null, and mischaracterized the dispatch site as type-specific when it is actually a shared ChargeLevelSqlCalculation case arm with the real routing in SqlCalculationSqlGeneratorFactory.