2015-30591. Medicaid Program; Mechanized Claims Processing and Information Retrieval Systems (90/10)

AGENCY:

Centers for Medicare & Medicaid Services (CMS), HHS.

ACTION:

Final rule.

SUMMARY:

This final rule will extend enhanced funding for Medicaid eligibility systems as part of a state's mechanized claims processing system, and will update conditions and standards for such systems, including adding to and updating current Medicaid Management Information Systems (MMIS) conditions and standards. These changes will allow states to improve customer service and support the dynamic nature of Medicaid eligibility, enrollment, and delivery systems.

DATES:

Effective Date: These regulations are effective on January 1, 2016.

FOR FURTHER INFORMATION CONTACT:

Victoria Guarisco [phone], for issues related to administrative questions.

Carrie Feher [phone], for issues related to the regulatory impact analysis.

Christine Gerhardt [phone] or Martin Rice [phone], for general questions.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Executive Summary

A. Purpose

B. Summary of the Major Provisions

C. Summary of Costs and Benefits

II. Background

A. Legislative History and Statutory Authority

B. Program Affected

III. Provisions of the Proposed Rule and Responses to Comments

A. Amendments to 42 CFR Part 433

B. Technical Changes to 42 CFR Part 433, Subpart C-Mechanized Claims and Processing Information Retrieval Systems

C. Changes to 45 CFR Part 95—General Administration—Grant Programs, Subpart F

IV. Provisions of the Final Regulations

V. Collection of Information Requirements

VI. Regulatory Impact Analysis

Acronyms

APD Advance Planning Document

API Application program interface

ASO Administrative Services Organization

BPM Business Process Model

CALT Collaborative Application Lifecycle Tool

COTS Commercial Off-the-Shelf

CSF Critical success factor

CY Calendar year

DDI Design, development and installation

E&E Eligibility and enrollment

ELC Enterprise Life Cycle

FDSH Federal Data Services Hub

FFM Federally-Facilitated Marketplace

FFP Federal financial participation

IAPD Implementation Advance Planning Documents

IV&V Independent Verification & Validation

M&O Maintenance and operations

MAGI Modified adjusted gross income

MITA Medicaid Information Technology Architecture

MMIS Medicaid Management Information Systems

MOU Memorandum of Understanding

ONC [HHS'] Office of the National Coordinator for Health IT

PAPD Planning Advance Planning Documents

PHI Protected health information

PoC Proof of Concept

SaaS Software-as-a-Service

SMM State Medicaid Manual

SNAP Supplemental Nutrition Assistance Program

SOA Service-oriented architecture

XLC Expedited Lifecycle

I. Executive Summary

A. Purpose

This final rule will revise the regulatory definition of Medicaid mechanized claims processing and information retrieval systems to include Medicaid eligibility and enrollment (E&E) systems, which would make available for E&E systems the enhanced federal financial participation (FFP) specified in section 1903(a)(3) of the Social Security Act (the Act) on an ongoing basis. Enhanced FFP will be available, under certain circumstances, for costs of such systems at a 90 percent federal match rate for design, development and installation (DDI) activities, and at a 75 percent federal match rate for maintenance and operations (M&O) activities. In addition to lifting the time limit that currently applies to the inclusion of E&E systems in the definition of mechanized claims processing and information retrieval systems, we proposed changes to the standards and conditions applicable to such systems to access enhanced funding. We also solicited comment on new approaches to systems development, the inclusion of Commercial Off-the-Shelf (COTS) software at a 90 percent matched cost, acquisition approvals and MMIS certification. Specifically, we are publishing new definitions for “Commercial Off-the-Shelf (COTS),” “open source,” “proprietary,” “service,” “shared services,” “Software-as-a-Service (SaaS),” and “module.”

B. Summary of the Major Provisions

On April 16, 2015, (80 FR 20455), we proposed changes to §§ 433.110, 433.111, 433.112, 433.116, 433.119, and 433.120. These changes provide for the 90 percent enhanced FFP for DDI activities for E&E systems to continue on an ongoing basis. These proposed changes would also allow the states to complete fully modernized E&E systems and will support the dynamics of national Medicaid enrollment and delivery system needs. These changes would further set forth additional criteria for the submission, review, and approval of Advance Planning Documents (APDs).

In addition, we proposed changes to provisions within 45 CFR part 95, subpart F, § 95.611. These changes align all Medicaid IT requirements with existing policy for Medicaid Management Information Systems (MMIS) pertaining to prior approvals when states release acquisition solicitation documents or execute contracts above certain threshold amounts. Lastly, we proposed to amend § 95.611(a)(2) by removing the reference to 45 CFR 1355.52, which references enhanced funding for Title IV-E programs. Enhanced funding for Title IV-E programs expired in 1997.

C. Summary of Costs and Benefits

Provision description	Total costs	Total benefits
42 CFR part 433	The federal net costs from FY 2016 through 2025 of implementing the final regulation on eligibility systems is approximately $3 billion. This includes approximately $5.1 billion in increased federal costs for system design, development, or installation, offset by lower anticipated maintenance and operations costs. These costs represent only the federal share. These figures were derived from states' actual system development and maintenance costs as the foundation for projected costs	We project lower costs over the 10-year budget window due to the increased savings to operating one E&E system and eliminating legacy systems. The costs shift from mostly 90 percent FFP for design, development, or installation to 75 percent FFP for maintenance and operations over time (federal share only).
42 CFR part 433	The state net costs from FY 2016 through 2025 of implementing the final regulation on eligibility systems is approximately −$1.1 billion. This includes approximately $572 million in state costs for system design, development, or installation, offset by lower anticipated maintenance and operations costs. These costs represent only the state share	We project savings for states over the 10-year budget window due to moving away from operating two or more systems, and replacing legacy systems.
45 CFR part 95, subpart F: § 95.611	This is an administrative change with no associated costs	This administrative change is expected to result in nominal savings from increased efficiency.
* See section VI. of this final rule for the underlying assumptions in support of these totals and further explanation.

II. Background

A. Legislative History and Statutory Authority

Section 1903(a)(3)(A)(i) of the Act provides for FFP at the rate of 90 percent for state expenditures for the DDI of mechanized claims processing and information retrieval systems as the Secretary of the Department of Health and Human Services (the Secretary) determines are likely to provide more efficient, economical and effective administration of the state plan. In addition, section 1903(a)(3)(B) of the Act provides for FFP at the rate of 75 percent for state expenditures for M&O of such systems.

In a final rule published October 13, 1989 (54 FR 41966), we revised the definition of a mechanized claims processing and information retrieval system at § 433.111(b) to provide that eligibility determination systems (referred to in this rule as E&E systems) would not be considered part of mechanized claims processing and information retrieval systems or enhancements to those systems. As a result, we also indicated at § 433.112(c) that the enhanced FFP for mechanized claims processing and information retrieval systems in accordance with section 1903(a)(3) of the Act would not be available for eligibility determination systems.

We published a final rule entitled, “Federal Funding for Medicaid Eligibility Determination and Enrollment Activities” on April 19, 2011 (76 FR 21949-21975) that temporarily reversed the 1989 rule. We explained that this reversal was in response to changes made by the Affordable Care Act that required sweeping changes in Medicaid E&E systems and removed certain linkages between Medicaid eligibility determinations and eligibility determinations made by other federal-state programs, as well as changes in Medicaid eligibility and business processes that have occurred since our 1989 final rule to integrate eligibility and claims processing systems. The reversal was temporary to address the immediate need for eligibility system redesign to coordinate with the overall claims processing and reporting systems. Specifically, in the April 19, 2011 final rule (76 FR 21950), we included eligibility determination systems in the definition of mechanized claims processing and information retrieval systems in § 433.111(b)(3). We also provided that the enhanced FFP would be available at the 90 percent rate for DDI or enhancement of E&E systems and at the 75 percent rate for M&Os of such systems, to the extent that the E&E systems were developed on or after April 19, 2011, operational by December 31, 2015, and met all standards for such systems. Under that rule, the 90 percent enhanced matching rate for system development is available through calendar year (CY) 2015 for state expenditures on E&E systems that meet specific standards and conditions, and the 75 percent match for M&Os is available for systems that meet specific standards and conditions before the end of CY 2015, as long as those systems are in operation.

In the April 19, 2011 final rule (76 FR 21950), under the authority of sections 1903(a)(3)(A)(i) and 1903(a)(3)(B) of the Act, we codified the conditions at § 433.112(b) that must be met by the states for Medicaid technology investments including traditional claims processing systems, as well as eligibility systems, to be eligible for the enhanced funding match. We also issued subregulatory guidance, “Medicaid IT Supplement Version 1.0; Enhanced Funding Requirements: Seven Conditions and Standards,” in April 2011 that outlined in greater detail the seven new standards and conditions for enhanced funding.

As explained in more detail below, we proposed to make permanent the inclusion of E&E systems in the definition of mechanized claims processing and information retrieval systems, and to consequently extend the availability of enhanced FFP. We proposed to define a state Medicaid E&E system as the system of software and hardware used to process applications, renewals, and updates from Medicaid applicants and beneficiaries. In part, this change reflects a better understanding of the complexity of the required E&E system redesign based on our experience with states since finalizing the April 29, 2011 regulation, and an appreciation of the need for E&E systems to operate as an integral part of the mechanized claims processing and information retrieval systems using a standard Medicaid Information Technology Architecture (MITA).

We previously expected that fundamental changes to state systems would be completed well before December 31, 2015. It is now clear that additional improvements would benefit states and the federal government. It is also clear that such systems are integral to the operation of the state's overall mechanized claims processing and information retrieval systems and must be designed and operated as a coordinated part of such systems. Without recognition as an integral part of such systems, and without ongoing enhanced federal funding, state Medicaid E&E systems are likely to become out of date and would not be able to coordinate with, and further the purposes of, the overall mechanized claims processing and information retrieval systems.

B. Program Affected

Since 2011, we have worked with the states on the DDI of modernized Medicaid and CHIP E&E systems, supported by the enhanced FFP, to achieve the technical functionality necessary for the implementation of the new eligibility and renewal policies on January 1, 2014. In December 2012, we identified critical success factors (CSFs) in order for the states to demonstrate operational readiness, including: Ability to accept a single, streamlined application; ability to convert existing state income standards to modified adjusted gross income (MAGI); ability to convey state-specific eligibility rules to the Federally-Facilitated Marketplace (FFM), as applicable; ability to process applications based on MAGI rules; ability to accept and send application files (accounts) to and from the Marketplace; ability to respond to inquiries from the Marketplace on current Medicaid or CHIP coverage; and, ability to verify eligibility based upon electronic data sources (the Federal Data Services Hub (FDSH) or an approved alternative).

The states are in varying stages of completion of their E&E system functionality, with work still ahead to maximize automation, streamline processes, and to migrate non-MAGI Medicaid programs into the new system. In addition, the majority of the states are engaged in system integration with human services programs, further increasing efficiencies and improving the consumer experience for those seeking benefits or services from programs in addition to Medicaid.

The response to our proposed rule indicated a need for the development of supporting policy. The responses also expressed the desire from stakeholders and partners to have further input into the policy development and implementation process. Following the effective date of this final rule, we intend to issue subregulatory guidance in the form of a series of State Medicaid Director Letters, each to address discrete subject areas affected by this rule, such as the new conditions for enhanced funding, COTS products, new APD requirements, new MMIS certification rules and reuse. In developing that guidance, we will consider the comments that have been submitted in response to our proposed rule, and will engage our partners and stakeholders to ensure that the guidance fully addresses the issues raised and that any procedures that are included in such guidance can be appropriately implemented by all actors. This engagement may take place within already established forums, such as Technical Advisory Groups, workgroups, or conferences, but may also include focused discussions with our partners and stakeholders. We wish to acknowledge that our federal and state partners, industry representatives, beneficiary advocates, and other stakeholders have valuable experience and unique perspectives that can improve the effectiveness of this rule and the overall quality of our guidance. For this reason we will seek out support from these sources as we move forward in the development of subregulatory guidance.

The response to our proposed rule also indicated a need for an update to the State Medicaid Manual (SMM). The responses suggested collaboration to address how this final rule will be implemented. Although the SMM is not within scope of this final rule, we recognize the need to update it, especially for funding of E&E systems and IT requirements subregulatory guidance referenced above will take precedence over any obsolete content in the SMM, until this update is complete. We are investigating the best approach to re-issuing the SMM in a more accessible, searchable and easily updated format. In the interim, we will continue to point to subregulatory guidance as the official source for needed updates, and such guidance takes precedence over conflicting material in the existing SMM. We believe that § 433.112(b)(5) as written is adequate, and can be expanded upon in subregulatory guidance; therefore, we will not be revising it in this rule.

We will take these recommendations under consideration as we formulate our plan for updating the SMM.

This rule finalizes provisions set forth in the “Mechanized Claims Processing and Information Retrieval Systems (90/10)” proposed rule, published on April 16, 2015 (80 FR 20455 through 20464).

III. Provisions of the Proposed Rule and Responses to Comments

We received 54 timely responses from the public on the April 16, 2015, Medicaid Program; Mechanized Claims Processing and Information Retrieval Systems (90/10) proposed rule, (80 FR 20455 through 20464). The following sections, arranged by subject area, include a summary of the proposed revisions and the public comments received, and our responses.

A. Amendments to 42 CFR Part 433

We proposed to amend § 433.110 by removing paragraphs (a)(2)(ii) and (iii) and paragraph (b). Previously, regulations at § 433.119 indicated that we would review at least once every 3 years each system operation initially approved under § 433.114 and, based on the results of the review, reapprove it for FFP at 75 percent of expenditures if certain standards and conditions were met. The final rule published April 19, 2011 (75 FR 21905) eliminated the requirement for the scheduled triennial review. Through a drafting error in the final rule published on April 19, 2011 (75 FR 21950), the reference to the scheduled triennial performance reviews at § 433.110(a)(2)(ii) and (iii) was not deleted as intended, and we proposed to delete the references here. The Secretary retains authority to perform periodic reviews of systems receiving enhanced FFP to ensure that these systems continue to meet the requirements of section 1903(a)(3) of the Act and that they continue to provide efficient, economical, and effective administration of the state plan.

We proposed technical corrections to amend § 433.110 by removing paragraph (b) and by updating the reference to 45 CFR part 74. The proposed changes were necessary because the statutory waiver authority that supported paragraph (b) was deleted by section 4753 of the Balanced Budget Act of 1997 (Pub. L. 105-33) and because 45 CFR part 74 was supplanted; first by 45 CFR part 92 in September of 2003, and then by 45 CFR part 75 in December 2014. References made to 45 CFR part 74 should have been updated at those times but were not. The Department published Uniform Administrative Requirements, Cost Principles and Audit Requirements for HHS Awards at 45 CFR part 75 as an interim final rule at 79 FR 75871, 75889 (December 19, 2014), which supersedes HHS regulations at 45 CFR parts 74 and 92.

We proposed to amend § 433.111 to revise the definition of “mechanized claims processing and information retrieval system”, and provide new definitions for “Commercial Off-the-Shelf (COTS) software”, “open source”, “proprietary”, “shared services”, and “MMIS Module”. We proposed to amend § 433.112(c) to provide for the 90 percent enhanced FFP for DDI activities to continue on an on-going basis. Making enhanced E&E system funding available on an on-going basis, as is the case with the 90 percent match for the MMIS systems, would allow the states to complete fully modernized systems and avoid the situation where their ability to serve consumers well is limited by outdated systems. Enhanced funding will also support the dynamic and on-going nature of national Medicaid eligibility, enrollment, delivery system, and program integrity needs. Continued enhanced funding will support the retirement of remaining legacy systems, eliminating ongoing expenses for maintaining these outdated systems. It will also achieve additional staffing and technology efficiencies over time by allowing for a more phased and iterative approach to systems development and improvement.

Our 2011 final rule limited the availability of 75 percent enhanced funding for M&Os to those E&E systems that have complied with the standards and conditions in that rule by December 31, 2015. Given our proposed modifications to 42 CFR part 433, subpart C, on-going successful performance, based upon CMS regulatory and subregulatory guidance, is a requisite for on-going receipt of the 75 percent FFP for operations and maintenance, including for any eligibility workers (http://www.medicaid.gov/​State-Resource-Center/​FAQ-Medicaid-and-CHIP-Affordable-Care-Act-Implementation/​Downloads/​FAQs-by-Topic-75-25-Eligibility-Systems.pdf). We intend to work with the states to do regular automated validation of accurate processing and system operations and performance.

We are authorized under the Act to approve enhanced federal funding for the DDI and operation and maintenance of such mechanized claims processing and information retrieval systems that are likely to provide more efficient, economical, and effective administration of the Medicaid program and to be compatible with the claims processing and information retrieval systems utilized in the administration of the Medicare program.

We implemented this authority in part under regulations at 42 CFR part 433, subpart C. This regulation provides the primary technical and funding requirements and parameters for developing and operating the state MMIS and the state Medicaid E&E systems.

We proposed to amend § 433.116, which details how MMIS are initially approved and certified to be eligible for the 75 percent FFP for operations. Specifically, we proposed that, given the modular design approach required by our 2011 regulation, certification should also be available for MMIS modules, rather than only when the entire MMIS system is completed and operational. Under existing regulations as amended in 2011, at § 433.112(b), we have already required that MMIS development be modular; the proposed change would make clear that approval, certification and funding could also be approached in a modular fashion. The states may accordingly take a phased approach, with the procurement of a module or modules occurring at different times. We also encourage a modular approach to E&E systems, although certification is not applicable to E&E systems since they are evaluated on the basis of meeting specified CSFs.

We strongly support the reusability of existing or shared components so in the case that technology products exist that can be used for MMIS or E&E, we want to encourage that by allowing FFP for the developmental costs of integrating existing or shared components as part of the MMIS or E&E systems. We clarify that, while E&E system performance investments must be approved to be eligible for the 75 percent enhanced funding for M&Os, the MMIS system certification requirements are not applicable to E&E systems at this time.

We will provide a series of artifacts, supporting tools, documentation, and diagrams to the states as part of our technical assistance, monitoring, and governance of MMIS systems design and development. It is also our intent to work with the states as identified and addressed prior to the certification stage.

We received the following comments in response to our proposal to amend 42 CFR part 433:

Comment: Many commenters expressed strong support for the proposed rule at § 433.111(b)(2) to permanently broaden the definition of mechanized claims processing and information retrieval systems to include Medicaid E&E systems, and to permanently extend 90 percent FFP for DDI of E&E systems, and with the requirement that E&E systems meet the conditions specified in § 433.112(b).

Response: We appreciate the supportive comments.

Comment: Several commenters agreed with the proposal to remove the December 31, 2015 compliance date for E&E systems to qualify for 75 percent FFP for M&Os. Another commenter expressed that the extension of enhanced funding would enable states to modernize their renewal processes to minimize the burden on consumers and prevent gaps in coverage from occurring.

Response: We agree with commenters who believe permanent extension of this enhanced funding can play a vital role in helping consumers enroll and stay enrolled while balancing states' fiduciary commitments.

Comment: Many commenters agreed with the requirement that E&E systems meet the conditions specified in § 433.112(b). Commenters support the goal for states to have high-performing systems that meet CSFs with limited workarounds or mitigations. Commenters also support aligning regulations with modern standards and best practices for information technology systems and projects.

Response: We agree that these provisions will enhance the overall quality of the enterprise and facilitate improved customer service.

Comment: Several commenters supported aligning regulation with modern standards and best practices for information technology systems and projects.

Response: We will continue to work with the industry and other stakeholders to ensure the Medicaid enterprise continues its forward momentum.

Comment: One commenter expressed support related to MAGI and non-MAGI system functionality, as referenced in § 433.112(b)(10) which provides for the use of a modular, flexible approach to systems development, including the use of open interfaces and exposed application programming interfaces; the separation of business rules from core programming, available in both human and machine readable formats.

Response: We concur with this comment related to MAGI and non-MAGI system functionality.

Comment: One commenter suggested that we consider revising the definition of a claims system in light of the ongoing shift of State Medicaid programs toward managed care and the related need to “manage” the Medicaid program in a comprehensive manner.

Response: We are clarifying our intent that the term, “claims for medical assistance”, which we used in the definition of a mechanized claims processing and information retrieval system includes capitation payments to Managed Care Plans. However, to state this explicitly, we modified the definition of the MMIS component in this final rule to include applicability to managed care.

Comment: A commenter asked about the inclusion of E&E systems in the definition of mechanized claims processing and information retrieval system. The commenter asked if it is CMS's intent that states should maintain one system that includes MMIS and E&E components, whether it is CMS's intent that states should have one APD to cover the MMIS and E&E systems, and whether this precludes states from continuing to maintain separate MMIS and E&E systems and APDs.

Response: The inclusion of E&E systems in the definition of mechanized claims processing and information retrieval systems does not mean that states must operate a single system or submit a single or combined APD; rather this language supports an enterprise perspective where individual processes, modules, sub-systems, and systems are interoperable and support a unified enterprise, working together seamlessly and transparently. This language also provides for consistent treatment of MMIS and E&E systems, especially for reuse, funding and standards and conditions. States may continue to operate separate E&E and MMIS but these must be fully interoperable and reflect an enterprise approach.

Comment: One commenter requested clarification on the inclusion of E&E systems into the definition of Mechanized Claims Processing and Information Retrieval System, particularly with the expanded list of standards and conditions.

Response: We intend to address how the revised list of standards and conditions applies to E&E systems in subregulatory guidance.

Comment: A few commenters requested clarification of the term, “subsystem,” and one commenter requested clarification of the “required subsystem” in a Mechanized claims processing and information retrieval system and asked whether there is an existing list of required subsystems. Commenters also asked whether the definition applies to both MMIS and E&E.

Response: In this final rule we are substituting the word “module” for “subsystem” at § 433.111(b) to be consistent with our modular approach to systems. We agree that required modules need to be defined and will discuss this further in subregulatory guidance. This definition does apply to both MMIS and E&E.

Comment: A commenter recommended wording to define MMIS in § 433.111 as “the operations, management, monitoring and administration of the Medicaid program.” The commenter has also suggested additional alternate wording for this section as well.

Response: We have revised the definition of MMIS in this final rule, and believe the definition now reflects the spirit of the commenter's recommendations.

Comment: A few commenters believe that the current definition of COTS will likely create issues regarding proprietary software, ownership, and customization of solutions that include COTS solutions. One alternative definition for COTS is offered, to add language after “little or no modification” to read “other than configuration to run in a specific hardware environment or to be used in combination with other software.”

Response: We considered the addition of this language to our definition in this final rule, but we believe that this qualification will be better addressed in subregulatory guidance.

Comment: A commenter suggested revising the language at proposed § 433.111(b)(2)(ii) and offered the following alternative language: “The MMIS may include other automated transactions, encounter data, premium and option payments, provider and consumer enrollments, drug rebates, and others.”

Response: We recognize that all of the functions mentioned by the commenter are MMIS functions, however, the description at § 433.111(b)(2)(ii) is not meant to be all inclusive, but rather to provide a foundational definition. Language has been added to the definition to include other necessary functions.

Comment: Many commenters generally stated support for our proposed definition of COTS software; but asked for clarification addressing why the COTS software definition does not include software that has been developed for public assistance programs. Several commenters suggested that some public assistance systems may serve E&E purposes for Medicaid and CHIP programs and should therefore not be excluded from the definition of COTS software, and suggested that the exclusion of public assistance programs from the definition of COTS seems to be in direct conflict with our intent to support integration.

Response: We concur with the recommendation that COTS software created for public assistance systems should not be excluded from this definition. Therefore, we have removed this exclusion from the definition in the final rule.

Comment: A commenter recommended a definition of open source similar to the definition in the proposed rule, but omits the references to free and open distribution and technology neutrality.

Response: The commenter's proposed definition omits what we believe are important elements for the effectiveness of open source software, so we are retaining the language of the proposed rule in the final rule.

Comment: Many commenters questioned the applicability of § 95.617 to COTS products matched at 90 percent. Several commenters asked for clarification regarding the issue of proprietary software with respect to COTS. The same commenters referred to the Ownership Rights provision in § 95.617(b) but point out that vendors invest time, money and intellectual capital in developing system capabilities, and they are only made whole through the ability to sell these capabilities. These commenters pointed out that vendors are not likely to seek to invest and innovate in the Medicaid systems market if they cannot recoup costs. One commenter recommends that we review the policy regarding royalty-free licensing of COTS products. The commenters recommend that if 90 percent FFP is used for enhancements to a module, then CMS and the state own the modifications, which can then be shared and that when 90 percent FFP is used to purchase an “open source” module, by definition, the state and CMS can share the module with other states and contractors. Another commenter recommended that this final rule exempt COTS software from the Software and Ownership Rights provisions in § 95.617(b). The commenters expressed concern that the current language presents an immense financial risk to vendors and as such poses a barrier to the proliferation of COTS software.

Response: We acknowledge that the interpretation of 42 U.S.C. 1396b(a)(3)(A), which provides 90 percent FFP for the DDI of such mechanized claims processing and information retrieval systems, to include use of COTS as part of the design where that solution would be the more economical and efficient approach, necessitates a refinement and clarification of the policy relating to the applicability of § 95.617(b) to COTS software. We clarify that the 90 percent match is not available for the purchase of COTS, but is available for the initial licensing fee and costs to analyze, configure, install, and integrate the COTS into the design of the state's MMIS system. When the enhanced match is used for COTS enhancements, configuration or customization, those elements become subject to existing regulation at § 95.617 regarding ownership and royalty-free licensing. The COTS itself is not designed, developed or installed with the 90 percent match; but the initial licensing fee is a necessary part of the development of a system that uses the COTS. Subsequent licensing fees would not be necessary for the DDI process and would be considered to be operational expenditures that would be matched at the 75 percent rate applicable to operation of an MMIS.

We do not agree that this rule creates a disincentive to vendors to develop COTS products. Rather, we believe that paired with the existing regulations about software developed with federal funding, our final policies incentivize vendors to join the Medicaid IT market because more states will be willing to utilize COTS. Offering the 90 percent match for a substantial portion of states' costs related to the integration of COTS software solutions into the design of state systems will encourage more states to seek COTS software products and services, as will the requirements for modular architecture. These final policies will drive the emergence and adoption of more COTS solutions, thereby increasing broader vendor participation while protecting state and federal funding from unnecessary duplicative development.

The regulation at § 95.617(a) requires that the state have ownership rights in software or modifications designed, developed or installed with FFP. For this requirement the emphasis should be on the, software or modifications designed, developed or installed with FFP. The COTS product itself is not designed, developed or installed with FFP, but is used in a system that meets those conditions. The initial licensing fee is necessary to allow the state to design a system that uses the COTS product, and there are also development and installation costs for the modifications that enhance, customize and configure it to the state and enable it to be installed in that state's system. The COTS product itself is designed and developed by the vendor, so the state is not entitled to ownership rights to the core program, only to those elements designed for, and paid for, specifically by that state so that the COTS product can be used in the state's system. In other words, we read the requirement for a royalty-free, non-exclusive and irrevocable license to software referenced in § 95.617(b) to apply in this instance only to the software related to the customization, modifications and configuration of a COTS product for state use, not the core product.

For these reasons, the final rule at § 433.112(c)(2) provides for the application of the 90 percent match to the cost to procure COTS software, that is, initial licensing fees, and costs to analyze, configure, install and integrate that software into a system. The 90 percent is not for the outright purchase of the COTS product itself. If such products were purchased outright with Federal funds then the provisions at § 95.617(a) and (b) would be applicable. We note that these same principles will be used to evaluate the eligibility of SaaS for enhanced match, that is, only costs related to analysis, configuration, installation and integration will be eligible for the 90 percent match.

The regulation at § 95.617(c) provides that FFP is not available for proprietary applications developed specifically for the public assistance programs covered under this subpart. For the Title XIX, Medicaid, and Title XXI, CHIP, programs under the newly developed enterprise systems that support the Affordable Care Act, CMS is supporting only systems that function seamlessly with the health insurance marketplace, whether the federally facilitated marketplace or state-based marketplaces. As such, functionality for these systems cannot be considered specifically for the public assistance programs covered under this subpart, in this case, Titles XIX and XXI, but are necessarily broader than those programs. Indeed, seamless integration with the marketplaces, health information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance are requirements for the enhanced funding under § 433.112(b)(16) of this final rule. It should be noted that not all systems must interface with all of these entities, but where such integration is required for the efficient operation of the enterprise, such integration must be seamless and transparent to beneficiaries. The condition of § 95.617(c) regarding proprietary applications developed specifically for titles XIX and XXI do not apply to the COTS products for which certain costs are eligible for the 90 percent match, because these products are not specifically for title XIX and XXI, but must include the broader health insurance enterprise.

Comment: A commenter recommends that we develop a framework in conjunction with software vendors related to ownership to avoid a number of potential issues. The commenter made recommendations in the area of issues related to proprietary software and shared modules.

Response: We will take into consideration the commenter's concern regarding establishing software framework that other states may leverage. We will address issues related to proprietary software and shared modules in subregulatory guidance.

Comment: Many commenters made recommendations on the proposed definition of shared services. One commenter suggested that the definition be expanded to include sharing between and among states. Another commenter requested clarification on the use of the word “provision” in the definition of a shared service. One commenter proposed the following as a definition of “Software-as-a-Service”: “Proprietary Software that is hosted by a service provider and used and accessed by the subscription holder licensee over a network such as the Internet. SaaS is provided to the subscription holder as a periodic or pay-as-you-go subscription with on-demand access to the Proprietary Software according to the terms of a SaaS subscription agreement.”

Response: We clarified the definition of shared services in this final rule by removing the word “provision” and by referencing the availability of the service whether within or outside of a state. We also included SaaS in the definition. We have considered the commenter's definition of SaaS, however, we are not adopting it because we believe it defines proprietary software rather than SaaS. We believe the definition in this final rule accurately describes the key characteristics of SaaS.

Comment: One commenter recommended the removal of the final sentence of the definition for Shared Services, which is: “The funding and resourcing of the service is shared and the providing department effectively becomes an internal service provider.”

Response: We believe the final sentence for the definition of Shared Services is critical to the understanding of this phrase in the context of Medicaid and other human service programs. We modified language in this definition in this final rule to provide greater overall clarity.

Comment: One commenter recommended that we clarify the approach to and definition of a module. The commenter further recommended that a core set of modules be identified and defined through a collaborative workgroup of representative states, vendors, and CMS. Several commenters requested clarification of the definition of an “MMIS module” and guidance regarding timing for multiple modular implementations and the life expectancy of a module. Some commenters offered alternative definitions. Some commenters requested definitions for the following: Module, modular, modularity, and the Modularity Standard.

Response: The language in the final rule at § 433.111(h) has been modified to define a module as 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. Each module of a system has well-defined, open interfaces for communicating with other modules, encapsulates unique system functionality and has a single purpose, is relatively independent of the other system modules. Two principles that measure module independence are coupling, which means loose interconnections between modules of a system and cohesion, which means strong dependence within and among a module's internal element (for example, data, functions, internal modules). Examples of modules include eligibility enrollment, fee for service claims administration, managed care encounters & administration, etc. Other modules may be recognized based on new statutory regulatory requirements or federal state business needs. A listing of modules will be included in subregulatory guidance rather than in this final rule to allow for flexibility and future updates and revisions responsive to change requirements and IT development.

Comment: One commenter suggested consolidating the MMIS and E&E APD review, as well as other work products (that is, Enterprise Life Cycle (ELC) gate reviews, status reports, etc.).

Response: We will take this request under advisement but at this time consolidation of the MMIS and E&E APD review, as well as other work products (that is, ELC gate reviews, status reports, etc.) may not be a practical approach, we believe such tandem treatment will not be possible until the enterprise approach is fully matured.

Comment: We received a request for clarification on the meaning of “approved enhancements” found at § 433.111(b)(1)(iii).

Response: This term refers to our approval of states APDs for Medicaid systems DDI projects.

Comment: One commenter requested clarification as to any differences with respect to certification between MMIS and E&E.

Response: We require formal certification of MMIS for enhanced funding for operations and maintenance. Certification is not required for E&E systems, however E&E systems are subject to the Medicaid IT conditions and standards unless otherwise noted as MMIS-only and must meet CSFs and other performance standards to qualify for the 75 percent enhanced match for M&Os.

Comment: One commenter asked about whether modules implemented by the vendor community can be “harmonized” with the certification definition of a module.

Response: We believe that the MMIS Modular certification process will create an incentive for the states to take a modular approach both in IT architecture and in procurement strategy. States and vendors are encouraged to follow the modularity principles in their development of new MMIS modules. We are continuing to seek comments and collaboration from the vendor community. We believe that a harmonization of vendor activities, state needs, and federal requirements is possible and will pursue a means to achieve this goal.

Comment: A commenter requested clarification (for systems built with the 90 percent FFP) that we, “consider strategies to minimize the costs and difficulty of operating the software on alternate hardware or operating systems,” and asked whether this refers to MMIS, E&E, claims, or all of these. The commenter also asked whether this would refer to an open source system that could easily be moved to another platform or if it referred to a disaster recovery system.

Response: At § 433.112(b) we specify that the following conditions apply to both E&E and claims systems. The only exception to this is at § 433.112(b)(17), in which the regulation specifies applicability limited to E&E systems. The condition at § 433.112(b)(21) refers to operating on other hardware or operating systems. Disaster recovery is a separate requirement addressed at § 95.610(b)(11).

Comment: One commenter asked for clarification regarding the match for the modification of non-COTS software to ensure coordination of operations.

Response: DDI of non-COTS products, including modifications to ensure coordination of operations, continue to be matched at 90 percent FFP.

Comment: One commenter recommended that we clarify the difference between customization and configuration of COTS products. Several commenters inquired about the parameters regarding “little or no modification” and “over-customization” of COTS and how that will be measured.

Response: We appreciate this recommendation and we will clarify the difference between customization and configuration of COTS products in subregulatory guidance. We acknowledge the relevance of general IT industry definitions for distinguishing between software configuration and installation versus software customization. The degree of modification that is acceptable for enhanced match is dependent on a number of factors, including the size and scope of the project and the cost of the modifications relative to overall project costs. The acceptable degree of modification will be evaluated on a case by case basis.

Comment: One commenter recommended that we provide additional clarity as to when in the Advanced Planning Document process states should specify all costs associated with DDI and modifications to COTS software.

Response: Subregulatory guidance will include greater detail on the APD requirements and approval process.

Comment: One commenter recommended that CMS provide subregulatory guidance for states to develop comprehensive risk assessment and management plans that can be reviewed at the start of procurement planning, that is, the onset of the ELC; and updated as necessary during subsequent project phases.

Response: We will provide subregulatory guidance on these topics.

Comment: One commenter recommends alignment of the contract approach in the MMIS DDI process with both the prime vendor and Independent Verification & Validation (IV&V) vendor sharing the risk for the success of the project.

Response: Contracts are executed between the state Medicaid agency and the vendor. We agree that contracts should clearly identify accountability for risk. However, we are not in the position to intervene in the states' contractual arrangements, but encourage states to address this risk in accordance with state procurement rules and project management.

Comment: A commenter requested clarification regarding whether the state can modify the base software for COTS products in addition to customizations required for integration.

Response: We believe it is outside of the scope of this regulation to address detailed questions that we would expect to be addressed in the APD review process.

Comment: One commenter recommended to continue using CSFs for discussing both project status and system readiness and using the CSF approach when approving proposed modifications and customizations to COTS and SaaS solutions.

Response: We intend to continue to use the CSF approach as a means to monitor state implementation performance. We will consider uses of the CSF approach for approving proposed modifications and customizations to COTS and SaaS solutions.

Comment: One commenter asked what the definition of “minimum necessary costs” is and who determines whether or not a state's proposal meets this definition.

Response: “Minimum necessary costs,” means only those expenditures required to analyze the suitability of the COTS software, and to configure, install and integrate the COTS software. It may also include expenditures for modification of non-COTS software to ensure coordination of operations. During the APD, procurement, and contract reviews, we will determine if the proposed costs are limited to the purposes specified previously. As is our current practice, these reviews will include dialogue with the state to ensure our decision is accurate and equitable.

Comment: A commenter asked for clarification on a case where CMS determines after the reapproval review that the system no longer meets the conditions for reapproval. CMS will reduce FFP for certain expenditures for system operations. Clarification is requested on what is meant by certain expenditures. Is there a predefined list, or is this determined on a case by case basis?

Response: We intend to assess on a case-by-case basis the extent to which that state's system is non-compliant and will propose to reduce FFP for specific system functionality operation costs, which might be one or more module(s).

Comment: One commenter asked if mitigation plans have to be submitted with the APD. Another commenter requested a template for mitigation strategies.

Response: We will issue subregulatory guidance that includes more details on developing and submitting a mitigation strategy. However, we note that identification of potential projects risks, key milestones and potential mitigations is an industry standard for major IT builds.

Comment: One commenter raised a question concerning the phrase, “strategies for reducing the operational consequences of failure” and questioned who would determine what constitutes a failure. The commenter noted that the state is expected to address the operational consequences of failure, and the meaning of failure is for the state to determine. Another commenter suggested that CMS, HHS' Administration for Children and Families (ACF), and the U.S. Department of Agriculture's Food and Nutrition Services Program develop joint performance measures for integrated eligibility systems, in conjunction with states and other external stakeholders.

Response: We recognize this concern. We have identified CSFs and performance standards related to various systems functionality and will continue to work with states to identify additional metrics of success for E&E systems, including non-MAGI functionality, and for MMIS systems. We are taking the suggestion of joint performance measures for integrated eligibility systems into consideration and will address that effort independently of the final regulation.

Comment: One commenter requested clarification on the parameters of, “limited mitigations and workarounds,” and suggested that factors such as time limitations, frequency, quantity, and/or severity be considered.

Response: We agree that these factors should be considered when evaluating what constitutes “limited” mitigations and workarounds, and would consider other factors such as impact on the beneficiary, impact on access to care, and impact on providers. Every systems build varies for scope and impact, therefore we cannot specify within this rule specific parameters for what constitutes “limited”, but will evaluate on a case by case basis.

Comment: One commenter proposed that mitigation plans apply to both MMIS and E&E.

Response: The requirement in this final rule is to have mitigation plans for both MMIS and E&E, as specified at § 433.112(b)(18). We provide clarification on the process and procedure of contingency planning within the CMS Expedited Lifecycle (XLC) Model, as described in the CMS Expedited Lifecycle Process: Detailed Description 3.3 available at https://www.cms.gov/​Research-Statistics-Data-and-Systems/​CMS-Information-Technology/​XLC/​Downloads/​XLC-DDD.pdf. We will issue additional subregulatory guidance regarding the expanded discussion of mitigation planning to reduce risk, and will allow necessary flexibility depending on the nature and scope of the project.

Comment: Several commenters recommended adding an additional condition at § 433.112(b) for states to collect and submit key E&E performance indicator data on a regular basis to ensure that purchases of COTS software represent good value and will not subject the state to inappropriate future costs or loss of flexibility.

Response: Performance indicators already exist [see “Federal Funding for Medicaid Eligibility Determination and Enrollment Activities” (75 FR 21950) and “Eligibility Changes under the Affordable Care Act of 2010” (77 FR 17144)] for E&E Systems] and we will consider the development of MMIS performance measures in conjunction with the MMIS certification criteria for future subregulatory guidance.

Comment: One commenter expressed concern that all of the stipulations included in § 433.112(b) may not apply to each module for which a state may submit an APD and that CMS should consider changing the proposed wording of § 433.112(b) to, “CMS will approve the E&E or claims system or service modules described in an APD if the applicable conditions as determined by CMS are met. The conditions that a system or service module, whether a claims or E&E system, must meet as applicable are:”

Response: We believe that the wording of § 433.112(b) does not require revision, so we are retaining the language of the proposed rule in this final rule. We believe that terminology such as “applicable” does not add clarity because it still fails to specify exactly what standards and conditions would apply in what circumstances. We believe that subsequent guidance and a case by case evaluation during the APD approval process will be supported by the language in this rule, but allow the flexibility to apply standards and conditions appropriate to each particular project.

Comment: A few commenters expressed concern over the new condition at § 433.112(b)(22), “Other conditions as required by the Secretary,” that reserves the right of CMS to add conditions without going through the rule making process, and suggested that this may exceed statutory authority. It was noted that this provision is incorporated into § 433.119, which pertains to conditions for re-approval to receive the 75 percent match, and there was concern that if the proposed language was adopted, a state's enhanced funding could be jeopardized by a new condition on which the state has had no opportunity to comment and may not have sufficient notice. One commenter asked CMS to clarify whether the addition of new criteria and modifications to the existing standards and conditions under this revision will impact current state approvals. The commenter also asked CMS to clarify whether a state whose standards and conditions are currently approved will be required to obtain a new or revised approval of system compliance. One commenter suggested § 433.119(a)(1) be amended to require that CMS adopt any additional conditions in compliance with 5 U.S.C. 533's public notice and comment process. The commenters asked us to delete the provision or, alternately, add some parameters to clarify the intent of the condition.

Response: We appreciate the comment and we are clarifying the language of § 433.112(b)(22) to provide that the additional conditions that may be issued by the Secretary will not be new requirements, but will be limited to guidance on conditions for compliance with existing statutory and regulatory requirements, as necessary to update and ensure proper implementation of those existing requirements. Should new requirements be necessary, we would follow required rulemaking procedures to modify the regulations. The language of § 433.112(b)(22) is intended to recognize that implementation of the statutory and regulatory requirements may require interpretive guidance that sets forth conditions for compliance with those requirements. Moreover, we clarify that we do not intend to add conditions without first consulting with states and other stakeholders. Such standards would not be applicable retrospectively. We believe the flexibility to update guidance on conditions for compliance with statutory and regulatory requirements is necessary to meet the demands of evolving business processes, so we are retaining this modified language in this final rule.

Comment: Several commenters expressed concerns that the inclusion of E&E is confusing and that the Seven Standards and Conditions are MMIS-specific. Clarification is requested on how the new or expanded Standards and Conditions apply to E&E systems and asks whether the 7 Standards and Conditions apply to only MMIS or to E&E also.

Response: The standards and conditions in this rule apply to any systems projects within the Medicaid enterprise, E&E or MMIS, except the requirement at § 433.112(b)(17), which is specific only to E&E systems.

Comment: One commenter requested the clarification on whether the addition of new criteria and modifications to the existing standards and conditions under this revision will impact current state approvals.

Response: We do not intend to retroactively apply the revised standards and conditions to APDs already approved as of the effective date of this rule. However, they will be applicable to APDs pending as of this effective date, or approved on or after this effective date.

Comment: One commenter suggested we include non-MAGI Medicaid at § 433.112.

Response: This provision is applicable to all Medicaid programs, which include both MAGI and non-MAGI.

Comment: A commenter asked, with respect to MAGI-based system functionality, what is the definition of “acceptable” performance and who makes this determination. One commenter suggested CMS add a condition that E&E systems must deliver acceptable MAGI functionality, and identify the factors to be considered. Another commenter suggested that “acceptable” criteria be defined as part of the Payment Error Rate Measurement (PERM) audit work currently underway.

Response: Whether or not MAGI-based functionality is acceptable is determined in the gate review process and is evaluated with the language that follows in the same clause, “demonstrated by performance testing and results based on CSFs, with limited mitigations and workarounds.” We agree with the commenter's suggestion to adopt a flexible approach to addressing deficiencies in this E&E, similar to that proposed for MMIS system modules, and will issue subregulatory guidance with additional detail on this topic.

Comment: Several commenters have requested clarification of the proposed language in § 433.112(b)(18) and § 433.112(c)(2) regarding the definition of “major milestones and functionality”.

Response: This refers to the major milestones in the State's APD submission.

Comment: One commenter asked CMS to clarify whether CMS's proposed wording at § 433.112(b)(21) that states, “consider” strategies to minimize costs, could be more explicitly stated with this rule.

Response: We believe that the wording in the proposed rule for states to consider certain strategies to minimize costs is sufficient, and therefore will not be making changes to this final rule. Further discussion will be included in subregulatory guidance.

Comment: A commenter asked that in the phrase, “the state must consider strategies to minimize costs”, the word “consider” be changed to “present”. Another commenter requested clarification on how states measure operating cost on any hardware system in order to minimize cost and effort. This commenter questioned how a state can measure this operating cost on any hardware system other than its intended use as specified in that states' APD.

Response: We believe it is understood that all decisions included in the APD, including strategies to minimize costs must be documented and/or fully discussed to attain approval, therefore we do not believe it is necessary to change the word “consider” to “present”. We refer the commenters to the MITA Roadmap as an effective means to realize infrastructure cost savings. Further, a state can outline their progress toward meeting the MITA roadmap in their APD submission.

Comment: One commenter expressed concurrence that a state must submit plans that contain strategies for reducing the operational consequences of failure to meet applicable requirements for all major milestones and functionality with the APD submission.

Response: We appreciate the feedback. We consider risk management as an on-going activity during the planning, implementation and operations phases of the system lifecycle.

Comment: One commenter offered specific language to amend § 433.112(b)(6), which states that, “The Department has a royalty free, non-exclusive, and irrevocable license to reproduce, publish, or otherwise use and authorize others to use, for Federal Government purposes, software, modifications to software, and documentation that is designed or developed with 90 percent FFP.”

Response: We did not propose any amendments to § 433.112(b)(6) and therefore we are accepting as final the provision set forth as stated in the April 16, 2015 proposed rule. However, we look forward to the possibility of further discussion of this subject matter during some of the established forums as outlined in the Program Affected section of this final rule.

Comment: We received several comments requesting clarification on providing the names and responsibilities of key state and vendor personnel in both the Planning and Implementation Advance Planning Documents (PAPD & IAPD). We received a recommendation to add additional language to this requirement to read, “identifying key state personnel for their primary responsibilities and their decision-making authority, and that CMS and the vendor are notified in writing when changes are made.” One commenter recommended limiting the reporting of key personnel per the IAPD template, to limit the burden on to the state. Additionally, we received a recommendation to issue subregulatory guidance on resource management plan and matrix reporting and what kinds of roles constitute key personnel.

Response: We agree that clarification is needed and changed the language to identify key state personnel by name. This applies to all APDs. We agree that key vendor personnel should be identified as cited in regulation related to CMS approval requirements. Additionally we will consider issuing subregulatory guidance on how to identify key state personnel based on their primary responsibilities and their decision-making authority, and if any personnel changes should be communicated in writing to CMS and the state.

Comment: One commenter suggested including vendor staff as identified key personnel, and encouraged states to limit the number of key staff that vendors are required to identify. Additionally, the commenter suggested CMS might also want to consider including guidelines regarding the need to have vendor key staff onsite for the entirety of the project.

Response: We will include further discussion in subregulatory guidance, including when key vendor staff must be named. Given the changing world of software development and wireless communications, we encourage states to revisit their policies requiring all key vendor staff be onsite. However, to require such a change is outside of the scope of this regulation.

Comment: Two commenters asked if key state personnel résumés are required as part of the APD submission.

Response: Résumés are not a requirement.

Comment: One commenter expressed concern that identifying and providing key state staff/personnel as a new APD requirement may negatively influence or create a scenario where CMS may exert its influence over internal state staffing decisions, or that it might fundamentally alter and undermine existing relationships between the state and CMS.

Response: We disagree with the commenter's assessment. We value our state and federal partnership, and believe that having states dedicate key state personnel to IT systems project is a best practice. Additionally, we want to emphasize the need to identify key personnel to identify those who may be over committed to multiple projects and therefore place projects at increased risk.

Comment: A commenter asked for clarification on whether the word “system”, in § 433.112(b)(16), refers to the E&E system, the MMIS system, or both systems.

Response: In this context we are referring to both an E&E system and a MMIS according to the approved E&E and/or MMIS APD.

Comment: One commenter recommended measuring progress of a state's project as noted in subregulatory guidance released November 2012, entitled, “Medicaid and CHIP FAQs: Enhanced Funding for Eligibility and Enrollment Systems (90/10),” rather than identifying key personnel.

Response: We agree with the state's recommendation to measure the progress of state projects as noted in subregulatory guidance released November 2012, entitled, “Medicaid and CHIP FAQs: Enhanced Funding for Eligibility and Enrollment Systems (90/10)”. However, we want to emphasize the need to identify key state personnel based on our observation that states may over commit staff to multiple projects and therefore increase project risk and delays.

Comment: One commenter inquired about CMS's intent and application of § 433.112(b)(10), which allows the use of modular, flexible approaches to systems development, including the use of open interfaces and exposed application programming interfaces, on E&E systems.

Response: This final rule at § 433.112(b)(10), applies to all mechanized claims processing and information retrieval systems, including both E&E systems and MMIS.

Comment: A commenter recommended that CMS conduct a certification of vendor products that meet the Seven Conditions and Standards.

Response: We concur with the comment to certify vendor's MMIS products that meet the Seven Standards and Conditions. We intend to address this subject in subregulatory guidance.

Comment: One commenter stated that HIPAA transactions and code sets should be acceptable for certification purposes and FFP.

Response: We concur that HIPAA compliance is required for MMIS, but note that there are additional standards that states must incorporate to be fully compliant and interoperable as specified in this final rule at § 433.112(b).

Comment: Two commenters asked about whether they could leverage documentation provided to CMS during the GATE Review (XLC) process to support the Modular MMIS certification process.

Response: We encourage reuse in many different forms including leveraging documentation provided to us during the XLC process.

Comment: A commenter asks if the E&E APD must include assurances that the states' MMIS meets the MITA assessment criteria.

Response: An E&E APD need not include assurances regarding the states' MMIS MITA self-assessment. We remind states to use the CMS IT Guidance 2.0, which outlines the use of MITA for E&E systems.

Comment: One commenter requested CMS provide clarification on shared system components to encourage reuse between integrated eligibility systems and MMIS.

Response: We appreciate the commenter's recommendation and will take it into consideration for future subregulatory communications and guidance.

Comment: A commenter requested clarification that the requirements for detailed documentation and for analysis of cost minimization and use of alternate hardware or operating systems are not required for legacy systems implemented prior to the effective date of the proposed rule.

Response: These requirements will not be required for a legacy system but we will apply to these requirements if any component from the legacy system were to be transferred or shared.

Comment: One commenter expressed concern that this documentation would be of limited value and that this requirement would be hard to meet due to differing methods and technical environments. This commenter also expressed that it does not support the proposed change to require such documentation.

Response: We acknowledge these concerns but believe that this documentation would contribute to sharing and reuse. We believe that this requirement may serve to provide more consistent methods and technical environments. We are therefore retaining this requirement in the final rule.

Comment: A commenter expressed some concerns regarding use of shared components. The commenter expressed that requiring the use of existing components may preclude some vendors from offering solutions in response to an RFP and that it may not be feasible to share components where the various modules are hosted in multiple separate data centers procured through separate contracts. The commenter explained that requiring the use of existing or shared components would reduce the solution options available to the states and requested that FFP not be restricted for the development costs of implementing new components as part of the MMIS or E&E systems.

Response: We acknowledge these points, and will provide clarification that sharing and reuse are intended as accelerators, not impediments, to be leveraged wherever they can produce an efficiency or gain. The final policies in this regulation do not prevent us from considering state proposals that justify the need for custom developed software for the enhanced match, or that only shared reused software will be eligible.

Comment: One commenter stated that the language of proposed § 433.112(c)(2) should include the cost of procuring the software (or licenses to use the software). The commenter also recommended that the regulation be clarified to clearly state that the infrastructure changes necessary to support the COTS system (for example, servers and storage) should also qualify for 90 percent FFP.

Response: The 90 percent match rate remains for the planning, DDI of systems and the 75 percent match remains for COTS licensing costs. No change to the regulation is needed to permit the enhanced match for procurement, as it already is matched at 90 percent FFP. Infrastructure and hardware costs will need to be included in the APD submission and will be evaluated for the applicability of the 90 percent match during the APD review.

Comment: A few commenters recommended updating § 433.116(j) by removing the December 31, 2015 end date.

Response: We concur with the recommendation to update § 433.116(j) by removing the December 31, 2015 end date, and included this change in this final rule.

Comment: One commenter disagreed with our justification to extend enhanced FFP to allow the states to complete fully modernized systems. The same commenter believes that extension of the FFP will result in two systems—one for Medicaid and one for human services—resulting in duplicative administrative costs and more than twice the burden for program participants eligible for Medicaid and any one of the many human service programs; for example, SNAP, child welfare, LIHEAP, etc.

Response: We recognize the importance of integrated eligibility systems and we are actively working with our federal partners to facilitate this effort, including federal financial support. We believe that we will be able to address states' concerns to encourage continued integration.

Comment: One commenter asked if the 75 percent FFP will also include support staff, appeals staff, etc. who are not eligibility workers, but are part of the Medicaid process.

Response: We issued clarification on this topic in the “Medicaid and CHIP FAQs: Enhanced Funding for Medicaid Eligibility Systems” originally released April 2013 and currently posted on Medicaid.gov. In applying the 75 percent match to E&E systems we sought to identify roles and functions analogous to those matched at 75 percent for MMIS systems.

Comment: Relative to the federal performance review one commenter expressed appreciation of the flexible approaches available for the federal performance review but urged CMS to consider alternative language that conveys the intent expressed in the preamble of the proposed rule for HHS to perform regular automated validation of accurate processing and systems operations and performance.

Response: We acknowledge this recommendation and agree as to the importance of regular automated validation of accurate processing and systems operations and performance.

Comment: Two commenters asked CMS to clarify how often CMS planned to conduct periodic reviews of systems.

Response: With the April 19, 2011 final rule on regulations at § 433.110, we intentionally removed the requirement for a once every 3-year review of such systems, but did not remove references at § 433.110(a)(2)(ii) and (iii). The failure to remove § 433.110(a)(2)(ii) and (iii) was a drafting error. With this final rule, we are only correcting that error in the 2011 final rule. At this time, we have not specified requirements for periodic reviews but retain the authority to conduct them as part of our oversight role.

Comment: One commenter agreed with the removal of language that requires CMS to review systems once every 3 years in order for states to continue to be eligible for the enhanced 75 percent federal match for ongoing maintenance of their systems. However, the commenter suggested a provision carrying over language from the preamble stating that “the Secretary retains authority to perform periodic reviews of systems receiving enhanced FFP to ensure that these systems continue to meet the requirements of section 1903(a)(3) of the Act and that they continue to provide efficient, economical, and effective administration of the plan.”

Response: We appreciate the commenter's support for review to ensure on-going quality of systems performance, but we do not believe it is necessary to include the wording from the preamble in the regulatory text. We believe the statute provides sufficient support for this activity.

Comment: One commenter requested clarification regarding whether or not CMS will continue conducting annual IT reviews with states.

Response: We appreciate the request to clarify the role of annual reviews and have provided this clarification in the document entitled “Guidance for Exchange and Medicaid Information Technology Systems 2.0 (May 2011),” which can be accessed at https://www.cms.gov/​CCIIO/​Resources/​Files/​Downloads/​exchange_​medicaid_​it_​guidance_​05312011.pdf.

In addition, we proposed to amend § 95.611(a)(2) by removing the reference to 45 CFR 1355.52. This paragraph provides prior approval requirements when states plan to acquire ADP equipment or services with FFP at an enhanced matching rate for the Title IV-D, IV-E, and XIX programs, regardless of acquisition costs. We proposed to delete the reference to the Title IV-E regulation, 45 CFR 1355.52 because enhanced funding for information systems supporting the Title IV-E program expired in 1997.

We received no comments in response to our technical amendment to § 95.611 and will finalize as proposed.

We invited comment on our intention to move to a modular certification process for MMIS, based upon the MITA business processes (http://www.medicaid.gov/​Medicaid-CHIP-Program-Information/​By-Topics/​Data-and-Systems/​Medicaid-Information-Technology-Architecture-MITA.html) to seek an optimal balance in the use of open source and proprietary COTS software solutions, to further promote reuse, to expand the availability of open source solutions, and to encourage the use of shared services. Modular MMIS certification would allow the states to access the 75 percent FFP for M&Os of the certified module(s) prior to having completed their total MMIS system replacement.

We also sought comment on the advantages and disadvantages of certifying MMIS modules, versus whole systems. We believe that certifying MMIS modules will remove the barrier to entry for many small IT solution vendors, increase the availability of certified modules in the market for the states to choose from, and create an incentive for the states to take a modular approach both in IT architecture and in procurement strategy. We solicited comments on the opportunities that a modular MMIS certification process may create as well as the challenges that might arise, including defining a finite list of MMIS modules to ensure the appropriate combinations of certification criteria are established. In response to the comments received we will issue subregulatory guidance which will specify various MMIS modules and how a modular certification process will be implemented.

We also sought comments on a model where vendors propose modules for CMS certification prior to the state installation, unrelated to the question of the state's enhanced match rate for M&Os. Many commenters agreed that Modular MMIS certification process will result in better procurements, faster time to benefit, and a rapid adoption of industry standards in Medicaid.

We received the following comments on these topics:

Comment: A commenter recommended that we be more inclusive about sourcing options and eliminate the relation of “modular” to sourcing or procurement and that CMS adopt the term “multi-sourcing” or “portfolio sourcing” so that sourcing should not be viewed as a one-size-fits-all scenario.

Response: This recommendation will be taken into consideration for future communications regarding MMIS acquisition and modularity.

Comment: A commenter expressed concern that modular solutions may function as standalone silos intended to be interfaced with other MMIS solutions and utilize a separate copy of the MMIS data. The same commenter also mentioned that the replication of MMIS data into multiple operational data stores potentially located in multiple data centers increases data storage costs, integration development and maintenance costs, potential failure points in the system, and security risks. The recommendation was made that CMS analyze the MMIS solutions available in the market for effective support of the modular approach and consider this when evaluating the states' IT architecture and procurement strategies.

Response: We agree that this is a valid concern and one that should be taken into consideration in making design and procurement decisions.

Comment: Several commenters tied enhanced funding to improving state data quality and reporting and the associated adequate investment in staffing and human capital needed to accomplish this goal. One commenter expressed concern about the impact of a modular approach on human resource management, which will require increased planning activities. The commenter expressed that states and CMS will need to organize and staff accordingly; and that there is further dependence on system integrator capabilities. Additionally, the commenter stated there would be increased dependence on integration between state programs, technical management and contractors.

Response: We appreciate the commenter's concern and concur that states and CMS must thoughtfully estimate project costs and human resource needs upfront to address the complexities of managing modular functionalities. We believe that the investment of enhanced FFP should result in a higher level of performance which should be evidenced in reported metrics. We believe that investments in software and hardware alone cannot achieve high quality results without an adequate staffing compliment. We encourage states to carefully evaluate their human resources that support systems builds and operations to ensure that there is adequate oversight of projects and on-going supervision of operations.

Comment: One commenter expressed concern that a third party systems integrator having no direct contractual relationship with the modular solution providers would be ineffective and noted that the state would have the key role in managing the contracts. The commenter requested that we recognize the importance of the Fiscal Agent/Systems Integrator having the primary contract for the MMIS solution and that they should be managing the various modular solution providers as subcontractors. Another commenter suggested that a new APD requirement should be to require states to include its strategy, if using a modular development, and resources (staff verses contractual) in the APD. Federal regulations at 45 CFR part 95, subpart F, “Automatic Data Processing Equipment and Services,” specifically mandate that states provide a plan of action in order to request federal funding approval for a project. In addition, the commenter also suggested clarifying the distinct roles and responsibilities of an Independent Verification & Validation (IV&V) vendor and Systems Integrator.

Response: We find this recommendation to be consistent with the role we see for the system integrator relative to other vendors employed in the cooperative modular process; however we do not believe that this should be incorporated into regulation. The APDs used to request FFP should describe states' plans for managing its systems DDI. Title 45 CFR part 95, subpart F also sets forth the roles and responsibilities of the IV&V, if required. We plan to provide subregulatory guidance on this issue and we will include a discussion of these roles in subregulatory guidance.

Comment: A commenter requested clarification on whether the modular approach applies to both MMIS and E&E systems, or to just MMIS. Additionally, the comment asked if the modular approach applied only to MMIS, why there was not an equivalent definition for E&E Module, and provided some suggested modules.

Response: While the modular approach to system architecture applies to both MMIS and E&E, we do not require certification of E&E systems. We have not specified any required MMIS modules in this final rule. We will consider identifying required MMIS modules in subregulatory guidance.

Comment: One commenter asked about how CMS will incentivize modular development when a state transitions from a monolithic MMIS to a modular approach within current state contracts.

Response: Modular development helps with seeking an optimal balance in the use of open source and proprietary COTS software solutions, further promotes reuse, expands the availability of open source solutions, and encourages the use of shared services. Modular MMIS certification will allow the states to access the 75 percent FFP for M&Os of the certified module(s) prior to having completed their total MMIS system replacement. We will work with states individually that wish to transition to modular development to assess the most efficient path forward.

Comment: One commenter pointed out the challenges associated with integrating modules if done so on a piecemeal basis. This commenter mentioned that the procurement and implementation of a modular based approach requires a detailed design of the end-to-end data integration requirements at a data element level before those processes can be initiated. This commenter suggested that as more states achieve readiness to transition to a modular system, a more specific definition of an MMIS module should evolve. The commenter provided a list of modules that can be defined by CMS within the regulation. The commenter further stated the positive aspects of modular certification including reduced implementation risks and a reduction in costs.

Response: We have modified the definition of module at § 433.111(h) in this final rule. A list of modules and additional discussion will be included in subregulatory guidance.

Comment: Many commenters asked questions about the Modular MMIS certification process pertaining to pre-certification requirements, re-certification of modules, triggers for recertification, process alignment with MITA, length of the process, and availability of checklists.

Response: We will be issuing subregulatory guidance on how MMIS modules will be certified and how a modular certification process will be implemented. Additionally, it is also our intent to work with the states as systems are designed and developed on a continuous basis so that issues and solutions are identified and addressed prior to the certification stage.

Comment: A commenter agreed that modular certification will lower the barriers to entry for smaller IT solution vendors and increase the availability of modules in the marketplace. That commenter recommends that vendors be able to propose modules for pre-certification by CMS. They point out that many state RFPs require that vendors demonstrate that they have “certified” their systems in other states, so the pre-certification process will be important in enabling new vendor participation in this market. They recommend that CMS work with industry and states to structure permissible penalties in state contracts when pre-certified modules are used, and especially when those solutions are customized at state direction.

Response: The provisions proposed here mark a significant departure from current CMS policy. We agree that modular certification will lower the barriers to entry for smaller IT solution vendors and increase the availability of modules in the marketplace. We appreciate the commenter's support of the proposal to strengthen accountability for successful system functionality, however states and vendors are responsible for negotiating their contracts and both parties should carefully ensure that accountability and penalties for failed implementations are clear.

Comment: A few commenters recommended staged, incremental approach to pre-certification starting with a common software product as well as a common service used in MMIS and E&E. One commenter suggested that the documentation for these pre-certified modules would need to be made available for review by states in their consideration of the appropriate project approaches for implementation.

Response: We believe recommendation for a staged, incremental approach to pre-certification process is a valuable concept and we will consider it carefully as we develop our implementation.

Comment: One commenter asked whether CMS intended to pre-certify certain vendor solutions; and, if so will CMS collaborate with industry before adopting a process or issuing subregulatory guidance.

Response: We will issue subregulatory guidance on how MMIS modules will be defined and how a modular certification process would be implemented.

Comment: A commenter requested clarification on when and how CMS will begin to pre-certify E&E solutions for pilot for states review.

Response: Note that E&E does not require certification.

Regarding our proposal to pre-certify MMIS modules and then complete the certification once installed and implemented, we received many comments expressing concerns for timelines so that innovation not be stifled and that reuse not be hampered. Several commenters expressed support for initial certification and enhanced funding of modules prior to full integration but reminded us that we will need to validate that the functionality works as designed and documented. It was recommended that use cases be defined to demonstrate that each MMIS module's functionality is operating as intended, using performance metrics such as key performance indicators.

Comment: Several commenters expressed concerns about the encouragement of software reuse in a manner that could expose security vulnerabilities, or possibly affect areas such as program integrity or enforcement, and negatively impact State Medicaid Programs.

Response: We recognize these concerns but do not believe they are exclusive to open source software. We will provide guidance on avoiding such risks while promoting sharing and reuse in future subregulatory guidance.

Comment: A commenter stated that the best approach for producing a sufficient level of detail is through community engagement and the development of working Proof of Concept (PoC) demonstrations. The commenter stressed the importance of ongoing community involvement in order for modularity, reuse, and interoperability in complex systems become a reality.

Response: We concur with the supportive comments to have ongoing community engagement, and it supports the goal of states developing working PoC demonstrations for modularity, reuse, and interoperability in complex systems.

Comment: One commenter suggested focusing on how states share similarities in performing business functions related to Managed Care as a basis for CMS, states and vendors to share and reuse IT solutions.

Response: We appreciate the insight provided by the commenter and will consider the suggestion. We concur that there is value in states exchanging information and experience around business functions they have in common.

Comment: A commenter made recommendations regarding the states' ability to share and reuse IT solutions while at the same time ensuring that there are appropriate incentives in the marketplace to provide the best quality and value in IT solutions and services to enhance operation of Medicaid programs nationwide.

Response: We appreciate the commenter's support of reuse of existing and shared components. We intend to address this in greater detail in subregulatory guidance. We will consider the commenters recommendations as we develop this guidance.

Comment: Several commenters recommended that the most effective way to encourage reuse is to certify modules prior to installation and to encourage states to utilize these modules and that it is important to clarify the vendors' business case for pre-installation certification.

Response: We concur and we intend to proceed with policy development around MMIS module precertification. There will be further discussion of the precertification requirements and process in subregulatory guidance.

Comment: One commenter recommends using a holistic view of the MMIS that requires a coordinated effort among CMS and the states to establish standards promoting reuse of open source code.

Response: We concur and will coordinate with states to establish standards and promote reuse.

Comment: One commenter recommends that an effective and efficient balance can be achieved when approving enhanced FFP for the acquisition of open source proprietary COTS software and information technology solutions, and they suggest a number of ways in which this could be done.

Response: We will consider these points in the formulation of subregulatory guidance and appreciate the input.

Comment: Several commenters had questions or sought clarity on setting dollar thresholds for incremental modernization and for COTS installation. A few commenters recommended that CMS consider providing clarity around what constitutes a noncompetitive install.

Response: We do not believe dollar thresholds are a workable solution because the size and scope of COTS applications will vary widely. We will provide guidance on what is a noncompetitive install in future subregulatory guidance.

Comment: A few commenters recommended that CMS consider selecting known vendors with proven Medicaid IT modules/components for a pilot with either CMS or a state and that this funding be made available through the MITA Roadmap and APD approval process. One commenter requested that CMS clarify its vision for the use of open source software and that open source code be piloted in order to demonstrate utility. The same commenter recommended that CMS facilitate introducing states to vendors.

Response: The funding available to us for MMIS development at sections 1903(a)(3)(A)(i) and 1903(a)(3)(B) of the Act only authorizes us to use matching funds for state system implementation and does not include pilot projects. It is one of our goals to stimulate competition and to help facilitate the entry of new vendors into the Medicaid IT market; therefore we would not engage in any project that would give one vendor an advantage.

Comment: One commenter explained that transfer solutions lose connection with the originating software because of the need for specific customization and adaptation to state environments. Some commenters recommend that CMS work with states and vendors to develop subregulatory guidance on this matter, including helping to standardize business requirements and workflows. They provide examples of the kind of guidance they are requesting. The commenter recommends CMS work directly with COTS vendors to ensure appropriate coverage of new or changing federal requirements.

Response: We acknowledge these points and will address them in subregulatory guidance. As stated previously, we plan to engage all stakeholders, for example, states, vendors and advocacy organizations, in developing this guidance.

Comment: One commenter suggested that CMS should allow states access to enhanced 90 percent FFP for customization of COTS and open source software based on a CMS-approved cost-allocation. We should encourage the use of contract language that stores initial and ongoing documentation and source code in a form and format that is easily accessible by states so that they can share.

Response: We concur. Further guidance is necessary in the area of customization to COTS and open source software and accessibility of documentation. We will expand upon this in subregulatory guidance.

Comment: One commenter recommended 90 percent FFP for implementing on-going COTS releases and M&Os activities.

Response: We appreciate the commenter's recommendation for 90 percent FFP for implementing on-going COTS releases, such as training, regression testing, configuration, and process modifications. Subregulatory guidance will clarify what activities will be matched at 90/10 and which will be subject to 75/25.

Comment: A commenter recommended that activities related to implementing COTS software as a module be included in the enhanced funding, since a significant portion of the cost to implement a COTS software as a module is related to configuration.

Response: We concur with the commenter's supportive comments on the use of configurable solutions with minimal customization and intend to address this in subregulatory guidance. To clarify, COTS software configuration costs are funded at 90 percent under this final regulation.

Comment: One commenter requested that we provide a framework against which to plan and subsequently validate COTS and open source code. Additionally the commenter expressed that as there is an increase in the variety of software being implemented there may be an increased complexity to the certification process.

Response: We agree with the comment and welcome a dialogue with state and vendors as an effective means to accomplish this goal.

Comment: One commenter expressed the concern that lack of an established governance and/or support model for any open source solutions not developed and/or maintained by a specific software manufacturer introduces significant risk of obsolescence from technology changes such as operating system upgrades and reduces the opportunity for shared development and upgrades in the long term. The commenter also mentions that the use of these open source solutions could present significant risk to the state because their use may not justify the cost savings over the use of equivalent COTS solutions. The same commenter requests that we recognize the long-term advantage of the COTS solutions.

Response: We agree that open source software or solutions are not impervious to the same challenges as other kinds of software, and we agree that there is a balance that must be achieved between cost and utility. While we do not agree that a COTS solution is necessarily less prone to these risks, we do highly support use of COTS solutions and, through this final rule provide equal financial support for proprietary COTS and open source COTS. We agree that we must provide guidance and on-going governance and support for both models and will explore this further as we develop subregulatory guidance.

Comment: One commenter recommended that business requirements be standardized nationally, and it supports CMS's efforts to facilitate collaboration among states with similar business requirements so that they may share and reuse IT solutions.

Response: We concur with the supportive comments on reuse of IT solutions.

Comment: One commenter recommended that, rather than compelling the states to maintain and make available the software documentation at § 433.112(b)(20), it makes more economic sense for CMS to be the custodian of this information. The commenter explained that states do not have the time, staff, or technical resources to undertake this critically important function. They assert that only CMS can enforce the regulations at § 95.617(b), not the states, and it can only do this effectively by creating a central repository under its immediate control.

Response: We agree that creating a repository for making software documentation available to other states is a project beyond the scope of state activities, however the requirement at § 433.112(b)(20) does not require creation and maintenance of the repository, but simply the maintenance of the documentation for the state's own software applications. We are considering the commenter's recommendation for a central repository and are exploring the concept. We will provide further subregulatory guidance on the states' maintenance of documentation and will engage stakeholders as we consider development of a centralized repository.

Comment: One commenter recommended CMS establish a control mechanism as the clearing house.

Response: We will take into consideration the recommendation to utilize a clearinghouse to aid in managing shareable components.

With regard to all Medicaid IT, we also sought comments on how to achieve an effective and efficient balance when approving enhanced FFP for the acquisition of open source and proprietary COTS software and information technology solutions provided in the Medicaid information technology marketplace. Section 1903(a)(3)(A) of the Act, which provides 90 percent FFP for the “design, development, or installation of such mechanized claims processing and information retrieval systems” could be interpreted to include use of COTS where that solution would be the more economical and efficient approach. We proposed this approach, acknowledging that it will necessitate a refinement of policy for proprietary COTS software for § 95.617(b) to protect intellectual property. We sought comment on the inclusion of some costs related to COTS software in DDI to further encourage the states to opt for the COTS and SaaS option, currently matched at 75 percent, rather than ground-up development approaches, which are duplicative and have a potentially much larger total cost over the span of the project. We intend to address this further in future subregulatory guidance. In considering approvals for ground-up system builds we may require states to evaluate whether cost-effective and practical open source and/or proprietary COTS solutions exist and whether those solutions are feasible.

We received the following comments on this approach.

Comment: Some commenters asked if we intend to provide enhanced FFP for customization to COTS solutions where it is necessary to meet the business needs of a Medicaid Program.

Response: We will pay enhanced FFP for limited modifications required for compliance with federal and state regulations and integration and configuration and will require that the result be made available for reuse. Costs not eligible for enhanced funding would be eligible for 50/50 administrative funding if they are allowable Medicaid costs.

Comment: One commenter asked us to clarify the difference between proprietary software and COTS software and to address the issue of ownership when customization is paid for with federal funds; and another requested clarity on when the federal government owns a license to a system for perpetual use after implementation.

Response: Software that was developed without federal funding is generally considered proprietary. This usually applies to COTS software. However, as articulated in existing § 95.617(b) the federal government retains ownership and a perpetual license for software developed with federal funding, which may include software code written to customize proprietary COTS software solutions. We are seeking to discourage the extra costs of unnecessary customization of COTS software solutions, therefore this final rule explicitly provides in § 433.112(c)(2) that development costs at the enhanced match rate may only include the minimum necessary to install the COTS software and ensure that other state systems coordinate with the COTS software solution. We intend to develop further guidance, in consultation with the industry and other stakeholders, regarding the proportion of customization that would result in a product no longer being considered COTS, and thus being subject to the provisions of § 95.617, as is other software developed with federal funds.

Comment: A commenter supported the proposed exemption to the restriction of FFP funding when it is more efficient and economical to purchase COTS software. It suggests use of an analysis template to compare modules, state collaborations, CMS guidance, and CMS pre-approved modules for E&E. The commenter also recommends that subregulatory guidance be issued to include the requirement of a budget for risk assessment. The commenter also suggests several recommendations for these strategies.

Response: These suggestions will be considered during the formulation of sub regulatory guidance.

Comment: Many commenters recognized that the alignment of Medicaid E&E systems with MMIS requirements and MITA is unclear. One commenter also thought the inclusion of E&E systems in the definition of MMIS presents some confusion.

Response: This rule includes E&E systems in the definition of mechanized claims processing and information retrieval systems, not as part of an MMIS. We recognize the commenters' concerns regarding alignment of E&E systems, MMIS and MITA. Existing federal guidance is provided in “Enhanced Funding Requirements: Seven Conditions and Standards: Medicaid IT Supplement,” (MITA-11-01-v1.0) dated April 2011, which is available at http://www.medicaid.gov/​medicaid-chip-program-information/​by-topics/​data-and-systems/​downloads/​efr-seven-conditions-and-standards.pdf.

We will provide additional clarification regarding the standards and conditions applicable to E&E in the subregulatory guidance.

Comment: One commenter expressed concern that MITA remains a loose architectural framework that, in its current state, does not provide sufficient definitions, constraints, or measures to support consistent modular development. Specifically, standardized baseline procedures and Organizational Change Management maturity are not in place; the lack of common SOA and data governance practice maturity and a lack of technical expertise prevent “plug-in” modules from being established and matured by states. We also received many detailed recommendations on how a collaborative workgroup could update MITA to provide sufficient structure for a modular approach and it was recommended that subregulatory guidance be jointly developed between CMS, the states, and the vendors for best-practice process baselines that align with the MITA Business Areas.

Response: We recognize the concern regarding potential challenges using MITA, and will address this in subregulatory guidance. We welcome the collaboration.

Comment: Several commenters also recommended that the MITA be updated, completed, and standardized to provide sufficient structure for a modular approach and that this be accomplished through a collaborative workgroup of states and vendors.

Response: We agree and will issue further communications regarding this on-going effort.

Comment: Several commenters requested a modular certification process that closely aligns with the MITA Business Process Model (BPM) and that subregulatory guidance should be developed, with state and industry collaboration, to develop common framework and terminology for defining a module of an MMIS. One commenter recommended that CMS use “MITA Business Process Model” instead of “module” when referring to portions of an entire MMIS.

Response: While we appreciate the intent of the suggested changes, we do not believe that this would improve the clarity of our rule, so we are not adopting that suggestion. We appreciate the recommendation for a certification closely aligned to MITA and will take it into consideration as we finalize the MMIS certification criteria. We are currently piloting use of MITA aligned business processes in a Phased MMIS Gate Review process.

Comment: One commenter expressed concern that open source software may create a security risk for protected health information (PHI).

Response: We believe that the use of open source software is not necessarily a risk to PHI. All HIPAA regulations apply, and PHI must be protected in any implementation as specified in this rule at § 433.112(b)(12).

Comment: One commenter supports the flexibility to solicit, but not the mandated use of, open source products where appropriate. Several possible issues are mentioned, such as quality of proposals or workable solutions, evaluation of proposals, etc.

Response: We appreciate this supportive comment and we believe that open source software is one possible solution but not necessarily the only solution. The states still have great discretion in making procurement choices. Our intent is that sharing and reuse be encouraged to avoid redundant custom development and to facilitate collaboration not typically enabled by non-open source software solutions.

Comment: Another commenter suggested that we ensure flexible and proper fiscal allocation to address enrollment fluctuations.

Response: Cost allocation plans are flexible and states may propose a number of methodologies, including population based methodologies, for consideration and approval by CMS and other federal partners. Cost allocation plans may be updated as needed according to HHS cost allocation regulations at 45 CFR part 75, subpart E—Cost Principles.

Comment: One commenter expressed a concern that CMS allows only one point of connection to the FDSH per state and the importance of recognizing that there may be multiple connections along the path to the FDSH that establish such interoperability. The commenter suggested that a state may satisfy the interoperability with Marketplace requirement if either component—the eligibility or the enrollment system—coordinates with the Marketplace.

Response: We appreciate the comment; however we disagree with the recommendation to determine eligibility in separate components as it creates duplicative processes, and as such, the recommendation will not be incorporated into the final rule.

Comment: There were several comments related to the reusability of existing or shared components. These involved technical definitions, real-time interfaces, number of application program interfaces (APIs), amount of data, stability, security and authentication, specialty vendors, batch data exchanges, business rules, absence of single sign on, and absence of real-time interfaces to MMIS.

Response: We consider these technical recommendations to be outside the scope of this regulation since the technical specifications for shared modules are to be found in MITA 3.0 and IT Standards and Guidance 2.0.

Currently, regulations at § 95.617(b) provide that the federal government shall have a royalty-free, nonexclusive and irrevocable license to reproduce, publish or otherwise use and to authorize others to use for federal government purposes, software, modifications and documentation that are developed with federal support. We also sought comments on requiring that states affirmatively document and make available such software to ensure that it may be used by others.

Consistent with these requirements, and to encourage broader use and reuse of federally funded software, we also proposed at § 433.112(b)(20) and (21) that software developed with the 90 percent federal match be adequately documented so that it can be operated by contractors and other users, and that states consider strategies to minimize the costs and difficulty of operating the software using alternate hardware or operating systems.

We received the following comments on proposed § 433.112(b)(20) and (21).

Comment: One commenter requested that open source software be documented according to the Open Source Institute standard.

Response: We appreciate and will consider this recommendation in the formulation of subregulatory guidance.

Comment: A commenter stated that that CMS should be the entity that takes recommendations from the industry in order to establish IT standards relevant to Medicaid systems, and that the standards should be housed and maintained in a publicly accessible repository.

Response: We appreciate the suggestion and will explore how we can engage with existing standards bodies and stakeholders to support the development and adoption of IT standards relevant to Medicaid business processes. We will also consider options for a publicly accessible repository.

Comment: One commenter commends CMS for the proposed requirement regarding documentation detail.

Response: We acknowledge this support.

Comment: A commenter recommended we explore innovative ways to create a multi-state “vendor and state” repository as well as a structured pilot process that formalizes and publicizes processes, lessons learned, and how those lessons change future processes.

Response: We concur with the commenter's recommendation and have implemented many aspects in the roll-out of the Affordable Care Act to include establishing the Collaborative Application Lifecycle Tool (CALT) as a first step in creating a multi-state “vendor and state” repository. We will take into consideration the commenter's recommendation on a structured pilot process, building learning communities, creating a technical assistance portal, and expanding the most effective approaches to reuse.

Comment: A commenter asked that CMS clarify what it means for software to be “documented.” They make the point that software that can be legitimately run by contractors and other users will have different documentation needs from software that is proprietary or is being maintained as a shared service and will not be transferred to another entity.

Response: The intent was for software that was custom developed to be sufficiently documented such that another vendor or state staff could operate it. It is not meant to refer to proprietary COTS software, which would necessarily already include through the licensing agreement provisions for support of operations. Nor is it meant to apply to SaaS or Business-Solutions-as-a-Service, which operate under totally different parameters from states' custom-developed solutions.

Comment: A commenter anticipated an increase in costs for developed software to create the documentation supporting transfer to another state and to design the solution to operate on alternate hardware and operating systems. They asked whether we intend to designate the hardware and operating system manufacturers that must be supported. The commenter makes the point that the challenges for designing solutions to operate on alternate hardware and operating systems includes having the necessary knowledge of the alternate hardware, software components, and operating systems and having the alternate environments available for testing. The same commenter also asked if we intend to provide more specific guidance on how states are to gauge when the software and related technical architecture is adequately documented so that it can be operated by contractors and other users.

Response: We agree that these are good points and that they call for further discussion. We do not intend to designate specific hardware and operating systems that must be supported because we do not wish to limit the provision. We will provide more specifics in subregulatory guidance so that states can assess whether or not this requirement is met.

Comment: In reaction to the CMS proposal that software custom developed with the 90 percent federal match be adequately documented so that it can be operated by contractors and that states consider strategies to minimize the costs of operating the software using alternate hardware or operating systems, several commenters provided feedback. Concerns have been expressed that this appears to burden states with conducting a cost benefit analysis for software applicability across multiple hardware or operating systems. Another concern was that adequate documentation should not be subject to trademark, or patent to promote reuse.

Response: We agree that this software should be adequately documented and that states should use strategies to minimize costs.

Comment: One commenter requested clarification on CMS documentation standards so MMIS modules can be used by other contractors and states.

Response: We appreciate this comment and will address in future subregulatory guidance.

Comment: One commenter recommended CMS should provide the opportunity to establish a repository of reusable business rules and regularly updated references to standards that are necessary to support interoperability as it could also store best-practice materials on performance measurement and management, such as service level agreements, dashboard formats, and other performance tracking and reporting capabilities.

Response: We concur with the commenter's recommendation and have established the CALT, as a repository environment of reusable business rules and regularly updated references to standards that are necessary to support interoperability.

Comment: One commenter recommended that CMS clearly define and standardize its communication methodology and tools to ensure states and vendors work together, as historically CMS has had a practice of only communicating directly with states regarding system changes. Also, the commenter recommended that CMS develop a repository for states and vendors to share documents, to host learning communities, and to serve as a channel of regular communication about changes.

Response: We concur with the commenter's recommendation and have established the CALT, a repository environment to create a multi-state “vendor and state” repository. We will take into consideration the recommendation to adopt a model similar to the Office of the National Coordinator for Health IT (ONC) collaborative leadership with agencies, providers, and vendors.

Comment: One commenter suggested that CMS allow free sharing of assets, such as documentation and code, without Memorandum of Understanding (MOUs).

Response: We encourage states to collaborate to the extent possible but as we do not require MOUs, it is outside of the scope of this final rule to address how states' sharing should be governed.

Comment: With respect to sharing and reuse a commenter recommends that the market for sharing and reusing software will need to be established between CMS and states so that states are more likely to openly participate.

Response: These recommendations will be considered. We recognize the need for a repository to make software available to states for re-use. We are exploring the best means to achieve that end.

We conduct periodic reviews of the states' MMIS and E&E system functionality and operations. Current regulations at § 433.120 allow for reduction of FFP for system operations from 75 percent to 50 percent if the system fails to meet any or all of the standards and conditions. We proposed to allow for the FFP reduction to be tailored where appropriate to specific operational expenditures related to the subpar system component rather than only being able to apply it across all operational expenditures. We also proposed to revise current regulations that require the disallowance to be for a minimum of four quarters so that there is no defined timeframe. Furthermore, we proposed to remove the restriction on the FFP reduction occurring at least four quarters after the system was initially approved.

We received the following comments in reference to the proposals concerning FFP.

Comment: Several commenters expressed their support for changes at § 433.120 and expressed concerns about how this change to current regulation will be implemented. One commenter asked which expenditures for system operations could be reduced and whether CMS will be providing a list for the states. There were questions regarding application of the policy to legacy systems and the necessity for a grace period prior to applying the policy to legacy systems was mentioned. Two commenters asked about timeframes for determining non-compliance and how corrective action plans might be used as a mechanism to ensure compliance prior to reduction of FFP. One commenter asked whether we would be providing a predefined list of expenditures; or in the alternative, will a case by case analysis be applied to determine which expenditures could be exposed to a decrease in FFP due to noncompliance. A commenter expressed that E&E system builds have been a priority under the Affordable Care Act and have required a considerable amount of state resources. Due to a lack of resources some states have experienced a lag in their modernization efforts for MMIS systems which could lead to noncompliance, a reduction in FFP, and an increase in state's share of MMIS operational costs. One commenter asked for reassurances that we would not order a reduction in funds without first providing the state with an opportunity to provide feedback on the disallowance.

Response: We conduct periodic reviews of the states' MMIS and E&E system functionality and operations. Current regulations at § 433.120 allow for reduction of FFP for systems that are found to be noncompliant; and, we will consider the suggestions, recommendations, and clarification requests as content for subregulatory guidance. We will provide a series of artifacts, supporting tools, documentation, and diagrams to the states as part of our on-going technical assistance, monitoring, and governance of MMIS systems design and development. The goal is to assist states in being successful and would only deploy this approach after a meaningful escalation process after which it was determined that there was persistent non-compliance that lacked an approvable workaround and/or plans for timely remediation.

Comment: Two commenters provided alternative language to modify the rule at § 433.120. Commenters asked that we state that only expenditures that relate to the failure to meet the conditions of re-approval for system operations could be reduced. Another commenter asked us to add language stating that system components receiving a reduction in FFP may include MMIS modules or other discrete components of the MMIS system.

Response: We agree that the reductions may be applicable only to certain modules or a single module. We believe that the reference to “non-compliant functionality or system components” adequately captures the meaning of the suggested language, therefore, we are finalizing the language as proposed. We will, however, discuss these issues in greater depth in subregulatory guidance.

Comment: Two commenters asked that we retain the language that restricts FFP reduction during the first four quarters following initial approval because states should not be subject to reductions in FFP for intermittent periods of subpar performance of system components during the initial periods of operation of newly installed system components; and, projects that require remediation should not be jeopardized.

Response: We agree with the commenter and it is not our intention to adopt this approach for circumstances as described above. We are committed to working with states and understand the realities of system launches. We are finalizing the language as proposed.

Comment: For §§ 433.112 and 433.120 regarding the proposal to reduce FFP for system non-compliance, many commenters proposed changes to the wording, made recommendations to change the proposed penalties or process, or requested clarification of the proposed process.

Response: We considered the proposals, recommendations, and clarification requests. As described in the proposed rule, we will provide a series of artifacts, supporting tools, documentation, and diagrams to the states as part of our on-going technical assistance, monitoring, and governance of MMIS systems design and development. We will continue to work with states that show a good faith effort to comply with certification requirements, and as described in the proposed rule, we will continue to work with the states as systems are designed and developed so that issues and solutions are identified and addressed prior to the certification stage. We described in the proposed rule that there is an established notice and state appeals rights in existing regulations. Those rights regulations are not changing with these final regulations.

Comment: A state asks CMS to clarify whether the proposed increase in reduction includes only the number of quarters or also the increase in reduction of percentage of FFP. One commenter is concerned that this rule ultimately may increase states' share of MMIS operational costs, noting that the Affordable Care Act required states to implement a significant number of changes to E&E systems, resulting in state investment of vast resources on a short timeline to ensure compliance under the Affordable Care Act. For states, this may have resulted in a lag in MMIS modernization efforts. Therefore, applying the proposed rule equally to both E&E systems and MMIS systems may inherently increase states' share of MMIS operational costs.

Response: This rule provides that the reduction in FFP was for a certain number of quarters that could be fewer than 4, and that the operations costs could be reduced from 75 percent to 50 percent. We are aware of the multiple requirements that states must implement, and will engage in dialogue with states regarding resources and priorities before imposing a reduction in FFP.

Comment: A commenter requested clarity on the process to correct a reduction in FFP related to a non-compliant system component, and whether this provision applies to legacy systems, and if so, requests a grace period for implementing necessary changes.

Response: We will provide a description of how states can address system non-compliance through subregulatory guidance. With this final rule, we are not proposing a new requirement for systems to be in compliance, therefore a grace period is not appropriate.

Comment: A state requests a specific timeframe for determining non-compliance and whether a state can submit a corrective action plan before having FFP reduced.

Response: We will provide clarification of the process to resolve system non-compliance in subregulatory guidance, and this will address corrective action plans.

Comment: A commenter recommended that CMS reconsider its proposal to remove the restriction on reducing FFP during the first four quarters of the maintenance and support period where a system does not meet requirements, and expressed concern that the rule could jeopardize projects that require remediation during this period. Another commenter expressed concern that this rule will allow CMS to order a reduction of funds without providing the affected state an opportunity to review and provide feedback on the disallowance. That state asks CMS to explicitly provide a federal mechanism for reviewing E&E systems for disallowance before reducing FFP.

Response: We proposed the revisions to the regulations to allow flexibility in deciding if, when, and to what extent amounts might be denied for system non-compliance. When significant non-compliance is identified, we will seek appropriate relative penalties and only after discussion, corrective action plans and good faith efforts have been unsuccessful. We have an established escalation process that allows for state notification and appeal rights during which the state can provide mitigating information prior to disallowance.

Comment: A commenter asked for clarification about what “operating continuously” means in the context of when CMS would conduct MMIS certifications.

Response: The full requirement is that the system be operated continuously “during the period for which FFP is requested.” Although this question does not relate to this rule, the requirement means that the state must operate its system without interruption in a manner that meets the system certification requirements. Temporary interruptions that are consistent with normal operations (such as when necessary for updates or maintenance) would not affect compliance with this requirement.

We also received the following general comments.

Comment: Many commenters expressed support for matching COTS products at the 90 percent FFP.

Response: We appreciate the support for this rule that allows COTS products to be matched at 90 percent FFP, and we believe this will encourage reuse and development of new products that can be shared.

Comment: Many commenters expressed support for modularity, as it will encourage states to pursue smaller and more modular procurements and reduce the risk of large IT implementation projects. They also support our direction to encourage modularity, reusability and the flexibility to try new approaches.

Response: We appreciate this positive feedback and will continue to support this approach in future subregulatory guidance and in our work with states and vendors engaged in modular builds.

Comment: Some commenters expressed concurrence with the need for meaningful interoperability standards and concern that seamless coordination will not be truly achieved until these standards are in place. One commenter expressed support of adopting standards for Medicaid Health Information Enterprises that are eligible for enhanced FFP. Another commenter recommended that CMS specify the review criteria for how the interoperability requirement is to be satisfied.

Response: We concur with the commenter in support of meaningful interoperability standards. We welcome a dialogue with vendors and states on this topic.

Comment: One comment expressed the need for states to use industry standards to help ensure success of modular solutions. A commenter recommends that modular development for MMIS facilitate a phased approach to procurement/implementation and that the risks can be mitigated by the use of a systems integrator to manage the timing and approach to integration and to facilitate interoperability.

Response: We concur.

Comment: A commenter expressed concern that some of the requirements included in § 433.112(b) may not be applicable in an Administrative Services Organization (ASO) model. The commenter offered several recommendations to address this. The commenter also offered recommendations for improved wording to accommodate the ASO model.

Response: We concur with the commenter's recommendation to include revisions in the final rule to include the ASO model, and have included this change at § 433.111(b)(2)(ii). The ASO model is already supported under current regulations, but this final rule is modified to specifically address ASOs.

Comment: One commenter expressed that funding for E&E systems should not be approved unless and until the states seeking such funding can demonstrate a clearly articulated roadmap for integrated eligibility and contract bidders should be required to describe how their solution is able to assist states and CMS in reaching the goal of integrated eligibility. The commenter also recommended that CMS work with states and the broader IT community to allow for more standardization across the program.

Response: We agree with the commenter's concern around integrated eligibility roadmap; however, it is better addressed via subregulatory guidance. We welcome a dialogue with vendors and states regarding an effective approach to standardization across the program as we develop that guidance.

Comment: A commenter noted that we should consider enhanced FFP for Organizational Change Management and related activities.

Response: We appreciate the comment; however Organizational Change Management is out of the scope of this final rule.

Comment: One commenter suggested those counties that provide direct services to Medicaid beneficiaries should be allowed to apply directly for FFP for enhancements to E&E systems.

Response: We acknowledge the suggestion; however FFP is only available to the single state agency that has oversight for implementation of the Medicaid program.

Comment: A commenter expressed concern that by requiring systems to use industry standards adopted by ONC, in addition to those standards already specified for Medicaid MMIS and E&E systems, this increases the standards applied to State systems and the States' responsibility in monitoring and adapting to these additional standards. The commenter requests that CMS take a leadership role to assure that states have appropriate notice and response time to give input on ONC proposed industry standards. One commenter asked whether CMS, as the certifying agency, will represent the State Medicaid Agencies on standards proposed by ONC.

Response: We acknowledge the state's concern with regard to industry standards. We will consider ways to improve communication of states' concerns for new standards from ONC. While we do not believe it is our role to represent states in national standards development processes, we do believe it is our role to support all partners, including states, in considering appropriate standards for widespread adoption.

Comment: CMS was urged to develop and test innovative models that are modular and to prioritize critical requirements and functionality that will deliver features for customers.

Response: We agree with this suggestion and will discuss further with states and stakeholders, however it is not necessary to address it in the final regulation.

Comment: Some commenters expressed concurrence that state Medicaid systems must support seamless operational coordination and integration not only with the marketplaces, but also with community organizations providing outreach and enrollment assistance services. One commenter recommended a prioritized list of “modifications to further improve interaction and alignment between state Medicaid agencies and the Exchange program”. Additionally, this commenter placed importance on aligning and streamlining eligibility policies and encouraged CMS work with states and vendors to explore a variety of communications.

Response: We concur with the supportive comments and reviewed the prioritized list of “modifications to further improve interaction and alignment between state Medicaid agencies and the Exchange program”. We welcome a dialogue with vendors and states regarding aligning and streamlining eligibility policies.

Comment: A commenter recommended adding a definition for “seamless coordination and integration”. One commenter inquired if the definition in the context of proposed rule will include the coordination and integration with the Marketplace, the FDSH, as well as interoperability with health information exchanges, public health agencies, human services programs and community organizations providing outreach and enrollment assistance as applicable.

Response: We welcome a dialogue with vendors and states regarding the definition for “seamless coordination and integration” and will reflect outcomes in subregulatory guidance, as described above.

Comment: One commenter suggested CMS adopt similar strategy as the Innovation Center's strategy to develop and test innovation models.

Response: We appreciate the comment to adopt a similar strategy as the Innovation Center's strategy to develop and test innovation models. Although, this comment is out of the scope of this final rule, we believe this idea is valuable and we will take this strategy under consideration.

Comment: Several commenters expressed concern that the growth in the number of beneficiaries, as well as the increased need to communicate personal information between parties, will inevitably lead to increased misuse of beneficiary identities, for health care purposes as well as non-healthcare purposes. Further, they expressed that the use of the Social Security number as the primary identifier among stakeholders such as hospitals, medical practices, and Managed Medicaid beneficiaries will continue to be used as identification.

Response: We have received several comments about improving privacy and security processes to reduce Medicaid fraud and prevent identity theft of Medicaid beneficiaries. We appreciate the commenter's recommendation of implementing a HealthCare ID; however, this recommendation is outside of the scope of this final rule. If we decide to implement a HealthCare ID, we will address this in subregulatory guidance.

Comment: A few commenters suggested that states should consider modifying their single streamlined application to include questions to determine an individual's MSP eligibility. One commenter recommended enhancements to state E&E systems regarding MSP determinations and renewals, including the ability to apply online, automatic eligibility determinations, enhancing notices, and minimizing human error to avoid incorrect determinations of eligibility at renewal. Another commenter urged CMS to identify more straight forward paths to using MAGI methodology to simplify the ABD application process

Response: We consider these comments to be outside of the scope of this rule, however, we will take these comments into consideration.

Comment: One commenter requested CMS clarification regarding the waiver requirements for § 435.949 connecting to the FDSH for verification.

Response: Although this is outside of the scope of this rule, we will take this into consideration.

Comments: One comment requested that enhancements that are interfaces to existing state E&E systems and other data systems should be prioritized for FFP, as these enhancements have the flexibility to span multiple data sets to improve direct service delivery.

Response: We appreciate this suggestion; however, we consider this comment to be outside the scope of the proposed rule, and therefore, will not address it in this final rule.

Comment: A commenter recommended that those states who are still using paper fax machines switch over to an electronic fax system.

Response: We appreciate the comment; however, it is outside the scope of the proposed rule, and therefore, is not addressed in this final rule.

B. Technical Changes to 42 CFR Part 433, Subpart C—Mechanized Claims Processing and Information Retrieval Systems

We solicited comments concerning the following proposed technical changes:

• § 433.110(a)(1) referred to “45 CFR part 74”. Our proposed rule replaced this citation with, “45 CFR part 92”. This final rule corrects § 433.110(a)(1) to refer to “45 CFR part 75”.
• Due to a drafting error in the April 19, 2011 rule, § 433.110(a)(2) is followed by paragraphs (ii) and (iii) which are unrelated to (a)(2). The intent of the 2011 rule was to remove these paragraphs along with the requirement for a triennial review of an MMIS. In this final rule paragraphs (ii) and (iii) are removed from § 433.110(a)(2).
• § 433.110 is amended to remove paragraph (b) because the statutory waiver authority upon which this provision was based was deleted in the Balanced Budget Act of 1997, Public Law 105-33, sec. 4753.
• § 433.116(c) referenced the conditions (1) through (16) under § 433.112(b). Since new conditions have been added to § 433.112(b) we updated § 433.116(c) to reference the conditions (1) through (22) under § 433.112(b).
• § 433.119 required compliance with § 433.112(b)(1), (3), (4), and (7) through (16). This final rule reflects the newly added conditions at § 433.112(b)(1) through (22).

We received no comments on these technical corrections to part 433 and are finalizing these as proposed.

C. Changes to 45 CFR Part 95—General Administration—Grant Programs, Subpart F

In the final rule titled “State Systems Advance Planning Document (APD) Process”, (75 FR 66319, October 28, 2010), § 95.611 was modified to include an acquisition threshold for prior approval of the state costs at the regular matching rate but noted that equipment or services at the enhanced matching rate necessitated prior approval regardless of the cost. We proposed to amend § 95.611 to align all Medicaid IT requirements with existing policy for MMIS regarding prior approvals, such that what is currently acceptable for regular match would be acceptable for enhanced match as well. We proposed that if there is already an approved APD, prior approval will be required in order for the state to release acquisition solicitation documents or execute contracts when the contract is anticipated to or will exceed $500,000. For all Medicaid IT acquisition documents, an exemption from prior federal approval shall be assumed in the approval of an APD provided that: The acquisition summary provides sufficient detail to base an exemption request; the acquisition does not deviate from the terms of the exemption; and, the acquisition is not the initial acquisition for a high risk activity, such as software application development. All acquisitions must comply with the federal provisions contained in § 95.610(c)(1)(viii) and (c)(2)(vi) or submit an Acquisition Checklist for prior approval.

For noncompetitive acquisitions, including contract amendments, when the resulting contract is anticipated to exceed $1,000,000, the state will be required to submit a sole source justification in addition to the acquisition document. The sole source justification can be provided as part of the APD.

If the state does not opt for an exemption or submittal of an Acquisition Checklist for the contract, prior to the execution, the state will be required to submit the contract when it is anticipated to exceed the following thresholds, unless specifically exempted by CMS: Software application development—$6,000,000 or more (competitive) and $1,000,000 or more (noncompetitive); Hardware and COTS software—$20,000,000 or more (competitive) and $1,000,000 or more (noncompetitive); Operations and Software Maintenance acquisitions combined with hardware, COTS or software application development—the thresholds stated in § 95.611(b)(1)(v)(A) and (B) apply.

For contract amendments within the scope of the base contract, unless specifically exempted by the Department, prior to execution of the contract amendment involving contract cost increases which cumulatively exceed 20 percent of the base contract cost.

The following is a summary of the comments we received regarding the proposed changes to part 95.

Comment: We received several comments commending CMS for aligning the acquisition thresholds for E&E systems to that of the MMIS. One commenter conveyed their commitment to work with our Federal partners in ACF and the USDA, Food and Nutrition Services who oversee the Supplemental Nutrition Assistance Program (SNAP) to clarify the acquisition costs and thresholds for all benefiting programs in support of an integrated E&E system.

Response: We concur with the supportive comments and we are pleased with the expressed commitment to work with our federal partners.

Comment: A commenter asked, regarding prior approval requirements, if the $500,000 threshold is for a specific piece of work that is part of a larger project, or if the threshold applies when the $500,000 is met in the aggregate.

Response: The $500,000 threshold is for a specific procurement, or contract action and is not an aggregate.

Comment: A commenter asked CMS to confirm that the prior federal approval exemption can be applied to projects under enhanced funding and for clarity on the requirement to provide “sufficient detail to base an exemption request” in the APD acquisition summary. The commenter also requested clarification on whether or not contract amendments based on an approved initial acquisition contract can qualify for the prior federal approval exemption.

Response: We believe that existing regulation at § 95.610 already provides sufficient detail stating that for all Medicaid IT acquisition documents, an exemption from prior federal approval, including enhanced funding, shall be assumed in the approval of an APD provided that the acquisition summary provides sufficient detail to base an exemption request; the acquisition does not deviate from the terms of the exemption; and, the acquisition is not the initial acquisition for a high risk activity, such as software application development. All acquisitions must comply with the federal provisions contained in § 95.610(c)(1)(viii) and (c)(2)(vi) or submit an Acquisition Checklist for prior approval.

In addition, we proposed to amend § 95.611(a)(2) by removing the reference to 45 CFR 1355.52. This paragraph provides prior approval requirements when states plan to acquire ADP equipment or services with FFP at an enhanced matching rate for the Title IV-D, IV-E, and XIX programs, regardless of acquisition costs. We proposed to delete the reference to the Title IV-E regulation, 45 CFR 1355.52 because enhanced funding for information systems supporting the Title IV-E program expired in 1997.

We received no comments in response to our technical amendment to § 95.611 and will finalize as proposed.

IV. Provisions of the Final Regulations

For the most part, this final rule incorporates the provisions of the proposed rule. Those provisions of this final rule that differ from the proposed rule are as follows:

• In § 433.110 of the proposed rule, we inadvertently proposed to remove and reserve paragraph (b). Therefore, in this final rule, we are not finalizing this change.
• In § 433.111(b), we expanded the definition of mechanized claims processing and information retrieval system to include language consistent with the concept of modularity and to elaborate on the functionalities included in such systems. We included in the revised definition a concept of “System of systems”, to emphasize that such a system may consist of multiple, interoperable subsystems, or modules to support MMIS and E&E. Note that in this final rule the words “subsystem” and “module” have the same meaning.
• In § 433.111(b), we deleted “non-proprietary” to remove this limitation from the description of Mechanized Claims Processing and Information Retrieval System modules.
• In § 433.111(b)(1)(i) through (iii), we substituted the word “module(s)” for “subsystem(s)” to be consistent with our modular approach.
• In § 433.111(b)(2)(i), we added clarifying language to indicate that E&E systems are used to determine eligibility for enrollment.
• In § 433.111(b)(2)(ii), we added language to clarify that MMIS are used to perform other management and administrative functions, to reference the MMIS Certification Toolkit, and to clarify that this is applicable in fee for service, managed care and ASO environments.
• In § 433.111(f), we added a definition of “Service.”
• In § 433.111(g), we slightly altered the definition of “shared service” to clarify that such services are available to other entities, including states, for use, and may include SaaS.
• In § 433.111(h), we replaced “MMIS Module” with the term “module” to broaden the meaning to apply to either MMIS or E&E.
• In § 433.111(i), we deleted the sentence that excluded software developed for public assistance programs from the definition of COTS software, to permit their inclusion, if appropriate.
• In § 433.111(j), we have added a definition of SaaS.
• In § 433.112(b)(19), we added that key state personnel must be identified by name.
• In § 433.112(b)(20), we struck “MMIS” to make the condition more broadly applicable to both MMIS and E&E.
• In § 433.112(b)(21), we struck “MMIS” to make the condition more broadly applicable to both MMIS and E&E.
• In § 433.116(j), we modified this paragraph to remove the compliance date of December 31, 2015.

V. Collection of Information Requirements

While this rule sets out information collection requirements, the rule does not contain any new or revised reporting, recordkeeping, or third-party disclosure requirements. Consequently, the provisions of the Paperwork Reduction Act of 1995 (44 U.S.C. chapter 35) and its implementing regulations (5 CFR part 1320) do not apply.

VI. Regulatory Impact Analysis

A. Statement of Need

Experience with the Affordable Care Act implementation has shown that Medicaid eligibility policies and business processes benefit from continued updating and strengthening. System transformations are needed to apply new rules to adjudicate eligibility for the program; enroll millions of newly eligible individuals through multiple channels; renew eligibility for existing enrollees; operate seamlessly with the Health Insurance Marketplaces (“Marketplaces”); participate in a system to verify information from applicants electronically; incorporate a streamlined application used to apply for multiple sources of coverage and financial assistance; and produce notices and communications to applicants and beneficiaries concerning the process, outcomes, and their rights to dispute or appeal.

We wish to ensure that our technology investments result in a high degree of interaction and interoperability to maximize value and minimize burden and costs on providers and beneficiaries. Thus, we are committed to providing ongoing 90 percent FFP for DDI or 75 percent FFP for M&Os of such systems. We have provided that states must commit to a set of standards and conditions to receive the enhanced FFP. This enhanced FFP reduces the financial burden on states to 10 percent of the costs compared to the 50 percent financial burden currently in place and ensures that states continue to utilize current technology development and deployment practices and produce reliable business outputs and outcomes.

B. Overall Impact

We have examined the impacts of this rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism (August 4, 1999) and the Congressional Review Act (5 U.S.C. 804(2).

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) Having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local or tribal governments or communities (also referred to as “economically significant”); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive Order.

A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We estimate that this rulemaking is “economically significant” as measured by the $100 million threshold, and hence also a major rule under the Congressional Review Act. Accordingly, we have prepared a Regulatory Impact Analysis that to the best of our ability presents the costs and benefits of the rulemaking.

C. Anticipated Effects

1. While it is difficult to predict state behavior, we believe all states will comply with the standards and conditions in this regulation to receive the 90 percent FFP, and have assumed that for the purpose of these estimates.

To meet the requirements of the Affordable Care Act, states, the District of Columbia and the U.S. Territories must build new E&E systems or modernize existing E&E systems. Most states have added new functionalities to interface with the Marketplaces and implemented new adaptability standards and conditions (such as incorporation of mandated eligibility categories).

There are currently 9 states that have relatively new E&E systems and do not need replacement of whole systems, but are instead making modular improvements and upgrades. We assumed that the cost per state for the 9 states improving rather than replacing systems would be $3.8 million on average, for a total of $34 million FFP. For these 9 states, we believe upgrades would occur even in the absence of this rule, during the initial 5 years of enhanced funding. We believe that most states have not had sufficient time to complete the total system replacement for both MAGI and non-MAGI eligibility functionality, as we believe that new system builds will take 4-6 years. We assume that an additional 19 states will retire their legacy E&E systems with ongoing 90 percent FFP for design and development within 2-3 years. We estimated that the average cost savings for each state will be $16.6 million per year. We expect all 19 states to eliminate their legacy E&E systems by 2019; therefore, the total cost savings by 2019 for those 19 states will be about $368 million. Based on previous spending trends, we assumed that those 9 states with new systems account for 15 percent of E&E spending and the 28 states that we anticipate retiring their legacy E&E systems by 2025 account for 55 percent of E&E spending. We believe that by eliminating 28 legacy systems, we reduce M&O costs by maintaining only one E&E system per state. Eventually, we assume that all states will replace their current E&E legacy system(s) using ongoing 90 percent FFP. We expect almost all states to eliminate their legacy E&E systems by 2025, adding about $3 billion in cost savings. To calculate the impact of the regulation, we assumed that new E&E systems on average would cost $50 million over 3 years for each state ($15 million federal costs at 90 percent FFP per year).

States will see a decrease in their net state share due to the enhanced federal match for eligibility systems and states will also realize benefits by putting in place the set of standards and conditions articulated in this final regulation.

The state net costs from FY 2016 through 2025 for implementing the regulation on eligibility systems is approximately −$1.1 billion. This includes approximately $572 million in state costs for system design and development, offset by lower anticipated M&Os costs. These costs represent only the state share.

Table 1—State Net Costs by Fiscal Year

[In millions]

	2016	2017	2018	2019	2020	2021	2022	2023	2024	2025	2016-2025
E&E Systems—DDI	199	244	37	31	20	16	10	5	5	5	572
E&E Systems—M&O	(19)	(19)	(95)	(120)	(165)	(213)	(240)	(263)	(280)	(286)	(1,700)
Total	180	225	(58)	(89)	(145)	(197)	(230)	(258)	(275)	(281)	(1,128)
* Numbers in parentheses represent savings to State Governments.

Similar to the federal budget impact, we expect to see higher savings achieved by states over the 10-year budget window due to the increased savings by moving away from operating two or more systems, and replacing legacy systems.

The RFA requires agencies to analyze options for regulatory relief of small entities, if a rule has a significant impact on a substantial number of small entities.

Since this rule would primarily affect states, which are not considered small entities, the Secretary has determined that this final rule will not be likely to have a significant economic impact on a substantial number of small entities. Therefore, we have not prepared a regulatory flexibility analysis.

In addition, section 1102(b) of the Act requires us to prepare a regulatory impact analysis if a rule may have a significant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 604 of the RFA. For purposes of section 1102(b) of the Act, we define a small rural hospital as a hospital that is located outside of a metropolitan statistical area and has fewer than 100 beds. This rule will not have a significant impact on hospitals. Therefore, the Secretary has determined that this final rule will not have a significant impact on the operations of a substantial number of small rural hospitals.

Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2015, that is approximately $144 million. This rule does not mandate expenditures by the state governments, local governments, tribal governments, or the private sector. This rule provides that states can receive enhanced FFP if states ensure that the mechanized claims processing and information retrieval systems, including those that perform eligibility determination and enrollment activities, as well as the Medicaid portion of integrated eligibility determination systems, meet with certain conditions including migrating to the MITA framework and meeting certain performance requirements. This is a voluntary activity and the rule imposes no substantial mandates on states.

2. The federal net costs from FY 2016 through 2025 of implementing the regulation on eligibility systems is approximately $3 billion. This includes approximately $5.1 billion in increased federal costs for system design and development, offset by lower anticipated M&Os costs. These costs represent only the federal share. Uncertainty exists because we are unsure of the rate of adoption for states to make the changes in this final rule.

Table 2—Federal Net Costs By Fiscal Year

[In millions]

	2016	2017	2018	2019	2020	2021	2022	2023	2024	2025	2016-2025
E&E Systems—DDI	1,788	2,192	333	277	184	143	89	47	44	44	5,141
E&E Systems—M&O	(19)	(19)	(95)	(120)	(165)	(298)	(325)	(344)	(360)	(367)	(2,112)
Total	1,769	2,173	238	157	19	(155)	(236)	(298)	(315)	(323)	3,029
* Numbers in parentheses represent savings to the Federal Government.

We considered a number of ways in which application of the standards and conditions, including increased use of MITA, could result in savings; however, as no states have yet reached MITA maturity, it is difficult to predict the savings that may accrue over any certain timeframe. These areas include the following:

• Modular technology solutions: As states, or groups of states, would begin to develop “modular” technology solutions, these solutions could be used by others through a “plug and play” approach, in which pieces of a new MMIS would not need to be reinvented from scratch every time, but rather, could be incorporated into the MMIS framework.

We assume that savings associated with reusable technology could be achieved in both the development and operation of new systems.

• Increased use of industry standards and open source technologies: While HIPAA administrative transaction standards have existed for 8 to 10 years, use of more specific industry standards to build new systems would allow such systems to exchange information seamlessly. We also believe that more open source technology would encourage the development of software solutions that address the needs of a variety of diverse activities—such as eligibility, member enrollment, and pharmacy analysis of drug claims. Software that is sufficiently flexible to meet different needs and perform different functions could result in cost savings, as states are able to use the systems without making major adaptations to them.
• Maintenance and operations: As states continue to implement changes, the M&O costs of new systems should decrease. Less maintenance should be required than that necessary to reengineer special, highly customized systems every time there is a new regulatory or legal requirement.
• Reengineering business processes, more web based solutions, service-oriented architecture (SOA): Savings are likely to result from the modular design and operation of systems, combined with use of standardized business processes, as states are being compelled to rethink and streamline processes as a result of greater reliance on technology.

There are uncertainties regarding our assumptions, including state behavior, and the associated cost estimates for states implementing new systems. However, we have based our assumptions on data on states' previous behavior, spending and APDs over the last 4 years. It is important to point out that we believe that systems transformation is necessary to meet the vision of the Affordable Care Act and consequently, these costs provide for efficient systems that in the end would provide for more efficient and effective administration of the state plan.

D. Alternatives Considered

We considered as an alternative to our rule to not continue to provide enhanced match for state eligibility systems builds after December 2015, and to not update federal standards and conditions for Medicaid IT development. We also considered an extension for a 2 or 3 year timeline but deduced that it was both insufficient for states to effectively transition out of their legacy systems and to complete human services integration in the new shared eligibility system. Furthermore, this assumes that all significant policy changes that trigger the need for IT updates were limited to those in the Affordable Care Act, however systems reforms are an on-going facet of eligibility policy with an accompanying ongoing financial burden. A limited extension would also ignore that states that already modernized and did not replace their systems starting in 2011 will eventually need to do so to maintain system integrity and modernity sometime after a 2 or 3-year extension. Absent an ongoing extension, states would receive the traditional 50 percent FFP for reasonable administrative expenditures for designing, developing, installing, or enhancing Medicaid eligibility determination systems. Similarly, states would receive 50 percent FFP for expenditures associated with the M&O of such systems. However, states would have to continue to meet the requirements of federal legislation. Since the Affordable Care Act significantly alters Medicaid eligibility, we believe that treating E&E systems as an integral part of mechanized claims processing system and information retrieval systems is consistent with the federal statute. This would have the effect of continuing the higher federal matching rate, which would provide states additional resources to meet this challenge. In addition, the federal guidance in the form of clearer federal standards and conditions would facilitate the design, development, implementation, and operation of IT and systems projects that fully support the Medicaid program, including the new responsibilities under the Affordable Care Act. Supporting the transformation of Medicaid E&E systems through these enhanced funding and clearer federal guidelines will also reduce duplication of systems and overall system costs.

E. Accounting Statement and Table

Whenever a rule is considered a significant rule under Executive Order 12866, we are required to develop an Accounting Statement. We have prepared an accounting statement showing the classification of the expenditures associated with the provisions of this rule. Tables 3 through 5 provide our best estimate of the net costs as a result of the changes presented in this rule.

Table 3—Federal Net Costs

Category	Estimates	Units
		Year dollar	Discount rate %	Period covered
Annualized Monetized ($million/year)	444.3	2016	7	2016-2025
	363.6	2016	3	2016-2025

Table 4—State Net Costs

Category	Estimates	Units
		Year dollar	Discount rate %	Period covered
Annualized Monetized ($million/year)	−81.2	2016	7	2016-2025
	−99.1	2016	3	2016-2025

Table 5—Estimated Net Present Value of Federal Costs, FY 2016-2025

[In millions of dollars]

	Discount rate
	7%	3%
Federal Costs NPV	$3,120.6	$3,101.8
State Costs NPV	−$570.7	−$845.5
*Note: The 10-year federal costs are less than the net present value of the federal costs and savings due to the pattern of projected costs and savings over the 10-year period. There are costs in the first several years of the period, followed by savings in the last several years. When the costs and savings are discounted, the savings are more heavily discounted when calculating the net present value because they occur later. Therefore, the net present values under the discount factors used here are actually greater than the 10-year net cost.

We received the following comment about this analysis:

Comment: One commenter requested CMS identify the nine states referred to as having relatively new E&E systems and the 28 states referred to as having legacy E&E systems.

Response: The nine states that have relatively new E&E systems that do not need system replacements are; Colorado, Florida, Idaho, Montana, New Mexico, North Carolina, Oklahoma, Texas, and Utah. The twenty-eight states/territories that are referred to as having a legacy E&E system that we believe will eventually retire their legacy system with ongoing 90 percent FFP are: Alabama, Alaska, American Samoa, California, Connecticut, Georgia, Guam, Illinois, Louisiana, Maine, Maryland, Massachusetts, Michigan, Nebraska, Nevada, New York, North Dakota, Ohio, Oregon, Pennsylvania, Puerto Rico, Rhode Island, South Carolina, South Dakota, Tennessee, Vermont, Virgin Islands, and Wyoming. We believe that the remaining states would have retired their legacy E&E systems with a 2-year 90 percent FFP extension.

F. Conclusion

We considered a number of ways in which application of the standards and conditions, including increased use of MITA, could result in savings. We see increased investments in DDI somewhat offset by lower costs over the 10-year budget window due to the increased savings to operating one E&E system and eliminating legacy systems. The costs shift from mostly 90 percent FFP for design, development, and installation to 75 percent FFP for M&Os over time.

The federal net costs from FY 2016 through 2025 of implementing the regulation on eligibility systems is approximately $3 billion. This includes approximately $5.1 billion in increased federal costs for system design and development, offset by lower anticipated M&Os costs. The state net costs from FY 2016 through 2025 for implementing the regulation on eligibility systems is approximately −$1.1 billion. This includes approximately $572 million in state costs for system design and development, offset by lower anticipated M&Os costs.

There are uncertainties regarding our assumptions, including state behavior, and the associated cost estimates for states implementing new systems. However, we have based our assumptions on data on states' previous behavior, spending and APDs over the last 4 years. It is important to point out that we believe that systems transformation is necessary to meet the vision of the Affordable Care Act and consequently, these costs are necessary and would provide for efficient systems that in the end would provide for more efficient and effective administration of the state plan.

The analysis above, together with the remainder of this preamble, provides a Regulatory Impact Analysis. The reason to refer to other portions of the preamble is that they include sections, such as the statutory authority and purpose that are required but are not normally included in the impact analysis section.

In accordance with the provisions of Executive Order 12866, this regulation was reviewed by the Office of Management and Budget.

List of Subjects

42 CFR Part 433

• Administrative practice and procedure
• Child support
• Claims
• Grant programs—health
• Medicaid
• Reporting and recordkeeping requirements

45 CFR Part 95

• Claims
• Computer technology
• Grant programs—health
• Grant programs—social programs
• Reporting and recordkeeping requirements
• Social security

For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services amends 42 CFR chapter IV as set forth below:

PART 433—STATE FISCAL ADMINISTRATION

6. The authority citation for part 433 continues to read as follows:

Authority: Section 1102 of the Social Security Act, (42 U.S.C. 1302).

§ 433.110

[Amended]

2. In § 433.110, amend paragraph (a)(1) by removing the reference “ 45 CFR part 74” and adding in its place “45 CFR part 75”, removing paragraphs (a)(2)(ii) and (iii), and removing and reserving paragraph (b).

3. Section 433.111 is amended by revising paragraph (b) and adding paragraphs (d) through (j) to read as follows:

§ 433.111

Definitions.

* * * * *

(b) “Mechanized claims processing and information retrieval system” means:

(1) “Mechanized claims processing and information retrieval system” means the system of software and/or hardware used to process claims for medical assistance and to retrieve and produce service utilization and management information required by the Medicaid single state agency and Federal government for program administration and audit purposes. It may include modules of hardware, software, and other technical capabilities that are used by the Medicaid Single State Agency to manage, monitor, and administer the Medicaid enterprise, including transaction processing, information management, and reporting and data analytics.

(2) “Mechanized claims processing and information retrieval system” includes a “System of Systems.” Under this definition all modules or systems developed to support a Medicaid Management Information System (MMIS) and Eligibility and Enrollment (E&E) may be implemented as discrete, independent, interoperable elements. Use of a System of Systems requires interoperability between the systems.

(i) The system consists of—

(A) Required modules specified by the Secretary.

(B) Required changes to the system or required module that are specified by the Secretary.

(C) Approved enhancements to the system or module.

(ii) A “Mechanized claims processing and information retrieval system” include—s—

(A) An Eligibility and Enrollment (E&E) System which is used to process applications from Medicaid or CHIP applicants and beneficiaries to determine eligibility for enrollment in the Medicaid or CHIP programs, as well as change in circumstance updates and renewals; and

(B) A Medicaid Management Information System (MMIS) which is used to process claims for Medicaid payment from providers of medical care and services furnished to beneficiaries under the medical assistance program and to perform other functions necessary for economic and efficient operations, management, monitoring, and administration of the Medicaid program. The pertinent business areas are those included in the MMIS Certification Toolkit, and they may be applicable to Fee-For-Service, Managed Care, or an Administrative Services Organization (ASO) model.

* * * * *

(d) “Open source” means software that can be used freely, changed, and shared (in modified or unmodified form) by anyone. Open source software is distributed under Open Source Initiative-approved licenses that comply with an open source framework that allows for free redistribution, provision of the source code, allowance for modifications and derived works, free and open distribution of licenses without restrictions and licenses that are technology-neutral.

(e) “Proprietary” means a closed source product licensed under exclusive legal right of the copyright holder with the intent that the licensee is given the right to use the software only under certain conditions, and restricted from other uses, such as modification, sharing, studying, redistribution, or reverse engineering.

(f) “Service” means a self-contained unit of functionality that is a discretely invokable operation. Services can be combined to provide the functionality of a large software application.

(g) “Shared Service” means the use of a service, including SaaS, by one part of an organization or group, including states, where that service is also made available to other entities of the organization, group or states. Thus the funding and resourcing of the service is shared and the providing department effectively becomes an internal service provider.

(h) “Module” means 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.

(i) “Commercial Off the Shelf” (COTS) software means specialized software (which could be a system, subsystem or module) designed for specific applications that is available for sale or lease to other users in the commercial marketplace, and that can be used with little or no modification.

(j) “Software-as-a-Service” (SaaS) means a software delivery model in which software is managed and licensed by its vendor-owner on a pay-for-use or subscription basis, centrally hosted, on-demand, and common to all users.

4. Section 433.112 is amended by revising the section heading and paragraphs (b) introductory text, (b)(12) and (16), and (c) and adding paragraphs (b)(17) through (22) to read as follows:

§ 433.112

FFP for design, development, installation or enhancement of mechanized processing and information retrieval systems.

* * * * *

(b) CMS will approve the E&E or claims system described in an APD if certain conditions are met. The conditions that a system must meet are:

* * * * *

(12) The agency ensures alignment with, and incorporation of, industry standards adopted by the Office of the National Coordinator for Health IT in accordance with 45 CFR part 170, subpart B: The HIPAA privacy, security and transaction standards; accessibility standards established under section 508 of the Rehabilitation Act, or standards that provide greater accessibility for individuals with disabilities, and compliance with Federal civil rights laws; standards adopted by the Secretary under section 1104 of the Affordable Care Act; and standards and protocols adopted by the Secretary under section 1561 of the Affordable Care Act.

* * * * *

(16) The system supports seamless coordination and integration with the Marketplace, the Federal Data Services Hub, and allows interoperability with health information exchanges, public health agencies, human services programs, and community organizations providing outreach and enrollment assistance services as applicable.

(17) For E&E systems, the State must have delivered acceptable MAGI-based system functionality, demonstrated by performance testing and results based on critical success factors, with limited mitigations and workarounds.

(18) The State must submit plans that contain strategies for reducing the operational consequences of failure to meet applicable requirements for all major milestones and functionality.

(19) The agency, in writing through the APD, must identify key state personnel by name, type and time commitment assigned to each project.

(20) Systems and modules developed, installed or improved with 90 percent match must include documentation of components and procedures such that the systems could be operated by a variety of contractors or other users.

(21) For software systems and modules developed, installed or improved with 90 percent match, the State must consider strategies to minimize the costs and difficulty of operating the software on alternate hardware or operating systems.

(22) Other conditions for compliance with existing statutory and regulatory requirements, issued through formal guidance procedures, determined by the Secretary to be necessary to update and ensure proper implementation of those existing requirements.

(c)(1) FFP is available at 90 percent of a State's expenditures for the design, development, installation or enhancement of an E&E system that meets the requirements of this subpart and only for costs incurred for goods and services provided on or after April 19, 2011.

(2) Design, development, installation, or enhancement costs include costs for initial licensing of commercial off the shelf (COTS) software, and the minimum necessary costs to analyze the suitability of COTS software, install, configure and integrate the COTS software, and modify non-COTS software to ensure coordination of operations. The nature and extent of such costs must be expressly described in the approved APD.

5. Section 433.116 is amended by revising paragraphs (b), (c), and (j) to read as follows:

§ 433.116

FFP for operation of mechanized claims processing and information retrieval systems.

* * * * *

(b) CMS will approve enhanced FFP for system operations if the conditions specified in paragraphs (c) through (i) of this section are met.

(c) The conditions of § 433.112(b)(1) through (22) must be met at the time of approval.

* * * * *

(j) Beginning, and no earlier than, April 19, 2011, FFP is available at 75 percent of a State's expenditures for the operation of an E&E system that meets the requirements of this subpart. FFP is not available for E&E systems that do not meet the standards and conditions.

6. Section 433.119 is amended by revising paragraph (a)(1) to read as follows:

§ 433.119

Conditions for reapproval; notice of decision.

(a)* * *

(1) The system meets the requirements of § 433.112(b)(1), (3), (4), and (7) through (22).

* * * * *

7. Section 433.120 is revised to read as follows:

§ 433.120

Procedures for reduction of FFP after reapproval review.

(a) If CMS determines after the reapproval review that the system no longer meets the conditions for reapproval in § 433.119, CMS may reduce FFP for certain expenditures for system operations.

(b) CMS may reduce FFP from 75 percent to 50 percent for expenditures related to the operations of non-compliant functionality or system components.

For the reasons set forth in the preamble, the Department of Health and Human Services amends 45 CFR part 95 as set forth below:

PART 95—GENERAL ADMINISTRATION—GRANT PROGRAMS (PUBLIC ASSISTANCE, MEDICAL ASSISTANCE AND STATE CHILDREN'S HEALTH INSURANCE PROGRAMS)

8. The authority citation for part 95 continues to read as follows:

Authority: 5 U.S.C 301, 42 U.S.C. 622(b), 629b(a), 652(a), 652(d), 654A, 671(a), 1302, and 1396a(a).

9. Section 95.611 is amended by revising paragraph (a)(2) to read as follows:

§ 95.611

Prior approval conditions.

(a)* * *

(2) A State must obtain prior approval from the Department which is reflected in a record, as specified in paragraph (b) of this section, when the State plans to acquire ADP equipment or services with proposed FFP at the enhanced matching rate subject to one of the following:

(i) If authorized by § 205.35 of this title and part 307 of this title, regardless of the acquisition cost.

(ii) If authorized by 42 CFR part 433, subpart C, if the contract is anticipated to or will exceed $500,000.

* * * * *

Dated: November 16, 2015.

Andrew M. Slavitt,

Acting Administrator, Centers for Medicare & Medicaid Services.

Dated: November 18, 2015.

Sylvia M. Burwell,

Secretary, Department of Health and Human Services.