Prior authorization needs a receipt neither side can rewrite. Since January 2026, payers covered by CMS’s interoperability and prior authorization rule have had to decide standard requests within 7 calendar days and expedited requests within 72 hours. Those clocks run from the payer’s receipt of the request. In most programs, the only record of that receipt is the payer’s own.
Anyone who has worked a prior authorization queue knows the dispute that follows. The office says it sent the request on Monday. The plan’s system shows it arriving on Thursday, or not at all. Each side has a log, and each log is kept by the party it protects. A shared ledger of receipts would give both sides the same record of when a request arrived, without putting the request itself on the ledger.
The clock depends on who logged it
CMS’s 2024 rule set the 72-hour and 7-day limits for Medicare Advantage plans and Medicaid programs, among other payers, starting in 2026. Our analysis of the decision timeframes covers how the clocks work. In Medicare Advantage, the standard clock runs 7 calendar days “after receiving the request,” in the words of 42 CFR § 422.568. A plan that misses it has made a decision anyway. Under the same section, a failure to give timely notice “itself constitutes an adverse organization determination and may be appealed.” A deadline with that consequence is only as firm as the record of receipt.
That record is fragile. Requests still arrive through portals and fax, and many pass through a clearinghouse or a delegated review vendor before the plan’s own system sees them. Each handoff is a place where a request can wait without a timestamp anyone else can see. When the dates disagree, the provider has a fax confirmation or a portal screenshot. The plan has its intake log. Neither proves much to the other.
The Prior Authorization API that payers must run by January 2027 will help. A request sent through the API carries machine timestamps, and CMS proposed in April 2026 that payers report how much the API is used, according to its fact sheet. The timestamps still live in the payer’s system, though. Electronic adoption for medical prior authorization was 40% in 2024, as our review of HTI-4 noted, so other channels will carry requests for years.
A receipt neither side controls
A permissioned ledger can hold receipts without holding requests. The design needs a few rules.
- The submitter writes first. When a provider sends a request, its system computes a salted fingerprint of the request and writes it to the ledger with a timestamp. The fingerprint identifies that exact version of the request and reveals nothing about the patient.
- Every handoff writes its own entry. A clearinghouse that forwards the request records the same fingerprint when it passes it on. So does a delegated vendor. The plan records it at intake.
- Status changes are entries too. Each change in status, from a pend to a final decision, references the original fingerprint. The ledger becomes a timeline of the request that every participant can read.
- The request stays off the ledger. Clinical content travels the way it does today, through the API or the existing channel. Only fingerprints and timestamps are shared.
Hyperledger Fabric, the permissioned ledger we examined in our analysis of ledgers for PHI, already works this way for private data. The data goes only to the organizations authorized to see it. A hash of the data is written to the ledgers of every peer on the channel, and Fabric’s documentation says the hash “serves as evidence of the transaction and is used for state validation and can be used for audit purposes.” Private data can also be purged, which fits the approach in our piece on crypto-shredding.
A clock that only one side can read is not a shared deadline.
With a shared timeline, the Monday versus Thursday argument changes shape. If the provider’s entry and the clearinghouse’s entry both show Monday, the delay happened inside the plan or its vendor. The ledger shows where. If the provider never wrote an entry, the plan’s position is stronger. Either way the question becomes what happened at a specific handoff, which is a question both sides can answer.
What a ledger does not fix
A receipt proves when a request arrived. It does not prove the request was complete. A plan can still say the documentation was missing, and the provider can still disagree. The fingerprint narrows that argument, because both sides can show which version of the request was sent and which version was received.
A ledger is also not the only way to get a trustworthy receipt. Between 2 parties, a signed acknowledgment does most of the work. If the plan’s system returns a digitally signed receipt with a timestamp the moment a request arrives, the provider holds proof the plan cannot later revise. The ledger earns its cost when more than 2 organizations touch a request, or when no single party should be trusted to keep the timeline.
The ledger also creates metadata of its own. Fingerprints reveal nothing about a patient, but entries show which organizations exchanged requests and when. Channel membership should be limited to the organizations on each request path, and entries should identify organizations rather than clinicians.
Governance is the hard part. Someone has to decide who runs nodes and who pays for them. Someone also has to decide what happens when an entry is wrong. A sensible start is small. A plan and its delegated vendors could share receipts first, then add the provider groups that send them the most requests.
Where Redlake stands
Redlake builds tools that health plans use in utilization review. Our rules require that every decision can be reconstructed, and reconstruction starts with when the request arrived. A decision record that begins with a disputed receipt is weak from its first line.
We would rather give providers a receipt they can verify than one they have to trust. Signed acknowledgments are the first step, and they fit inside the API exchange that arrives in 2027. A shared ledger is the next step for requests that pass through several hands. The same logic drives our view of tamper-evident access logs. A record is only as good as the hardest party to convince.