Missouri Eligibility Determination and Enrollment System ... · Event processing, requestresponse,...

Centers for Medicare & Medicaid Services

CMS eXpedited Life Cycle (XLC)

Missouri Eligibility Determination and Enrollment System (MEDES)

Database Design Document Version 1.0

11/29/2013

Document Number: TBD

Contact Number: State of Missouri Contract C213050001

CMS XLC Approvals

Table of Contents

1. Introduction

2. Overview

3. Assumptions/Constraints/Risks

3.1 Assumptions 3.2 Constraints 3.3 Risks

4. Design Decisions

4.1 Key Factors Influencing Design 4.2 Functional Design Decisions 4.3 Database Management System Decisions 4.4 Security and Privacy Design Decisions 4.5 Performance and Maintenance Design Decisions

5. Detailed Database Design

5.1 Data Software Objects and Resultant Data Structures 5.2 Database Management System Files

6. Database Administration and Monitoring

6.1 Roles and Responsibilities 6.2 System Information

6.2.1 Database Management System Configuration 6.2.2 Database Support Software 6.2.3 Security and Privacy

6.3 Performance Monitoring and Database Efficiency 6.3.1 Operational Implications 6.3.2 Data Transfer Requirements 6.3.3 Data Formats

6.4 Backup and Recovery

Appendix

Acronyms

Glossary

Referenced Documents

Record of Changes

Database Design Document 2 Error! Use the Home tab to apply Version Number to the text that you want to appear here.

11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Approvals

List of Figures

Figure 1: Decision Support Method for Evaluating Database Designs

List of Tables

Table 1: Acronyms

Table 2: Glossary

Table 3: Referenced Documents

Table 4: Record of Changes


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

1. Introduction

The purpose of this Database Design Document is to give a highlevel overview of the database design for the Missouri Eligibility Determination and Enrollment System (MEDES). This document was created as an artifact for the Operational Readiness Review of Project 1, Release 2, scheduled for January 1, 2014. This document will be updated periodically throughout the MEDES project life cycle as database design details are further defined and finalized. The intended audience of the MEDES Database Design Document is all project stakeholders including the project sponsor, senior leadership, and the project team. All security and privacy considerations related to use of this Database Design Document are covered in the System Security Plan (SSP), SSP Workbook, Information Security Risk Assessment, and other securityrelated documentation available on the Collaborative Application Lifecycle Management Tool (CALT).

2. Overview

MEDES is intended to meet the changing requirements in eligibility due to the Affordable Care Act (ACA), such as the use of Modified Adjusted Gross Income (MAGI), the consolidation and simplification of eligibility groups defined by Centers for Medicare and Medicaid Services (CMS), and the interface to the FederallyFacilitated Marketplace (FFM). MEDES will also advance the state’s alignment with Medicaid Information Technology Architecture (MITA) 3.0 and enable the achievement of higher levels of MITA maturity. MEDES will replace the Family Assistance Management Information System (FAMIS), which is the current integrated eligibility system, and eligibility components of several other associated systems that handle Medicaid eligibility for certain categories. In addition, MEDES will be designed to serve as the foundational platform to support the range of Medicaid service delivery systems the state is considering such as Supplemental Nutrition Assistance Program (SNAP) and Temporary Assistance to Needy Families (TANF). The eligibility systems and processes currently in place serve both the Medicaid and Children's Health Insurance Program (CHIP) populations and, throughout this document, the word Medicaid is intended to include CHIP. Missouri intends for MEDES to provide a “No Wrong Door” entry point for all Missourians seeking health care or other financial assistance. MEDES will be built such that it performs Marketplace subsidy eligibility screenings and interacts fully with the FFM, and has the capability to support any other Marketplace model the state elects in the future. Its functionality will include Marketplacelike plan comparison and selection


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

abilities, and is intended to provide the same highlevel consumeroriented shopping experience envisioned in Marketplaces. The development plan includes three projects:

Project I: MAGI eligibility Project II: NonMAGI Medicaid eligibility Project III: Other state programs (e.g. SNAP, TANF)

The existing systems will run concurrently with the new system as needed, until the full functionality of each of the systems to be replaced is achieved in the new system. The state has contracted with EngagePoint as the Solution Integrator (SI) to implement MEDES. The state has also contracted with CSG Government Solutions to be the Project Management Office (PMO) and BerryDunn for Independent Validation and Verification (IV&V) on the project. Because of the January 1, 2014, implementation deadline for many ACA provisions affecting eligibility and enrollment, the State will implement a system that has already passed at least the preliminary design phase and associated gate reviews in some other state. In this way, the State intends to leverage the experience and work of early innovators, CMS, and other states in developing Eligibility and Enrollment systems to meet the ACA requirements. The project will be overseen by the MEDES Executive Steering Committee described and illustrated in the Program Management Plan (PMP). Project management will be performed under the umbrella of the MEDES Steering Committee by the PMO. A full description of the MEDES project is in the Concept of Operations documentation, which is stored on CALT.

3. Assumptions/Constraints/Risks

3.1 Assumptions This section identifies the statements believed to be true for the release of the product or IT system:

Adequate federal funding will be made available to implement and operate the system.

Project implementation deadlines will not change. Intermediate tasks and dependencies will be defined based on the EngagePoint’s Design, Development, and Implementation (DDI) methodologies.

Federal guidance will be provided in a timely manner so as not to delay the project. The processes and plans contained in this document may require revision based on future federal guidance.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

The PMP and its subsidiary plans, including this Risk Management Plan, are living documents. As such, they will be updated as needed.

Changes required in FAMIS and other legacy systems (listed in Section 1.2) will be completed timely and will not cause delays in MEDES development and implementation activities.

Required interfaces between MEDES and federal and state systems will be completed in a timely manner and will not delay development and implementation of the new system.

DDI of the federal data services hub and the FFM will not force any delays in MEDES DDI activities.

3.2 Constraints This section identifies any limitations that must be taken into consideration prior to the release of the product or IT system:

The project schedule continues to compress as time elapses for meeting the federal required dates.

There are a limited number of experienced state resources available to staff the project, especially in view of the very short deadlines and the need to maintain the existing systems for an extended period of time.

Fund appropriation and legislative activity occur on a schedule that isn’t always well aligned with the timing of federal activities and receipt of federal funds.

The DDI schedules for the federal systems (FFM and data services hub) are not aligned with the state’s implementation schedule causing the testing phases for these key integration components to occur at different times between the state and federal systems.

3.3 Risks This section identifies any risks associated with the release of the product or IT system:

The state does not receive federal funding due to the updated Advanced Planning Document (APD) not being accepted (conditional acceptance of the APD has been received) as well as funding in future years).

Insufficient involvement of state resources in the project due to competing projects and priorities.

Staff turnover resulting in lack of knowledge and experience among project team members.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

4. Design Decisions

The database design decisions made are subject to the core technologies supported by Commercial OfftheShelf (COTS) applications. The following figure shows the criteria used in the selection of software.

Figure 1: Decision Support Method for Evaluating Database Designs

4.1 Key Factors Influencing Design The overall design and target Database Management System (DBMS) environments are dependent on selected components. The Cúram software web server, application server, and database server use Oracle database in their software design. Additional information on the key factors influencing the design may be found in the MEDES System Design Document (SDD).

4.2 Functional Design Decisions The solution is primarily based on Service Oriented Architecture (SOA) leading practices. Event processing, requestresponse, and continual monitoring are completed


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

in realtime. Design is influenced by functionality except for the cases where data is at rest as part of the component. The Cúram component will primarily handle the eligibility and initial data entry point for the user but may also receive initial data from other state systems. Additional information on functional design decisions may be found in the MEDES to Federal Data Services Hub (FDSH) Interface Control Document (ICD) and SDD.

4.3 Database Management System Decisions Information on database management is available in the MEDES SDD.

4.4 Security and Privacy Design Decisions Information on security and privacy is available in the MEDES SDD and System Security Plan (SSP).

4.5 Performance and Maintenance Design Decisions Information on performance and maintenance is available in the MEDES SDD.

5. Detailed Database Design

5.1 Data Software Objects and Resultant Data Structures Information on data software objects and resultant data structures is available in the MEDES SDD.

5.2 Database Management System Files Information on database management system files is available in the MEDES SDD.

6. Database Administration and Monitoring

6.1 Roles and Responsibilities The Database Administrator (DBA) provides database access and the procedures for granting access to the various databases including Connecture, EngagePoint Financials, and Cúram. The DBA is responsible for making changes to the database, adding/deleting groups and users, setting permissions for users, indexing the database after changes have been made, packing/compressing the database, database reporting, and performing database backups/restores. The DBA is responsible for source data, the format of the data, data validation requirements, and disposition of input source and created data in accordance with the requirements of Connecture, EngagePoint Financials and Cúram applications as determined by business requirements.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

The System Administrator is responsible for the UNIX and Windows environments. The System Administrator ensures that the environments are adequately backed up, software is installed and licenses are correctly administered, users are served, firewalls are correctly maintained, and security standards are followed. System Administrator responds to system outages and other problems in a timely manner. The Security Administrator is responsible for setting security policy and creating and modifying rights profiles. This also involves assigning privileges to a user, role, or rights profiles assigning and modifying the security attributes of a user, role, or rights profile. The Application Administrator is responsible for the setting up of the application software, and performing the duties specific to that software application such as its backup.

6.2 System Information The MEDES system consists of the following layers:

Presentation layer Integration layer Application layer SOA runtime management and security Interoperability and mediation Information services Enterprise shared services Transaction services

Additional system information is described in the SDD.

6.2.1 Database Management System Configuration

This information may be provided in a future update of this document.

6.2.2 Database Support Software


6.2.3 Security and Privacy

Information on security and privacy is available in the MEDES SDD and System Security Plan (SSP).

6.3 Performance Monitoring and Database Efficiency The Operations and Maintenance (O&M) team will be responsible for performance monitoring. Additional information may be found in the MEDES Operations and Maintenance Manual.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

6.3.1 Operational Implications

Information on operational implications is available in the MEDES SDD.

6.3.2 Data Transfer Requirements

The implementation of the MEDES and FDSH interfaces will be orchestrated by using the Fuse Enterprise Service Bus (ESB), which is a scalable Service Oriented Architecture (SOA) integration platform. Username and password are passed in the Simple Object Access Protocol (SOAP) payload over a Secure Socket Layer (SSL) connection.

6.3.3 Data Formats


6.4 Backup and Recovery Information on backup and recovery procedures is available in the Data Conversion Plan.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Appendix


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Acronyms

Table 1: Acronyms Acronym Literal Translation ACA Affordable Care Act

APD Advanced Planning Document

CALT Collaborative Application Lifecycle Management Tool

CHIP Children's Health Insurance Program

CMS Centers for Medicare and Medicaid Services

COTS Commercial OfftheShelf

DBA Database Administrator

DBMS Database Management System

DDI Design, Development, and Implementation

ESB Enterprise Service Bus

FDSH Federal Data Services Hub

FFM FederallyFacilitated Marketplace

ICD Interface Control Document

IV&V Independent Validation and Verification

MAGI Modified Adjusted Gross Income

MEDES Missouri Eligibility Determination and Enrollment System

MITA Medicaid Information Technology Architecture

O&M Operations and Maintenance

PMO Project Management Office

PMP Program Management Plan

SDD System Design Document

SI Solution Integrator

SNAP Supplemental Nutrition Assistance Program

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SSL Secure Socket Layer


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

SSP System Security Plan

TANF Temporary Assistance to Needy Families

XLC eXpedited Life Cycle


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Glossary

Table 2: Glossary Term Definition Baseline (1) A specification or product that has been

formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. (2) A document or a set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item. (3) Any agreement or result designated and fixed at a given time, from which changes require justification and approval. (IEEE Std. 610121990) A baseline is configuration identification formally designated and applicable at a specific point in the life cycle of a configuration item.

Centers for Medicare and Medicaid Services (CMS)

U.S. Federal agency which administers Medicare, Medicaid and the Children’s Health Insurance Program. CMS oversees implementation of many of the provisions of the ACA.

Children’s Health Insurance Program (CHIP)

A Medicaid program for children up to age 19 in families with income below 300% of the Federal Poverty Level. In Missouri, the program has 3 groups based on age and income ranges. Families with income in the lowest range receive the benefit at no cost while families with income above 150% of the poverty level must pay a monthly premium.

Conversion (Transfer) Converting Data from one system in one format to another system/format.

Family Assistance Management Information System (FAMIS)

Missouri’s primary client eligibility system for public assistance programs. Used by eligibility specialists to process eligibility for Child Care Assistance, Temporary Assistance, Food Stamps and various Medicaid and vendor programs.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Medicaid Eligibility Determination and Enrollment System (MEDES)

Proposed system that Missouri seeks to acquire to process Medicaid, insurance affordability and human services program in a manner consistent with the vision and requirements of the ACA and CMS.

Medicaid Information Technology Architecture (MITA)

Medicaid system architectural requirements promulgated by CMS for new systems intended to foster integrated business and IT transformation across the Medicaid enterprise to improve the administration of the Medicaid program.

Modified Adjusted Gross Income (MAGI)

A calculated income amount that will be used to determine eligibility for certain Medicaid programs. MAGI is equal to the total income minus allowable tax deductions and credits modified by adding back (1) any foreign income or housing costs; and (2) tax exempt interest received or accrued by the tax payer. Asset tests do not apply in cases where eligibility is based on MAGI.

Patient Protection and Affordable Care Act (PPACA or ACA)

Public Law 111148 effective March 23, 2010. This health care reform changes aspects of the health care insurance industry and Medicaid programs. Requires State to modify Medicaid eligibility rules for select programs and add one new program.


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Referenced Documents

Table 3: Referenced Documents Document Name Document Number and/or URL Issuance Date Concept of Operations N/A July 2013

Data Conversion Plan TBD December 2013

MEDES to FDSH ICD TBD December 2013

Operations and Maintenance Manual

TBD December 2013

System Design Document

TBD December 2013

System Security Plan (SSP)

TBD September 2013


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Record of Changes

Table 4: Record of Changes Version Number

Date Author/Owner Description of Change

1.0 11/29/2013

Cara Chang/ EngagePoint

Initial baseline version


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals


11/29/2013<Pub Date>11/29/2013


CMS XLC Approvals

Approvals

The undersigned acknowledge that they have reviewed the Database Design Document and agree with the information presented within this document. Changes to this Database Design Document will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature: Date: 11/29/2013 Print Name: Matt Dudzik

Title: ITSD Project Manager

Role: Submitting Organization’s Approving Authority Signature: Date: Print Name:

Title:

Role: CMS’ Approving Authority Signature: Date: Print Name:

Title:

Role: CMS Business Owner


11/29/2013<Pub Date>11/29/2013


Missouri Eligibility Determination and Enrollment System ... · Event processing, requestresponse,...

Documents

Transcript of Missouri Eligibility Determination and Enrollment System ... · Event processing, requestresponse,...