Real-time prior authorization is a data contract. In June 2025, the insurers behind the industry pledge said that “in 2027, at least 80 percent of electronic prior authorization approvals (with all needed clinical documentation)” would be answered in real time. The words in parentheses carry the commitment. A plan can answer in seconds only when a request arrives with the data its rules need, and today only the plan knows what that data is.
That makes the 80% target hard to check. If each plan defines “all needed clinical documentation” privately, service by service, providers cannot tell in advance whether a request qualifies. The public cannot tell afterward whether the target was met. The condition should be published as a contract, with the data elements that make a request complete on one side and the plan’s promise of an answer on the other.
What the pledge counts
The AHIP announcement set the target for approvals, not for all requests. That is the right design. An automated system can safely say yes when the record meets the criteria. A denial needs a clinician’s judgment and should take longer. Our review of the pledge found that the plans have so far reported a single measured result, a modeled cut in the number of services that need authorization.
The real-time commitment will be harder to verify than the cut in scope. Its numerator is approvals answered in real time. Its denominator is electronic approvals that came with all needed documentation. The plan defines both, and the plan decides which requests were complete. A plan could reach 80% honestly by building fast automated approvals. It could also reach 80% by defining completeness so narrowly that only the easiest requests count.
The pledge also sets the target alongside a separate commitment to standardize electronic prior authorization on FHIR APIs by January 1, 2027. CMS requires most of the payers it regulates to run a Prior Authorization API by the same month, under its 2024 rule. The plumbing for real-time answers is arriving on schedule. The terms that decide when a request deserves one are not public.
Write the contract down
A data contract is a published promise between 2 systems. It says what one side will send and what the other will do when it arrives. For real-time prior authorization, a contract for each service would hold 5 things.
- The service and its codes. The contract names the procedure or item and the codes it covers, so both sides know when it applies.
- The required data, tied to criteria. Each required element maps to a criterion in the plan’s policy and to a standard FHIR element an EHR can supply. A requirement that cannot be traced to a criterion does not belong in the contract.
- The promise. When every element is present and the criteria are met, the plan returns an approval through the API while the order is still open. When an element is missing or a criterion is not met, the request goes to review under the normal clock of 72 hours or 7 days.
- A version and an effective date. Plans change their rules. The contract changes with them, with notice, so a request is judged against the version in force when it was sent.
- Measures for both sides. The plan reports the share of complete requests it answered in real time. It also reports the share of requests that arrived complete, so a gap can be traced to the side that caused it.
If a plan alone decides what counts as complete, it alone decides whether it met the target.
The Da Vinci guides already have places for this content. Coverage discovery can tell the EHR, at the moment of the order, which documentation the plan needs. The documentation template can collect it, filling in what the record holds. The submission carries it to the plan. HTI-4 certified the provider side of that exchange, as our analysis of HTI-4 described. The contract is the content those guides would carry, written where providers can read it before they build to it.
Both sides of the contract
A contract binds the provider as well as the plan. A request missing a required element is not eligible for a real-time answer, and the contract says so in advance. That is fairer than the current arrangement, where a provider learns what was missing only when a request is pended. It also gives provider organizations a target. A practice that knows which 6 data elements earn a real-time answer for a common imaging study can build its order sets to capture them.
The 2 measures together would show where the work is. If complete requests are answered in real time but few requests arrive complete, the fix is in data capture. EHRs can help there. If complete requests still wait for a person, the fix is in the plan’s automation. Today neither side can see the other’s half of the problem.
There are limits. Some criteria depend on clinical judgment that no data element captures, such as whether conservative treatment was adequate for a particular patient. Those services may never be candidates for a real-time answer, and the contract should say that plainly instead of promising what it cannot deliver. Contracts also take work to maintain. A plan with thousands of codes on its prior authorization list will need to start with its highest-volume services. A contract can also be gamed from the provider side, if required fields are filled without the clinical facts behind them. Sampled audits of real-time approvals keep both sides honest.
Where Redlake stands
Redlake builds tools that health plans use in utilization review. Our first rule is that a machine can say yes, but only a person can say no. Real-time approvals fit that rule exactly. They are automated yeses for requests that meet published criteria, and everything else goes to a clinician.
Our second rule is that every recommendation shows its reasons. A data contract is those reasons, published before the request instead of after the decision. We have argued that plans should publish coverage criteria like code, versioned and testable. Real-time prior authorization is where that argument pays off. The pledge’s 80% target is a good one. It will mean more when providers can read the terms it is measured against.