Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt

Use this file to discover all available pages before exploring further.

Feature ID: PM-10
Status: ✅ Implemented
Last Verified: 2026-02-22
Spec Reference: PM-10-prior-authorization-management.md
Last Updated: 2026-02-22

​
Table of Contents

​
Overview

PM-10 provides prior authorization (PA) request creation and tracking, status lifecycle (draft → submitted → pending → approved/denied/appealed/expired/cancelled), AHCCCS PA rules (e.g. BHRF initial 5 days for urgent), authorization vs. used units/days tracking, concurrent review and denial/appeal workflow, and readiness for FHIR PA API (Da Vinci CRD/DTR/PAS) when payers expose APIs. It depends on PM-01 (patient), PM-02 (payer/auth requirements); integrates with PM-08 (claim scrub auth verification), CL-16 (Da Vinci PAS), and PF-10 (expiration/renewal alerts).

​
Quick Reference

ItemValue
Core tablespm_prior_authorizations, pm_auth_reviews
Key dependenciesPM-01, PM-02, PM-08, CL-16, PF-10
Required permissionspm.prior_auth.view, pm.prior_auth.create, pm.prior_auth.submit, pm.prior_auth.appeal, pm.prior_auth.edit
RLS helperpm_has_org_access(organization_id, auth.uid())
Child INSERT helperpm_prior_auth_can_insert_review(authorization_id, auth.uid())

​
Integration Points (from Spec)

DependencyPatternPurpose
PM-01 (Patient Registration)FKpatient_id references pm_patients(id)
PM-02 (Insurance & Eligibility)FK / Datapayer_id references pm_payers(id); payer-specific auth rules
PM-08 (Claims)Data / APIAuth verification during claim scrubbing; used_units updated when claims post
CL-16 (FHIR Interoperability)APIDa Vinci PAS for FHIR-based prior authorization when payers expose APIs
PF-10 (Notifications)EventExpiration and renewal alerts for PA

​
API / Data Contracts

​
PM-08 → PM-10: Authorization Verification at Claim Scrub

Pattern: SECURITY DEFINER read
Direction: PM-08 reads pm_prior_authorizations to verify active authorization during claim scrubbing. 
-- Claim scrub checks active authorization for patient/service/date
SELECT id, authorization_number, status, approved_units, used_units,
       approved_start_date, approved_end_date
FROM pm_prior_authorizations
WHERE organization_id = p_org_id
  AND patient_id = p_patient_id
  AND status = 'approved'
  AND approved_start_date <= p_service_date
  AND approved_end_date >= p_service_date
  AND deleted_at IS NULL
LIMIT 1;
Response:
  • If found: claim passes auth check; used_units may be incremented on claim payment.
  • If not found: claim flagged with scrub warning “No active authorization found.”

​
PM-10 → PM-08: Used Units Update

Pattern: Application-level update
Direction: When a claim referencing a PA is paid (PM-09 payment posting), used_units on the PA is incremented. 
// In payment posting flow
await supabase
  .from('pm_prior_authorizations')
  .update({ used_units: newUsedUnits })
  .eq('id', authorizationId)
  .eq('organization_id', orgId);

​
CL-16 (Da Vinci PAS): FHIR PA API

Status: 📝 Planned
Pattern: Outbound FHIR R4 API
Direction: PM-10 submits PA request to payer via Da Vinci PAS when payer exposes FHIR API. Standards:
  • Da Vinci CRD STU 2.0.1: Coverage Requirements Discovery
  • Da Vinci DTR STU 2.0.0: Documentation Templates and Rules
  • Da Vinci PAS STU 2.1: Prior Authorization Support
Contract: TBD per payer API availability. Will map pm_prior_authorizations fields to FHIR Claim resource with use: preauthorization.

​
Event Contracts

​
PM-10 → PF-10: Authorization Expiration Alert

Channel: pm_events
Event: prior_auth_expiring
Status: 📝 Planned 
{
  event: 'prior_auth_expiring';
  publisher: 'PM';
  subscriber: ['PF'];
  payload: {
    authorization_id: uuid;
    authorization_number: string;
    patient_id: uuid;
    approved_end_date: date;
    days_until_expiry: number;
  };
  metadata: {
    organization_id: uuid;
    timestamp: timestamptz;
  };
}
Trigger: Cron edge function checks PAs where approved_end_date is within configured alert window (default: 30, 14, 7 days).

​
PM-10 Status Transition Events

Channel: pm_events
Events: prior_auth_submitted, prior_auth_approved, prior_auth_denied
Status: ✅ Implemented (client-side publishEvent() in usePriorAuthorizationMutation) 
// Published on status transitions
{
  event: 'prior_auth_submitted' | 'prior_auth_approved' | 'prior_auth_denied';
  publisher: 'PM';
  subscriber: ['CL', 'PM'];
  payload: {
    authorization_id: uuid;
    patient_id: uuid;
    payer_id: uuid;
    status: string;
    service_type: string;
  };
  metadata: {
    organization_id: uuid;
    user_id: uuid;
    timestamp: timestamptz;
  };
}
Consumers:
  • CL-08 (CDS): Alert clinicians when authorization is approved or denied
  • PM-08: Gate claim submission on active authorization

​
Security and RLS

  • All access to pm_prior_authorizations and pm_auth_reviews is tenant-isolated via organization_id and RLS.
  • FORCE ROW LEVEL SECURITY enabled on both tables.
  • RLS policies use pm_has_org_access(organization_id, auth.uid()) SECURITY DEFINER helper.
  • pm_auth_reviews INSERT uses pm_prior_auth_can_insert_review(authorization_id, auth.uid()) to validate parent PA org access.
  • UPDATE policies include both USING and WITH CHECK to prevent organization_id mutation.
  • DELETE restricted to pf_is_org_admin(organization_id, auth.uid()).
  • PHI: PA records and clinical justification are PHI; no PHI in logs or external API payloads beyond authorized use.