Privacy
The cheapest way to protect a record is not to send it.
Prior authorization normally works by handing the payer the chart and trusting them with it. Pavo answers the payer's question without the chart ever crossing the boundary.
The circuit
Three criteria, proven, none disclosed.
The patient meets the age floor
A comparison inside the circuit. The age itself is never transmitted.
The diagnosis matches the covered condition
Checked against a hash. The code is never transmitted.
The deductible requirement is satisfied
A threshold check. No amount is ever transmitted.
groth16 over the bn128 curve, built with circom and snarkjs. The proving artifacts are committed to the repository, so a proof returns in well under a second with no setup step.
Public signals — the complete payload 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. Everything else stays in the provider's system.
What this circuit does not do
Two limits worth stating before anyone asks.
A prototype that oversells its cryptography is worse than one that has none, because it invites the wrong kind of trust.
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.
Operating constraints
These hold in code, not just on paper.
Each of these is enforced at the point where it would otherwise be violated, and each has a test that fails if it stops being true.
Raw PHI is never stored
Patient identifiers are SHA-256 hashed before they reach the database. Member IDs read off an insurance card are hashed too, and the hash — never the raw value — is what appears in storage paths.
Every decision carries a rule ID
The rule engine cannot return an outcome without one, and it is written to the audit log on every decision.
Ambiguity escalates
Anything without a definitive rule match becomes escalated rather than being guessed at. The system knows what it does not know.
No automated final denial
A denial is either appealed or escalated to a human. The payer agent answers a rejected appeal with ESCALATED, never DENIED.
Private keys never reach the database
Key storage holds the public key and a digest of the private key, nothing more.
Unverified messages do not act
A signature that fails verification is rejected with a 401 before its payload is read, and the rejection is audited.
Sample data is always labelled
With no model key — or a text-only provider that cannot read the documents — the parsers return values that are obviously placeholders, and the API response names the source of each half. Nothing silently invents a member's plan.
Before any real data
Nothing here has touched a real patient record.
Every figure in this build is synthetic. The demo patients are fixtures, the facility prices are generated deterministically from the CPT code, and the insurance documents are labelled samples.
A HIPAA business associate agreement is a prerequisite before any real data flows through the system, and the operating constraints above are the reason the architecture is ready for that conversation rather than something to be retrofitted after it.