Project 08 of 09
Nothing is submitted without a clinician.

Prior Authorization

An agent for Campux Health that reads a clinical order, checks it against the payer's own medical-necessity policy, and drafts a justification a clinician signs off on. It never guesses that a criterion is met, and it never submits.

build time: 6 to 8 hours
cost: Under $8 if torn down the same day⁴
services: Foundry Agent Service, Azure AI Language (PII detection, Text Analytics for health), Azure SQL Database, Entra ID, Azure Monitor
assumes: Project 07, or its PHI handling. You can explain managed identity and role assignment.
exams: Overlaps AI-103, AI-200
vocabulary: Prior authorization, medical necessity, criterion, supportable, justification, human-in-the-loop, FHIR

The problem

A Campux Health clinician orders an MRI of the lumbar spine. The patient's insurer will not pay for it without prior authorization, and the criteria run to two pages.

Today a coordinator reads the chart, reads the payer's policy, decides whether the order meets each criterion, gathers the notes that prove it, and submits the package through a portal. It takes half an hour, and an incomplete submission comes back denied a week later, with the patient still in pain. The medical director does not want the submission automated. She wants the reading and the drafting done in minutes, and a clinician to approve every word before it leaves the building.

definition: Medical necessity. The payer's published test for whether it will cover a service: a list of criteria, each either met by something in the chart or not. Prior authorization is the act of proving, before the service, that the criteria are met.

The architecture

Seven parts. The agent decides supportable or not, and a clinician decides whether to send.

livepress play to follow one order from chart to payer

Figure 4 The agent produces verdicts and a draft; the submit path belongs to a clinician and does not exist for anyone else. The payer sits outside every boundary on purpose.

Redact. The order's note goes through PII detection before the agent can read it.
Extract. Text Analytics for health pulls diagnoses, prior treatments and red flags out of the redacted note.
Judge. The agent gets the extracted facts and the requested service, never a name.
Look up the policy. File search returns the payer's numbered medical-necessity criteria.
Log it. Every criterion verdict and the entity it cites go to an append-only audit table.
Draft, or refuse. All criteria met: a letter quoting each one. Anything unmet: a list of what is missing, and no letter.
Review. A clinician reads the draft and the per-criterion verdicts.
Submit, by hand. Only an approved package leaves the building; the agent has no submit path.

Service map, for readers coming from AWS
Job	AWS version	This build	Same idea?
Model	Bedrock model	Foundry model deployment	Yes
Agent runtime	Bedrock Agent	Foundry Agent Service	Yes
PHI redaction	Comprehend Medical PHI detection	Azure AI Language, PII detection	Yes
Clinical extraction	Comprehend Medical entities	Text Analytics for health	Yes
Payer policy	Knowledge base	File search over criteria PDFs	Yes
Audit trail	CloudTrail + a ledger table	Azure Monitor + an append-only log table	Yes
Identity	IAM	Entra ID + managed identity, split roles	Different. Read the trade-offs below

The build

In this order. Step 7 is the one that separates a useful assistant from a liability: the agent must be able to say "not supportable" and mean it. Synthetic data throughout.

Foundry project and model
Create a Foundry project, deploy gpt-5-mini, confirm against the Learn page for the day; same setup as Project 01.
The model answers in the playground.
Payer policy documents
Write three short medical-necessity policies as PDFs, one per service: MRI lumbar spine, a specialty biologic drug, and advanced cardiac imaging. Each lists numbered criteria, for example: six weeks of documented conservative treatment, a specific symptom, no red-flag contraindication. Upload to a file search vector store.
The vector store shows three files indexed, and you can read the MRI policy's numbered criteria yourself.
Synthetic orders and notes
Build fifteen fake orders in Azure SQL: the service requested, and a short clinical note. Make some clearly supportable, some clearly not (no conservative treatment tried), and two ambiguous. Plant a name and a phone number in a few notes, on purpose.
```
Order 004: MRI lumbar spine.
Note: "8 weeks PT and NSAIDs, no relief. Positive straight-leg
raise. No bowel or bladder involvement. Pt requests imaging.
Ordering per Dr. Nguyen."
```
Fifteen orders, at least four unsupportable, at least three notes containing a name that is not the patient's.
Redact before anything runs
Run Text PII detection over every note. Store the redacted note for the agent; keep the original and the name mapping in a separate table with its own tighter role, exactly as in Project 07.
A redacted note shows placeholders for every name and number. The mapping table is not reachable by the agent's identity.
Extract the clinical facts
Run Text Analytics for health over the redacted notes. Pull out diagnoses, prior treatments and their durations, and any red-flag findings as structured entities.
For order 004, the extracted entities include eight weeks of physical therapy and a positive straight-leg raise. Verified: they arrive as a time linked to a treatment and a value linked to an examination, and "no bowel or bladder involvement" arrives marked negative.
The agent
Create an agent with file search over the payer policies. Instructions: for the ordered service, retrieve its policy, and for each numbered criterion state met, unmet, or not documented, citing the exact extracted entity that satisfies it. Never mark a criterion met without a cited entity.
For order 004, every MRI criterion is marked met with a specific citation, and the conservative-treatment criterion points to the eight weeks of PT.
Draft, or refuse to draft
If every criterion is met, the agent drafts a justification letter that quotes each criterion and the chart evidence for it. If any criterion is unmet or undocumented, it produces a short "not supportable" note listing what is missing, and drafts no submission.
A supportable order yields a letter. An order with no documented conservative treatment yields "not supportable: criterion 2 has no cited evidence", and no letter to send.
The clinician gate
Build a review screen: the draft, the per-criterion verdicts with citations, and an Approve control. Nothing is marked ready to submit until a clinician approves. There is no path in the system that sends a package to a payer without that click.
Try to reach a "submitted" state without approving. You cannot; the state does not exist.
Audit and identity
Log every criterion verdict, its citation, the draft version, and the approving clinician to an append-only table. Split roles: the agent's identity (redacted data and policies only), the coordinator role (review and draft), the clinician role (approve). Remove any key used while building.
grep -ri key .env* returns nothing. You can answer "why did we say this MRI was justified" from one audit row, and see who approved it.
Tear it down
```
azd down
```
Then check the resource group by hand, including the Azure AI Language resource if you created it separately.
The resource group is empty. Today's cost is under $8.

Where it breaks

Cause each one on purpose. A prior-auth tool that fabricates a justification is worse than no tool; it launders a guess into an official document.

The invented criterion Feed it an order where conservative treatment was never tried, and watch an early version write a confident letter claiming it was. Fix: a criterion is met only with a cited extracted entity; no citation, no "met"; verify every citation in the audit log resolves to a real value.
It drafts for an unsupportable order The agent should refuse to draft a submission when a criterion is unmet, not soften the language and send it anyway. Test it with a deliberately weak order and confirm you get "not supportable", not a hopeful letter.
Redaction misses a referrer A note naming the ordering physician or a relative may slip past redaction. It did not slip in our run; "Dr. Nguyen" was masked. Do not take that as a guarantee: build the note that breaks it, a nickname or a surname used as a first name, and hand-sample before you trust it at volume.
Policy drift Change the MRI policy's conservative-treatment requirement from six weeks to twelve and rerun. Order 004 (eight weeks) should flip from supportable to not. If it does not, the agent is not reading the policy per run.
The missing role Deploy without Foundry Project Manager and read the error. Same as Project 01, worth seeing again.
The silent auto-submit The worst failure. If any code path can move an order to submitted without a clinician approval, a denied or wrongful authorization goes out under a clinician's name. Test by trying to force that state directly; it must be impossible, not merely discouraged.

The trade-offs

Draft and approve, or submit automatically?: Auto-submission is faster and, for prior authorization, indefensible: a wrong authorization affects a patient's care and carries the ordering clinician's name. This build stops at a reviewed draft on purpose. The time saved is in the reading and writing, not the sending.
Let the agent judge, or hard-code the criteria?: Numeric thresholds, like six weeks of treatment, are safer computed in code than reasoned by a model. This build has the agent read the policy and match evidence in language, but keeps the letting-through decision explicit and auditable per criterion, so a human can see exactly which one it relied on.
Redact first, or reason on the full chart?: Same tension as Project 07. Redacting first keeps PHI out of every model call and loses some context. For prior authorization the context that matters is clinical, not the patient's name, so the loss is small and the safety is large.
Build for today's portal, or the coming FHIR API?: Right now most prior authorizations are submitted through payer portals or fax. Under the CMS Interoperability and Prior Authorization Final Rule, affected payers must run a FHIR-based Prior Authorization API, with the API requirements due 1 January 2027.² This build drafts a human-submitted package today; a production version would target that API as payers turn it on. The agent's job, deciding supportability from evidence, does not change.
HIPAA, or a non-US framework?: Written for HIPAA. Prior authorization as a concept is specific to US-style payer systems; the same de-identify-first, cite-everything, human-approves design would carry to any regulated approval workflow, but the regulatory scaffolding around it would be entirely different.³

In the interview

"Tell me about an agent in a real payer workflow."

decisionA prior-auth assistant: read the order, match each medical-necessity criterion to cited chart evidence, draft a justification, and stop at a clinician approval.
reasonThe reading and drafting are slow and mechanical; the judgment and the submission are not the agent's to make.
watchedWhether it ever marked a criterion met without a citation. It did once, before I forbade it.

"How do you stop it fabricating a justification?"

decisionA criterion is met only when a specific extracted entity is cited; no citation, no letter, and it says what is missing instead.
reasonAn official document that launders a guess is worse than a blank one.
watchedEvery citation in the audit log resolves to a real extracted value, not free text.

"What about the CMS electronic prior-auth rule?"

decisionToday the draft is submitted by a person; the design targets the FHIR Prior Authorization API as payers stand it up.
reasonCMS-0057-F requires that API of affected payers, with the API work due January 2027.
watchedThe agent's supportability logic is independent of the submission channel, so the channel can change without reworking it.

Evidence

One supportable, one not: Two orders side by side: the drafted letter with its citations, and the "not supportable" note listing what is missing.
One audit row: A single order's per-criterion verdicts, citations, and the approving clinician, screenshotted.
The repo: Instructions file, the three policy PDFs, the role assignment script, and a README that states plainly it uses synthetic data and does not submit to any payer.
One sentence for the résumé: "Built a prior-authorization agent that de-identifies clinical text, matches payer medical-necessity criteria to cited chart evidence, refuses to draft unsupportable requests, and routes every submission through clinician approval and an audit log."

Project 09, Medication Reconciliation. Cross-check one patient's medications across two record sources and cite every line that disagrees.

Notes

Checked against Microsoft Learn on 2 September 2026, and the redaction and extraction steps were run on this page’s own sample note on 3 September. "No bowel or bladder involvement" came back with the symptoms marked certainty=negative, which is exactly what lets the agent treat the red flags as absent rather than present. Azure AI Language and Text Analytics for health are decision-support tools, not medical devices; the clinician approval gate is not optional politeness, it is the point.
The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires affected payers, including Medicare Advantage, Medicaid, CHIP, and Federally Facilitated Exchange QHP plans, to implement a set of HL7 FHIR APIs including a Prior Authorization API, with the API requirements due 1 January 2027 and certain operational changes from 1 January 2026. Confirm the current dates and which payers are in scope before you rely on them; rules move.
Not legal advice. This project uses fabricated data. Real prior authorization on real PHI needs a signed Business Associate Agreement with Microsoft, in-scope HIPAA-eligible services, and your organization's own compliance sign-off, none of which this page provides.
"Under $8" assumes fifteen small orders, three short policy PDFs, and teardown the same day. Azure AI Language billing and Foundry model tokens are the two line items that grow with real volume.