The decision
Does this prior authorization request meet medical policy criteria, and if not, who needs to look at it?
Health plans and benefits
Approve the clear ones, and route the rest to a clinician with the reasoning attached
Encode medical policy as rules that approve requests meeting every criterion, and send everything else to clinical review with the criteria already evaluated. Denials stay a clinical decision made by a person, and every determination carries its reasoning.
How it runs on AI Rule Engine
The request arrives
From a provider portal, a fax intake pipeline, or an integration, carrying the codes, the diagnosis, and the supporting documentation.
Documentation is read into facts
AI extracts and classifies what the clinical attachments contain and records the result as facts on the request. It reports what the document says, not what should happen.
Medical policy criteria evaluate
Each criterion in the policy is an explicit condition. The engine works backwards from the question, evaluating only the criteria that bear on it, and shows which were met and which were not.
Clear approvals go through
A request meeting every criterion is approved automatically, with the criteria and values that satisfied it on the record.
Everything else goes to a clinician
Not-met and partially-met requests route to clinical review with the criteria pre-evaluated, so the reviewer starts from the analysis instead of building it.
What the auditor sees
Most automation records that a decision happened. This records why it happened, on logic you can prove was in force at the time.
Criteria met and not met
The trace records each criterion that was evaluated and the value it matched, so a determination is a checklist with evidence rather than a conclusion.
The proof tree for a gap
When criteria cannot be established, the proof tree names the missing fact. That is what turns a denial-for-insufficient-information into a specific, answerable request to the provider.
The medical policy version in force
Determinations are pinned to the published version. A request decided under last quarter policy is explained by last quarter policy.
The reviewing clinician
Reviewers sign in before they can open a request, so the record carries the identity of the person who decided, the criteria they were shown, the point in the run where they were asked, and the response that came back.
A signed record of the policy release
Each publish is signed with RSA-SHA256 and verifiable against a public key, so the criteria in force on a given date can be proven unchanged.
Where the human stays
This is the point of the whole design. Automated approval is available for requests that meet policy. Adverse determinations stay with the clinician: the run pauses, the reviewer sees the criteria already evaluated and the documentation behind them, and their decision resumes the run and is recorded as theirs. Review requires signing in, so an adverse determination always carries the name of the clinician who made it.
Where AI is used, and where it is not
The boundary is enforced by how the workflow is built, not by a policy document. AI turns text into facts. Rules you wrote decide what those facts mean.
AI is asked to
- Extracting clinical values from attached documentation
- Classifying a request against a service category
- Summarizing a long clinical history for the reviewer
- Turning a stored trace into readable language for a determination letter
AI is never asked to
- Deciding whether a criterion is met
- Approving a request
- Issuing or recommending an adverse determination
- Any step where a clinician is required to decide
What changes
Clinical time on clinical work
Reviewers stop re-checking requests that meet every criterion and spend their time on the ones that need judgment.
Turnaround protected
Clear approvals resolve immediately instead of aging in the same queue as complex requests.
Consistent, specific determinations
Every determination cites the criteria it turned on, so provider appeals get a concrete answer.
Policy changes that are traceable
A criteria update is authored, tested, approved, and published as a version, with every determination linked to the version that decided it.
The objections you are about to raise
“Regulators will not accept automated prior authorization.”
What draws scrutiny is automated adverse determination without clinical review. This does the opposite: it automates approval where policy is clearly met and routes everything else to a clinician, with the criteria evaluation on the record either way.
“Our UM vendor already does this.”
Then the question worth asking them is what a determination shows six months later. If the answer is a status code and a note, you are carrying the risk of a decision you cannot reconstruct.
“Medical policy changes constantly.”
That is an argument for versioned, testable rules rather than against automation. Criteria are edited in the authoring UI, checked against saved cases, and published behind an approval, with prior versions intact.
“You have no SOC 2 and no BAA.”
Correct, and we say so plainly on our security page rather than burying it. On a dedicated deployment the platform runs inside your own Azure subscription, so this data stays inside a boundary your existing controls already cover. If a signed BAA is a hard requirement today, we are not yet the right fit and we will tell you that up front.
Frequently asked questions
Can the system issue a denial?
Configure it not to, and that is the intended design. Rules approve or route. Adverse determinations are made by a clinical reviewer through a human approval step. Reviewers authenticate before they can open a request, so their identity is recorded on the determination.
How do we handle a request with missing documentation?
Goal-driven evaluation produces a proof tree naming the fact it could not establish, which becomes a specific request to the provider rather than a generic insufficient-information denial.
Can we run this against real requests before trusting it?
Yes. Test cases and the what-if sandbox run a ruleset without side effects, so you can replay historical requests and compare outcomes before anything goes live.
Where does the clinical documentation go?
On a dedicated deployment it stays in your own Azure subscription, and paired with Azure OpenAI the model calls stay inside your boundary as well. Read the security page for the specifics before your review.
Related decisions
Bring us one decision you make by hand
Pick the decision that costs your team the most time and the most argument. In one working session we will model it, run it against your own examples, and show you the trace it produces. If it is not a fit, we will say so.