Medicaid Managed Services RFP Guide: SLAs, Data Ownership, Security, and Regulatory Change Management
Consider a provider update that introduces an incorrect effective date.
Otherwise valid Medicaid claims fail, downstream records disagree, and vendors dispute responsibility. The system remains online, but payments stall.
A strong request for proposal must address that operational failure. It should establish who detects problems, coordinates correction, validates recovery, and pays for the work.
This guide covers technology operations for Medicaid Enterprise Systems, including Medicaid Management Information System applications, interfaces, hosting, and support. Managed IT services procurement rather than managed care health plan selection. Include claims business operations or call centers only when expressly within scope.
Define Scope and CMS Requirements First
Document included applications, environments, interfaces, service hours, transaction volumes, backlogs, and known defects. Assign responsibilities retained by the state and other contractors.
For each critical workflow, name the operational lead, contributing teams, decision authority, and escalation path. Separate application processing responsibilities from payment authorization duties.
CMS requires standardized MES templates effective July 1, 2026, including a Procurement Document Checklist for procurement instruments submitted to CMS. Applicable operational reporting uses the Operational Report Workbook.
Assign submission owners and confirm the approval path with procurement staff and the CMS MES State Officer. Distinguish procurement approval, funding approval, and certification.
The structures below are recommendations; targets must reflect applicable requirements and operational baselines.
7 Steps for Building a Medicaid IT Managed Services RFP
1. Define Measurable SLAs
Measure business outcomes alongside availability.
| Service | Define and verify |
| Claims | Eligible population, processing milestones, aging, and delay attribution |
| Provider updates | Effective-date accuracy, propagation deadlines, and reconciliation |
| Interfaces | Expected deliveries, destination acceptance, rejects, and retries |
| Availability | Covered services, monitoring points, maintenance exclusions, and degraded service |
| Incidents | Severity, acknowledgment, restoration, resolution, and communication |
| Recovery | Recovery time and recovery point objectives, supported by test results |
For every service-level agreement, specify calculations, evidence sources, reporting periods, clock rules, exclusions, and accountable owners. Specify corrective-action deadlines, applicable service credits, and escalation for repeated failures.
Separate contractor processing commitments from statutory payment obligations. Under 42 CFR § 447.45, agencies must pay 90% of specified clean practitioner claims within 30 days and 99% within 90 days of receipt, subject to applicable provisions. These deadlines do not universally cover every Medicaid claim.
The clean-claim definition includes claims with errors originating in the state’s claims system. Preserve that distinction when measuring internal failures.
Require reporting of missed processing windows and affected transactions; monthly averages can conceal failures. Test recovery of critical workflows, including queued transactions and reconciliation.
For example, require bidders to define deadlines for propagating approved provider updates, identify receiving systems, demonstrate reconciliation, and assign responsibility for correcting and reprocessing affected claims.
2. Protect Data and Software Rights
Define state rights to access, correct, retain, use, and transfer program data. Cover claims, eligibility, provider histories, encounters, audit logs, configurations, and mappings.
Address software rights separately. Under 45 CFR § 95.617, applicable procurement instruments must include state or local government ownership provisions for software, modifications, and documentation designed, developed, or installed with federal financial participation under the subpart. Account for proprietary software exceptions and federal licensing provisions.
Require bidders to disclose third-party licenses and restrictions affecting continued operation.
Make exports usable: specify formats, dictionaries, relationships, historical versions, delivery schedules, validation, and permitted charges. Require record counts, financial reconciliation, and successor testing. Exchange standards alone do not define a complete exit package.
3. Require Security Evidence
Map security obligations to the module, data, environment, and subcontractors. Specify applicable HIPAA safeguards, state requirements, and business associate agreements where required.
CMS requires ARC-AMPE for applicable Eligibility and Enrollment systems connected to the Federal Data Services Hub. It superseded MARS-E on March 4, 2026. ARC-AMPE is not a universal CMS mandate for every non-E&E module.
A SOC 2 report used as the primary security assessment report must cover all five Trust Services Criteria under CMS guidance. SOC 2 alone does not establish HIPAA compliance.
Request evidence covering access reviews, encryption, monitoring, vulnerability remediation, independent assessments, protected backups, and restoration tests.
Define incident discovery triggers, reporting deadlines, escalation, evidence preservation, and notification authority. Assign prompt escalation to the state and responsibility for the state’s CMS reporting using current instructions.
HIPAA business associates must notify the covered entity of breaches of unsecured protected health information without unreasonable delay and no later than 60 calendar days after discovery. Contracts can require earlier incident reporting.
4. Control Regulatory Changes and Charges
Maintain a change register recording the source, applicability, compliance deadline, affected systems, dependencies, owner, pricing, approvals, testing, and validation. Distinguish binding obligations from proposed rules and guidance.
Distinguish defect correction, routine maintenance, included regulatory updates, enhancements, and emergency work. Identify which activities the recurring fee covers.
Set deadlines for acknowledgment, impact analysis, and escalation. Schedule implementation against the actual compliance date. Avoid a blanket deployment deadline for changes of different complexity.
Require interim mitigation when necessary, regression testing across connected workflows, rollback procedures, and verification after deployment.
5. Compare Lifecycle Costs
Require comparable pricing for transition-in, recurring support, infrastructure, licenses, assessments, recovery exercises, enhancements, regulatory updates, and transition-out.
Disclose volume assumptions, annual increases, minimum commitments, exclusions, and subcontractor charges. Compare expected-volume and higher-demand scenarios over the same contract term.
Require written approval before chargeable work begins and establish a process for disputed fees.
6. Evaluate Demonstrated Capability
Separate mandatory qualifications from scored criteria. Publish weights and scoring methods before evaluation.
| Evaluation area | Illustrative weight |
| Operations and SLA measurement | 25% |
| Security evidence | 20% |
| Data rights and transition | 15% |
| Regulatory change delivery | 15% |
| Total evaluated cost | 20% |
| Governance and staffing | 5% |
These weights are suggestions, not CMS requirements.
Score qualitative responses using defined anchors: unsupported promise, documented process, or demonstrated performance backed by evidence. Check comparable references.
Use the provider-effective-date failure as a demonstration.
Ask bidders to identify the authoritative source, locate affected claims, coordinate correction, reprocess without duplication, and reconcile downstream results. Assess ownership and recovery evidence rather than presentation quality.
7. Define Transition Acceptance
Require transition plans before award.
| Stage | Acceptance evidence |
| Knowledge transfer | Current runbooks, architecture, dependencies, and procedures |
| Operational readiness | Tested access, monitoring, support, and escalation |
| Data transfer | Reconciled exports and target-system validation |
| Recovery readiness | Restoration results and assigned remediation |
| Handover | Resolved critical defects and state approval |
Set an appropriate stabilization period and address inherited defects and backlogs.
For transition-out, define cooperation, deliverables, charges, license dependencies, and access changes. Validate transfers before authorized deletion, subject to retention requirements and litigation holds.
Final RFP Readiness Checklist
Before release, confirm that the RFP establishes:
- Service boundaries and retained state responsibilities.
- Applicable CMS submissions and approval owners.
- Measurable SLAs, evidence, remedies, and escalation.
- Data, software, licensing, and export rights.
- Security controls, assessment evidence, and incident duties.
- Regulatory change scope, pricing, and acceptance.
- Comparable lifecycle costs and disclosed evaluation methods.
- Tested transition and handover requirements.
For the opening failure, the contract should make the response clear: identify the source, correct affected records, reprocess claims, reconcile results, and verify closure.
Plan Support Around Operational Requirements
A strong Medicaid IT managed services RFP connects technical commitments to the workflows the state must maintain.
CapMinds supports healthcare application management, integration, and legacy application support. Share your application environment, interface dependencies, and support gaps with our team to discuss a practical managed support scope.
