Prior Authorization Guide

End-to-end guide to prior authorization in Cloud Health Office — from X12 278 request receipt through clinical decision engine evaluation, authorization lifecycle, and Da Vinci FHIR IG integration. Covers CMS-0057-F prior auth API compliance.

Overview

Cloud Health Office prior authorization spans four major areas — from inbound request processing through automated clinical decision-making, lifecycle management, and CMS-mandated FHIR API compliance:

The prior authorization module integrates directly with the claims adjudication pipeline — approved authorizations are matched to inbound claims at Step 9 (Authorization Match) to determine whether the required auth exists and is valid.

1. Authorization Requests

Authorization requests arrive from providers and facilities through multiple channels. Each request is validated, checked against the plan’s auth-required rules, and routed to the decision engine for evaluation.

Inbound Channels

Channel	Protocol	Mode	Typical Use
X12 278 via Clearinghouse	SFTP / AS2	Batch & real-time	Standard EDI channel via Availity, Change Healthcare, or other clearinghouses
FHIR PriorAuth/$submit	HTTPS (FHIR R4)	Real-time	Da Vinci PAS-enabled EHR systems submitting via FHIR API
Portal Manual Entry	HTTPS (portal UI)	Real-time	Payer staff entering requests received by phone, fax, or mail
Phone / Fax (Digitized)	Portal data entry	Asynchronous	Legacy requests digitized by utilization management staff into the portal

Request Data Elements

Each authorization request includes the following data elements, regardless of the inbound channel:

Data Element	Source	Description
MemberID	278 Loop 2010C / FHIR Patient	Unique identifier for the member requiring the service
RequestingProviderNPI	278 Loop 2010B / FHIR Practitioner	Ordering/referring provider’s NPI
ServicingProviderNPI	278 Loop 2010EA / FHIR Practitioner	Provider or facility performing the service
DiagnosisCodes	278 HI segment / FHIR Condition	ICD-10-CM codes supporting medical necessity
ProcedureCodes	278 SV1/SV2 / FHIR ServiceRequest	CPT/HCPCS codes for the requested service(s)
PlaceOfService	278 UM04 / FHIR Encounter.class	Where the service will be rendered (Inpatient, Outpatient, Office, Home, etc.)
RequestedUnits	278 UM05 / FHIR ServiceRequest.quantity	Number of units, visits, or days requested
ClinicalNotes	278 PWK segment / FHIR DocumentReference	Attached clinical documentation supporting the request

Request Validation

Before routing to the decision engine, each request undergoes three validation checks:

1. Member eligibility check — Confirm the member has active coverage on the requested service date. If the member is not eligible, the request is denied immediately.
2. Provider active/credentialed check — Verify both the requesting and servicing providers are active, credentialed, and not on any exclusion list (OIG LEIE, GSA SAM). Integrates with the ProviderVerificationService.
3. Service-requires-auth lookup — Check whether the requested service + plan + place of service combination requires prior authorization. If no auth is required, the system returns an informational response indicating the service is covered without auth.

Auth-Required Determination

The IsAuthRequired API checks the plan’s auth-required configuration to determine whether the requested service needs prior authorization. This lookup considers:

• Service category + procedure code — Some procedures always require auth (e.g., advanced imaging, inpatient admissions); others never do (e.g., routine PCP visits, preventive care)
• Place of service — The same procedure may require auth in one setting (outpatient surgery center) but not another (physician office)
• Line of Business — Medicaid may have different auth requirements than Commercial or Medicare Advantage

Submission (X12 278 / FHIR PAS / Portal) → Validation (member, provider, plan) → Auth-Required Check (service category + LOB + POS) → Decision Engine (auto-approve / auto-deny / pend / request info)

2. Decision Engine

The PriorAuthDecisionEngine is the core of Cloud Health Office’s prior authorization processing. It is a configuration-driven rule engine — no clinical logic is hardcoded. All rules are stored in Cosmos DB/MongoDB and can be modified, added, or deactivated without code deployment.

Rule Structure

Each decision rule follows a Condition → Action pattern:

• Condition — A combination of criteria that must all be true for the rule to fire:
  • Diagnosis codes (ICD-10-CM code or code range)
  • Procedure codes (CPT/HCPCS code or code range)
  • Place of service
  • Line of Business
  • Member demographics (age range, sex, pregnancy status)
  • Prior treatment history (e.g., conservative therapy attempted for X weeks)
• Action — The disposition when the condition matches:
  • Auto-Approve — Request meets clinical criteria; authorization issued immediately
  • Auto-Deny — Service is not covered or explicitly excluded by the plan
  • Pend for Clinical Review — Requires nurse or physician reviewer evaluation
  • Request Additional Info — Missing clinical documentation; request returned to provider

Condition Set (diagnosis + procedure + POS + LOB + demographics) → Priority-Ordered Rule Match → Action: Auto-Approve | Auto-Deny | Pend for Clinical Review | Request Additional Info

Pathway Capacity

The PriorAuthDecisionEngine is designed to handle 400–600+ authorization pathways per Line of Business. This is a key differentiator — many legacy and vendor solutions cap at approximately 130 rules, which is insufficient for complex Medicaid programs like Texas Medicaid that require hundreds of distinct authorization pathways across service categories.

Decision Categories

Decision Type	Criteria	Typical % of Volume	Turnaround SLA
Auto-Approve	Request meets all clinical criteria; no review needed	40–60%	Immediate (< 1 minute)
Auto-Deny	Service not covered, explicitly excluded, or member not eligible	5–10%	Immediate (< 1 minute)
Pend for Clinical Review	Requires nurse/physician evaluation; clinical criteria partially met or complex case	25–40%	Standard: 2 business days (Medicaid); Urgent: 24 hours
Request Additional Info	Missing clinical documentation; request cannot be evaluated without notes/records	5–15%	Clock paused until documentation received

Rule Priority & Conflict Resolution

Rules are evaluated in priority order (lowest priority number = highest priority). When multiple rules match a single request:

• First match wins — The highest-priority matching rule determines the disposition
• Specificity tiebreaker — If two rules have the same priority, the more specific rule (more condition fields populated) takes precedence
• Audit trail — The decision trace log records every rule that was evaluated, which rules matched, and which rule ultimately fired — enabling compliance audits and rule tuning

Turnaround Time Tracking

The system tracks turnaround time from request receipt to final disposition, segmented by urgency level:

Urgency	Definition	Regulatory SLA	Clock Behavior
Urgent / Expedited	Delay could jeopardize member’s life, health, or ability to regain maximum function	24 hours (Medicaid); 72 hours (CMS MA)	Continuous (no clock pause)
Standard (Pre-service)	Non-urgent request for a service not yet rendered	2 business days (TX Medicaid); 14 calendar days (CMS MA); varies by state	Pauses when additional info requested; resumes on receipt
Post-service	Retroactive auth request for a service already rendered	30 calendar days	Continuous

Rule Type Catalog (PriorAuthRuleEngine)

The PriorAuthRuleEngine extends the PriorAuthDecisionEngine with a library of composable, state-specific rule types. Each rule is a self-contained class that evaluates a single criterion and returns an Approve, Deny, Pend, or Skip result. Rules are resolved per-tenant from the database and cached in Redis.

Gold Card Exemptions

Texas HB 3459 (2021) established “gold card” exemptions for providers who consistently meet prior authorization approval criteria. The TxGoldCardExemptionRule implements this by checking:

• Provider history — 90%+ approval rate for the specific service category over the past 6 months
• Tenure threshold — Provider enrolled in the Medicaid MCO network for 2+ years
• No recent adverse actions — No sanctions, exclusions, or material fraud referrals

When all gold card criteria are met, the request is auto-approved immediately with a GoldCardExemption reason code in the audit trail. Gold card status is re-evaluated quarterly.

Rule Seeding & Management

Rules are managed through the PriorAuthRuleSeeder which loads seed rule sets from JSON configuration. The seeder uses a dictionary pre-fetch strategy to avoid N+1 queries when checking for existing rules:

1. Load seed data — Read rule definitions from config/ JSON files
2. Pre-fetch existing — Query all existing rules for the tenant in a single batch
3. Upsert delta — Only insert new rules or update changed rules; skip unchanged entries
4. Cache invalidation — Clear the Redis rule cache for affected tenants

Rule Caching (Redis)

Resolved rule sets are cached in Redis to avoid database round-trips during high-volume claims processing:

• Cache key: pa-rules:{tenantId}:{lobCode}:{state}
• Default TTL: 30 minutes (configurable via PriorAuthRuleEngine:CacheTtlMinutes)
• Null safety: If a cached value deserializes to null (e.g., corrupted entry or JsonException), it is treated as a cache miss and rules are re-resolved from the database
• Invalidation: Rule changes via the seeder or admin API automatically invalidate the relevant cache entries

Rule Evaluation Pipeline

When a prior auth request enters the PriorAuthRuleEngine, rules are evaluated in the following order:

1. Resolve rules — Load the rule set for the request’s tenant + LOB + state (from Redis cache or database). Uses first-non-empty-wins across registered IRuleSource implementations.
2. Sort by priority — Rules are ordered by priority (ascending). Lower priority numbers evaluate first.
3. Sequential evaluation — Each rule is evaluated against the request context. A rule returns Approve, Deny, Pend, or Skip.
4. First decisive result — The first non-Skip result becomes the final disposition. All subsequent rules are short-circuited.
5. Audit trace — Every rule evaluation (including skipped rules) is logged to the decision audit trail for compliance and tuning.

3. Authorization Lifecycle

Each authorization progresses through a defined lifecycle from initial submission through final resolution. The lifecycle supports standard approvals, partial approvals, extensions, expirations, and voids.

Status Lifecycle

Status	X12 278 Code	FHIR ClaimResponse Status	Portal Display
Submitted	A1 (Certification Action: Request)	active	🟡 Submitted
In Review	A1 (Pending)	active	🔵 In Review
Approved	A1 (Certified)	active (outcome: complete)	🟢 Approved
Denied	A1 (Not Certified)	active (outcome: error)	🔴 Denied
Partial	A1 (Certified, modified)	active (outcome: partial)	🟠 Partial
Pended	A4 (Pended)	active	🟡 Pended — Awaiting Info
Extended	A1 (Certified, extended)	active	🟢 Extended
Expired	N/A (system-generated)	cancelled	⚪ Expired
Voided	A3 (Cancel)	cancelled	⛔ Voided

Partial Authorization

A partial authorization approves fewer units, visits, or days than the provider requested. This is common for therapy services, behavioral health, and home health:

• Provider requests 10 physical therapy visits; plan approves 5 visits based on clinical criteria
• Provider requests 14-day inpatient stay; plan approves 7 days with review required for extension
• The partial authorization includes the approved quantity and a reason code explaining the modification
• Providers can request additional units via a new authorization or an extension request

Extension

An extension extends the authorized service period or adds units without requiring a completely new authorization request:

• Continued stay reviews — For inpatient admissions, clinical staff review continued stay requests (typically every 2–3 days) and extend the authorization if medical necessity criteria are still met
• Therapy extensions — After the initial authorized visits are exhausted, a new clinical review determines if additional visits are warranted
• Extensions are tracked as amendments to the original authorization, maintaining the full history chain

Expiration

Every authorization has a ValidThrough date. When this date passes without the authorized service being rendered:

• The authorization status automatically transitions to Expired
• Expired authorizations do not satisfy the claims adjudication auth-match step — claims submitted after the auth expires will pend to the “Missing Prior Auth” work queue
• Providers must submit a new authorization request if the service is still needed

Voiding

A previously approved authorization can be voided (cancelled) when:

• The member disenrolls from the plan before the service is rendered
• The service is no longer needed (provider cancellation)
• The authorization was issued in error (data entry mistake, wrong member/service)

Voided authorizations cannot be reinstated — a new request must be submitted if the service is later needed.

Notification

Authorization decisions are communicated back to the requesting provider and the member through multiple channels:

• X12 278 Response — Sent back through the originating clearinghouse channel (Availity, Change Healthcare, etc.)
• FHIR ClaimResponse — Returned via the Da Vinci PAS API for FHIR-enabled providers
• Portal — Real-time status update visible in the provider and member portals
• Letter generation — For denials and partial approvals, a formal determination letter is generated with appeal rights, clinical rationale, and the specific plan provision applied

Newborn Authorization

4. CMS-0057-F Prior Auth APIs

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires payers to implement three Da Vinci FHIR Implementation Guides for prior authorization by January 1, 2027. Cloud Health Office implements all three as production-ready APIs.

Da Vinci CRD (Coverage Requirements Discovery)

CRD provides real-time coverage information to providers at the point of care via CDS Hooks integration with the provider’s EHR:

• Hook trigger — When a provider orders a service in the EHR (e.g., orders an MRI), the CDS Hooks order-sign or order-select hook fires
• Response cards — Cloud Health Office returns information cards indicating:
  • Whether prior authorization is required for this service
  • What clinical documentation is needed
  • Whether the service is covered under the member’s plan
  • A link to launch the DTR questionnaire (if applicable)
• No prior auth needed — If the service does not require auth, the response says so explicitly, eliminating unnecessary auth submissions

Da Vinci DTR (Documentation Templates & Rules)

DTR reduces provider documentation burden by pre-filling clinical questionnaires with data already available in the EHR:

• SMART-on-FHIR app — Launches within the EHR workflow when the provider clicks the DTR link from a CRD response card
• Questionnaire pre-fill — The DTR app retrieves the payer’s clinical questionnaire (FHIR Questionnaire resource) and pre-fills answers using CQL (Clinical Quality Language) expressions that query the EHR’s FHIR server
• Provider review — The provider reviews pre-filled answers, corrects any inaccuracies, and submits the completed questionnaire
• Attachment to auth request — The completed QuestionnaireResponse is attached to the prior auth request, providing the clinical documentation the decision engine needs

Da Vinci PAS (Prior Authorization Support)

PAS is the FHIR-based replacement for X12 278, enabling fully electronic prior auth submission and response:

• FHIR Claim/$submit — Providers submit a prior auth request as a FHIR Claim resource with use = preauthorization
• Synchronous response — For auto-approve/auto-deny decisions, the ClaimResponse is returned immediately
• Asynchronous (pended) — For requests requiring clinical review, a pended ClaimResponse is returned with a reference ID; the provider can poll for updates via Claim/$inquire
• Update and cancel — Providers can update a pending request (add documentation) or cancel a request via the PAS API

Implementation Status

Implementation Guide	FHIR Operation	Endpoint	Status
Da Vinci CRD	CDS Hooks (order-sign, order-select)	/cds-services/prior-auth-check	🟢 Production
Da Vinci DTR	SMART-on-FHIR Launch + Questionnaire/$populate	/fhir/Questionnaire/$populate	🟢 Production
Da Vinci PAS	Claim/$submit, Claim/$inquire	/fhir/Claim/$submit	🟢 Production

5. Reporting & Analytics

The prior authorization module includes built-in dashboards and reports for monitoring authorization volume, turnaround compliance, and denial patterns.

Auth Volume Dashboard

The volume dashboard provides real-time and historical views of authorization activity:

• Requests by LOB — Volume breakdown by Medicaid, Medicare Advantage, Commercial, and Exchange
• Requests by status — Current counts of Submitted, In Review, Approved, Denied, Partial, Pended, Extended, and Expired
• Requests by decision type — Auto-Approve vs. Auto-Deny vs. Pend for Clinical Review vs. Request Additional Info
• Trend analysis — Week-over-week and month-over-month volume trends with seasonality indicators

Denial Analytics

• Top denial reasons — Ranked list of denial reason codes with counts and percentages
• Denial rate by procedure category — Percentage of denials per service category (e.g., imaging denials at 18%, pharmacy denials at 12%)
• Appeal overturn rate — Percentage of denials overturned on appeal, segmented by denial reason — high overturn rates indicate potential rule misconfiguration

Turnaround Compliance

• SLA compliance rate — Percentage of authorizations completed within the regulatory SLA, segmented by LOB and urgency level
• Average turnaround time — Mean and median time from request receipt to final determination
• Breached auths — List of authorizations that exceeded their SLA with root cause categorization (staffing, documentation delays, system issues)

Provider-Level Metrics

• Request volume by provider — Identifies high-volume requesting providers for outreach and education
• Auto-approval rate by provider — Providers with low auto-approval rates may benefit from documentation improvement support
• Pend rate by provider — High pend rates indicate incomplete or inadequate clinical documentation

Getting Started

Recommended setup order for a new health plan implementation:

1. Configure auth-required rules — Define which services require prior authorization per plan and LOB
2. Load clinical criteria rules — Import or configure decision rules in the PriorAuthDecisionEngine for each authorization pathway
3. Configure clearinghouse 278 inbound/outbound — Set up X12 278 request receipt and response transmission via Availity, Change Healthcare, etc.
4. Set up Da Vinci CRD/DTR/PAS endpoints — Configure the FHIR-based prior auth APIs for CMS-0057-F compliance
5. Submit a test 278 request — Send a sample authorization request through the clearinghouse or API
6. Review the decision trace log — Verify which rules were evaluated, which rule fired, and confirm the expected disposition

Related Documentation