Publish coverage criteria the way engineers publish code. Coverage criteria are the rules that decide whether a requested service is approved, down to which diagnoses qualify and which findings must be documented. They change as evidence changes. Yet the physicians whose requests are judged against them often cannot tell which version applied to a given case or what changed last quarter.
Software engineers solved a version of this problem long ago. Rules that many people depend on are published with version numbers and change logs. Coverage criteria deserve the same treatment.
What the rules require now
Medicare Advantage set a baseline in 2024. Under 42 CFR § 422.101(b)(6), plans may use internal coverage criteria only when Medicare’s own criteria are not fully established, and the criteria must rest on current evidence in widely used treatment guidelines or clinical literature. When plans use them, the regulation requires them to make several things publicly accessible.
- the internal coverage criteria in use and a summary of the evidence considered in developing them
- a list of the sources of that evidence
- an explanation of the rationale supporting the criteria
Where criteria supplement general Medicare provisions, the plan must identify the provisions being supplemented and explain how the additional criteria provide clinical benefits.
CMS’s interoperability and prior authorization rule adds a second layer. By January 2027, impacted payers’ Prior Authorization APIs must be able to indicate whether authorization is required and identify the documentation requirements. Those are the pieces that let a provider’s system check a request before it is sent, as we described in our piece on retiring the fax.
Those requirements make criteria visible. They do not yet make criteria easy to use or to hold to account.
What code-style publishing adds
The habits that make shared software reliable translate directly.
- Version numbers and effective dates. Every set of criteria should carry a version and the date it took effect, and every decision should record which version it applied. Without that, a physician appealing a denial cannot know whether the plan used the rule posted today or the one posted when the request was made.
- Change logs. Each new version should come with a plain account of what changed and on what evidence, published before the change takes effect. A physician should not discover a new documentation requirement through a denial.
- Test cases. Criteria should be published with worked examples, synthetic patients whose records meet or fail each criterion, along with the expected result. Test cases show providers exactly what documentation a rule expects. They also let a plan check whether its reviewers, and any software that assists them, apply the rule consistently.
- Machine-readable forms. Criteria expressed in structured formats, such as the questionnaires and logic used in the Da Vinci documentation templates that CMS recommended for prior authorization APIs, can run inside a provider’s electronic health record to check a request before it is submitted.
- A way to report problems. Software projects take bug reports. A plan should give providers a clear channel to report a criterion that is ambiguous or out of step with the evidence it cites, and should answer those reports.
A published criterion built this way could fit on a short page. It would name the service and codes it covers and give the current version with its effective date. The numbered criteria would follow with their evidence, then a change log of earlier versions and 3 or 4 worked cases showing requests that meet the criteria or fall short for different reasons. A link would lead to the structured version for electronic use. None of that is exotic. Most of it already exists inside plans. It is simply not published together.
If a rule can change without a version number, no one can say which rule decided their case.
Why it matters for decisions
Treating criteria as versioned, tested artifacts changes how decisions are made and reviewed.
It makes decisions reconstructable. A decision record that names the criteria version and the facts that met or missed each criterion can be checked years later against the rule as it stood that day, whether by an appeals reviewer or a court.
It makes review consistent. Test cases become calibration tools. If 2 reviewers reach different answers on the same synthetic case, the plan has found a training need or an ambiguity in the rule before it affects a real patient. The same cases can test software that assists review, which is the kind of validation regulators increasingly expect as states adopt rules on AI in coverage decisions like those we described earlier this month.
It reduces avoidable denials. Many requests fail not because the patient does not qualify but because the documentation does not show it. When providers can see the test cases and run the criteria against their own records before submitting, more requests arrive complete.
It builds trust in a narrow but real way. A physician who can read the change log and test a case may still disagree with a criterion. But the disagreement is about the medicine, which is where it belongs, rather than about whether the plan is playing fair.
What we build for
We build tools health plans use in utilization review, and our rules depend on criteria being treated this way. Every recommendation shows its reasons, in the form of the criteria applied and the facts from the record that met or missed them. The criteria have to be specific enough, and versioned well enough, for that to mean something. Every decision can be reconstructed, which requires knowing exactly which version of which rule was in force when the decision was made.
We think plans should go beyond what the regulation requires. That means versioned criteria with effective dates, and change logs published before a change takes effect. It also means test cases for every criterion and a structured version wherever providers can use one.
A machine can say yes when a request clearly meets a well-specified rule. Only a person can say no. Both work better when everyone can see the rule.