#NLP #LLM #ML #AWS #Healthcare IT

AI Engineering · Healthcare

Claim denial management & revenue cycle automation for a regional health network

Pre-payment in days, not weeks · denial risk scored before submission

An EDI 837 claims pipeline built on AWS — rules + RAG scrubber, XGBoost + LLM denial risk model, and ISO 20022 pre-payment — so the health network receives cash before the insurer even processes the claim.

Challenge

EDI claims take weeks to months to settle. Manual review overwhelmed the revenue cycle team, denial rates were climbing, and cash flow was hostage to insurer turnaround times that the health network had no control over.

Approach

Built a four-stage pipeline: EDI 837 ingestion via Stedi, automated rules + RAG scrubber to catch denial risk before submission, XGBoost + LLM denial risk scoring, and ISO 20022 pre-payment calculation that decouples cash flow from insurer settlement timelines.

Outcome

The health network now receives pre-payment days after claim submission rather than waiting for insurer settlement. Denial risk is scored at the point of submission, not discovered at rejection. The revenue cycle team reviews exceptions rather than processing every claim.

4
Pipeline stages from EDI ingest to pre-payment — fully automated
2
Claim types covered: 837I institutional and 837P professional
−days
Days removed from the cash-flow cycle vs. waiting for insurer settlement
0
Manual handoffs in the standard path — exceptions routed automatically to review queue

Revenue cycle stuck between submission and settlement.

The health network was processing thousands of claims monthly across institutional (837I) and professional (837P) billing. The bottleneck wasn't generation — it was what happened after. Claims entered the insurer's adjudication queue and the health network waited. Typical settlement cycles ran 30 to 90 days, with denied claims requiring rework before resubmission added another cycle on top. The revenue cycle team spent the majority of their time on manual review: checking scrubbing errors, reconciling denied claims, and chasing down payer responses that arrived weeks after submission.

A secondary problem was visibility. Denial risk was only discovered at rejection — by which point the claim had already been submitted, the adjudication clock was running, and a rework cycle was guaranteed. There was no mechanism to score a claim's likelihood of denial before it left the system. Both problems — slow settlement and reactive denial management — were rooted in the same architecture: a passive pipeline that submitted claims and waited, with no intelligence between submission and outcome.

Three problems compounding each other.

01 — EDI
Slow, opaque settlement

Insurer settlement cycles ran 30–90 days. The health network had no visibility into adjudication status mid-cycle and no mechanism to accelerate cash flow outside of waiting.

02 — Denials
Reactive, not preventive

Denial risk was only surfaced at rejection. By then, a full adjudication cycle had been consumed. The scrubbing in place caught syntax errors but not payer-specific denial patterns — the most expensive category.

03 — Manual
Review bottleneck

Every claim touched a human reviewer at some point. There was no triage logic — low-risk, high-volume claims consumed the same attention as genuinely complex ones. The team's capacity was the throughput ceiling.

A four-stage pipeline on AWS — from EDI ingest to pre-payment.

Rather than patching the existing scrubbing layer, Adimen designed the pipeline from the ground up — with pre-payment as the architectural goal, not an afterthought.

EDI 837 ingestion

Claims arrive as HIPAA X12 837I and 837P transactions via Stedi's real-time EDI API. A custom parser built on EDIFabric handles the full transaction set — claim headers, service lines, diagnosis codes, NPI validation — and normalises the output into a canonical JSON structure consumed downstream. Malformed transactions are quarantined and flagged for review without blocking the pipeline.

Automated scrubber — rules + RAG

Each parsed claim runs through a two-layer scrubber. The first layer applies rules-based checks against HIPAA X12 edit sets and payer-specific billing requirements. The second uses a RAG pipeline against a vector store of historical denial reasons — retrieving similar past claims and their outcomes to surface payer-specific denial patterns that rules alone cannot catch. Claims flagged at this stage are corrected or routed before submission.

Denial risk prediction

Scrubbed claims are scored by an XGBoost model trained on 18 months of historical adjudication data, enriched by an LLM layer that extracts features from free-text fields — clinical notes, remarks codes, authorisation text. The model outputs a denial probability score and the top contributing factors (via SHAP), giving reviewers an actionable signal rather than just a flag. High-risk claims are held for review; low-risk claims proceed automatically.

Payment calculation & pre-payment

Low-risk claims trigger an ISO 20022-compliant pre-payment calculation using contracted fee schedules and adjudication history to estimate the expected reimbursement. The calculated amount is transmitted to the health network's treasury system for same-day funding. When the actual insurer settlement arrives, the delta is reconciled automatically. The result: cash flow decoupled from insurer turnaround timelines.

From EDI 837 to bank — one continuous, observable pipeline.

AWS · EC2 · S3 · SQS · SNS · RDS · CloudWatch · NATS · Kubernetes retrieve 01 · Ingest EDI 837 837I / 837P via Stedi EDIFabric parse normalised JSON 02 · Scrub Rules + RAG HIPAA X12 edits Payer-specific denial patterns clean claim 03 · Score XGBoost + LLM Denial probability SHAP factors Route decision risk score 04 · Submit 270/271 · 835 Eligibility check Claim submission ERA receipt payer 05 · Pay ISO 20022 Pre-payment calc Treasury transfer Delta reconcile cash received Vector Store Denial history Qdrant · 18 mo. data Observability ClickHouse analytics CloudWatch metrics NATS messaging FastAPI + gRPC

Cash flow decoupled from insurer turnaround.

4
Pipeline stages — ingest, scrub, score, pay — fully automated end-to-end.
2
Claim types covered: 837I and 837P, handling both institutional and professional billing.
−days
Days removed from the cash-flow cycle — pre-payment arrives before insurer settlement.
0
Manual handoffs in the standard path. Reviewers handle exceptions only — not the volume.

Tech stack

EDIFabric Stedi ISO 20022 HIPAA X12 LangGraph Qdrant XGBoost scikit-learn SHAP ClickHouse PostgreSQL Python FastAPI gRPC NATS AWS EC2 AWS S3 AWS SQS Docker Kubernetes GitHub Actions

Stuck on revenue cycle bottlenecks?
Let's scope it together.

Get in touch →
← Back to Case studies