Pavo CloudMenu

Autonomous healthcare authorization

Prior authorization that resolves in minutes, not weeks.

Provider and payer agents negotiate authorization directly over ARIA. Clear cases resolve automatically. Ambiguous ones escalate to a human with the full record already assembled.

End to end

11s

measured, order to price

Median decision

46ms

created to resolved

Decisions with a rule ID

100%

the engine cannot return one without

The problem

A fax sits in a queue for two weeks while a patient waits.

Prior authorization is the friction tax on American healthcare. It runs on fax machines, phone trees and staff rekeying the same clinical data into a second system.

3–14 days

The typical wait for a decision that, for a clear-cut case, needs no human judgement at all.

$35B

Spent every year on the administrative overhead of asking permission and answering the question.

Two systems

The clinical record already holds every fact the payer needs. It is re-entered by hand because the two sides cannot talk.

How a request flows

Six steps, no human in the loop until one is needed.

Every step below is a real subsystem, not a diagram. The demo runs all six against the same agents, rules, signatures and circuit the rest of the app uses.

  1. 01

    EHR order fires a webhook

    A physician places an order and the webhook fires. No member of staff submits anything, and no one rekeys a fax.

  2. 02

    Both agents prove who they are

    Each organization holds an RSA-2048 key pair. Every ARIA message is signed over a SHA-256 digest of its contents, and a signature that fails verification is rejected before its payload is ever read.

  3. 03

    Criteria are proven, not disclosed

    A zero-knowledge proof shows the patient meets the payer's criteria. The age, the diagnosis code and the deductible amount never cross the boundary.

  4. 04

    A deterministic rule decides

    Five coverage rules are evaluated in order and the first match wins. A model never decides coverage — the engine cannot return an outcome without a rule ID.

  5. 05

    The decision carries its reasoning

    The outcome, the rule that produced it and the confidence are written to an append-only audit log. Anything without a definitive match escalates to a human rather than being guessed at.

  6. 06

    The member sees what they will pay

    The same authorization drives a price comparison across nearby facilities — what the member actually pays, through insurance or in cash.

Zero-knowledge

The payer learns whether you qualify. Not why.

A payer needs three facts about a patient. It does not need the chart to know them. The provider sends a mathematical proof instead.

  • Patient meets the age floor — the age itself is never sent

  • Diagnosis matches the covered condition — the code is never sent

  • Deductible requirement is satisfied — no amount is ever sent

groth16 over bn128. The circuit artifacts are committed, so proving works out of the box — a proof returns in well under a second.

Public signals — everything the payer receives

[
  "1",
  "1",
  "1",
  "18",
  "19673004205371315839122558043490202024231",
  "1"
]

Three satisfied criteria, the age floor that was tested, the hashed condition, and a validity flag. The chart stays where it was.

Deterministic, not a black box

A model never decides coverage.

Rules are evaluated in order and the first match wins, so the specific knee rule is checked before the general one. Every decision records the rule that produced it, and the table is returned by the API at runtime.

RuleProcedureDiagnosisOutcome
PAVO-R00170553 (MRI brain)anyAPPROVED
PAVO-R00227447 (knee replacement)M17.11APPROVED
PAVO-R00327447 (knee replacement)any otherESCALATED
PAVO-R00499214 (office visit)anyAPPROVED
PAVO-R005any otheranyESCALATED

Two of the five escalate. That is the point: the system is built to hand over the cases it cannot settle, with the record already assembled, rather than to produce a confident answer to a question it was never equipped to decide.

Insure

The same authorization tells the patient what they will pay.

Upload an insurance card and an Evidence of Coverage, ask for a procedure in plain language, and get what you would actually pay at each facility nearby.

Cash prices run well below negotiated rates. Before a deductible is met, paying cash is frequently cheaper than using the insurance you already pay for — and nobody tells the member that.

Knee replacement · CPT 27447 · deductible not met

Northgate Community Hospital

$5,296

Negotiated rate
$26,482
Cash price
$7,176

One of five facilities returned for this procedure.

What's real today

A prototype that says which parts are prototype.

Everything below the fold on most demos is a claim. Here is the line between what runs and what does not, so you can judge the rest of this site knowing where it sits.

Running now

  • The full authorization loop, end to end, in about eleven seconds

  • ARIA envelopes signed RSASSA-PSS over SHA-256, with an RSA-2048 key pair per organization

  • groth16 proofs over bn128 — the circuit artifacts are committed, so proving works out of the box

  • Five deterministic coverage rules, each decision carrying the rule that produced it

  • An append-only audit log covering every entity, exportable as CSV

  • Autonomous appeals with a confidence threshold below which the system escalates instead

Not yet

  • The ZK circuit is deliberately simplified

    The approved-diagnosis check compares against a single hash, so a passing proof does tell the payer the patient carries that one diagnosis. Proving membership in a set of many codes without revealing which needs a Merkle circuit. The age and deductible criteria leak nothing.

  • The trusted setup is local

    The build runs its own Powers of Tau ceremony, so whoever runs it knows the toxic waste. Fine for a prototype; these artifacts should never secure anything real.

  • Facility pricing is mocked

    Prices are generated deterministically from the CPT code rather than gathered from facilities by the voice agent.

  • NPI verification is a flag

    Not yet a lookup against the live CMS registry.

  • Federated learning is not built

    It is described in the specification as a later phase and is not part of the running system.

Watch one order go start to finish.

Six steps, live against the running system — signed messages, a real proof, a deterministic decision and the audit trail it wrote. About eleven seconds.