Prior-authorization AI

What this is

Prior-authorization (PA) AI typically does two things: classifies medical-necessity criteria fit (approve / further-review / decline) from a submitted treatment request, and drafts the narrative justification accompanying the submission. Volume at healthtech-RCM SMB scale runs 10k–500k decisions per month across customers.

The regulatory perimeter is dense: HIPAA §164.312(b) audit controls for any system handling ePHI; payer contracts often require demonstrable consistency in PA criteria application; state laws (CMS Interoperability + Prior Authorization Final Rule effective 2026-2027, California SB 1120 2025, Texas SB 1188 2023) add transparency + appeals-rights requirements that fold back into the AI's operating envelope.

Promethean records each PA decision as an L12 entry. The closed-enum output schema (approve / further-review / decline + criteria-matched array) bounds the AI; the reviewer-gate primitive captures the revenue-cycle specialist or clinician sign-off; the chain export is what a provider's denial-management team needs when contesting a payer's adverse determination.

How Promethean addresses this

• Per-decision medical-necessity criteria evidence

  The spec's outputSchema enumerates the criteria checked; each L12 entry's outputCanonicalHash binds the criteria-matched vector. A denial appeal can be answered with 'these specific criteria were evaluated, this was the outcome'.

• Clinician / RCM-specialist sign-off evidence (CA SB 1120 utilization-review human-review rule)

  Reviewer-gate set to always-human for any decline; the L12 entry records the reviewer identifier + verdict. Over the audit window, the override rate proves human review was meaningful. Texas SB 1188 (89R, 2025) layers on top for any diagnostic-AI use case, separately from the PA flow.

• CMS PA Rule rationale requirement

  Each PA decision is committed with the rationale field (length-bounded by schema); outputCanonicalHash binds the rationale to the entry. The rationale is retrievable for FHIR PA API responses + appeals workflows.

• HIPAA Audit Controls (§164.312(b))

  L12 chain provides hardware-and-software-enforced recording: the substrate emits per-decision entries; the operator cannot disable emission. Per-entry Ed25519 attestation provides integrity. Combined with operator-side SIEM (which Promethean doesn't replace), this satisfies the audit-controls implementation specification.

• Multi-payer-customer tenant isolation

  Healthtech-RCM SMBs typically serve many provider customers; R4 tenantId on each L12 entry lets you ship per-customer audit bundles filtered to their decisions only. Production tier and above.

What this looks like in practice

Hypothetical: state-AG inquiry on AI-driven PA denials

A state Attorney General announces an inquiry into AI-driven prior-auth denials following patient-advocacy complaints. The AG demands: 'Provide per-decision evidence for all AI-touched PA denials in 2026 affecting CA residents. Demonstrate clinician review per CA SB 1120. Demonstrate the criteria-matching logic was the documented one.' Without Promethean: months of cross-referencing claims-system exports with internal AI logs + a defensive narrative. With Promethean: chain-export filtered to recordedAtIso 2026 + outputCategory=decline + tenantId where the patient's payer matches the CA cohort; reviewer-verdict shows clinician sign-off on 100% of declines (CA SB 1120 satisfied); specHash sequence shows two documented model versions with documented transition dates. The AG accepts the chain output + handoff packet; inquiry concludes with corrective recommendations rather than enforcement action.

Frequently asked