A well-structured RFP for Medicaid premium billing should address these requirement categories:

• Population support. Which programs require billing (Medicaid expansion adults, CHIP, Medicaid children, buy-in programs)? What are the premium amounts and billing frequencies? Are there different rules per population?
• Payment methods. ACH, credit/debit cards, retail cash, checks/lockbox, stored-value cards. Specify which are required vs. desired.
• Delinquency management. Configurable event types, notice generation, grace periods, escalation rules, disenrollment triggers, balance transfer to state revenue.
• Integration requirements. Interfaces with enrollment/eligibility (MMIS), accounts receivable, financial reporting, state treasury, and claims systems. Specify data standards (web services, ANSI X.12 834, proprietary).
• Member portal. Online invoice viewing, payment processing, payment method storage, recurring payment enrollment, payment history.
• Invoicing. Electronic and paper invoice generation, configurable templates, custom notification language per population, responsible party/in-care-of support.
• Fees and credits. Support for community engagement credits, health risk assessment credits, electronic payment incentives, late fees, work requirement calculations, low-income subsidy credits.
• Reporting. CMS reporting support, state oversight reporting, financial reconciliation, collection rate analytics.
• Security and compliance. PCI DSS compliance, HIPAA, state-specific security requirements, data residency.
• Implementation. Timeline expectations, phased approach, pilot program support, CMS certification experience.

Premium billing software integrates with MMIS platforms through configurable interfaces that exchange data with multiple components of the state's system environment:

• Enrollment & Eligibility (inbound). The billing system receives enrollment data including member demographics, coverage details, premium amounts, effective dates, and eligibility category. This is the primary data feed that drives invoice generation. Formats: ANSI X.12 834, web services (REST/SOAP), or proprietary flat files.
• Accounts Receivable (outbound). Payment data flows from the billing system to the state's financial systems for reconciliation and general ledger posting.
• Financial Reporting (outbound). Collection rates, delinquency status, revenue summaries, and program performance metrics reported to state finance and CMS.
• State Treasury (outbound). Delinquent balances transferred to the state Department of Revenue or treasury for collection via income tax assessment or other enforcement mechanisms.
• Claims Systems (outbound). Payment status data communicated to claims systems to support eligibility verification and coverage confirmation.

The key architectural principle is that the billing system operates as a modular component with well-defined interfaces. It does not require modification of the MMIS core. Data flows in through enrollment feeds and flows out through payment and status reporting.

States face a fundamental choice: ask their MMIS vendor (Deloitte, Accenture, IBM, etc.) to build premium billing as a custom module, or procure a dedicated, purpose-built solution. The differences are significant:

• Cost. Custom MMIS builds for premium billing typically cost $5-15M+ in development and require ongoing maintenance budgets. A purpose-built SaaS solution operates on a predictable operational expense model with implementation costs a fraction of custom development.
• Timeline. Custom MMIS builds take 18-36 months. A configurable SaaS platform can be production-ready in as little as 90 days because the core platform already exists.
• Domain expertise. MMIS vendors are generalists. Premium billing for Medicaid populations is a specialized problem requiring deep understanding of collection challenges, payment method diversity, delinquency management, and the economics of small-premium programs. Purpose-built vendors have solved these problems across multiple states.
• Configurability. Custom builds are rigid once deployed. Changes require development cycles and change orders. A configurable platform allows business users to adjust rules, thresholds, and workflows without code changes.
• Risk. Custom builds carry implementation risk (delays, cost overruns, scope creep). A proven platform with production deployments in other states carries significantly less risk.
• Ongoing maintenance. With a custom build, the state owns maintenance. With SaaS, the vendor is responsible for upgrades, security patches, regulatory compliance updates, and infrastructure.

Implementation timeline depends on the approach:

• Purpose-built SaaS platform: 90-180 days from contract to production. This covers configuration of billing rules, delinquency events, invoice templates, payment method setup, interface development with state systems, testing, and go-live.
• Custom MMIS build: 18-36 months. Includes requirements gathering, design, development, testing, CMS certification (if applicable), and deployment.

The 90-day timeline for a configurable platform is achievable because:

1. The core billing engine, payment processing, delinquency management, and member portal already exist in production.
2. Configuration (not custom development) adapts the platform to state-specific rules.
3. Interface development uses proven patterns from prior state implementations.
4. Testing focuses on state-specific configuration rather than core platform functionality.

Yes. A well-architected premium billing platform is MMIS-agnostic. It receives enrollment data through configurable interfaces and does not depend on any specific MMIS vendor's technology stack.

The key integration requirements are:

• Inbound enrollment data. The billing system needs member demographics, coverage details, premium amounts, and effective dates. This data can arrive via web services (REST/SOAP), ANSI X.12 834 transactions, or proprietary file formats. The specific format is configured during implementation.
• Outbound payment/status data. Payment confirmations, delinquency status, and disenrollment events flow back to the MMIS through the same configurable interface layer.

Because the billing system operates as a modular component with standardized interfaces, it can integrate with:

• Legacy MMIS platforms (mainframe-based systems with file-based interfaces)
• Modern modular MMIS environments (API-based, microservices architecture)
• Hybrid environments (legacy core with modern integration layers)
• Any MMIS vendor's platform (Deloitte, Accenture, IBM, CNSI, Conduent, etc.)