1. Executive Summary
This document defines the business requirements for the eSHARS (Electronic School Health and Related Services) system, a comprehensive Medicaid billing and compliance platform for Texas school districts.
2. Business Context
2.1 Industry Background
Texas school districts can receive Medicaid reimbursement for health services provided to special education students through the SHARS (School Health and Related Services) program. Services include:
- Speech Therapy
- Occupational Therapy (OT)
- Physical Therapy (PT)
- Psychological Services
- Nursing Services
- Audiology
- Personal Care
- Special Transportation
2.2 Business Problem
School districts need to:
- Document every billable service visit with compliance requirements
- Verify student Medicaid eligibility
- Submit claims to Texas Medicaid (TMHP)
- Track reimbursements and manage receivables
- Maintain audit-ready documentation for federal/state reviews
- Manage provider credentials and qualifications
2.3 Business Objectives
| Objective | Description |
|---|
| Maximize Revenue | Capture all billable services and ensure proper documentation |
| Ensure Compliance | Meet all Medicaid, HIPAA, and FERPA requirements |
| Reduce Administrative Burden | Automate eligibility checks and billing |
| Provide Visibility | Real-time reporting for districts and state |
| Support Audits | Complete documentation trail for reviews |
3. Functional Requirements
FR-1: Organization Management
| ID | Requirement | Priority |
|---|
| FR-1.1 | System shall support hierarchical organization: State → District → Campus | Critical |
| FR-1.2 | Each level shall have configurable settings that can inherit or override parent | High |
| FR-1.3 | Districts shall have EDI identifiers (TPI, NPI) for billing | Critical |
| FR-1.4 | Campuses shall be assignable to districts with effective dates | High |
| FR-1.5 | System shall support district deactivation with date tracking | Medium |
| FR-1.6 | Districts shall have configurable calendars for school year tracking | High |
| FR-1.7 | System shall support district-specific system settings (FTP, SFTP, email) | High |
FR-2: User Management
| ID | Requirement | Priority |
|---|
| FR-2.1 | System shall support role-based access control (RBAC) | Critical |
| FR-2.2 | Users shall have qualifications (OT, PT, Speech, Nursing, etc.) | Critical |
| FR-2.3 | Qualifications shall determine which services users can provide | Critical |
| FR-2.4 | Users shall be assignable to multiple campuses | High |
| FR-2.5 | System shall support user impersonation for admin support | Medium |
| FR-2.6 | System shall enforce password policies (7+ chars, mixed case, digit, special) | Critical |
| FR-2.7 | System shall support two-factor authentication (2FA) via email | Critical |
| FR-2.8 | System shall lock accounts after 5 failed login attempts | High |
| FR-2.9 | Users shall have certificates and licenses tracked with expiration dates | High |
FR-3: Student Management
| ID | Requirement | Priority |
|---|
| FR-3.1 | System shall maintain student demographic information | Critical |
| FR-3.2 | Students shall have multiple identifiers (Student ID, TX Student ID, Medicaid ID, PEIMS, SSN) | Critical |
| FR-3.3 | System shall track Medicaid eligibility status and effective dates | Critical |
| FR-3.4 | System shall track parental consent with consent dates | Critical |
| FR-3.5 | Students shall be assignable to services (OT, PT, Speech, etc.) | Critical |
| FR-3.6 | System shall track campus enrollment history with date ranges | High |
| FR-3.7 | System shall track transportation routes (AM pickup, PM dropoff) | Medium |
| FR-3.8 | System shall support student attachments (documents, files) | Medium |
| FR-3.9 | System shall track prescriptions and referrals (Rx/Referral) | High |
FR-4: ARD/Service Activation Management
| ID | Requirement | Priority |
|---|
| FR-4.1 | System shall track ARD (IEP) service hours per service type | Critical |
| FR-4.2 | System shall enforce service hour limits during visit creation | Critical |
| FR-4.3 | System shall display remaining hours against allocation | High |
| FR-4.4 | Districts shall configure goal enforcement by service category | High |
| FR-4.5 | System shall support service dismissal workflow with effective dates | Medium |
| FR-4.6 | ARD records shall have start and end dates | Critical |
| FR-4.7 | System shall track instructional weeks for ARD periods | High |
| FR-4.8 | ARD records shall be lockable to prevent modifications | Medium |
FR-5: Visit Management
| ID | Requirement | Priority |
|---|
| FR-5.1 | Clinicians shall create visits for students on their caseload | Critical |
| FR-5.2 | System shall support 60+ visit types across service categories | Critical |
| FR-5.3 | Visits shall capture: date, duration, service type, goals addressed, session notes | Critical |
| FR-5.4 | System shall validate visits against ARD hours, eligibility, parental consent | Critical |
| FR-5.5 | Visits shall support approval workflow (clinician release → supervisor approval) | High |
| FR-5.6 | System shall support group visits for multiple students | High |
| FR-5.7 | Clinicians shall view visit history by student and date range | High |
| FR-5.8 | System shall support visit copying for efficiency | Medium |
| FR-5.9 | System shall link visits to student prescriptions | High |
| FR-5.10 | Visits shall track billing status (billable, billed, paid, denied) | Critical |
FR-6: Caseload Management
| ID | Requirement | Priority |
|---|
| FR-6.1 | Clinicians shall have assigned student caseloads | Critical |
| FR-6.2 | Caseloads shall be filterable by campus, student name, service | High |
| FR-6.3 | Clinicians shall create student groups for group sessions | Medium |
| FR-6.4 | System shall notify clinicians of new students assigned | Medium |
| FR-6.5 | System shall notify clinicians of new Medicaid-eligible students | Medium |
| FR-6.6 | System shall notify clinicians of approved/rejected visits | Medium |
| FR-6.7 | Clinicians shall have a schedule view of their activities | Medium |
FR-7: EDI/Eligibility Management
| ID | Requirement | Priority |
|---|
| FR-7.1 | System shall generate 270 eligibility requests to TMHP | Critical |
| FR-7.2 | System shall process 271 eligibility responses | Critical |
| FR-7.3 | Eligibility checks shall be schedulable (automated recurring) | High |
| FR-7.4 | System shall support multiple matching algorithms (SSN+DOB, Name+DOB, Medicaid+SSN) | High |
| FR-7.5 | System shall create and manage billing transactions | Critical |
| FR-7.6 | Billing transactions shall be schedulable per district | High |
| FR-7.7 | System shall support bulk status moves for visits | Medium |
| FR-7.8 | System shall track eligibility status over last 3 days on dashboard | High |
| FR-7.9 | System shall track appeal status over last 3 days on dashboard | High |
| FR-7.10 | System shall support end-of-year cleanup processes | High |
FR-8: Appeals Management
| ID | Requirement | Priority |
|---|
| FR-8.1 | Clinicians shall submit appeals for rejected/denied visits | High |
| FR-8.2 | Supervisors/admins shall approve or reject appeals | High |
| FR-8.3 | System shall track appeal history and status changes | High |
| FR-8.4 | Bulk approval shall be supported for efficiency | Medium |
| FR-8.5 | Appeals shall be searchable by district, provider, status, date range | High |
| FR-8.6 | System shall track who approved/rejected and when | High |
FR-9: Finance Management
| ID | Requirement | Priority |
|---|
| FR-9.1 | System shall generate invoices for districts by fiscal year/month | Critical |
| FR-9.2 | Invoices shall track line items, total amounts, and status | Critical |
| FR-9.3 | System shall track receivables with payment status (paid, unpaid, partial) | High |
| FR-9.4 | System shall support credit memos | Medium |
| FR-9.5 | System shall generate cost reports for Medicaid | High |
| FR-9.6 | System shall track settlement amounts (proposed and final) | High |
| FR-9.7 | System shall provide revenue reports by campus and district | High |
| FR-9.8 | System shall support revenue data import | Medium |
| FR-9.9 | System shall track contract details and fee structures per district | High |
| FR-9.10 | Invoices shall be printable (individual and bulk) | High |
FR-10: Reporting
| ID | Requirement | Priority |
|---|
| FR-10.1 | System shall provide activity tracking reports | High |
| FR-10.2 | System shall provide district ARD reports | High |
| FR-10.3 | System shall provide district revenue reports | High |
| FR-10.4 | System shall provide district tabulation reports | High |
| FR-10.5 | System shall provide eligible visits without parental consent reports | High |
| FR-10.6 | System shall provide district appeals reports | High |
| FR-10.7 | System shall support ad-hoc reporting | Medium |
| FR-10.8 | Reports shall be exportable to Excel | High |
| FR-10.9 | Reports shall be exportable to PDF | High |
| FR-10.10 | Finance reports shall include: Certification of Funds, Client Revenue, Cost Report Comparative Analysis, Disallowed Visits, District Federal Cap, IEP Report | High |
FR-11: Import/Export
| ID | Requirement | Priority |
|---|
| FR-11.1 | System shall support batch import of students | High |
| FR-11.2 | System shall support batch import of users | High |
| FR-11.3 | System shall support import of ARD/goals data | High |
| FR-11.4 | System shall support import of prescriptions and parental consent | High |
| FR-11.5 | System shall track import batches with row counts, processed counts, and errors | High |
| FR-11.6 | System shall support multiple import types via templates | High |
| FR-11.7 | Import files shall be uploadable via drag-and-drop | Medium |
| FR-11.8 | System shall support GE Paid Visit Data upload (Custom TR Matching) | Medium |
FR-12: Signature Authorization
| ID | Requirement | Priority |
|---|
| FR-12.1 | Providers shall complete annual signature authorization (SA) forms | Critical |
| FR-12.2 | System shall track SA form status (received, approved, paper signed) | High |
| FR-12.3 | System shall support paper attachment upload for signed forms | Medium |
| FR-12.4 | SA forms shall be downloadable as PDF | High |
| FR-12.5 | SA forms shall be exportable to Excel | Medium |
| FR-12.6 | System shall track SA disagree with reasons | Medium |
FR-13: Audit & Compliance
| ID | Requirement | Priority |
|---|
| FR-13.1 | System shall maintain complete audit trail of all data changes | Critical |
| FR-13.2 | Audit logs shall be searchable by record type, user, date range | High |
| FR-13.3 | System shall track user login/logout events | High |
| FR-13.4 | System shall support user traceability logs (view, add, update, delete) | High |
| FR-13.5 | Audit logs shall be filterable by action type | High |
| FR-13.6 | Audit logs shall be printable | Medium |
| FR-13.7 | Finance module shall have separate audit log for financial records | High |
FR-14: Background Jobs
| ID | Requirement | Priority |
|---|
| FR-14.1 | System shall support scheduled background jobs | High |
| FR-14.2 | Jobs shall be configurable per district (BillTransactionJob per ISD) | High |
| FR-14.3 | System shall display job execution history with timestamps | High |
| FR-14.4 | System shall show currently executing jobs | High |
| FR-14.5 | System shall log job errors for troubleshooting | High |
| FR-14.6 | System shall show TMHP service status (send to TMHP on/off) | High |
FR-15: Messaging & Notifications
| ID | Requirement | Priority |
|---|
| FR-15.1 | System shall support internal messaging between users | Medium |
| FR-15.2 | System shall support system-wide announcements | Medium |
| FR-15.3 | System shall support broadcast messages to user groups | Medium |
| FR-15.4 | Users shall see unread message count indicator | Medium |
FR-16: Training & Help (eSHARS University)
| ID | Requirement | Priority |
|---|
| FR-16.1 | System shall provide access to training materials | Medium |
| FR-16.2 | System shall provide FAQs | Medium |
| FR-16.3 | System shall provide step-by-step guides | Medium |
| FR-16.4 | System shall provide SHARS manual references | Medium |
4. Non-Functional Requirements
NFR-1: Security
| ID | Requirement | Priority |
|---|
| NFR-1.1 | System shall comply with HIPAA for protected health information (PHI) | Critical |
| NFR-1.2 | System shall comply with FERPA for student educational records | Critical |
| NFR-1.3 | System shall implement role-based access control with least privilege | Critical |
| NFR-1.4 | Data shall be encrypted at rest | Critical |
| NFR-1.5 | Data shall be encrypted in transit (TLS/HTTPS) | Critical |
| NFR-1.6 | System shall support two-factor authentication | High |
| NFR-1.7 | Sessions shall timeout after period of inactivity | High |
| NFR-1.8 | Accounts shall lock after failed login attempts | High |
| NFR-1.9 | Passwords shall meet complexity requirements | High |
| NFR-1.10 | System shall mask sensitive data (SSN, passwords) in UI | High |
| ID | Requirement | Priority |
|---|
| NFR-2.1 | System shall support 100+ concurrent users per district | High |
| NFR-2.2 | Page load times shall be under 3 seconds | High |
| NFR-2.3 | Batch imports shall process 10,000+ records efficiently | High |
| NFR-2.4 | Background jobs shall run during off-peak hours | Medium |
| NFR-2.5 | Database queries shall be optimized with proper indexing | High |
| NFR-2.6 | Grids shall support pagination for large datasets | High |
NFR-3: Availability
| ID | Requirement | Priority |
|---|
| NFR-3.1 | System shall maintain 99.9% uptime during business hours | High |
| NFR-3.2 | Scheduled maintenance shall occur during off-peak hours | Medium |
| NFR-3.3 | System shall support multiple environments (dev, QA, UAT, training, prod) | High |
| NFR-3.4 | Database backups shall be performed regularly | Critical |
NFR-4: Scalability
| ID | Requirement | Priority |
|---|
| NFR-4.1 | System shall support 100+ Texas school districts | High |
| NFR-4.2 | System shall support millions of student and visit records | High |
| NFR-4.3 | System shall scale for peak periods (end of year, billing cycles) | High |
| NFR-4.4 | Database shall support partitioning for large tables | Medium |
NFR-5: Usability
| ID | Requirement | Priority |
|---|
| NFR-5.1 | UI shall be responsive across desktop and tablet devices | High |
| NFR-5.2 | Navigation shall be consistent across all modules | High |
| NFR-5.3 | Error messages shall be clear and actionable | High |
| NFR-5.4 | Search and filter capabilities shall be provided on all grids | High |
| NFR-5.5 | Custom sorting shall be available on data grids | Medium |
| NFR-5.6 | Breadcrumb navigation shall show current location | Medium |
NFR-6: Maintainability
| ID | Requirement | Priority |
|---|
| NFR-6.1 | Code shall follow consistent naming conventions | High |
| NFR-6.2 | Business logic shall be separated from presentation | High |
| NFR-6.3 | Database changes shall use migration scripts | High |
| NFR-6.4 | Configuration shall be externalized (not hardcoded) | High |
| NFR-6.5 | Logging shall be comprehensive for troubleshooting | High |
5. User Roles and Permissions
5.1 Role Hierarchy
| Role | Level | Description |
|---|
| Super Admin | State | Full system access, all districts |
| State Reports | State | Read-only state-level reporting |
| Finance Admin | State | Finance module across districts |
| District Admin | District | Full access within assigned district |
| Campus Admin | Campus | Administration within assigned campuses |
| Supervisor | Campus | Approve visits, manage providers |
| Clinician | Campus | Document visits for assigned students |
5.2 Security Areas (Modules)
| Security Area | Description |
|---|
| Dashboard | Main dashboard and home screens |
| Global Data | Services, qualifications, home screen config |
| Data Management | State, district, campus, student, user data |
| EDI Management | Eligibility, billing transactions, bulk moves |
| Appeals | Appeal submission and approval |
| Imports | Batch data imports |
| Jobs | Background job management |
| Audit Log | Audit trail viewing |
| SA Submittals | Signature authorization forms |
| Messages | Internal messaging |
| Reports | Standard reports |
| Ad-Hoc Reports | Custom report builder |
| Security | User and role management |
| Finance | Invoicing, receivables, cost reports |
6. Glossary
| Term | Definition |
|---|
| ARD | Admission, Review, and Dismissal - Texas term for IEP meeting |
| EDI | Electronic Data Interchange |
| IEP | Individualized Education Program |
| NPI | National Provider Identifier |
| PEIMS | Public Education Information Management System |
| SHARS | School Health and Related Services |
| TMHP | Texas Medicaid & Healthcare Partnership |
| TPI | Texas Provider Identifier |
| 270/271 | EDI transaction codes for eligibility inquiry/response |
| SA | Signature Authorization |
For technical architecture details, see the Developer documentation.