To “score” an account is to estimate what the payer will allow on its charges. This is a field-by-field reading of what the engine writes — and how every row joins back to the rest of the system.
There is no risk score or propensity-to-pay model here. Scoring = pricing. But the engine’s inputs aren’t one undifferentiated pile — they fall into three classes with three different lifecycles, entering from three directions. Activity flows through it; contract rules are the business logic dropped in from above; reference & fee schedules are lookup data it dips into from below.
PricingRecord each step cites⟳ per-contract loadCustomer.MedicareDatabase)⟳ CMS quarterly / annualEvery output row carries the same composite key. Toggle a key below to light it up across all three tiers and see exactly what threads through. These keys are also how outputs join back to source data — the account, its charges, and the chosen contract.
AccountID → the Account being priced. One actual estimate per account.ChargeNumber → the account’s individual charge line (CPT/HCPCS, units, amount charged).ScenarioInsurance → NULL = the live, actual estimate. Non-null = a what-if priced against a different insurance/contract.FeeLogic → the fee-logic rule set that was applied (which methodologies, in what order).PricingRecord → the specific fee-schedule record a calculation pulled its rate from.CalculationError → enum explaining a failed score (see §05).One row per (account, scenario). This is the answer consumers read first: did we price it, and for how much. Keyed AccountID + ScenarioInsurance.
| Field | Type | What it means & where it joins |
|---|---|---|
| AccountID | string | Joins to the Account. The thing being scored. |
| ScenarioInsurance | string | NULL = actual estimate. Non-null keys a what-if scenario against another insurance/contract. |
| Calculated | bool | Did pricing succeed? If false, read CalculationError for why. |
| AmountAllowed moneyheadline | decimal? | The estimate. Total allowed across all charges — the roll-up of every Tier-2 AmountAllowed. |
| FeeLogic | string | Which fee-logic rule set was applied (the recipe of methodologies). |
| CalculatedDate | DateTime? | When this score was produced (freshness / staleness signal). |
| CalculationError | enum? | Reason code when Calculated = false. See §05. |
One row per charge line. Splits the account total into per-charge allowed amounts, and exposes the value before vs. after adjustments. Keyed AccountID + ChargeNumber + ScenarioInsurance.
| Field | Type | What it means & where it joins |
|---|---|---|
| AccountID | string | Back to the parent AccountEstimate / Account. |
| ChargeNumber | int | Which charge line on the account this prices. |
| ScenarioInsurance | string | Same scenario discriminator as Tier 1. |
| Calculated | bool | Did this charge price out? Some charges can fail while others succeed. |
| AmountAllowedBase money | decimal? | Allowed before adjustments — the sum of base calculations for this charge. |
| AmountAllowed money | decimal? | Final per-charge allowed, after adjustments. These sum to the account total. |
Many rows per charge — the audit trail. Each row is one pricing step: a base calculation or an adjustment, with the dollars it contributed and the fee-schedule record it came from. This is what lets you reconstruct any AmountAllowed from scratch.
| Field | Type | What it means & where it joins |
|---|---|---|
| AccountID | string | Back to account. |
| ChargeNumber | int | Back to the Tier-2 charge these steps explain. |
| ScenarioInsurance | string | Scenario discriminator. |
| CalculationType | string | The methodology applied (e.g. MedicareRVU, CaseRate, PercentOfFees). Taxonomy in §04. |
| CalculationName | string | Human-readable label for this step. |
| IsAdjustment | bool | false = base calculation; true = adjustment layered on top. The split between Base and Final. |
| Amount money | decimal? | Dollars this step contributed — negative for downward adjustments. |
| Description | string | Free-text explanation of the step’s logic. |
| PricingRecord | string | Pointer to the fee-schedule record the rate was read from. |
In code these three arrive bundled as AccountEstimateData — { Estimate, Charges[], Calculations[] } plus an ErrorDescription — with a helper GetCalculationsByChargeNumber() to pull one charge’s breakdown.
Read this bottom-up: Tier-3 steps sum into a charge’s base, adjustments bend it to a final, and charge finals sum into the account total. (Illustrative figures.)
| Tier 3 — calculation step | Charge | Amount |
|---|---|---|
| MedicareRVUbase | #1 | + 412.00 |
| MedicareSequestrationAdjustmentadj | #1 | − 8.24 |
| ↳ Charge #1 base 412.00 → final | #1 | 403.76 |
| PercentOfChargesbase | #2 | + 1,250.00 |
| MultipleProcedureAdjustmentadj | #2 | − 625.00 |
| ↳ Charge #2 base 1,250.00 → final | #2 | 625.00 |
| AccountEstimate.AmountAllowed = Σ charge finals | — | 1,028.76 |
AmountAllowedBase. Base ± adjustments gives Tier-2 AmountAllowed. Those finals sum to Tier-1 AmountAllowed. Each italic line is a row you’d actually find in AccountEstimateCalculation.
Two enums give the outputs their meaning: why a score failed, and how a charge was priced.
Other Unclassified failure.MissingContractMap No contract mapping for the insurance.MissingScheduleMap No fee-schedule mapping found.NoBaseCalculations Nothing to price from — no base step ran.InvalidChargeCodes Charge codes weren’t recognized.SqlCalculationSyntaxError A SQL-based rule failed to parse.Gold = Medicare family · teal = adjustments · plain = base methodologies. ~45 values total.
Outputs aren’t static. AccountLoader compares incoming vs. current account data; if a pricing-relevant field changed, it enqueues the account via AccountScoringQueue, which deletes the prior actual rows (ScenarioInsurance IS NULL) and recomputes. Scenario rows are managed separately for contract modeling.
Any one of these changing ⇒ the account is re-scored and its three output tiers are rebuilt.