Inspiration Prior authorization is one of healthcare's most stubborn bottlenecks as personally experienced by Rahil while working as a Surgical Assistant for a brand new dermatology office. For Mohs micrographic surgery, the gold-standard treatment for high-risk skin cancers, a patient with a confirmed basal cell carcinoma can wait days or weeks not because their case is ambiguous, but because the paperwork machine moves slowly. Physicians/Clinical Assistants spend hours on hold with payer portals, writing letters that cite the same NCCN guidelines every single time, and patients sit in limbo wondering if their cancer is being treated or just processed.
We built DermAuth because the clinical decision is usually obvious. The authorization shouldn't take longer than the diagnosis.
What We Built DermAuth is an AI-native prior authorization engine purpose-built for dermatology. A physician uploads a clinical note and insurance card, or loads a demo patient,and within seconds the system extracts structured data, cross-references the patient's payer against a live rules engine covering BCBS, Aetna, UHC, Cigna, and Medicare, generates a formal PA letter, and returns an authorization decision.
When a payer denies, DermAuth doesn't stop. It generates a peer-to-peer appeal letter grounded in NCCN Clinical Practice Guidelines and the AAD's position statement — the same arguments a fellowship-trained Mohs surgeon would make, written in under a second.
The Full Journey demo shows the complete arc: denial, AI-drafted appeal, re-review, approval, handoff to the mock EMR (ClarityEMR), surgery scheduling, and the patient notification SMS thread,from clinical note to confirmed OR slot, end to end.
How We Built It Backend: Node.js + Express, proxying calls to Anthropic's Claude API for document extraction, PA letter generation, and appeal drafting Frontend: Vanilla HTML/CSS/JS — a 3-panel SPA with a document upload zone, animated results engine, and a payer rules panel Mock EMR: A fully interactive ClarityEMR prototype with patient records, an authorization tab, an interactive surgery calendar, and a phone mockup showing the patient's SMS notification thread
Payer Rules Engine: A hand-curated database of coverage criteria, turnaround times, and portal routing for five major payers Demo scenarios: Three distinct patient journeys (Quick Approval, Denial + Appeal, Full Journey) with real clinical data for Patricia Okafor and James Thornton
Challenges Getting Claude to return structured JSON reliably was the first real hurdle. Medical prompts with nested data requirements would occasionally return markdown-wrapped JSON or partial objects. We solved this with strict prompt engineering, a raw-text cleaning step, and graceful fallback to hardcoded demo data so the demo never breaks mid-presentation.
Designing the payer rules engine required balancing accuracy with demo clarity. Real PA criteria are dense policy documents, we distilled BCBS, Aetna, UHC, Cigna, and Medicare into a structured database that's both clinically grounded and visually scannable.
The Full Journey flow required orchestrating multiple async state transitions — denial → appeal submission → animated re-review → approval → EMR handoff — without a backend state machine. We built it entirely in the frontend with sequenced async functions and shared state.
What We Learned PA denial rates for medically necessary procedures aren't primarily a clinical problem — they're a documentation and timing problem. The right letter, with the right citations, submitted through the right portal at the right time, gets approved. DermAuth makes that process deterministic instead of heroic
Expand beyond Mohs — to all of dermatology PA BCC is the proof of concept. The same engine applies to biologics (dupilumab for eczema, secukinumab for psoriasis), MOHS for SCC, PDT, and laser procedures — all of which have high PA denial rates. Each payer policy becomes a rules module.
Real EMR integration Replace the ClarityEMR mockup with actual FHIR API connections to Epic, Athena, and Modernizing Medicine (the dominant derm-specific EHR). Patient data flows in automatically — no upload required.
Live payer portal submission Right now DermAuth generates the letter. The next step is submitting it — directly to Availity, CoverMyMeds, or payer portals via API, with status tracking built in.
Denial pattern analytics Every denial carries a reason code. Aggregate those across a practice and you surface patterns: which payers deny most, which documentation gaps recur, which physicians have the highest appeal success rates. That's a practice operations dashboard.
Appeal outcome learning Feed approved appeal letters back into the model. Over time, DermAuth learns which arguments, which citation formats, and which clinical framings win with which payers — making each subsequent appeal sharper.
Patient-facing status portal The SMS thread in the demo is a glimpse of this — a real patient portal where they can see exactly where their authorization stands, without calling the office.
Specialty expansion The architecture is specialty-agnostic. Orthopedics (joint injections, surgery), oncology, ophthalmology, and neurology all have brutal PA burdens. DermAuth becomes the template; the payer rules engine and specialty-specific prompt tuning is the moat.
The core insight that scales: the clinical logic is always the same. Only the paperwork changes. DermAuth owns the paperwork layer.
Built With
- claude
- riplet

Log in or sign up for Devpost to join the conversation.