PL0019 - Foster Care.pdf

South Carolina Department of Health and Human Services

(SCDHHS)

Member Management Replacement Program (MMRP)

Health Care Reform (HCR) and

Cúram Global Income Support (CGIS) Integration

Approach Document (AD)

HCR Department of Social Services (DSS) Integration

MMRP CGIS Project HCR/CGIS Integration DSS AD v1.0

Version Log

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

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

Version Date Drafted by Role Description of Change

V0.1 12/4/18 Amir Iqbal Business Analyst Initial draft.

V0.2 2/21/19 Amir Iqbal Business Analyst Updated based on cycle 1 comments.

V0.3 03/06/19 Ken Haas IBM Functional Process Lead

QA and Clarity Review

V0.4 04/24/19 Amir Iqbal Business Analyst Updated design to align with updated SDX design.

V0.5 5/7/19 Amir Iqbal Randhir Singh

Business Analyst Dev lead

Updated the document based on the review comments received.

V0.6 5/20/19 Amir Iqbal Randhir Singh

Business Analyst Dev lead

Updated based on the second round of comments received from the state.

V0.7 6/12/19 Amir Iqbal Business Analyst Updated for state final round of comments.

V0.8 6/24/19 Amir Iqbal Business Analyst Corrected the requirement number referenced in the 4th entry of table in the section 4.2.3. Changed from INT_DSS_REQ_.1.2.1 to

INT_DSS_REQ_.2.2.1.

V0.9 9/3/20 Tiffany Ortega IBM BA Lead Updated the template, spelling and grammar check for formal approval

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

Updated the date, version, and watermark to reflect approval. Updated section headers and Table on Contents. Accepted all track changes.

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

Second Review / Reviewer Name

Third Review / Reviewer Name

DDI Manager 1/12/2019

Product Manager 1/14/2019 3/11/2019 4/30/2019

Technical Lead 3/12/2019 5/6/2019

5/17/2019 ()

Business Analyst 1/14/2019 3/11/2019 4/30/2019

UAT Lead 1/14/2019 Carissa Onorato

3/12/2019 Carissa Onorato

05/03/2019 Carissa Onorato

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

Second Review / Reviewer Name

Third Review / Reviewer Name

Technical Lead 3/12/2019 5/17/2019 5/21/2019

IBM Approval Review Log

The IBM Approval Review Log captures that the AD and 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 review and Approval.

Functional Design Section

Technical Design Section

IBM Functional Design Review – v1.0

Role Name Date Comments

CGIS Project Manager Courtney Stevens 9/4/2020 Approved v0.9 to v1.0

CGIS BA Lead Tiffany Ortega 9/3/2020 Approved v0.9 to v1.0

CGIS Testing Lead Brian Grieves 9/4/2020 Approved v0.9 to v1.0

CGIS Business Analyst Amir Iqbal 9/3/2020 Approved v0.9 to v1.0

CGIS Development Lead Vijay Mujumdar 9/4/2020 Approved v0.9 to v1.0

CGIS Development Team Lead Sandeep Burman 9/4/2020 Approved v0.9 to v1.0

IBM Technical Design Review – v1.0

Role Name Date Comments

CGIS Development Lead Vijay Mujumdar 9/4/2020 Approved v0.9 to v1.0

CGIS Development Team Lead Sandeep Burman 9/4/2020 Approved v0.9 to v1.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 a subsequent 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 v1.0

Role Name Date Comments

SCDHHS DDI Manager Tim Cozine 5/22/2019

SCDHHS Product Manager Abhishek Sahu 5/22/2019 6/27/2019 –

CR 23

SCDHHS Technical Lead Renjan Bhasi 6/27/2019 –

CR 23

SCDHHS Business Analyst Abhishek Sahu 5/22/2019

SCDHHS Process & Artifact Development Manager

Erin Coleman 9/29/2020 Approved AD

Technical Design Section

Technical Design Approval v1.0

Role Name Date Comments

SCDHHS Technical Lead Renjan Bhasi 5/21/2019 Approved (FDS and TDS).

Table of Contents

1 Introduction

1.1 Background

1.2 Purpose

1.3 Scope – N/A

1.4 Key References

1.5 Definitions & Acronyms

1.6 Key Assumptions

1.7 Alignment Overview

1.8 Approach Focus

2 Conceptual Flow

2.1 Existing Flow

2.1.1 Existing Flow Narrative

2.2 Modified Flow

2.2.1 Modified Flow Narrative

3 Requirements Matrix Realignment

3.1 Requirement Modifications – N/A

4 Functions

4.1 Check if Member has CGIS Eligibility

4.1.1 Design Description

4.1.2 Functional Output

4.1.3 Design Details - Requirements Addressed

4.1.4 Screen Flow – N/A

4.1.5 Screen Mockup – N/A

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validation – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Check for Foster Care Recipient for Whom Service Closed

4.2.1 Design Description

4.2.2 Functional Output

4.2.3 Design Details - Requirements Addressed

4.2.4 Screen Flow – N/A

4.2.5 Screen Mockup – N/A

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks – N/A

4.2.13 Other – N/A

5 Technical Design

5.1 Common Technical Artifacts

5.1.1 Sequence Diagram

5.1.2 Events – N/A

5.1.3 Events Class Details – N/A

5.1.4 Domain Definitions – N/A

5.1.5 Code Tables – N/A

5.1.6 Code Tables Details – N/A

5.1.7 Messages – N/A

5.1.8 Message Detailed Description – N/A

5.1.9 DMX – N/A

5.1.10 Security – N/A

5.1.11 Security Details – N/A

5.1.12 Model

5.1.13 Interfaces – N/A

5.1.14 Facades – N/A

5.1.15 Entity Layer – N/A

5.1.16 Service Layer – N/A

5.1.17 POD Definitions – N/A

5.1.18 Java Script Changes – N/A

5.1.19 CSS Changes – N/A

5.1.20 Global Configuration Changes – N/A

5.1.21 Wizard Changes – N/A

5.1.22 Menu Details – N/A

5.1.23 Evidence Configuration Changes – N/A

5.1.24 Renderers – N/A

5.1.25 Keywords (Hover Values) – N/A

5.1.26 Help Content – N/A

5.1.27 Links – Navigation – N/A

5.1.28 Links – Functions/Actions – N/A

5.1.29 Validation – N/A

5.1.30 Workflow – N/A

5.1.31 Web Services – N/A

5.1.32 Java Classes – N/A

5.1.33 Task and Work Queues – N/A

5.1.34 Reports – N/A

5.1.35 Unit Testing Scenarios

5.1.36 Cúram Unit Testing Scenarios

5.1.37 ESB Unit Testing Scenarios – N/A

5.1.38 Data Retention – N/A

5.1.39 Persistence Requirements – 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 Components Technical Design – N/A

5.1.48 Batch Methods

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

5.1.57 Links/ Actions Controls – N/A

5.1.58 Lists/ Inline Page Details – N/A

5.1.59 Cluster Details – N/A

5.1.60 Other – N/A

5.2 ESB Development

5.2.1 Outbound – N/A

5.2.2 Inbound – N/A

5.2.3 Supporting Details: Record Layout – N/A

5.2.4 ESB Operational – N/A

5.3 Rules Development

5.3.1 Rules (Rules Areas) – N/A

5.3.2 Table of Values – N/A

5.4 Batch Development

5.4.1 Batch Overview – N/A

5.4.2 Functional Summary – N/A

5.4.3 Batch Specifications – N/A

5.4.4 Data Retention – N/A

5.4.5 Batch Classes

5.4.6 Batch Methods

6 Integration Points/Dependencies – N/A

7 Use Cases

7.1 Check if Member has CGIS Eligibility

7.1.1 Member Currently Eligible on a CGIS PCAT other than PCAT 80

7.1.2 Member Currently Eligible on a CGIS PCAT 80

7.2 Check for Foster Care Recipient for whom Service Closed

7.2.1 SC Indicator where Member has future eligibility on PCAT 80

7.2.2 Applicant Not found in MEDS but Exists in CGIS

7.2.3 Applicant Not found in MEDS and CGIS

8 Appendices

Appendix A: Action Item Matrix – N/A

Appendix B: Out of Scope Requirements – N/A

Appendix C: Comment/Resolution Log – N/A

Appendix D: Approval History – N/A

1 Introduction

1.1 Background

Incorporating the CGIS functionality into MMRP, with the implementation focus to remain as close to Out of the Box (OOTB) as possible, has led to some integration issues that need to be resolved. There were no specific business requirements that are necessitating the changes, but rather systemic, processing or current MMRP enhancements that give rise to the misaligned circumstances or create conflicting requirements.

1.2 Purpose

The Approach Document describes the conditions that require a solution, to enable the CGIS and

HCR modules to perform similar functions. The Approach Document is used to document and align requirements between the current HCR requirements and the CGIS requirements.

Requirements will be documented from both modules/projects in order to ensure proper alignment and prevent the creation of conflicting requirements.

1.3 Scope – N/A

1.4 Key References

This section lists any key documents that might be helpful to understanding the functionality which are located on the MMRP SharePoint site in the CGIS Business Requirements and Design

Documents as an Approved/Reference document under the associated track.

Document Name Location

HCR18.1 Functional Design Specification DSS Foster Care Interface SharePoint

MMRP CGIS28 HCR CGIS Integration ADD SharePoint

MMRP CGIS36 SDX Interface ADD SharePoint

1.5 Definitions & Acronyms

The list includes all the definitions of specialized terms and acronyms that will be used throughout the document.

Term Meaning

AD Approach Document

BRD Business Requirements Document.

CGIS Cúram Global Income Support.

DSS Department of Social Services

FDS Functional Design Specification.

https://schhs.sharepoint.com/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Forms/AllItems.aspx https://schhs.sharepoint.com/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/Forms/AllItems.aspx https://schhs.sharepoint.com/:w:/r/sites/1211207/Business%20Process%20Modeling%20Documents/HCR%20Tracks/Track%20HCR18.1%20-%20DSS_Foster%20Care_Interface/Approved%20Documents/MMRP%20HCR18.1%20DSS%20Foster%20Care%20FDS.docx?d=w3a98d44770b043a1b5b23d3e679d7ea9&csf=1&web=1&e=nayLcG https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS28%20HCR%20CGIS%20Integration%20ADD.docx?d=w69eab3c7f019493b92e074b863836875&csf=1&web=1&e=vocQ14 https://schhs.sharepoint.com/:w:/r/sites/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS36%20SDX%20Interface%20ADD%20V2.1.docx?d=w76df583e76714e869227ca862c98a8c1&csf=1&web=1&e=hTmcro

Term Meaning

HCR Health Care Reform

IC Integrated Case

MEDS Medicaid Eligibility Determination System.

OOTB Out of the Box

PCAT Payment Category

SC Service Closure

SCDSS South Carolina Department of Social Services.

SSI Supplemental Security Income

1.6 Key Assumptions

• No change in the process of receiving and processing of the inbound DSS file.

1.7 Alignment Overview

The alignment will cover following two main areas;

1. Applicant is currently getting benefits in CGIS either on PCAT 80 or any other CGIS

PCAT and applicant information received in the daily DSS file.

2. Applicant is currently a foster care recipient has future SSI eligibility (PCAT 80) and a Service Closure (SC) indicator is received from DSS.

1.8 Approach Focus

The document covers the changes required in the HCR DSS track to add an additional check to confirm an applicant is not currently receiving eligibility in CGIS. Prior to the implementation of

CGIS, the only other system where applicant may be getting benefits was MEDS. With the addition of CGIS, it’s possible applicant may be getting benefits in CGIS.

The document also covers the scenario, where a current foster care recipient has future SSI eligibility Payment Category (PCAT) 80 and a Service Closure (SC) is received from DSS.

2 Conceptual Flow

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

2.1 Existing Flow

DSS MEDs Check – Existing Process

ES

B

Cu ra m

1: Daily file from DSS

2: Exists in

MEDS ?

3: Store data for Report & Data File

Yes

NO

Data file is used by an external system developed by SCDHHS Platform team

4: Process Applicant Process Applicant in HCR and give eligibility according to rules defined in DSS track

Existing Process Changes to the Existing Process

New Process

Legend

5: Generate Report & Data File

Figure 1 - Existing Process Flow

2.1.1 Existing Flow Narrative

Action # Action Label Narration

1 DSS file from DSS A daily file is received from SC DSS.

2 Exists in MEDS?

Check if applicant is currently receiving eligibility in the MEDS, lasting more than 45 days.

Store data for Report & Data File

System places the applicant details in a table, if applicant is getting eligibility in MEDS and has more than 45 days of eligibility.

4 Process Applicant Process Applicant in HCR and give eligibility according to rules defined in DSS track.

Generate Report & Data File

System will generate the report (MEDS_DSS_FosterCareDDMMYYYY) and data file(MEDS_DSS_FosterCareDDMMYYYY.txt), based on the information saved in activity 3.

2.2 Modified Flow

2.2.1 Modified Flow Narrative

Action # Action Label Narration

1 DSS file from DSS A daily file is received from SCDSS.

Existing Activity, no change

2 Exists in MEDS? Check if applicant is currently getting benefits in the MEDS and have more than 45 days of eligibility.

Existing Activity, no change

3 Store data for Report & Data File

Store the applicant detail into a table, which is later going to be used to generate the report and data file.

Existing Activity, no change

Figure 2 - DSS MEDs & CGIS Check - Modified Process

Action # Action Label Narration

4 Exists in Cúram System searches the person in Cúram and determines if person exists in Cúram or not.

Existing Activity, no change

5 Process Applicant System processes the record in DSS track based on the existing logic.

Existing Activity, no change

6 Current CGIS Eligibility

System determines applicant has CGIS eligibility currently?

IF YES THEN

All indicators will go into the unsuccessful file with the appropriate error reason.

ELSE

Follow the existing DSS processing

New Activity

7 Unsuccessful Report & Data File

Existing report and data file containing records where all indicators not processed successfully.

Existing Activity, no change

8 Process Change Indicator(s)

Existing process to process the individual change indicator based on the logic defined in the existing DSS track design.

Existing Activity

9 SC Indicator & FC System determines if applicant currently is on PCAT 31 or 60 and Indicator is Service Closure.

New Activity

10 Future PCAT 80 Eligibility?

System checks if future eligibility on PCAT 80 has been established for the applicant.

New Activity

11 END HCR Eligibility System will end HCR eligibility at the end of current month.

New Activity

12 Start PCAT 80 Eligibility

System will change PCAT 80 eligibility to start from first of next month.

New Activity

13 Existing Process Indicators other than SC , or where indicator is SC but no future eligibility on PCAT 80 exists will be processed according to the existing logic defined in the DSS design.

Existing Activity

3 Requirements Matrix Realignment

HCR or

CGIS

Source

Requirem ent ID

Busines s Rule ID

Description System Feature In Scope (Yes or No)

CGIS

CGIS 28 -

HCR CGIS

Integration

INT.1.2.6 The system shall have a process to determine if a person is currently eligible in Cúram.

INT_DSS_REQ_1.1

INT_DSS_REQ_1.1.1

INT_DSS_REQ_1.2

INT_DSS_REQ_1.2.1

INT_DSS_REQ_1.2.2

INT_DSS_REQ_1.2.3

INT_DSS_REQ_1.2.4

Y

CGIS

CGIS 28 -

HCR CGIS

Integration

INT.1.11 The system shall prevent eligibility overlap for a person in HCR and CGIS

INT_DSS_REQ_2.1

INT_DSS_REQ_2.2

INT_DSS_REQ_2.2.1

INT_DSS_REQ_2.2.2

INT_DSS_REQ_2.3

INT_DSS_REQ_2.3.1

INT_DSS_REQ_2.3.2

INT_DSS_REQ_2.3.3

INT_DSS_REQ_2.3.4

INT_DSS_REQ_2.4

INT_DSS_REQ_2.4.1

INT_DSS_REQ_2.4.2

INT_DSS_REQ_2.4.2.1

INT_DSS_REQ_2.4.2.2

INT_DSS_REQ_2.5

INT_DSS_REQ_2.5.1

INT_DSS_REQ_2.6

INT_DSS_REQ_2.6.0.1

INT_DSS_REQ_2.6.1

INT_DSS_REQ_2.6.1.1

INT_DSS_REQ_2.6.1.2

INT_DSS_REQ_2.6.1.2.1

INT_DSS_REQ_2.7

Y

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.

HCR or

CGIS

Source

Requirem ent ID

Busines s Rule ID Description System Feature

Date Updated

In Scope (Yes or No)

4 Functions

4.1 Check if Member has CGIS Eligibility

4.1.1 Design Description

The Department of Social Services (DSS) sends a daily file, which includes information about new applicants, who are eligible for foster care and updates for the applicants who are currently getting foster care benefits under HCR. The existing DSS foster care implementation checks if member exists in Cúram or not. The current implementation is designed with the understanding;

if member exists in Cúram he/she can have only HCR eligibility. CGIS Release 1 will allow eligibility on CGIS PCATs as well. This functional story lists the additional business logic need to be added in the current DSS implementation to handle the scenarios where the person listed in the daily DSS file currently have eligibility on one of the CGIS PCATs.

4.1.2 Functional Output

• System processing the record from daily DSS file, one by one.

• System determines person from the DSS record exists in Cúram and has current CGIS eligibility.

• System sends the record to unsuccessful data file and report.

4.1.3 Design Details - Requirements Addressed

# Requirement Description

1 INT_DSS_REQ_1.1 System determined the person from the DSS record exists in Cúram and currently has eligibility on a CGIS PCAT.

The person from DSS record who currently has HCR eligibility will be processed according to the existing functional design of DSS. Please see the HCR18.1 Functional Design Specification DSS Foster Care Interface for details.

2 INT_DSS_REQ_1.1.1 System checks if the member has current eligibility on CGIS PCAT 80 or some other CGIS PCAT.

3 INT_DSS_REQ_1.2 System sends the record to unsuccessful file and report.

4 INT_DSS_REQ_1.2.1 The “Error Reason” column in the data file for each indicator would have following value if person currently have eligibility on CGIS PCAT 80.

“Member exist on PCAT 80, please change Placement type and person contact details.”

5 INT_DSS_REQ_1.2.2 The “Error Reason” column in the data file for each indicator would have following value if person currently have eligibility on a CGIS PCAT other than PCAT 80.

“Member exist on PCAT <PCAT> other than 80.”

<PCAT> will be replaced by actual CGIS PCAT, applicant currently has CGIS eligibility.

6 INT_DSS_REQ_1.2.3 System will populate the existing unsuccessful data file as follow for a DSS record where person is currently eligible on a CGIS PCAT.

There is no change in the layout of the existing unsuccessful data file.

Below table lists the field names in the data file and in “Comments” column describes how the data file will be populated when person currently getting benefits in CGIS.

Field Name Value Comments

Person ID Value from DSS record No change

SSN Value from DSS record No change

DOB Value from DSS record No change

First Name Value from DSS record No change

Last Name Value from DSS record No change

Prospect Match

Y or N No change

DSS Indicator Indicator No change

Error Reason Text The error reason would be based on the

INT_DSS_REQ_1.2.1

or

INT_DSS_REQ_1.2.2.

Depending upon whichever is true.

7 INT_DSS_REQ_1.2.4 System will populate the existing unsuccessful report as follow for a DSS record where person is currently eligible on a CGIS PCAT.

There is no change in the layout of the existing unsuccessful report.

Below table lists the report columns and in “Comments” column describes how the report will be populated when person currently getting benefits in CGIS.

Report Column

Value Comments

Person ID Value from DSS record No change

SSN Value from DSS record No change

DOB Value from DSS record No change

First Name Value from DSS record No change

Last Name Value from DSS record No change

Prospect Match

Y or N No change

Indictors Processed Successfully

Blank

No change None of the indicators processed successfully as member currently has CGIS eligibility

First Indicator not processed with error reason

First Indicator with error reason

The error reason would be based on the INT_DSS_REQ_1.2.1 or

INT_DSS_REQ_1.2.2.

Depending upon whichever is true.

Other Indicators not processed

All other indicators No change

4.1.4 Screen Flow – N/A

4.1.5 Screen Mockup – N/A

4.1.6 Business Rules – N/A

4.1.7 User Roles – N/A

4.1.8 Data Fields – N/A

4.1.9 Links – Navigation – N/A

4.1.10 Links – Functions/Actions – N/A

4.1.11 Validation – N/A

4.1.12 Notifications and Tasks – N/A

4.1.13 Other – N/A

4.2 Check for Foster Care Recipient for Whom Service

Closed

4.2.1 Design Description

The Service Closure (SC) indicator for an existing foster care recipient indicates applicant is no longer eligible for the foster care benefits. The system will be modified to check if future SSI eligibility has been established for the foster care recipient, for whom the SC indicator is received. In case if a future SSI eligibility exists, which is set to start once foster care recipient turns 21 now needs to be started from next month.

4.2.2 Functional Output

• The Service Closure (SC) indicator received in the daily DSS file.

• System determines if applicant who is losing foster care eligibility because of Service

Closure, is he/she has future SSI eligibility established.

• The foster care recipient who is losing foster care eligibility (because of SC), has future

SSI eligibility already established. System will change the SSI eligibility start date to the first of the next month.

4.2.3 Design Details - Requirements Addressed

1 INT_DSS_REQ_2.1 System received the Service Closure(SC) indicator for a current foster care (PCAT 31, 60) recipient.

Note: The daily file from DSS includes the change indicator, and SC is one of the possible values for the Change Indicator.

2 INT_DSS_REQ_2.2 System determines for current foster care recipients for whom SC indicator received, if he/she is eligible for future SSI benefits.

3 INT_DSS_REQ_2.2.1 Applicant is SSI eligible if all of the following conditions are true.

a) An open CGIS income support IC exists for the applicant.

b) Applicant has future SSI (PCAT 80) eligibility established, starting from the first of the month following the month in which foster care recipient turns 21.

c) The Benefit Evidence of Type SSI exists on the CGIS IC and benefit evidence covers the next month.

4 INT_DSS_REQ_2.2.2 Foster care recipient who determined not to be eligible for SSI benefits based on above requirement (INT_DSS_REQ_2.2.1) will be processed according to the existing DSS functional specifications.

Note: Please see the HCR18.1 Functional Design Specification DSS Foster Care Interface for details.

5 INT_DSS_REQ_2.3 System creates the SC Medicaid evidence on the HCR IC on which applicant is currently getting the foster care benefits (PCAT 31, 60), if one does not exist.

INT_DSS_REQ_2.3.1 System will set the last day of current month as the end date for the manual evidence on the HCR IC.

6 INT_DSS_REQ_2.3.2 System sets the SC Medicaid benefit evidence start date to the first day of next month and no end date is given for the SC Medicaid benefit evidence on HCR IC.

7 INT_DSS_REQ_2.3.3 System will end the authorization detail evidence on HCR IC.

8 INT_DSS_REQ_2.3.4 System will end the authorization detail evidence with reason code “Automatic Closure” and set the end date to the last day of current month.

9 INT_DSS_REQ_2.4 System apply changes and reassess the HCR IC.

10 INT_DSS_REQ_2.4.1 No closure notice is generated from the HCR IC.

Note: No closure notice is generated because an open SC Medicaid evidence exists on the HCR IC.

11 INT_DSS_REQ_2.4.2 During HCR evidence update or during apply changes if a technical failure happens, system will perform following actions defined in the sub requirements.

12 INT_DSS_REQ_2.4.2.1 System will include the SC indicator in the unsuccessful file and report.

The error message would be as follow.

“System failed to process the Service Closure (SC) indicator due to a technical reason, changes could not be applied to HCR IC and no changes could be made to CGIS IC Case Reference <CGIS IC Case Reference>. Please complete the processing of the Service Closure indicator manually.

13 INT_DSS_REQ_2.4.2.2 System will not make any changes on the CGIS case and will leave it as it is.

14 INT_DSS_REQ_2.5 System will end date the SC Medicaid benefit evidence on the CGIS IC with the last day of current month.

NT_DSS_REQ_2.5.1 System will change the start date of the manual evidence to the first of next month if future PCAT 80 eligibility is on a manual product.

15 INT_DSS_REQ_2.6 System apply changes and reassess the CGIS IC.

16 INT_DSS_REQ_2.6.0.1 Create a manual evidence starting from the first of next month till the end of birth month applicant turns 21, when all of the following conditions are true.

1) Apply changes on the CGIS IC failed due to technical failure

2) The future eligibility (starting after member turns 21) is on ABD product.

17 INT_DSS_REQ_2.6.1 An approval notice is generated from the CGIS IC. If CGIS eligibility is starting in more than 30 days in future, then CGIS approval notice will be sent 30 days before CGIS eligibility starts.

18 INT_DSS_REQ_2.6.1.1 The CGIS approval notice will be sent to auth rep defined for the applicant, if an active authorization detail evidence exists on CGIS IC without an outstanding verification.

19 INT_DSS_REQ_2.6.2 During CGIS evidence update or during apply changes if a technical failure happens, system will perform following action defined in the sub requirement.

20 INT_DSS_REQ_2.6.2.1 System will include the SC indicator in the unsuccessful file and report.

The error message would be as follow.

“System failed to process the Service Closure (SC) indicator due to a technical reason, changes could not be applied to CGIS IC Case Reference <CGIS IC Case Reference>. Updates on HCR IC were made and applied successfully. Please complete the processing of the Service Closure indicator manually.

21 INT_DSS_REQ_2.7 The SC indicator will be included in the successfully processed data file and report when HCR eligibility ended at the end of current month and PCAT 80 eligibility is starting from first of next month.

4.2.4 Screen Flow – N/A

4.2.5 Screen Mockup – N/A

4.2.6 Business Rules – N/A

4.2.7 User Roles – N/A

4.2.8 Data Fields – N/A

4.2.9 Links – Navigation – N/A

4.2.10 Links – Functions/Actions – N/A

4.2.11 Validation – N/A

4.2.12 Notifications and Tasks – N/A

4.2.13 Other – N/A

5 Technical Design

This section describes the technical architecture of the system.

5.1 Common Technical Artifacts

Below are the technical details which illustrate that the Cúram system is validating whether the child is getting eligibility in CGIS. If child is getting eligibility in CGIS then that record is marked as unsuccessful and system will not process that record. The CGIS record will be shown on MEDS Eligible Data File. Below are the steps to perform to achieve the above requirement

1. Child is currently getting eligibility in CGIS – Any of the service indicators received through the DSS nightly batch:

1. Member is getting eligibility in CGIS, any of the service indicators received through the DSS nightly batch. Do the following process

Condition: A

1. IC Type == PC4000 ( Income Support Case)

2. BatchRunDate between CGIS Eligibility startDate and endDate

If Condition A is true

Create Unsuccessful Record

Else

Process DSS record

2. Child has future PCAT 80 CGIS Eligibility - Service closure indicator received through

DSS nightly batch:

1. Member is getting eligibility in HCR under PCAT-60 or PCAT-31, Service closure indicator received through DSS nightly batch.

2. Determine if the child has future CGIS eligibility having SSI benefits under PCAT-80.

Condition: A

1. IC Type == PC4000 ( Income Support Case)

2. BatchRunDate is before the CGIS eligibility startDate

If Condition A is true

End Date HCR Eligibility

1. End Date existing Manual Evidence on PCAT60 or PCAT 31.

2. End Date Authorization Details Evidence as of last of this month.

Update CGIS IC Benefit Evidence of type SC Medicaid.

1. Update the start date of benefit evidence of type SC Medicaid on the CGIS IC Case last of this month.

3. If integrated case is of type "Income Support” and the batch run date is before the CGIS eligibility start date, End the HCR eligibility at the end of the batch run date month. Modify the

SC Medicaid benefit evidence at the end of this month on the CGIS IC and establish the eligibility on the CGIS IC from next month onwards.

Technical Function

5.1.1 Sequence Diagram

Below sequence diagrams address the requirement where member is receiving eligibility under

CGIS IC. Any of the service indicators received through the DSS nightly batch.

DSS Foster Care Sequence Diagram Member currently has CGIS eligibility

5.1.1.1 Sequence Diagram Narrative

Action # Action Label Action Label Narration

1 Calling process method process() MMDSSFosterCareNightyChunker will invoke the process method of MMDSSFosterCareNightyStreamer

Action # Action Label Action Label Narration

2 Calling process methodRecord processRecord() process() of MMDSSFosterCareNightyStreamer class will make internal call to processRecord() of MMDSSFosterCareNightyStreamer class for processing each record of retrieved. by chunker

Calling processMemberHavingCurrentC GISEligibility processMember HavingCurrentC GISEligibility()

The method processMemberHavingCurrentCGISEligi bility () has been called from processRecord() of MMDSSFosterCareNightyStreamer class which call getEDDRecordsByICTypeandConcernR oleID () to determine child eligibility in

CGIS.

getEDDRecordsByICTypeandConcernR oleID (), Existing API returns the all the EDD records for the CGIS IC Case, Based on the above CGIS eligibility start date and end date, determine the batch run date is within the CGIS eligibility dates.

If the above condition is true, Create the DSS report record after calling the operation createNightlyUnsuccessfulReportRecord s().– This is an existing API.

For the above condition: If child is getting eligibility in CGIS then that record is marked as unsuccessful and system will not give benefit to the child.

Calling getEDDRecordsByICTypeandCo ncernRoleID getEDDRecords ByICTypeandCo ncernRoleID ()

This method returns the all the edd records for CGIS IC case for a member.

Existing API returns the latest eligibility of the member on CGIS IC Case. To get the latest eligibility this API reads the record with the most recent start date of the table MMEligibilityDecisionDetails, column startDate.

5 Calling sendBatchReport() sendBatchRepor t()

This method (sendBatchReport()) of chunker is used to generate the report data file require for DSS. Existing API.

5.1.1.2 Sequence Diagram

Below sequence diagrams address the requirement where member is receiving eligibility under

HCR IC on PCAT-60/PCAT-31. Member has future CGIS eligibility having SSI benefits under

PCAT-80. Closure service indicator received through the DSS nightly batch.

Diagram-1: Below diagram show the processing of HCR IC Case.

DSS Foster Care Sequence Diagram Member has future CGIS eligibility on PCAT 80

Diagram-2: Below diagram show the processing of CGIS IC Case.

DSS Foster Care Sequence Diagram Member has future CGIS eligibility on PCAT 80

Diagram-3: Below diagram show the processing of apply changes on CGIS IC Case with exception handling.

5.1.1.3 Sequence Diagram Narrative

1 Calling process method process() MMDSSFosterCareNightyChunker will invoke the process method of MMDSSFosterCareNightyStreamer

2 Calling process methodRecord processRecord() process() of MMDSSFosterCareNightyStreamer class will make internal call to processRecord() of MMDSSFosterCareNightyStreamer class for processing each record of retrieved. by chunker

3 Calling handleChangeIndicators handleChangeIn dicators() This is an existing API.

Members having conclusive match (Member has HCR eligibility on PCAT- 60 or PCAT-31) If the change indicator is "SC:Service Closure", get the latest eligibility of a member in CGIS by making a call to the operation getLatestEligibleDecisionsByConcernR oleIdsAndProductCategory()

If member has future CGIS eligibility, end the existing Manual evidence on PCAT-60/PCAT-31 after making an internal call to the operation endDateManulaEligibilityEvidence()

Read the latest active manual evidence having PCAT eligibility under PCAT- 60/PCAT-31 and the batch run date between the manual evidence start date and end date.

End Date: Batch run date month end date.

End Date the Authorization Details Evidence by making a call to internal operation endDateAuthorizationDetailsEvidence(), endAuthorizationDetailsEvidence.

Following details will be updated as part of the evidence update End Date: Batch run date month end date

Create Benefit Evidence of type SCMEDICAID if it does not exist on a member by making a call to the operation updatOrCreateSCMedicaidBenefitEvide nce () getLatestEligibleDecisionsByCon cernRoleIdsAndProductCategory getLatestEligible DecisionsByCon cernRoleIdsAnd ProductCategor y()

This method returns the latest CGIS eligibility for a member. To get the latest eligibility this API reads the record with the most recent start date of the table MMEligibilityDecisionDetails, column startDate.

Calling endDateManulaEligibilityEvidenc e() endDateManula EligibilityEvidenc e ()

This method end dates the PCAT60 or PCAT31 PCAT30 manual evidence.

End date of the evidence will be batch run date month end date.

Method reads the manual evidence details by using API searchByConcernroleIDCaseIDAndEvid enceType(), Method filters the record with the payment category and batch run date. Batch run date will be between the evidence start date and end date.

Update the manual evidence with the end date as end date month of the batch run date using the API modifyEvidence of EvidenceServiceInterface.

endDateAuthorizationDetailsEvid ence() endDateAuthoriz ationDetailsEvid ence()

This method end dates the authorization details evidence. End date of the evidence will be batch run date month end date.

Calling updatOrCreateSCMedicaidBenef itEvidence () updatOrCreateS CMedicaidBenef itEvidence ()

API reads the benefit evidence of type SC Medicaid for batch run date; API internally makes a call to searchByCaseIDParticipantIDAndType () to read the latest Benefit evidence on HCR IC Case. Compare the start date and end date that has been retrieved from the benefit evidence against the batch run date. If the batch run date between benefit start date and end date, Update the Medicaid Benefit evidence with the start date to first of the month following the batch run month. Update the end date of the evidence as null.

If the benefit evidence of type SC Medicaid not found, read the benefit evidence that has been created in future from batch run date using the internal Cúram API searchByCaseIDParticipantIDAndType (), Compare the retrieved evidence start date against the batch run date on the HCR IC Case. If the batch run date is before the evidence start date, Update the Medicaid Benefit evidence with the start date to first of the month following the batch run month.

If the above two conditions do not return the benefit evidence of type SC Medicaid, create a benefit evidence of type SC Medicaid on HCR IC Case if it does not exist on a member. If it exists in future it modifies the start date of the evidence to the Start Date of the evidence will be batch run date month plus 1.

8 Calling applyChanges() applyChanges()

This method applies the in-edit evidences that has been created/updated as part of the change indicator process of HCR IC Case.

9 Calling getBenefitEvidences () getBenefitEvide nces ()

This method reads the SC Medicaid benefit evidence on the CGISIC Case by batch run date. Read the Benefit evidence of type SC Medicaid. Batch run date should be in between the start date and end date of the benefit evidence of type SC Medicaid.

10 Calling modifyBenefitEvidence () modifyBenefitEvi dence ()

This method will update the benefit evidence of type SC Medicaid on the CGIS IC Case. Set the benefit evidence end to the last day of the month batch run month.

Calling readCGISBenefitEvidence() readCGISBenefi tEvidence()

This method reads the CGIS benefit evidence of type SSI where batch run date is within the date range of CGIS benefit evidence start date and end date.

12 Calling readManualEvidence() readManualEvid ence()

This method reads the CGIS Manual evidence of type SSI where batch run date is before the SSI benefit evidence start date.

13 Calling applyChanges() applyChanges()

This method applies the in-edit evidences that has been updated as part of the change indicator process for CGIS IC Case (SC Medicaid evidence)

Exception on CGIS Apply Changes

Determine if CGIS Manual Evidence of type SSI exits based on the call at the step 12

CGIS Manual Evidence of type SSI exits

Condition() If Manual Evidence of type SSI exists

16 updateStartDateEvidence() updateStartDate Evidence()

Update the start date of the CGIS Manual Evidence of type SSI to the first of next month of batch run date.

17 Calling applyChanges() applyChanges()

This method applies the in-edit evidences that has been updated as part of the change indicator process for CGIS IC Case (SC Medicaid evidence and the CGIS Manual Evidence of type

SSI)

CGIS Manual Evidence based on the condition line 15

Condition() CGIS Manual Evidence of type SSI does not exit

Calling createNonMAGIManualEligiblity Evidence () createNonMAGI ManualEligiblity Evidence ()

Create the non-MAGI CGIS Manual Evidence of type SSI from the first of next month of the batch run date.

20 Calling applyChanges() applyChanges()

This method applies the in-edit evidences that has been updated/created as part of the change indicator process of CGIS IC Case (SC Medicaid evidence and the CGIS Manual Evidence of type SSI)

5.1.2 Events – N/A

5.1.3 Events Class Details – N/A

5.1.4 Domain Definitions – N/A

5.1.5 Code Tables – N/A

5.1.6 Code Tables Details – N/A

5.1.7 Messages – N/A

5.1.8 Message Detailed Description – N/A

5.1.9 DMX – N/A

5.1.10 Security – N/A

5.1.11 Security Details – N/A

5.1.12 Model

The following section describes the files that need to be modeled:

Model File Location Custom or

OOTB

Override / New

MMDSSFosterCareNightly.efx EJBServer/components/custom/model/Pa ckages/MM/Batch/MMDSSFosterCare/M MDSSFosterCareNightly/

Custom Existing

5.1.13 Interfaces – N/A

5.1.14 Facades – N/A

5.1.15 Entity Layer – N/A

5.1.16 Service Layer – N/A

5.1.17 POD Definitions – N/A

5.1.18 Java Script Changes – N/A

5.1.19 CSS Changes – N/A

5.1.20 Global Configuration Changes – N/A

5.1.21 Wizard Changes – N/A

5.1.22 Menu Details – N/A

5.1.23 Evidence Configuration Changes – N/A

5.1.24 Renderers – N/A

5.1.25 Keywords (Hover Values) – N/A

5.1.26 Help Content – N/A

5.1.27 Links – Navigation – N/A

5.1.28 Links – Functions/Actions – N/A

5.1.29 Validation – N/A

5.1.30 Workflow – N/A

5.1.31 Web Services – N/A

5.1.32 Java Classes – N/A

5.1.33 Task and Work Queues – N/A

5.1.34 Reports – N/A

5.1.35 Unit Testing Scenarios

The development team(s) will test the following scenarios during unit testing.

5.1.36 Cúram Unit Testing Scenarios

Ite m

Requirement # Associ ated Jira

Unit Test Case Description Test Scenario

1 INT_DSS_REQ_

1.1

INT_DSS_REQ_

1.1.1

INT_DSS_REQ_

1.2

INT_DSS_REQ_

1.2.1

INT_DSS_REQ_

1.2.2

INT_DSS_REQ_

1.2.3

INT_DSS_REQ_

1.2.4

SDX daily update batch should perform person match on the SDX record and if the person will not be found in the system. It will register a person and give the eligibility in CGIS.

Class Name:

MMDSSBatch_ExitsingCGISEligibilityTes t001.java

Method Name:

processMemberHavingCGIEligibility ()

Create an input xml called MMIntegration_DSS001.xml having CGIS eligibility created on any of the ABD products.

testMemberHavingCGISEligi bility () should register a person, create an IC case and PDC case

AssertTrue() if member has CGIS eligibility for the batch run date.

Ite m

Requirement # Associ ated Jira

Unit Test Case Description Test Scenario

2 INT_DSS_REQ_

2.1

INT_DSS_REQ_

2.2

INT_DSS_REQ_

2.2.1

INT_DSS_REQ_

2.2.2

INT_DSS_REQ_

2.3

INT_DSS_REQ_

2.3.1

Insert a record in the DSSFosterCare daily inbound table MMDSSFosterCareDaily. Processing of the record will create the HCR IC with the Foster care eligibility of the person.

Class Name:

MMDSSBatch_FosterCareManualEviden ceEndDated002.java

Method Name:

testFosterCareManualEvidenceEndDate d () testFosterCareManualEvide nceEndDated() will register a person having DSS Foster Care Eligibility with the payment category 60.

Simulate the Service Closure indicator received as part of DSS file when member is receiving the future CGIS Eligibility. End Date the Foster Care Manual evidence.

AssertTrue if Foster Care Manual evidence has been end dated for the payment category 60.

3 INT_DSS_REQ_

2.1

INT_DSS_REQ_

2.2

INT_DSS_REQ_

2.2.1

INT_DSS_REQ_

2.2.2

INT_DSS_REQ_

2.3

INT_DSS_REQ_

2.3.1

Insert a record in the DSSFosterCare daily inbound table MMDSSFosterCareDaily. Processing of the record will create the HCR IC with the Foster care eligibility of the person.

Class Name:

MMDSSBatch_FosterCareManualEviden ceEndDated003.java

Method Name:

testFosterCareManualEvidenceEndDate d () testFosterCareManual

EvidenceEndDated() will register a person having DSS Foster Care Eligibility with the payment category 31.

Simulate the Service Closure indicator received as part of DSS file when member is receiving the future CGIS Eligibility. End Date the Foster Care Manual evidence.

AssertTrue if Foster Care Manual evidence has been end dated for the payment category 31.

Requirement # Associ ated Jira

Unit Test Case Description Test Scenario

4 INT_DSS_REQ_

2.1

INT_DSS_REQ_

2.2

INT_DSS_REQ_

2.2.1

INT_DSS_REQ_

2.2.2

INT_DSS_REQ_

2.3.3

INT_DSS_REQ_

2.3.4

Insert a record in the DSSFosterCare daily inbound table MMDSSFosterCareDaily. Processing of the record will create the HCR IC with the Foster care eligibility of the person.

Class Name:

MMDSSBatch_AuthEvidenceEndDated0 04.java

Method Name:

testAuthEvidenceEndDated () testAuthEvidenceEndDated( ) will register a person having DSS Foster Care Eligibility with the payment category 31. Authorization Details Evidence will be created.

Simulate the Service Closure indicator received as part of DSS file when member is receiving the future CGIS Eligibility. End Date the authorization details evidence.

AssertTrue if authorization details has been end dated.

5 INT_DSS_REQ_

2.1

INT_DSS_REQ_

2.2

INT_DSS_REQ_

2.2.1

INT_DSS_REQ_

2.2.2

INT_DSS_REQ_

2.3.2

Insert a record in the DSSFosterCare daily inbound table MMDSSFosterCareDaily. Processing of the record will create the HCR IC with the Foster care eligibility of the person.

Class Name:

MMDSSBatch_CreateOrUpdateSCMedic aid005.java

Method Name:

testCreateOrUpdateSCMedicaid () testCreateOrUpdateSCMedi caid () will register a person having DSS Foster Care Eligibility with the payment category 31.

Simulate the Service Closure indicator received as part of DSS file when member is receiving the future CGIS Eligibility. SC Medicaid Evidence will be created or updated as part of the test.

AssertTrue if SC Medicaid Evidence created.

Requirement # Associ ated Jira

Unit Test Case Description Test Scenario

1 INT_DSS_RE

Q_1.1

,INT_DSS_RE

Q_1.1.1

,INT_DSS_RE

Q_1.2

,INT_DSS_RE

Q_1.2.1

,INT_DSS_RE

Q_1.2.2

,INT_DSS_RE

Q_1.2.3

DSS Nightly Batch ran with change Indicator “NS”

Register a child in CGIS and having eligibility in CGIS.

When DSS Nightly batch ran with change Indictor “NS” system should check if the child has CGIS eligibility if yes than mark the child record as unsuccessful with report type ‘'DSSRPT2' and don’t provide the child manual eligibility. This record should be shown on MEDS Data file.

5.1.37 ESB Unit Testing Scenarios – N/A

5.1.38 Data Retention – N/A

5.1.39 Persistence Requirements – N/A

5.1.40 Backup Requirements – N/A

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

5.1.48 Batch Methods

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

5.1.57 Links/ Actions Controls – N/A

5.1.58 Lists/ Inline Page Details – N/A

5.1.59 Cluster Details – N/A

5.1.60 Other – N/A

5.2 ESB Development

5.2.1 Outbound – N/A

5.2.2 Inbound – N/A

5.2.3 Supporting Details: Record Layout – N/A

5.2.4 ESB Operational – N/A

5.3 Rules Development

5.3.1 Rules (Rules Areas) – N/A

5.3.2 Table of Values – N/A

5.4 Batch Development

5.4.1 Batch Overview – N/A

5.4.2 Functional Summary – N/A

5.4.3 Batch Specifications – N/A

5.4.4 Data Retention – N/A

5.4.5 Batch Classes

Table: Chunking / Streaming

Class Name Package Override / New

Modeled

MMDSSFosterCareNightlyChunker .mm.batch.dss.fostercare.impl Existing Yes

MMDSSFosterCareNightlyStream curam.mm.batch.dss.fostercare.impl Existing Yes

5.4.6 Batch Methods

Class Name

Stereotype and operation name

Overri de / New

In Struct Out Struct Comments

MMDSSF

osterCar eNightlyS tream processMem berHavingCG

IEligibility

New BatchProcessingID, MMDSSFosterCareRecor dDetails boolean This method is called for conclusive match and it does the following.

1.Check if the child intergeratedcasetype is of

"Income Support”.

2.If intergeratedcasetype is of

"Income Support” and child is having CGIS is having eligibility, then create unsuccessful record in the

MMDSSFosterCareReport table and don’t give any benefit to child.

3. If the member is on PCAT-

80, Message in the DSS report will be “Member exist on PCAT

80, please change Placement type and person contact details.”

4. If the member is on any other CGIS PCAT other than

PCAT-80, Message in the DSS report will be

“Member exist on PCAT other than 80”

MMDSSF

osterCar eNightlyC hunker generateDail yMEDSEligibi leDataFile

Existin g batchRunDate void This method should be modified to show up the new column system Found on

MEDS Eligible Data File.

5.4.6.1 Java Classes

Class Name package Override / New

If override

Super class Name with code package

Comments

MMDSSFo sterCareMa tchedPerso nHelper curam.mm.batch.ds sfostercare.nightly.i mpl

Override handleChangeIndicators (MMDSSFosterCareRecordDetails, integratedCaseID, batchRunDate, BatchProcessingID, MMDSSFosterCareExceptionDetailsLi st)

Operation is modified to do the following steps

1) If the change indicator is "SC:

Service Closure", get the latest eligibility of a member in

CGIS

2) If member has future CGIS eligibility, end the existing PCAT60 evidence (Manual/Legacy)

3) If member has future CGIS eligibility, end date the authorization details evidence

4) If member has future CGIS eligibility create Benefit Evidence of type SCMEDICAID if it does not exist on a member

5) apply all the INEDIT evidences that has been created/updated as part of the change indicator process for HCR IC Case

6) If member has future CGIS eligibility reads the SCMEDICAID benefit evidence on the CGISIC Case by batch run date.

7) If member has future CGIS eligibility update the SCMEDICAID benefit evidence on the CGISIC Case end date.

8) If member has future CGIS eligibility apply all the in-edit evidences that has been updated as part of the change indicator process for CGIS IC Case

MMDSSFo sterCareMa tchedPerso nHelper curam.mm.batch.ds sfostercare.nightly.i mpl

New readCGISBenefitEvidence()

Operation is created to do the following

1) Operation reads the static (CASEEVIDENCE.BENEFIT) benefit evidence of type BENEFITTYPE.SSI

2) Operation returns the benefit evidence where batch run date is within the date range of evidence state date and end date

MMDSSFo sterCareMa tchedPerso nHelper curam.mm.batch.ds sfostercare.nightly.i mpl

New readManualEvidence()

Operation does the following

1) Operation reads the active evidence descriptor details using the evidence descriptor APIs for the Non-MAGI Manual Evidence

2) Operation returns the manual evidence where batch run date is within the date range of manual evidence state date and end date

5.4.6.2 Entity Classes

Class Name Package Override / New

MMDSSFosterCareDailyDao curam.mm.batch.dssfostercare.nightly.impl Existing

5.4.6.3 Message Files

Message File Name Location Override / New/OOTB

MMDSSFosterCareMessage.xml EJBServer/components/custom/message/ Existing

6.5.8.18.1 Messages

Message Table File Name Message Name Message Description

MMDSSFosterCareMessage.xml DSS_NIGHTLY_PERSON_EXIST_IN_CGIS_ON_PCAT80 Member exist on

PCAT 80,

please change Placement type and person contact details.

MMDSSFosterCareMessage.xml DSS_NIGHTLY_PERSON_EXIST_IN_CGIS_NOT_ON_PCAT80 Member exist on PCAT other than 80.

6 Integration Points/Dependencies – N/A

This section lists any integration point and/or dependency with other system functionality not described in this document.

Integration…