PL0019 - CGIS31.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)

CGIS31 Medicare Savings Program

(MSP)

MMRP CGIS31 MSP ADD

Medicare Savings Program V3.0 Page 2 of 92

Version Log

Version Date Drafted by Role Description of Change

0.1 11/30/2018 Jim Bostick IBM Business Analyst Initial Draft

0.2 12/11/2018 Jim Bostick IBM Business Analyst Revisions from Initial walk-through

0.3 01/02/2019 Jim Bostick IBM Business Analyst Revisions per second walk-through

0.4 7/30/2019 WL Truesdale UAT Removed comments added to Question Template

1.0 Approved Version

1.1 10/9/2019 Tiffany Ortega IBM Functional Consultant

Mad the following updates per CR095:

1) Modified the note for

MSP.REQ.2.5.1

2) Added MSP.REQ.2.5.1.1

3) Added MSP.REQ.2.5.1.2

4) Modified the note for

MSP.REQ.3.8.2

5) Updated MSP.REQ.3.1.1.1

6) Updated MSP.REQ.2.1.1

7) Updated MSP.REQ.2.4

8) Updated Key Assumption #5

9) Updated Section 4.4.3 to strikethrough as the requirements are no longer valid

10) Updated Conceptual Flow 2.2

Person Search and Match

Processing and the associated

Narrative 2.2.1

11) Added Use Case 6.8

1.1 10/16/2019 Vamshi Vankadara

Developer

Made the following technical updates per CR095:

1) 5.5.12.1 - Removed the split file logic and added exception letter details for applicant with

MEDS eligibility.

1.1 10/21/2019 Margi Tripathi Business Analyst CR updates are reviewed & feedback is provided for functional requirements/UC.

Medicare Savings Program V3.0 Page 3 of 92

Version Date Drafted by Role Description of Change

1.2 10/21/2019 Tiffany Ortega IBM Functional Consultant

Responded to state comments.

1) Removed strikethrough for

Section 4.4.3.

2) Removed requirement

MSP.RPT.4.1 B

3) Updated MSP.REQ.2.1.1

4) Updated Use Case 6.8 to add the Alternate Flow

1.2 11/4/2019 Margi Tripathi Business Analyst Closed comments from round 1 review for CR095.

1.3 11/7/2019 Tiffany Ortega IBM Functional Consultant

Updated MSP.REQ.3.8 to replace “Income Support Application” with “Income Support case” to align with the

TDS.

1.3 12/18/2019 Margi Tripathi Business Analyst

CR095 changes are approved. This is with the understanding that a new doc-only CR would be opened to address remaining updates/open comments.

1.4 6/3/2020 Amir Iqbal Business Analyst

Updated for CR183 Following requirements added/updated

2.2.1 Person Search and Match

Processing Narrative #6

2.3.1 MSP Specific Processing Steps

#6

2.3.1 MSP Specific Processing Steps

#7

MSP.REQ.2.1.2

MSP.REQ.Screen.3.8 MSP.REQ.2.4 Inconclusive Match MSP.REQ.3.8.2 Note 3.b.ii MSP.REQ.3.8.2 Note 3.b.iv

1.5 6/4/2020 Vamshi Vankadara

Developer

Updated for CR183 TDS Details added for MSP_REQ_2.4.1 in TDS Section

5.1.1.6. MSP Prospect Person

Processing

1.6 6/6/2020 Tiffany Ortega IBM BA Lead

Updates per CR212:

MSP.REQ.1.3

Appendix E

1.6 6/15/2020 Margi Tripathi State Business Analyst

CR183 document updates approved

1.6 07/06/2020 Vijay Makam IBM Dev Lead Updated ESB Technical sections 5.3.1.3.5

5.3.1.3.1 for CR212

1.7 07/15/2020 Tiffany Ortega IBM BA Lead Updated Key Assumption #2 and MSP.REQ.3.3.2 per CR207

Medicare Savings Program V3.0 Page 4 of 92

Version Date Drafted by Role Description of Change

1.8 7/22/2020 Tiffany Ortega IBM BA Lead Completed spelling and grammar check/updates; updates the links in the Key References

1.9 8/7/2020 Amir Iqbal IBM BA

Corrected the reference in the

MSP.REQ.1.3

Corrected to file name for evidence mapping spreadsheet from MSP_Fields_To_EvidenceMapping_v2 To MSP_Fields_To_EvidenceMapping_v3 Appendix H, refers the evidence mapping file for validations

2.0 8/14/2020 Erin Coleman MMRP Process & Artifact Development Manager

Updated date, version number and watermark to reflect approval. Removed comments and accepted all track changes.

2.1 8/26/2020 Amir Iqbal IBM BA Updated for CR211 Requirement 3.8.2.b iv added the note.

2.2 8/28/2020 Vamshi Vankadara

IBM Developer

Updated for CR211 Added method getICForCoupleMSPApplication method to service layer section 5.1.16.1

2.3 9/29/2020 Amir Iqbal IBM BA

Updated for CR283 Added notes to following req

MSP.REQ.1.2

MSP.REQ.1.4

2.4 10/7/2020 Amir Iqbal IBM BA Updated for CR278

MSP.REQ.4.3

2.5 12/8/2020 Vamshi Vankadara

IBM Developer

Updated following for CR 309

5.1.16.1 Service Layer

updated method processCoupleMSPApplication with 4.1 updated method seachInboundRecordByConcernRoleID to use new entity method

5.1.50 Entity Methods

new method 'searchRecordsBySpouseConcernRoleID' details

5.1.51 Entity Input/output structs

5.1.52 Input/output attributes

2.6 12/11/2020 Tiffany Ortega IBM BA Lead

Updated the following requirements per

CR315:

MSP.REQ.4.1

MSP.REQ.4.2

MSP.REQ.4.3

MSP.REQ.4.4

MSP.REQ.4.5

2.7 1/27/2021 Amir Iqbal IBM BA

Updated following requirements per CR330

MSP.REQ.3.1.1.2

MSP.REQ.3.1.1.4

Appendix G https://team.scdhhs.gov/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MSP_Fields_To_EvidenceMapping_v2.xlsx https://team.scdhhs.gov/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MSP_Fields_To_EvidenceMapping_v2.xlsx

Medicare Savings Program V3.0 Page 5 of 92

Version Date Drafted by Role Description of Change

3.0 8/14/2020 Erin Coleman MMRP Process & Artifact Development Manager

Updated date, version number and watermark to reflect approval. Removed comments and accepted all track changes.

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.

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 / Reviewer Name

Third Review Date/ Reviewer Name

DDI Manager

Product Manager

Technical Lead

Business Analyst

Testing Manager

Subject Matter Expert

Documentation Specialist

MMRP Process & Artifact Development Manager

Technical Lead Sudheer Arimbra 9/2/2020 CR 211 no comments

SCDHHS Role First Review Date / Reviewer Name

Second Review Date / Reviewer Name

Third Review Date / Reviewer Name

Technical Lead 9/4/2020 Renjan Bhasi

CR211

9/8/2020 Renjan Bhasi

CR211

Medicare Savings Program V3.0 Page 6 of 92

IBM Approval Review Log

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.

Functional Design Section

Technical Design Section IBM Technical Design Approval Review – v3.0

Role Name Date Comments

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

CGIS Development Team Lead

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

Approvals

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 another round of Approvals.

Functional Design Section

IBM Functional Design Approval Review – v3.0

Role Name Date Comments

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

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

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

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

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

CGIS Development Team Lead

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

Medicare Savings Program V3.0 Page 7 of 92

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 Comments

SCDHHS DDI Manager Tim Cozine 4/7/2021 Approved V2.7 SCDHHS Product Manager Abhishek Sahu 4/7/2021 Approved V2.7 SCDHHS Technical Lead Renjan Bhasi

SCDHHS Business Analyst Joel Mudumala 4/6/2021 Approved (FDS) SCDHHS Process and Artifact Development Manager

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 Comments

SCDHHS Technical Lead Renjan Bhasi

Medicare Savings Program V3.0 Page 8 of 92

Table of Contents

Version Log

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 Inbound MSP Update Files Processing

2.1.1 Inbound MSP Update Files Processing Narrative

2.2 Person Search and Match Processing

2.2.1 Person Search and Match Processing Narrative

2.3 MSP Specific Processing

2.3.1 MSP Specific Processing Steps

2.4 MSP Addendum Processing

2.4.1 MSP Addendum Processing Steps

2.5 MSP Timer Expiry

2.5.1 MSP Timer Expiry Narration

3 Requirements Matrix

3.1 Requirement Modifications

4 Functions

4.1 Inbound MSP Update Files Processing

4.1.1 Design Description

4.1.2 Functional Output

4.1.3 Design Details

Medicare Savings Program V3.0 Page 9 of 92

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 Date Fields – N/A

4.1.9 Links - Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validations – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Person Search and Match Process

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 Date Fields – N/A

4.2.9 Links - Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validations – N/A

4.2.12 Notifications and Tasks

4.2.13 Other – N/A

4.3 MSP Application Processing

4.3.1 Design Description

4.3.2 Functional Output

Medicare Savings Program V3.0 Page 10 of 92

4.3.3 Design Details

4.3.4 Screen Flow – N/A

4.3.5 Screen Mockup

4.3.6 Business Rules – N/A

4.3.7 User Roles – N/A

4.3.8 Date Fields – N/A

4.3.9 Links - Navigation – N/A

4.3.10 Links – Functions/Actions – N/A

4.3.11 Validations – N/A

4.3.12 Notifications and Tasks

4.3.13 Other – N/A

4.4 MSP Daily Reports

4.4.1 Design Description

4.4.2 Functional Output

4.4.3 Design Details

4.4.4 Screen Flow – N/A

4.4.5 Screen Mockup – N/A

4.4.6 Business Rules – N/A

4.4.7 User Roles – N/A

4.4.8 Date Fields – N/A

4.4.9 Links - Navigation – N/A

4.4.10 Links – Functions/Actions – N/A

4.4.11 Validations – N/A

4.4.12 Notifications and Tasks – N/A

4.4.13 Other – N/A

5 Technical Design

5.1 Common Technical Artifacts

Medicare Savings Program V3.0 Page 11 of 92

5.1.1 Sequence Diagram

5.1.2 Events – N/A

5.1.3 Events Class Details – N/A

5.1.4 Domain Definitions – N/A

5.1.5 Code Tables

5.1.6 Code Table Details

5.1.7 Messages – N/A

5.1.8 Message Detailed Description – N/A

5.1.9 DMX

5.1.10 Security – N/A

5.1.11 Security Details – N/A

5.1.12 Model

5.1.13 Interfaces – N/A

5.1.14 Facades

5.1.15 Entity Layer

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

Medicare Savings Program V3.0 Page 12 of 92

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 – N/A

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

5.1.40 Backup Requirements – N/A

5.1.41 Archiving and Purging Requirements – N/A

5.1.42 Data Validation Checks

5.1.43 Security Considerations – N/A

5.1.44 Event Sequence Diagram – N/A

5.1.45 Coding Specifications

5.1.46 Table Names – N/A

5.1.47 Cúram Batch Component Technical Design – N/A

5.1.48 Batch Methods – N/A

5.1.49 Entity Classes

5.1.50 Entity Methods

5.1.51 Input/ Output Structs

5.1.52 Input/ Output Attributes

5.1.53 Technical Dependencies – N/A

5.1.54 Source-to-Target Mapping – N/A

Medicare Savings Program V3.0 Page 13 of 92

5.1.55 System Properties

5.1.56 Page Parameters

5.1.57 Links/ Action Controls – N/A

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.2 ESB Development

5.2.1 Outbound – N/A

5.2.2 Inbound – N/A

5.2.3 Supporting Details: Record Layout

5.2.4 ESB Operational - N/A

5.3 Rules Development – N/A

5.3.1 Rules (Rules Area) – N/A

5.3.2 Table of Values – N/A

5.4 Batch Development

5.4.1 Batch Overview (MSP Batch Detailed Design)

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 Code Tables

5.5 Non-Functional Requirements

5.5.1 Accessibility - N/A

5.5.2 Availability – N/A

5.5.3 Development Resource – N/A

Medicare Savings Program V3.0 Page 14 of 92

5.5.4 Evolution – N/A

5.5.5 Globalization -N/A

6 Integration Points/Dependencies – N/A

7 Use Cases

7.1 Spouse Handling

7.2 MSP applicant already has full Medicaid in Cúram

7.3 MSP applicant eligible; Spouse already has Medicaid

7.4 Applicant and Spouse Fail Eligibility (income)

7.5 MSP Addendum not returned

7.6 MSP Applicant receives Medicaid Coverage

7.7 Caseworker to reopen case

7.8 MSP Addendum Received Before Timer Expires

8 Appendixes

8.1 Appendix A: Action Item Matrix

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

8.3 Appendix C: Comments/Resolution Log – N/A

8.4 Appendix D: Approval History

8.5 Appendix E: MSP File Layout

8.6 Appendix F: MSP File to Cúram Data Mapping

8.7 Appendix G: Exception Letter

8.8 Appendix H: Validations

8.9 Appendix I: Notice API/Template and OnBase Keywords

Medicare Savings Program V3.0 Page 15 of 92

1 Introduction

1.1 Background

Per the federal government’s Medicare Improvements for Patients and Providers Act of 2008

(MIPPA), the Social Security Administration (SSA) must send all data electronically, for persons who have applied for Low Income Subsidy (LIS), to state Medicaid agencies to be processed for

Medicare Savings Programs.

1.2 Purpose

The purpose of this document is to define the process for ingesting data from SSA to deliver appropriate benefits to eligible applicants while reducing the amount of manual intervention needed by case workers.

The intended audiences for this document are:

• MMRP Subject Matter Experts (SMEs)

• MMRP Cúram – Business Analysts

• MMRP Cúram – Architecture team

• MMRP Cúram – Solution Developers

• MMRP Cúram – Testing Team

1.3 Scope

This document covers the processing of MSP documents from SSA within the Cúram application in the CGIS module. It includes Person Search for each applicant in Cúram and MEDS, Person registration where needed, application ingestion and the assignment of eligibility based on standard system rules.

1.4 Key References

This section lists any key documents that might be helpful in understanding the detailed functionality. All referenced documents will be available in State SharePoint site and/or JIRA.

Document Name Location

MMRP CGIS MSP Interface BRD SharePoint Link

MMRP CGIS 31 MSP Interface ADD RTM SharePoint Link

MSP Manual 2009 SharePoint Link

Addendum SharePoint Link

MMRP CGIS 15 Integration with OnBase ADD SharePoint Link https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/CGIS31%20MSP%20Interface%20BRD.docx?d=we362431852ab42fa985933acf631318a&csf=1&web=1&e=K21Uy4 https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%2031%20MSP%20Interface%20ADD%20RTM.xlsx?d=w40c60c579a6a4d63af29cb332926c0a8&csf=1&web=1&e=FQYbfZ https://schhs.sharepoint.com/:b:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MSP%20Manual_2009.pdf?csf=1&web=1&e=XZzZkS https://schhs.sharepoint.com/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/FM%203306%20MSP%20Addendum_CGIS.pdf https://team.scdhhs.gov/pmo/ProjectRepository/1211207/_layouts/xlviewer.aspx?id=/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Document%20Types%20-%20Keywords.xlsx&Source=https%3A%2F%2Fteam%2Escdhhs%2Egov%2Fpmo%2FProjectRepository%2F1211207%2FCGIS%2520Business%2520Requirements%2520and%2520Design%2520Documents%2FForms%2FAllItems%2Easpx%3FInitialTabId%3DRibbon%252EDocument%26VisibilityContext%3DWSSTabPersistence%26GroupString%3D%253B%2523CGIS15%2520Integration%2520with%2520OnBase%253B%2523Reference%253B%2523%26IsGroupRender%3DTRUE&DefaultItemOpen=1&DefaultItemOpen=1

Medicare Savings Program V3.0 Page 16 of 92

Document Name Location

MMRP CGIS 23 Global Notices ADD SharePoint Link

SCDHHS CGIS Notices Master List SharePoint Link

MMRP CGIS 24 Global Program Alignment ADD SharePoint Link

CGIS Program Rules – Shared Processes ADD SharePoint Link

CGIS Medicaid Programs List SharePoint Link

MMRP CGIS Interface DDD TT43828 MSP SharePoint Link

1.5 Definitions and Acronyms

Term Meaning

ABD Aged, Blind, and Disabled

BRD Business Requirements Document

CGIS Cúram Global Income Support

CMS Centers for Medicare and Medicaid Services

CW Case Worker

DHHS Department of Health and Human Services

DSS Department of Social Services

EDD Eligibility Decision Details

ESB Enterprise Service Bus

FPL Federal Poverty Limit

IC Integrated Case

LIS Low Income Subsidy

MCN Medicare Claim Number

MIPPA Medicare Improvements for Patients and Providers Act of 2008

MMIS Medicaid Management Information System

MMRP Member Management Replacement Program

MSP Medicare Savings Program which includes QMB, SLMB, QI, QDWI and ABD-SC

OnBase Reference Number

A unique number given to each addendum when a case is created in Cúram.

PCAT Payment Category

QDWI Qualified Disabled Working Individual

QI Qualifying Individual

QMB Qualified Medicare Beneficiary Program

RRB Railroad Retirement Board https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS23%20Global%20Notices%20ADD%20v1.13.docx?d=w928907f6b6d94db494c7413b04d1c3f7&csf=1&web=1&e=nMjsIX https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/SCDHHS%20CGIS%20Notices%20Master%20List.xlsx?d=w6cf33a678e8842a58093e7b0b8f54f8a&csf=1&web=1&e=BZ2mA7 https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS24%20Global%20Program%20Alignment%20ADD%20v1.9.docx?d=wea43097c0b5243f995d6410b220d2ded&csf=1&web=1&e=fwZHcF https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS25%20-%20Program%20Rules%20-%20Shared%20Processes%20ADD%20v1.8.docx?d=wd28ac11fa5864eafbc4557f0d5d00d8d&csf=1&web=1&e=uLtfkX https://schhs.sharepoint.com/:x:/r/sites/1211207/_layouts/15/Doc.aspx?sourcedoc=%7BCDF9EE56-199E-4017-B5F6-318928BBFEAF%7D&file=MMRP%20-%20CGIS%20Medicaid%20Programs%20List.xlsx&action=default&mobileredirect=true&DefaultItemOpen=1 https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%20Interface%20DDD%20TT%2043828%20MSP.docx?d=wccc1fe04fc554fa09f4fce43c5090945&csf=1&web=1&e=nV45bC

Medicare Savings Program V3.0 Page 17 of 92

Term Meaning

SLMB Specified Low-Income Medicare Beneficiary

SSA Social Security Administration

SSN Social Security Number

VA Veterans Affair

WQ Work Queue

1.6 Key Assumptions

This document assumes the following:

1. SSA will send a file daily, Monday through Friday, except for federal holidays to

SCDHHS.

a. No file will be transmitted if there are no applications processed by SSA for a specific day.

b. The file will contain a detailed record for each LIS applicant.

2. A unique OnBase Reference Number will be generated for each MSP applicant until

PROD-7430 is implemented.

3. The present interaction between Cúram and OnBase will continue.

4. The MSP data to Evidence mapping is started in Appendix B. This is a technical effort to be continued in the TDS phase.

5. When MEDS is sunset, any interactions with the MEDS will need to be addressed differently. Interactions including but not limited to searching for persons in MEDS, checking eligibility in MEDS will no longer be needed.

Medicare Savings Program V3.0 Page 18 of 92

2 Conceptual Flows The flows captured within this section provide a high-level overview of the process. Please refer to the Section “Function” for detailed requirements.

2.1 Inbound MSP Update Files Processing

2.1.1 Inbound MSP Update Files Processing Narrative

# Action # Action Label Narration

1 10 DSS receives MSP files from SSA

The Department of Social Services (DSS) receives the MSP files from SSA.

Medicare Savings Program V3.0 Page 19 of 92

2 11

MEDS receives MSP files DSS

MSP files will be received by MEDS through the existing communication channel (Cyberfusion). And then MEDS will place the file in the HLQ and will not process the original file.

3 1 ESB Receives MSP File(s)

The Enterprise Service Bus (ESB) receives the MSP File(s) from the mainframe HLQ location where MEDS places the MSP files.

4 2 File Validation File format and header validation will be triggered by ESB job.

5 3 Manually retry the MSP file pull

If the file validation fails, then the ESB will retry the pull manually. If the file still fails, the following manual actions will be performed:

Report of file validation to be communicated to DSS to ensure that it’s not an issue between DSS and Cúram.

Next step would be to contact SSA via DSS communication.

6 4 Store MSP Records in ESB Tables

After successful file validation, records from the file will be inserted into the MSP ESB tables.

7 5 MSP Files disposed securely

Once the master data is stored successfully, MSP physical files need to be securely disposed from the system.

8 6 Record level validations ESB will perform record level validation to verify that records match the Layout outlined as per Appendix.

9 7 Validation Successful At this step, system checks whether record level validation passes.

10 8 Generate Exception Report

If at the Task ID 7, system determines that record validation failed then, that record will be queued for exception report generation.

11 9 System Processing Once the records are successfully validated then it will be sent to Cúram for further system processing.

2.2 Person Search and Match Processing

Medicare Savings Program V3.0 Page 20 of 92

2.2.1 Person Search and Match Processing Narrative

1 1 MEDS Person Check MEDS person Check is run to see if the person exists in MEDS and has eligibility for greater than 45 days.

2 2 MEDS Person exists with 45+ days of eligibility remaining?

If the applicant exists in MEDS and has 45+ days of eligibility, then task 3 will be invoked (MEDS split file generation) and MEDS will handle the person.

If the applicant is not found in MEDS or does not have 45+ days of eligibility in MEDS, then the system proceeds to task 5 for Cúram Person Match.

3 3 Send MSP Exception Letter to Print Queue

If the person is in MEDS with 45+ days of eligibility remaining the MSP Exception Letter will be sent to the Print Queue. Also, a copy would be stored in OnBase with MEDS Household ID Details.

4 4 Cúram Person Match Cúram Person Match is run on each applicant in the MSP file. SSN is used as the parameter for a conclusive match. Inconclusive match will use first name, last name and date of birth as parameters.

5 5 Person Match Found? There are 3 branch points based on the results from Person Match:

Medicare Savings Program V3.0 Page 21 of 92

# Action # Action Label Narration

1. Unique Person Match (A Conclusive match based on SSN provided in MSP file).

2. Prospect Person Match (Inconclusive match based on first name, last name, date of birth)

No Person Match (No records were found in Cúram for the applicant.

6 6 Create Prospect Prospect Person is created per the existing Person Search and Match.

7 7 Generate Task to Register Person

When the system will register Prospect Person, a task will be generated and assigned to MIM work queue for the case workers to manually register the prospect person as person.

8 8 Person Registered in Cúram

The applicant is systematically registered based on mapping key fields from the input file to the associated Person evidence fields.

9 9 MSP specific processing The MSP specific eligibility processing sub-flow will handle potential eligibility checks to decide on sending out the addendum for further processing.

2.3 MSP Specific Processing

Medicare Savings Program V3.0 Page 22 of 92

2.3.1 MSP Specific Processing Steps

1 1 Check applicant Medicaid Benefits in both Cúram and

MEDS

Applicant Medicaid Benefits will be checked in Cúram and MEDS (through MEC call).

2 2 Receiving Medicaid? System branches based on current Medicaid coverage of the user. If they have Medicaid, the applicant will not be eligible for MSP. Otherwise, the system will proceed with other checks.

3 3 Update OnBase with exception letter

The current applicant has Medicaid. An exception letter is uploaded to OnBase.

4 4 exception letter sent to Applicant

The current applicant has Medicaid. An exception letter is sent to the applicant to the address stored in the Cúram system.

Medicare Savings Program V3.0 Page 23 of 92

2.4 MSP Addendum Processing

5 10 Create MSP Application Application is created from data mapped from the MSP file to the application.

6 5 Check against 150% FPL. The current applicant does not have Medicaid. The system proceeds to Check the applicant against 150% FPL.

For an applicant with a spouse, both the applicant and spouse combined income will be checked against FPL limits.

7 6

Greater than 150% FPL? This is the branching point based on the check against 150% FPL

• When less than or equal to 150%, the addendum will be sent out (task 8)

• Application is denied when applicant exceeds 150% (task 7)

8 7 Application is denied The FPL Limits are exceeded, and the applicant is not eligible for MSP.

Therefore, the application is denied.

9 8 Send Addendum to Applicant Because the applicant is potentially eligible, the addendum will be sent out.

10 9 Start Addendum Timer A 20-day timer is started. The applicant addendum should be returned within that time.

11 11 Update OnBase with Denial Notice

The Denial Notice sent out to the applicant is also stored in OnBase.

Medicare Savings Program V3.0 Page 24 of 92

2.4.1 MSP Addendum Processing Steps

1 10 Mail room indicates addendum is returned

When the applicant returns their addendum, the mail room provides indication and the addendum will be stored on OnBase, the timer will be stopped, and the system will create a task for the case worker to update the applicant information.

2 1 Timer is stopped The 20-day timer for the return of the Addendum is stopped.

3 2 System creates a task for the Case Worker

A standard task is created for a Case Worker to pick up.

4 3 Addendum is updated to OnBase

The Addendum is stored in OnBase.

5 4 Worker picks up a task A case worker picks up the task for updating applicant information.

Medicare Savings Program V3.0 Page 25 of 92

# Action # Action Label Narration

6 5 Worker updates Applicant information

The case worker updates applicant information.

7 6 CGIS income support case authorized

Evidences for the case are approved and the CGIS income support case is authorized.

8 7 Run Eligibility Rules Eligibility Rules are run. Alignment of dates between an applicant and spouse are ensured in this process.

9 8 Eligible applicants are provided MSP Eligibility Benefit

The eligibility rules will decide if the applicant is eligible for various benefits. As per standard processing, applicant will be provided notices about approvals and denials.

10 9 Notification This represents the notification received by the applicant during standard eligibility processing.

2.5 MSP Timer Expiry

Medicare Savings Program V3.0 Page 26 of 92

2.5.1 MSP Timer Expiry Narration

1 1 Initial Timer is expired The initial 20-day timer has expired

2 2 Application is Denied Because the initial 20-day timer has expired, the application is denied. This step includes sending out the denial notice as well as updating OnBase with the denial notice.

3 3 Update OnBase with Denial Notice

OnBase is updated with the denial notice.

4 4 Mail room indicates addendum is returned (late – after the 20-day timer had expired)

When the applicant returns their addendum, the mail room provides indication and the addendum will be stored on OnBase

Medicare Savings Program V3.0 Page 27 of 92

# Action # Action Label Narration

The system will additionally check to see if it falls into a timing window where the caseworker can reopen the case (between days 21 and 50). This check is done in task 5.

5 5 Addendum Received prior to 30 days deadline?

Worker may reopen the case when the addendum is returned within 30 days of the initial denial.

6 6 Addendum Updated to OnBase

The Addendum that was returned is sent to OnBase to be used by the case worker.

7 7 System Creates a task for the Case Worker

The applicant has returned the addendum within 30 days of the denial, a task is created to let the case worker re-open the application.

8 8 Case Worker re-opens Case

The Case Worker re-opens the application the application data is filled in and subsequently triggers the authorization processing.

Medicare Savings Program V3.0 Page 28 of 92

3 Requirements Matrix

This section provides the references to the Requirement Traceability Matrix (RTM.) The spreadsheet to upload the requirements to JIRA is stored on SCDHHS MMRP SharePoint as

MMRP CGIS 31 MSP Interface ADD RTM

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.

3.1 Requirement Modifications

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 document and JIRA.

Requirement

ID

Business Rule ID

Description System Feature

Date Updated

In Scope (Yes or No) https://team.scdhhs.gov/pmo/ProjectRepository/1211207/_layouts/xlviewer.aspx?id=/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%2031%20MSP%20Interface%20ADD%20RTM.xlsx&Source=https%3A%2F%2Fteam%2Escdhhs%2Egov%2Fpmo%2FProjectRepository%2F1211207%2FCGIS%2520Business%2520Requirements%2520and%2520Design%2520Documents%2FForms%2FAllItems%2Easpx%3FInitialTabId%3DRibbon%252EDocument%26VisibilityContext%3DWSSTabPersistence%26Paged%3DTRUE%26p%5FTrack%5Fx0020%5FName%3DCGIS23%2520Global%2520Notices%26p%5FStatus%3DIn%2520Progress%26p%5FFileLeafRef%3DNotices%2520Issue%2520Tracking%252exlsx%26p%5FID%3D169%26GroupString%3D%253b%2523CGIS23%2520Global%2520Notices%253b%2523In%2520Progress%253b%2523%26PageFirstRow%3D31%26IsGroupRender%3DTRUE&DefaultItemOpen=1&DefaultItemOpen=1

Medicare Savings Program V3.0 Page 29 of 92

4 Functions This section describes the detailed functionality of the system.

4.1 Inbound MSP Update Files Processing

4.1.1 Design Description

This story describes the system processing for the Inbound MSP Update Files from SSA that are sent via DSS. The daily MSP file contains records for each applicant applying for MSP.

4.1.2 Functional Output

• ESB receives the MSP Updates files from MEDS that originates from SSA.

• ESB performs file validation and generates the exception reports for the validation failures.

• Cúram ESB will store MSP File records into the MSP master table in the ESB database.

• MSP Update Files will be securely disposed (i.e. permanently deleted by OS secure-delete function) from the system.

4.1.3 Design Details

MSP.REQ.1 - Cúram ESB will receive the MSP Updates file(s), that are originally received by

MEDS through SSA/DSS Cyberfusion channel. Following actions will be performed by the system.

MSP.REQ.1.1 If file validation fails, ESB will retry the file download and re-trigger the file validation.

MSP.REQ.1.2 If the validation of the file fails twice, the system will insert the record in the error queue and at the end of the process the system will generate an exception report based on the failed records.

Note: This note is applicable to MSP.REQ.1.1 and MSP.REQ.1.2.

If the validation of the file fails, system will stop processing the file and UC4 will generate an email. System will not retry to download the file, system will not retrigger the file validation. There will be no exception report generated when a file fails the validation. These two requirements will be tested only as part of the error handling testing.

Note: Manual actions will be performed:

1. The file failure will be communicated to MEDS, as the primary point of contact.

Medicare Savings Program V3.0 Page 30 of 92

2. The report of file validation failure will be communicated to DSS to ensure that it’s not an issue between DSS and MEDS.

3. SSA will be contacted about the failure through the DSS established communication method.

MSP.REQ.1.3 Record level validation will be performed to ensure the records conform to the

MSP File Layout (refer to MSP_Fields_To_EvidenceMapping_v3.xlsx).

MSP.REQ.1.3.1: At the end of the record validation process (when all applicants have been validated), the system will trigger an exception report as detailed in MSP.REQ.4.2 and

MSP.RPT.4.2.

MSP.REQ.1.4 The system will retrieve validated records from MSP updates file and store them sequentially to the MSP master table based on the timestamp for 3 years. After 3 years the data in the master tables are archived.

Note: Archiving functionality is not part of the MMRP. The archiving functionality will not be implemented as part of CGIS, nor archiving will be tested as part of CGIS.

MSP.REQ.1.5 Once the system has successfully retrieved and stored the data from the files, the

MSP files will be securely disposed from the file system (i.e. permanently deleted using operating system’s “secure-delete” or similar function).

https://urldefense.com/v3/__https:/schhs.sharepoint.com/:x:/r/sites/1211207/CGIS*20Business*20Requirements*20and*20Design*20Documents/MSP_Fields_To_EvidenceMapping_v3.xlsx?d=w2b33017c92f546aa97b8d170d5e6a118&csf=1&web=1&e=ECUIUx__;JSUlJSU!!KMKkofZL!wl-ryl0fY6IuiV1Q-d5heqoJL39XiRVZ-tQ5JuoQRccVOIpeXzBjxddDOMgwvgmaB7HC-Zo$

Medicare Savings Program V3.0 Page 31 of 92

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 Date Fields – N/A

4.1.9 Links - Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validations – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Person Search and Match Process

4.2.1 Design Description

This story describes the process of searching for a person record and based on what is found, making systematic decisions on whether to process the applicant in MEDS or whether to register and process the applicant in Cúram.

4.2.2 Functional Output

• MSP file record is processed by a daily batch process.

• The system performs the person search and match process.

• The system initially uses primary search criteria (e.g. SSN) to find the person.

• In the case of no results, the system uses secondary search criteria (first name, last name, date of birth and gender).

Medicare Savings Program V3.0 Page 32 of 92

4.2.3 Design Details

MSP.REQ.2 The system will perform Person Search based on the data elements provided in the

MSP record for the applicant:

1. Claim Own Social Security Number (COSSN) (length 9)

2. Individual’s Name:

First Name (length 15)

Middle Name (length 15)

Last Name (length 22)

Suffix (length 4)

3. Gender (M or F)

4. Date of Birth with Century (date format MMDDCCYY)

MSP.REQ.2.1 The system starts by checking for the person in the MEDS system.

MSP.REQ.2.1.1 If the applicant exists in MEDS and has 45+ days of eligibility then Cúram will send the exception letter to this applicant.

MSP.REQ.2.1.2 Applicants that are added to the MSP list to be processed by MEDS shall not be processed in Cúram.

MSP.REQ.2.2 For applicants not added to the MSP list to be processed by MEDS, the system will perform a Person Search based on the following criteria in order of hierarchy:

1. SSN

2. SSN, First Name, Last Name, Date of Birth, Gender

3. SSN, Soundex (First Name), Soundex (Last Name), Date of Birth, Gender

Note: Cúram will reuse the existing person search logic to find the appropriate match based on the parameters above. Cúram will take differing appropriate actions based on the three search outcomes (Conclusive Match, Inconclusive Match or No Match).

MSP.REQ.2.3 Conclusive Match: If the system finds a unique person match using the data elements from MSP records, then the system will proceed processing the found person for MSP eligibility. A known person exists for handling, so the MSP applicant record is marked as processed so that it will not be run in subsequent batch runs.

MSP.REQ.2.4 Inconclusive Match: If the system did not find a match using SSN (no conclusive match), but finds one or multiple matches using the existing Person Search and Match

(Soundex (First Name), Soundex (Last Name), Gender, Date of Birth), then the system will register the prospect, create the application and IC case, and then proceed to create task

MSP.REQ.TASK.2.4 (MSP Prospect Person Registered) and assign it to Prospect Person Work queue. All the tasks are sent to Pathos.

Medicare Savings Program V3.0 Page 33 of 92

MSP_REQ_2.4.1: Once the prospect person is resolved by the caseworker then the associated unprocessed MSP record will be processed by the MSP batch process.

MSP_REQ_2.4.2: MSP information will NOT be populated unless the prospect person is resolved as person.

Note: The system leaves this applicant record marked as unprocessed and once the prospect person is resolved, the applicant record will be processed as part of the daily batch.

MSP.REQ.2.5 NO Match: If the system finds NO match in any of the Cúram searches, the system will proceed with systematic registration in Cúram.

MSP.REQ.2.5.1 Registration in Cúram will be based on mapping from data sent for the applicant in the MSP record. A known person exists for handling, so the MSP applicant record is marked as processed so that it will not be run in subsequent batch runs.

Note: Data will be mapped from MSP to Cúram as per MSP_Fields_To_EvidenceMapping_v3

MSP.REQ.2.5.1.1

For a couple application, when single MSP record is received in the file then the gender of the spouse will be assumed to the opposite of the primary.

MSP.REQ.2.5.1.2

For a couple application, when 2 MSP records are received in the file then the gender of the spouse will be obtained from the primary in the 2nd record.

https://team.scdhhs.gov/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MSP_Fields_To_EvidenceMapping_v2.xlsx

Medicare Savings Program V3.0 Page 34 of 92

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 Date Fields – N/A

4.2.9 Links - Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validations – N/A

4.2.12 Notifications and Tasks

MSP.REQ.TASK.2.4 MSP Prospect Person Registered

Task Notification Name: MSP Prospect Person Registered

Purpose: Resolve Prospect person created from the MSP file.

Trigger(s): Inconclusive search results from Cúram person search.

Allocation Type User Position Job Org Unit Queue

Allocation Strategy

Assign it to “MSP MIM” work queue

Link Link Yes No

Primary Action Link Prospect Person home page

Supporting Information Link

Subject Subject Text MSP Prospect Person Registered.

Task Details Deadline Strategy Yes No

Deadline Strategy Details 5 days.

Escalation Strategy

Deadline Override Allowed

Yes No

Task Priority Low Medium High

Medicare Savings Program V3.0 Page 35 of 92

Manual Forwarding Allowed

Yes No

Manual Close Allowed Yes No

If No, Automatic Task Closure Instructions below must be completed

Automatic Task Closure Instructions

Yes, as soon as person is resolved.

Task/Notification Information

This may be used to place instructions, help or steps to complete the task. 2000 alpha and numeric character limit.

Please resolve prospect person by using the prospect person job aid.

Task/Notification Body Details

Message Body Text Please resolve prospect person by using the prospect person job aid.

Other special processing instructions: None

4.2.13 Other – N/A

4.3 MSP Application Processing

4.3.1 Design Description

Each record in the MSP file represents an applicant. Current applicant eligibility is one determinant in deciding whether to go forward with the application or send out an exception letter. The second criteria are based on the income of the applicant (and spouse where applicable). If the person or household exceeds 150% FPL, then the MSP application will be denied.

4.3.2 Functional Output

• If criteria are met, the applicant will be sent an addendum and go through the process described to be approved by the system for appropriate benefit.

• If criteria are not met, the applicant will receive an exception letter if they already had eligibility, or they will receive a denial notice when the application is denied based on FPL limit checks.

4.3.3 Design Details

MSP.REQ.3.1: When the applicant already has Medicaid coverage, Cúram will send an exception letter to the applicant.

Medicare Savings Program V3.0 Page 36 of 92

MSP.REQ.3.1.1: Cúram will check the Eligibility Decision Details (EDD) tables to see whether the Person is eligible in Cúram.

MSP.REQ.3.1.1.1: MSP applicant positions 348 to 350 (Income Used for

Determination) can be used to determine if the applicant is an individual (“SNG”) or a couple (“CPL”). For a couple application the files may contain one or two records, if there are two records then each member will be primary in their own record.

MSP.REQ.3.1.1.2 If a singular person is already eligible for Medicaid benefits in

Cúram other than family planning, then an exception letter will be sent out to the applicant and the application will not be created. Please see Cover Letter_MSP

Withdrawal.docx for the template.

MSP.REQ.3.1.1.3 If a couple has both applicants already eligible for any benefits in Cúram other than family planning, then exception letters will be sent out and the application will not be created.

MSP.REQ.3.1.1.4 If a couple has one applicant receiving benefits in Cúram other than family planning (and the other applicant / spouse is not), then an exception letter will be sent out to the applicant already receiving benefits, while an application will be created for the spouse.

Note: Please see Cover Letter_MSP Withdrawal.docx for the template.

MSP.REQ.3.1.4: Cúram will store a copy of the exception letter in OnBase. The system will transmit this to OnBase using the MMMailCommunication Batch. Per CGIS Notices

Master List spreadsheet , the exception letter is a “Notice of Action” and the type of action is “Decision”. The keywords are defined in section 5.2.4, requirement

CGIS_IOB_2.3 of the MMRP CGIS 15 Integration with OnBase ADD.

MSP.REQ.3.2: Cúram will create income support applications for each applicant that is not already eligible.

MSP.REQ.3.2.1: An applicant and their spouse will both be included on the same application.

MSP.REQ.3.2.2: Data will be mapped from MSP to Cúram evidence per Appendix B

(MSP File to Cúram Data Mapping) and minimally includes name, address, gender and date of birth. Additional information will be updated later in the process when the addendum is returned.

MSP.REQ.3.3: Cúram will create a PDF - same PDF that is created for all income support applications. MSP applications are created during our ingest process as opposed to going through IEG scripts.

https://urldefense.proofpoint.com/v2/url?u=https-3A__schhs.sharepoint.com_-3Aw-3A_r_sites_1211207_CGIS-2520Business-2520Requirements-2520and-2520Design-2520Documents_Cover-2520Letter-5FMSP-2520Withdrawal.docx-3Fd-3Dw6b2f1aaff1514e3287c6b7b8412e43bd-26csf-3D1-26web-3D1-26e-3Ds0dGR0&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=5RnWPUrhQ3Gdsv9sCFXqhigu4gF8u5s5VOiwvTjtS3o&m=uPdmTuZ2ec7xvOMLqB5ivcgOvBUn6moTcwGD6_U40Zw&s=D4KJ5L83qwsuS7hqv9GGWI0HUn3fpUfA8WMabP_0CmA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__schhs.sharepoint.com_-3Aw-3A_r_sites_1211207_CGIS-2520Business-2520Requirements-2520and-2520Design-2520Documents_Cover-2520Letter-5FMSP-2520Withdrawal.docx-3Fd-3Dw6b2f1aaff1514e3287c6b7b8412e43bd-26csf-3D1-26web-3D1-26e-3Ds0dGR0&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=5RnWPUrhQ3Gdsv9sCFXqhigu4gF8u5s5VOiwvTjtS3o&m=uPdmTuZ2ec7xvOMLqB5ivcgOvBUn6moTcwGD6_U40Zw&s=D4KJ5L83qwsuS7hqv9GGWI0HUn3fpUfA8WMabP_0CmA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__schhs.sharepoint.com_-3Aw-3A_r_sites_1211207_CGIS-2520Business-2520Requirements-2520and-2520Design-2520Documents_Cover-2520Letter-5FMSP-2520Withdrawal.docx-3Fd-3Dw6b2f1aaff1514e3287c6b7b8412e43bd-26csf-3D1-26web-3D1-26e-3Ds0dGR0&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=5RnWPUrhQ3Gdsv9sCFXqhigu4gF8u5s5VOiwvTjtS3o&m=uPdmTuZ2ec7xvOMLqB5ivcgOvBUn6moTcwGD6_U40Zw&s=D4KJ5L83qwsuS7hqv9GGWI0HUn3fpUfA8WMabP_0CmA&e= https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/SCDHHS%20CGIS%20Notices%20Master%20List.xlsx?d=w6cf33a678e8842a58093e7b0b8f54f8a&csf=1&web=1&e=B00CGn https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/SCDHHS%20CGIS%20Notices%20Master%20List.xlsx?d=w6cf33a678e8842a58093e7b0b8f54f8a&csf=1&web=1&e=B00CGn https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%2015%20Integration%20with%20OnBase%20ADD%20v1.5.docx?d=wb2475d3e8a814ab59cbc15e149e3f624&csf=1&web=1&e=c8rO6b

Medicare Savings Program V3.0 Page 37 of 92

MSP.REQ.3.3.1 - The PDF will be stored with workflow status of complete as to not be processed by caseworker. The system will use existing functionality framework to create application PDF’s.

MSP.REQ.3.3.2: A unique OnBase reference number will be generated for each applicant.

MSP.REQ.3.3.3: Cúram will store a copy of the application PDF in OnBase. The keywords are defined in section 5.1.4, requirement CGIS_IOB_1.3 of the MMRP CGIS 15 Integration with

OnBase ADD.

Note: CGIS will use the same web services framework as HCR to upload PDFs into OnBase.

Note: The system will transmit notices to OnBase using the MMMailCommunication Batch.

MSP.REQ.3.4: Cúram will determine if the applicant(s) income is below 150% of the FPL for the number of household members:

MSP.REQ.3.4.1: MSP applicant positions 351 to 353 (Income as Percentage of FPL) can be used for determination of FPL. This is numeric and represents a percentage (e.g. 176 means Income is 176% of FPL).

Note: MSP applicant positions 518 to 519 (Household size) provides information about the household size, where the number represents the number of other relatives, not including the applicant or their spouse.

MSP.REQ.3.4.2: The FPL check always includes income from the applicant and spouse, in cases where there is a spouse.

MSP.REQ.3.5: Based on the comparison described in MSP.REQ.3.4, if the applicant or household has exceeded 150% of FPL, the application will be denied.

MSP.REQ.3.5.1: Cúram will trigger the generation of a standard denial notice as per the template identified in MMRP CGIS 23 Global Notices.

MSP.REQ.3.5.2: Cúram will store a copy of the denial notice in OnBase.

MSP.REQ.3.5.3: The system will transmit notices to OnBase using the

MMMailCommunication Batch. The file “Document Types – Keywords” in the track

“CGIS 15 Integration with OnBase” contains the necessary data needed to integrate under the tab “MEDS - Notices of Action”.

MSP.REQ.3.6: When the applicant is not already on full Medicaid and applicant is not denied for LIS based on income, Cúram will send an Addendum to the applicant.

https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%2015%20Integration%20with%20OnBase%20ADD%20v1.5.docx?d=wb2475d3e8a814ab59cbc15e149e3f624&csf=1&web=1&e=c8rO6b https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%2015%20Integration%20with%20OnBase%20ADD%20v1.5.docx?d=wb2475d3e8a814ab59cbc15e149e3f624&csf=1&web=1&e=c8rO6b

Medicare Savings Program V3.0 Page 38 of 92

MSP.REQ.3.6.1: Additionally, Cúram will set an application timer of Addendum generation date plus 20 days. Standard system application timer will be invoked.

MSP.REQ.3.7: Cúram will close the income support application if the Addendum is not returned within 20 days.

MSP.REQ.3.7.1: When the timer expires (the Addendum is not returned on time), Cúram will trigger the generation of a denial notice as per the template identified in

MMRP CGIS 23 Global Notices.

Note: Key input includes the case identifier, the Type of Notice and the denial reason

(“Information Not Returned on Time (AppDetails)”). “SCDHHS CGIS Notices Master

List” contains denial reason information.

MSP.REQ.3.7.2: Cúram will store a copy of the denial notice in OnBase. The file

“Document Types – Keywords” in the track “CGIS 15 Integration with OnBase” contains the necessary data needed to integrate under the tab “MEDS - Notices of Action”.

MSP.REQ.3.8: When the addendum is returned on time, the mailroom worker will click on the

Income Support case action tab menu and select 'MSP Addendum Returned', as per the following requirements.

MSP.REQ.Screen.3.8. This will work like the similar ‘Information Returned’ selection in the picture below, except it will open an MSP specific task instead of the generic.

MSP.REQ.TASK.3.8 is triggered and sent to the MSP Addendum work queue. (see the

Notifications and Tasks section for more details).

Note: Based on data returned in the addendum, an eligibility worker will…