HIPAA-aware denial management

Data flow

1. Denial intake.A denial arrives as an 835 electronic remittance from the clearinghouse, a scanned EOB / paper denial letter, or a payer-portal export. The payload carries CARC/RARC codes, the payer's stated reason, and enough claim context to identify the original submission.
2. Ingest gateway. Receives the denial inside the customer-tenanted VPC, validates payload, stamps a correlation ID, writes an immutable audit record, and stores the raw denial encrypted at rest (AES-256, customer-managed KMS key).
3. PHI minimization. Strip the 18 Safe Harbor identifiers (§164.514(b)(2)) before the prompt: member names and IDs, geographic subdivisions smaller than state, dates more precise than year, phone, fax, email, SSN, MRN, account, plan number, device identifiers, URLs, IPs, biometric IDs, photos, and any other unique identifying number. The model sees the denial reason, the CARC/RARC codes, and the de-identified claim context — not the patient or subscriber identity.
4. Model serving (BAA gate). Calls go to a foundation model under a signed BAA — Gemini via Google Vertex AI (HIPAA-eligible under a Google Cloud BAA), Claude via AWS Bedrock, GPT-class via Azure OpenAI Service, or a self-hosted open model (Llama-3, Mistral) inside the VPC. The public Google AI Studio / Anthropic / OpenAI APIs without a BAA are not a permissible path. The demo on this site uses Google AI Studio because its inputs are synthetic; the only change to run in production is the SDK endpoint and a signed BAA.
5. Policy & rule engine.The three model steps (analyze → correct → appeal) propose a root cause, a corrected claim, and an appeal letter; a deterministic post-processor validates suggested CPT / ICD-10-CM / HCPCS against current catalogs, checks the CARC/RARC interpretation against the payer's published policy and the relevant LCD, and confirms the appeal respects the payer's filing deadline. Rule violations become flags shown to the human reviewer.
6. Human-in-the-loop review. Every AI-suggested correction and appeal is validated by a certified coder or denial specialist before anything is submitted — AI proposes, a human decides. The reviewer sees the supporting evidence from the denial text and chooses to accept, edit, or reject the suggestion. Rejected suggestions are logged back to the vendor for accuracy tuning.
7. Submit correction / appeal. The corrected claim posts back through the clearinghouse as a resubmission, or the appeal packet routes to the payer's appeals channel (portal upload, fax, or mail). The denial status updates and the case is tracked to resolution. Every read, write, decision, and outbound call is in the audit log.

The HIPAA controls that actually matter

BAA: the clauses that actually matter

“HIPAA-eligible” is a vendor checkbox. The BAA is where the eligibility is enforced. Four clauses I look for before signing:

• No training on PHI. The vendor cannot use customer prompts, completions, or any payload-derived data to train, fine-tune, or evaluate models — for this customer or any other.
• No retention after task completion. PHI is held only as long as needed to return the response, then deleted. Any cache (prompt cache, KV cache, batch buffer) is scoped to the request and purged.
• No commingling across tenants. Tenant data is logically isolated; no shared embeddings store, no shared evaluation set, no “learn from all customers” feature.
• No PHI in vendor logs. Whatever the vendor logs for debugging, abuse detection, or analytics excludes request/response bodies — or hashes them. PHI in a log line is still a breach.

If a vendor won't put these in writing, the tool is for synthetic or de-identified data only. That covers prototyping; it does not cover production.

Ongoing compliance

• Annual security risk assessment. Per §164.308(a)(1)(ii)(A), the SRA runs at minimum yearly — re-map data flows, re-check access controls, re-verify that every PHI hop still ends at a BAA-covered endpoint.
• Re-assess when a vendor turns on an AI feature. A denial or billing tool that adds an “AI assist” toggle six months after contract signing is a new data flow, even if the vendor calls it an “enhancement.” Trigger an out-of-cycle SRA and confirm the BAA still covers the new processing path.
• BAA refresh on vendor change. Sub-processor list changes, new AI capabilities, new data residency — any of these require revisiting the agreement, not waiting for the renewal date.
• Reject-flag feedback loop. Reviewer rejections and edits feed back to the vendor as accuracy signal — without sending the underlying PHI. The signal is “this correction was wrong in context Y,” not the denial letter.

From this public demo to a private BAA testbed

The site you're reading is a public demo on synthetic data. If a prospect signs a BAA and wants to evaluate against real denials, the live data does not go through denials.usesmpt.com. The codebase deploys a second time into a private environment with different config. The deltas:

The codebase is one deploy target; the surrounding infrastructure is what changes. Standing up the private testbed is a config swap and a DNS record, not a rewrite — typically a one-day setup after BAA execution.

Honest limitations of this prototype

• No live payer integration. Nothing is submitted anywhere. The corrected claim and appeal packet are generated for inspection, not transmission. A production build would post resubmissions through a clearinghouse and route appeals to each payer's channel.
• No live catalog / policy lookup. Suggested CPT and ICD-10 codes are not validated against current AMA/CMS catalogs here, and CARC/RARC interpretation isn't checked against live payer policy or LCD tables. That deterministic layer is the next step.
• Synthetic denials only. All sample EOB excerpts and claim contexts were written for this demo. No real payer correspondence and no PHI is, has been, or will be processed by this app.
• Three single-shot calls, no agent loop. Each step is one model call with the prior step's result as input. No retry beyond transient-error backoff, no critic pass, no tool use. Deliberate simplicity for v1.
• Outpatient scope. The samples model outpatient professional-claim denials. Facility, DME, and specialty-specific denial patterns each need their own evaluation.