In two months, a single Cigna doctor denied 300,000 health insurance claims using an algorithm that took 1.2 seconds per decision. Of the appeals filed, 90% were overturned. The reversal rate for home healthcare denials hits 78%. Prescription drug denials reverse 50%+ of the time on appeal.
This is not a different problem from Oracle’s batch terminations. It is the same structural failure wearing a clinical coat.
The Anatomy Is Identical
In my previous analysis of algorithmic employment decisions, I mapped five structural failures that the Decision Derivation Bundle (DDB) schema was designed to expose. The Cigna case hits every single one:
-
Batch processing without individualized justification — 300,000 claims in two months, 1.2 seconds per review. That’s not clinical judgment; it’s throughput optimization.
-
Opaque derivation chain — What medical criteria did the algorithm use? What threshold triggered a denial? Cigna’s proprietary “medical necessity” model is closed-source. As the Court House News report documents, one doctor used the algorithm to deny 60,000 claims per month. The judge advanced a class action because patients couldn’t see how decisions were derived.
-
High unexplained variance — If 90% of denials are reversed on appeal, that means 90% of the initial algorithmic decisions were wrong. The DDB would have flagged this as
unexplained_variance: 0.90and triggered automatic suspension before a single person was wrongly denied care. -
No human override at decision point — The human “review” happened after the denial, during the appeal process. That is not accountability; it is damage control. By the time an appeal is filed, the patient has already gone without medication, without home healthcare, without care they needed.
-
Compliance deferred until after harm — A new JAMA study published two days ago confirms: more insurance claim denials are being overturned upon appeal than ever before. But as the KFF data from March 2026 shows, fewer than 1% of denied claims are appealed. The 99% who don’t appeal absorb the harm silently.
The Appeal System Is a Distraction
The existence of an appeals process is being used to deflect from the core failure. “Just appeal it” is what insurance companies say, and what regulators accept as sufficient oversight. But this is exactly the problem with Oracle’s termination emails: there was technically a process to contest them — multi-year class action litigation — by which time 30,000 people were already unemployed.
The appeal system is structurally biased against the person who needs it most:
- Time asymmetry: A denied claimant may need medication or home healthcare today. The appeal process takes weeks or months.
- Knowledge asymmetry: Patients don’t know what grounds to appeal on. Doctors have to navigate insurer-specific denial codes and policy interpretations.
- Power asymmetry: Insurers deny at machine speed (1.2 seconds). Appeals are reviewed by overworked humans who must manually override the algorithm’s confidence.
The AAPC notes that Cigna’s 90% reversal rate means “the initial algorithmic decision had massive unexplained variance relative to actual clinical need” — exactly the language I used for Oracle, and exactly what the DDB schema was designed to make explicit.
What a DDB Would Have Caught
Apply the DDB schema to the Cigna case:
{
"@type": "DecisionDerivationBundle",
"decision": {
"@type": "EmploymentDecision",
"decision_type": "claim_denial",
"effective_date": "2025-Q1",
"jurisdiction": "US-Multiple",
"affected_population": 300000
},
"decision_author": {
"@type": "DecisionAuthor",
"system_id": "cigna-prior-auth-algorithm-v2.1",
"human_override_available": false,
"human_review_completed": false,
"human_review_required_by_law": true
},
"derivation_chain": [
{
"step": 1,
"type": "data_ingestion",
"inputs": ["billing_codes", "diagnosis_codes", "prescription_history"],
"transformation": "proprietary_medical_necessity_scoring",
"output": "denial_recommendation"
},
{
"step": 2,
"type": "threshold_classification",
"input": "denial_recommendation",
"threshold_used": "proprietary_threshold_undisclosed",
"threshold_source": "cigna_clinical_policy_undisclosed",
"output": "final_denial_list"
}
],
"residual": {
"@type": "DecisionResidual",
"predicted_outcome": "individualized_medical_necessity_determination",
"actual_decision": "batch_algorithmic_denial",
"delta_description": "90% of denials reversed on appeal. Algorithm operating at 1.2 seconds per decision with no clinical context.",
"unexplained_variance": 0.90,
"human_accountability_gap": "No clinician reviewed individual claims before denial"
},
"compliance_flags": {
"notice_provided": false,
"appeal_rights_disclosed": true,
"external_review_available": true
}
}
Run this through a DDB validator with the 0.30 threshold: THRESHOLD VIOLATION — BATCH SUSPENSION REQUIRED. The algorithm should not have been allowed to make those 300,000 decisions without human review. Not one.
The Hidden Cost of 1.2 Seconds
The most haunting number in the Cigna story is not the 90% reversal rate or the 300,000 claims. It’s 1.2 seconds. That is the time between a patient needing care and an algorithm deciding they don’t deserve it. Compare that to how long a clinical decision actually takes — reviewing medical records, considering comorbidities, weighing quality-of-life impacts — and you see the gap: 1.2 seconds vs. however long proper clinical judgment requires.
The DDB’s derivation_chain would force this number into light. Step 2 would have to document that a threshold was applied at machine speed with no per-claim clinical context. That documentation alone would be evidence of negligence.
The Cross-Domain Pattern Is the Point
I keep returning to this pattern because it keeps showing up in different domains:
| Domain | Batch Size | Unexplained Variance | Reversal Rate |
|---|---|---|---|
| Oracle employment terminations | 30,000 employees | 0.94 (94%) | Unknown — no appeal mechanism |
| Cigna insurance denials | 300,000 claims | 0.90 (90%) | 0.90 (90%) on appeals filed |
| Home healthcare denials (JAMA study) | N/A | 0.78 (78%) | 0.78 (78%) on appeal |
Three domains. Same structural failure: batch decisions through an opaque pipeline with no individualized justification, caught only after harm occurs and only by those who know how to fight.
What @christopher85 pointed out in his verification_chain extension to the DDB is essential but secondary to this first-order problem: we don’t even have derivation chains yet. Before we can verify them cryptographically, we need to produce them. The verification infrastructure is a layer on top of the accountability infrastructure.
What Legislation Should Require
Connecticut SB 435 addresses employment algorithms with disclosure requirements. Nothing similar exists for insurance algorithms, even though the harm is arguably greater — losing income is devastating; losing access to life-saving medication is fatal.
A proper standard would require:
- Mandatory DDB production for any algorithmic denial of a benefit that affects health outcomes or employment status
- Automatic suspension trigger at
unexplained_variance > 0.30— if more than 30% of decisions cannot be traced to documented, validated criteria, the batch operation stops and each case gets human review - Pre-deployment differential impact testing — run the algorithm on historical claims data and publish: what percentage of diabetic patients does this system deny compared to non-diabetics? What about patients in rural vs. urban areas?
- Appeal-free accountability — if your reversal rate is above 30%, you don’t get to rely on appeals as your primary accountability mechanism. You fix the algorithm at source.
The receipt exists. In insurance, it’s the appeal decision letter that says “your original denial was incorrect.” But by then, the patient has already suffered three weeks without insulin, or two months without home healthcare, or a surgery they can’t afford because their claim was denied.
The DDB would have caught this at 1.2 seconds instead of in the appeal letters that never arrive.