DEPARTMENT OF HEALTH & HUMAN SERVICES 
Centers for Medicare & Medicaid Services 
7500 Security Boulevard, Mail Stop S2-26-12 
Baltimore, Maryland   21244-1850 
SMD # 16-010 
RE: CMS-2392-F Mechanized Claims 
Processing and Information Retrieval 
Systems  Modularity  
August 16, 2016 
Dear State Medicaid Director: 
The Centers for Medicare & Medicaid Services (CMS) is issuing this third in a series of State 
Medicaid Director letters to provide sub-regulatory guidance to supplement CMS-2392-F, 
Mechanized Claims Processing and Information Retrieval Systems (90/10), which became 
effective January 1, 2016.  This regulation further supports the modular systems development 
requirement detailed in 42 CFR Part 433, Subpart C - Mechanized Claims Processing and 
Information Retrieval Systems.  
In reviewing the responses to our Request for Comments in our Notice of Proposed Rulemaking 
(NPRM) (CMS-2392-P) published on April 16, 2015 (80 FR 20455), we determined that there is 
a need for the development of supporting policy and sub-regulatory guidance.  In developing 
sub-regulatory guidance, CMS is engaging our partners and stakeholders in recognition of their 
valuable experience and unique perspectives on this final rule.   
Each of the letters in this series addresses discrete subject areas impacted by the final rule.1 This 
letter addresses modular certification of Medicaid Management Information Systems (MMIS).   
Background 
On December 4, 2015, CMS published a final rule at 80 FR 75817, Federal Funding for 
Medicaid Eligibility Determination and Enrollment Activities.  This final rule provided for a 
temporary enhancement to the federal financial participation (FFP) rate to support the design, 
development, and installation (DDI) and maintenance and operations (M&O) of Medicaid 
Eligibility and Enrollment (E&E) systems that are streamlined and interoperable with other 
systems and that provide a consumer-friendly experience.  To further integrated systems, the 
final rule modified the definition of Claims Processing and Information Retrieval Systems at 42 
CFR 433.111(b) to permanently include E&E systems.  The broadened definition was also 
refined to support an enterprise approach where individual processes, modules, sub-systems, and 
systems are interoperable and work together seamlessly to support a unified Medicaid enterprise.  
1  Previous letters in this series include State Medicaid Director Letter (SMDL) #16-004 and SMDL #16-009 which 
can be found at https://www.medicaid.gov/federal-policy-guidance/federal-policy-guidance.html.   Page 2  State Medicaid Director 
 
The Medicaid enterprise includes: (1) An E&E system used to process Medicaid enrollment 
applications, as well as change in circumstance updates and renewals.  The E&E system might 
be implemented as the core of an integrated eligibility system that also supports eligibility for 
other human services programs; and (2) An MMIS used to process claims for Medicaid payment 
from providers of medical care and services furnished to beneficiaries under the medical 
assistance program, including review of managed care encounter data, and to perform other 
functions necessary for economic and efficient operations, management, monitoring, and 
administration of the Medicaid program.  To receive enhanced federal matching funding for 
development, maintenance and operations, the Medicaid E&E systems and the MMIS must meet 
all applicable standards and conditions, including modularity, along with associated provisions 
such as the role of independent verification and validation (IV&V). 
 
A module is a packaged, functional business process or set of processes implemented through 
software, data, and interoperable interfaces that are enabled through design principles in which 
functions of a complex system are partitioned into discrete, scalable, reusable components.  An 
MMIS module is a discrete piece (component) of software that can be used to implement an 
MMIS business area as defined in the Medicaid Enterprise Certification Toolkit (MECT).  The 
updated MECT can be found at https://www.medicaid.gov/medicaid-chip-program-
information/by-topics/data-and-systems/mect.html.   
 
Modules can be added to a system or replaced, as needed, to implement a required functionality.  
To meet re-use requirements, modules should be made available to be shared and reused by 
another state or territory, or have been obtained as a result of sharing and reusing software from 
another state or territory.  Modular projects may leverage the use of commercial off-the-shelf 
(COTS) products or Software-as-a-Service (SaaS) solutions as well as other modular approaches.  
In the case of proprietary products and SaaS, the same effective module is potentially available 
to other states subject to a states contractual arrangement with the vendor. 
 
Under the revised rule, CMS requires states to follow a modular approach that supports timely, 
cost-effective projects. We believe that a modular approach to the Medicaid Information 
Technology (IT) enterprise provides the most efficient and cost-effective long-term solution for 
meeting states business needs.  States will be able to leverage the modular approach to optimize 
project design for agility, interoperability and other desirable attributes as well as associated 
acquisition approaches to avoid prolonged development efforts and vendor lock-in.  The modular 
approach is capable of supporting all Medicaid service delivery models, including managed care, 
fee-for-service, and use of an administrative services organization.   
 
CMS will support projects that address rational, discrete subsets of Medicaid enterprise 
functionality (modules) that are interoperable with other parts of the Medicaid enterprise and 
meet all other Standards and Conditions for Medicaid IT.  States are required to follow the 
modularity principles in their development of new or replacement MMIS and E&E modules.  
The requirement for modular approaches applies to all systems that are eligible for enhanced 
match within the Medicaid IT enterprise.   
 
Modular Certification of MMIS Modules 
  Page 3  State Medicaid Director 
 
Under previous rules, determination that an MMIS meets all applicable requirements (i.e. 
certification), was completed only after implementation of an entire system and an initial 
period of operational use.  States were able to access the enhanced federal match for maintenance 
and operations only after this determination.  Such an approach resulted in replacement or 
enhancement projects that were often large, lengthy, expensive and high risk, and delayed states 
access to the enhanced match.  For these reasons CMS discourages replacement of an entire 
MMIS as a monolithic activity. 
 
Modular certification will be applied to MMIS systems as new modules are introduced and as 
existing modules are replaced.  CMS may require modular certification of portions of a system 
when proposed changes or enhancements have been determined to be high risk.  Modular 
certification will result in several benefits to states.  With smaller, more incremental projects risk 
and costs should be reduced for all aspects of the project.  Modular MMIS certification will 
allow the states to access the 75 percent enhanced FFP for M&O of the certified module(s) prior 
to having completed their total MMIS system replacement, improving the states cash flow.   
 
Modular certification is supported by the updated MECT, which supersedes the prior MMIS 
Certification Toolkit.  Modular certification will leverage the MECT as a dynamic methodology 
that can be applied to projects variously aligned along business process lines and functionality.  
The MECT has multiple options for certifying modular projects that should suit the variety of 
approaches being taken by different states, including a custom certification approach suggested 
by a state, subject to CMSs review and approval.  Project risk will be a major consideration in 
deciding whether or not to approve enhanced FFP for a modular project. 
 
Although the addition of a new module or changes or enhancements to an existing module or set 
of modules would call for modular certification, it would not require the recertification of the 
entire MMIS.  Review of a modular implementation would focus on that modules functions 
within the MMIS, how it interfaces with other MMIS modules, and how effectively and 
efficiently it serves its purpose within the MMIS.  Successful completion of regression testing 
must also be verified to ensure that the integration of the new module will not have a negative 
impact on other parts of the system.  CMS requires that the state has accepted the modular 
solution from their vendor and that there has been at least a six-month period of live operations 
before it will consider a module for certification.  Approval is subject to the conditions in the 
State Medicaid Manual Chapter 2, Approval of MMIS Systems, sections 11210, 11241, and 
related sections, found at https://www.cms.gov/Regulations-and-
Guidance/Guidance/Manuals/Paper-Based-Manuals-
Items/CMS021927.html?DLPage=1&DLEntries=10&DLSort=0&DLSortDir=ascending, as well 
as the standards and conditions documented in the MECT.  
 
CMS has organized the requirements in the MECT into checklist sets to be used in certifying 
MMIS modules.  States can use MECT checklists based on 1) the MITA 3.0 business areas, 2) 
MMIS modules, or 3) a tailored checklist set prepared by the state which the state then submits 
to CMS for acceptance.  Appendix A lists the MITA 3.0 and MMIS business area checklists.  
Whichever checklist set is used, the MITA 3.0 requirements still apply.  In support of a more 
outcome-based approach, the new MECT also incorporates the concept of critical success 
factors, further unifying the approaches available to the states for managing MMIS projects.    Page 4  State Medicaid Director 
 
 
 
 
Recommended Modules 
 
CMS expects that states will take different approaches to identifying the best solutions to meet 
the needs of the Medicaid IT enterprise.  CMS will work with states during the planning stage 
and provide guidance on the appropriate modules to be incorporated into each project based on 
the states concept of operations.  The need for modular certification will be identified during the 
planning stages of a project, including advance planning document (APD) review.  Appendix A 
lists modules that could be constructed based on the two standard checklist sets.  
 
Modular Acquisition 
 
A modular approach to acquisition increases the opportunity to select progressive technology 
from different vendors, along with the flexibility to swap solutions in and out over time as 
needed.  As the market for modular solutions evolves, states should take advantage of acquisition 
approaches that will avoid vendor lock-in and other risks of a single, massive solutions.  States 
also should be able to replace individual modules to take advantage of specific innovations 
without significant integration cost and additional risks.   
 
The modular approach supports states in achieving an optimal balance in the use of open source 
and proprietary COTS software solutions over the use of custom solutions, thereby reducing the 
need for custom development, promoting reuse, expanding the availability of open source 
solutions, and encouraging the use of shared services.  Open source projects offer the potential to 
introduce additional efficiency and innovation.  Multiple independent developers contribute best 
practices and new ideas, reacting to each others work in a collaborative, open environment.  
Such projects have been highly successful in other subject domains, in terms of both richness of 
functionality and economy, and could have similar potential in the Medicaid domain as well. A 
modular approach to acquisition will lower the barriers to entry for smaller vendors, thereby 
increasing the availability of modules and shared services in the marketplace.   
 
Conditions for modularity and interoperability require acquisition of loosely coupled modules 
with open, documented interfaces, including COTS solutions, in order to qualify for enhanced 
federal funding. A key component of this approach is a well-documented set of open interfaces 
that allow for vendor-independent integration of modules into an overall business solution.  
These interfaces may take a number of forms including, but not limited to, application 
programming interfaces (APIs), open services under a service oriented architecture (SOA), and 
shared standards-based data stores.   
 
States should carefully craft Requests for Proposals (RFPs) to specify these conditions, and may 
find it efficient to include excerpts from the certification checklists, particularly the critical 
success factors.  CMS expects that states RFPs and contracts will contain language requiring 
publication of open APIs. 
 
System Integrator Role  Page 5  State Medicaid Director 
 
 
CMS envisions a discrete role for the system integrator (SI) in each state, with specific focus on 
ensuring the integrity and interoperability of the Medicaid IT architecture and cohesiveness of 
the various modules incorporated into the Medicaid enterprise.  The target outcome for the SI 
should be to foster ever evolving solutions for Medicaid business requirements, with the SI 
responsible for the successful integration of the chosen solutions and infrastructure into a 
seamless functional system. The scope of the SI role shall include the interoperable integration of 
the Health Information Exchange activities as described in State Medicaid Directors letter #16-
003 into the Medicaid enterprise.   More information on the SI role can be found in the MECT, 
Medicaid Enterprise Certification Life Cycle, part 01 Section 1.7.   
 
States are encouraged to use an acquisition approach that limits the potential for conflict of 
interest an SI may have in choosing the modular solutions to be incorporated into the system.  
Such an approach could preclude the SI from bidding on functional modules, but still allow the 
SI to provide elements of the technical infrastructure such as the enterprise service bus, master 
data management, etc.  As described above, the goal is to avoid lock-in to a single vendor or an 
otherwise closed set of solutions.   
 
Independent Verification and Validation  
 
Under regulation at 45 CFR 95.626, Independent Verification and Validation (IV&V) may be 
required for any major Medicaid IT project.  The IV&V contractor represents state and CMS 
interests throughout each project and, as such, provides an independent and unbiased perspective 
on the progress of MMIS or E&E system development and the integrity and functionality of the 
system.  The scope of IV&V responsibilities are detailed in the MECT and include evaluation of 
project management and performance, project development and testing processes, and technical 
reviews of the modules.  The IV&V contractor must also verify that adequate regression testing 
has been performed to confirm that the replaced or enhanced module does not adversely impact 
the functionality and operation of the MMIS, E&E systems or other related components of the 
states Medicaid Enterprise.   
 
In order to allow time for states to align existing contracts and projects to the new IV&V 
guidelines, CMS will allow states an 18-month period from the date of this letter to comply with 
new IV&V requirements.  This 18-month period is applicable only to contracts in place as of the 
date of this letter. Contracts entered into after the date of this letter must comply with all IV&V 
requirements.  To aid in adoption of these new requirements the MECT contains model language 
for states to include in their IV&V contracts. 
 
MITA 3.0 Compliance  
 
Regulation at 42 CFR 433.112(b)(11) requires alignment with MITA for DDI of MMIS and 
E&E systems that are funded with enhanced federal matching funds.  MITA 3.0 compliance 
requires  that systems be designed, developed, and maintained with up-to-date industry best 
practices, so that the resulting MMIS and E&E systems are modular and technically suitable for 
sharing and reuse with other states. See https://www.medicaid.gov/Medicaid-CHIP-Program- Page 6  State Medicaid Director 
 
Information/By-Topics/Data-and-Systems/Medicaid-Information-Technology-Architecture-
MITA.html.  
 
 
 
 
Module Pre-Certification 
 
CMS will implement a module pre-certification program that will allow vendors to present their 
Medicaid IT modular solutions to CMS for review, regardless of whether the software has been 
implemented in a state system or not. Information about the pre-certification criteria and process 
is available at https://www.medicaid.gov/medicaid-chip-program-information/by-topics/data-
and-systems/modules.html. 
This SMDL supersedes previous guidance in the State Medicaid Manual (SMM) Chapter 11 
(https://www.cms.gov/Regulations-and-Guidance/guidance/Manuals/Paper-Based-Manuals-
Items/CMS021927.html).  Supplemental information is available in the MECT and in a series of 
responses to frequently asked questions (FAQs) maintained at https://questions.medicaid.gov. 
 
If you have additional questions, please contact Martin Rice at Martin.Rice1@cms.hhs.gov.  We 
look forward to working with states to facilitate state system builds, to ensure compliance with 
this regulation, and to provide assistance implementing these requirements. 
 
Sincerely, 
 
             /s/ 
 
Vikki Wachino 
Director 
 
cc: 
Jessica Kahn, Director of the Data and Systems Group, CMS  
National Association of Medicaid Directors  
National Academy for State Health Policy  
National Governors Association  
American Public Human Services Association  
Association of State Territorial Health Officials  
Council of State Governments  
National Conference of State Legislatures  
Academy Health  Page 7  State Medicaid Director 
 
 Appendix A: List of Modules 
 
 
Medicaid Management Information System (MMIS) Modules 
Below are lists of modules that could be constructed based on the two standard checklist sets 
available within the Medicaid Enterprise Certification Toolkit (MECT).  
 
I.  Medicaid Information Technology Architecture (MITA) Business-Aligned 
Modules 
The following correspond to the set of MITA business-aligned certification checklists 
of the same names: 
 
  Business Relationship Management 
  Care Management 
  Contractor Management 
  Eligibility & Enrollment 
  Financial Management 
  Member Management 
  Operations Management 
  Performance Management 
  Plan Management 
  Provider Management 
 
II.  MMIS System Modules 
The following are aligned with MMIS system models: 
 
  Member Enrollment 
  FFS Claims & Adjudication 
  Pharmacy 
  Third Party Liability 
  Care Management 
  Program Integrity 
  Decision Support System 
  Reference Data Management 
  Provider Management 
  Registries