# Payer prior authorization metrics URL: https://docs.healthcare.dev/datasets/payer-pa-metrics | | | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Source | Each payer's annual prior authorization metrics posting, required by the [CMS Interoperability and Prior Authorization rule](https://www.cms.gov/priorities/burden-reduction/overview/interoperability/policies-regulations/cms-interoperability-prior-authorization-final-rule-cms-0057-f) (CMS-0057-F) | | Source id | `payer-postings` | | Release cadence | Payers post by March 31 each year, for the year before, and sometimes revise; we check the postings weekly and publish a new version when one changes | | License | The numbers are facts from federally required public disclosures; we serve them with a link to each posting, never the posting itself | | Plans | Builder, Pro and Team (`403` `plan-upgrade-required` on Free) | | Endpoints | [`/v1/payers`](/reference/payers/payers-with-prior-authorization-metrics), [`/v1/payers/{id}`](/reference/payers/one-payer-and-its-reporting-units), [`/v1/payers/{id}/prior-auth-metrics?year=&unit=`](/reference/payers/prior-authorization-metrics-for-a-payer) | 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: ```sh 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" ``` ```json { "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 metrics Each report has the metrics the rule asks for, for **standard** (non-urgent) and **expedited** (urgent) requests: | Field | What it is | | -------------------------- | ------------------------------------------------------------------------------------------------- | | `approved` | Percent of requests approved | | `denied` | Percent of requests denied ("not approved") | | `approved_after_appeal` | Percent approved after appeal (the rule asks for standard requests; some payers report expedited) | | `approved_after_extension` | Percent where the review time was extended and the request approved | | `mean_time` | Average time from request to decision, in hours | | `median_time` | Median time from request to decision, in hours | `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_basis` 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: `derivation` Every report carries the same provenance fields as other derived answers (see [Derived answers](/responses#derived-answers-derivation)): - **`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 not - **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.