Prior Authorisation With AI: Drafting Letters and Tracking Status

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Prior Authorisation With AI: Drafting Letters and Tracking Status.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Prior Authorisation With AI: Drafting Letters and Tracking Status.

A small practice can use AI to turn a clinician's redacted notes into a prior authorisation letter that follows the payer's own criteria, and to keep a tracker of every request's status. The clinician decides medical necessity and signs every letter, and patient identifiers stay out of any tool without approved safeguards.

Searching for this topic mostly returns vendors of prior authorisation platforms. Those products can be worth it at volume, but a practice with a few dozen requests a month often needs something simpler: a good letter, sent with the right attachments, then followed up on time. Both halves are about discipline more than software. A well-written letter still comes back if a required document is missing, and a request stalls when nobody is assigned to look at it on day three. A small team can run both halves with a template, a spreadsheet and an AI assistant used carefully.

Follow me on Instagram@sagnikteaches

What the AI does, and what it must never do

Split the job into steps and decide who owns each. The AI is a drafting and organising assistant. It can restructure a clinician's rough note into the order a reviewer looks for, match your note against a checklist of the payer's published criteria, and tell you what is missing. It cannot decide that a treatment is medically necessary, supply a clinical fact that is not in the note, or know a payer's current policy from memory.

Connect on LinkedInSagnik Bhattacharya
StepOwnerAI role
Decide the request is clinically justifiedClinicianNone
Find the payer's current criteria for this serviceStaff member, from the payer's own pageNone, or summarise text you paste
Redact the clinical noteStaff memberNone; do not paste the unredacted note
Draft the letter from the redacted note and criteriaStaff memberDrafts; flags gaps
Check facts, add identifiers, attach recordsStaff memberNone
Review and signClinicianNone
Submit and logStaff memberNone
Chase and record outcomesStaff memberDrafts chase messages

Notice how small the AI's column is. That is deliberate, and it is where the time saving comes from: the drafting step is where a practice can lose twenty minutes or more per request, and the status chasing is where requests are lost.

Subscribe on YouTube@sagnikteaches

Redaction first, or nothing leaves the practice

Patient records are the most sensitive data a practice holds, and the privacy rules that apply to them are strict. Before any text goes into an AI tool, decide which of three routes you are using. Route one: a redacted note, with name, date of birth, address, phone, member ID, provider names and any other identifier replaced by tags. Route two: an AI vendor and plan that your compliance adviser has approved, with a signed business associate agreement (BAA) or whatever written agreement your privacy rules require, used inside your own policy. Route three: no AI at all for that request. Do not paste real patient details into a consumer chat account, whatever the privacy toggles say.

Route two is narrower than it sounds, because these agreements are tied to particular plans. As of November 2026, OpenAI's help pages say it signs a BAA for its API and for sales-managed ChatGPT Enterprise and Edu accounts, but not for ChatGPT Business. ChatGPT for Clinicians, a free version for verified individual clinicians that lists prior authorisation letters among its drafting uses, has its own in-product BAA flow; it is built for one clinician's own use, and OpenAI points practices that need one agreement covering several users to ChatGPT for Healthcare. Anthropic signs a BAA for its API and for Claude Enterprise organisations once the owner switches on the health-data configuration in the organisation settings. Neither company lists its personal consumer plans as covered, and even under an agreement some features sit outside it, so read the vendor's list of covered features with your adviser before anyone relies on route two.

A practical redaction routine for route one takes about two minutes. Copy the clinical note into a plain document. Replace the patient's name with [patient], the date of birth with [age band, such as 40s], dates of visits with [day 0], [day 14], and so on, and the provider's name with [clinician]. Remove addresses, record numbers and the payer member ID. Read it once from the top as a stranger would, and ask: could anyone work out who this is? Free-text notes carry surprising clues, such as an employer's name, a unique injury story or a small town. If you cannot make it safe, use route three. Keep the redaction mapping (which tag stands for what) out of the AI chat and in your own records, so that you can put the identifiers back by hand into the final letter.

A redaction example

Original line, illustrative: "Mrs Jane Doe, 47, seen 3 March, 14 March; right knee pain for about eight weeks, 7/10 despite six weeks of physiotherapy and naproxen; joint line tenderness, positive McMurray's test; MRI requested." Redacted: "[Patient], 40s, seen [day 0] and [day 11]; right knee pain for about eight weeks, 7/10 despite six weeks of physiotherapy and an anti-inflammatory; joint line tenderness, positive McMurray's test; MRI requested." The clinical logic survives, and the identity does not. The letter that comes back will carry the tags, and you will replace them with the real details after the AI step.

The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Build a payer criteria checklist before you draft

A letter that argues the right points in the payer's own terms is approved more easily than one that argues well in general terms. The way to get there is a short checklist per payer and service. Find the payer's current medical policy or prior authorisation criteria for the service on their provider portal. Copy the section's text into a document (this is a public or portal document, not patient data), and ask the assistant to turn it into a checklist.

Below is a payer's published criteria for authorising [service], copied
from their provider policy dated [date]. Turn it into a checklist of
the items a request must show. For each item give: the criterion in one
sentence using their wording, what documentation usually evidences it
(for example conservative treatment dates, imaging results, functional
scores), and a yes/no question I can put to the clinical note.
Do not add criteria that are not in the text. If something is
ambiguous, list it under "Check with payer".

TEXT:
[paste the criteria]

Save one checklist per payer and service in a shared folder, with the policy date. The first one takes half an hour, mostly reading the policy. The tenth is quick, because many payers ask for similar items: diagnosis and its code, what has been tried and for how long, results of relevant tests, functional impact, and why the requested service is the appropriate next step. When a payer changes its policy, you replace the checklist and every future letter benefits. Do not rely on the assistant's general knowledge of what "payers usually require". It does not know yours.

The letter prompt and what comes back

Give the assistant the redacted note, the checklist and a template structure. Ask it to write only what the note supports and to list anything the checklist needs that the note does not contain. That second instruction matters most, because it converts the assistant from a writer into a gap-finder.

Draft a prior authorisation letter from the redacted clinical note and
checklist below.
Structure: 1) request (service, code placeholder [CPT/HCPCS code],
diagnosis placeholder [ICD code]); 2) relevant history in 4-6 sentences;
3) treatment so far, with durations; 4) findings and test results;
5) functional impact; 6) why the requested service is appropriate and
how it meets each criterion, referring to the checklist numbers;
7) closing line and signature placeholder for [clinician].
Use only facts in the note. Do not invent any date, score, drug or
result. Keep to one page. After the letter, list every checklist item
the note does not evidence, under "Missing from the note".

CHECKLIST:
[paste]
REDACTED NOTE:
[paste]

An illustrative result for the knee MRI example, abbreviated: "I am writing to request authorisation for an MRI of the knee for [patient]. [Patient], in their 40s, has had knee pain for about eight weeks, rated 7/10 despite six weeks of physiotherapy and an anti-inflammatory. Examination found joint line tenderness and a positive McMurray's test. Conservative treatment has not resolved the pain or restored function (criterion 2). An MRI is needed to assess for a structural cause that would change management (criterion 4)." Under "Missing from the note": "Criterion 3, a plain X-ray result; criterion 5, a functional score." That list is the useful output: someone now asks the clinician for the X-ray result before submitting, which can save a denial and a resubmission.

What you fix before it goes to the clinician

Read the draft against the note, sentence by sentence. In the sample above, "or restored function" has to go: the note says nothing about function, which is exactly why criterion 5 sits on the gap list. Other fixes that come up often: the assistant turns "positive McMurray's test" into "findings consistent with a meniscal tear", a diagnosis the clinician never wrote; it rounds "about eight weeks" to "two months"; it writes "failed conservative therapy" where the note only says "7/10 despite six weeks of physiotherapy". Reword each so it states only what the note states. Put back the identifiers from your mapping, the codes from the clinician's order, and the attachments the checklist asks for. Then the clinician reads the letter as their own, edits what needs it, and signs. The assistant's draft has no clinical authority until they do.

The status tracker: one row per request, with a next action

A prior authorisation that nobody is watching ages quietly, and the patient pays for it in delay. A spreadsheet is enough. Use these columns: internal request ID (not the patient's name in a shared sheet if you can avoid it), payer, service, date submitted, submission method, payer reference number, expected decision date, current status, last contact date and method, next action, owner, and outcome (approved, denied, more information requested, withdrawn).

Req IDPayerServiceSubmittedDueStatusNext actionOwner
R-0412Payer AKnee MRI17 Mar24 MarPendingCheck portal 25 MarFront desk 1
R-0413Payer BInfusion course17 Mar31 MarMore info askedSend labs by 21 MarNurse lead
R-0414Payer ASleep study18 Mar25 MarApprovedBook patient; note expiry dateFront desk 2

Three rules make the tracker work. Every row has a next action and a date, so that a quick filter on "next action is today or earlier" is each morning's to-do list. Every contact is logged with the person, method and reference number. Approved requests carry an expiry date and a scheduled service, since an approval that lapses before the appointment is a second round of paperwork. You can also ask the assistant to turn the filtered rows into short chase messages for a payer portal or a phone call script, using only request IDs and payer reference numbers.

Here are the open requests due for follow-up today (no patient names,
request IDs and payer reference numbers only): [paste rows].
For each, write a two-sentence portal message asking for a status
update and listing the documents we sent, with their dates. Then list
any request where the expected decision date has passed by more than
two working days, as "escalate".

A month of requests in a four-clinician practice

An illustrative case. A practice with four clinicians submits about 38 prior authorisations a month, mostly imaging, specialty drugs and a few procedures. The practice manager times a sample and finds that a letter takes about 25 minutes from clinician note to a signed document, with another 10 for gathering attachments, and that nobody has a routine for checking status. Say 6 requests a month are denied for missing documentation, and the staff time spent on each resubmission is around 40 minutes.

The practice builds checklists for its five most common payer and service pairs and starts using redacted notes. Drafting falls from 25 minutes to about 12, including the redaction and the fix-up read. Across 38 requests that saves roughly 38 times 13 minutes, which is about 8 hours a month. The "Missing from the note" list catches gaps before submission, and the tracker shows who owns each follow-up. If the six documentation denials halve, that saves about two further hours. These are made-up numbers for a made-up practice; time your own sample over two weeks before and after and use that instead. The honest result to aim for is not a perfect approval rate but fewer avoidable denials and no request that nobody was watching.

A second example: a specialty drug that needs a step-therapy history

Imaging is the easy case. Drug requests often turn on what was tried first, in what order and for how long, so the history section does the work. Illustratively, a request for a second-line medicine needs evidence that two cheaper options were tried and either failed or caused side effects. The redacted note says: "[Patient], 50s; first-line agent for 12 weeks at standard dose with partial response; second agent stopped at week 3 owing to nausea; current symptoms persist." The draft, given a checklist that asks for "dose, duration and outcome of each prior therapy", should produce a small table in the letter body, one row per prior therapy, not a paragraph.

The gap list is where it pays. The note gives a duration for the first agent but no dose, and "partial response" with no measure. The assistant lists "dose of first-line agent" and "objective measure of response" under Missing. A nurse finds the dose in the prescribing record in two minutes; the clinician adds a sentence on the measure. Without that step the letter would have gone out looking complete and come back with a request for more information a week later. If a payer uses a standard form for drugs, paste the field names (not any patient data) into the prompt and ask the assistant to map the note to those fields, then complete the form by hand in the portal.

Portals, faxes and phone calls: the last mile

Drafting is only half of submission. Payers differ: some take requests through a provider portal, some by fax or secure message, some only by phone for urgent cases. Record the submission method per payer in your checklist file along with the usual decision time stated in their policy, so that the tracker's "due date" is calculated from a published figure, not a guess. For some plans the clock is now set by regulation: since 1 January 2026, many government-programme health plans have had to decide standard requests within seven calendar days and urgent ones within 72 hours, and to give a specific reason for any denial. That rule does not cover drugs, and other payers work to their own published timeframes, so note in the checklist file which timeframe applies to each payer. When a payer publishes different timeframes for standard and urgent requests, add a column for urgency and let the clinician mark it. Never describe a request as urgent to shorten the clock unless the clinician says it is.

Keep a copy of exactly what was sent, and when: the signed letter, the attachment list and the portal confirmation or fax receipt. Save them in one folder per request ID, named by the same ID as the tracker row. When a payer says "we never received the labs", you can show the confirmation within a minute. This is dull, and it is the habit that turns a late request into a quick fix, because the next person can see the whole story without asking the one colleague who remembers it.

Training the team and measuring the result

Run a thirty-minute session before launch with everyone who touches requests: what to redact, which route applies, where the checklists live, how to use the tracker and who signs. Practise on a made-up case so that no real patient's data is used for training. Then measure three things for the first two months: the time from clinician note to signed letter, the share of requests returned for missing information, and the number of requests that passed their expected decision date without a logged contact. A drop in the second and zero in the third are better signs than any time saving. If the second number rises, look at which checklist item is being missed and fix the checklist, the note template or both.

When a request is denied: using the same tools for the appeal

A denial letter states a reason. Read it carefully, because the same checklist and tracker give you what you need. Add the denial reason to the tracker, compare it with the checklist, and see whether the criterion was evidenced and missed, or never evidenced at all. Ask the assistant to draft an appeal letter from the denial text (redacted), the original request and the checklist, with the same rule that it may use only supported facts, and with a list of anything the clinician must add. The clinician decides whether to appeal, request a peer-to-peer conversation if the payer offers one, or change the plan. Put the appeal deadline from the denial letter into the tracker the day the denial arrives, because it is easy to miss while the clinician decides.

Stale criteria, stray identifiers and lapsed approvals

  • Identifiers in the prompt. A real name or ID slips in. Use a redaction step with a second look, a rule that the AI sees only tagged text, and a log of who did it.
  • Stale criteria. The checklist was built last year. Store the policy date on every checklist and re-check it every quarter or when a payer announces a change.
  • Overstated findings. The draft strengthens a clinical claim. Read each sentence against the note, and have the clinician read for tone as well as facts.
  • No owner for the follow-up. A request sits for three weeks. Make "owner" and "next action date" required columns and review the sheet at a daily huddle.
  • Approvals that lapse. The authorisation expires before the appointment. Record the expiry on approval and flag any appointment booked after it.

Where this sits in a wider clinic routine

Prior authorisation is one of several letter-and-chase jobs in a practice. The same method, a template, a checklist, a tracker and a clinician sign-off, applies to referrals (see referral tracking and chase letters), to visit-count tracking in a therapy practice and to the insurer forms and letters covered in the AI secretary tutorial for doctors. If your practice is run by a nurse practitioner, this workflow for nurse practitioners adds policy wording. Once approvals come through, the next pressure point is payment, which aged claims follow-up addresses.

If you want to be sure prior authorisation is the right first job to automate, a one-page AI use case template scores it against the others. And if you would like someone to map your current steps, choose the tool and set up the tracker with you, that is what my AI implementation consultation covers; the contact page is the way in. Whatever you build, keep two things fixed: the clinician signs, and patient identifiers stay out unless the tool, the plan and the agreement have been approved for them.

Questions practices ask before using AI on prior authorisations

Can AI decide whether a request meets medical necessity?

No. It can organise the clinician's reasoning and match it to the payer's published criteria, but the clinician decides what is clinically justified and signs the letter. Treat any AI statement about clinical criteria as a draft to verify against the payer's own policy.

Is it safe to paste patient notes into ChatGPT or Claude?

Not into a standard consumer account. Use redacted or fictional text, or a tool and plan your compliance adviser has approved with the right agreement in place. Ask the vendor in writing how data is stored and used before any patient information goes near it.

How often should we chase a pending request?

Set a rule per payer based on their stated turnaround, for example a check on the day after the published decision window ends, then every two working days. Log each contact with date, method and reference number so the next person can pick up.

Do we need a paid prior authorisation platform?

Not always. A small practice with a few dozen requests a month can run a letter template, a payer checklist and a shared tracker. Platforms and portals earn their cost at higher volumes or where they connect directly to payers and your records system.

Further reads

Sources: the government fact sheet on the interoperability and prior authorisation final rule (decision timeframes and denial reasons); OpenAI's help pages on business associate agreements and on ChatGPT for Clinicians; Anthropic's privacy centre page on BAAs for commercial customers; all checked November 2026. Also each payer's published prior authorisation policies and your own agreements with payers. Payer rules change; always check the current document.

Want prior authorisations to stop eating your front desk?

On a 1:1 call we'll map how requests move through your practice today, choose what to draft with AI and what to leave alone, and set up a tracker your team can run.

Book a 1:1 call with me