Skip to primary interaction
Healthcare

Denial Taxonomy + KPI Spine

One versioned reference layer that every RCM workflow shares

  • Replaces three-team-three-numbers reporting with one versioned spine
  • Surfaces denial-mix anomalies anchored to taxonomy nodes
  • Gives every downstream automation a stable training target
Try the mapperExplore the taxonomy

Primary interaction

Operating model

Map, standardize, detect, govern

The same spine that maps denial codes also stabilizes KPIs, anomaly review, and downstream automation.

MapStandardizeDetectGovern
Map a denial
385ms wall · undefinedms classifier
Mapping failed: Failed to fetch
Failed to load: Failed to fetch

Three teams compute the same KPI three ways. The spine gives them one.

Loading economics…
Under the hood

Capability proof

Capability proof

Shared denial intelligence spine

Service model

Live operating workflow for code mapping, KPI review, anomaly surfacing, and breach inference.

Intelligence layer

Maps denial signals into a common taxonomy and highlights deviations that need review.

Operational state

Maintains shared denial definitions, KPI observations, mapped codes, and anomaly context.

Human control

Analysts can inspect the mapping, review outliers, and keep the taxonomy governed.

Business value

Gives BI, operations, and automation teams one stable vocabulary instead of separate spreadsheet logic.

Why a shared spine compounds

Denial Taxonomy + KPI Spine — Live AI Demo

Most health systems run RCM on top of an unspoken taxonomy that lives in spreadsheets and analyst memory. KPIs get computed three different ways depending on which team owns the dashboard. Every downstream automation has to re-invent its own mapping. Externalizing the spine gives BI a versioned source of truth and gives agentic workflows a stable training target, so the value of each new automation compounds instead of starting from scratch.

Library overview

Failed to load library overview.

Architecture

Estimated monthly cost at portfolio traffic: under $1/month (Lambda free tier + minimal API Gateway requests)

LayerTechPurpose
Synthetic dataJSON · 30 CARCs · 25 RARCs · 12 taxonomy nodes · 8 KPIs · 768 obs · ~350 eventsReal WPC ANSI codes; pre-computed mappings, pre-computed anomalies, pre-computed inferences; one deterministic seed
ComputeAWS Lambda (nodejs20.x · 512MB)Single function, route-based dispatch across 9 endpoints (taxonomy, codes, mapper, KPIs, observations, inference, anomalies, events)
AI surfacesPre-computed classifier outputs + z-score anomaly detection + event-provenance inferenceMapper baked into the dataset (mirrors fine-tuned classifier in prod). Anomaly + breach engines run deterministic statistics with real reasoning traces.
APIAPI Gateway (HTTP API)Shared with the other healthcare demos on the same SAM stack
FrontendReact + CSS modules · EDGE design tokens · inline SVG sparklinesLibrary overview, code mapper, anomaly feed, breach inference, taxonomy explorer, KPI dashboard
DeployAWS SAM · us-east-2`sam build && sam deploy`; CloudFormation manages all resources

What this demo is, and isn't

What this demo is, and isn't

  • All payer names are realistic-generic but synthetic (not real entities). CARC, RARC, and HCPCS codes are real WPC ANSI X12 835 values, used so the rule and remit shapes are accurate. The data behind every code is fictional; no PHI, no real claims.
  • The code mapper is the headline AI surface, but its outputs are pre-computed in the synthetic dataset. A production deployment would call a fine-tuned text classifier or a managed service (Comprehend Medical, a custom Bedrock model, or a purpose-built distilbert) for live mapping. The per-field confidence shape, the alternative-mappings list, and the reasoning trace structure all model what that service would return.
  • Anomaly detection is real arithmetic, not narration. Each weekly KPI observation is scored against a rolling baseline with a floored standard deviation (to avoid runaway z-scores when noise is tiny relative to scale), z-clipped at ±5, and flagged when |z| > 1.8 AND the warning threshold is breached. Adjacent weeks for the same payer/KPI are clustered into a single alert. Production deployments would replace this with a time-series anomaly detector (AWS Lookout for Metrics, Datadog anomaly monitors, or a forecast-residual detector) over the same data shape.
  • Breach inference is also real arithmetic — for each warning- breaching observation, the engine pulls denial events from the same payer in a two-week window and counts which taxonomy node their CARC-mapped denials concentrate in. Confidence rises with supporting-event count. Production would supplement with learned event-impact weights so a single high-dollar denial weighs more than ten low-dollar ones.
  • The taxonomy here is illustrative, not authoritative. Real internal denial taxonomies vary by organization — some split coordination-of-benefits as a parent of eligibility; some treat contractual write-offs as multiple sub-nodes by contract type. The 12-node structure here is a reasonable starting point common in mid-size RCM teams, intentionally exposed as data rather than hardcoded so the demo can show what a versioned taxonomy looks like operationally.
  • The economics math assumes 3 FTE analysts on the measurement layer at $130K loaded. Real organizations rarely have this headcount in one place — the work happens diffusely across BI, finance, and operations. The portfolio value isn't consolidating those FTEs; it's creating a contract that every downstream automation can build against without re-inventing its own mapping and KPI rollup.
  • The KPI thresholds (target / warning / critical) are illustrative midpoints. Real targets vary by payer mix, service line, and contract terms. A production deployment would version thresholds per payer / per service line and surface threshold changes themselves in the audit log alongside taxonomy edits.