Prior authorization is the single biggest administrative drag in specialty medical practices that bill workers' compensation or no-fault insurance. Before a provider can perform an injection, an EMG, an MRI, or a surgical procedure, someone has to write a formal request to the claims administrator justifying medical necessity — citing the treatment guidelines, summarizing the clinical exam findings, listing the failed conservative treatments, and requesting the specific procedure code. Get the justification wrong, omit a required element, or miss a guideline citation, and the request comes back denied, the patient's treatment stalls, and staff spend another round-trip rewriting it.
We built an AI system for a multi-location personal injury medical practice that generates these prior authorization requests (PARs) automatically from a provider's exam notes, cutting a task that took a biller 20-30 minutes per request down to a couple of minutes of review. Here's how it actually works, what made it hard, and where the guardrails had to go.
The problem with prior authorization at volume
A practice seeing a high volume of workers' comp and no-fault patients generates dozens of these requests a week, across a range of procedure types — injections, EMGs, imaging, and orthopedic surgery referrals — each governed by a different regulatory standard. In New York, for example, requests fall under the Workers' Compensation Board's Medical Treatment Guidelines (MTG) for enumerated procedures, or a separate non-MTG justification pathway for anything not explicitly covered, each with its own required documentation and even different dollar thresholds that change whether authorization is required at all.
The knowledge required to write a compliant request correctly — which guideline applies, which CPT code goes with which procedure, what clinical findings the reviewer needs to see, which provider is credentialed to request which procedure — lives partly in a biller's head and partly in a stack of reference sheets. New staff take months to get proficient, experienced staff still spend real time on formatting and citation lookup, and any inconsistency between requests submitted by different staff members becomes an audit and denial-rate problem.
What the system does
The workflow starts with the same exam note data a provider already documents in their EHR — physical exam findings, range-of-motion measurements, orthopedic special tests, imaging results, and treatment history. Instead of a biller manually translating that clinical narrative into a formal request letter, the system takes the structured exam data plus the requested procedure type, and generates a complete, formatted prior authorization letter: the clinical summary, the objective findings section, the guideline citation and compliance language, and the specific authorization request sentence — ready for a human to review and submit.
The mechanism is a well-scoped LLM call, not a general-purpose chatbot. The system prompt is deliberately narrow: it only drafts the medical necessity section of a specific procedure's PAR, using a fixed letter structure, plain text, no markdown. The procedure type selected up front is treated as the single source of truth — the system is instructed to generate that procedure's PAR using only findings relevant to that body part or procedure, and to ignore inconsistent or wrong data elsewhere in the input rather than getting confused or refusing to proceed. That single design choice — pick one authoritative field and build every downstream rule off it — is what keeps output consistent across dozens of requests a day instead of behaving differently depending on how a staff member phrased the intake.
Where the real engineering work is
As with any AI system doing regulated work, the interesting problems aren't the API call — they're the business rules encoded around it.
Procedure-specific routing. Different procedures need entirely different letterhead, different supervising providers, and different clinical language. A knee surgery PAR needs a different signature block and different diagnostic focus than a spinal injection PAR. Getting this right meant building explicit routing logic per procedure type rather than one generic template — the system checks procedure type first and applies a completely different rule set for surgical versus non-surgical requests, down to which facility name is allowed to appear on which letter.
Provider-to-procedure mapping. Certain procedures can only be requested under specific credentialed providers by regulation or by internal policy — a physician assistant's exam findings still need to route to a supervising MD's name on certain request types. The system enforces this mapping unconditionally: if the intake data names the wrong provider for a given procedure, the system substitutes the correct one rather than reproducing the mismatch in the final letter. That's a rule you only discover by watching real denials come back, not one you'd think to add in a first draft.
Guideline classification and dollar thresholds. Not every procedure sits under the same regulatory pathway. Some are enumerated under the treatment guidelines with a defined authorization process; others fall under a separate track where authorization is only required above a specific dollar threshold. The system has to classify which pathway applies and generate the correct compliance language for that pathway — including citing the specific regulatory section — rather than using one generic justification paragraph for everything.
Handling missing data honestly. Real exam notes are incomplete. A rule we learned the hard way: when a required data point is missing — say, the number of completed physical therapy sessions on a surgical request, which reviewers weight heavily — the system should never invent a plausible-sounding number to fill the gap. It flags the field as missing so staff can pull it before submission. A generated document that reads confidently but contains a fabricated clinical detail is worse than one that visibly says "needs input," because the first one gets submitted without anyone noticing.
Omitting rather than guessing on optional fields. Some sections of a request are only required when the underlying data exists — a mechanism-of-injury narrative, for instance. The system is instructed to omit a section cleanly when the input doesn't support it, rather than printing a placeholder or guessing. A visible gap in a reviewer-facing document is an invitation to deny the request; the fix was making the system comfortable saying less rather than inventing more.
The result
Every prior authorization request the practice generates now follows the same structure, cites the correct guideline pathway automatically, and routes to the correct provider and letterhead without a biller having to remember which rule applies to which procedure. The system doesn't submit anything on its own — every request still gets reviewed by staff before it goes to the claims administrator — but the 20-30 minutes of drafting and formatting work per request is now a couple of minutes of review against the source exam note. At the volume a multi-location practice processes, that's hours of staff time recovered every week, and — just as important — a level of consistency across requests that a team of different billers, each with their own habits, couldn't produce manually.
The output also feeds the practice's broader intake and document infrastructure: the same structured case data that drives the PAR generation is what populates the practice's encrypted document archive, so information captured once at intake gets reused across every downstream document instead of being re-typed for each one.
What this pattern generalizes to
Prior authorization is a specific case of a general shape of problem: a regulated, high-stakes document that has to be assembled correctly from clinical or business data, following rules that vary by category, with real consequences for getting a detail wrong. The same architecture — treat one input field as authoritative, build explicit per-category routing instead of one generic template, flag missing required data instead of guessing, and keep a human review step before anything leaves the building — applies just as well to insurance claims documentation, loan underwriting memos, compliance filings, or any other regulated document a professional services firm generates at volume.
If your practice or firm is still drafting these documents by hand, from scratch, every time — and living with the denial-rate and staff-training cost that comes with it — that's usually the highest-leverage automation project available. The Digital Guys can assess whether your document workflow is a fit — we've built these systems for medical, legal, and home services businesses working under real regulatory constraints, and the design patterns transfer directly.