PL0019 - CGIS33.pdf

SCDHHS MMRP ADD

CGIS33 PARIS V2.0 Page 1 of 129

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)

CGIS33 Public Assistance Reporting Information System (PARIS) Interface

CGIS33 PARIS V2.0 Page 2 of 129

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 11/15/18 Jim Bostick, Biswajit Deka

Business Analyst Initial draft

0.2 12/18/18 Jim Bostick Business Analyst Updates per walk-through and initial comments.

0.3 03/19/2019 Ashleigh Kelley Cúram Developer TDS Section Added

0.4 6/6/2020 Tiffany Ortega IBM BA Lead Updates to Approved ADD Template

0.5 6/15/2020 Tiffany Ortega IBM BA Lead

The following changes were made per CR212:

Updated:

CGIS_PARIS_2.1

CGIS_PARIS_3.1

CGIS_PARIS_4.1

Added:

CGIS_PARIS_2.1.1

CGIS_PARIS_2.1.2

CGIS_PARIS_2.1.3

CGIS_PARIS_2.1.4

CGIS_PARIS_2.1.5

CGIS_PARIS_3.1.1

CGIS_PARIS_3.1.2

CGIS_PARIS_3.1.3

CGIS_PARIS_3.1.4

CGIS_PARIS_4.1.1

CGIS_PARIS_4.1.2

CGIS_PARIS_4.1.3

CGIS_PARIS_4.1.4

CGIS33 PARIS V2.0 Page 3 of 129

Version Date Drafted by Role Description of Change

0.6 6/23/2020 Tiffany Ortega IBM BA Lead

Minor update to grammar for the following requirements per CR212 Review Cycle 1 comments:

CGIS_PARIS_2.1.5

CGIS_PARIS_3.1

CGIS_PARIS_4.1

Added CGIS_PARIS_2.1.6 per Review Cycle 1 comments for CR212.

Added requirement

CGIS_PARIS_2.1.6

0.7 7/06/2020 Vijay Makam IBM Dev Lead updated ESB Technical Design Sections 5.4.2, 5.4.4, 5.4.5 for CR212

0.8 8/6/2020 Amir Iqbal IBM BA

Made 1 minor update to correct format of the following field in ADD based on production data and file layout

GIS_PARIS_2.1.6 the format is changed to CCYYMM from CCYYMMDD. Also added the location in the file.

Two req were listed with the same number CGIS_PARIS_2.2, changed the later one to CGIS_PARIS_2.3.0 please page 30,31

0.9 8/13/2020 Tiffany Ortega IBM BA Lead Updated the template, spelling and grammar check for formal approval of v2.0.

V1.0 9/2/2020 Erin Coleman SCDHHS Process & Artifact Development Manager

Update the watermark, date, and version number based on approval. Removed all comments and accept track changes.

V1.1 10/15/2020 Amir Iqbal IBM BA

Updated for CR289, following requirements updated.

CGIS_PARIS_1.1

CGIS_PARIS_1.2

CGIS_PARIS_1.3

V1.2 10/15/2020 Ashleigh Kelley IBM Developer

CR289 updates to sections 5.4.1.2 5.4.1.11 5.4.1.12 5.4.1.13

CGIS33 PARIS V2.0 Page 4 of 129

Version Date Drafted by Role Description of Change

V1.3 12/11/2020 Tiffany Ortega IBM BA Lead Updated the PARIS Interface Data Model spreadsheet per CR306.

V1.4 1/14/21 Amir Iqbal IBM BA

Updated PARIS_RPT_1.24 for

CR329

Two columns from the report removed

V1.5 1/15/21 Amir Iqbal IBM BA Updated county code doc referenced in Appendix F for CR323

V1.6 1/15/21 Amir Iqbal IBM BA

Reversing the changes made for CR329 , as CR329 has been moved to O&M

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

Update the watermark, date, and version number based on approval. Removed all comments and accept track changes.

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

Third Review Date/ Reviewer Name

DDI Manager

Product Manager

Technical Lead

Business Analyst

Testing Manager

Subject Matter Expert

Documentation Specialist

CGIS33 PARIS V2.0 Page 5 of 129

Process & Artifact Development Manager

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

SCDHHS Technical Lead

4/1/2019 / Renjan Bhasi

Technical Lead Sudheer Arimbra 10/22/2020 – CR289 no comments

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

IBM Functional Design Review – v2.0

Role Name Date Comments

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

IBM Development Team Lead

Vijay Mujumdar 3/25/2021 Approved v1.6 to v2.0

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

IBM Business Analyst Amir Iqbal 3/25/2021 Approved v1.6 to v2.0

IBM Testing Lead Brian Greives 3/25/2021 Approved v1.6 to v2.0

IBM CGIS Development Lead

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

Technical Design Section

CGIS33 PARIS V2.0 Page 6 of 129

IBM Technical Design Review – v2.0 Role Name Date Comments

IBM Development Manager Vijay Mujumdar 3/25/2021 Approved v1.6 to v2.0 IBM Development Lead Randhir Singh 3/25/2021 Approved v1.6 to v2.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

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 v2.0

Role Name Date Comments

SCDHHS DDI Manager Tim Cozine 4/7/2021 Approved V1.2

SCDHHS Product Manager Abhishek Sahu 4/7/2021 Approved V1.2

SCDHHS Business Analyst Joel Mudumala 4/6/2021 Approved (FDS)

SCDHHS Technical Lead Renjan Bhasi

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 v2.0 Role Name Date Comments

SCDHHS Technical Lead Renjan Bhasi

CGIS33 PARIS V2.0 Page 7 of 129

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 Quarterly Outbound PARIS Request File

2.1.1 Quarterly Outbound PARIS Interstate File Narrative

2.2 Quarterly Inbound PARIS Interstate Response File

2.2.1 Quarterly Inbound PARIS Interstate File Narrative

2.3 Quarterly Inbound PARIS VA Response File

2.3.1 Quarterly Inbound PARIS VA File Narrative

2.4 Quarterly Inbound PARIS Federal Response File

2.4.1 Quarterly Inbound PARIS Federal Response File Narrative

3 Requirements Matrix

3.1 Requirements Modifications

4 Functions

4.1 Quarterly Outbound PARIS Interstate Request File

4.1.1 Design Description

4.1.2 Functional Output

4.1.3 Design Details

4.1.4 Screen Flow

4.1.5 Screen Mockup

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

CGIS33 PARIS V2.0 Page 8 of 129

4.1.8 4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validations – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Reports

4.2 Quarterly Inbound Interstate Match Response File

4.2.1 Design Description

4.2.2 Functional Output

4.2.3 Design Details

4.2.4 Screen Flow

4.2.5 Screen Mockup

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks

4.2.13 Reports

4.3 Quarterly Inbound VA Match Response File

4.3.1 Design Description

4.3.2 Functional Output

4.3.3 Design Details

4.3.4 Screen Flow

4.3.5 Screen Mockup

4.3.6 Business Rules – N/A

CGIS33 PARIS V2.0 Page 9 of 129

4.3.7 User Roles – N/A

4.3.8 Data Fields – N/A

4.3.9 Links – Navigation – N/A

4.3.10 Links – Functions/Actions – N/A

4.3.11 Validation – N/A

4.3.12 Notifications and Tasks – N/A

4.3.13 Reports

4.4 Quarterly Inbound Federal Match Response File

4.4.1 Design Description

4.4.2 Functional Output

4.4.3 Design Details

4.4.4 Screen Flow

4.4.5 Screen Mockup

4.4.6 Business Rules – N/A

4.4.7 User Roles – N/A

4.4.8 Data Fields – N/A

4.4.9 Links – Navigation – N/A

4.4.10 Links – Functions/Actions – N/A

4.4.11 Validation – N/A

4.4.12 Notifications and Tasks – N/A

4.4.13 Reports

5 Technical Design

5.1 Common Technical Artifacts

5.1.1 Sequence Diagram

5.1.2 Events - N/A

5.1.3 Event Class Details - N/A

5.1.4 Domain Definitions - N/A

CGIS33 PARIS V2.0 Page 10 of 129

5.1.5 Code Tables

5.1.6 Code Table Details

5.1.7 Messages

5.1.8 Message Detailed Description

5.1.9 DMX

5.1.10 Security

5.1.11 Security Details

5.1.12 Model

5.1.13 Interfaces - N/A

5.1.14 Façades

5.1.15 Entity Layer

5.1.16 Service Layer

5.1.17 POD Definitions - N/A

5.1.18 Java Script Changes - N/A

5.1.19 CSS Changes -N/A

5.1.20 Global Configuration Changes - N/A

5.1.21 Wizard Changes - N/A

5.1.22 Menu Details – N/A

5.1.23 Evidence Configuration Changes – N/A

5.1.24 Renderers – N/A

5.1.25 Keywords (Hover Values) – N/A

5.1.26 Help Content – N/A

5.1.27 Links – Navigation – N/A

5.1.28 Links – Functions/Actions – N/A

5.1.29 Validation – N/A

5.1.30 Workflow

5.1.31 Web Services – N/A

CGIS33 PARIS V2.0 Page 11 of 129

5.1.32 Java Classes – N/A

5.1.33 Task and Work queues

5.1.34 Reports

5.1.35 Unit Testing Scenarios

5.1.36 Cúram Unit Testing Scenarios

5.1.37 ESB Unit Testing Scenarios

5.1.38 Data Retention – N/A

5.1.39 Persistence Requirements – N/A

5.1.40 Backup Requirements – N/A

5.1.41 Archiving and Purging Requirements – N/A

5.1.42 Data Validation Checks – N/A

5.1.43 Security Considerations – N/A

5.1.44 Event Sequence Diagram – N/A

5.1.45 Coding Specifications – N/A

5.1.46 Table Names – N/A

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

5.1.48 Batch Methods – N/A

5.1.49 Entity Classes – N/A

5.1.50 Entity Methods – N/A

5.1.51 Input/ Output Structs – N/A

5.1.52 Input/ Output Attributes – N/A

5.1.53 Technical Dependencies – N/A

5.1.54 Source-to-Target Mapping – N/A

5.1.55 System Properties – N/A

5.1.56 Page Parameter Details

5.1.57 Links/Actions Controls

5.1.58 Lists/Inline Page Details – N/A

CGIS33 PARIS V2.0 Page 12 of 129

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

5.2.2 Inbound

5.2.3 Supporting Details: Record Layout

5.2.4 ESB Operational – N/A

5.3 Rules Development

5.3.1 Rules (Rules Area) – N/A

5.3.2 Table of Values – N/A

5.4 Batch Development

5.4.1 MMPARISOutboundBatch Detailed Design

5.4.2 MMPARISInboundBatch Detailed Design

5.5 Non-Functional Requirements

5.5.1 Accessibility – N/A

5.5.2 Availability – N/A

5.5.3 Development Resource – N/A

5.5.4 Evolution – N/A

5.5.5 Globalization – N/A

6 Integration Points/Dependencies – N/A

7 Use Cases

7.1 Paris Exception Report Generation

7.2 PARIS Case Worker Task Generation

7.3 PARIS Interstate Response File Display

7.4 PARIS VA Response File Display

7.5 PARIS Federal Response File Display

CGIS33 PARIS V2.0 Page 13 of 129

7.6 PARIS Replacement of Previous Quarter Tasks

7.7 PARIS Search Interface

8 Appendixes

Appendix A: Action Item Matrix

Appendix B: Out of Scope Requirements – N/A

Appendix C: Comments/Resolution Log – N/A

Appendix D: Approval History

Appendix E: File Layout

Appendix F: Mapping

CGIS33 PARIS V2.0 Page 14 of 129

1 Introduction

1.1 Background

1.2 Purpose

The purpose of this document is to document the interface data exchange between Cúram and the

Public Assistance Reporting Information System (PARIS). Maintained and operated by the

Defense Manpower Data Center (DMDC), PARIS is an information exchange system designed by the Administration for Children and Families to provide State Public Assistance Agencies

(SPAAs).

Every quarter Cúram identifies eligible Medicaid recipients, and creates a file containing information requests to send to the Defense Manpower Data Center (DMDC).

Three response files are returned, based on the sent file, from PARIS with the participant’s data match information:

1. The Interstate Match - Provides information to participating states regarding possible duplicate public assistance payments Temporary Assistance for Needy Families (TANF), Medicaid, Supplemental Security Income (SSI), Food Stamps, General Assistance, Child

Care, and Workers Compensation.

2. The Veterans Administration Match - Provides information of an award amount, when a participant is receiving a Veteran’s benefit paid by the Veteran’s Administration, including spousal benefits.

3. The Federal Match – Provides information on participants that are currently receiving wages for federal and military employment, or who are receiving retirement pay for previous federal or military employment.

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 the quarterly PARIS requests and response documents within the Cúram application.

1.4 Key References

Document Name Location

CGIS33 PARIS V2.0 Page 15 of 129

MMRP CGIS PARIS Interface BRD MMRP CGIS PARIS Interface BRD

Public Assistance Reporting Information System

Public Assistance Reporting Information System

Closure Notice for termination of benefits

CGIS Closure Notice

PARIS Integration RTM Excel file PARIS Integration RTM.

1.5 Definitions and Acronyms

Term Definition

A&A Aid and Attendance

BRD Business Requirements Document

CGIS Cúram Global Income Support

CoC Change of Circumstance - Any change in an Individual's/Household's information which potentially impacts eligibility.

COLA Cost of Living Adjustment

CRCF Community Residential Care Facility

DEERS Defense Enrollment Eligibility Reporting System

DHHS Department of Health and Human Services

DMDC Defense Manpower Data Center

DOB Date of Birth

DOD Date of Death

DoD Department of Defense

DSS Department of Social Services

EDS Enterprise Data Service

FPL Federal Poverty Level

GH General Hospital

HCR Health Care Reform

IEG Script Intelligence Evidence Gathering Script

MMRP Member Management Replacement Program

PARIS Public Assistance Reporting Information System

SME Subject Matter Expert

SSA Social Security Administration

SSI Supplemental Security Income

SSN Social Security Number https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/CGIS33%20PARIS%20Interface%20BRD.docx?d=w855d97c4f57a491a9a4e14d6bcfbdae6&csf=1&web=1&e=wcZ61Z https://www.acf.hhs.gov/paris/state https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Closure-CGIS.docx?d=wd4c5cc59e3ac4fd9b34b2bee16496891&csf=1&web=1&e=KLrSol https://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS33%20PARIS%20Interface%20ADD%20RTM.xlsx?d=w98272ff386b942d0bbeac79fe429db8b&csf=1&web=1&e=x7ek7f

CGIS33 PARIS V2.0 Page 16 of 129

Term Definition

TANF Temporary Assistance for Needy Families

VA Veterans Administration

VA Veteran’s Affairs

WD Working Disabled

1.6 Key Assumptions

This document assumes the following:

a. All Cúram Medicaid cases are considered for PARIS integration.

b. MEDS will use existing file transfer process and will transfer the file to DMDC via

Connect Direct.

c. For PARIS response file processing, Cúram database tables will be created to store all response file data elements for presentation on the new screens. Work in the technical design (TDS) will design the tables as well as the mapping of response file data to database elements in those tables.

d. The PARIS workflow will follow the standard Notices process.

e. Changes will need to be made to accommodate when MEDS is sunset.

CGIS33 PARIS V2.0 Page 17 of 129

2 Conceptual Flow

The flows captured within this section provide a high-level overview of the Interface file exchange process between Cúram and DMDC.

2.1 Quarterly Outbound PARIS Request File

CGIS33 PARIS V2.0 Page 18 of 129

2.1.1 Quarterly Outbound PARIS Interstate File Narrative

# Action # Action Label Narration

1 Startpage System starts the process of selecting the data and sending the outbound PARIS request file to DMDC.

2 (2) Consolidate Data of All Eligible Medicaid Members in Cúram With Verified SSN

The system selects all members in Cúram who are currently eligible for Medicaid benefits and who have their SSN’s verified.

3 (3) Perform File Data Validation

ESB performs data validation of the records selected for the outbound request file to PARIS.

4 (4) Valid Records? ESB checks if all the mandatory fields required to be populated in the outbound request file to PARIS are present in the file and in the required format.

5 (5) Generate Exception Report

If a record is not valid i.e. the record is missing mandatory data, or the format is not valid, then an exception report is generated. For valid records, the system proceeds to step 7.

6 (11) MEDS collects Eligible Medicaid Members

MEDS system selects all members eligible for Medicaid for input to the PARIS request file. It will be merged with the Cúram PARIS file in step 7.

7 (6) File Delivered to ESB ESB receives the outbound request file to PARIS from MEDS and proceeds to step 7.

8 (7) Merge Cúram Records with MEDS Records

ESB proceeds to merge the records present in the

MEDS PARIS Request file with the Cúram PARIS file and remove duplicate records to create the consolidated outbound request file to PARIS.

9 (8) Duplicate Records? ESB checks for the presence of duplicate records in the

Cúram and MEDS during the file merge. The values to be checked by the system for duplicate records are:

SSN

First Name

Last Name

Date of Birth

CGIS33 PARIS V2.0 Page 19 of 129

# Action # Action Label Narration

10 (8.1) Generate Exception Report

If duplicate records exist, then the records from the MEDS file will be removed during the outbound file consolidation and an exception report is generated

11 (8.2) Populate Outbound PARIS Request File

Once the data has been consolidated, ESB proceeds to populate the outbound file.

12 (9) File Delivered to MEDS 1. ESB proceeds to transfer the consolidated outbound request file to MEDS.

13 (10) File Delivered to DMDC MEDS proceeds to send the request file using connect direct. DMDC will process the request and send back responses for Interstate, VA and Federal.

2.2 Quarterly Inbound PARIS Interstate Response File

CGIS33 PARIS V2.0 Page 20 of 129

2.2.1 Quarterly Inbound PARIS Interstate File Narrative

1 Start Once the match is completed, the process of sending the PARIS Interstate response file from DMDC begins.

2 (2) PARIS Interstate Response File

DMDC on the scheduled date sends the PARIS Interstate response file to MEDS.

3 (3) MEDS Receives the File MEDS receives the file and sends it to ESB.

4 (4) Perform File Data Validation

ESB stores the data from the file and checks if all the mandatory fields are populated in the file and are in the valid format.

5 (5) Valid Records? Record level processing applies to each record until all records have been processed.

For each record that is not valid, the system proceeds to step 6.

For valid records, the system proceeds to step 7.

This happens until all records are processed.

6 (6) Generate Exception Report

For records that are not valid i.e. the record is missing mandatory data, or the format is not valid, then the record is included on an exception report that is generated.

7 (7) SSN Found? The system proceeds to match the SSN in the response file against Cúram.

9 (9) Is Member Eligible for Benefits in any State(s) Other Than SC

If an SSN match is found, the system proceeds to read the State (positions 286-287), that the member is receiving TANF, Food Stamps, General Assistance, SSI and Medicaid benefits in.

11 (11) Task is Assigned to the PARIS Work Queue

If the State is not ‘SC’ then the interface process will raise a task and assign it to the PARIS work queue.

12 (12)/ (12.1) (12) Caseworker Starts Follow Up Process (12.1) Is Member Currently Living in SC?

Once the task is assigned to the PARIS work queue, the case worker starts an outreach process to find out if the member currently lives in South Carolina.

13 (12.2)/ (12.3) (12.2) Caseworker Makes Sure That Benefits Are Active (12.3) Caseworker Closes the Task

Upon follow up if the caseworker finds that the member lives in South Carolina, the case worker ensures that the member’s benefits are active in Cúram and manual outreach process ends. The case worker closes the task.

14 (12.4)/ (12.5) (12.4) Caseworker Determines That Member is Receiving Benefits (12.5) Caseworker Terminates Member’s Benefits in SC

2. Upon follow up if the caseworker finds that the member does not live in South Carolina, the case worker terminates the member’s benefits in Cúram.

CGIS33 PARIS V2.0 Page 21 of 129

# Action # Action Label Narration

15 (12.6) Notice Sent to The Member Informing About Benefit Termination

An eligibility termination notice is sent to the member.

16 (12.7) Caseworker Closes the Task

The caseworker closes the task.

2.3 Quarterly Inbound PARIS VA Response File

2.3.1 Quarterly Inbound PARIS VA File Narrative

1 Start Once the match is completed, the process of sending the PARIS VA response file in DMDC begins.

2 (2) PARIS VA Response File

DMDC on the scheduled date sends the PARIS Interstate response file to MEDS.

3 (3) MEDS Receives the File MEDS receives the file and sends it to ESB.

CGIS33 PARIS V2.0 Page 22 of 129

# Action # Action Label Narration

4 (4) Perform File Data Validation

ESB stores the data from the file and checks if all the mandatory fields are populated in the file and in the valid format.

5 (5) Valid Records? If a record is not valid, the system proceeds to step 6.

For valid records, the system proceeds to step 7.

6 (6) Generate Exception Report

For records that are not valid i.e. the record is missing mandatory data, or the format is not valid, then an exception report is generated.

7 (7) Display the Data The VA response is displayed in Cúram.

2.4 Quarterly Inbound PARIS Federal Response File

2.4.1 Quarterly Inbound PARIS Federal Response File

Narrative

CGIS33 PARIS V2.0 Page 23 of 129

# Action # Action Label Narration

1 Start Once the match is completed, the process of sending the PARIS Federal response file in DMDC begins.

2 (2) PARIS Federal Response File

DMDC on the scheduled date sends the PARIS Federal response file to MEDS.

3 (3) MEDS Receives the File MEDS receives the file and sends it to ESB.

4 (4) Perform File Data Validation

ESB stores the data from the file and checks if all the mandatory fields are populated in the file and in the valid format.

5 (5) Valid Records? If a record is not valid, the system proceeds to step 6.

For valid records, the system proceeds to step 7.

6 (6) Generate Exception Report

For records that are not valid i.e. the record is missing mandatory data, or the format is not valid, then an exception report is generated.

7 (7) Display the Data The Federal response is displayed in Cúram.

CGIS33 PARIS V2.0 Page 24 of 129

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

PARIS Integration 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 Requirements 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://schhs.sharepoint.com/:x:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS33%20PARIS%20Interface%20ADD%20RTM.xlsx?d=w98272ff386b942d0bbeac79fe429db8b&csf=1&web=1&e=x7ek7f

CGIS33 PARIS V2.0 Page 25 of 129

4 Functions

4.1 Quarterly Outbound PARIS Interstate Request File

4.1.1 Design Description

This section provides a description of the events in Cúram and the selecting the records for the quarterly outbound PARIS interstate request file

4.1.2 Functional Output

1. The system will select all members with verified SSNs, who are eligible for Medicaid in

Cúram

2. The system will validate the records and generate reports for records that were not successfully generated on the PARIS request file.

3. A file merge and transfer process will occur to merge the Cúram PARIS request file with the

MEDS PARIS request file in Cúram and send the consolidated file to MEDS.

4. MEDS will send the consolidated PARIS request file to SSA via Connect Direct

4.1.3 Design Details

Selection Criteria for The Quarterly Outbound PARIS Request File

CGIS_PARIS_1.1 The system shall send a request for Interstate match to PARIS for all eligible

Medicaid members whose SSN is verified in Cúram excluding those eligible on PCAT 89.

CGIS_PARIS_1.2 The system shall send a request for VA match to PARIS for all eligible

CGIS_PARIS_1.3 The system shall send a request for Federal match to PARIS for all eligible

Quarterly Outbound PARIS Request File Merge

CGIS_PARIS_1.7 The system shall merge the MEDS PARIS Request file with the Cúram

PARIS Request file and remove duplicate records to create the consolidated PARIS outbound request file.

CGIS_PARIS_1.8 The system shall remove duplicate records that contain the same value for all the following data elements:

SSN

First Name

CGIS33 PARIS V2.0 Page 26 of 129

Last Name

Date of Birth

CGIS_PARIS_1.9 When duplicate records exist, the system will delete the MEDS provided record and keep the Cúram provided record in the PARIS file.

Quarterly Outbound PARIS Request File Data Population

CGIS_PARIS_1.10 Once the processing logic on the outbound file data set is complete, the system shall populate the outbound file. Field mapping of the request file has been included in

Appendix F.

File Transfer Process

CGIS_PARIS_1.11 Cúram will send the consolidated quarterly outbound PARIS request file to

MEDS.

PARIS Response Search Screen

CGIS_PARIS_1.14 The case worker shall be able to search for PARIS response data.

CGIS_PARIS_1.15 The case worker shall be able to select a date range to search for PARIS response data.

PARIS Interstate Response

CGIS_PARIS_1.18 The caseworker shall be able to access interface data for PARIS by selecting the corresponding page from the page group navigation bar.

CGIS_PARIS_1.19 The system shall display all the responses received from PARIS for the member.

CGIS_PARIS_1.20 The system shall display the PARIS Interstate match response received from PARIS.

PARIS VA Response

CGIS_PARIS_1.21 The system shall display the VA response received from PARIS.

PARIS Federal Response

CGIS_PARIS_1.22 The system shall display the Federal response received from PARIS.

CGIS33 PARIS V2.0 Page 27 of 129

4.1.4 Screen Flow

4.1.5 Screen Mockup

4.1.5.1 PARIS Response Search Screen

Fig: Interface Data Search Screen

CGIS33 PARIS V2.0 Page 28 of 129

4.1.5.1.1 Data Fields

# Screen Label Element Type Narration

Interface Data Tab The Interface Data tab will be in the navigation bar at the person level. This tab will contain the interface data details for the applicable CGIS interfaces.

PARIS Page The PARIS page will be displayed in the page group navigation bar within the Interface Data tab. The PARIS page will contain the interface data details and requests and responses for the applicable person.

Search Page The search page is the default page when a person clicks on the “Interface Data” tab. It is common to all the interfaces.

4 Select Interface Field A list of available interfaces.

5 Select Type Field Response

6 Date Range Field From and to dates.

4.1.5.2 PARIS Interstate Response Screen

Figure: PARIS Display Responses Screen

4.1.5.2.1 Data Fields

# Screen Label Element Type Narration

Requester’s User Id

Field The person asking for the verification. It can be manually requested by caseworker or generated by System.

2 Transaction Date Field The date and time of the request or response.

Type of Response Field Either Interstate Response or VA Response or Federal

Response.

CGIS33 PARIS V2.0 Page 29 of 129

4.1.5.2.2 Links – Functions/Actions

# Name New/ Modified/ Delete

Details

1. View New Clicking on ‘View’ will display a modal with all the response fields.

4.1.5.3 PARIS Interstate Match Response Screen

Figure: PARIS Interstate Match Response Screen

CGIS33 PARIS V2.0 Page 30 of 129

4.1.5.4 PARIS VA Response Screen

Figure: PARIS VA Match Response Screen

4.1.5.5 PARIS Federal Response Screen

Figure: PARIS Federal Match Response Screen

CGIS33 PARIS V2.0 Page 31 of 129

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

4.1.8 4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validations – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Reports

PARIS_RPT_1.22: The system shall generate an exception report when the outbound file has been sent to SSA

MMRPPAR1000R02 – PARIS Outbound Request Exceptions Report

Report Details

a. Scheduled: Quarterly, when the outbound PARIS request file is generated in Cúram

b. Frequency: Quarterly

c. Output: Quarterly – Stored in SharePHI Location

Requirements

Selection Criteria: Select all eligible Medicaid members who have missing SSN, a pseudo SSN, an alternate recipient number or a missing date of birth.

Report Fields

# Report Label

1. Medicaid ID

2. SSN

3. Last Name

4. First Name

5. Date of Birth

6. Reason for Exception

7. Applying or Not Applying

8. PCAT

CGIS33 PARIS V2.0 Page 32 of 129

PARIS_RPT_1.24: The system shall generate a quarterly control totals reports when the outbound PARIS request file is generated.

MMRPPAR1000R01 –Control Totals Report

Report Details

a. Scheduled: Quarterly, once the Cúram outbound PARIS request file is merged with

MEDS outbound PARIS request file

Selection Criteria: Totals are to be generated in report form of number of records read, exceptions, records written, duplicates dropped, and number of records sent.

1. Type of record count record

2. Number of records read

3. Number of exceptions

4. Number of records written

5. Number of duplicates dropped

6. Number of records sent

4.2 Quarterly Inbound Interstate Match Response File

This section provides a description of the processing in Cúram once the inbound PARIS

Interstate match response file is received. It contains information about Medicaid eligible members who are receiving benefits in any state other than South Carolina.

4.2.1 Design Description

This section provides a description what happens in Cúram once the PARIS Interstate match file is received by Cúram

4.2.2 Functional Output

1. Interface process will store the Interstate match response

2. Interface process will read all open tasks of type “PARIS match response” for the previous quarter and close them

3. Interface process will raise a task and assign the task to the PARIS Work queue for members who has no eligibility end date for Medicaid, TANF, General Assistance, Food Stamps and

SSI benefit in the response file

4. An eligibility termination notice will be sent to the member whose Medicaid benefits were terminated by the case worker

5. Interface process will display the information in Cúram

CGIS33 PARIS V2.0 Page 33 of 129

4.2.3 Design Details

CGIS_PARIS_2.1 The system shall validate the following fields in the PARIS Interstate match response file per the requirements below: Client SSN, Client Surname, Client First Name, Client

Date of Birth, Match Run Month

CGIS_PARIS_2.1.1: ‘clientSSN’ must be a 9-digit number and must not start with ‘9’.

CGIS_PARIS_2.1.2: ‘clientLastName’ must be alpha characters, -, or ‘ only.

CGIS_PARIS_2.1.3: ‘clientFirstName’ must be alpha characters, - , or ‘ only.

CGIS_PARIS_2.1.4: ‘clientDateOfBirth’ must be a valid CCYYMMDD format and cannot be in the future.

CGIS_PARIS_2.1.5: The system will not validate the following fields; any invalid values will be displayed as they exist on the file:

• State Name (stateName)

• TANF Indicator (tanfInd)

• General Assistance Indicator (generalAssistanceInd)

• Food Stamp Indicator (foodStampInd)

• SSI Indicator (ssiInd)

• Medicaid Indicator (medicaidInd)

CGIS_PARIS_2.1.6: ‘matchRunMonth” must be a valid CCYYMM format and cannot be in the future. In the file data element position is 49-54.

CGIS_PARIS_2.2 The system shall identify all the open tasks of type “PARIS match response” for the previous quarter and close them

CGIS_PARIS_2.3 The system shall assign a task to the PARIS work queue for members who are receiving benefits in any State other than South Carolina with no eligibility end date in the response file. This applies to Medicaid, TANF, Food Stamps, General Assistance and SSI. One task will be assigned for a member whether they have one or multiple benefits in other states.

All previous quarter tasks have been removed for each member as a previous step

CGIS_PARIS_2.3.0. For the current quarter, no more than one task should be assigned for any member.

CGIS_PARIS_2.3.1 If the member does not already have a task assigned to the PARIS work queue, the system shall assign a task to the PARIS work queue for members who are receiving Medicaid benefits in any State other than South Carolina with no eligibility end date in the response file.

CGIS_PARIS_2.3.2 If the member does not already have a task assigned to the PARIS work queue, the system shall assign a task to the PARIS work queue for members who

CGIS33 PARIS V2.0 Page 34 of 129 are receiving TANF benefits in any State other than South Carolina with no eligibility end date in the response file.

CGIS_PARIS_2.3.3 If the member does not already have a task assigned to the PARIS work queue, the system shall assign a task to the PARIS work queue for members who are receiving Food Stamps benefits in any State other than South Carolina with no eligibility end date in the response file.

CGIS_PARIS_2.3.4 If the member does not already have a task assigned to the PARIS work queue, the system shall assign a task to the PARIS work queue for members who are receiving General Assistance benefits in any State other than South Carolina with no eligibility end date in the response file.

CGIS_PARIS_2.3.5 If the member does not already have a task assigned to the PARIS work queue, the system shall assign a task to the PARIS work queue for members who are receiving SSI benefits in any State other than South Carolina with no eligibility end date in the response file.

Note: The case worker shall terminate the Medicaid benefits in Cúram of members who do not reside in South Carolina.

CGIS_PARIS_2.4 The system shall trigger the sending of an eligibility termination notice to the member whose benefits were terminated by the case worker.

CGIS_PARIS_NOTICE_2.4 An eligibility termination notice is sent to the member whose

Medicaid benefits were terminated by the case worker. The CGIS Closure Notice is used as the notice template form termination of benefits. Key input includes:

• Name

• Medicaid ID

• End Date

• Reason Code Text

• Policy Reference

• Federal Regulation Citations

CGIS_PARIS_2.5 The system shall store all the Interstate match response received for historical purposes.

The case worker shall be able to view the Interstate match response.

• A caseworker will open the appropriate Person Page, select the interface data tab located in the navigation bar, and select the PARIS tab from the page group navigation bar.

• From this location, the caseworker will select “View” under the “View Response” heading with the “Type of Response” being “Interstate” Response.

file:///C:/Users/IBM_ADMIN/Downloads/Closure-CGIS.docx

CGIS33 PARIS V2.0 Page 35 of 129

4.2.4 Screen Flow

Please refer to section 4.1.4 for the screen flow.

4.2.5 Screen Mockup

Please refer to section 4.1.5.2 for the Interstate Match Response screen

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks

This task is raised to notify the case worker that an eligible Medicaid member in Cúram is receiving Medicaid, Food Stamps, TANF, General Assistance or SSI benefits in another state.

Task Alert Name: Member receiving benefit in another State.

Purpose: Generate a task when an eligible Medicaid member in Cúram is receiving Medicaid, Food Stamps, TANF, General Assistance or SSI benefits in another state.

Trigger(s): Generate a task when an eligible Medicaid member in Cúram is receiving Medicaid, Food Stamps, TANF, General Assistance or SSI benefits in another state.

Allocation Strategies

Organization Specialist Consulted

Yes N/A

Allocation Type User Position Job Org Unit Queue

Allocation Strategy Task will be allocated to PARIS work queue.

Link Link Yes No

Primary Action Link The case worker will be led to the PARIS response screen in the person home page

Supporting Action Link None

CGIS33 PARIS V2.0 Page 36 of 129

Page Target (ID)

None

Subject Text (200 limit)

Member receiving benefits in multiple states.

Confirm correct state of residence.

Subject Deadline Strategy 30 days

Task Details Escalation Strategy N/A

Deadline Override Allowed No

Task Priority Low Medium High

Manual Forwarding Allowed Yes No

Manual Close Allowed Yes No

Automatic Task Closure Instructions

Yes No

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

Yes No

Task Information

Message Body (3400 limit) Member receiving benefits in multiple states.

Confirm correct state of residence.

Alert Details Message Body (3400 limit)

4.2.13 Reports

PARIS_RPT_2.12: The system shall generate an Interstate match response quarterly control totals reports once the inbound PARIS Interstate response file is processed in Cúram.

MMRPPAR2000R01 – PARIS Interstate Match Response Control Totals Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

CGIS33 PARIS V2.0 Page 37 of 129

Requirements

Selection Criteria: Count the total number of records in the PARIS Interstate response file, number of records that were not processed because the record is missing mandatory data, or the format is not valid, number of records that were in the request file that matched with the response file, number of records that has a successful SSN match, number of records that are not Medicaid eligible, and the number of tasks created.

1. Number of Records Received from PARIS

2. Number of Exceptions

3. Number of Records Matched Request File

4. Number of Records Dropped (no longer Medicaid eligible)

5. Number of Matches Found

6. Number of Tasks Created

PARIS_RPT_2.13: The system shall generate a quarterly Interstate match response error reports once the inbound PARIS Interstate response file is processed in Cúram.

MMRPPAR2000R02 – PARIS Interstate Match Response Error Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

Selection Criteria: Count the total number of records in the PARIS Interstate response file that were not processed because the record is missing mandatory data, or the format is not valid.

1. First Name

2. Last Name

3. Date of Birth

4. SSN

5. Medicaid ID

PARIS_RPT_2.14: The system shall generate a quarterly Interface Match response summary report once the inbound PARIS Interstate response file is processed in Cúram.

MMRPPAR2000R03 –PARIS Interstate Match Response Summary Report

Report Details

CGIS33 PARIS V2.0 Page 38 of 129

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

Selection Criteria: Count the total number of members receiving Medicaid, TANF, Food Stamps, General Assistance, SSI, Child Care and Workers Compensation benefits in South Carolina and any other State with no eligibility end date in the PARIS Interstate response file and display state totals by each state.

1. State

2. Total

PARIS_RPT_2.15: The system shall generate a no match report for the quarterly Interstate match response once the inbound PARIS Interstate response file is processed in Cúram.

MMRPPAR2000R04 –PARIS Interstate Match Response No Match Exception Report

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

Selection Criteria: Select number of members receiving Medicaid, TANF, Food Stamps, General

Assistance, SSI, Child Care or Workers compensation for whom SSN did not match while processing the PARIS Interstate match response file.

1. Name

2. SSN

3. Date of Birth

4. State

5. Phone

6. TANF

7. Medicaid

8. Food Stamps

9. General Assistance

10. SSI

CGIS33 PARIS V2.0 Page 39 of 129

# Report Label

11. Child Care

12. Workers Compensation

PARIS_RPT_2.16: The system shall generate an exception report for the quarterly Interstate match response once the inbound PARIS Interstate response file is processed in

Cúram.MMRPPAR2000R05 – PARIS Interstate Match Response Exception Report

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

Selection Criteria: Select the number of records in the PARIS Interstate match response file which failed mandatory fields or field format validation.

1. Medicaid ID

2. SSN

3. Name

4. Field in error

5. Reason

PARIS_RPT_2.17: The system shall generate a quarterly Interstate Matches by State report once the inbound PARIS Interstate response file is processed in Cúram.

MMRPPAR2000R06 – PARIS Interstate Matches by State Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS Interstate response file is processed in Cúram

Selection Criteria: Select the members receiving Medicaid, TANF, Food Stamps, General

Assistance, SSI, Child Care and Workers Compensation benefits in South Carolina and any other

State with no eligibility end date in the PARIS Interstate response file.

CGIS33 PARIS V2.0 Page 40 of 129

1. State

2. SSN

3. First Name

4. Last Name

5. Date of Birth

6. Sex

7. Member ID

8. County Contact

9. Medicaid

10. SSI

11. TANF

12. General Assistance

13. Food Stamps

14. Child Care

15. Workers Compensation

4.3 Quarterly Inbound VA Match Response File

This section provides a description of the processing in Cúram once the inbound PARIS VA match response file is received by Cúram and contains information about Medicaid eligible members receiving Veterans Administration benefits.

4.3.1 Design Description

This section provides a description what happens in Cúram once the PARIS VA match file is received by Cúram

4.3.2 Functional Output

1. Interface process will store the VA match response

2. Interface process will display the information in Cúram

4.3.3 Design Details

CGIS_PARIS_3.1 The system shall validate the following fields in the VA match response file per the requirements below: Client SSN, Client Surname (Last Name), Client First Name, Client

Date of Birth.

CGIS_PARIS_3.1.1: ‘clientSSN’ must be a 9-digit number and must not start with ‘9’.

CGIS_PARIS_3.1.2: ‘clientLastName’ must be alpha characters, -, or ‘ only.

CGIS_PARIS_3.1.3: ‘clientFirstName’ must be alpha characters, - , or ‘ only.

CGIS33 PARIS V2.0 Page 41 of 129

CGIS_PARIS_3.1.4: ‘clientDateOfBirth’ must be a valid CCYYMMDD format and cannot be in the future.

CGIS_PARIS_3.2 The system shall store all the VA match response received for historical purposes.

The case worker shall be able to view the VA match response.

in the navigation bar, and select the PARIS tab from the page group navigation bar.

• From this location, the caseworker will select “View” under the “View Response” heading with the “Type of Response” being “VA” Response.

4.3.4 Screen Flow

Please refer to section 4.1.4 for the screen flow.

4.3.5 Screen Mockup

Please refer to section 4.1.5.3 for the VA Match Response screen

4.3.6 Business Rules – N/A

4.3.7 User Roles – N/A

4.3.8 Data Fields – N/A

4.3.9 Links – Navigation – N/A

4.3.10 Links – Functions/Actions – N/A

4.3.11 Validation – N/A

4.3.12 Notifications and Tasks – N/A

4.3.13 Reports

PARIS_RPT_3.4: The system shall generate a quarterly VA match control totals report once the inbound PARIS VA response file is processed in Cúram.

MMRPPAR3000R01 – PARIS VA Match Response Control Totals Report

CGIS33 PARIS V2.0 Page 42 of 129

a. Scheduled: Quarterly, once the Inbound PARIS VA response file is processed in

Cúram

Selection Criteria: Count the total number of records in the PARIS VA response file, number of records that were not processed because the record is missing mandatory data, or the format is not valid and number of records that were processed in Cúram.

1. Number of Records Received from PARIS

2. Number of Exceptions

3. Number of Records Processed

PARIS_RPT_3.5: The system shall generate a quarterly VA match response error reports once the inbound PARIS VA response file is processed in Cúram.

MMRPPAR3000R02 – PARIS VA Match Response Error Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS VA response file is processed in

Cúram

Selection Criteria: Count the total number of records in the PARIS VA response file that were not processed because the record is missing mandatory data, or the format is not valid.

1. First Name

2. Last Name

3. Date of Birth

5. Reference ID

CGIS33 PARIS V2.0 Page 43 of 129

4.4 Quarterly Inbound Federal Match Response File

This section provides a description of the processing in Cúram once the inbound PARIS Federal match response file is received by Cúram and contains information about Medicaid eligible members receiving Federal benefits.

4.4.1 Design Description

This section provides a description what happens in Cúram once the PARIS Federal match file is received by Cúram

4.4.2 Functional Output

1. Interface process will validate the mandatory fields in the Federal match response file

2. Interface process will display the information in Cúram

4.4.3 Design Details

CGIS_PARIS_4.1 The system shall validate the following fields in the Federal match response file per the requirements below: Client SSN, Client Surname, Client First Name, Client Date of

Birth.

CGIS_PARIS_4.1.1: ‘clientSSN’ must be a 9-digit number and must not start with ‘9’.

CGIS_PARIS_4.1.2: ‘clientLastName’ must be alpha characters, -, or ‘ only.

CGIS_PARIS_4.1.3: ‘clientFirstName’ must be alpha characters, - , or ‘ only.

CGIS_PARIS_4.1.4: ‘clientDateOfBirth’ must be a valid CCYYMMDD format and cannot be in the future.

CGIS_PARIS_4.2 The system shall store all the Federal match response received for historical purposes.

The case worker shall be able to view the Federal match response.

in the navigation bar, and select the PARIS tab from the page group navigation bar.

• From this location, the caseworker will select “View” under the “View Response” heading with the “Type of Response” being “Federal” Response.

4.4.4 Screen Flow

Please refer to section 4.1.4 for the screen flow.

CGIS33 PARIS V2.0 Page 44 of 129

4.4.5 Screen Mockup

Please refer to section 4.1.5.4 for the Federal Match Response screen

4.4.6 Business Rules – N/A

4.4.7 User Roles – N/A

4.4.8 Data Fields – N/A

4.4.9 Links – Navigation – N/A

4.4.10 Links – Functions/Actions – N/A

4.4.11 Validation – N/A

4.4.12 Notifications and Tasks – N/A

4.4.13 Reports

PARIS_RPT_4.4: The system shall generate a quarterly Federal match control totals report once the inbound PARIS Federal response file is processed in Cúram.

MMRPPAR4000R01 – PARIS Federal Match Response Control Totals Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS Federal response file is processed in

Cúram

Selection Criteria: Count the total number of records in the PARIS Federal response file, number of records that were not processed because the record is missing mandatory data, or the format is not valid and number of records that were processed in Cúram.

1. Number of Records Received from PARIS

2. Number of Exceptions

3. Number of Records Processed

CGIS33 PARIS V2.0 Page 45 of 129

PARIS_RPT_4.5: The system shall generate a quarterly Federal match response error reports once the inbound PARIS Federal response file is processed in Cúram.

MMRPPAR4000R02 – PARIS Federal Match Response Error Report

Report Details

a. Scheduled: Quarterly, once the Inbound PARIS Federal response file is processed in

Cúram

Selection Criteria: Count the total number of records in the PARIS Federal response file that were not processed because the record is missing mandatory data, or the format is not valid.

1. First Name

2. Last Name

3. Date of Birth

5. Reference ID

CGIS33 PARIS V2.0 Page 46 of 129

5 Technical Design This section describes the technical architecture of the system.

5.1 Common Technical Artifacts

Outbound Processing of Records:

A quarterly outbound file will be generated by ESB using data provided by Cúram. The

MMPARISOutbound batch will implement chunker and streamer batch classes to select all members with verified SSNs who are eligible for Medicaid in Cúram by searching the EDD table for concernRoleIDs with Medicaid eligibility. Selected records will be loaded into an entity and used by ESB for file generation. After records are processed, the data will be available for search and display at the person level under the “Interface Data” tab.

Inbound Record Processing:

The processing of inbound records will be implemented by the MMPARISInboundBatch through use of Cúram chunker and streamer batch classes. Incoming data will be loaded into three entities, one per response type, by the ESB layer which triggers processing. Record processing will consist of person search and match, task closure/generation, and notice and reports generation.