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)

CGIS11 Beneficiary and Earnings Data Exchange (BENDEX) Interface

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/26/2018 Chris LiPuma IBM Business Analyst

Initial Draft

0.2 11/14/2018 Chris LiPuma IBM Business Analyst

Updates per Review comments

0.3 11/19/2018 Ken Haas Functional Lead QA Content Review Updated version to match PM guide both document and SharePoint.

Format Standardization will be done for Approval

0.4 11/21/2018 Chris LiPuma IBM Business Analyst

Updates per Review comments

0.5 12/21/2018 Satish Kappera

Cúram Consultant TDS Section Added.

0.6 1/9/2019 Chris LiPuma IBM Business Analyst

Updated Screen Mockups and related screen details requirements in alignment with interface global design.

0.7 1/09/2019 Satish Kappera

Cúram Consultant TDS Section updated with New UI Changes.

0.8 1/10/2019 Harjeet Parmar

Cúram Consultant Create two additional section: 6.3.2.1 and

6.3.2.2 to elaborate on the BENDATA and MEDS file merge process.

MMRP CGIS Project ADD CGIS11 BENDEX Interface V3.0

Version Date Drafted by Role Description of Change

0.9 2/5/2019 Chris LiPuma IBM Business Analyst

Completed design for new BRD requirements.

1) Dual & Triple Entitlement Task Generation:

Added BDX_Req.11.3.1 BDX_Req.11.3.2 BDX_Req.17.1 Section 5.5.8 - Notifications and Tasks - Task Templates

2) BENDEX Identifications Processing:

Added BDX_Req.18.1 BDX_Req.18.1.1 BDX_Req.18.1.2 BDX_Req.18.1.3 BDX_Req.18.2 BDX_Req.18.3 BDX_Req.18.3.1 BDX_Req.18.4 BDX_Req.18.4.1 BDX_Req.18.4.2 BDX_Req.18.5

3) BENDEX Medicare Processing:

Added BDX_Req.19.1 BDX_Req.19.1.1 BDX_Req.19.1.2 BDX_Req.19.2 BDX_Req.19.2.1 BDX_Req.19.2.2 BDX_Req.19.2.3 BDX_Req.19.2.4 BDX_Req.19.3 BDX_Req.19.3.1 BDX_Req.19.3.2 BDX_Req.19.3.3 BDX_Req.19.3.4

4) COLA:

Updated BDX_Req.15.5 BDX_Req.15.6 BDX_Req.15.6.1 BDX_Req.15.6.2 BDX_Req.15.6.3 BDX_Req.15.6.4 BDX_Req.15.6.5 Inserted ‘COLA Variation’ Column in Appendix B

0.10

3/11/2019 Chris LiPuma IBM Business Analyst

Updates from QA Review for final acceptance submission

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

Updated version number, watermark, and approval date.

V1.1 6/28/2019 Chris LiPuma IBM Business Analyst

Updated per CGIS11 BENDEX CR01 and CGIS29 MMA Interface CR032

1) CGIS11 BENDEX CR01:

Updated BDX_Req.11.9.1 BDX_Task_6 BDX_Req.15.7.1 BDX_Task_7 Added BDX_Req.15.7.2 BDX_Req.11.9.1.1 BDX_Req.11.9.1.2

2) CGIS29 MMA Interface CR032:

Updated BDX_Req.18.3 BDX_Req.19.1.1 Added BDX_Req.18.3.2 BDX_Req.19.2.5 BDX_Req.19.3.5 BDX_Req.18.3.3 Changed Requirement Numbering BDX_Req.18.5 to BDX_Req.18.3.4 BDX_Req.18.6 to BDX_Req.18.3.5

V1.2 7/9/2019 Kumara Balaji, Kuppan

Cúram Developer Updated Technical Specifications section per CGIS11 BENDEX CR01 and CGIS29 MMA Interface CR032.

5.8.1.11 BENDEX Batch Streamer – Modified

the sequence diagram.

5.78.2. BENDEX Inbound Streamer Process

– Added technical description related to the required changes.

V1.3 12/20/2019 Tiffany Ortega

IBM BA Lead Updated the Data Type for the “State Control Data” Data Element per CR168 #5 on the Appendix A – Master BENDEX Mapping spreadsheet.

V1.4 1/16/2020 Tiffany Ortega

Vinod Mandloi

IBM BA Lead

Developer

Updated requirement BDX_Req.5.6.2 per

CR163.

Updated screenshot 4.1.4.7 and #8 in the associated table in section 4.1.5.8 to change “SSN” to “SSN/CAN” per requirement BDX_Req.5.8.1.

TDS 5.78.2 Step-4 section updated for

CR163.

V1.5 3/2/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated following section(s)/ requirement(s) for R1forR2

1. BDX_Req.11.8.1

2. Section 4.4.1 Task: BENDEX –

Payment Status Code Task (updated allocation strategy for BDX_Task_1 to BDX_Task_8) and added a new task BDX_Task_9

3. Table in BDX_Req.15.6.5

4. Appendix B: BENDEX Processing

Details processing details spreadsheet (see Change History tab for details)

V1.6 3/2/2020 Vinod Mandloi

Developer Updated following section(s)/ TDS(s) for R1forR2

1. 5.78.2 BENDEX INBOUND

STREAMER PROCESS

2. DMX Details

V1.7 3/10/202 Sarfaraz Ahmed

IBM Business Analyst

Updated following requirements for CR189:

1. BDX_Req.15.6.5

2. BDX_Req.15.7

3. BDX_Req.15.7.1

4. BDX_Req.15.7.2 https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Appendix%20B%20-%20BENDEX%20Processing%20Details.xlsx?d=wb20a03ff907a4acfac2c16c0095767df&csf=1&e=3YmIE8 https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Appendix%20B%20-%20BENDEX%20Processing%20Details.xlsx?d=wb20a03ff907a4acfac2c16c0095767df&csf=1&e=3YmIE8

V1.8 3/11/2020 Vinod Mandloi

Developer Update for CR189 Jan COLA batch SSA benefit update.

1) 5.105.3 COLA INBOUND

STREAMER PROCESS

2) 5.8.1.17 COLA SSA Benefit update from BATCH STREAMER sequence diagram

V1.9 3/11/2020 Tiffany Ortega

IBM BA Lead Updated the following requirements per

CR193:

1. BDX_Req.2.1

2. Section 4.3.2 Functional Output

3. BDX_Req.8.2

4. Section 4.5.2 Functional Output

5. BDX_Req.14.2

6. BDX_Req.16.2.1

V1.10 3/21/2020 Tiffany Ortega

IBM BA Lead Updated the following per CR209:

4.1.9 Validation #1

BDX_REQ.18.4

Marked the following removed per CR209:

BDX_REQ.18.4.1

BDX_REQ.18.4.2

BDX_Req.16.3.2 #5 BDX_Req.10.3.2 #5

Added the following per CR209:

BDX_REQ.9.1.1

Updated the following per CR210:

4.1.7 Data Fields #1

4.1.8 Links – Functions/Actions #2

Appendix A – BENDATA Tab – cell C6

V1.11 4/07/2020 Vijay Makam IBM Cúram Lead Updated ESB technical sections 5.42, 5.44 and 5.45 for CR193

V1.12 4/08/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated following for defect CGISS-28467

1) Updated Figure 2.2

2) Added Figure 2.3 and Figure 2.4

V1.13 4/16/2020 Tiffany Ortega

IBM BA Lead Added the following requirements per

CR214:

1) BDX_Req.18.1.3.1

2) BDX_Req.18.3.4.1

V1.14 4/16/2020 Kumara Balaji, Kuppan

Cúram Developer Updated section 5.78.2 (Step-6 BENDEX Identification Processing)

V1.15 4/20/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated subject of 4.4.1 Task: BENDEX – Payment Status Code Task for CR226

V1.16 4/20/2020 Kumara Balaji, Kuppan

Cúram Developer Updated section 5.78.2 – Step 7 for CR226 related technical changes.

V1.17 4/22/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated BDX_Req.11.6.2 and added new child requirements for CR215

V1.18 4/23/2020 Kumara Balaji, Kuppan

Cúram Developer Updated below sections for R14R2 DHEC DOD related technical changes.

Section 5.35 section 5.78.2 – Step 6

V1.19 4/29/2020 Kumara Balaji, Kuppan

Cúram Developer Updated below section 5.105.3 – Step 7a for CR215 related technical changes.

V1.20 4/30/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated following for defect CGISS-28467 Updated Figure 2.2 - Figure 2.4 Added Figure 2.5

V1.20 5/6/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated work queue names in section 4.4 Notifications and Tasks. These four queues are dedicated to BENDEX:

BENDEX Work Queue BENDEX LTC/OSS work queue BENDEX TEFRA/BCCP work queue

BENDEX MIM WQ

V1.21 5/8/2020 Sarfaraz Ahmed

IBM Business Analyst

Updated following:

1) 4.1.4.8 Data Fields for CR234

2) Figure 2.2 to display BIC code and its description for CR229

V1.22 5/28/2020 Sita Garaga IBM Business Analyst

Updated the following per CR237:

1. Requirement BDX_Req.10.2.2

2. Requirement BDX_Req.5.6.2

Updated the following for CR234:

1. 4.1.4.8 Data fields

2. 1.4 screenshot

V1.23 5/29/2020 Sita Garaga IBM Business Analyst

Copied the March Rebudgeting related functionality from MMRP CGIS25 – Program Rules – Shared Processes ADD v1.5 to add the following functionality:

1. Added section 4.6

2. Added the task 4.4.10

3. Added the Use Case section 6.2

V1.24 5/30/2020 Kumara Balaji, Kuppan

Cúram Developer Updated the following technical sections for MARCH COLA related technical changes.

5.50.2, 5.51, 5.60, 5.61, 5.66, 5.67, 5.70

V1.25 6/5/2020 Sita Garaga IBM Business Analyst

CR237:

Updated BDX_Req.16.2.2

Updated BDX_Req.3.2

Clarification Note added to BDX_Req.6.2.1

Sample table updated in BDX_Req.10.3.5 per

CR209

V1.26 6/8/2020 Sita Garaga IBM Business Analyst

Updated the following task for the allocation strategy when the member is not eligible on any

PCAT”

4.4.1

4.4.2

4.4.4

4.4.6

4.4.7

4.4.8

4.4.9

V1.26 6/9/2020 Kumara Balaji, Kuppan

Cúram Developer Updated following sections to reflect the technical changes related to task allocation.

5.35

5.75.2

V1.27 6/22/2020 Sita Garaga IBM Business Analyst

Updated the following requirements per CR245 changes.

BDX_Req.10.4.3 BDX_Req.16.4.2

V1.28 7/15/2020 Ella Dickerson

IBM Business Analyst

Action Item #1275 Updated task templates reference to “training guide” to refer to the “Cúram Timers, Tasks & Work Queues” which is the desk reference that will be used for all tasks.

V1.29 7/23/2020 Sita Garaga IBM Business Analyst

Reverted back the changes related to AI#1275 updates.

V1.30 7/27/2020 Tiffany Ortega

IBM BA Lead Updated the template, spelling and grammar checks for formal approval.

V1.31 7/31/2020 Tiffany Ortega

IBM BA Lead The following requirements were added per

CR260:

BDX_Req.1.2.2.1 BDX_Req.19.2.6 BDX_Req.19.3.6

Updated the following items per CR260:

Section 4.3.8.10 Task BENDEX – Review Case for New Coverage

Updated Work Queue to work queue to remove it from the work queue names, and Removed WQ from the work queue names

V1.32 8/11/2020 Sita Garaga IBM Business Analyst

Updates to Appendix B – BENDEX Processing Details.xlsx per CR262

V2.0 8/13/20 Erin Coleman MMRP Process & Artifact Development Manager

Updated version number, watermark, and approval date to reflect approval; remove comments.

V2.1 9/2/2020 Sita Garaga IBM Business Analyst

Updated the requirement BDX_Req.10.3.2 per CR272.

Deleted the following requirements per

CR272:

BDX_Req.10.3.4 BDX_Req.10.3.5

Updated the System Action for the below Communication Codes on Appendix B - BENDEX Processing Details spreadsheet per CR272.

XREF NUM

ENFORXXX

JURISXXX

CFXXX

B-I TERM

DELETED

V2.2 10/12/2020 Sita Garaga IBM Business Analyst

Updated the following requirements for the report name updates per CR295:

BDX_Req.3.1 BDX_Req.10.2 BDX_Req.10.3 BDX_Req.10.4 BDX_Req.16.2 BDX_Req.16.3 BDX_Req.16.4

V2.3 10/19/2020 Sita Garaga IBM Business Analyst

Updated the following requirements per

CR290:

BDX_Req.11.9 BDX_Req.15.7.1.2

V2.4 10/30/2020 Sita Garaga IBM Business Analyst

Added the following R2 requirement per

CR296:

R2_BDX_Req.15.7.1

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

Updated version number, watermark, and approval date.

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/20/2018 Tim Cozine

11/23/2018 Tim Cozine

Product Manager/ Business Analyst

10/24/2018 Abhishek Sahu 3/20/2020

11/27/2018 Abhishek Sahu

12/6/2018 Abhishek Sahu

Technical Lead 10/25/2018 Renjan Bhasi

12/6/2018 Renjan Bhasi

Technical Lead 8/8/2019 Renjan Bhasi (CR01)

Technical SME 10/25/2018

Subject Matter Expert

(SME)

10/26/2018 Patti Davis

Technical Lead 3/25/2020 Renjan Bhasi (Reviewed CR189)

Technical Lead 5/17/2020

R1-4-R2

6/2/2020

Renjan Bhasi (R14R2)

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 1/07/2019

Technical Consultant 2/14/2019 Ramchandra Takkar

SCDHHS Role First Review Date / Reviewer Name

Second Review Date / Reviewer Name

Third Review Date / Review Name

Technical Lead 7/31/2019 Renjan Bhasi (CR01)

8/7/2019 Renjan Bhasi (CR01)

Technical Lead 3/20/2020 Renjan Bhasi (Reviewed CR189 and R1-4-R2)

3/25/2020

(Reviewed CR189)

Technical Lead 4/12/2020

(R1-4-R2 – added some more comments)

5/17/2020 Renjan Bhasi R1-4-R2

6/2/2020

Renjan Bhasi (R14R2)

Technical Lead 5/7/2020

CR214 and CR215

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/23/2021 Approved V2.4 to 3.0

CGIS BA Lead Tiffany Ortega 3/23/2021 Approved V2.4 to 3.0

CGIS Testing Lead Brian Grieves 3/23/2021 Approved V2.4 to 3.0

CGIS Business Analyst Sita Garaga 3/23/2021 Approved V2.4 to 3.0

CGIS Development Lead Vijay Mujumdar 3/23/2021 Approved V2.4 to 3.0

CGIS Development Team Lead

Randhir Singh 3/23/2021 Approved V2.4 to 3.0

Technical Design Section

IBM Technical Design Approval Review – v3.0

Role Name Date Comments

CGIS Development Lead

Vijay Mujumdar

3/23/2021 Approved V2.4 to 3.0

CGIS Development Team Lead

Randhir Singh 3/23/2021 Approved V2.4 to 3.0

The Approval 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 DDI Manager Tim Cozine 4/7/2021 Approved V2.3

SCDHHS Product Manager Abhishek Sahu 4/7/2021 Approved V2.3

SCDHHS Technical Lead Renjan Bhasi

SCDHHS Business Analyst Abhishek Sahu 4/7/2021 Approved V2.3

SCDHHS Process & Artifact Development Manager

Erin Coleman 4/11/2021 Approved ADD

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

Technical Lead Renjan Bhasi

CGIS11 BENDEX Interface V2.0

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 Flow

2.1 BENDEX Interface – Outbound/Inbound File Transfer Process

2.1.1 BENDEX Interface – Outbound/Inbound File Transfer Process Narration

3 Requirements Matrix

3.1 Requirement Modifications – N/A

4 Functions

4.1 BENDATA File Generation

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

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 – NA

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

4.2.13 Other – NA

4.3 BENDEX File Processing

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

4.3.6 Business Rules

4.3.7 User Roles

4.3.8 Data Fields – N/A

4.3.9 Links – Navigation – N/A

4.3.10 Links – Functions/Actions

4.3.11 Validation – N/A

4.3.12 Notifications and Tasks

4.4 Cost of Living Adjustment Process

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 Data 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

4.5 COLA Rebudget – March Process

4.5.1 Design Description

4.5.2 Functional Output

4.5.3 Design Details

4.5.4 Screen Flow – N/A

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

4.5.12 Notifications and Tasks – N/A

4.5.13 Other – N/A

5. Technical Design

5.2 Common Technical Artifacts

5.2.1 Sequence Diagram

5.2.2 Events- N/A

5.2.3 Event Class Details- N/A

5.2.4 Domain Definitions

5.2.5 Code Tables

5.2.7 Messages

5.2.8 Message Detailed Description

5.2.9 DMX

5.2.10 Security – N/A

5.2.11 Security Details – N/A

5.2.12 Model

5.2.13 Interfaces – N/A

5.2.14 Facades

5.2.15 Entity Layer

5.2.16 Service Layer

5.2.17 POD Definitions – N/A

5.2.18 Java Script Changes – N/A

5.2.19 CSS Changes – N/A

5.2.20 Global Configuration Changes – N/A

5.2.21 Wizard Changes – N/A

5.1.21.1 UIM Configuration Changes

5.1.21.2Page Parameter Details

5.1.21.3Server Interface Details

5.1.21.4Links/Action Controls

5.21.1.5 Lists/Inline Page Details – N/A

5.21.1.6 Cluster Details

5.2.22 MENU Details-N/A

5.2.23 Evidence Configuration Changes – N/A

5.2.24 Renderers – N/A

5.2.25 Key Words (Hover Values) – N/A

5.2.26 Help Content – N/A

5.2.27 Links – Navigation – N/A

5.2.28 Links – Functions/Action – N/A

5.2.29 Validation

5.2.30 Workflow

5.2.31 Web Service – N/A

5.2.32 Java Classes

5.2.33 Task and Work queues – N/A

5.2.34 Reports – N/A

5.2.35 Unit Testing Scenarios

5.2.36 Cúram Unit Testing Scenarios

5.2.37 ESB Unit Testing Scenarios

5.2.38 Data Retention – N/A

5.2.39 Persistence Requirements – N/A

5.2.40 Backup Requirements – N/A

5.2.41 Archiving and Purging Requirements – N/A

5.2.42 Data Validation Checks – N/A

5.2.43 Security Considerations – N/A

5.2.44 Event Sequence Diagram – N/A

5.2.45 Coding Specifications – N/A

5.2.46 Table Names – N/A

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

5.2.48 Batch Methods – N/A

5.2.49 Entity Classes – N/A

5.2.50 Entity Methods – N/A

5.2.51 Input/ Output Structs – N/A

5.2.52 Input/ Output Attributes – N/A

5.2.53 Technical Dependencies – N/A

5.2.54 Source-to-Target Mapping – N/A

5.2.55 System Properties – N/A

5.2.56 Page Parameter Details – N/A

5.2.57 Links/Action Controls – N/A

5.2.58 Lists/Inline Page Details – N/A

5.2.59 Cluster Details – N/A

5.2.60 Other

5.3 ESB Development

5.3.1 BENDEX Inbound Flow

5.3.2 BENDATA Outbound Flow

5.2.2.1MEDS-BENDATA Inbound Flow

5.2.2.2BENDATA Outbound Flow

5.3.3 5.2.3 Supporting Details: Records Layout – N/A

5.2.4 ESB Operational Section – N/A

5.4 Rules Development – N/A

5.4.1 Rules - <Rules Area 1> – N/A

5.4.2 Table of Values – N/A

5.5 Batch Development

5.5.1 BENDEX Person Search Batch Detailed Design

5.5.2 March COLA Rebudget Batch Process

5.5.3 Batch Specifications

5.5.4 Data Retention – N/A

5.5.5 Batch Classes – N/A

5.5.6 Batch Methods– N/A

5.5.7 Table Names

5.4.6 Batch Methods

5.5.8 Entity Classes

5.5.9 System Properties

5.5.10 Code Tables

5.5.11 Message Files

5.5.12 Messages

5.5.13 BENDEX Inbound Batch Detailed Design

5.5.14 Batch Overview

5.5.15 Batch Specifications

5.5.16 Table Names

5.5.17 Cúram Batch Component Technical Design

5.5.18 Batch Methods

5.5.19 Entity Classes

5.5.20 Entity Methods – N/A

5.5.21 Input/Output Structs – N/A

5.5.22 Input / Output Attributes – N/A

5.5.23 System Properties

5.5.24 Code Tables

5.5.25 Overview – N/A

5.5.26 Message Files – N/A

5.5.27 Messages – N/A

5.5.28 Coding Specifications – N/A

5.5.29 Source-to-Target Mapping – N/A

5.5.30 Input/Output File/Message Layouts – N/A

5.5.31 COLA Inbound Batch Detailed Design

5.5.32 Batch Overview

5.5.33 COLA(BRI) File Functional Output

5.5.34 COLA INBOUND CHUNKER PROCESS

5.5.35 COLA INBOUND STREAMER PROCESS

5.5.36 Functional Summary-N/A

5.5.37 Batch Specifications

5.5.38 Data Retention – N/A

5.5.39 Persistence Requirements – N/A

5.5.40 Backup Requirements – N/A

5.5.41 Archiving and Purging Requirements – N/A

5.5.42 Data Validation Checks – N/A

5.5.43 Security Considerations – N/A

5.5.44 Event Sequence Diagram – N/A

5.5.45 Coding Specifications – N/A

5.5.46 Table Names

5.5.47 Cúram Batch Component Technical Design

5.5.48 Batch Methods

5.5.49 Entity Classes

5.5.50 Entity Methods – N/A

5.5.51 Input/Output Structs – N/A

5.5.52 Input / Output Attributes – N/A

5.5.53 System Properties

5.5.54 Code Tables

5.5.55 Overview – N/A

5.5.56 Message Files – N/A

5.5.57 Messages – N/A

5.5.58 Coding Specifications – N/A

5.5.59 Source-to-Target Mapping – N/A

5.5.60 Input/Output File/Message Layouts – N/A

5.5.61 BENDEX Re-Accomplishment Batch Detailed Design

5.5.62 Batch Overview

5.5.63 Functional Summary – N/A

5.5.64 Batch Specifications

5.5.65 Data Retention – N/A

5.5.66 Persistence Requirements – N/A

5.5.67 Backup Requirements – N/A

5.5.68 Archiving and Purging Requirements – N/A

5.5.69 Data Validation Checks – N/A

5.5.70 Security Considerations – N/A

5.5.71 Event Sequence Diagram – N/A

5.5.72 Coding Specifications – N/A

5.5.73 Table Names

5.5.74 Cúram Batch Component Technical Design

5.5.75 Batch Methods

5.5.76 Entity Classes

5.5.77 Entity Methods – N/A

5.5.78 Input/Output Structs – N/A

5.5.79 Input / Output Attributes – N/A

5.5.80 System Properties

5.5.81 Code Tables

5.5.82 Overview – N/A

5.5.83 Message Files – N/A

5.5.84 Messages – N/A

5.5.85 Coding Specifications – N/A

5.5.86 Source-to-Target Mapping – N/A

5.5.87 Input/Output File/Message Layouts – N/A

5.5.88 IEG Script – N/A

5.5.89 Technical Dependencies:

5.6 Non-Functional Requirements – N/A

5.6.1 Accessibility – N/A

5.6.2 Availability – N/A

5.6.3 Development Resource – N/A

5.6.4 Evolution – N/A

5.6.5 Globalization – N/A

6. Integration Points/Dependencies – N/A

7. Use Cases

7.2 BENDATA File Generation

7.2.1 System Generated BENDATA Request

7.2.2 Manual BENDATA Request

7.3 COLA Rebudget - March

7.3.1 ABD-SC Disregard

7.3.2 Individual Loses Eligibility for SLMB/QDWI

8. Appendices

8.1 Appendix A: Master BENDEX Mapping

8.2 Appendix B: BENDEX Processing Details

8.3 Appendix C: Action Item Matrix – N/A

8.4 Appendix D: Out of Scope Requirements – N/A

8.5 Appendix E: Possible Impacted Areas

8.6 Appendix F: Risks and Design Constraints – N/A

8.7 Appendix G: Comment/Resolution Log – N/A

8.8 Appendix H: Approval History

1 Introduction

1.1 Background

BENDEX is part of the Income Eligibility Verification System (IEVS). IEVS is an automated system that matches Medicaid applicants/recipients with the Social Security Administration

(SSA). The IEVS is designed to assist in the determination of an applicant’s eligibility through the exploration of past and present income, disability, and Medicare benefits. Information obtained through IEVS is considered to be verified information, and highly confidential.

SCDHHS identifies Medicaid applicants and recipients and submits daily requests (BENDATA) to SSA through DSS, South Carolina’s State Agency authorized to send and receive the SSA information

Once the BENDATA file is processed by SSA, BENDEX exchange is established on the beneficiary/applicant/recipient. Initial entitlement and material changes in entitlement to SSA benefits will be automatically reported to the State.

BENDEX interface initiative will enable the Cúram system to establish an automated process of sending and receiving files on the daily basis. The main purpose of this interface is to establish an exchange for every Medicaid applicant and recipient in the Cúram system. Exchange is a successful response for a member whose request was triggered by the state.

Existing Process

BENDEX interface is established for the MEDS (legacy) system. Following is the AS IS process:

1. Request BENDATA file nightly

2. Receive BENDEX on a daily basis and then,

i. Validate the file

ii. Create report

iii. Update member’s information

iv. Create alert for the cases that might need redetermination information

v. Create alert for case triaging

vi. Re-send the request automatically or manually based on the communication codes received.

3. COLA file: Trigger re-determination when the COLA file is received

4. Re-accomplishment process: Re-send the request for the records for whom SCDHHS didn’t receive a response on from SSA. This file is sent a month prior to the COLA file.

1.2 Purpose

The purpose of this document is to define the functional and technical design for the CGIS11

Track - Beneficiary and Earnings Data Exchange (BENDEX) Interface of the CGIS project.

Within this Architectural Description Document, the details and necessary information required to effectively develop and implement the BENDEX interface are defined. The ADD will identify all possible inputs and outputs from the system, including required system actions related to the processing and flow of information. This document will satisfy the requirements identified within the approved BENDEX Business Requirements Document (BRD) and comply with the specifications within the BENDEX Manual provided by the Social Security Administration. This includes any rules surrounding interface communication and file transfer.

The Architectural Description Document is created during the Design Phase of the project and will be referenced by development, architecture, and quality assurance teams during the implementation. The intended audience of this document includes:

• CGIS Subject Matter Experts (SMEs)

• CGIS Cúram – Business Analysts

• CGIS – Architecture Team

• CGIS – Solution Developers

• CGIS – Testing Team

• CGIS – IV&V team

1.3 Scope

The Beneficiary and Earnings Data Exchange (BENDEX) interface will be established between

SCDHHS Cúram and the Social Security Administration (SSA) as part of Cúram Global Income

Support (CGIS) implementation. This project will meet the business need to establish an exchange for every Medicaid applicant/recipient with the BENDEX component of the Income

Eligibility Verification System (IEVS). The interface will handle both inbound and outbound

(I/O) file transfers and the related downstream data processing in Cúram will be developed.

Specifically, the interface will be providing verified information related to past and present income to assist in the determination of applicants’ eligibility. The implementation of the

BENDEX interface will provide the following high-level business functionality:

1. Request Daily BENDATA File

The State Beneficiary Input Data File, or BENDATA File, is the outbound file that is triggered by the State and sent by the Department of Social Services (DSS) to the Social Security Administration (SSA). The BENDATA file will be sent nightly in the file layout provided by SSA and will be merged with the existing file sent from MEDS such that only one BENDATA File is triggered from

SCDHHS to SSA. SCDHHS will only be triggering accretion requests although

BENDEX supports additional requests. The outbound file will be populated to capture the following from both MEDS & Cúram CGIS:

1) New Applications

2) Change in SSN, Name, DOB, SSCN, or Medicare Claim Number

3) New member addition

4) Manual Requests

5) Automated resend request based on the response received.

2. Receive Daily BENDEX File

The BENDEX File, is the inbound file response from the SSA that SCDHHS will receive from DSS on a daily basis. The incoming file will contain additional records not requested by SCDHHS. SCDHHS will store the information for all of the records but only display the information of the members who are known to

Cúram. The unknown members information will not be displayed unless the member applies for CGIS Non-Magi Medicaid benefits. When the unknown member submits an application in the future, the request will be sent to SSA. An exchange is established when the response confirms there is a record for the individual. The SSA will continue to send information for:

1) SSA Benefits

2) Disability Information

3) Hospital Insurance (HI)

4) Supplemental Medical Insurance (SMI)

5) Amount or premium information

6) Date ranges for SSA, HI, and SMI

7) DOB and DOD, etc.

The following actions/processes will be defined and performed by the system upon receiving the inbound file from DSS:

i. Store BENDEX File Records and Perform Data Validation

ii. Pre-processing report generation for invalid data

iii. Cúram processing – A change in information will require member updates in Cúram

iv. Trigger Redetermination

v. Create tasks and assign tasks to appropriate work queues

vi. Re-send request based on the response received.

3. Receive Cost of Living Adjustment (COLA) File and trigger redetermination.

The Social Security amendments provide for an automatic benefit rate increase

(BRI) or cost-of-living adjustment (COLA) in Retirement, Survivors, and

Disability Insurance (RSDI) payments each year. The COLA increase for most beneficiaries on the MBR is accomplished electronically about 2 months before the new rate is payable. The BENDEX file will provide advance notice of the new rates to the States.

The COLA File will be sent by SSA in November. The new SSA benefit amounts will be updated for matched members in the system. The effective date of the new

SSA benefit amounts will be based on PCAT as identified in the detailed COLA design requirements. The file processing will allow for the required advanced notice generation to clients.

4. Quarterly Outbound Re-accomplishment Processing

Re-send the request quarterly for the records where no response was received from SSA. These members will be incorporated into the existing daily file and no

‘net new’ file will be sent. The last re-accomplishment file for the year will include BENDATA requests for all members on an open Income Support case.

1.4 Key References

This section lists any key documents that might be helpful to understanding the functionality which are located on the state SharePoint site.

Document Name Location

MMRP CGIS BENDEX Interface BRD Track Name: CGIS 11 BENDEX Interface (Reference)

BENDEXMANUAL2017 Track Name: CGIS 11 BENDEX Interface (Reference)

Master BENDEX Mapping.xlsx Appendix A

BENDEX Processing Details.xlsx Appendix B

1.5 Definitions and Acronyms

Term Meaning

BENDATA State Beneficiary Input Data File

BENDEX Beneficiary and Earnings Data Exchange (Output File)

BEER Beneficiary Earnings Exchange Record

BIC Beneficiary Identification Code

BOSSN Beneficiary's own Social Security Number

BRD Business Requirements Document

BRI Benefit Rate Increase

CAN Claim Account Number https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%20BENDEX%20Interface%20BRD.docx?d=we1afe1befc504b329f0fb81f56d280cd&csf=1&web=1&e=VhdwDV https://schhs.sharepoint.com/:b:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/BENDEXMANUAL2017.pdf?csf=1&web=1&e=EWwYIp https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Appendix%20A%20-%20Master%20BENDEX%20Mapping.xlsx?d=w15127299e3a94aa69daa3e82f0fdc05b&csf=1&web=1&e=9IKsoW https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Appendix%20B%20-%20BENDEX%20Processing%20Details.xlsx?d=wb20a03ff907a4acfac2c16c0095767df&csf=1&web=1&e=ZuK8qG

Term Meaning

CGIS Cúram Global Income Support

COLA Cost of Living Adjustment

CoC Change of Circumstance

CP Citizen Portal

DOB Date of Birth

DSS Department of Social Services

ESB Enterprise Service Bus

HCR Healthcare Reform

HI Hospital Insurance

HICN Health Insurance Claim Number

IEVS Income and Eligibility Verification System

MBR Master Beneficiary Record

MCN Medicare Claim Number

MEF Master Earnings File

MMRP Member Management Replacement Program

OV Outstanding Verification

RR Railroad Retirement

RSDI Retirement, Survivors, and Disability Insurance

SCDHHS South Carolina Department of Health and Human Services

SDX State Data Exchange System

SMI Supplemental Medical Insurance

SSA Social Security Administration

SSCN Social Security Claim Number

WP Worker Portal

1.6 Key Assumptions

BENDEX Initiative:

1. The data interchange protocols between South Carolina Department of Health and

Human Services (SCDHHS), Department of Social Services (DSS) and Social

Security Administration (SSA) will be per the security standards.

2. The Security Design Plan will be approved without impacting the project schedule.

3. The file layout provided by SSA will remain consistent. If it changes, then the appropriate change will be made in the incoming and outgoing file.

BENDATA File Generation:

1. MEDS will provide Cúram the MEDS generated BENDATA file

2. MEDS will conform to the pre-existing BENDATA file generation schedule to which

Cúram will align.

3. MEDS BENDATA file format is the same as the Cúram BENDATA file format as defined in the 2017 BENDEX Manual.

4. MEDS has performed field level data validations on the records in the BENDATA file in compliance with the 2017 BENDEX Manual BENDATA format.

5. MEDS will use existing connections via CyberFusion to transfer the consolidated

BENDATA file to DSS

BENDEX File Processing:

1. MEDS will provide Cúram the daily BENDEX file

2. MEDS will conform to the pre-existing BENDEX response file schedule to which

Cúram will align.

3. BENDEX file format will follow the format as defined in the 2017 BENDEX

Manual.

2 Conceptual Flow

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

2.1 BENDEX Interface – Outbound/Inbound File

Transfer Process

B

EN

D

EX

I n te rf ac e

O u tb o u n d

/I n b o u n d F ile T ra n sf er

E

SB

C u ra m

D

SS

SS

A

M

ED

S

Daily Process

1.0 New Application, Change of

Circumstance, or Renewal

2.0 Batch Performs

Daily BENDATA File

Record Selection

1.1 Caseworker

indicates BENDATA trigger

2.1 BENDATA

File Data

Validation

2.2 Create BENDATA

Exception ReportFail

Pass

2.5 Curam & MEDS

BENDATA File Merge

3.0 BENDATA File is

Received

3.1 DSS BENDATA

File Transformation

2.6 Consolidated

BENDATA File is Sent to MEDS

3.2 DSS Sends

BENDATA to SSA

4.0 SSA IEVS

Receives BENDATA

File

4.1 BENDEX

Response File is

Generated

4.2 SSA Sends

BENDEX File to DSS

5.0 DSS Receives

BENDEX File

5.1 DSS Sends

BENDEX File to

MEDS SC DHHS

6.0 ESB Receives

BENDEX File

6.1 System

Stores BENDEX

Data

6.2 BENDEX FIle

Data Validation

6.3 Create BENDEX

Exception ReportFail

Pass

7.0 Person

Match

MatchNo Match

7.2 Create Prospect

Match Report

Prospect Match

7.1 End

8.2 Create Task and

Assign to BENDEX

Work Queue

8.1 Update Member

Record in Curam

8.3 Create Report

8.4 Resend

BENDATA Request

8.5 Loop

with 2.0

8.0 Event

Based

Gateway

9.0 Event

Based

Gateway

9.3 Trigger

Reassessment

9.1 Clear

Outstanding Verification

10.0 End

9.2 Apply Changes

and Reassessment

2.3 MEDS Daily

BENDATA File

2.4 MEDS Sends

MEDS BENDATA File to ESB

2.7 MEDS Sends

Consolidated

BENDATA File to DSS

5.2 MEDS Receives

the BENDEX File and Sends a Copy to ESB

2.1.1 BENDEX Interface – Outbound/Inbound File Transfer

Process Narration

# Task/Process Task ID Narration

1. 1. New Application, CoC or Renewal Created

2.

3. Caseworker initiates

BENDATA Request

4. 1.0 & 1.1 5. Citizen applies for Non-Magi Medicaid benefits, an existing member reports a CoC, or Renewal process is completed in CGIS Cúram.

Caseworker has initiated manual BENDATA interface request on a record in Cúram.

2. 6. Batch Performs Daily BENDATA File Record Selection

7. 2.0 Daily BENDATA file generation batch process selects records that meet the following conditions:

1) New Application – a request will be triggered for all members within the new application both applying and non-applying members

2) Change to an existing eligible member’s information:

a. SSN

b. SSCN/CAN (Claim Account Number)

c. DOB

d. Name

e. Medicare Claim Number (HICN)

3) COC - Newly added member to the household (Worker Portal (WP), Citizen Portal (CP), Renewals)

4) Records where caseworker has manually indicated BENDATA

5) Quarterly: Batch process will select records where no response was received from SSA and resend the request. (Re-accomplishment process)

6) Records in Renewal Process identified by case selection batch

3. 8. BENDATA ESB Data Validation

9. 2.1 & 2.2 Enterprise Service Bus (ESB) performs data validation on the selected BENDATA file records.

Records that fail ESB Data Validation due to missing mandatory or invalid data will be filtered out in a report.

4. 10. MEDS Daily BENDATA File

11. 2.3 MEDS creates the MEDS daily BENDATA File

5. 12. MEDS Sends MEDS BENDATA File to ESB

13. 2.4 MEDS sends the MEDS BENDATA File to ESB

# Task/Process Task ID Narration

6. 14. Cúram & MEDS BENDATA File Merge

15. 2.5 Cúram records that pass ESB Data Validation will be merged with the MEDS BENDATA File. Any record that is duplicated between the Cúram & MEDS BENDATA files will be filtered out so that only 1 instance of the record is included on the consolidated/merged file.

7. 16. Consolidated BENDATA File is Sent to MEDS

17. 2.6 System generates one consolidated BENDATA (outbound) file of MEDS & Cúram records and sends to MEDS.

8. 18. MEDS Sends Consolidated BENDATA File to DSS

19. 2.7 MEDS sends the consolidated BENDATA file as-is leveraging existing connections to DSS

9. 20. BENDATA File is Received

21. 3.0 BENDATA File is Received by DSS

10. 22. DSS BENDATA File Transformation

23. 3.1 24. DSS modifies the BENDATA file to include records from both SCDHHS and DSS.

11. 25. DSS Sends BENDATA to

SSA

26. 3.2 27. DSS sends the BENDATA file to

SSA.

12. 28. SSA IEVS Receives BENDATA File

29. 4.0 30. SSA receives and processes the BENDATA file from DSS.

13. 31. BENDEX Response File is Generated

32. 4.1 33. SSA generates the BENDEX response file with data for new records and updates to existing records.

14. 34. SSA Sends BENDEX Response File to DSS

35. 4.2 36. SSA Sends the BENDEX Response (Inbound) File to DSS

15. 37. DSS Receives BENDEX File

38. 5.0 39. DSS receives the BENDEX response file from SSA.

16. 40. DSS Sends BENDEX File to MEDS SC DHHS

41. 5.1 42. DSS Sends BENDEX File to MEDS

SC DHHS

17. 43. MEDS Receives the BENDEX File and Sends to ESB

44. 5.2 45. MEDS Receives the BENDEX File and Sends to ESB

18. 46. ESB Receives BENDEX File

47. 6.0 48. ESB Receives BENDEX File from

MEDS

19. 49. BENDEX Data is Stored 50. 6.1 51. System will store the BENDEX master records.

20. 52. ESB Data Validation 53. 6.2, 6.3 54. ESB performs data validation on the BENDEX file. Valid records proceed to person match.

Records that fail ESB Data Validation due to missing mandatory or invalid data will be filtered out in an exception report.

21. 55. Person match 56. 7.0 The system performs a person match between the BENDEX file and Cúram. Based on the match criteria (to be defined), the outcome will be either:

1: No Match 2: Prospect Match

57. 3: Match

22. 58. No Match 59. 7.1 The system shall not take any action for no match records. The data that is received in the BENDEX file will be stored for future references.

23. 60. Prospect Match - Create Report

61. 7.2 The system will create a report for the prospect persons.

24. 62. Matched Person - Event based action

63. 8.0,

64. 8.1, 8.2, 8.3, 8.4,

65. 8.5

Based on the data received in the BENDEX file for a matched person, the system will either:

1. Update member’s information based on the date received in the BENDEX file or, wherever applicable,

2. Create task based on the communication and/or payment codes or,

3. Create report based on the communication and/or payment codes or,

4. Resend request based on the communication and/or payment codes.

66. - If it’s a resend request, then in the process flow it should loop back to

2.0. The BENDATA request for that

member will be triggered again.

25. 67. Event based action on case

68. 9.0 Based on the evidence changes applied, the system will determine the next action, whether to clear the Outstanding Verification (OV) if OV exists, or to trigger re-determination. .

26. 69. Clear outstanding verification

70. 9.1 If there is any OV for the member, like SSA benefit, then the system will clear the OV based on the information provided in the file.

27. 71. Apply changes & Trigger re-determination

72. 9.2 Based on the information received and if required, the system will apply changes, trigger the reassessment, and generate a task if the member is no longer eligible.

28. 73. Trigger re-determination 74. 9.3 Based on the information received and if required, the system will reassess the case and generate a task if the member is no longer eligible.

29. 75. End 76. 10.0

3 Requirements Matrix

The mapping from business requirement to functional requirement is documented in this Track

Name: CGIS 11 BENDEX Interface located in Jira.

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

/Users/sitagaraga/Downloads/CGIS11%20Bendex%20InterfaceCGISS-6https:/cuihhsiutl10.clemson.edu:8443/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS#160&BENDEX%20BR/FR/TC%20RTM&true /Users/sitagaraga/Downloads/CGIS11%20Bendex%20InterfaceCGISS-6https:/cuihhsiutl10.clemson.edu:8443/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS#160&BENDEX%20BR/FR/TC%20RTM&true

4 Functions

This section describes the details of the system functionality.

4.1 BENDATA File Generation

4.1.1 Design Description

This story describes the process for triggering a BENDATA request for a record and generating the BENDATA file from Cúram.

4.1.2 Functional Output

The caseworker or citizen will either submit a new CGIS application for Non-Magi Medicaid benefits, report a Change of Information, Change of Circumstance, or initiate the Renewal process in CGIS Cúram

The caseworker has initiated a manual BENDATA interface request on a record in Cúram.

The system will run a daily BENDATA file generation batch that will select records that meet the above aforementioned conditions in either step 1 or step 2.

The system will validate the records and generate reports for records that could not be successfully generated on the BENDATA file.

A file merge and transfer process will occur to merge the Cúram BENDATA file with the MEDS

BENDATA file and send to DSS.

System will display the status of the BENDEX interface data request

4.1.3 Design Details

Triggering BENDATA Request

BDX_Req.1.1 The system will run a daily BENDATA File Generation batch

BDX_Req.1.1.1 The BENDATA file generation batch will capture records where a

BENDATA request is required to be generated and sent to the Social Security

Administration to establish BENDEX exchange. This batch will select records from the system when a manual BENDATA request has been initiated for the record (manual generated request).

BDX_Req.1.1.2 The BENDATA file generation batch will also capture records where the record meets predefined conditions for a BENDATA request (system generated request).

BDX_Req.1.1.3 The daily BENDATA File Generation batch will be aligned with the existing MEDS BENDATA File generation schedule.

BDX_Req.1.2 The batch selection criteria will include records where the following conditions exist in CGIS and have occurred after the previous day’s run of the BENDATA File Generation batch. The following triggers will be referenced in this document as the ‘BENDATA triggers’:

BDX_Req.1.2.1 When a new CGIS application is submitted, a request will be generated for all members included within the new application. This includes requests for both applying and non-applying members.

BDX_Req.1.2.2 When a change is reported on an Income Support case or person record related to any of the following evidence for an existing eligible member, the BENDATA request will be generated for that member:

a. SSN

b. Social Security Claim Number (SSCN)/ Claim Account Number (CAN)

c. Date of Birth (DOB)

d. Name

e. Medicare Claim Number/Health Insurance Claim Number (HICN)

BDX_Req.1.2.2.1 The system shall not trigger a new BENDATA request if the SSCN evidence for an existing member is created/updated by BENDEX inbound processing.

BDX_Req.1.2.3 When a new member has been added to the household on an Income

Support case, the BENDATA request will be generated for said member.

BDX_Req.1.2.4 During the case selection batch of the Renewal process for an Income

Support case, a request will be generated for all members included on the case, both applying and non-applying.

BDX_Req.1.2.5 When a caseworker has manually indicated the BENDATA request on a record.

BDX_Req.1.3 When there is a new CGIS application or a member is added to an Income

Support case, the system will search the interface tables to check if BENDEX information already exists for the member.

BDX_Req.1.3.1 System will search for the member in the interface tables using the

BENDEX person search logic as defined in BDX_Req.9.2

BDX_Req.1.3.2 If a match exists, system will apply the last received BENDEX data to the person and case if the age of the data is within 12 months of the current date of the

BENDATA trigger.

BDX_Req.1.3.2.1 Data that is older than 12 months from the date that the

BENDATA trigger has occurred is not valid and will not be applied to the member.

BDX_Req.1.3.3 The BENDATA request will still be generated for the member even if valid BENDEX data exists in the interface tables for said member (i.e. data is within 12 months the date the BENDATA trigger has occurred).

BDX_Req.1.4 The system will allow for a caseworker to manually indicate the BENDATA request for a record. This functionality has been provided through new customized interface screens documented in the screen mockup section.

BDX_Req.1.5 System will generate the BENDATA File as per the layout defined by the latest available copy of the BENDEX Manual, updated December 5, 2017. The BENDATA file layout is as follows:

Figure 1 - BENDATA File Layout

BDX_Req.1.6 The fields of the BENDATA file can be populated by Cúram or as a fixed value either defined by the BENDEX manual or designated by SC DHHS. The value and source of the value for each data element is identified in the ‘Master BENDEX Mapping.xlsx’, included in the appendix as document “A”.

BDX_Req.1.6.1 The railroad claim number should not be used in the BENDATA file.

BDX_Req.1.7 SC DHHS has elected to send only accretion requests to BENDEX. System will populate the ‘State Communication Code’ field in the BENDATA file for all records with the fixed value ‘BDA’ to indicate the accretion request.

BDX_Req.1.8 The BENDEX Manual identifies agency codes by State. The State of South

Carolina corresponds to agency code ‘420’. System will populate the ‘Agency Code’ field in the

BENDATA file for all records with the fixed value ‘420’ to indicate South Carolina.

BDX_Req.1.9 The system will populate the ‘Category of Assistance Code’ field in the

BENDATA file for all records with the fixed value ‘N’ to indicate Title XIX Medicaid

Determination.

BDX_Req.1.10 Position 1-9 in the BENDATA file can be used to populate either the record’s

SSN or CAN/SSCN. The following logic applies:

BDX_Req.1.10.1 For system generated requests, position 1-9 will be populated with the

SSN. If SSN is blank, system will populate position 1-9 with the record’s CAN/SSCN. If both SSN and CAN/SSCN are blank, position 1-9 will be blank for the record.

BDX_Req.1.10.2 For manual requests, caseworker can manually input either SSN or

CAN/SSCN data to be populated in the BENDATA request.

BDX_Req.1.11 BENDATA File will capture a record and the respective SSN even if the SSN is not verified.

BDX_Req.1.12 The system will track the status of BENDATA requests generated for each record as documented in the screen mockup section of this document.

ESB Data Validation

BDX_Req.2.1 The system will perform data validations on the records generated within the

BENDATA file for the fields used by Cúram which are identified in the Release 1 Interface Data

Elements Cúram Validations spreadsheet.

BDX_Req.2.2 Records that fail ESB Data Validation due to missing mandatory or invalid data will be filtered out in a report, and not included in the validated BENDATA file.

BDX_Req.2.2.1 Mandatory BENDATA fields are defined in appendix document “A”

BDX_Req.2.3 Records that pass ESB Data validation will be generated into the Cúram

BENDATA file.

Reports

BDX_Req.3.1 System will generate a daily BENDATA Exception Report with the report name

MMRPBNDX2000R02.

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

BDX_Req.3.1.1 This report will contain records with missing mandatory or invalid data.

BDX_Req.3.2 The BENDATA Exception Report will include the following fields:

1) First Name

2) Last Name

3) SSN

4) DOB

5) Error Column

6) Error Value

7) Error Reason

BDX_Req.3.3 The report will be generated and stored to a designated folder on SharePHI.

Sample Daily BENDATA Exception Report

First Name Last Name Social Security Number

Date of Birth Error Column Error Value Error Reason

Bob Jones 123456789 11/11/1940 SSN/CAN

MEDS File Merge and Transfer Process

MEDS File Merge Description

MEDS currently generates a BENDATA file that is sent to SSA by DSS. In effort to provide only 1 BENDATA file to SSA, the MEDS generated BENDATA file will be merged with the

Cúram generated BENDATA file prior to sending to DSS.

File Transfer Process

Cúram will provide a consolidated BENDATA file to MEDS. This process starts with MEDS providing Cúram the daily MEDS BENDATA file.