Missouri Eligibility Determination and Enrollment System (MEDES) Database Design Document

Size: px

Start display at page:

Download "Missouri Eligibility Determination and Enrollment System (MEDES) Database Design Document"

Roland Stevens
6 years ago
Views:

1 Centers for Medicare & Medicaid Services Missouri Eligibility Determination and Enrollment System (MEDES) Database Design Document Version /29/2013 Document Number: TBD Contact Number: State of Missouri Contract C

2 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 Database Management System Configuration Database Support Software Security and Privacy 6.3 Performance Monitoring and Database Efficiency Operational Implications Data Transfer Requirements Data Formats 6.4 Backup and Recovery Appendix Acronyms Glossary Referenced Documents Record of Changes Database Design Document 2

3 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 Database Design Document 3

4 1. Introduction The purpose of this Database Design Document is to give a high level 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, 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 security related 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 Federally Facilitated 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 Marketplace like plan comparison and selection Database Design Document 4

5 abilities, and is intended to provide the same high level consumer oriented shopping experience envisioned in Marketplaces. The development plan includes three projects: Project I: MAGI eligibility Project II: Non MAGI 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. Database Design Document 5

6 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. Database Design Document 6

4. Design Decisions The database design decisions made are subject to the core technologies supported by Commercial Off the Shelf (COTS) applications.

7 4. Design Decisions The database design decisions made are subject to the core technologies supported by Commercial Off the Shelf (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, request response, and continual monitoring are completed Database Design Document 7

8 in real time. 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. Database Design Document 8

9 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 Database Management System Configuration This information may be provided in a future update of this document Database Support Software This information may be provided in a future update of this document 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. Database Design Document 9

10 6.3.1 Operational Implications Information on operational implications is available in the MEDES SDD 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 Data Formats This information may be provided in a future update of this document. 6.4 Backup and Recovery Information on backup and recovery procedures is available in the Data Conversion Plan. Database Design Document 10

11 Database Design Document 11

12 Appendix Database Design Document 12

13 Acronyms Table 1: Acronyms Acronym ACA APD CALT CHIP CMS COTS DBA DBMS DDI ESB FDSH FFM ICD IV&V MAGI MEDES MITA O&M PMO PMP SDD SI SNAP SOA SOAP SSL Literal Translation Affordable Care Act Advanced Planning Document Collaborative Application Lifecycle Management Tool Children's Health Insurance Program Centers for Medicare and Medicaid Services Commercial Off the Shelf Database Administrator Database Management System Design, Development, and Implementation Enterprise Service Bus Federal Data Services Hub Federally Facilitated Marketplace Interface Control Document Independent Validation and Verification Modified Adjusted Gross Income Missouri Eligibility Determination and Enrollment System Medicaid Information Technology Architecture Operations and Maintenance Project Management Office Program Management Plan System Design Document Solution Integrator Supplemental Nutrition Assistance Program Service Oriented Architecture Simple Object Access Protocol Secure Socket Layer Database Design Document 13

14 SSP TANF XLC System Security Plan Temporary Assistance to Needy Families expedited Life Cycle Database Design Document 14

15 Glossary Table 2: Glossary Term Baseline Centers for Medicare and Medicaid Services (CMS) Children s Health Insurance Program (CHIP) Conversion (Transfer) Family Assistance Management Information System (FAMIS) Definition (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 ) A baseline is configuration identification formally designated and applicable at a specific point in the life cycle of a configuration item. 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. 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. Converting Data from one system in one format to another system/format. 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. Database Design Document 15

16 Medicaid Eligibility Determination and Enrollment System (MEDES) Medicaid Information Technology Architecture (MITA) Modified Adjusted Gross Income (MAGI) Patient Protection and Affordable Care Act (PPACA or ACA) 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 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. 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. Public Law effective March 23, 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. Database Design Document 16

17 Database Design Document 17

18 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 System Design Document System Security Plan (SSP) TBD December 2013 TBD December 2013 TBD September 2013 Database Design Document 18

19 Database Design Document 19

20 Record of Changes Version Number /29/201 3 Table 4: Record of Changes Date Author/Owner Description of Change Cara Chang/ EngagePoint Initial baseline version Database Design Document 20

21 Database Design Document 21

22 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: Title: Role: Matt Dudzik ITSD Project Manager Submitting Organization s Approving Authority Signature: Print Name: Title: Role: CMS Approving Authority Date: Signature: Print Name: Title: Role: CMS Business Owner Date: Database Design Document 22

ACF Interoperability Human Services 2.0 Overview. August 2011 David Jenkins Administration for Children and Families

ACF Interoperability Human Services 2.0 Overview August 2011 David Jenkins Administration for Children and Families Interoperability: An Operational Definition Creating a Health and Human Service System