Praxigen: the AI-native operating layer for prior authorization

Prior authorization is the most hated workflow in American healthcare. Physicians and their staff burn 12+ hours per provider every week chasing insurer approvals: looking up each payer's rules, formatting clinical notes to match hidden criteria, tracking cases across portals, and appealing denials by fax. It's a multi-billion-dollar administrative drag, and it's getting worse. Payers now use algorithms to auto-deny at scale, and the provider side has no equivalent firepower. Praxigen is building it.

What inspired this

I have a clinical background as a former pre-med and saw this workflow up close; these kinds of gaps are why I decided to switch from the medical track to HealthTech innovation. The thing that stuck with me wasn't the paperwork, it was watching patients wait months for care that had already been deemed necessary, stuck behind an approval process designed to create friction. One specialty practice I spoke with described a denial rate as high as 75%, with staff manually rewriting notes and chasing adjusters who had gone silent. The denials usually weren't about whether the procedure was warranted. They were about whether the documentation used the exact language a given payer wanted to see. That gap, between medically necessary and correctly worded, is the whole problem. And it's solvable.

What it does

Praxigen is one connected workspace that runs the entire prior-auth loop:

  • PA Lookup: instant payer requirements across 13 major payers by procedure or CPT code, with AI that understands what staff actually mean (search "spine fusion," not the exact billing name).
  • Note Checker: scores a clinical note against that payer's real criteria before submission and rewrites the gaps, including the conservative-care and continuation-of-care arguments that trigger the most denials.
  • Case Tracker: every active authorization in one queue with AI-generated next steps, so nothing slips past a deadline.
  • Appeal Letters & Peer-to-Peer Prep: formal appeals in seconds, plus talking points built from the original note and the denial reason.

The defensibility is a closed-loop denial engine: every case teaches Praxigen which language wins approvals, per payer and per procedure, over time. The more a practice uses it, the harder it gets for payers to say no. That compounding advantage is something no incumbent retrofitting AI onto legacy software can easily copy.

How I built it

The product is live at praxigen.dev, built AI-native from the first line. The front end is Next.js on Vercel; data and auth run on Supabase with row-level security; every intelligent action routes through the Anthropic Claude API. The payer requirements database was populated by scraping public payer documentation and using Claude to extract structured requirements from long, messy PDFs into clean queryable fields. The search layer combines deterministic token matching with a Claude semantic fallback so staff can find what they need in plain language. The whole thing is multi-tenant and role-based, so a single practice or a multi-site hospital system can run on it.

What I learned

The hardest lessons came from talking to the people who actually do this work, not from building. Most prior auths don't route directly through the insurer; they go through utilization-management middlemen like eviCore and Carelon, which I hadn't accounted for in the original data model. The real daily pain is concentrated in workers' comp and no-fault cases, where staff track down adjusters, patients, and clinical notes across separate systems at once. And sub-plan granularity matters more than I expected: a single payer can have EPO, PPO, federal, and state plans with different requirements. Every one of those findings reshaped the product.

Challenges I faced

The biggest challenge is that the underlying data is fragmented, undocumented, and constantly changing. Payer rules live in hundreds of PDFs that get revised without notice, so keeping the database current is an ongoing engineering problem, not a one-time scrape. The second challenge is compliance: anything touching real patient data requires HIPAA infrastructure (BAAs across every vendor, audit logging, access controls), so the product runs on sample data for demos and the compliance layer is being built before any real patient information enters the system. The third is staying narrow. The temptation is to build the operating layer for all of healthcare admin immediately. The discipline is making one workflow, prior auth, genuinely reliable first.

What's next

The wedge is prior auth. The vision is the operational layer for all of healthcare admin. Praxigen is currently in the UStart League accelerator, running validation conversations with specialty practices, and building toward a founding pilot cohort.

Built With

Share this project:

Updates

Submission history