Doctor's Orders

Insurance denials suck. Doctor's Orders generates a doctor-ready preauth justification—and turns a denial plus what you've tried into a winning appeal.

Comment

Inspiration

Insurance preauthorizations are hard for regular people — and the system quietly counts on that.

Doctors don't want to do them. They take time, so they get handed to assistants who aren't experts, or they don't get done at all. The patient ends up referred for a less effective procedure, or handed a prescription that's cheaper instead of better. And if the request gets denied, the appeal is even harder: patients don't have the expertise to write one, they're stuck in back-and-forth with a doctor who doesn't want to do it either, and the implied next step is hire a lawyer. So most people give up. The denial wins by default.

I know because it happened to me. I had dry eye. Every source said drops with preservatives would irritate my eyes, so I asked my doctor for preservative-free. I got the preserved ones anyway. They burned, so I stopped using them. Then the denial showed up — no justification on file, and (reading between the lines) I hadn't yet tried and failed the cheaper preserved drops the plan wanted first. The cruel part: by the time the denial came, I had tried them. They burned, months passed, and my eyes were still dry. I didn't appeal. Too much of a pain.

That denial is the whole reason this exists. The insurer's own mandated step is exactly what proved I needed the alternative. The evidence to win was sitting in my own experience — I just had no tool to turn it into a letter.

What it does

Doctor's Orders works in two strokes:

  1. Justification. From the patient's situation, an LLM generates a standard-of-care-grounded preauthorization justification letter that the patient hands to their doctor to submit to the plan.
  2. Appeal. If the plan denies anyway, the patient enters what they were forced to try and how it failed. The model takes that lived evidence plus the denial's stated reasons and writes a point-by-point appeal that rebuts each reason and establishes medical necessity.

The strongest move it makes is documenting that the plan-mandated alternative was trialed and failed — satisfying the insurer's own step-therapy requirement and turning their protocol into the argument for the original treatment.

How we built it

  • Spec-first. I drove the build with a requirements → strategy → architecture cascade (Cascadia), so the design was nailed down before code. Total LLM spend on the entire spec build was about \$2.
  • Pipeline. File-based stages: a validated case object in, an LLM pipeline that generates the justification and (when a denial is present) the appeal with a rebuttal map, a validated document artifact out.
  • Surface. A clean, document-forward linear stepper — request → submitted → denied → interim treatment & harm → generate → outcome — where the letter is the hero, not a flashy dashboard.
  • Model. LLM-driven generation via the xAI (Grok) endpoint with a Claude fallback; deployed on Vercel.

Challenges we ran into

  • Knowing when to stop. Scoping a v2 with real bugs still in it, and shipping anyway, took more discipline than fixing everything would have.

Accomplishments that we're proud of

  • A working end-to-end product — justification and appeal — built and deployed inside the hackathon window.
  • A v2 that adds the load-bearing feature: capturing the failed-step evidence that turns a routine denial into a winnable appeal.

What we learned

  • Move fast and cap iterations. I held myself to two passes and stopped at a satisfactory v2 instead of polishing forever. A few bugs remain, and that's fine for now — shipping beat perfecting.
  • Spec-first pays for itself. Nailing the requirements before writing code made the build fast and the scope honest.

What's next for Doctor's Orders

  • Fix the known bugs from the v2 sprint.
  • Appeal-denial-of-appeal. Add the follow-up stage: when an appeal is itself denied, generate the next-level appeal — capturing the new denial's reasons and escalating the case. ** Messaging / EHR integration ** integration into tools like Epic Mychart messaging. ** HIPAA compliance ** Add security, encryption, data protection, etc.
  • ** Integration with Docrates.ai ** Add this application as a new "feature" to my already production HIPAA compliant Docrates.ai patient advocate application.

Built With

Share this project:

Updates