BRD-01: Claims & Prior Authorization AI

Year 1 Flagship Workstream — This BRD defines the functional, non-functional, AI model, data, integration, and regulatory requirements for ACME Highland Health's claims and prior authorization AI capability. Developed through 8 JAD sessions (Oct–Dec 2026) with mandatory participation from Legal, Compliance, Enterprise Architecture, Cybersecurity, Clinical/Medical Policy, AI Governance, and the BRD-01 delivery lead. Requirements signed off at the Phase 1 gate (28 Feb 2027).

1. Executive Summary & Business Case

ACME Highland Health processes approximately 800,000 prior authorization (PA) requests annually across its 4 million member base. The current process is predominantly manual: PA requests arrive via fax, phone, and provider portal; clinical staff review each request against medical policy guidelines; determinations are issued within 7–14 calendar days for standard requests and 24–72 hours for urgent requests. This manual process consumes approximately 120 FTE-years of clinical reviewer time annually, produces inconsistent decision quality (inter-reviewer agreement rate of approximately 78%), and creates member dissatisfaction driven by wait times and opaque decision rationale.

BRD-01 delivers an AI-powered claims and prior authorization capability that automates the intake, clinical evaluation, and determination workflow for PA requests — while maintaining mandatory human review for all adverse determinations and preserving full audit traceability for regulatory compliance. The system uses a combination of natural language processing (to extract clinical information from unstructured submissions), rules-based clinical decision support (to apply medical policy guidelines), and machine learning (to predict approval likelihood and flag edge cases for human review).

1.1 Business Objectives

1.2 Investment & Timeline

Budget: $27.72M (Year 1 SOW-01, which also covers cross-cutting platform and governance work). BRD-01-specific delivery labor: approximately $12M of the Year 1 allocation.

Timeline: Phase 0 (Aug–Nov 2026, readiness) → Phase 1 (Nov 2026–Feb 2027, requirements & design) → Phase 2 (Feb–Jun 2027, build & test) → Phase 3 (Jun–Aug 2027, pilot) → Phase 4 (Sep 2027, full production). Total: approximately 14 months from kickoff to production.

Team: 28 people (see Section 16), led by F. Bennett (BRD-01 Lead, Pulaski). Includes 4 ML engineers, 2 NLP engineers, 2 clinical rules engineers, 3 clinical reviewers (human-in-the-loop, ACME FTEs), 3 data scientists, 2 integration engineers, and supporting product, QA, DevOps, and documentation roles.

2. Regulatory Drivers & Compliance Requirements

2.1 CMS-0057-F: Prior Authorization Interoperability

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) is the primary external regulatory driver for BRD-01. Key requirements applicable to ACME as a payer:

• Decision timelines (effective Jan 1, 2026): 72 hours for urgent PA requests; 7 calendar days for standard PA requests. ACME's current performance frequently exceeds these windows. BRD-01's automation capability is designed to bring ACME well within compliance — targeting ≤24 hours (urgent) and ≤3 days (standard).
• Prior Authorization API (effective Jan 1, 2027): Payers must implement a FHIR-based Prior Authorization API supporting electronic PA requests, responses, status updates, and documentation exchange. The API must support HL7 Da Vinci implementation guides: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). BRD-01's integration architecture (Section 8) is built around these FHIR standards.
• Denial transparency (effective Jan 1, 2026): Payers must provide specific, machine-readable reasons when PA requests are denied. BRD-01's explainability requirement (Section 6.4) directly supports this — every AI-assisted determination includes a structured explanation of the factors that drove the decision.
• Public reporting (effective Jan 1, 2026): Payers must publicly report PA metrics: submission volume, approval rate, denial rate, average decision time, appeal rate. BRD-01's audit trail (Section 10.3) captures the data needed for this reporting.

2.2 State AI-in-Insurance Regulations

• Colorado SB 21-169: Requires insurers using AI in coverage determinations to test for unfair discrimination. BRD-01's fairness testing requirement (Section 11) satisfies this.
• Connecticut SB 1103: Requires disclosure when AI is used in insurance decisions and mandates human review of adverse determinations. BRD-01's human-in-the-loop requirement (Section 10) satisfies this.
• NAIC Model AI Bulletin: Recommends governance, risk management, and transparency for AI use in insurance. BRD-01 operates under the AI Governance & CoE framework (Section 16), which is aligned to both the NAIC bulletin and NIST AI RMF.

2.3 HIPAA / HITECH

All PA data is PHI. BRD-01 systems are subject to HIPAA Privacy and Security Rules. PHI handling requirements are defined in Section 7 (Data Requirements) and Section 9 (Non-Functional Requirements, security subsection). All vendor access to PA data requires executed BAAs.

3. Current State Assessment

3.1 Current PA Workflow

1. Intake: PA requests arrive via fax (~40%), provider portal (~35%), phone (~20%), and mail (~5%). No standardized electronic intake format; significant data re-entry.
2. Triage: Administrative staff classify requests by service type, urgency, and medical policy category. Manual process, approximately 15 minutes per request.
3. Clinical Review: Licensed clinical reviewers evaluate the request against ACME's medical policy guidelines. Reviewers access member history, clinical documentation, and policy guidelines across 3–4 separate systems. Average review time: 45–90 minutes per complex case; 15–30 minutes per routine case.
4. Determination: Reviewer issues approval, denial, or pend (request additional information). Denials require peer-to-peer review opportunity per CMS guidelines. Determination communicated to provider via portal notification, fax, or letter.
5. Appeal: Denied requests may be appealed. Appeals follow a separate workflow with additional clinical review levels.

3.2 Current State Pain Points

• Cycle time: Average 9.3 calendar days for standard PAs; 58% exceed the 7-day CMS-0057-F target. Urgent PAs average 36 hours; 12% exceed the 72-hour target.
• Inconsistency: Inter-reviewer agreement rate of ~78% on matched cases. Variation driven by individual reviewer interpretation of medical policy guidelines, inconsistent access to member history, and reviewer workload pressure.
• Cost: ~120 FTE clinical reviewers at an average fully-loaded cost of ~$135,000/year = approximately $16.2M annually in PA review labor alone, not counting administrative intake and triage staff.
• Data fragmentation: Clinical documentation, member history, and medical policy guidelines are stored across 4 disparate systems with no unified data layer. Reviewers spend approximately 30% of their review time navigating between systems rather than evaluating clinical evidence.
• Member experience: Opaque determination rationale; generic denial letters that do not explain the specific clinical basis for the decision. PA-related complaints represent 22% of all member service inquiries.

4. Target State & Capability Description

4.1 Target State Architecture (Conceptual)

The target state replaces the manual intake-triage-review-determination workflow with an AI-assisted pipeline:

1. Intelligent Intake: PA requests received via FHIR API (CMS-0057-F compliant), provider portal, or fax (OCR + NLP extraction). Unstructured clinical documentation automatically parsed, coded, and mapped to ACME's medical policy taxonomy.
2. Automated Triage & Pre-Screening: AI model classifies the request by urgency, service type, complexity, and medical policy category. Routine, clearly-approvable requests (e.g., well-established clinical evidence, matching policy criteria, no contraindications) are auto-approved without human touch. Estimated auto-approval pool: 60–70% of standard PAs.
3. AI-Assisted Clinical Review: Complex or edge-case requests are routed to clinical reviewers with an AI-generated case summary: extracted clinical evidence, relevant medical policy sections, similar prior decisions, and a preliminary recommendation with confidence score. Reviewers evaluate the AI summary and make the final determination. Average review time target: 10–20 minutes (down from 45–90).
4. Mandatory Human Review for Adverse Determinations: All denials and partial denials receive mandatory human clinical review before the determination is issued. The AI cannot issue an adverse determination without a human clinical reviewer confirming the decision. This is a hard constraint, not a configurable setting.
5. Explainable Determination: Every determination (approval or denial) includes a structured, human-readable explanation: the clinical factors evaluated, the medical policy sections applied, and the rationale for the decision. Explanations are machine-readable (for CMS-0057-F denial-reason reporting) and member-readable (for determination letters).
6. Continuous Monitoring: Production model performance monitored via automated dashboards: accuracy vs. ground-truth audit, fairness metrics by demographic group, cycle time, automation rate, and override rate (human reviewer overturning AI recommendation). Retraining triggered if performance drifts beyond defined thresholds.

5. Functional Requirements

Requirements are classified using MoSCoW prioritization: Must (non-negotiable for production), Should (expected, can defer with documented justification), Could (included if capacity allows).

5.1 Intake & Document Processing

5.2 AI-Assisted Clinical Decision

5.3 Determination & Communication

5.4 Audit, Reporting & Compliance

6. AI Model Specifications

6.1 Model Architecture

BRD-01 uses a multi-model architecture — not a single monolithic model. Each model has a specific function, its own training data, and its own validation criteria:

6.2 Model Training Data Requirements

• Training corpus: Minimum 500,000 historical PA decisions (3 years of ACME PA history) with outcomes, clinical documentation, medical policy versions applied, and reviewer notes.
• Ground-truth benchmark: 5,000 PA cases independently reviewed by a panel of 3 clinical experts (majority-rules adjudication) to establish gold-standard labels. Benchmark refreshed annually.
• De-identification: All training data de-identified per HIPAA Safe Harbor method before use. De-identification verified by Data Privacy Office (E. Sato) before any dataset is released for model training.
• Bias audit of training data: Training data audited for demographic representation before use. If any demographic group (age, gender, geography, plan type) is underrepresented by >20% relative to ACME's member population, the dataset is augmented or the model is trained with appropriate weighting.

6.3 Model Performance Monitoring (Production)

• Accuracy drift monitoring: Weekly comparison of model predictions against retrospective audit results. If accuracy drops >3 percentage points below the validation benchmark, a retraining investigation is triggered within 5 business days.
• Override rate monitoring: Monthly tracking of human reviewer override rate (cases where the reviewer changes the AI recommendation). If override rate exceeds 15% for any service category, the model for that category is flagged for retraining assessment.
• Fairness drift monitoring: Monthly comparison of approval/denial rates across demographic groups. If any group's rate deviates >5% from the population mean (and deviation is not explained by documented clinical differences), flagged to AI Governance Board within 48 hours.

6.4 Model Explainability Requirements

Every model output must be interpretable. Black-box models without explainability are rejected at the model design stage (AI Governance Board, Section 12 of Program Governance Model).

• M-03 (Clinical Decision Model): For every recommendation, the system must identify: the top 5 clinical factors that drove the decision, the specific medical policy section(s) applied, and the confidence basis (similar cases, rule match, or both).
• M-01 (Document Extraction): Extracted entities must be linked to their source location in the original document (character offset), enabling human verification of extraction accuracy.
• M-05 (Explanation Generator): Generated explanations must be factually grounded — every claim in the explanation must trace to either an extracted clinical fact or a medical policy citation. Hallucinated explanations (claims not supported by evidence) are treated as Critical defects.

7. Data Requirements

8. Integration Requirements

9. Non-Functional Requirements

9.1 Performance

• API response time: FHIR PAS API P95 latency ≤ 2 seconds for synchronous status queries; ≤ 5 seconds for initial submission acknowledgment.
• Model inference latency: End-to-end processing (document extraction + classification + clinical evaluation + explanation generation) ≤ 30 seconds per PA request for batch processing; ≤ 60 seconds for real-time API-submitted requests.
• Throughput: System shall handle peak volume of 5,000 PA submissions per day (approximately 2× the average daily volume of 2,200, to accommodate seasonal spikes and open enrollment periods).

9.2 Availability & Disaster Recovery

• Availability target: 99.5% uptime (measured monthly), excluding scheduled maintenance windows.
• RTO (Recovery Time Objective): 4 hours for full system recovery.
• RPO (Recovery Point Objective): 1 hour — maximum data loss in disaster scenario.
• Graceful degradation: If AI models are unavailable, the system shall fall back to manual routing — all PA requests go directly to the human review queue. The system must never silently drop PA requests.

9.3 Security

• All data encrypted at rest (AES-256) and in transit (TLS 1.3).
• Role-based access control (RBAC) enforced for all system access. Clinical reviewers, administrators, and AI models have distinct permission sets.
• Adversarial input testing: model inputs validated and sanitized to prevent prompt injection, data poisoning, and model inversion attacks.
• Penetration testing conducted before production release and annually thereafter.
• SOC 2 Type II compliance required for any cloud-hosted component.

10. Human-in-the-Loop & Override Requirements

10.1 Override Workflow

• When a clinical reviewer overrides the AI recommendation (changes approval to denial or vice versa), the system shall require a structured override reason from a predefined code list (e.g., "additional clinical evidence not captured by AI," "medical policy interpretation differs," "edge case not covered by training data").
• Override reasons are logged in the audit trail and aggregated monthly. Override patterns are analyzed by the AI CoE to identify model improvement opportunities.
• Persistent override patterns (>15% override rate in any service category over 3 consecutive months) trigger a model retraining assessment with a root-cause analysis presented to the AI Governance Board.

10.2 Peer-to-Peer Review

• For denied PA requests, the system shall support the peer-to-peer review process: providers may request a phone consultation with an ACME clinical reviewer to discuss the denial.
• The AI case summary (clinical evidence, medical policy, recommendation rationale) shall be available to the reviewing clinician during the peer-to-peer call, enabling faster, more informed discussions.

11. Fairness, Bias & Responsible AI Requirements

11.1 Fairness Testing (Pre-Production)

• All models shall be tested for disparate impact across demographic groups: age bracket, gender, geography (urban/rural/suburban), plan type, and (where data permits) race/ethnicity.
• Fairness threshold: No demographic group's approval or denial rate shall deviate >5% from the population mean without documented clinical justification reviewed and accepted by the Chief Medical Officer (Dr. N. Patel).
• Fairness testing is conducted by the Independent Model Validation team (P. Okafor), not by the delivery team. Results are presented to the AI Governance Board before production release approval.

11.2 Ongoing Fairness Monitoring (Production)

• Monthly demographic disparity analysis conducted by AI CoE using production decision data.
• If any group's rate deviates >5% from the population mean in production (and the deviation was not present in pre-production testing, or has grown beyond pre-production levels), the AI Governance Board is notified within 48 hours and a model investigation is initiated.

12. Testing & Validation Requirements

13. Acceptance Criteria & Definition of Done

BRD-01 is accepted into production when ALL of the following criteria are met:

1. All "Must" functional requirements (FR-01.001 through FR-01.017) implemented and tested
2. All 5 AI models pass Independent Model Validation (zero Critical, zero uncorrected High)
3. Fairness testing passed (≤ 5% demographic deviation)
4. UAT passed (≥ 95% pass rate, zero open Critical/High defects)
5. Security testing passed (zero Critical/High findings)
6. Performance testing passed (all latency and throughput targets met at 2× peak volume)
7. DR/BCP test passed (recovery within RTO/RPO)
8. Human-in-the-loop workflow verified (adverse determination cannot proceed without human confirmation)
9. Audit trail verified (complete, immutable, queryable)
10. CMS-0057-F compliance verified (API conformance, decision timelines, denial-reason structure, reporting capability)
11. All 3 governance boards sign off at Phase 3 gate
12. Production monitoring dashboards operational
13. Runbook and operational documentation delivered to IT Operations

14. Constraints, Assumptions & Dependencies

14.1 Constraints

• All PHI data onshore US only (no offshore access to real PA data)
• Human review mandatory for all adverse determinations (non-negotiable)
• Model explainability required for all determination types (no black-box models)
• CMS-0057-F compliance is a prerequisite, not an option

14.2 Assumptions

• ACME's baseline CMS-0057-F compliance project delivers FHIR API endpoints on schedule (independent project)
• Historical PA data (3 years, 500K+ cases) is available and of sufficient quality for model training (validated Phase 0; RAIDD R-01 addresses data quality risk)
• Medical policy guidelines are machine-readable or can be converted to machine-readable format within Phase 1
• Clinical reviewer pool (3 ACME FTEs) is available for human-in-the-loop operations

14.3 Dependencies

• DEP-02: AI Governance & CoE Charter (Phase 0) completed before JAD sessions begin
• DEP-03: Data & Cloud Platform Foundation live before model build accelerates
• DEP-06: ACME baseline CMS-0057-F API endpoints available for BRD-01 integration testing

15. Regulatory Traceability Matrix

16. BRD-01 Delivery Team & Governance

Team size: 28 people. Lead: F. Bennett (Pulaski). Full roster in Resource Plan, Team 21.

Governance: BRD-01 operates under the full Project Catalyst governance framework: three-board sign-off at phase gates, AI Governance Board model-release authority, Independent Model Validation blocking gate, and JAD session requirements development. Sprint-level execution uses 2-week sprints with Scrum Master (Z. Okoro3), Product Manager (M. Beaumont2), and daily standups.

17. Sign-Off & Approval