Payer and provider evidence exchange
Send the receipt, not the record.
A health plan and its contracted provider groups move enormous volumes of protected health information to settle questions that are, underneath, questions about a computation. Whether a quality measure was met. How a risk score was reached. Those questions can be answered with a signed receipt instead, and the data can stay where it already is.
Today
The data moves because the trust does not.
Chart chases, supplemental data files, extracts, retrieval vendors, secure transfer portals. When a plan and a contracted medical group disagree about whether a quality measure was met or how a risk score was reached, the way that gets resolved is by moving records until one side concedes.
Every transfer creates a new copy of protected health information, a new access surface, a new retention question, and a new obligation on both sides. The cost is not only the transfer. It is everything that has to be true about the copy afterwards.
And the question being settled is much narrower than the transfer. It is: did the stated computation run, over the stated population, under the stated controls, and what did it produce? None of that requires either side to see the other’s member data. It requires each side to be able to check the other’s work.
The pattern
The computation crosses as evidence. The data stays put.
Each side computes on its own data, inside its own boundary. Each side signs a receipt for the computation it ran. The receipts are exchanged, and each side verifies the other’s independently.
Claims, enrollment, and member data stay inside the plan’s boundary. The plan runs its computation there and signs a receipt for it.
receipt →Computation identifier and version. Control outcomes. Input and output digests. Population count and period. Signatures.
no PHICharts, encounter notes, and clinical data stay inside the group’s boundary. The group runs its computation there and signs a receipt for it.
← receiptNothing that could reconstruct a member crosses the boundary. What crosses is small enough to email and specific enough to argue with.
The artifact
What the receipt carries, and what it never touches.
A receipt is a record of a computation, not a copy of its inputs. That distinction is the entire reason this pattern is safe to propose.
Carried
What a receipt contains
- Computation identifier and version — the measure or model specification that ran
- The control set in force, and each control’s outcome
- Input and output digests — a hash, not the content
- Population count and the period covered
- Model and version, where a model was involved
- Timestamp and chain position
- Operator signature
- Witness countersignature, on portal‑minted receipts
Absent
What it does not contain
- Any member identifier
- Any claim, chart, encounter note, or clinical document
- The input or output content
- Anything that could reconstruct them
- Any judgement about whether the result was right
Two exchanges
A quality measure, and a risk score.
A quality measure computation
A plan computes a measure over its claims data. A contracted provider group computes the same measure over its clinical data. The numbers differ, as they usually do, and the reconciliation today is a file transfer.
With receipts, each side publishes a signed record of the computation it actually ran: the measure specification and version, the control set, the population count, the period, and the digest of the result. Each verifies the other’s. Where the receipts agree on inputs and disagree on outputs, you have located the disagreement precisely — before a single record moves, and often without needing to move one at all.
A risk score computation
A risk score derived partly by model has to survive a look‑back that may arrive years later. Reconstructing what ran, after the fact, from logs and tickets and someone’s memory of a model version, is the part nobody enjoys.
A receipt records which model version ran, which controls were in force, whether the human‑review control fired, and what the computation produced — as a signed record made at the time, not a reconstruction assembled afterwards. If records genuinely do need to move later, the receipt tells you exactly which ones, and why.
What an exchanged receipt records, reduced to its key fields. Field names are illustrative; the format is OVERT, which is open and which Glacis stewards.
Field shapes for this pattern, not a signed artifact. The verifier below loads a real receipt and checks its signatures in your browser.
Run the checks belowWhere the obligation lands
The plan is the party whose decision affects care.
Rules governing the use of algorithms in coverage and utilization decisions land mostly on the plan, and the reason is structural rather than political: the plan’s determination is the act that changes what a member receives. A provider group’s model is an input. The plan’s decision is the event.
That asymmetry sets the position a plan actually wants to be able to defend, and it is not the one the coverage of this topic assumes. It is not “we used AI to decide,” and it is emphatically not “we used AI to say no.” It is one of two sentences, each with a record behind it:
“We approved — and here is the record of what ran, under which controls, on what date.”
“We do not have enough information yet — and here is the record of what ran, what it could not resolve, and what we asked for.”
The second sentence is the harder one to defend and the more common one in practice. A pended decision carrying a signed record of the controls that evaluated and the information that was missing is a materially different artifact from a pended decision carrying a note in a queue. How any of this maps to your specific obligations is a question for your counsel and your regulator. What Glacis supplies is the record.
What this is not
A pattern, not a ratified standard.
Nothing on this page is an interoperability standard. There is no balloted specification for exchanging computation receipts between a plan and a provider, no implementation guide, and no conformance program, and we are not going to imply that there is one. Claiming otherwise would be the exact behavior this company exists to make unnecessary.
What does exist is OVERT, an open receipt format Glacis stewards, and a verifier anyone can run without our involvement. Two counterparties who agree to exchange receipts can begin today, bilaterally, under the agreements they already have. Nothing needs to be ratified for that to work.
Whether the pattern becomes a standard depends on whether enough counterparties find it useful, which is a slower and considerably more public process than anything a vendor can announce. We would rather describe it accurately now than claim conformance to something that does not exist yet.
What a receipt is, and is not
The boundary of the claim.
A receipt is evidence that a defined control ran and what it decided. It is not a certificate that the computation was correct, that the system is safe, or that either party is compliant, and we will not describe it as one.
Two receipts that both verify tell you that both sides ran what they said they ran. They do not tell you the measure specification was the right specification, or that either result is clinically or actuarially sound. Those stay human judgements. What the receipts remove is the argument about what actually happened, which is usually the part that consumes the quarter.
Because no protected health information crosses, the pattern does not create a new flow of it between the parties. It does not dissolve the agreements you already have, and counsel on both sides should scope any exchange before it goes to production. We will hand them the schema.
Receipts minted through the Glacis portal are countersigned by an independent witness and carry an inclusion proof against an append‑only log. Receipts minted through the SDK are operator‑signed. For an exchange between counterparties, the countersigned path is the one worth using, because it means neither party is the only one who can say what happened.
Verify it yourself
Run the checks in your browser.
This is the part that matters for an exchange: the counterparty checks the receipt without asking permission from anyone. The verifier fetches our canonical demonstration receipt — it records a clinical documentation workflow, the one we publish publicly — and checks both Ed25519 signatures and the hash commitments with WebCrypto, locally, on this page. An exchanged receipt has the same structure with different fields.
Where to start
One computation, one counterparty.
This does not begin as a network. It begins as one computation you already argue about, with one counterparty who is already tired of arguing about it.
Pick the disputed computation
The measure or the score where reconciliation costs both sides the most. Usually everyone can name it in the first minute.
Agree the receipt schema
Both sides fix what the receipt will carry before either mints one. Counsel on both sides reviews it. This is the negotiation, and it happens once.
Mint on both sides
Each party runs its own computation in its own environment and signs the result. Neither party changes where its data lives.
Exchange and verify
Each side verifies the other’s receipt at /verify, with no dependency on Glacis and no data transfer between the parties.
Bring the computation you argue about most.
We will scope one exchange with one counterparty, define the receipt both sides will accept, and show you the verification path before anyone signs anything.