aibilly_backend_code/srs_document.md

# Software Requirements Specification

## AI-Powered Medical Billing Automation System

#### For Out-of-Network Neurosurgical & Orthopedic Practices

```
Prepared by: Dextra Labs Pte Ltd
Document Version: 2.
Date: February 2026
```
**Document Information**

**Client** Dr. Brian McHugh / McHugh
Neurosurgery

**Project Name** AI-Powered Medical Billing Automation

**Implementation Partner** Dextra Labs

**Development Partner** Tech4Biz Solutions Pvt Ltd

**Document Status** v2.0 — Development-Ready


## Table of Contents


## 1. Introduction

### 1.1 Purpose

This Software Requirements Specification (SRS) document provides a comprehensive,
development-ready description of the AI-Powered Medical Billing Automation System. It details
functional and non-functional requirements, system architecture, interfaces, constraints, and
milestone-aligned deliverables for building an intelligent billing automation platform for out-of-
network neurosurgical and orthopedic practices.

This document serves as the primary reference for developers, project managers, technical
leads, QA personnel, and stakeholders throughout the development lifecycle. All requirements
are mapped to SOW milestones to ensure traceability from specification to delivery.

### 1.2 Scope

The system is designed to transform the end-to-end claim generation process for specialty
medical practices. **[UPDATED]** The MVP focuses on 5-10 common spine surgery types
(covering approximately 98-99% of typical procedures) for a single practice with up to 5
providers.

The system will:

- Convert clinical audio dictation to text using Whisper ASR with medical-specialized
    vocabulary
- Extract clinical entities (diagnoses, procedures, anatomical locations) using NLP
- Map extracted entities to ICD-10 diagnosis codes and CPT procedure codes
- Apply payer-specific billing optimization rules to maximize reimbursement
- Perform RAG-powered claim scrubbing against NCCI edits and LCD/NCD coverage
    determinations
- Provide human-in-the-loop review workflow for mandatory claim verification
- Integrate with existing EMR systems (Epic, Athena Centricity, CureMD) via FHIR and
    REST APIs
- Support a template-based fast-track workflow for standard procedures (e.g., standard 2-
    level ACDF)
- Maintain HIPAA compliance through cloud-hosted, VPC-isolated AI infrastructure

### 1.3 System Boundary

#### 1.3.1 In Scope (Our System)

- Audio capture via mobile application (smartphone-based, no dedicated hardware)
- Speech-to-text conversion with medical terminology using Whisper STT
- EMR data retrieval (patient demographics, insurance, clinical documentation) from Epic,
    Athena, CureMD
- AI-powered entity extraction and ICD-10/CPT code mapping with confidence scoring
- RAG-powered claim scrubbing against payer-specific rules, NCCI edits, and LCD/NCD
- Payer-specific optimization and claim generation (CMS-1500 professional claims)
- Template-based fast-track workflow for standard procedures
- Human review workflow with mandatory approval before finalization
- Export of approved claims for downstream processing


- Audit trails, compliance reporting, and analytics dashboard
- Provider interface supporting dictate → review → approve → submit workflow

#### 1.3.2 Out of Scope (Existing Practice Workflow)

- Claim submission to clearinghouse or insurance payers (EDI 837P/837I transmission)
- Payment posting and ERA/835 processing
- Patient billing and collections
- Denial appeals and follow-up automation
- Accounts receivable management
- Operative report generation/amendment (future phase consideration)
- ModMed integration (mentioned in original brief, formally excluded from MVP)
- UB-04 institutional claims (MVP covers CMS-1500 professional claims only)

_Note: The practice will continue using their existing systems (Athena Centricity) for claim
submission and payment processing. Our system generates the approved claim and hands off
to their existing workflow._

#### [NEW] 1.3.3 Out-of-Network Billing Lifecycle Context

Developers must understand the out-of-network (OON) billing lifecycle to build this system
effectively. The typical OON claim lifecycle is: Procedure → Coding & Claim Generation (our
system) → Submission to Payer → Initial Denial (common for OON) → Appeal with
Documentation → Arbitration (if needed) → Payment. Our system’s output directly impacts
denial rates and appeal success by ensuring accurate coding, proper modifier application, and
comprehensive documentation from the start.

### 1.4 Definitions, Acronyms, and Abbreviations

```
Term Definition
```
```
ASR Automatic Speech Recognition — converts spoken words to text
CPT Current Procedural Terminology — medical procedure codes maintained by
AMA
```
```
EMR/EHR Electronic Medical/Health Record — digital patient medical history
FHIR Fast Healthcare Interoperability Resources — healthcare data exchange
standard
HIPAA Health Insurance Portability and Accountability Act — US healthcare privacy
law
ICD- 10 International Classification of Diseases, 10th Revision — diagnosis coding
system
LCD/NCD Local/National Coverage Determination — payer coverage policies
```
```
LLM Large Language Model — AI model trained on large text datasets
```
```
LoRA Low-Rank Adaptation — technique for efficient LLM fine-tuning
MDM Medical Decision Making — complexity level used for E/M coding
```
```
MVP Minimum Viable Product — initial product version with core features
```

```
NCCI National Correct Coding Initiative — CMS edits to prevent improper code
pairs
NLP Natural Language Processing — AI techniques for understanding text
```
```
OON Out-of-Network — healthcare providers not contracted with insurance plans
```
```
PHI Protected Health Information — patient health data protected by HIPAA
RAG Retrieval-Augmented Generation — AI technique combining semantic search
with LLM
STT Speech-to-Text — audio to text conversion technology
```
```
WER Word Error Rate — standard metric for measuring STT accuracy
```
### 1.5 References

- SO070FY26: Real-Time Dictation and Automated Billing AI Platform (December 2025)
- SOW: AI Dictation Application Development, Dextra Labs v
- Product Vision Document — Dr. Brian McHugh Discovery Session Notes (1st & 2nd
    calls)
- Project Kickoff Presentation (February 2026)
- AI-Enabled Real-Time Dictation and Automated Billing Project Brief
- HIPAA Security Rule (45 CFR Part 164)
- HL7 FHIR R4 Specification
- Epic FHIR API Documentation


## 2. Overall Description

### 2.1 Product Perspective

The AI-Powered Medical Billing Automation System addresses a significant gap in the
healthcare revenue cycle management market. While in-network billing has seen substantial
automation advances, out-of-network specialty billing remains largely manual due to complex
payer-specific coding requirements, high-value procedures requiring precise documentation,
institutional knowledge locked within experienced human coders, and stringent HIPAA
requirements limiting cloud-based AI adoption.

This system serves as a standalone application integrating with existing EMR infrastructure
while providing its own AI-powered processing layer.

### 2.2 Why Historical Billing Data is Critical

The system requires access to historical billing data from the practice (filtered for relevance).
This data serves several critical purposes:

- Pattern Recognition: Learning which CPT codes are most successful for specific
    procedures with specific payers
- Denial Avoidance: Understanding which code combinations and documentation patterns
    lead to claim denials
- Payer-Specific Optimization: Different insurers have different preferences (e.g., BCBS
    prefers certain code sequences while Cigna accepts others)
- Institutional Knowledge Capture: Expert coders have accumulated decades of
    knowledge about what works

**Important:** Historical data will be filtered to exclude outdated policy periods. For example, if
United Healthcare restructured policies 3 years ago, denial patterns from before that date are
excluded as no longer relevant. Data filtering criteria must be defined per-payer based on policy
change dates.

### 2.3 Product Functions

#### 2.3.1 Audio Capture and Transcription

- Smartphone-based audio recording for clinical dictation (no dedicated hardware in MVP)
- AI-powered speech-to-text conversion with medical vocabulary fine-tuning
- Noise reduction optimized for hospital environments (post-procedure hallway, dictation
    room, OR)
- Single speaker per dictation session (clinic claims may have PA voice, surgical claims
    have surgeon voice)

#### 2.3.2 Clinical Entity Extraction

- Automated extraction of diagnoses, procedures, anatomical locations, and laterality
- Temporal relationship mapping for procedure sequencing
- Confidence scoring for each extracted entity

#### 2.3.3 Medical Code Mapping

- Automatic mapping of diagnoses to ICD-10 codes and procedures to CPT codes


- Modifier suggestions based on context (-59, -51, -LT/RT, etc.)
- Confidence scoring with alternative code suggestions for edge cases

#### [NEW] 2.3.4 Template-Based Fast-Track Workflow

For standard, high-volume procedures (e.g., standard 2-level ACDF), the system provides a
fast-track workflow where the surgeon selects a procedure template and associates it with a
patient. The system auto-generates the claim with pre-mapped CPT/ICD codes, modifiers, and
justification. The surgeon can add dictation notes for any deviations. This significantly reduces
time-to-claim for routine procedures.

#### 2.3.5 RAG-Powered Claim Scrubbing

Automated claim review using Retrieval-Augmented Generation against payer-specific rules,
NCCI edits, and Local/National Coverage Determinations (LCD/NCD). The RAG corpus
includes policy documents per individual plan, coding manuals, billing guidelines, and the
practice’s laminated cheat sheets.

#### 2.3.6 Payer-Specific Optimization

- Business rules engine for payer-specific coding strategies
- Historical denial pattern analysis for proactive optimization
- Coverage for top 30 local insurance plans in MVP (starting with top 10 for initial
    validation)

#### 2.3.7 Claim Generation and Review

- Automated generation of submission-ready CMS- 15 00 professional claims
- Mandatory human review interface with AI-generated content highlighting
- Correction workflow with feedback captured for model improvement
- Complete audit trails for compliance and quality tracking

### 2.4 User Classes and Characteristics

```
User Class Description Technical Proficiency
```
```
Surgeon/Physician Primary users who record clinical dictation via
mobile app. Up to 5 providers in MVP.
```
```
Low — Requires simple,
intuitive interface
Medical Biller Reviews AI-generated claims, makes
corrections, approves submissions
```
```
Moderate — Familiar with
billing systems
```
```
Billing Supervisor Oversees billing operations, manages rules
and policies
```
```
Moderate — Dashboard and
reporting focus
```
```
System
Administrator
```
```
Manages system configuration, users, and
integrations
```
```
High — Technical
administration
```
### 2.5 Operating Environment

- Web Application: Modern browsers (Chrome, Firefox, Safari, Edge) on Windows,
    macOS
- Mobile Application: iOS 14+ and Android 11+ smartphones for audio capture


- Server Infrastructure: Cloud-hosted (AWS/GCP/Azure) with HIPAA-compliant VPC
    isolation
- AI Infrastructure: GPU-enabled cloud instances or Mac Mini M-series for LLM inference
- Database: PostgreSQL for structured data; vector database for RAG/semantic search
- Network: Always-online connectivity required (no offline mode in MVP)

### 2.6 Design and Implementation Constraints

- HIPAA Compliance: All PHI must remain within HIPAA-compliant, VPC-isolated
    infrastructure
- Self-Hosted AI: No external API calls for patient data processing (LLM inference is self-
    hosted)
- Human-in-the-Loop: Mandatory human review before any claim finalization
- Single Practice: MVP limited to Dr. McHugh’s practice only (up to 5 providers)
- Surgical Focus: MVP focused on 5-10 common spine surgery types (CMS- 1500
    professional claims only)
- English Only: Speech-to-text optimized for English medical dictation, single speaker per
    session
- Open-Source LLM: Llama/Mistral/Mixtral/Qwen with LoRA fine-tuning

### 2.7 Assumptions and Dependencies

#### 2.7.1 Assumptions

- Internet connectivity is always available at all practice locations
- Practice will provide access to historical billing and denial data (filtered for relevance)
- Payer policy documents, coding manuals, and cheat sheets will be provided for RAG
    corpus
- Human billers will be available for review and correction during MVP
- Epic FHIR API access will be granted through proper channels (timeline dependency)
- No major scope changes during the execution of agreed phases
- Client will provide list of 5-10 common spine surgeries with typical CPT/ICD code
    combinations
- Client will provide prioritized list of top 30 insurance plans for payer rules configuration

#### 2.7.2 Dependencies

- Epic Systems: FHIR R4 API availability and access credentials (critical path — can take
    3 - 6 months)
- Athena Centricity: Legacy system data export capabilities and API availability
- CureMD: REST API documentation and access
- Open-source LLM: Availability of Llama 2/3 or Mistral/Mixtral models for self-hosting
- Whisper ASR: Model availability for self-hosting with medical vocabulary fine-tuning
- Client SMEs: Availability of billing and clinical subject matter experts for validation


## 3. Functional Requirements

All functional requirements are mapped to SOW milestones for traceability. Priority levels: Must
(MVP-critical), Should (important but can be deferred), Could (nice-to-have).

### 3.1 Audio Capture Module (Mobile App) — Milestone 2

```
Req ID Requirement Description Milestone Priority
FR-AC-
001
```
```
System shall allow users to record audio dictation using
smartphone microphone
```
```
M2 Must
```
```
FR-AC-
002
```
```
System shall support audio recording in standard formats
(AAC, MP3, WAV)
```
```
M2 Must
```
```
FR-AC-
003
```
```
System shall display recording duration and audio level
indicator
```
```
M2 Must
```
```
FR-AC-
004
```
```
System shall allow pause and resume during recording
session
```
```
M2 Must^
```
```
FR-AC-
005
```
```
System shall require user to associate recording with patient
identifier (MRN or encounter ID from EMR lookup)
```
```
M2 Must^
```
```
FR-AC-
006
```
```
System shall encrypt audio files at rest on device before
upload (AES-256)
```
```
M2 Must^
```
```
FR-AC-
007
```
```
System shall automatically upload recordings when network is
available
```
```
M2 Must^
```
```
FR-AC-
008
```
```
System shall support multiple recording sessions per patient
encounter
```
```
M2 Must^
```
```
FR-AC-
009
```
```
System shall support template-based fast-track: surgeon
selects standard procedure template and patient, bypassing
full dictation
```
```
M2 Must^
```
### 3.2 Speech-to-Text Module — Milestones 2- 3

```
Req ID Requirement Description Milestone Priority
```
```
FR-ST- 001 System shall convert audio dictation to text with ≥97% word
accuracy (WER) on a mutually agreed medical dictation test
corpus
```
```
M3 Must^
```
```
FR-ST- 002 System shall use medical-specific vocabulary (ICD-10 terms,
CPT terms, drug names, anatomical terms) for recognition
```
```
M3 Must
```
```
FR-ST- 003 System shall recognize ICD-10 and CPT codes when spoken
directly
```
```
M3 Should
```
```
FR-ST- 004 System shall handle medical drug names and dosages
accurately
```
```
M3 Must
```
```
FR-ST- 005 System shall apply AI-powered noise reduction for hospital
environments (hallway, dictation room, OR)
```
```
M3 Must
```
```
FR-ST- 006 System shall provide transcript with timestamps for review M2 Must
```

```
FR-ST- 007 System shall allow manual correction of transcription errors M2 Must^
FR-ST- 008 System shall mark low-confidence words/phrases for human
review
```
```
M3 Must^
```
### 3.3 Clinical Entity Extraction Module — Milestone 3

```
Req ID Requirement Description Milestone Priority
```
```
FR-EE- 001 System shall extract diagnoses from clinical documentation M3 Must^
FR-EE- 002 System shall identify procedures and treatments performed M3 Must^
FR-EE- 003 System shall recognize anatomical locations and laterality
(left/right)
```
```
M3 Must^
```
```
FR-EE- 004 System shall extract temporal relationships between
procedures
```
```
M3 Should^
```
```
FR-EE- 005 System shall identify patient demographics from EMR
integration
```
```
M2 Must^
```
```
FR-EE- 006 System shall extract insurance/payer information for the
encounter
```
```
M2 Must^
```
```
FR-EE- 007 System shall provide confidence scores for each extracted
entity
```
```
M3 Must^
```
### 3.4 Code Mapping Module — Milestone 3

```
Req ID Requirement Description Milestone Priority
FR-CM-
001
```
```
System shall map extracted diagnoses to ICD-10 codes M3 Must
```
```
FR-CM-
002
```
```
System shall map procedures to appropriate CPT codes M3 Must
```
```
FR-CM-
003
```
```
System shall suggest appropriate CPT modifiers based on
context (-59, -51, -LT/RT, etc.)
```
```
M3 Must
```
```
FR-CM-
004
```
```
System shall provide confidence scores for each code
mapping
```
```
M3 Must^
```
```
FR-CM-
005
```
```
System shall suggest alternative codes for low-confidence
mappings (<80%)
```
```
M3 Must^
```
```
FR-CM-
006
```
```
System shall validate code combinations against NCCI/CCI
edits
```
```
M3 Must^
```
```
FR-CM-
007
```
```
System shall support neurosurgery-specific code sets (5- 10
common spine procedures)
```
```
M3 Must^
```
```
FR-CM-
008
```
```
System shall support orthopedic surgery-specific code sets M3 Should^
```
```
FR-CM-
009
```
```
System shall apply confidence thresholds: >90% auto-
suggest, 70-90% flag for review, <70% require manual coding
```
```
M3 Must^
```

```
FR-CM-
010
```
```
System shall determine and assign Medical Decision Making
(MDM) level based on clinical documentation complexity
```
```
M3 Must^
```
```
FR-CM-
011
```
```
System shall generate medical necessity justification text to
support assigned codes
```
```
M3 Must^
```
### 3.5 RAG-Powered Claim Scrubbing Module — Milestone 3

```
Req ID Requirement Description Milestone Priority
```
```
FR-RS-
001
```
```
System shall scrub generated claims against payer-specific
rules using RAG
```
```
M3 Must^
```
```
FR-RS-
002
```
```
System shall validate claims against NCCI edits for improper
code pair detection
```
```
M3 Must^
```
```
FR-RS-
003
```
```
System shall check claims against Local Coverage
Determinations (LCD)
```
```
M3 Must
```
```
FR-RS-
004
```
```
System shall check claims against National Coverage
Determinations (NCD)
```
```
M3 Must
```
```
FR-RS-
005
```
```
System shall flag claims failing scrubbing rules with specific
failure reasons
```
```
M3 Must
```
```
FR-RS-
006
```
```
System shall suggest corrective actions for failed scrubbing
checks
```
```
M3 Should
```
```
FR-RS-
007
```
```
RAG corpus shall include: policy docs per plan, coding
manuals, cheat sheets, billing guidelines
```
```
M3 Must
```
### 3.6 Payer Rules Engine — Milestones 3- 4

```
Req ID Requirement Description Milestone Priority
FR-PR-
001
```
```
System shall maintain payer-specific coding rules for top 30
local plans
```
```
M3 Must
```
```
FR-PR-
002
```
```
System shall apply different coding strategies based on payer M3 Must^
```
```
FR-PR-
003
```
```
System shall incorporate historical denial pattern analysis M3 Must^
```
```
FR-PR-
004
```
```
System shall flag claims at high risk of denial based on
historical patterns
```
```
M4 Must^
```
```
FR-PR-
005
```
```
System shall optimize code selection for maximum
reimbursement
```
```
M3 Must^
```
```
FR-PR-
006
```
```
System shall allow manual update of payer rules by billing
staff
```
```
M4 Must^
```
```
FR-PR-
007
```
```
System shall track payer rule changes with version history M4 Should^
```
### 3.7 Claim Generation Module — Milestone 4


```
Req ID Requirement Description Milestone Priority
FR-CG-
001
```
```
System shall generate complete billing claims from processed
data
```
```
M4 Must
```
```
FR-CG-
002
```
```
System shall populate all required CMS-1500 claim fields
automatically
```
```
M4 Must
```
```
FR-CG-
003
```
```
System shall consolidate multi-session audio into single
patient claim
```
```
M4 Must
```
```
FR-CG-
004
```
```
System shall validate claim completeness before presenting
for review
```
```
M4 Must
```
```
FR-CG-
005
```
```
System shall generate claims in CMS-1500 professional
format
```
```
M4 Must
```
```
FR-CG-
006
```
```
System shall support multi-session audio consolidation
including recordings spanning multiple days for a single
surgical encounter
```
```
M4 Must
```
```
FR-CG-
007
```
```
System shall implement claim state machine with defined
states: Draft, Pending STT, Pending AI Review, Ready for
Human Review, Approved, Rejected, Exported
```
```
M4 Must
```
### 3.8 Human Review Workflow — Milestone 4

```
Req ID Requirement Description Milestone Priority
```
```
FR-HR-
001
```
```
System shall present claims for mandatory human review
before finalization
```
```
M4 Must^
```
```
FR-HR-
002
```
```
System shall highlight AI-generated content for reviewer
attention
```
```
M4 Must^
```
```
FR-HR-
003
```
```
System shall display original audio/transcript alongside
generated claim (side-by-side view)
```
```
M4 Must^
```
```
FR-HR-
004
```
```
System shall allow reviewers to modify any claim field M4 Must^
```
```
FR-HR-
005
```
```
System shall track all reviewer corrections for model
retraining feedback loop
```
```
M4 Must^
```
```
FR-HR-
006
```
```
System shall require explicit approval before claim finalization M4 Must
```
```
FR-HR-
007
```
```
System shall support claim rejection with reason capture and
re-routing to biller for manual correction
```
```
M4 Must
```
```
FR-HR-
008
```
```
System shall maintain complete audit trail of all claim
modifications
```
```
M4 Must
```
```
FR-HR-
009
```
```
System shall display EMR data (demographics, insurance)
alongside claim for cross-reference
```
```
M4 Must
```
### 3.9 EMR Integration — Milestones 2- 4


```
Req ID Requirement Description Milestone Priority
FR-EMR-
001
```
```
System shall integrate with Epic via FHIR R4 API for hospital
records (operative reports, clinical notes)
```
```
M4 Must
```
```
FR-EMR-
002
```
```
System shall integrate with Athena Centricity for billing data,
denied claims, patient records
```
```
M2 Must
```
```
FR-EMR-
003
```
```
System shall integrate with CureMD via REST API for patient
demographics and clinical docs
```
```
M2 Must
```
```
FR-EMR-
004
```
```
System shall retrieve patient demographics from EMR M2 Must
```
```
FR-EMR-
005
```
```
System shall retrieve insurance/payer information from EMR M2 Must
```
```
FR-EMR-
006
```
```
System shall retrieve clinical documentation and notes from
EMR
```
```
M2 Must
```
```
FR-EMR-
007
```
```
System shall handle EMR connection failures gracefully with
retry logic
```
```
M4 Must
```
### 3.10 Reporting and Analytics — Milestone 5

```
Req ID Requirement Description Milestone Priority
FR-RA-
001
```
```
System shall provide dashboard with claim processing status
(pending, approved, rejected, exported)
```
```
M5 Must^
```
```
FR-RA-
002
```
```
System shall display AI accuracy metrics (STT WER, code
mapping accuracy)
```
```
M5 Must^
```
```
FR-RA-
003
```
```
System shall track and report claim approval/rejection rates M5 Must^
```
```
FR-RA-
004
```
```
System shall provide human correction rate analytics (per
coder, per payer)
```
```
M5 Must^
```
```
FR-RA-
005
```
```
System shall generate audit reports for compliance review M5 Must^
```
```
FR-RA-
006
```
```
System shall support search/filter claims by patient, date
range, status, payer
```
```
M5 Must^
```
```
FR-RA-
007
```
```
System shall track same-day charge capture rate (target:
80%)
```
```
M5 Must^
```
### [NEW] 3.11 Notification System — Milestone 4

```
Req ID Requirement Description Milestone Priority
FR-NT- 001 System shall notify billers when a new claim is ready for
review
```
```
M4 Must
```
```
FR-NT- 002 System shall notify providers when a claim is approved or
requires attention
```
```
M4 Should
```
```
FR-NT- 003 System shall support in-app push notifications on mobile M4 Should
```

```
FR-NT- 004 System shall support email notifications for critical events M4 Should^
```
### [NEW] 3.12 Data Migration & Model Training Pipeline — Milestones 1, 3,

### 6

```
Req ID Requirement Description Milestone Priority
```
```
FR-DM-
001
```
```
System shall provide ETL pipeline to extract, clean, and load
historical billing data from Athena Centricity
```
```
M1 Must^
```
```
FR-DM-
002
```
```
System shall filter historical data per-payer based on policy
change dates to exclude outdated patterns
```
```
M1 Must^
```
```
FR-DM-
003
```
```
System shall ingest and index policy documents, coding
manuals, and cheat sheets into the RAG vector store
```
```
M1 Must^
```
```
FR-DM-
004
```
```
System shall capture human reviewer corrections in a
structured format suitable for model retraining
```
```
M4 Must^
```
```
FR-DM-
005
```
```
System shall support periodic model retraining/fine-tuning
using accumulated correction data (manual trigger in MVP)
```
```
M6 Should^
```

## 4. Non-Functional Requirements

### 4.1 Performance Requirements

```
Req ID Requirement Target Milestone
NFR-P-
001
```
```
Speech-to-text processing time per minute of
audio
```
```
< 90 seconds M
```
```
NFR-P-
002
```
```
Claim generation time from completed transcript < 90 seconds M
```
```
NFR-P-
003
```
```
Web dashboard page load time < 3 seconds M
```
```
NFR-P-
004
```
```
Mobile app recording start latency < 2 seconds M
```
```
NFR-P-
005
```
```
Provider submission workflow completion
(dictate to approve)
```
```
< 1 minute M
```
```
NFR-P-
006
```
```
Concurrent users supported 20+ simultaneous M
```
### 4.2 Security Requirements

```
Req ID Requirement Milestone
```
```
NFR-S-
001
```
```
All PHI shall be encrypted at rest using AES-256 encryption M
```
```
NFR-S-
002
```
```
All data in transit shall be encrypted using TLS 1.3 M
```
```
NFR-S-
003
```
```
User authentication shall use OAuth 2.0 with multi-factor authentication M
```
```
NFR-S-
004
```
```
Role-based access control shall restrict data access by user role M
```
```
NFR-S-
005
```
```
All user actions shall be logged in tamper-proof audit trail M
```
```
NFR-S-
006
```
```
Session timeout shall occur after 15 minutes of inactivity M
```
```
NFR-S-
007
```
```
AI inference shall occur entirely within VPC-isolated, HIPAA-compliant
infrastructure
```
##### M

```
NFR-S-
008
```
```
No PHI shall be transmitted to external cloud AI services M
```
### 4.3 Reliability and Availability

```
Req ID Requirement Milestone
```

```
NFR-R-
001
```
```
System availability target: 99.5% during business hours (6 AM - 10 PM
ET)
```
##### M

```
NFR-R-
002
```
```
Mean time to recovery from failure: < 4 hours M
```
```
NFR-R-
003
```
```
Database backup frequency: Daily with 30-day retention M
```
```
NFR-R-
004
```
```
Audio file retention: 7 years (aligned with HIPAA audit trail requirements) M
```
```
NFR-R-
005
```
```
Graceful degradation when EMR integration is unavailable M
```
### 4.4 Compliance Requirements

```
Req ID Requirement Milestone
NFR-C-
001
```
```
System shall comply with HIPAA Privacy Rule requirements M
```
```
NFR-C-
002
```
```
System shall comply with HIPAA Security Rule requirements M
```
```
NFR-C-
003
```
```
Business Associate Agreement (BAA) required with all cloud providers M
```
```
NFR-C-
004
```
```
Complete audit trails shall be maintained for minimum 7 years M
```
```
NFR-C-
005
```
```
System shall support compliance reporting for audits M
```
### 4.5 Usability Requirements

```
Req ID Requirement Milestone
```
```
NFR-U-
001
```
```
Mobile app shall require < 3 taps to start recording M
```
```
NFR-U-
002
```
```
New billers shall be productive within 4 hours of training M
```
```
NFR-U-
003
```
```
Web interface shall be accessible on screen sizes >= 1280px width M
```
```
NFR-U-
004
```
```
System shall provide clear error messages with suggested corrective
actions
```
##### M


## 5. System Architecture

### 5.1 Architecture Overview

The system follows a modular, layered architecture designed for scalability and future
expansion to agentic AI capabilities. The architecture separates concerns across four distinct
layers.

#### 5.1.1 Experience Layer

- Web Dashboard (React.js + TypeScript): Primary interface for billers to review claims
    and view analytics
- Mobile App (React Native / Expo): Smartphone-based audio capture, template selection,
    and claim status
- REST API Gateway: Secure API with OAuth 2.0 authentication, rate limiting, and routing

#### 5.1.2 Processing Layer

- Workflow Engine: Orchestrates the claim generation pipeline (audio → transcript →
    entities → codes → claim)
- Business Rules Engine: Implements payer-specific billing rules and optimization logic
- Claim Scrubbing Engine: RAG-powered validation against NCCI, LCD/NCD, and payer
    rules
- NLP Processor: Coordinates speech-to-text and clinical entity extraction

#### 5.1.3 AI Layer

- Open Source LLM: Self-hosted Llama/Mistral/Mixtral/Qwen with LoRA fine-tuning
- Speech-to-Text Engine: Whisper with medical vocabulary fine-tuning
- Vector Database: For semantic search and RAG (pgvector or Weaviate/Pinecone)

#### 5.1.4 Data Layer

- Knowledge Base: Vector database for semantic search across policy docs, coding
    manuals, cheat sheets
- Historical Data: Billing and denial history (filtered per-payer by policy change dates)
- Operational Database: PostgreSQL for claims, users, transactions, and audit logs

### 5.2 Technology Stack

```
Layer Technology Rationale
Frontend React.js + TypeScript Modern, maintainable UI
```
```
Mobile React Native / Expo Cross-platform iOS/Android
API Server FastAPI (Python) High performance, async, ML
ecosystem
```
```
LLM Llama/Mistral/Mixtral + LoRA Open source, fine-tunable, self-
hostable
```
```
Speech-to-Text Whisper (OpenAI) High accuracy, self-hostable, medical
fine-tuning
```

```
Database PostgreSQL + pgvector Structured + vector search in single
DB
Cache Redis Session management, API caching
```
```
Hosting AWS/GCP/Azure (HIPAA BAA) Cloud-hosted, VPC isolation, scalable
```
### 5.3 Deployment Architecture

The MVP deployment is designed for cloud-hosted operation within a HIPAA-compliant VPC:

- Application Server: Cloud VM (8+ cores, 32GB RAM) for API, workflow engine, and web
    app
- AI Inference: GPU-enabled cloud instance or Mac Mini M-series for LLM and Whisper
- Database: PostgreSQL with pgvector extension on managed service (RDS/Cloud SQL)
- Storage: Encrypted object storage for audio files and documents
- Estimated monthly infrastructure cost: $1,100-1,600/month


## 6. EMR Integration Specifications

### 6.1 Epic Integration (Hospital)

```
Attribute Specification
Integration Method FHIR R4 API
```
```
Authentication OAuth 2.0 with SMART on FHIR
Data Retrieved Patient demographics, encounters, operative reports, clinical notes,
insurance
```
```
Environment Hospital inpatient and surgical records
Risk Epic FHIR approval can take 3-6 months. Timeline contingency required.
```
### 6.2 Athena Centricity Integration (Outpatient Legacy)

```
Attribute Specification
```
```
Integration Method Custom API Connector (legacy Centricity version — confirm actual version
and API limitations)
```
```
Data Retrieved Historical billing data, denied claims with reason codes, patient records
Note Existing connector available — reduces integration time. Emily has flagged
potential roadblocks with older Centricity version vs modern Athena API.
```
### 6.3 CureMD Integration (Outpatient)

```
Attribute Specification
Integration Method REST API
```
```
Data Retrieved Patient demographics, appointments, clinical documentation
Note Existing connector available — reduces integration time
```
### [NEW] 6.4 ModMed — Formally Excluded from MVP

ModMed was listed in the original project brief but has been dropped from all subsequent
documents. It is formally excluded from MVP scope. If needed in a future phase, a separate
integration SOW will be required.


## 7. MVP Scope Definition

### 7.1 In Scope (MVP)

1. Integration with Epic (hospital) and Athena Centricity/CureMD (outpatient)
2. Speech-to-text with medical dictionary (smartphone-based capture via Expo/React
    Native)
3. AI-powered claim generation from clinical documentation (5-10 common spine surgery
    types)
4. RAG-powered claim scrubbing against NCCI edits and LCD/NCD coverage
    determinations
5. Payer-specific CPT code optimization for top 30 local plans (starting with top 10)
6. Template-based fast-track workflow for standard procedures
7. Human review interface with mandatory approval workflow
8. Complete audit trails for compliance
9. Manual policy updates by billing staff
10. Single-practice deployment (Dr. McHugh’s practice, up to 5 providers)
11. CMS-1500 professional claims (surgical billing focus)
12. Provider interface supporting dictate → review → approve → submit workflow
13. Analytics dashboard with claim status, AI accuracy, and correction rates

### 7.2 Out of Scope (Future Phases)

- Self-learning/auto-updating rules engine
- Agentic AI capabilities
- Dedicated hardware dictation devices
- Multi-accent speech recognition optimization
- Offline/mobile-only processing
- Multi-practice/multi-tenant deployment
- Full automation without human review
- Outpatient clinic visit (E/M) billing automation
- Direct clearinghouse/EDI submission integration (837P/837I)
- Denial appeals automation
- Payment posting and ERA/835 processing
- Patient billing and collections
- UB-04 institutional claims
- ModMed integration
- Operative report generation/amendment


## 8. Project Timeline — SOW Milestone Aligned

### 8.1 Milestone Schedule

```
Phase Deliverable Target Date Duration SOW Milestone
Kick
Off
```
```
Scope & Team
Walkthrough
```
```
04 Feb 2026 — —
```
```
Phase
1
```
```
Foundation & Architecture 11 Mar 2026 5 weeks M1: Infrastructure
```
```
Phase
2
```
```
Core Platform
Development
```
```
22 Apr 2026 6 weeks M2: Core Platform
```
```
Phase
3
```
```
AI Engine Development 24 Jun 2026 9 weeks M3: AI Engine
```
```
Phase
4
```
```
Integration & Workflow 12 Aug 2026 7 weeks M4: Integration
```
```
Phase
5
```
```
Testing & Go-Live 23 Sep 2026 6 weeks M5: Go-Live
```
```
Phase
6
```
```
Support & Maintenance Post go-live Ongoing M6: Support
```
### 8.2 Phase Details with Deliverables

#### Milestone 1 — Foundation & Architecture (Weeks 1-5)

- HIPAA-compliant cloud infrastructure setup (VPC, encryption, IAM)
- Database schema design and deployment (PostgreSQL + pgvector)
- Authentication and RBAC framework (OAuth 2.0 + MFA)
- API gateway and security layer
- CI/CD pipeline configuration
- Historical data extraction from Athena Centricity (ETL pipeline)
- Data cleaning and filtering (per-payer policy change date filtering)
- Policy document collection and RAG corpus preparation

**Acceptance: Infrastructure operational, data pipeline running, security audit passed.**

#### Milestone 2 — Core Platform Development (Weeks 6-11)

- Web dashboard foundation (React.js + TypeScript)
- Mobile app with audio capture (Expo/React Native)
- Speech-to-text module integration (Whisper base)
- Athena Centricity connector implementation
- CureMD API connector implementation
- Patient lookup and encounter linking via EMR
- Template-based fast-track UI for standard procedures

**Acceptance: Audio capture working end-to-end, EMR data retrieval functional, basic
transcript generation.**


#### Milestone 3 — AI Engine Development (Weeks 8-17)

- LLM fine-tuning on billing data using LoRA (orthopedic/neurosurgery domain)
- Medical vocabulary fine-tuning for Whisper STT
- Clinical entity extraction pipeline (NLP)
- ICD-10 and CPT code mapping engine with confidence scoring
- RAG pipeline for claim scrubbing (NCCI, LCD/NCD, payer rules)
- Business rules engine with payer-specific optimization
- Modifier logic implementation

**Acceptance: AI generates claims for test cases with ≥90% code mapping accuracy, STT
≥97% WER on test corpus.**

#### Milestone 4 — Integration & Workflow (Weeks 15-21)

- End-to-end pipeline integration (audio → transcript → entities → codes → claim)
- Human review interface with side-by-side transcript/claim/EMR view
- Claim correction workflow with model feedback loop
- Epic FHIR integration (contingent on API access approval)
- Audit trail and compliance logging
- Notification system for claim events
- Claim export mechanism for downstream processing

**Acceptance: Full workflow functional, human review working, audit trails complete.**

#### Milestone 5 — Testing & Go-Live (Weeks 19-24)

- User acceptance testing with billing staff (real claim scenarios)
- Bug fixes and performance optimization
- Analytics dashboard and reporting
- Documentation and training materials
- Go-live preparation and cutover support
- Pilot with 1-3 surgeons, then rapid expansion

**Acceptance: UAT sign-off, 80% same-day charge capture target met, system stable in
production.**

#### Milestone 6 — Support & Maintenance (Post Go-Live)

- Ongoing bug fixes and performance monitoring
- Model retraining based on correction feedback
- Payer rule updates as policies change
- System monitoring and infrastructure management


## 9. Success Metrics

```
Metric Target Measured At
Same-day charge capture rate 80% M5 Go-Live
```
```
Claim denial reduction 10 - 25% reduction 3 months post go-live
A/R cycle improvement 5 - 10 days faster 3 months post go-live
```
```
Provider submission time (dictate to approve) < 1 minute M5 UAT
```
```
STT accuracy (Word Error Rate) ≥97% on test corpus M3 acceptance
Code mapping accuracy ≥90% on test cases M3 acceptance
```

## 10. Risk Assessment

```
Risk Impact Detail Mitigation
AI Hallucination HIGH^ Incorrect codes generated and
submitted
```
```
Mandatory human review for all
claims; confidence thresholds
with escalation
```
```
Epic API Delay HIGH^ FHIR approval can take 3- 6
months; blocks hospital
integration
```
```
Begin Epic approval process
immediately; build with mock
data; Epic integration is M4
deliverable allowing parallel work
```
```
STT Accuracy HIGH^ 99% target unrealistic; industry
standard is 95-98%
```
```
Revised to ≥97% WER; medical
vocabulary fine-tuning; noise
reduction; iterative improvement
via feedback loop
```
```
Policy Staleness MED^ Outdated rules cause denials Manual updates by billing staff in
MVP; per-payer relevance
filtering; future auto-learning
```
```
Data Quality MED^ Historical data has gaps or
errors
```
```
Data validation phase in M1; filter
obsolete records per-payer; SME
review of training data
Adoption Friction MED^ Users resist workflow changes Smartphone-only capture (no
hardware); template fast-track for
routine procedures; < 1 min
submission target
Security Breach HIGH^ PHI exposure Self-hosted LLM within VPC;
AES-256 encryption; HIPAA
controls; no external AI API calls
```
```
Integration Delays MED^ EMR API access issues
(especially Athena legacy)
```
```
Existing connectors for
Athena/CureMD; confirm
Centricity version; early API
testing in M1
```
```
Scope Creep MED^ Requirements grow beyond
agreed MVP
```
```
Strict scope freeze after M1;
change requests require written
approval with cost/timeline
impact
```

## 11. Open Questions Requiring Resolution

The following items must be resolved before or during Phase 1. Items marked CRITICAL block
development if unresolved.

### 11.1 Development-Critical Questions

```
# Question Priority Owner
```
```
Q1 What are the 5-10 common spine surgery types for
MVP with their typical CPT + ICD-10 code
combinations?
```
**CRITICAL** (^) Dr. McHugh / Billing
team
Q2 What is the Athena Centricity version? What APIs
are available? (Emily flagged potential legacy
roadblocks)
**CRITICAL** (^) Emily / Tech team
Q3 Is Epic FHIR API access already granted or is
approval still pending? What is the expected
timeline?
**CRITICAL** (^) Emily
Q4 What is the exact claim handoff mechanism to
Athena? (API push, file import, manual re-entry?)
**CRITICAL** (^) Emily
Q5 What is the timeline for receiving historical billing
data and payer policy documents?
**CRITICAL** (^) Emily
Q6 What is the prioritized list of top 30 insurance
plans? (Start with top 10 for initial validation)
**HIGH** (^) Emily / Billing team
Q7 What patient identifier links audio to EMR? (MRN,
encounter ID, manual entry, or EMR lookup?)
**HIGH** (^) Dr. McHugh / Emily
Q8 Mobile platforms: iOS only, Android only, or both
required for MVP?
**HIGH** (^) Dr. McHugh
Q9 What specific data fields should be pulled from
Epic vs Athena vs CureMD for a given claim?
**HIGH** (^) Emily / Billing team
Q10 Expected daily volume: how many audio
recordings per day, average length per recording?
**HIGH** (^) Dr. McHugh
Q11 Total concurrent users (providers + billers +
admin)?
**HIGH** (^) Emily
Q12 What format should approved claims be exported
in? (PDF CMS-1500, data file, API push to Athena)
**HIGH** (^) Emily
Q13 Cloud provider preference: AWS vs GCP vs
Azure? (GCP recommended in cost analysis)
**MEDIUM** (^) Emily
Q14 Has infrastructure budget (~$1,100-1,600/month)
been confirmed?
**MEDIUM** (^) Emily
Q15 What notification methods are required? (Email,
SMS, in-app push, or combination)
**MEDIUM** (^) Emily


_Note: CRITICAL questions must be resolved before Phase 1 can be completed. HIGH questions
must be resolved before Phase 2 begins._


## 12. Stakeholders and Team Structure

### 12.1 Client Stakeholders

```
Role Name Contact
Executive Sponsor Dr. Brian McHugh DrMcHugh@mchughneurosurgery.com
```
```
Project Manager Emily Clifford emily@farmtotablehealth.com / +1 (716) 983- 2572
```
### 12.2 Implementation Partner (Dextra Labs)

```
Role Name Email
Engagement
Partner
```
```
Vijay Agarwal vijay@dextralabs.com
```
```
Project Manager Gaurang Ghadigaonkar gaurang.ghadigaonkar@dextralabs.com
Solution Architect Yasha Khandelwal yasha@dextralabs.com
```
```
Technical Lead TBD —
```
### 12.3 Development Partner (Tech4Biz Solutions Pvt Ltd)

Tech4Biz Solutions serves as the development partner, providing technical execution and
existing EMR connector expertise (Athena Centricity, CureMD).


## 13. Document Approval

This Software Requirements Specification requires approval from the following stakeholders
before development proceeds:

```
Role Name Signature Date
```
```
Executive Sponsor Dr. Brian McHugh
```
Client PM Emily Clifford (^)
Engagement Partner Vijay Agarwal (Dextra) (^)
Solution Architect Yasha Khandelwal (Dextra) (^)

#### Document Version History:

```
Version Date Author Changes
```
```
1.0 03 Feb 2026 Yasha Initial draft based on discovery documents
1.1 03 Feb 2026 Yasha Added open questions (Sec 10), clarified system
boundary (Sec 1.3)
2.0 16 Feb 2026 Yasha Major revision: SOW milestone alignment, template fast-
track workflow, RAG claim scrubbing, OON billing
context, scope narrowing (5-10 spine procedures, 5
providers, CMS-1500 only), STT accuracy revised to 97%
WER, ModMed/UB-04 formally excluded, confidence
thresholds, notification system, success metrics, MDM
level generation, medical necessity justification, claim
state machine, data migration ETL pipeline, model
retraining pipeline, all requirements mapped to
milestones. Removed all references to specific AI model
names — SRS is now technology-agnostic on AI model
selection.
```
```
— End of Document —
```