Chapter 6 - CMS Certification Milestone 4: Validate Medicaid Solution Functionality

From RCWiki
Jump to: navigation, search
Primary Guidelines MITA 3.0 Guidelines, Medicaid Enterprise Certification Roadmap
Primary Methodology State- or Vendor-specific Methodology
Input SS-A, (inclusive), RTM from Milestone 3
Primary Activities Verifying SRC Functionality, Incorporating Changes in SS-A and MECT Checklists, Preparing for CMS Certification
Output MECT Checklists Linked to Solution Proof Points, Certification Readiness Checklists (AKA State Readiness Assessment Checklists and Certification Readiness Assessment Checklists)
Downstream Activities Supported Pre-Certification Meeting with CMS


The Medicaid Enterprise Certification Roadmap calls this milestone, "Validate MMIS Functionality." In ReadyCert 6CM, it is called "Validate Medicaid Solution Functionality." Since publication of the Medicaid Enterprise Certification Toolkit in 2007, the ACA-catalyst has taken the roadmap from a MMIS-centric guideline to one that is applicable to all Medicaid solutions.

Figure 6-1: States must achieve 6 CMS certification milestones to receive federal funds for their IT investments

There are two major activity categories in this milestone. First, the state and its vendors are deploying new or replacement solution functionality. The state is typically supported by SMEs from other agencies and departments as well as by IV&V and PMO vendors. The solution vendors that are involved in the deployment are those with contractual responsibility for the deployment. Typically, there is a lead vendor that is responsible for Analyzing, Configuring and Deploying the new solution. That vendor may be supported by subcontractors that perform under its authority, called that of the prime contractor. Some states may use specialty vendors under a direct relationship with the state, in which case, the lead contractor has no authority over the specialty vendors. Governance, that is, how decisions are made and executed, is key to successful solution deployment. The approach for establishing the governance structure, model and processes are covered under the overall PM methodology. However, it is a pre-requisite for commencement of this milestone.

The second part of this milestone involves the validation of the new or replacement Medicaid solution using the MECT Checklists. Using ReadyCert 6CM, the second part occurs concurrently with, and as a function, of the first, saving states and vendors time, resource utilization and money.

As such, this chapter has two parts. The first describes the approach for creating the baseline MECT checklists and continuously updating them throughout the deployment of the new or replacement solution functionality. The second part deals with the mechanics for addressing the Second Protocol of Chapter 3 of the Medicaid Enterprise Certification Toolkit.

Part 1: RTM/MECT Checklists Management and Integration

1.1 - RTM/MECT Checklists Use and Context

The RTM/MECT Checklists created and used throughout the procurement process in Milestone #3 form the baseline for the RTM/MECT Checklists used in this milestone. The RTM/MECT Checklists link all solution details to their associated business processes in ReadyCert. ReadyCert enforces linkages back to the associated attributes in the SS-A. This linkage ensures that the SS-A is continuously synced with the MECT Checklists, and vice versa, which gives the state and CMS a real time view of the MITA Maturity Roadmap and the To-Be assessments for all processes in the MITA BPM.

The methodology, tools, processes and techniques used to deploy Medicaid solutions vary from state to state. The Seven Conditions stress the need to use standard methodologies in deploying new or replacement solution functionality. CMS uses the term DD&I in its publications, however, this term is not relevant in today’s environment. In DD&I projects in previous generations of Medicaid system installations, the state defined its requirements and the vendors told the state how they would design and develop a system to meet those requirements. The systems were implemented in a one-to-one model.

Today, however, the MECT SRC describes the functionality that the MITA-aligned, SOA-based solution must have. Vendors respond with proof points about how the proposed solution meets (or will meet, per a committed product roadmap) the state’s requirements. When the vendor’s solution is selected, the requirements are analyzed, the solution is configured and tested and subsequently, increments of business, information and technology functionality are deployed.

Figure 6-2: Today’s Medicaid solutions are brought to life using an Analyze, Configure, Deploy framework, rather than the outdated DD&I framework from pre-MITA era system implementations.

The RTM/MECT Checklists do not take the place of the tools and techniques used by the state and its vendors to perform the Analyze, Configure and Deploy responsibilities in the overall MS Project Plan. For example, testing tools are required to simulate the new or replacement solution’s functionality and ensure that it performs as intended and required. The ReadyCert RTM/MECT Checklists do not substitute for those tools. Rather, they integrate via the overall MS Project Plan to provide a real-time view of the progress toward the To-Be state and record any changes made to the RTM/MECT Checklists. ReadyCert helps states and vendors comply with CMS’ requirements to prove the solution functions as the MITA framework requires, (for FFP), and supports enterprise-wide change management. Whereas the PM change management process records and tracks change at the project level, it does not integrate change at the SS-A and Medicaid Enterprise Certification Roadmap levels. ReadyCert facilitates this change automatically and seamlessly.

1.2 - Establish Linkage and Update Protocols between ReadyCert and MS Project Plan

ReadyCert is compatible with Microsoft Project; linkage between the two tools is straightforward. It is required that the MITA BPM numbering scheme, which is carried forward to the RTM/MECT Checklists, be used in the overall MS Project Plan to facilitate linkage between project tasks and the associated items on the RTM/MECT Checklists.

Under the guidance of the overall PM methodology and the Governance Model, determine the linkages desired between ReadyCert and the MS Project Plan. The options include:

  • Status Indicators – All status indicators can be set to zero when the project commences and updated automatically in ReadyCert, based on status indicators maintained in the MS Project Plan. ReadyCert provides a graphic depiction by individual SRC and Business Objective, facilitating management and executive review of project status.
  • Compliant – All "no" values can be changed automatically when the MS Project Plan’s indicators confirm that the functionality has been built into the solution.
  • Release or Increment – All values can be synched with the MS Project Plan to maintain a positive audit trail at the CMS certification-level. Date changes at the MS Project Plan level can be updated automatically in the RTM/MECT Checklists, which, in turn, update the status indicators in ReadyCert.
  • Solution Descriptions – Changes to textual descriptions made at the RTM/MECT Checklists level can be communicated to the MS Project Plan and updated automatically, and vice versa.
  • Business Process Models - Changes to business process diagrams attached to items in the RTM/MECT Checklists level can be communicated to the MS Project Plan and updated automatically, and vice versa.
  • Screen Shots and Artifacts - Changes to visual aids and reports attached to items in the RTM/MECT Checklists level can be communicated to the MS Project Plan and updated automatically, and vice versa.

It is recommended that ReadyCert be used as a business-facing tool to supplement the technology-centric tools used by the state and vendors for managing the overall project and performing specific project activities. The technology-centric tools are often difficult for business users to understand and work within. ReadyCert is business-centric and intuitive, which may be a better option for business SMEs engaged in the project. Change requests made in ReadyCert generate a formal change request per the overall PM methodology. The state and vendor CCB uses the standard processes in place to adjudicate change requests.

1.3 - Link ReadyCert to MS Project Plan

Under the guidance of the overall PM methodology, establish the field-specific map between ReadyCert and the MS Project Plan. Configure ReadyCert screens to comply with the MS Project Plan’s configuration. Test the linkages between the tools, based on the configurations made.

1.4 - Maintain, Manage and Report on Information in ReadyCert

Use the ReadyCert tool to track and trace solution proof points to the RTM/MECT Checklists. While the overall MS Project Plan is used to track all project activities, ReadyCert is used to track progress toward certification readiness.

Standard reports in ReadyCert provide a wide variety of information to assist decision makers in tracking compliance toward CMS Certification. Custom reports can be generated using ReadyCert’s Report Writer feature.

Establish the frequency with which reports are to be generated. Enforce quality control and management measures to ensure that the information in ReadyCert is correct and properly linked with that in the MS Project Plan.

It is recommended that communication and coordination between the MITA 3.0 SS-A team and the solution deployment team be maintained from the beginning to the end of the journey to facilitate consistent, repeatable and reusable information.

ReadyCert provides maximum reuse of information. The tool automatically updates the appropriate values in the SS-A when a related change is made to the RTM/MECT Checklists. This process occurs automatically (based on the configurations made in Milestone #3, carried forward to this milestone and linked to the MS Project Plan). For example, when screen shots are updated as the solution is being deployed, the update is automatically made to the SRC in the RTM/MECT Checklists and to the To-Be supporting evidence.

Part 2: State Certification Readiness Protocol

2.1 - ReadyCert Use and Context with CMS

The second protocol, called the State Certification Readiness Protocol, describes the process that CMS requires states to take to ensure the new or replaced solution meets requirements and is ready for certification. The second protocol is somewhat repetitive with the activities in Milestone #2, APD Development; Milestone #3, Release RFP, Sign Contract; and Milestone #5, Pre-Certification Meeting.

ReadyCert facilitates every step of the Second Protocol, requiring virtually no new work activity by the state or vendor teams.

2.2 - Select MECT Checklists (Second Protocol, Step 1)

ReadyCert automatically updates the MECT Checklists as changes are made. The MECT Checklists are available on demand for use in preparing the Certification Readiness Checklists, which is the outcome of the Second Protocol.

Select the MECT Checklists for use in the Certification Readiness Checklists.

2.3 - Tailor the MECT Checklists (Second Protocol, Step 2)

The Checklists were originally tailored as a function of the SS-A (with state-specific business processes). The resulting MECT Checklists carried forward automatically to Milestone #1, State Goals and Objectives; Milestone #2, APD Development; and Milestone #3, Release RFP, Sign Contract. Throughout Milestone #4, change is communicated from the MS Project Plan and MECT Checklists in ReadyCert, providing up-to-the-minute tailored checklists.

Transfer the MECT Checklists into a format appropriate for certification-readiness use. The SMA should work with the CMS RO to define the format; however, the standard MECT Checklists format is acceptable to CMS. The only modification that is generally required is to change the title of the MECT Checklists to Certification Readiness Checklists.

2.4 - Fill Out the Certification Readiness Checklists (Second Protocol, Step 3)

The Certification readiness Checklists are already complete and up-to-the-minute in ReadyCert. No additional activity is required.

2.5 Begin Data Collection (Second Protocol, Step 4)

CMS expects the product of Step 4 in the Second Protocol to be, "initiation of a data collection process that demonstrates that each criterion in the checklists has been met." Though not explicit in the CMS documentation, there are essentially two types of data: proof points that validate the solution is compliant with the defined SRC; and data that proves the solution is consistently functioning as intended and producing usable output.

By using ReadyCert, in combination with the MS Project Plan, every time proof points are added or modified, the information is captured on the RTM/MECT Checklists automatically. As these checklists form the Certification Readiness Checklists, there is no separate process required for collecting proof point data. The Certification Readiness Checklists are complete and current in ReadyCert. No additional activity is required to complete SRC proof points.

CMS requires six months of data[1] before the actual certification can be requested, according to the Medicaid Enterprise Certification Toolkit. The data is examined by CMS in the form of reports. It is recommended that the data be linked to the appropriate SRC in ReadyCert. When the solution becomes operational and actual data is generated, the associated SRC can be linked to reports in the solution’s data store. This way, the state and CMS have a single stool with linkages to the appropriate source information.

2.6 - Submit the Checklists (Second Protocol, Step 5)

Export a copy of ReadyCert and submit it to the CMS RO as required by this step in the Second Protocol. While ReadyCert produces output in Word, Excel and PDF format, it is not recommended as the screens in ReadyCert will facilitate CMS review in an eco-friendly manner.


  1. Of late, CMS has been receptive to alternative certification processes, sometimes requiring less than six months of data. The state and CMS RO should work together to define the amount of time and data appropriate to begin the certification process.