HiveClear gives every prior auth decision a receipt that holds up, for $0.0096 each. Prior auth denials are one of the biggest ways healthcare revenue disappears.
Forty-five million prior authorizations move through US payers every year. About four out of five appealed denials get overturned. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) now gives payers a 7-day standard window and a 72-hour expedited window to decide, with mandatory reporting starting in the 2026 plan year. CLEAR sits underneath that whole process. Submission, payer receipt, clinical review, decision, peer-to-peer, appeal, final determination: each step gets a dual-signed (Ed25519 + ML-DSA-65) receipt built for the post-quantum era, and auditors, regulators, and appeal panels can check it offline.
High-volume or negotiated terms? Talk to Steve
What this is worth to a single payer's book of PAs
CLEAR reads events from any X12 278, FHIR PAS, or Da Vinci CRD pipeline, or wraps around the PA API gateway a payer or PA automation vendor already runs. Every step in the process turns into a dual-signed receipt that points back to the one before it. Here are the numbers a Chief Medical Officer or VP of Utilization Management would bring to the board.
A national payer running roughly five million prior authorizations a year spends around $48,000 a year in receipt fees at $0.0096 per decision. Compare that to the cost of denial rework, appeal handling, regulator penalties, and frustrated providers, which already runs into the billions. The math speaks for itself.
CLEAR is a layer of proof that sits underneath Waystar, Cohere Health, Olive AI, Myndshft, Availity, and Change Healthcare. It doesn't replace any of them. Those platforms own clinical-review automation, payer connectivity, and policy logic. CLEAR owns the signed receipt that every one of their steps should already have. UnitedHealth, Anthem, Aetna, Cigna, Humana, Centene, Kaiser, and the hospital systems and PA automation vendors that work with them keep their existing PA stack and just add a chain that shows any tampering, which auditors can check offline.
Receipt rail, not a PA platform
PA automation platforms move authorization requests through the workflow. They run clinical-review rules, route peer-to-peers, surface medical-necessity criteria, and connect to EHRs. CLEAR does the one thing they don't: it produces the signed, anchored receipt that every step in the workflow should already have. Keeping these two jobs separate is the whole point.
Every payer, provider, and PA automation vendor produces the same kind of evidence, just under different vendor names. The evidence doesn't depend on any one platform. That's what makes it hold up in front of a state insurance commissioner, a CMS auditor, an appeal panel, or a court.
How a $48,000 denied chemo PA gets reversed in four hours instead of eight weeks
Here's a real-world walk-through. A community oncologist submits a prior authorization for an outpatient infusion regimen. Estimated allowable cost: $48,000. The patient is mid-cycle, on a tight clinical clock. The standard decision window is 7 days under CMS-0057-F.
clear_pa_submit alongside the FHIR PAS Bundle. The receipt locks in pa_id, payer DID, provider DID, member DID, CPT codes, ICD-10 codes, and a SHA-256 fingerprint of every clinical attachment. Both signatures get applied. It's anchored on Base 8453.clear_decision_attest with the denial reason and a pointer back to the chain. The provider sees the receipt and pulls the chain. Every clinical document the EHR sent has a fingerprint and a timestamp that directly contradicts the denial reason.clear_p2p_attest with a fingerprint of the peer-to-peer transcript, the attending oncologist's DID, and a pointer back to the denial. The payer's medical director reviews the chain instead of a stack of faxes.clear_appeal_attest. The payer's appeal panel runs clear_chain_verify on a clean laptop with no internet connection. Ed25519 and ML-DSA-65 both check out, the chain lines up, the record matches. The decision gets overturned.Live verification: what an auditor sees
The envelope is CBOR-canonical and checks offline against the issuer's published public keys. No call to Hive is needed at audit time. The panel below is the same thing every appeal panel, NCQA reviewer, or CMS auditor sees.
k1:8c2a…kq:b71d…That panel is everything an appeal panel or a CMS auditor needs to see. No demo. No login. The evidence proves itself, and it'll still work in fifty years on a laptop with no internet.
Standards: what CLEAR adds
Every existing PA standard answers a different question. CLEAR doesn't replace any of them. It adds the signed proof that makes each one hold up after the fact.
| Standard | Coverage | What CLEAR adds |
|---|---|---|
| CMS-0057-F | 7-day standard / 72-hour expedited PA decision rule, API surface, PA metric reporting (2026 plan year) | Decision timestamps that can't be faked, and drop straight into CMS reporting |
| HIPAA 45 CFR § 164.312 | Audit controls for PHI access, modification, transmission | Signed access records, dual-signed and anchored to the chain |
| ASTP HTI-1 / HTI-2 | Information blocking + Decision Support Interventions (DSI) | Proof tied to the actual PA decision: what was shown, when, and to whom |
| X12 278 | Health Care Services Review: eligibility / utilization review request / response | The receipt rides inside 278 transactions without breaking the wire format |
| FHIR PAS / DTR / CRD | Da Vinci PA Bundle, Documentation Templates & Rules, Coverage Requirements Discovery | Receipt anchored to the PAS Bundle fingerprint, covering the whole bundle, not just metadata |
| NCQA UM 5 | Utilization management timeliness | Automatic timeliness evidence for credentialing audits, no spreadsheet rebuilding |
| Da Vinci CDex | Clinical Data Exchange between payers and providers | Proof of document delivery, tracked from the EHR to the payer's reviewer |
| ASTP USCDI v3 | Common data set for interoperability | Proof at the element level: each USCDI element is fingerprinted and signed in place |
3-step integration path
clear_pa_submit and clear_decision_attest on each lifecycle transition. Add clear_p2p_attest and clear_appeal_attest as those events occur. Chain pointers resolve automatically; the lifecycle thread builds itself.clear_chain_verify on a clean laptop with no network, walk every receipt, and the case answers itself. NCQA UM 5, CMS-0057-F reporting, and HIPAA 45 CFR § 164.312 audits resolve from the same chain without re-collection.The 11 tools
| Tool | Purpose |
|---|---|
clear_pa_submit | Submit a prior authorization with a dual-signed receipt envelope. |
clear_pa_get | Retrieve a stored PA by id. |
clear_pa_verify | Verify both signatures (Ed25519 + ML-DSA-65) on a stored PA. |
clear_decision_attest | Attest a payer decision with chain pointer to the submission. |
clear_p2p_attest | Attest a peer-to-peer with chain pointer to the decision. |
clear_appeal_attest | Attest an appeal with chain pointer to the denial. |
clear_chain_verify | Verify the full chain for a PA, from submission through final determination. |
clear_by_payer | Paginated history by payer DID. |
clear_by_provider | Paginated history by provider DID. |
clear_pricing | Read live pricing surface. |
clear_health | Health probe. |
Eleven tools, all live in production. Contact us for integration credentials and the full manifest.
The PA envelope
Every clear_pa_submit and clear_decision_attest call returns an envelope with the PA id, payer DID, provider DID, member DID, CPT codes, ICD-10 codes, a fingerprint of the clinical document, the decision, the decision timestamp, the prior attestation id, and both signatures (Ed25519 + ML-DSA-65). The signatures lock in every field. Any attempt to tamper with it breaks verification.
The envelope is CBOR-canonical. Anyone can verify it offline against the issuer's published public keys. ML-DSA-65 (NIST FIPS 204) is the post-quantum signature. Ed25519 (RFC 8032) adds classical assurance. Both have to check out for the receipt to be valid. Receipts stay valid through key rotation, thanks to a signed key history, so a 2026 PA can still be defended in a 2046 audit.
What this is not
Setting the right expectations is part of the product. CLEAR is narrow on purpose.
The signed receipt rail underneath any of those. PA automation platforms, EHRs, payer portals, claims clearinghouses, and medical-necessity reviewers all run cleaner with a dual-signed receipt under each step.
Pricing
| Tier | Rate | Includes | Commitment |
|---|---|---|---|
| Per decision Self-serve, metered | $0.0096per decision | Every PA lifecycle decision: dual-signed receipt, chain pointers, checkable offline, ready for CMS-0057-F | None. Pay as you go. |
| Volume commit Optional | from $5,000/mobundle at $0.0096/decision | Pre-committed decision volume at the same per-decision rate; overage billed at $0.0096/decision; custom SLA and NCQA UM 5 reporting | Monthly or annual |
No per-seat fees, no tier walls. Every decision is one receipt at $0.0096. Volume-commit plans start at $5,000/mo and bundle decisions at the same rate. Custom integrations into a payer's X12 278, FHIR PAS, or Da Vinci CRD pipelines, plus NCQA UM 5 reporting and CMS-0057-F PA-metric submission, are available on volume-commit plans. Settlement is USDC on Base 8453 via x402. Receipts settle in seconds. Invoicing is monthly, net-30 by default.
Field map
CLEAR gives every prior-authorization step a dual-signed receipt that drops cleanly into existing X12 278, FHIR PAS, Da Vinci CRD, and CMS reporting pipelines. Each call accepts the fields below. The envelope round-trips through standard JSON / CBOR transports via the Hive Receipt primitive.
| Field | Format | Maps to |
|---|---|---|
pa_id | UUID | Internal PA correlation id; X12 278 trace number; FHIR PAS Bundle id |
payer_did | did:hive:payer:… | Payer organization: UnitedHealth, Anthem, Aetna, Cigna, Humana, Centene, Kaiser, or a regional plan |
provider_did | did:hive:provider:… | Submitting provider organization, NPI, group TIN |
member_did | did:hive:member:… | Member identifier: not the real ID, a stand-in derived from it under HIPAA-compliant rotation |
cpt_codes | array<string> | Procedure codes: CPT / HCPCS, for example 96413, J9355 |
icd10_codes | array<string> | Diagnosis codes: ICD-10-CM, for example C50.911, Z51.11 |
clinical_doc_hash | sha256 hex | SHA-256 fingerprint of the clinical attachments bundle delivered with the PA |
decision | enum | approved, denied, pended, approved_on_appeal, denied_on_appeal, peer_to_peer_held |
decision_at | RFC 3339 | Decision timestamp: the field CMS-0057-F reporting actually asks for |
prior_attestation_id | UUID | A pointer back to the prior event in this PA's chain |
Pair this with HiveComply when SOC 2, HIPAA, or NCQA audits come up. HiveComply reads CLEAR receipts natively, so one audit covers every Hive product your company uses. Pair it with Atticus if an appeal turns into litigation.
Start in under two minutes
Mint an API key, drop the SDK into your X12 278 / FHIR PAS pipeline, and your first PA decision gets a receipt. No qualification gate, no sales rep, no demo call required.
High-volume or negotiated terms? Talk to Steve
Questions buyers actually ask
What does CLEAR attest?
Every Prior Authorization step, from submission to payer receipt, clinical review, decision, peer-to-peer, appeal, and final determination, gets a dual-signed (Ed25519 + ML-DSA-65) receipt built for the post-quantum era. Providers, payers, and regulators can check it offline.
How does CLEAR align with CMS-0057-F?
CLEAR fits into the Prior Authorization workflow that CMS-0057-F requires. Receipt envelopes drop cleanly into existing payer and provider PA pipelines and make every required step checkable.
Why does each PA decision need a receipt?
Prior auth is the single biggest source of lost revenue from denials. A dual-signed PA receipt backs up the decision in an appeal, a peer-to-peer review, or any later dispute, without redoing the underlying clinical record.
What does each receipt cost?
$0.0096 per decision, self-serve and metered with no monthly commitment. Volume-commit plans from $5,000/mo available. Settlement is in USDC on Base 8453 via x402.
How are signatures verified?
ML-DSA-65 (NIST FIPS 204) is the post-quantum signature. Ed25519 (RFC 8032) adds classical assurance. Both need to check out for the receipt to be valid. Anyone can verify it offline against the issuer's published public keys.
Is CLEAR a payer or a provider tool?
Both. CLEAR is the receipt rail underneath the PA decision, no matter which side starts it. Providers attest submission and appeal events. Payers attest receipt, review, and final determination events.
Hive runs the receipt rail underneath the broader A2A · agent-to-agent commerce category.