Behavioral health · selected for the firm's flagship product
Prior-authorization automation — LLM and RAG inside Health Cloud
Started as a personal project, pitched to leadership, and selected for integration into the company's flagship product.
- Period
- Personal project → productization
- Role
- Originator — problem framing, architecture, build
v1 → v2
rebuilt after the problem was reframed
0
model-generated values written into payer forms
Context
Prior authorization is the paperwork gate in front of treatment. A coordinator assembles clinical evidence into a packet, sends it to a payer, and waits. When it comes back denied, the work is redone and the patient waits longer.
I started building against this problem on my own time, then pitched it internally. It was selected for integration into the company's flagship product.
Problem — and the correction that mattered
Version one was aimed at drafting authorization letters. Generating good clinical prose is the part of this problem that an LLM makes look easy, so that is where I started.
A manager who actually knew the workflow corrected it: coordinators do not need better letters. They need to not get denied. Denials come from packets that are incomplete against the payer's criteria — a missing assessment, an unmet criterion, an evidence gap — not from prose that could have been more persuasive.
That reframing threw away the premise of v1. The tool was rebuilt as a completeness and denial-prevention engine: work out what this payer requires for this request, check the packet against it, and surface what is missing before anything is submitted.
What I built
Requirement resolution
Determine what the specific payer and request type actually require, rather than assuming a generic checklist.
Packet assembly with retrieval
A RAG pipeline pulls the relevant clinical evidence out of the record so criteria are matched against real documents.
Completeness check
The core of the product. Every mandatory item is evaluated as met, missing, or needing confirmation, with the evidence behind each verdict shown.
Conditional drafting
Free text is drafted only where free text is genuinely needed — the thing v1 treated as the whole product is now a small conditional step.
Attestation and channel-aware output
A clinician confirms before anything leaves the system, and the packet is produced in the form the destination channel accepts.
Constraints and trade-offs
Shadow before you build
A mandatory shadowing phase precedes the build. V1 existed because I designed for the workflow I imagined; the rule exists so that does not happen twice.
Deterministic form filling
No model output is written into a payer form field. Structured values come from deterministic mapping. The model drafts free text and proposes evidence matches — it does not populate identifiers, codes or dates.
Propose and confirm
Document attachment is proposed to a human and confirmed, never performed silently. Nothing auto-submits.
An adapter layer for reality
Most payers in this space have no usable API. An adapter layer means v1 works with manual submission where that is the only channel, instead of waiting for integrations that may never exist.
Outcome
Selected by leadership for productization into the company's flagship product.
The more useful outcome was the judgement: the version that got picked up is the one built after someone who knew the work told me the problem was wrong. Deterministic filling, propose-and-confirm and mandatory shadowing all came out of taking that correction seriously.
Stack
ApexSalesforce Health CloudRAG pipelineLLM orchestrationAgentforceMCP-based toolingDeterministic field mappingAdapter layer for manual submission
Want the parts I can't put on a public page?
Happy to walk through the data model, the trade-offs, and what I would do differently. Open to Salesforce roles, 30-day notice.