Payer / Client Playbooks — Live AI Demo

Skip to primary interaction
Healthcare

Payer / Client Playbooks

RCM workflow that extracts rules from payer documents, scores each for confidence, routes claims to the right rule, and governs the library with version history and audit.

  • Converts policy excerpts, denials, and notes into candidate rules
  • Promotes reviewed rules into reusable routing logic
  • Keeps every rule tied to source evidence, version history, and audit
Extract candidate rulesSimulate claim routing

Primary interaction

Operating model

Source artifacts become governed rules

The demo is not just extraction. It shows how payer-specific knowledge moves from messy source material into reviewed, reusable routing logic.

01

Source

Source artifacts enter the extractor.

02

Candidate

Candidate rules are scored.

03

Review

Risky rules stay in review.

04

Route

Promoted rules route claims.

05

Govern

Evidence and history stay attached.

Failed to load source documents: Failed to fetch
Claim
767ms wall · undefinedms matcher
Simulation failed: Failed to fetch

Governed payer rules turn specialist interpretation into reusable routing logic.

Loading economics…
Under the hood

Capability proof

Capability proof

Governed rule operating model

Service model

Live rule-management workflow for extraction, routing, versions, audit, and similar-rule lookup.

Intelligence layer

Converts payer artifacts into candidate rules and applies approved rules to claims.

Operational state

Maintains payer playbooks, rule versions, source evidence, and audit history.

Human control

Candidate rules move through review before becoming reusable routing logic.

Business value

Turns specialist knowledge into governed operating rules that scale beyond one person.

Why externalizing rules compounds

Payer variability is the hidden tax on downstream RCM automation. Status, eligibility, prior authorization, and appeal workflows can only scale as far as the rule library behind them. This demo shows how specialist judgment becomes governed rules, with source evidence and review history preserved.

Library overview

Failed to load library overview.

Architecture

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

Architecture layers, technology, and purpose
LayerTechPurpose
Synthetic dataJSON · 15 payers · 122 rules · 25 sources · deterministic seedRealistic payer mix, CPT/CARC shape, source-doc variety, pre-computed extraction outputs
ComputeAWS Lambda (nodejs20.x · 512MB)Single function, route-based dispatch across 9 endpoints (library, playbooks, sources, extractor, simulator, similar, versions, audit)
AI surfacesPre-computed extraction + feature-weighted matchingExtractor outputs baked into the dataset (mirrors production document-AI); routing simulator scores live with a transparent, traceable model
APIAPI Gateway (HTTP API)Shared with the AI Transformation Platform demo on the same SAM stack
FrontendReact + CSS modules · EDGE design tokensLibrary overview, extractor, simulator, payer directory, rule browser, version-history and similar-rules drawers, audit log
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). Rules, conditions, and actions are generated from a deterministic seed. CPT, HCPCS, and CARC codes use real WPC ANSI values so the rule shape is accurate; the data behind them is fictional.
  • The extractor is the headline AI surface, but its outputs are pre-computed in the synthetic dataset. A production deployment would call a document-AI service (Hyperscience, Instabase, AWS Textract with a thin extraction layer, or a purpose-trained model) on each source. The confidence-scored output shape, reasoning trace, and promotion routing model what that service would return.
  • The routing simulator is live — every call scores the input claim against every active rule with a transparent feature-weighted model. The reasoning trace is real arithmetic, not narration. The weights (payer 0.45, CPT 0.30, POS 0.10, modifier 0.05, etc.) would be learned from historical routing decisions in production; here they're hand-set for demonstration.
  • Similar-rules across payers uses pre-computed semantic neighbors based on category match + CPT overlap + condition feature overlap. A production deployment would use an embedding store (pgvector, Pinecone, OpenSearch k-NN) over rule text and structured features. The UI shape and consolidation use case are accurate; the matching is a simpler stand-in for embeddings.
  • The economics math assumes 3 FTEs per major payer for policy interpretation at $150K loaded. This is the upper end of an honest range — many organizations underinvest in this function and the work happens diffusely (PDFs, specialist memory, email threads). The compounding value isn't the per-payer FTE savings, it's the substrate this creates for status automation, eligibility, and prior-auth to scale.
  • Version history and the audit log are deterministic on purpose. Governance surfaces should be plain tables, not magic. Anything that can't be inspected after the fact has no business shipping in a regulated workflow.