Healthcare pays first and determines afterward whether the payment was correct. We create verifiable evidence at the moment care happens, bind it to the payment decision that follows, and preserve it so any reviewer can check the result years later without trusting us.
Working implementation. Record format frozen and published. Verified across 2,080 independent checks with zero failures, reproducible on a machine that has never contacted our systems.
The verifier is public, open source and offline. Clone it, build it, and check our evidence on a machine that has never contacted us. Then alter a field and watch it fail. Both sessions below are real output from that tool, replayed exactly as recorded.
You do not have to install anything to do it. The same verifier runs inside your browser on the page below, on real signatures, with no request made to us.
Both sessions are transcripts of the published verifier running against synthetic data. Session one is the check most people expect: alter a field, the digest and the signature both fail. Session two is the one that matters more, because it is the case where we are the adversary. We hold the signing key, we rebuild our own log, and a witness that keeps its own record of what it last endorsed refuses to co-sign the result. The mechanism is built and tested. The witness key in this demonstration is still held by us, so until an outside party holds one we do not claim the log is independently anchored. That is a deployment step, not a software one, and we would rather say so here than have you find it later.
A provider makes an assertion. Money moves on that assertion. Years afterward, a reviewer has to determine whether it was true, using records reconstructed after the fact by the party with an interest in the outcome.
Every control in use today works downstream of that. Analytics, audit contractors and claims intelligence all operate on data whose origin cannot be independently checked. They can establish that a claim is inconsistent with policy. They cannot establish that the event behind the claim occurred, because no artifact establishing that event exists at the moment it occurs.
The result cuts two ways. An honest facility that delivered care absorbs a recoupment because it could not produce a document in the form a reviewer wanted. And a fraudulent operation billing against stolen identities is discovered only after the money is gone, because discovery after payment is the only mode the system currently has.
One signed record at each consequential event in an episode. No change to clinical workflow. No medical record ever leaves the facility.
The hospital discharge opens the episode and starts the chain. Captured from message streams that already flow, with no vendor negotiation required.
Beneficiary and provider bound to authoritative identifiers rather than to a local record number, at the moment the relationship is established.
The certifying clinician's eligibility is confirmed at the instant the order is signed, and that determination is frozen into the record.
A cryptographic fingerprint of the document. The document itself never moves and is never held by us.
One record per visit, bound to the clinician who performed it, created when the visit is documented.
Each record carries the fingerprint of the one before it and is anchored in an append only log. Alteration, insertion, deletion and reordering are all detectable afterward by a party who trusts nobody involved.
The orchestration layer attaches at four defined points. It attests. It does not move money.
The same episode, stepped through. Every record below is in the public conformance bundle, and the verdicts are what the published verifier returns when you run it yourself.
A patient is discharged. A signed record is produced immediately, carrying only what is needed to prove the event, and nothing more.
Five events across the episode. Each carries the fingerprint of its predecessor, and each is signed by the organization that made the assertion. No party signs on behalf of another.
At claim intake the submission is matched to the episode and annotated with a reference to its evidence root. This is enrichment. Nothing is gated and the claim proceeds exactly as it does today.
The verification service walks the chain, checks every signature, confirms each record is in the anchored log, and answers one question. It returns a verdict and signs the verdict itself, so the answer is as checkable as the evidence underneath it.
Someone changes the discharge disposition code in record one, two years later, to support a claim that would otherwise fail. This is the single most common form of documentation fraud, and today it is close to undetectable.
A claim arrives from an entity billing against a stolen identity. There is no episode underneath it. No discharge, no admission, no order, no visits. This is the pattern behind more than a million stolen Medicare identities in a single federal enforcement action.
The walkthrough above is illustrative. The live demonstration runs on a working reference implementation, offline, on a machine we hand to you, and includes independent verification on a second machine that has never contacted our systems.
Each of these is a structural property rather than a policy commitment. A policy can be waived when a schedule slips. A missing capability cannot.
The largest healthcare breach on record reached an estimated 192.7 million people because the system was holding data it needed to move. A complete compromise of this layer would disclose episode structure and pseudonymous references. No clinical content, because none is present. Beneficiary identifiers appear only as keyed pseudonyms, with the key held separately from the records.
The layer runs on the operator's own infrastructure, under the security authorization that already exists there. We do not host a service and do not take custody of federal, clinical or payment data at any point. The record format is a published specification and the verifier runs standalone and offline, so every proof produced remains verifiable without us.
Under Executive Order 14028 and OMB Memorandum M-22-18, federal agencies may use software only from producers who attest to secure development practices. The supporting ecosystem is cryptographic attestation backed by an append only transparency log with inclusion proofs. The same construction has operated at internet scale in Certificate Transparency for over a decade.
The government already accepts, requires and operates this model to answer whether a piece of software is what it claims to be. We apply the same evidence pattern to answer whether a healthcare event was what it claims to be.
That makes this an extension of an accepted control into a new domain, rather than a novel proposal. The same construction underlies Certificate Transparency, which every browser relies on to detect a mis-issued certificate. A federal program and a commercial health plan are asking the same question of their evidence, and the answer does not change with the buyer.
Post-quantum signatures under the current NIST standard. Transparency log construction per the specification behind Certificate Transparency. Canonical serialization per published RFC. Clinical capture on HL7, FHIR and CDS Hooks.
The record format is a published specification. The verifier runs standalone and offline. A second implementation can be built by a third party from the specification alone, and every proof we produce stays verifiable without us.
Algorithm and version are recorded inside every signed payload, and all cryptography passes through a single provider interface. A federal build selects a validated module and swaps it in. A commercial deployment makes the same choice on its own terms. That is a deployment decision, not a rewrite.
Stated plainly, because a reviewer who finds the gaps themselves discounts everything above them. This is the same inventory we hand to engineering and security teams before they ask, and it is why what sits above it can be relied on.
MedXT’s core evidence-verification technology is operational today. Moving from the current implementation into customer production environments introduces additional integration, security, compliance and performance requirements that will vary by deployment.
Fee-for-service payment integrity, where the dominant failure is evidentiary rather than criminal and post-payment recovery is structurally limited.
Organizations modernizing claims infrastructure, where verification interfaces can be designed in rather than retrofitted to production systems later.
Medicare Advantage risk adjustment, where the plan carries the overpayment itself, findings extrapolate across the contract, and the threshold question in an audit is whether an authenticated encounter record exists, by an eligible provider, in the service year. Also verified inputs to existing analytics and claim intelligence, which raises the ceiling on what those capabilities can conclude.
Post-acute organizations carrying a disproportionate documentation and audit burden, who would hold the evidence record rather than reconstruct one on demand.
The walkthrough is a working demonstration, not slides. We build the open source verifier from source, verify a synthetic episode, then break it in front of you: alter one field and watch the check fail, and rewrite the log as its own operator and watch a witness refuse to co-sign it. We run the failures ourselves because a demonstration that only succeeds proves nothing. Then your engineer takes the keyboard and does the same on their own machine.