Calculation type
Looks up the national Medicare ASP drug fee limit for a charge's procedure code by date only -- no state, modifier, facility, insurance, or bill-type filtering despite those parameters being bound to the query -- then rescales by RuleMultipliers or Percentage/100.
Same ChargeLevelSqlCalculator driver as MedicareDME (loop i=1..NumCharges-1, skip IgnoreCharge). MedicareDrugSqlGenerator.GetQuery: SELECT TOP 1 MedicareDataASPDrug.FeeLimit (CAST MONEY) joined to MedicareScheduleASPDrug/MedicareSchedule (period end computed via LEAD(StartDateEffective) ascending, not partitioned by anything) WHERE @BaseDate BETWEEN [StartDate,EndDate) AND ProcedureCode = @ProcedureCode -- that is the entire WHERE clause. Then identical post-processing to MedicareDME: amount = fee * charge.Units; round to 2dp AwayFromZero; amount *= matched RuleMultipliers[x].Multiplier else *= DefaultMultiplier (Percentage/100, default 1.0); round again; detail.SetBase(amount, calc).
| Key | Meaning |
|---|---|
| BaseDate | Optional override date (inherited from MedicareCalculation) selecting the ASP schedule period; defaults to context.ServiceDate. |
| Percentage | Decimal, default 100 (inherited); DefaultMultiplier = Percentage/100 applied when no RuleMultipliers rule matches. |
| RuleMultipliers | List<IMultiplierRule> (IHasRuleMultipliers); matched rule's Multiplier overrides the Percentage-derived DefaultMultiplier. |
Gotchas
MedicareDrugCalculation has no StateCode property at all (confirmed: MedicareDrugCalculationField adds no children beyond MedicareCalculationField<T>'s BaseDate/Percentage/RuleMultipliers), so unlike MedicareDME/MedicareLab there is no state concept to even be null. More importantly, ChargeLevelSqlGenerator.GetSharedParameters unconditionally binds @Modifier, @FacilityKey, @InsuranceKey, @BillTypeKey, and @Units on every call -- but MedicareDrug's query text references none of them (@Units isn't used in SQL for any of the three Medicare* base types; the unit multiply happens in C# after the query). A reimplementer expecting a drug-waste modifier like JW to affect ASP pricing, or a facility-specific ASP variant, would be wrong: the fee is looked up purely by ProcedureCode + BaseDate. Same round-then-multiply-then-round chain as MedicareDME (missing from the original draft's formula).
class · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Calculations/Medicare/MedicareDrugCalculation.cs:6
calculator · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/PricingEngine/Calculations/Medicare/MedicareDrugSqlGenerator.cs:11
dispatch · /home/cary/src/mdc/MdClarity/MDClarity/MDClarityCore/Backend/CalculationEngine.cs:703
CORRECTED: draft correctly identified 'no state or modifier filtering' but did not note that @Modifier/@FacilityKey/@InsuranceKey/@BillTypeKey/@Units are all bound as query parameters yet completely unreferenced by the SQL text (dead parameters), and omitted the round(fee*units)-then-multiply-then-round-again sequence that governs final precision.