Payer and provider evidence exchange
Share operational evidence, not sensitive records.
A health plan and its contracted provider groups may move protected health information to investigate a quality measure or risk score. For selected computations, a signed record can carry covered inputs by reference, reported control outcomes, and result commitments while sensitive source data stays within an agreed boundary. It supports a narrower review; it does not settle the computation or eliminate required data exchange.
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.
The operational question may be narrower than the transferred chart: which computation and population were claimed, which control outcome was recorded, and which result was committed? A signed record can make later alteration of covered fields detectable and attribute them to a key. It does not independently prove that the computation ran as reported or remove the need for source evidence where that question matters.
The pattern
The result can cross as evidence. Covered source data can stay put.
Each side can compute on its own data, inside its own boundary, and sign a configured receipt for the covered computation. The receipts are exchanged, and each side verifies the other’s independently.
In this profile, raw claims, enrollment, and member data are excluded from the exchanged receipt. The plan runs its computation inside its boundary and signs the covered result.
receipt →Computation identifier and version. Control outcomes. Input and output digests. Population count and period. Signatures.
raw PHI excludedIn this profile, raw charts, encounter notes, and clinical data are excluded from the exchanged receipt. The group runs its computation inside its boundary and signs the covered result.
← receiptThe configured exchange profile excludes raw member data and carries bounded fields and commitments for the covered computation.
The artifact
What this receipt profile carries, and what it excludes.
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
- Glacis service witness countersignature and inclusion proof, when present on portal‑minted receipts
Absent
What this profile excludes
- Any member identifier
- Any claim, chart, encounter note, or clinical document
- The input or output content
- Anything that could reconstruct them
- Any judgment 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 report of its declared computation: the measure specification and version, control set, population count, period, and result digest. Each can verify the other’s record integrity and signer. Agreement on declared inputs with different reported outputs narrows the investigation; deployment, computation, source-data, and control-testing evidence plus the governing agreements determine what conclusions follow and whether source records must move.
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 can carry a signed report of the declared model version, configured controls, reported human-review outcome, computation result, and event time. The signature protects covered fields and identifies a key; independent timing, actual execution, computation correctness, contemporaneity, and any need to move source records require surrounding evidence and agreement.
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 signed report of what the configured path recorded, under which declared controls and event time.”
“We do not have enough information yet — and here is the signed report of the unresolved fields and follow-up the configured path recorded.”
The second sentence is the harder one to defend and the more common one in practice. A pended decision carrying a signed report of the configured control claims and missing information is a different artifact from a queue note, while still requiring routing, execution, coverage, and control-testing evidence. How any of this maps to specific obligations is a question for counsel and the regulator.
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 signed record is, and is not
The boundary of the claim.
A signed record preserves covered fields and a reported control outcome under an enrolled key. Verification can support integrity and attribution; it does not independently prove that the control ran or worked, that the computation was correct, that coverage was complete, that the system is safe, or that either party is compliant.
Two receipts that both verify tell you that each side signed a structurally valid record with the disclosed fields and result. They do not independently establish that the underlying computation ran as reported, that coverage was complete, that the measure specification was right, or that either result is clinically or actuarially sound. Those require trusted collection, corroborating evidence, and human judgment. The receipts narrow the integrity and attribution questions rather than resolving every dispute about what happened.
When the exchanged receipt is configured to exclude protected health information, the pattern need not create a new PHI flow between the parties. It does not dissolve the agreements you already have, and counsel on both sides should scope the fields and exchange before it goes to production. We will hand them the schema.
Receipts minted through the Glacis portal may carry a Glacis service-operated witness countersignature and inclusion proof against an append‑only log. Receipts minted through the SDK or self-hosted path may be operator‑signed only. The countersigned path adds a separately identified service key and log proof; it does not by itself establish organizational independence.
Verify it yourself
The checks run 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 can check a supported record at /verify. Signature and commitment checks need not disclose the underlying payload, but the verifier may still retrieve recognized keys or inclusion data; review the actual exchange and network path.
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.