PL0019 - CGIS29.pdf

South Carolina Department of Health and Human Services

(SCDHHS)

Member Management Replacement Program (MMRP)

Cúram Global Income Support (CGIS) Project

Architectural Description Document

(ADD)

CGIS29 Medicare Modernization Act (MMA) Interface

MMRP CGIS Project ADD Page 2 of 203 CGIS29 MMA Interface V3.0

Version Log

The Version Log maintains a record of the changes made to the document during its life cycle.

Whole number versions are reserved to designate that the document has reached an Approved status. Changes/Revisions made to approved documents will continue with decimals numbers, until the document again reaches an Approved status.

Version Date Drafted by Role Description of Change

0.1 9/10/18 Sandeep Burman Interface Lead Initial draft

0.2 10/17/18 Sandeep Burman Interface Lead Updated for the review comments

0.3 10/27/18 Sandeep Burman Interface Lead Addressed the review comments.

0.4 10/29/2018 Ken Haas Functional Lead QA Review and Formatting Updates

0.5 12/11/18 Ashleigh Kelley Technical Developer Added TDS section

0.6 12/13/18 Sandeep Burman Interface Lead TDS Section Reviewed

0.7 12/26/2018 Vishnu Ghanta SCDHHS Technical

SME

Review commented added.

0.8 12/28/2018 Ashleigh Kelley / Harjeet Parmar

IBM Team TDS Review comments addressed

0.9 1/08/2019 Ashleigh Kelly / Harjeet Parmar

IBM Team TDS 2nd Cycle Review Comments addressed.

0.10 1/08/2019 Sandeep Burman Interface Lead Task Details Updated.

0.11 1/11/2019 Sandeep Burman Interface Lead Added a new report, see requirement 3.4.1.

Updated 3.9.5 based on the discussion with state team for outstanding verification.

Added clarifications to requirement 3.5, and 3.5.1

0.12 1/11/2019 Krishna Bommaraju / Ashleigh Kelly

Cúram Consultant Updated TDS Section for the corresponding FDS Changes.

0.13 3/20/2019 Tom Drennan IBM BA Formatting updates for final submission.

V1.0 3/26/2019 Erin Coleman Process & Artifact Development Manager

Updated version number, watermark, and approval date.

MMRP CGIS Project ADD Page 3 of 203

Version Date Drafted by Role Description of Change

V1.1 6/19/19 Amir Iqbal Business Analyst Updated for CR32, 35, 44

For CR35 added/updated

MMA_REQ.3.5

MMA_REQ.3.5.1

MMA_REQ.3.5.1.1

MMA_REQ.3.5.1.2

MMA_REQ.3.5.1.3

MMA_REQ.3.5.1.4

For CR32 added/updated

MMA_REQ.3.5.2

MMA_REQ.3.5.2.1

MMA_REQ.3.5.3

MMA_REQ.3.5.4

MMA_REQ.3.5.4.1

MMA_REQ.3.5.4.2

MMA_REQ.3.5.5

MMA_REQ.4.3.1

MMA_REQ.4.3.2

MMA_REQ.4.3.3

For CR44 updated

MMA_REQ.5.2

MMA_REQ.5.10

MMA_REQ.5.12

Report MMA2019R03 is removed based on CR44.

V1.2 7/2/19 Ashleigh Kelley Developer Updated the following TDS sections for CR32 and 35:

Section 5.2.1.2 Section 5.6.2 Section 5.6.18

For CR44 updated:

Section 5.8

V1.3 7/22/19 Amir Iqbal Ashleigh Kelly

Business Analyst Developer

Addressed the comments received for Cycle 1.

V1.4 7/24/19 Amir Iqbal Ashleigh Kelly

Business Analyst Developer

Updated based on the feedback got in the review session with the state team.

MMRP CGIS Project ADD Page 4 of 203

V1.5 9/25/19 Amir Iqbal Ashleigh Kelley

Business Analyst Developer

Added a note how DHEC data interface in CGIS release 2 will impact, per the R1_4_R2 JAD.

Please see MMA_REQ.3.6 for details.

Added a note to MMA_REQ.3.12.1 for the work queue changing in R2 for PCAT 71 task, per the R1_4_R2 JAD.

Updated the task template for PCAT_71_Task for work queue change in R2, per the R1_4_R2

JAD.

Updated TDS to reflect PCAT 71 task work queue assignment for R2

V1.6 10/15/2019 Tiffany Ortega IBM BA Lead Corrected the note on

MMA_REQ.3.6.

Correct the work queue name for

MMA_REQ.3.12.1.

V1.7 1/17/2020 Tiffany Ortega IBM BA Lead Added requirements MMA_REQ.3.5.7.1 and MMA_REQ.3.5.7.1.1 per CR178.

V1.8 1/23/2020 Tiffany Ortega IBM BA Lead Updated requirement

MMA_REQ.3.6

per CR092.

V1.9 1/30/2020 Ashleigh Kelley IBM Developer TDS Updates for CR178:

Updates to Section 5.6.2 - Technical Details of the Streamer Process

V1.10 2/29/2020 Tiffany Ortega IBM BA Lead Updated the note related to R14R2 for R2_MMA_REQ.3.12 to make it requirement R2_MMA_REQ.3.12.1 and corrected the work queue name

V1.11 3/11/2020 Tiffany Ortega IBM BA Lead Updated the following section/requirements per CR193:

1. 4.2.1 Design Description

2. MMA_REQ.2.8

MMRP CGIS Project ADD Page 5 of 203

V1.12 4/2/2020 Amir Iqbal Business Analyst Added following functional requirement MMA_REQ.2.8.1A to address zeros and nines in the period start and end dates.

V1.13 4/06/2020 Vijay Makam IBM Tech Lead Updated ESB Technical section

5.4.4.2.4 for CR 193

V1.14 04/20/2020 Ashleigh Kelley IBM Developer Updated sections 5.2.16 and 5.6.2:

R14R2 TDS Updates for DHEC

DOD

V1.15 04/21/2020 Tiffany Ortega IBM BA Lead Updated the format to align with the ADD Template.

V1.16 04/24/2020 Amir Iqbal Ashleigh Kelley

Business Analyst IBM Developer

Updated for CR218 Record processing order Requirement added/updated

MMA_REQ.2.7

MMA_REQ.3.1.1

MMA_REQ.3.1.2

MMA_REQ.3.1.3

MMA_REQ.3.1.3.1

MMA_REQ.3.1.3.2

MMA_REQ.3.1.3.3

MMA_REQ.3.1.4

MMA_REQ.3.1.4.1

TDS Updates for CR218:

Sections 5.4.2, 5.4.20, 5.4.21, 5.7

V1.17 5/7/2020 Amir Iqbal

Business Analyst Updated for cycle 1 comments for

CR218

Following requirements updated

MMA_REQ.3.1

MMA_REQ.3.1.2

MMA_REQ.3.1.3

MMA_REQ.3.1.3.2

MMA_REQ.3.1.3.3

V1.18 5/15/2020 Amir Iqbal Business Analyst Updated for cycle 2 comments for

CR218.

V1.19 8/1/2020 Tiffany Ortega IBM BA Lead Updated work queue names per

CR260.

V2.0 8/19/2020 Erin Coleman SCDHHS Process & Artifact Development Manager

Updated version number, watermark, and approval date.

Accepted all track changes and removed comments.

MMRP CGIS Project ADD Page 6 of 203

V2.1 10/08/2020 Amir Iqbal IBM BA Updated for CR284 Scenario spreadsheet embedded in Appendix updated.

V2.2 10/12/2020 Amir Iqbal IBM BA Updated for CR295, report name updated.

V2.3 10/15/2020 Ashleigh Kelley IBM Developer Updated section 5.4.2 for CR284 to remove “Move to History” wording

V2.4 11/09/2020 Amir Iqbal IBM BA Updated Mismatch task template based on CR297. Doc only updates to address the documentation discrepancy raised by defect CGISS-48665.

V2.5 1/8/2021 Amir Iqbal IBM BA Updated

R2_MMA_REQ.3.12.1 for

CR318.

V2.6 2/19/21 Ashleigh Kelley IBM Developer Updated TDS section 5.4.2 for

CR345

V3.0 4/11/2021 Erin Coleman Process & Artifact Development Manager

Updated version number, watermark, and approval date.

MMRP CGIS Project ADD Page 7 of 203

The Review Logs maintains a record of the State personnel that performed reviews leading up to the document reaching an Approved status. These reviews do not represent final approval of the document. The Approvals are recorded in the Approval Log Section.

Functional Review Log

The Functional Review Log maintains a record of the State personnel that performed the review of the functional design, confirming the understanding of the design. That the design meets the requirements, business requirements as described and is testable.

SCDHHS Role First Review Date / Reviewer Name

Second Review Date / Reviewer Name

Third Review Date / Review Name

DDI Manager 10/3/2018 Tim Cozine

11/3/2018 Tim Cozine

Business Analyst

10/9/2018 Upendra Koyagura

11/5/2018 Upendra Koyagura

3/22/20- Reviewed R14R2 Updates.

3/17/20- Reviewed CR193 updates.

1/13/20- Reviewed R1-4-R2 updates.

1/30/20- Reviewed FDS updates for CR178 and CR092.

Product Manager

10/4/2018 Abhishek Sahu

11/6/2018 Abhishek Sahu

Technical Lead 10/11/2018 Renjan Bhasi

11/7/2018

Subject Matter Expert

10/10/2018 Patti Davis

11/6/2018 Patti Davis

Documentation Specialist

Alishia Fuller 10/11/2018

11/26/2018 Evan Galdeen

Evan Galdeen 1/25/2019

Technical Lead 10/31/2019 Renjan Bhasi (Completed the review for R1-4-R2 changes)

5/17/2020 Renjan Bhasi (R14R2)

Technical Lead 1/22/2020 Renjan Bhasi 9Completed review of

CR178)

MMRP Process & Artifact Development Manager

3/17/2020 4/1/2020 4/30/2020

MMRP CGIS Project ADD Page 8 of 203

Technical Review Log

The Technical Review Log maintains a record of the State personnel that performed the review of the technical design, confirming the technical approach appropriately addresses the functional design.

SCDHHS Role First Review Date / Reviewer Name

Second Review Date / Reviewer Name

Third Review Date / Review Name

Technical Lead 12/26/2018 Renjan Bhasi

1/3/2019

7/18/2019

Reviewed the CR 32, 35 and 44.

7/31/2019 Renjan Bhasi

Reviewed the CR 32, 35 and 44.

Technical Lead 10/31/2019

(Completed the review for R1-4-R2 changes)

5/17/2020

(R14R2)

Technical Lead 4/30/2020

(CR218)

MMRP CGIS Project ADD Page 9 of 203

The IBM Approval Review Logs capture the IBM Project Team personnel that reviewed the completed ADD. The Functional and Technical Design Sections have been reviewed by the IBM team. The documented design, functional and technical components are understood as documented and can be validated through the Use Cases defined. This signifies that the section/document is ready for SC personnel review and Approval.

IBM Approval Review Logs

Functional Design Section

IBM Functional Design Approval Review – v3.0

Role Name Date Comments

CGIS Project Manager Courtney Stevens 3/25/2021 Approved v2.6 to v3.0

CGIS BA Lead Tiffany Ortega 3/25/2021 Approved v2.6 to v3.0

CGIS Testing Lead Brian Grieves 3/25/2021 Approved v2.6 to v3.0

CGIS Business Analyst Amir Iqbal 3/25/2021 Approved v2.6 to v3.0

CGIS Development Lead Vijay Mujumdar 3/25/2021 Approved v2.6 to v3.0

CGIS Development Team Lead

Randhir Singh 3/25/2021 Approved v2.6 to v3.0

Technical Design Section

IBM Technical Design Approval Review – v2.0

Role Name Date Comments

CGIS Development Lead Vijay Mujumdar 3/25/2021 Approved v2.6 to v3.0

CGIS Development Team Lead Randhir Singh 3/25/2021 Approved v2.6 to v3.0

MMRP CGIS Project ADD Page 10 of 203

The Approvals Section captures the Approval of the current Approved Major version (whole number per PMP). The approval tables will be copied to the Approval Appendix when changes are made that require a subsequent round of Approvals.

Approval Logs

Functional Design Section

The Functional Design Section captures the State personnel that reviewed and approved the functional design; confirming that the design is understood, fulfills the requirements and is testable.

Functional Design Approval v3.0

Role Name Date Approvals (✓)

SCDHHS Business Analyst

Upendra Koyagura 1/13/21

Approved- FDS updates for CR318.

SCDHHS Product

Abhishek Sahu 4/7/2021 Approved V2.6

SCDHHS Technical Lead Renjan Bhasi

SCDHHS DDI Manager Tim Cozine 4/7/2021 Approved V2.6

SCDHHS Process and Artifact Development

Erin Coleman

4/11/2021 ADD Approved

Technical Design Section

The Technical Design Section captures the State personnel that reviewed and approved the technical design. Confirming that the technical approach to fulfilling design is understood fulfills the requirements.

Technical Design Approval v3.0

Role Name Date Approval (✓)

SCDHHS Technical Lead Renjan Bhasi TDS (✓)

SCMMRP CGIS Project ADD Page 11 of 203 MMRP CGIS29 MMA Interface v0.13

Table of Contents

1 Introduction

1.1 Background

1.2 Purpose

1.3 Scope

1.4 Key References

1.5 Definitions and Acronyms

1.6 Key Assumptions

2 Conceptual Flows

2.1 MMA Outbound File Generation Conceptual Flow

2.1.1 MMA Outbound File Generation Conceptual Flow Narrative

2.2 Inbound File from CMS Conceptual Flow

2.2.1 Inbound File from CMS Narrative

3 Requirements Matrix

3.1 Requirement Modifications - N/A

4 Functions

4.1 Generate Outbound MMA Enrollment File

4.1.1 Design Description

4.1.2 Functional Output

4.1.3 Design Details

4.1.4 Screen Flow – N/A

4.1.5 Screen Mockup – N/A

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

Table of Contents

MMRP CGIS Project ADD Page 12 of 203

4.1.11 Validation – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Validate the Inbound MMA File

4.2.1 Design Description

4.2.2 Functional Output

4.2.3 Design Details

4.2.4 Screen Flow – N/A

4.2.5 Screen Mockup – N/A

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks – N/A

4.2.13 Other – N/A

4.3 Process Inbound MMA File

4.3.1 Design Description

4.3.2 Functional Output

4.3.3 Design Details

4.3.4 Screen Flow – N/A

4.3.5 Screen Mockup – N/A

4.3.6 Business Rules – N/A

4.3.7 User Roles – N/A

MMRP CGIS Project ADD Page 13 of 203

4.3.8 Data Fields – N/A

4.3.9 Links – Navigation – N/A

4.3.10 Links – Functions/Actions – N/A

4.3.11 Validation – N/A

4.3.12 Notifications and Tasks

4.3.13 Other – N/A

4.4 Display MMA info & Updates to Medicare Info

4.4.1 Design Description

4.4.2 Functional Output

4.4.3 Design Details

4.4.4 Screen Flow

4.4.5 Screen Mockup

4.4.6 Business Rules – N/A

4.4.7 User Roles – N/A

4.4.8 Data Fields – N/A

4.4.9 Links – Navigation – N/A

4.4.10 Links – Functions/Actions – N/A

4.4.11 Validation – N/A

4.4.12 Notifications and Tasks – N/A

4.4.13 Other – N/A

4.5 Generate MMA Reports

4.5.1 Design Description

4.5.2 Functional Output

4.5.3 Design Details

4.5.4 Screen Flow – N/A

MMRP CGIS Project ADD Page 14 of 203

4.5.5 Screen Mockup – N/A

4.5.6 Business Rules – N/A

4.5.7 User Roles – N/A

4.5.8 Data Fields – N/A

4.5.9 Links – Navigation – N/A

4.5.10 Links – Functions/Actions – N/A

4.5.11 Validation – N/A

4.5.12 Notifications and Tasks – N/A

4.5.13 Other – N/A

5 Technical Design

5.1 Common Technical Artifacts

5.1.1 Sequence Diagram

5.1.2 Events - N/A

5.1.3 Event Class Details - N/A

5.1.4 Domain Definitions

5.1.5 Code Tables

5.1.6 Code Table Details

5.1.7 Messages

5.1.8 Message Detailed Description

5.1.9 DMX

5.1.10 Security

5.1.11 Security Details

5.1.12 Model

5.1.13 Interfaces - N/A

5.1.14 Façades

5.1.15 Entity Layer

MMRP CGIS Project ADD Page 15 of 203

5.1.16 Service Layer

5.1.17 POD Definitions - N/A

5.1.18 Java Script Changes - N/A

5.1.19 CSS Changes - N/A

5.1.20 Global Configuration Changes - N/A

5.1.21 Wizard Changes - N/A

5.1.22 Menu Details – N/A

5.1.23 Evidence Configuration Changes – N/A

5.1.24 Renderers – N/A

5.1.25 Keywords (Hover Values) – N/A

5.1.26 Help Content – N/A

5.1.27 Links – Navigation – N/A

5.1.28 Links – Functions/Actions – N/A

5.1.29 Validation – N/A

5.1.30 Workflow – N/A

5.1.31 Web Services – N/A

5.1.32 Java Classes – N/A

5.1.33 Task and Work Queues – N/A

5.1.34 Reports

5.1.35 Unit Testing Scenarios

5.1.36 Cúram Unit Testing Scenarios

5.1.37 ESB Unit Testing Scenarios – N/A

5.1.38 Data Retention – N/A

5.1.39 Persistence Requirements – N/A

5.1.40 Backup Requirements – N/A

MMRP CGIS Project ADD Page 16 of 203

5.1.41 Archiving and Purging Requirements – N/A

5.1.42 Data Validation Checks – N/A

5.1.43 Security Considerations – N/A

5.1.44 Event Sequence Diagram – N/A

5.1.45 Coding Specifications – N/A

5.1.46 Table Names – N/A

5.1.47 Cúram Batch Component Technical Design

5.1.48 Batch Methods – N/A

5.1.49 Entity Classes – N/A

5.1.50 Entity Methods – N/A

5.1.51 Input/ Output Structs – N/A

5.1.52 Input/ Output Attributes – N/A

5.1.53 Tehcnical Dependencies – N/A

5.1.54 5.5.54 Source-to-Target Mapping – N/A

5.1.55 System Properties – N/A

5.1.56 Page Parameter Details

5.1.57 Links/Action Controls

5.1.58 Lists/ Inline Page Details – N/A

5.1.59 Cluster Details – N/A

5.1.60 UIM Configuration Changes

5.1.61 Server Interface Details

5.1.62 Other - N/A

5.2 ESB Development

5.2.1 Outbound - N/A

5.2.2 Inbound

MMRP CGIS Project ADD Page 17 of 203

5.2.3 Supporting Details: Record Layout

5.2.4 ESB Operational Platform

5.3 Rules Development - N/A

5.3.1 Rules - <Rules Area 1> -N/A

5.3.2 Table of Values - N/A

5.4 Batch Development

5.4.1 Batch Overview

5.4.2 Functional Summary

5.4.3 Batch Specifications

5.4.4 Data Retention - N/A

5.4.5 Batch Classes

5.4.6 Batch Methods

5.4.7 Other Methods

5.4.8 Table Names

5.4.9 Input Table Names

5.4.10 Output Table Names

5.4.11 Entity Classes

5.4.12 Entity Methods

5.4.13 Input/ Output Structs

5.4.14 Input / Output Attributes

5.4.15 System Properties

5.4.16 Code Tables

5.4.17 Overview

5.4.18 Message Files

5.4.19 Messages

MMRP CGIS Project ADD Page 18 of 203

5.5 Non-Functional Requirements – N/A

5.5.1 Accessibility – N/A

5.5.2 Availability – N/A

5.5.3 Development Resource – N/A

5.5.4 Evolution – N/A

5.5.5 Globalization – N/A

6 Integration Points/Dependencies

7 Use Cases

7.1 Caseworker Views Information Received from CMS

7.2 Helpdesk, MIM users updates the Medicare Part A, B

7.3 Caseworker works on the DHEC Report

7.4 Caseworker works on the Task Created due to Name Mis-matched in CMS and Cúram

8 Appendices

Appendix A: Open Action Items

8.1.1 Appendix B: Out of Scope Requirements – N/A

8.1.2 Appendix C: Comment/Resolution Log – N/A

8.1.3 Appendix D: Approval History

8.1.4 Appendix E: Data Elements to be Displayed on the Interface Tab for MMA . 187

8.1.5 Appendix F: Notice of Recommendation

8.1.6 Appendix G: Scenario Spreadsheet

8.1.7 Appendix H: Exception Report Mock-ups

MMRP CGIS Project ADD Page 19 of 203

1 Introduction

1.1 Background

The Centers for Medicare and Medicaid Services (CMS) requires state Medicaid agencies to submit files at least monthly to CMS to identify all people dually enrolled in both Medicare and

Medicaid, also known as dual eligible beneficiaries.

MMRP will be sending files daily and monthly via the MMIS system to CMS. The CMS response will be processed by MEDS and CGIS system.

1.2 Purpose

The purpose of this document is to define the processing of the daily/monthly inbound MMA file by CGIS. The file returned by CMS goes through a number of steps. The document covers the processing for the inbound response in detail.

The document is primarily for the business analysts, Subject Matter Experts (SMEs) , developers, testers, architects, and training team members working on the MMA track.

1.3 Scope

MMIS system currently generates the outbound daily and monthly files. MMIS will continue to generate the outbound files. The file for PCAT 48,50, 52 will be generated as per the CGIS30

MMIS Interface project design and MMIS system will merge the file from MEDS and CGIS. CGIS will not be generating the outbound MMA file. CGIS will be processing the daily/monthly inbound files. The generation of outbound files is not in the scope of this document. The processing of the inbound files will be covered in the document.

1.4 Key References

Document Name Location

MMRP CGIS MMA Interface BRD MMRP CGIS MMA Interface BRD

MMRP CGIS GLOBAL RULE ADD MMRP CGIS 25 ABD program Rules ADD

MMRP CGIS MMIS Interface ADD MMRP CGIS30 MMIS Interface ADD

MMA CMS File Layout MMA CMS File Layout

MMA Scenario spreadsheet MMA Scenario spreadsheet

1.5 Definitions and Acronyms

Term Meaning

CMS Centers for Medicare and Medicaid Services https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%20MMA%20Interface%20BRD.docx?d=w1198272cf58b40c389a8ba4b0d4cc753&csf=1&web=1&e=AFd66Z https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20-%20CGIS%20Global%20Program%20Rules%20ADD%20-%20ABD.docx?d=wa8697aa0632f4d18bc42f1e1afecb1f9&csf=1&web=1&e=xNa6rg https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS30%20MMIS%20Interface%20ADD.docx?d=w86849857938e46c79ee178a44fba8702&csf=1&web=1&e=KYT1e2 https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMA_CMS_File_Layout_062017.xlsx?d=w3f90ffd6ad1f4317ba548f00da84a9b2&csf=1&web=1&e=YjpFiH https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMA%20Scenarios%20Spreadsheet_V2.0.xlsx?d=wd95803bb095141698caefd4919a76945&csf=1&web=1&e=CmJpgq

MMRP CGIS Project ADD Page 20 of 203

Term Meaning

Current DET record Current month dual eligibility record

Daily MMA file Incremental file providing updates for changes in dual Iseligibility status, including additions, deletions, and changes.

DET record The record is an enrollment detail record (DET) for a known dual eligible or future Medicaid eligible.

Full dual eligible Beneficiaries in any of the following eligibility categories;

Medicare, QMB and Full Medicaid.

Medicare, full Medicaid.

Medicare and Full Medicaid.

Future DET record Medicare beneficiaries identified as eligible for Medicaid benefits one month into the future.

HCBS Home and Community Based Services

Institutional status H: Individual is receiving home and community-based services at any period during the month.

H: may also be used for persons receiving services under a waiver.

N: Individual is not institutionalized in a nursing facility, intermediate care facility or inpatient psychiatric hospital for the entire span of eligibility for month.

Y: Individual is institutionalized in a nursing facility, intermediate care facility or inpatient psychiatric hospital for the entire span of eligibility for month.

LIS Low-Income Subsidy

LIS records Low-income subsidy applications processed by the state.

Note: SC does not process LIS applications currently.

MA-PD Medicare Advantage Prescription Drug Plan

MBI Medicare Beneficiary Identifier

MCN Medicare Claim Number

Medicare Part A Hospital Insurance

Medicare Part B Medical Insurance

Medicare Part C Medicare Advantage Plans (MA Plans)

Medicare Part D Prescription Drug Coverage or PDP

MIM Member Information Management (SCDHHS work-group)

MMA Medicare Modernization Act

MMIS Medicaid Management Information System

Monthly MMA file Bulk file inclusive of all current DET records, retro DET records and PROspective records.

MMRP CGIS Project ADD Page 21 of 203

Term Meaning

Partial dual eligible Beneficiaries in any of the following eligibility categories;

Medicare and QMB only.

Medicare and SLMB only.

Medicare and QDWI.

Medicare and QI.

Note: To be eligible as QMB, SLMB, QDWI or QI, Medicare Part A eligibility is a requirement.

PDP Prescription Drug Plan

Potential dual eligible “PROspective” or PRO records

Individuals in the state Medicaid program who are not known to be full dual-eligible(s) but are Medicaid eligible approaching an age (64 and seven months or older in the reporting month) or disability status that is likely to lead to a future determination of full dual eligibility, or there exists a Medicare number in the system but no information on Medicare enrollment.

QDWI Qualified Disabled Working Individual

QI Qualifying Individual

QMB Qualified Medicare Beneficiary

Retro DET record Retro month dual eligibility record

RSP Recipient Special Programs

RSP Indicator The RSP codes for HCBS are:

AUTS: Autism Spectrum Disorder - State Plan Service.

AUTW: Autism Waiver.

CLTC: Elderly Disabled Waiver.

CSWE: Community Supports Waiver – Established.

CSWN: Community Supports Waiver – New.

DMRE: DMR Waiver/Established.

HIVA: CLTC HIV AIDS.

HSCE: Head & Spinal Cord Waiver Established.

HSCN: Head & Spinal Cord Waiver New.

MCSC: Pace.

VENT: CLTC Ventilator Dependent Waiver.

Note: Additional RSP codes could be added as applicable for

HCBS.

SLMB Specified Low-Income Medicare Beneficiaries

SPD State Phase-Down

1.6 Key Assumptions

1. MMIS system will continue to generate the outbound daily/monthly files.

2. Existing MMIS system processes will be followed, if an incoming file fails validations. Cúram will provide a report, and state will contact CMS outside of the system to get the right file. It’s the process (contact CMS and getting the right file) which state follows currently when a file fails validation.

MMRP CGIS Project ADD Page 22 of 203

3. Existing MMIS processes will be followed for resending an outbound file to CMS.

4. PCAT 48,50,52 file will be generated by the CGIS30 MMIS Interface. Please see the ADD for the CGIS30 MMIS interface for the details.

5. MMIS system will be able to use the file generated by CGIS for PCATs 48,50, 52.

6. MMIS will send the daily/monthly files to CMS

7. MMIS job will copy of the inbound file for CGIS use.

8. The same SSN may not occur more than once in one Response file.

9. Any changes to the MMA functionality may have major impacts on the processing of other interfaces that are dependent on this interface.

10. ESB is responsible for performing all validations before storing the record data to Cúram tables.

11. All the batch reports generated will be in excel format.

2 Conceptual Flows

The flows captured within this section provide a high-level overview of the processes. Please refer to the functional section for detailed requirements.

2.1 MMA Outbound File Generation Conceptual Flow

MMA Outbound File Generation

M M

IS

C u ra m C

M S

Start 01 - Daily MMIS File +

Daily PCAT 48,52 File

02 – Generate

Outbound

MMA File

03 - File Delivered to

CMS

Connect Direct

MMRP CGIS Project ADD Page 23 of 203

2.1.1 MMA Outbound File Generation Conceptual Flow

Narrative

# Task/Process Task ID Narration

1 Daily MMIS File Daily PCAT 48, 52

01 CGIS30 MMIS interface from CGIS to MMIS will deliver the daily MMIS file, and daily PCAT 48,50, 52 file.

2 Generate Outbound MMA File

02 Existing MMIS process will continue to generate the daily/monthly outbound file.

3 File Delivered to CMS 03 Using Connect Direct File is delivered to CMS for processing.

2.2 Inbound File from CMS Conceptual Flow

MMRP CGIS Project ADD Page 24 of 203

Inbound File from CMS C

M S

M M

IS

E S B

C u ra m

Start 1 CMS Generates Response File

Incoming File

Connect Direct

4 Valid File ?

2 Job Copies File for

MEDs , CGIS

3 Pick & Validate 6 Load to Database

Yes

5 File Rejected

No

8 Process one record at a time

10 Search

Person in Curam

13 Associate

Person to inbound

Data

B

B

Yes

11 Found in Curam?

12 Exists in

MEDS Rpt

NO

15 Create Tasks where

Conditions Met

14 Update

Evidences, if required

End

A

A 7 File Failure

Report

16 Generate

Notice where

Conditions Met

9 CMS Field

Failure Rpt

MMRP CGIS Project ADD Page 25 of 203

2.2.1 Inbound File from CMS Narrative

# Task/Process Task

ID

Narration

1 CMS Generates Response File 1 CMS generates a response file and places it on MMIS system using the Connect Direct.

2 Job Copies File for MEDS, CGIS 2 A MMIS job copies the file for MEDS. The job will be modified to make a copy for the CGIS.

3 Pick & Validate 3 ESB layer picks up the file(s) received from CMS and run basic structural validations on the file(s).

4 Valid File 4 Based on the results of structural validations, it is determined file is valid or invalid.

5 File Rejected 5 A file will be rejected, if one or more structural validations failed.

6 File Failure Report 7 The file(s) which failed file level validations are listed on this report.

7 Load to Database 6 Data from file(s) loaded into database only if all the files pass file level validations.

8 Process one record at a time. 8 Batch process reads the unprocessed records from the database one at a time and process them.

9 Field Level Failure Report 9 The records which failed CMS field level validations printed into the report.

10 Search Person in Cúram 10 Search for the person using the Medicaid ID in Cúram.

Medicaid ID is part of the “State Medicaid Agency Identifier” field. In case no match found on Medicaid ID, search using SSN.

11 Found in Cúram? 11 Determine if person exists in Cúram, if found in Cúram go to 13 else go to 12.

12 Exists in MEDS 12 Member not found in Cúram will be printed into the Exists MEDS report.

13 Associate Person to Inbound Data

13 Associate the inbound data in the database with the person.

14 Update Evidence if required 14 Update the evidences if required.

15 Create Tasks where Conditions Met

15 Create task for the case worker where certain conditions met.

16 Generate Notice where Conditions Met

16 Generate the Medicare notice where conditions met.

MMRP CGIS Project ADD Page 26 of 203

3 Requirements Matrix

The mapping from business requirement to functional requirement is documented in the MMA

RTM.

3.1 Requirement Modifications - N/A

This section will document any subsequent changes to the RTM that may later be required as discovered through development, test execution, bug fix develop or training activities.

Note: This section is used to highlight requirement changes, changes required to be addressed in by this design will be included in the Function Section as well as the RTM in Jira.

Requirement

ID

Business Rule ID

Description System Feature

Date Updated

In Scope (Yes or No)

N/A https://cuihhsiutl10.clemson.edu/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS#262&MMA%20RTM&true https://cuihhsiutl10.clemson.edu/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS#262&MMA%20RTM&true

MMRP CGIS Project ADD Page 27 of 203

4 Functions

This section describes the detailed functionality of the system. Functionality of the system is covered in multiple user stories/sections below. A daily and monthly outbound file are generated by the MMIS and sent to CMS. The response coming back from CMS will be provided to MEDS and CGIS for processing the records. The data brought in by the inbound file will be processed and saved.

4.1 Generate Outbound MMA Enrollment File

MMIS system generates the outbound files, and it will continue to generate the outbound files.

4.1.1 Design Description

Currently MMIS is generating the outbound MMA daily/monthly enrollment files, based on the data received from MEDS and HCR. CGIS will also feed the data to MMIS on daily basis using the data interface between CGIS and MMIS. MMIS will continue to generate the outbound files.

4.1.2 Functional Output

1. Cúram system sends daily updates to the MMIS (MMIS data interface).

2. PCAT 48,50,52 file will be generated by the CGIS30 MMIS Interface. Please see the ADD for the CGIS30 MMIS interface for the details.

3. MMIS system generates the outbound file and send it to CMS.

4.1.3 Design Details

MMA_REQ.1.1: The MMA outbound files (daily/monthly) will be generated by the existing

MMIS system. CGIS will use the CGIS30 MMIS Interface to send information daily to MMIS

System. MMIS system will generate and sends the outbound daily/monthly files. The additional file for PCATs 48,50,52 required by MMIS system will be generated and send by the CGIS30

MMIS interface in CGIS.

Note: Although the file for PCAT 48,50,52 generated by CGIS30 data interface, it should be tested with the MMA interface as it is required to generate the outbound file from MMIS.

Note: Confirmed with Clemson on the 11/27 call. They want PCAT 48, 50, 52 MIS7000 to be delivered along the other files at the same time.

MMRP CGIS Project ADD Page 28 of 203

4.1.4 Screen Flow – N/A

4.1.5 Screen Mockup – N/A

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validation – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Validate the Inbound MMA File

ESB layer runs basic structural validations on the incoming file.

4.2.1 Design Description

CMS drops the response file on MMIS. An existing MMIS job copies the file to a specific location, from where MEDS picks up and process the file. The job will be modified to create a copy for the

CGIS system. The file will be copied onto a specific location of HLQ and will be made available to ESB layer of CGIS, ESB will run the validation on the file per the Release 1 Interface Data

Elements Cúram Validations spreadsheet. The files passed basic validation listed below will be loaded to database. The details of the files failed validation will be on a report, and someone from state team will have to contact CMS to resolve the issue with the file. The report will be placed on the SharePHI folder.

4.2.2 Functional Output

1. CMS copies the file to MMIS.

2. CMS initiates a job at MMIS to copy the file.

3. MMIS copies the file for CGIS at the specified location on the HLQ.

4. CGIS validates the file.

https://schhs.sharepoint.com/:x:/r/sites/1211207/_layouts/15/Doc.aspx?sourcedoc=%7B837BBD13-0751-4F4A-8BA8-759D474E7B96%7D&file=Release1_Inteface_Data_Elements_Curam_Validations.xlsx&action=default&mobileredirect=true https://schhs.sharepoint.com/:x:/r/sites/1211207/_layouts/15/Doc.aspx?sourcedoc=%7B837BBD13-0751-4F4A-8BA8-759D474E7B96%7D&file=Release1_Inteface_Data_Elements_Curam_Validations.xlsx&action=default&mobileredirect=true

MMRP CGIS Project ADD Page 29 of 203

4.2.3 Design Details

MMA_REQ.2.1 ESB picks up the file copied by MMIS for CGIS. ESB runs the following validations to confirm the file returned by CMS is of the right format. These validations are to check the structure of the file, and if the file fails anyone of the following validations

(MMA_REQ.2.2 to MEM_REQ.2.5) it will be rejected and not loaded into the database. The details of the rejected file will be printed into a report, please see MMA_REQ.2.6 for details.

The high-level structure of the outbound and inbound file is shown below.

The Section 1 provides the high-level structure of the outbound file. The Section 2 provides the high-level structure of the inbound file.

The right most column “Record Start – End” represents the length of the record. The column “Sub

Section Start - End” represents the breakdown within the record. The “Sub Section Start - End” identifies the start and end of key sub sections within the record.

# Outbound, Inbound Sub Section Start- End

Record Start- End

1 Section 1 - State to CMS (outbound)

1.1 Org state to CMS header record 1-180

1.2 Org State to CMS detail record 1-180

1.3 Trailer Record 1-180

2 Section 2 - CMS to State (Inbound)

2.1 Header 1-4000

2.1.1 Actual Header from CMS 1-115

2.1.2 Org state to CMS header record (1.1) 116-295

2.1.3 Filler 296-4000

2.2 Detail 1-4000

2.2.1 Org State to CMS detail record (1.2) 1-180

2.2.2 CMS Error Return Codes 181-234

2.2.3 Medicare Data (CMS MBD) 229-3673

2.2.4 Filler 3674-4000

2.3 File Summary 1-4000

2.3.1 Summary Record 1-214

2.3.2 Filler 215-4000

MMRP CGIS Project ADD Page 30 of 203

# Outbound, Inbound Sub Section Start- End

Record Start- End

2.4 Monthly Summary 1-4000

2.4.1 Summary Record 1-84

2.4.2 Filler 85-4000

2.5 Trailer 1-4000

2.5.1 Actual Trailer from CMS 1-43

2.5.2 Org State to CMS Trailer Record (1.3) 44-223

2.5.2 Filler 224-4000

MMA_REQ.2.2 ESB layer validates header record, the very first record in the file received from

CMS should be a header record. The header record in the file is identified by the first three characters in the record. The first three characters should be ‘SRF’ for a valid header record. In case the first three characters are not ‘SRF’ reject the file and no further processing is required.

The reason for failure, which goes into report would be “Invalid header record.”.

MMA_REQ.2.3 ESB layer validates header record is followed by one or more detail record(s).

The header record should be followed by one or more of the detail records. The first 180 characters of the detail record are the actual record sent by state to CMS. The state detail record to CMS should start with one of the following values ‘DET’, ‘LIS’, ‘PRO’. In case no record found after header record with one of these values, it’s an invalid file and reject the file, and no further processing is required. The reason for failure, which goes into report would be “No detail record found in the file.”.

MMA_REQ.2.4 Validate the count in the header record matches with the number of actual DET records in the incoming file. Field “Total Number of Records” in the header record position 32-39 contains the total number of detail records starting with “DET’. The count in the header record field should match with the count of DET records in the detail section of the file. The file will be rejected, and no further processing will be done, if the file fails the validation. The reason for failure, which goes into report would be “Count of the detail records incorrect.”.

MMA_REQ.2.5 ESB layer validates the last record in the file is the trailer record. The trailer record starts with ‘TRL’. The first three characters should be ‘TRL’ for a valid trailer record. In case the first three characters are not ‘TRL’ reject the file and no further processing is required. The reason for failure, which goes into report would be “No trailer record found in the file.”.

MMA_REQ.2.6 The details of the file which failed any of the above validations will be included in the report (MMRPMMAX1000R13) and an email notification will be sent to the O&M point of contact (Action Item #816 added to cover the details in Operational Requirement section) .

Following details will be included in the “File Failure Report” for the file which failed processing.

1. Name of the file

MMRP CGIS Project ADD Page 31 of 203

2. Date file processed

3. Reason for Failure

System will not process any more MMA inbound file until the issue with the failing file is resolved.

This is to ensure files are processed in the order in which they received.

MMA_REQ.2.6.1 The file which failed validation(s) will be moved to archive folder with ” appended to the name.end of the file “_Invalid.

MMA_REQ.2.7 The file which passes the above-mentioned validations (MMA_REQ.2.2 to

MMA_REQ.2.5) is loaded into database. In case of multiple files received, ESB will process files in the ascending order determined by the timestamp in the file name. The file with the earliest timestamp in the file name, will be processed first. ESB will load the data into one big table along some transaction tables. Next ESB will validate and load the second file. ESB will stop processing if a file failed above mentioned validation, no more file will be validated and loaded until the issue with the failing file is resolved. It is to ensure the files received are processed in sequence.

MMA_REQ.2.8 Next ESB runs record level validations on the data loaded from the file(s) in the above step for the fields that are used in Cúram per the Release 1 Interface Data Elements Cúram

Validations spreadsheet. The record level validation verifies that data type and length of fields in the record and it is validated using the JRecord. It’s a record structure validation.

MMA_REQ.2.8.1A System will allow for following fields the corresponding additional values (all zeros or all nines) as valid values and will not reject the record.

• Column • Position • Validation

• Beneficiary Part A Entitlement Start Date

(Occurrence 1)

• 1152

• A valid date following the format

MMDDCCYY

or all zeros

• Beneficiary Part B Entitlement Start Date

(Occurrence 1)

• 1242

• A valid date following the format

MMDDCCYY

or all zeros

• Beneficiary Part A Entitlement End Date

(Occurrence 1)

• 1160

• A valid date following the format

MMDDCCYY

or all zeros or all nines

• Beneficiary Part B Entitlement End Date

(Occurrence 1)

• 1250 • A valid date following the format

MMDDCCYY

https://schhs.sharepoint.com/:x:/r/sites/1211207/_layouts/15/Doc.aspx?sourcedoc=%7B837BBD13-0751-4F4A-8BA8-759D474E7B96%7D&file=Release1_Inteface_Data_Elements_Curam_Validations.xlsx&action=default&mobileredirect=true https://schhs.sharepoint.com/:x:/r/sites/1211207/_layouts/15/Doc.aspx?sourcedoc=%7B837BBD13-0751-4F4A-8BA8-759D474E7B96%7D&file=Release1_Inteface_Data_Elements_Curam_Validations.xlsx&action=default&mobileredirect=true

MMRP CGIS Project ADD Page 32 of 203 or all zeros or all nines

MMA_REQ.2.8.1 A report (MMRPMMAX1000R14) is generated for the records which fail record level validations. Following fields are included in the report.

1. Name of the interface

2. Name of the inbound file

3. Date Processed

4. Medicaid ID , from State Medicaid Agency Identifier (36 -55)

5. SSN, State Medicaid Agency Identifier (36 -55)

6. Error reason, exception message from JRecord validation

MMA_REQ.2.9 The records which passes record level validations are copied into tables accessible to Cúram.

Next Cúram batch job processes the record received from the CMS and passed record level validations.

4.2.4 Screen Flow – N/A

4.2.5 Screen Mockup – N/A

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks – N/A

4.2.13 Other – N/A

MMRP CGIS Project ADD Page 33 of 203

4.3 Process Inbound MMA File

A batch process processes the records loaded into database from the inbound file(s) from the CMS.

4.3.1 Design Description

The inbound MMA file(s) from CMS was loaded into database tables by the ESB. Next a Cúram batch process, processes all the records one by one. Based on the response record batch will take the appropriate action.

4.3.2 Functional Output

1. The inbound MMA file(s) passed file level validations and loaded into database tables.

2. Cúram batch process processes all the records loaded into database tables from the inbound file(s) by the ESB.

3. Search the person using Medicaid ID or SSN.

4. System will create/update the Medicare benefit evidence information to the members IC case and activate the evidence.

5. Create task or generate notice where conditions met.

4.3.3 Design Details

MMA_REQ.3.1 UC4 triggers the Cúram batch job, once the file(s) loaded successfully. Batch process retrieves the unprocessed records from the database table and processes them one by one.

The processing order is determined using the Timestamp (date & time) included in the name of file and the Eligibility Month/Year (4 – 9) column.

MMA_REQ.3.1.1 Once the MMA file(s) are successfully loaded as mentioned in

MMA_REQ.2.7, UC4 will initiates the Cúram job MMA_REQ.3.1.

MMA_REQ.3.1.2 Cúram batch, starts processing all the unprocessed records from the staging table. Batch starts processing from the first record in the file with earliest timestamp in the file name.

MMA_REQ.3.1.3 Records are processed in the order they were loaded into the staging table. ESB loads the record into the staging table in the same order they are listed in the incoming file. In case if multiple records received for a person in the file(s), they all will be processed together.

MMA_REQ.3.1.3.1 System will use the State Medicaid Agency Identifier (36 – 55) field to determine if multiple records received for a person within file(s). Records with the same value for first 10 characters starting from position 36 will be used to determine if multiple records received for a person within file(s). The first 10 characters in the field represents the Medicaid ID.

Note: The grouping is being done on Medicaid ID value in the field State Medicaid Agency

Identifier and grouping can be across multiple files.

MMRP CGIS Project ADD Page 34 of 203

MMA_REQ.3.1.3.2 The batch process group all the unprocessed records for a given person within file(s) and order the records based on Eligibility Month/Year (4 – 9). The records in the group are sorted on Eligibility Month/Year in the ascending order.

Multiple records with the same Medicaid Agency Identifier on multiple response files processed at the same time, will be grouped together, sorted and processed such that the records from the oldest file are processed first followed by the records on the next file.

Example:

ESB loaded 2 MMA files. Cúram batch is processing the records loaded from the 2 MMA response files. File1 has 5 records for Medicaid ID 123 and File2 has 3 records for Medicaid ID 123. Then the batch will group 8 records such that the 5 records from file1 are processed first followed by the 3 records from file2. While processing the 5 records from file1, the batch will sort the records in ascending order of the eligibility month/year. Once the 5 records from File1 are processed, then the 3 records from File2 will be processed, sorted in ascending order of eligibility month/year.

MMA_REQ.3.1.3.3 System will continue processing from the next record in the order, if it encounters a runtime exception while processing a record. The record on which system encountered runtime exception will be include in the exception report defined in MM_REQ.3.1.4.

Example:

Following table show records from two files. The record for Person A is the first record in the first file “File 1”, followed by records for person B, C, D. Second file “File 2” has records for Person

B, D. “File 1” has oldest timestamp in the file name. When loading records from two files, ESB loaded records from “File 1” before “File 2”. There are multiple records received for Person B, and D.

File Name

State Medicaid Agency Identifier Medicaid ID (10 characters starting from position 36)

Elig Month Year

MMYYYY

Position 4 -9

Person

File 1 2121212121 042020 A

File 1 3131313132 012020 B

File 1 4141414143 042020 C

File 1 5151515154 032020 D

File 2 3131313132 032020 B

File 2 3131313132 022020 B

File 2 5151515154 042020 D

Table below shows the order in which Cúram batch will process the records from the two files.

MMRP CGIS Project ADD Page 35 of 203

File Name

State Medicaid Agency Identifier Medicaid ID (10 characters starting from position 36)

Elig Month Year

MMYYYY

Position 4 -9 Person

File 1 2121212121 042020 A

File 1 3131313132 012020 B

File 2 3131313132 022020 B

File 2 3131313132 032020 B

File 1 4141414143 042020 C

File 1 5151515154 032020 D

File 2 5151515154 042020 D

MMA_REQ.3.1.4 System will generate an exception report after processing all the records. The report will list all the records which encounter a runtime exception and processing for the record could not be completed. In case Cúram batch processed records from multiple files, the report will include all the records which could not be successfully processed due to runtime exception. The report will have two tabs, the first tab will provide the total count of the records included in the report. The second tab will list the individual records which encountered exception, see

MMA_REQ.3.1.4.1 for the columns included on the second tab. The name of report would be

MMA_Exception_Processing_Report_MMDDYYYY. “MMDDYYYY” part in the file name represents the date when report was generated. Report will be saved in a folder on SharePHI.

MMA_REQ.3.1.4.1 The report will include following columns for each record.

1. Record Unique Id (unique id from the table)

2. Social Security Number (27 – 35)

3. State Medicaid Agency Identifier (36 – 55)

4. Beneficiary First Name (56 – 67)

5. Beneficiary Last Name (68 – 87)

6. Eligibility Month/Year (4 -9)

7. Incoming Record (1-4000)

MMA_REQ.3.2 All records loaded by ESB will be processed by the batch process irrespective of the ‘Return Summary Code’ value.

MMA_REQ.3.2.1 The report (MMRPMMAX1000R15) will list only those records where one or more of 11 fields listed below have an invalid value. A record can have multiple invalid values, in that case record will be listed for each of the invalid field. The error report will include the following information from the inbound file.

1. Medicaid ID, State Medicaid Agency Identifier (36 -55) from inbound file.

MMRP CGIS Project ADD Page 36 of 203

2. Social Security Number, State Medicaid Agency Identifier (36 -55) from inbound file.

3. Beneficiary First Name, Beneficiary First Name(56 - 67) from inbound file.

4. Beneficiary Last Name, Beneficiary Last Name(68 - 87) from inbound file.

5. Beneficiary Gender Code, Beneficiary Gender Code(107 - 107) from inbound file.

6. Beneficiary Date of Birth, Beneficiary Date of Birth(108 - 115) from inbound file

7. Field Name Failed CMS Validation. It’s going to be one of the 11 fields listed in the table below. See column 2 “Field Name” in the table below.

8. Error Code, the 2-digit numeric code returned by CMS for the specific field. It’s going to be from the ‘Code and Description” column from the below table.

9. Error Description, the description given against the 2-digit code in the “Code and Description” column in the below table.

10. Record Return Summary Code, Record Return Summary Code (229 - 234) from inbound file.

MMA_REQ.3.2.1.1 The element on the report “Field Name Failed CMS Validation” will list the name of the field where value is not a valid value as mentioned in the table below. Starting from position 181 to 228, there are 24 two-character indicators. Each indicator represents one of the following 24 fields. E.g. indicator at 199-200 represents the value sent by state for “Error Return

Code for FPL Percentage Indicator” is valid or invalid. A value of ‘00’ or ‘99’ indicates value is valid, all other values indicates it’s an invalid value.

MMA_REQ.3.2.1.2 Out of the 24 fields mentioned below excluding LIS fields (12 to 23), names of all those fields where indicator value is other than the valid value mentioned in the table below will be printed under the “Field Name Failed CMS Validation”.

The LIS fields (12 to 23) are crossed out, they will not be included in the error report. MMRP does not use LIS data, and these fields (12 to 23) will not be included in the error report.

1. Error Return Code for Record Identification Code

2. Error Return Code for Eligibility Month/Year

3. Error Return Code for Eligibility Status

4. Error Return Code for Beneficiary Identifier

5. Error Return Code for Beneficiary Social Security Number

6. Error Return Code for Beneficiary Gender Code

7. Error Return Code for Beneficiary Date of Birth

8. Error Return Code for Dual Status Code

9. Error Return Code for FPL Percentage Indicator

10. Error Return Code for Drug Coverage Indicator

11. Error Return Code for Institutional Status Indicator

MMRP CGIS Project ADD Page 37 of 203

Field # Field Name Position Code and Description

1 Record Identification Code ERC

181–182 00: Value is valid 02: Value is not numeric 04: Date is unknown 05: Date is not equal to the File Create Month / File Create Year combination received in the Header record of the corresponding State-to-CMS Update file, when the Record Identification Code field is equal to ‘PRO’ 10: Future date 11: Month value is not within range of 01 to 12;

Note:

In order for the Detail record to be considered valid, the value in this field must be set to equal ‘00’.

2 Eligibility Month/Year

ERC

183–184 20: Year value is earlier than 2004 37: Date is earlier than 36 months prior to the File Create Month / File Create Year combination received in the Header record of the corresponding State-to-CMS Update file 99: The value is not scanned, when the Record Identification Code field is equal to ‘LIS’ Note:

In order for the Detail record to be considered valid, the value in this field must be set to equal ‘00’ or ‘99’.

3 Eligibility Status ERC 185–186 00: Value is valid.

01: Value is not in Valid Value Set.

06: Value is not equal to ‘Y’, when the Record Identification Code field is equal to ‘PRO’ 99: The value is not scanned, when the Record Identification Code field is equal to ‘LIS’ Note:

In order for the Detail record to be considered valid, the value in this field must be set to equal ‘00’ or ‘99’.

4 Beneficiary’s Identifier

ERC

187–188 00: Value is valid.

01: Value is not in Valid Value Set.

03: Value is empty.

Note:

In order for the Detail record to be considered valid, the value in this field must be set to equal one of the following:

- ‘00’; or

- Not ‘00’, when the Error Return Code for the…