Conditions for Enhanced Funding (CEF)

Overview

Regulatory requirements that span business areas, previously called “enterprise,” are now Conditions for Enhanced Funding (CEF) and mirror the “Standards and Conditions” in regulation. Under SMC, CMS significantly reduced number of requirements from 5 core MECT checklists to 22 conditions.

States must attest that the system complies with all the CEF outlined at 42 CFR 433.112 and that the system remains in compliance with Medicaid program standards, laws, regulations, and industry best practices once it is in production.

Conditions for Enhanced Funding

The information in the following table contains the Conditions for Enhanced Funding (CEF) described in 42 C.F.R. § 433.112 that are applicable for all MES modules.

This table, combined with the applicable business area outcomes, are a starting point for aligning the state’s goals for a project with applicable CMS-required outcomes.

Click here to download the Conditions for Enhanced Funding in a CSV file

Ref #	Condition	Example Evidence
1	CMS determines the system is likely to provide more efficient, economical, and effective administration of the State plan.	Documented in the CMS approved APD, including, but not limited to, the Analysis of Alternatives (AoA), State Self-Assessment (SS-A), or Cost Benefit Analysis (CBA), CMS-required and/or state-specific outcomes.
2	The system meets the system requirements, standards and conditions, and performance standards in Part 11 of the State Medicaid Manual, as periodically amended.	Refer to the applicable business area modular implementation streamlined business outcomes and metrics. Can be a state self-attestation.
3	The system is compatible with the claims processing and information retrieval systems used in the administration of Medicare for prompt eligibility verification and for processing claims for persons eligible for both programs.	Provide evidence of processing dual-eligible beneficiaries. Provide evidence of claims or eligibility and enrollment data loaded in the system being certified. Can be N/A depending on the MES module, if the module does not interface with the Claims or Eligibility and Enrollment module. Can be a state self-attestation.
4	The system supports the data requirements of quality improvement organizations established under Part B of title XI of the Act.	Provide evidence on how the MES module interfaces with the quality improvement organizations (QIO). Can be N/A depending on the MES module.
5	The State owns any software that is designed, developed, installed or improved with 90 percent FFP.	Documented in the contractual language between the SMA and vendor. If SaaS, then the language would focus on owning data vs software. Applicable procurement related documentation. Documented in the CMS approved APD which includes the state attestation and/or supplemental material.
6	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, developed, installed or enhanced with 90 percent FFP.	Documented in the contractual language between the SMA and the vendor. Documented in the CMS approved APD which includes the state attestation and/or supplemental material.
7	The costs of the system are determined in accordance with 45 C.F.R 75, subpart E.	Documented in the contractual language between the SMA and vendor. Documented in the CMS approved APD which includes the state attestation and/or supplemental material.
8	The Medicaid agency agrees in writing to use the system for the period of time specified in the advance planning document (approved by CMS) or for any shorter period of time that CMS determines justifies the Federal funds invested.	Documented minimum timeframe of use in the CMS approved APD. Can be a state self-attestation.
9	The agency agrees in writing that the information in the system will be safeguarded in accordance with 42 C.F.R. 431 subpart F of this subchapter.	Required: Most recent independent third-party security and privacy controls assessment report performed at a minimum of every two years per 45 C.F.R. 95.621(f)(3). Most recent independent third-party penetration test, performed at a minimum of every two years per 45 C.F.R. 95.621(f)(3). Most recent Vulnerability Scans, recommend running monthly. Plan of Action and Milestones (see Reference section below). Or: Affordable Care Act (ACA) Authority to Connect (ATC) to CMS Hub. Optional: Most recent Security Incident Breach Notification. HIPAA Business Associate Agreement (BAA). HIPAA sanction rules.
10	Use 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.	Conceptual data model that depicts high-level data and relationships with other state Medicaid systems/modules. Enterprise system diagrams to show how the open architecture is integrated in the overall solution (e.g. system architecture design showing adoption of an open Application Programming Interface (API) based architecture, automated arrangement, coordination, and management of the system). Screenshot of the business rules engine control panel.
11	Align to, and advance increasingly, in maturity for business, architecture, and data.	Documented in the CMS approved APD which includes the state attestation and/or supplemental material. Can be the SS-A or a state self-attestation.
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 C.F.R. 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.	Required: Most recent independent third-party security and privacy controls assessment report performed at a minimum of every two years per 45 C.F.R. 95.621(f)(3). Most recent independent third-party penetration test, performed at a minimum of every two years per 45 C.F.R. 95.621(f)(3). Most recent Vulnerability Scans, recommend running monthly. Plan of Action and Milestones (see Reference section below). 508 test report or equivalent showing Level AA compliance.
13	Promote sharing, leverage, and reuse of Medicaid technologies and systems within and among States.	Describe and document how the SMA leverages reuse opportunities. Documented in the CMS approved APD which includes the state attestation and/or supplemental material, AoA, or SS-A.
14	Support accurate and timely processing and adjudications/eligibility determinations and effective communications with providers, beneficiaries, and the public.	Refer to applicable business outcomes and metrics related to the following but not limited to, Claims, Pharmacy, Eligibility and Enrollment modules. Can be N/A depending on the MES module.
15	Produce transaction data, reports, and performance information that would contribute to program evaluation, continuous improvement in business operations, and transparency and accountability.	Confirmation of T-MSIS Outcome Based Assessment (OBA) reporting compliance. Confirmation of following T-MSIS Standard Operating Procedure (SOP). Metrics data reported in the Operational Report Workbook. Applicable service level agreement and/or key performance indicator showing the system can record and monitor the performance and utilization of resources.  Payment Error Rate Measurement (PERM) report and/or enrollment data performance indicator report as applicable.
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.	Refer to applicable business outcomes and metrics related to the following but not limited to, Eligibility and Enrollment, and Health Information Exchange modules. Can be N/A depending on the MES module.
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.	Refer to applicable business outcomes and metrics related to the Eligibility and Enrollment module. Can be N/A depending on the MES module.
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. This should include, but not be limited to, the Disaster Recovery Plan and related Disaster Recovery Test results.	Provide module specific DRP and DR test results, which are coordinated with the other related SMA DRP. Plan of Action and Milestones with any deficiencies found during the IT system level DR test.
19	The agency, in writing through the APD, must identify key state personnel by name, type and time commitment assigned to each project.	Documented in the contractual language between SMA and vendor. Documented in the CMS approved APD which includes the state attestation and/or supplemental material.
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.	Provide MES module-specific transition plan or relevant knowledgebase (training) documentation, and most current Concept of Operations (ConOps) documentation.
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.	Documented in the contractual language between SMA and vendor. Documented in the CMS approved APD which includes the state attestation and/or supplemental material, and the AoA.
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.	Other reporting metrics such as CMS-37 and CMS-64 quarterly estimates and expenditure reports, as applicable. Confirmation of T-MSIS Outcome Based Assessment (OBA) reporting compliance. Can be a state self-attestation, including, but not limited to, attesting that the system captures and stores relevant information necessary to support Medicaid Fraud Control Unit (MFCU) investigations.

Tips & Best Practices

General

While the CEF tab of the intake form must be fully completed for both the ORR and CR, if certain CEF requirements are met during the ORR, the state does not need to go over them during CR unless there are significant changes.
In some cases, CEF and security-related demonstrations can be conducted as pre-ORR or pre-CR desk reviews, or as separate conversations.
Not every Condition for Enhanced Funding requirement will apply to every system. For example, if a Condition for Enhanced Funding related to Enrollment & Eligibility does not apply because the system is a Health Information Exchange, mark it as such as explain why in the intake form.
Some CEFs can be satisfied through the established, tracked CMS-Required and State-Specific Outcomes.
The term ‘reporting’ either refers to internal quality management or performance reporting, or for federal reports, such as CMS-37, CMS-64, or TMSIS. In all instances, the system should enhance reporting wherever possible in comparison to previous reporting efforts. In addition, the state maintains complete and accurate historical TMSIS data for program evaluation and the continuous improvement of business operations. The state can demonstrate that data quality issues are meeting the targets for Outcomes Based Assessment (OBA) critical priority data quality checks, high priority data quality checks, and the expenditure data content category. The state should also demonstrate they are working in good faith to resolve such issues. Generally, CMS will consider the state out of compliance with TMSIS requirements if it is not meeting the targets for OBA criteria in critical priority data quality checks, high priority data quality checks, and the expenditure data content category and/or the state is not working in good faith to resolve any identified data quality issues. The state meets all requirements outlined in the T-MSIS Reporting - Standard Operating Procedures (SOP) for any Large System Enhancements (LSEs) affecting T-MSIS reporting.

Artifacts

The most common artifacts for security-related CEF are third-party penetration test results, security/privacy assessment report, plan of action and milestones (POA&M).
The most common artifacts for the non-security related CEF are typically the APD, vendor contacts, system design documents/ConOps, 508 test results, T-MSIS concurrence, Disaster Recovery Plans, ConOps, and Disaster Recovery Test Report.

508 Compliance

States should produce an objective artifact on 508 test reports; note that even if these are not in Voluntary Product Accessibility Templates (VPAT) format, this is acceptable as long as the state has performed 508 testing and is able to show the reports. State can follow tools and techniques at https://www.section508.gov/test or https://accessibility.18f.gov. Note that a VPAT is not an audit, as an audit goes into much greater detail.

System Architedcture

States must show how open architecture and vendor communication allows the system to continue performing in a plug-and-play manner despite potential vendor turnover.
States should provide a systems diagram that explains its architecture and the interaction between various aspects of the overarching MMIS ecosystem to demonstrate the larger system structure and how business areas communicate.

Using Contracts and APDs

Certain sections of contractual language with vendors typically contain system cost, leveraging current system functionality, and ownership information. Many times, states do not own the software, although they do own the data and bring that to the vendors; subscription fees are paid to vendors and are documented down to the line level in the APD. The state will need to discuss if the costs are appropriate.
Certain sections of contractual language from the APD typically contain system cost, leveraging current system functionality, and ownership information.

Business Continuity & Disaster Recovery

A Business Continuity Plan (BCP)/Disaster Recovery (DR) should be tested within 6 months post go-live; the state must conduct an actual BCP/DR exercise before the CR takes place. Results should be provided, as well as the state’s plan to remediate any findings identified during the exercise.
States can hold a tabletop BCP/DR test to meet this provision. However, states should plan for the real live BCP/DR testing to ensure their contractors can meet the state’s defined Recovery Time Objective and Recovery Point Objective.

ConOps

A Concept of Operations (ConOps) is a user-oriented document that “describes systems characteristics for a proposed system from a user’s perspective. A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative system characteristics to stakeholders.”¹
A ConOps “describes the proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used. CONOPS can be tailored for many purposes, for example, to obtain consensus among the acquirer, developers, supporters, and user agencies on the operational concept of a proposed system. Additionally, a CONOPS may focus on communicating the user’s needs to the developer or the developer’s ideas to the user and other interested parties.”²

Security & Privacy

Internal security and privacy personnel that is not part of the original MES DDI team can be the independent assessor to evaluate the security and privacy risk posture of the MES module.
States should provide a Security and Privacy Assessment Report (SAR) and Penetration Test report completed by an independent assessor on a periodic basis, at a minimum of every two years, to ensure that appropriate, cost-effective safeguards are incorporated into new and existing systems. State agencies must perform risk analyses whenever significant system changes occur. Additional information about meeting security and privacy requirements can be found in the Framework for the Independent Third-Party Security and Privacy Assessment Guidelines for Medicaid Enterprise Systems, also known as Appendix D in the SMC SMDL Guidance Document.
Typically, a third-party assessor entity is an independent security and privacy assessment organization, but a SMA’s sister agency can also be leveraged if they have the capabilities and skills to perform this task within the project timeline.
HITRUST certification can be utilized as a SAR. However, a separate penetration test report is still needed.
Typically, SSAE Type 2 SOC-1 or SOC-2 are not comprehensive enough to demonstrate the security and privacy risk posture for the MES environment, but states have the authority to make an informed risk tolerance decision to leverage these reports. Please ensure the proper scoping of these complementary assessment frameworks is providing sufficient assessment boundary to cover the MES IT environment.

Additional Resources

References

IEEE Computer Society, March 19, 1998, IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document (IEEE Std 1362-1998). ↩
Office of Management and Budget, December 5, 1994, Operational Concept Description (OCD), Data Item Description DI-IPSC-81430. ↩