Payer prior authorization metrics

Since March 31, 2026, Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and issuers of qualified health plans on the federal exchanges post their prior authorization metrics for the year before on their websites. Each posting covers one reporting unit: a Medicare Advantage contract (H1036), a state's Medicaid or CHIP fee-for-service program, one Medicaid or CHIP managed care plan, or a QHP issuer. Formats vary a lot from payer to payer; we read each one into the same fields.

Find a payer, then ask for its metrics:

curl "https://api.healthcare.dev/v1/payers?q=humana" -H "Authorization: Bearer $HDEV_API_KEY"
curl "https://api.healthcare.dev/v1/payers/humana/prior-auth-metrics?unit=H1036" \
  -H "Authorization: Bearer $HDEV_API_KEY"

{
  "data": {
    "payer": { "id": "humana", "name": "Humana" },
    "year": 2025,
    "years_available": [2025],
    "note": "Values are as the payer reported them in its annual public posting ...",
    "reports": [
      {
        "payer_id": "humana",
        "payer_name": "Humana",
        "unit": {
          "key": "H1036",
          "type": "ma_contract",
          "id": "H1036",
          "name": null,
          "state": null,
          "segment": null
        },
        "year": 2025,
        "report_status": "available",
        "standard": {
          "approved": {
            "value": 92.98,
            "unit": "percent",
            "count": 1212346,
            "denominator": 1303837,
            "denominator_basis": "total_requests",
            "as_reported": null
          },
          "approved_after_appeal": {
            "value": 55.73,
            "unit": "percent",
            "count": 870,
            "denominator": 1561,
            "denominator_basis": "total_appeals",
            "as_reported": null
          },
          "mean_time": {
            "value": 24,
            "unit": "hours",
            "count": null,
            "denominator": null,
            "denominator_basis": null,
            "as_reported": "1 day(s)"
          },
          "...": "..."
        },
        "expedited": {
          "approved_after_appeal": { "value": null, "not_reported_reason": "not_reported" },
          "...": "..."
        },
        "all_requests": {
          "approved_after_extension": { "value": null, "not_reported_reason": "not_reported" }
        },
        "items_requiring_pa_url": "https://www.humana.com/pal",
        "confidence": 1,
        "derivation": "source_stated",
        "evidence": [
          {
            "url": "https://assets.humana.com/is/content/humana/Humana_H1036_Prior_Auth_Metrics_PlanYear2025pdf",
            "anchor": "page=2"
          }
        ],
        "as_of": "2026-10-25T05:30:00.000Z"
      }
    ]
  }
}

Without year, you get the latest year the payer posted; years_available lists the others. Without unit, you get every unit we hold for that payer and year, ordered by unit key. Use GET /v1/payers/{id} to see the units and their years first.

The metricsCopy Anchor Link

Each report has the metrics the rule asks for, for standard (non-urgent) and expedited (urgent) requests:

all_requests.approved_after_extension is the extension rate when a payer reports it for standard and expedited requests together instead.

Every metric is either a value or a gap, never an estimate:

• A value: { value, unit, count, denominator, denominator_basis, as_reported }. unit is percent (0 to 100; a payer that writes 0.9036 is stored as 90.36) or hours (days are converted at 24 hours; as_reported keeps the payer's own wording, such as 1 Days 6 Hours, 5.8 days or 9 hour(s)). count and denominator are the payer's own counts, when it gives them.
• A gap: { value: null, not_reported_reason }. not_reported means the posting doesn't give it; not_applicable means the payer says it doesn't apply (for example, it never extends review times); unparseable_pending_review means we couldn't read it reliably yet (see below).

What a percentage is out of: denominator_basisCopy Anchor Link

Payers don't all divide by the same thing, so each percentage says what it is out of: total_requests (all standard, or all expedited, requests), total_requests_all_priorities (standard and expedited together), total_appeals (only requests that were appealed), extended_requests (only requests whose review time was extended) or not_stated. CMS's template divides the extension rate by all requests; several payers divide it by the extended requests only, which gives a much larger number for the same events. Compare like with like.

How each report was read: derivationCopy Anchor Link

Every report carries the same provenance fields as other derived answers (see Derived answers):

• derivation: source_stated when the numbers were read directly from the posting by fixed rules, and passed our checks (approved plus denied at most 100%, counts no larger than their totals, units stated, the right year and unit); reviewed when a person checked them against the posting.
• confidence: 1 for both; 0 while a report is pending.
• evidence: the payer's posting (file or page) and where in it the unit's numbers are.
• as_of: when the version of the posting the values come from went live.

A posting we can't read reliably by rules, or whose numbers fail a check, is never published as is: it waits for a person, and the report shows report_status: pending_review with every metric null (unparseable_pending_review) until then. The values a person checked appear in the next daily update, with derivation: reviewed. When the payer revises its posting, we read the new version afresh.

What it is notCopy Anchor Link

• Not audited. Values are as each payer reported them. Payers count requests, round and label differently; show the payer's posting (evidence) with any comparison.
• Not the list of services that need prior authorization. Postings include or link that list; we give the payer's link in items_requiring_pa_url (or the posting itself, when the list is in it), never the list.
• Not every payer. Some postings can't be read by an automated client or ask not to be crawled, and we leave those out rather than work around them. GET /v1/payers lists the payers we hold.