Model documentation belongs in the coverage file. The case file for a coverage request usually records what was decided and who signed it, even when software helped decide. It rarely records which model made the recommendation or what the model was built to do. An appeal reviewer who opens the file months later sees the decision. The machine that shaped it is invisible.
That gap matters more each year. Health plans use models to sort requests and suggest approvals. Some models estimate how long a patient will need care. The decision belongs to a person, but the model sets the starting point. A file that leaves the model out cannot show how the decision was really made.
What the file should hold about the model
Model developers already describe their models in documents often called model cards. A model card states what the model is for and how it was tested. It also describes where the model performs poorly. The coverage file does not need the whole card. It needs the parts that explain this decision.
- Name and version. The exact model and release that ran on this case, so the same model can be found later.
- Intended use. What the model was built to do, in a sentence, so a reader can tell whether this case fell inside it.
- Known limits. The populations or conditions where the model’s testing showed weaker performance.
- Inputs used. The data the model read for this case, with the date each item was current.
- Output. What the model recommended and any score it attached.
- Human action. What the reviewer did with the recommendation, and why if the reviewer departed from it.
Most of that information already exists somewhere. The model’s version sits in a deployment log. Its intended use and limits sit in the vendor’s documentation. The inputs and output sit in the system that ran it. Putting them in the case file is a matter of linking records that a plan already keeps.
A coverage file that names the reviewer but not the model tells only half the story.
The rules already point there
Federal claims rules for employer plans give a claimant the right to documents relevant to a claim. Relevant documents include records generated in the course of making the decision, under 29 CFR § 2560.503-1. That holds whether or not the plan relied on them. A model’s recommendation on a case is generated in the course of the decision. A plan that cannot say which model produced it will struggle to produce it at all.
States are asking for the same information from another direction. California requires that an AI tool used in utilization review be open to inspection by the state’s managed care regulator for audits and compliance reviews, according to Sheppard Mullin. The tool’s outcomes must also be reviewed periodically. Our review of state utilization review laws in 2026 found more states adding disclosure and reporting rules for AI in review.
Courts are asking too. In lawsuits over algorithmic denials, the question has often turned on what insurers told members about how decisions are made, as our piece on AI denial litigation described. A plan with model documentation in each file can answer that question case by case.
Our state and federal review of health AI found the states writing the thicker rulebook. Model documentation in the file is one way for a plan to meet many of those rules at once, because it answers the question each rule asks in a different form.
Why it helps everyone
The file serves the appeal first. A reviewer who sees that a model was built for a different population can weigh its recommendation accordingly. A clinician who appeals can ask a precise question about a named model version instead of a general one about software.
It serves the plan’s own oversight. Our piece on auditing payer AI like a reviewer argued that a model should be checked the way a human reviewer is checked. A file that records the model version on every case lets a plan compare outcomes across versions. If overturned denials cluster on 1 release, the plan can see it.
It also helps when a model changes. Vendors update models, and a decision made in March may have come from a different release than one made in June. The file should say which.
It serves the vendor relationship as well. A plan that records which model ran can hold the vendor to the performance the vendor claimed. A plan that records nothing has to take the vendor’s word.
There is a cost, and it is small. The information already exists in separate systems. The work is to attach it to each case at the moment of decision, so nobody has to rebuild it later. Our piece on denial audit trails described how that kind of record can be written as the decision happens.
Redlake builds tools that health plans use in utilization review. A machine can say yes, but only a person can say no. Every recommendation our tools make shows its reasons, and every decision can be reconstructed. Naming the model in the file is part of showing the reasons. A recommendation whose source is unknown is a reason nobody can check.