PL0019 - CGIS30.pdf
PDF 2 MB Posted
- Attached to
- MMS OPERATIONS AND ENHANCEMENTS
- Solicitation number
- 5400021308
- Issued by
- Richland County, South Carolina
About this file
This is an Architectural Design Document (ADD) prepared by the South Carolina Department of Health and Human Services (SCDHHS) for the Member Management Replacement Program (MMRP) Curam Global Income Support (CGIS) Project, specifically addressing the Medicaid Management Information System (MMIS) Interface (CGIS30). The document details the technical and functional design for data exchange between the Curam system and MMIS, focusing on non-MAGI Medicaid eligibility information. Five outbound files are generated daily (Monday through Friday at 7:00 PM and Sunday at 7:00 AM, excluding Saturdays): the Family/Recipient Record file, Managed Care Record file, Medicaid Card file, MIS7000 file, and Authorized Representative file. The Authorized Representative file is generated weekly on Wednesdays at 3:00 PM. The document was drafted beginning October 5, 2018, with multiple review cycles by IBM and SCDHHS personnel, reaching final approval on March 21, 2019, as version 1.0.
The design incorporates modifications to existing HCR MMIS batch programs to accommodate CGIS data, including updates to family and recipient records, managed care enrollment information, Medicaid card requests, and payment category data for PCATs 48, 50, and 52. Key technical changes include new evidence controller hooks to update the Eligibility Decision Details (EDD) table without case reassessment, modifications to data gathering utilities to read Income Support integrated case evidences, new batch classes and methods to process CGIS-specific data elements, and integration with buy-in eligibility interfaces. The system generates exception and control reports for each batch run, and all batch processing is monitored through UC4 automation with file transfers via ESB (ActiveMQ and Mule). The design includes comprehensive unit testing scenarios covering single and multiple member households, dual eligibility situations, split households, converted cases, and MEDS record handling. No pricing, funding, or contract award information is contained in this technical design document.
View the file
Other files
Show all 50
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
South Carolina Department of Health and Human Services
(SCDHHS)
Member Management Replacement Program (MMRP)
Cúram Global Income Support (CGIS) Project
Architectural Design Document
(ADD)
MMRP CGIS30 - Medicaid Management Information System
Interface
MMRP CGIS Project ADD CGIS30 - Medicaid Management Information System Interface 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
0.1 10/05/18 Biswajit Deka Business Analyst Initial draft
0.2 10/16/2018 Biswajit Deka Business Analyst Updated section 4 with RTM, updated section 5.1, 5.2, 5.3 and 5.4 with detailed requirements, added new section 5.5 “Daily Outbound Authorized Representative File” for new requirement C.MMIS.4.0.BR.1, added use case MMIS 03 for mixed household scenario
0.3 11/14/2018 Rohit Arora Cúram Consultant Addressed review comments
0.4 11/14/2018 Ken Haas Functional Business Lead QA Content Review – formatting will be standardized for Approval
0.5 11/16/2018 Rohit Arora Cúram Consultant Addressed review comments
0.6 12/4/2018 Rohit Arora Cúram Consultant Addressed review comments
0.7 12/11/2018 Sandeep Burman Team Lead Reviewed
0.8 12/12/2018 Vijay Mujumdar DDI Technical Lead Reviewed
0.9 01/03/2019 Santhosh George Cúram Consultant Addressed review comments
0.10 02/17/2019 Biswajit Deka Business Analyst Formatted ADD per ADD Approval template
0.11 03/11/2019 Ken Haas Functional Process Lead QA Review for final approval acceptance
V1.0 3/21/2019 Erin Coleman SCDHHS Process and Artifact Development Manager
Updated version number, watermark, and approval date.
The Review Logs maintains a record of the State personnel that performed reviews leading up to the document reaching an Approved status. These reviews do not represent final approval of the document. The Approvals are recorded in the Approval Log Section.
Functional Review Log
The Functional Review Log maintains a record of the State personnel that performed the review of the functional design, confirming the understanding of the design. That the design meets the requirements, business requirements as described and is testable.
SCDHHS Role First Review Date / Reviewer Name
Second Review Date / Reviewer Name
Third Review Date / Review Name
DDI Manager 10/27/2018 Tim Cozine
11/23/2018 Tim Cozine
12/7/2018 Tim Cozine
Product Manager 10/30/2018 Abhishek Sahu
11/23/2018 Abhishek Sahu
12/11/2018 Abhishek Sahu
Technical Lead 10/30/2018 Renjan Bhasi
11/23/2018 Renjan Bhasi
Business Analyst 10/23/2018 Margi Tripathi
11/20/2018 Margi Tripathi
12/5/2018 Margi Tripathi
Business Analyst 10/30/2018 Sherry Shuler
11/21/2018 Sherry Shuler
12/5/2018 Sherry Shuler
Technical Review Log
The Technical Review Log maintains a record of the State personnel that performed the review of the technical design, confirming the technical approach appropriately addresses the functional design.
SCDHHS Role First Review Date / Reviewer Name
Second Review Date / Reviewer Name
Third Review Date / Review Name
Technical Lead 12/20/2018 1/8/2019 1/29/2019
The IBM Approval Review Logs capture the IBM Project Team personnel that reviewed the completed ADD. The Functional and Technical Design Sections have been reviewed by the IBM team. The documented design, functional and technical components are understood as documented and can be validated through the Use Cases defined. This signifies that the section/document is ready for SC personnel review and Approval.
IBM Approval Review Log
Functional Design Section
IBM Functional Design Approval Review – v1.0
Role Name Date Comments
IBM MMRP Integration Lead Srimal Ekkad 3/19/2019
IBM MMRP Business Lead Ken Haas 02/11/2018
IBM CGIS Business Lead Sarfaraz Ahmed 11/12/2018
IBM CGIS Business Analyst Biswajit Deka 11/10/2018
IBM MMRP Testing Lead Courtney Stevens 02/11/2018
IBM MMRP Development Lead Yagnesh Ramani 12/18/2018
IBM CGIS Development Lead Vijay Mujumdar 11/12/2018
Technical Design Section
IBM Technical Design Approval Review – v1.0
Role Name Date Comments
IBM MMRP Integration Lead Srimal Ekkad 3/19/2019
IBM MMRP Development Lead Yagnesh Ramani 12/18/2018
IBM CGIS Development Lead Vijay Mujumdar 12/12/2018
IBM Developer Rohit Arora 12/10/2018
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.
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 Approval (✓)
SCDHHS Business Analyst Margi Tripathi 12/7/2018 (FDS) (✓)
SCDHHS Technical Lead Renjan Bhasi 12/11/2018 FDS (✓)
SCDHHS Product Manager Abhishek Sahu 12/11/2018 FDS (✓)
SCDHHS DDI Manager Timothy Cozine 12/7/2018 FDS (✓)
SCDHHS Process and Artifact Development Manager
Erin Coleman 3/21/2019 ADD (✓)
Technical Design Section Approvals
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 v1.0
Role Name Date Approval (✓)
SCDHHS Technical Lead Renjan Bhasi 1/28/2019 Yes.
We agreed to work on the Managed Care issue on split HH and Cúram mapping as Action Item’s.
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 Outbound File from Cúram to MMIS Flow
2.1.1 Outbound File from Cúram to MMIS Flow Narrative
3 Requirements Matrix
3.1 Requirement Modifications – N/A
4 Function
4.1 Daily Outbound Family/Recipient Record File
4.1.1 Design Description
4.1.2 Functional Output
4.1.3 Design Details
4.1.4 Reports
4.1.5 Screen Flow - NA
4.1.6 Screen Mockup - NA
4.1.7 Notifications and Tasks – NA
4.2 Daily Outbound Managed Care Record File
4.2.1 Design Description
4.2.2 Functional Output
4.2.3 Design Details
4.2.4 Reports - NA
4.2.5 Screen Flow - NA
4.2.6 Screen Mockup - NA
4.2.7 Notifications and Tasks - NA
4.3 Daily Outbound Medicaid Card File
4.3.1 Design Description
4.3.2 Functional Output
4.3.3 Design Details
4.3.4 Screen Flow - NA
4.3.5 Screen Mockup - NA
4.3.6 Notifications and Tasks – NA
4.4 Daily Outbound MIS7000 File
4.4.1 Design Description
4.4.2 Functional Output
4.4.3 Design Details
4.4.4 Screen Flow - NA
4.4.5 Screen Mockup - NA
4.4.6 Notifications and Tasks – NA
4.5 Daily Outbound Authorized Representative File
4.5.1 Design Description
4.5.2 Functional Output
4.5.3 Design Details
4.5.4 Screen Flow - NA
4.5.5 Screen Mockup - NA
4.5.6 Notifications and Tasks – NA
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
5.1.5 Code Tables
5.1.6 Code Table Details
5.1.7 Messages – N/A
5.1.8 Message Detailed Description – N/A
5.1.9 DMX – N/A
5.1.10 Security – N/A
5.1.11 Security Details – N/A
5.1.12 Model – N/A
5.1.13 Interfaces – N/A
5.1.14 Façades – N/A
5.1.15 BPO Method Details – N/A
5.1.16 Façade Structs – List of Structs Involved – N/A
5.1.17 Façade Struct Details – N/A
5.1.18 Façade Struct Aggregation Details – N/A
5.1.19 Entity Layer
5.1.20 Service Layer
5.1.21 Service Layer
5.1.22 Service Layer Structs – List of Structs Involved – N/A
5.1.23 Service Layer Struct Details – N/A
5.1.24 Service Layer Struct Aggregation Details – N/A
5.1.25 POD Definitions – N/A
5.1.26 Java Script Changes – N/A
5.1.27 CSS Changes – N/A
5.1.28 Global Configuration Changes – N/A
5.1.29 Wizard Changes – N/A
5.1.30 Wizard Changes – N/A
5.1.31 UIM Configuration Changes – N/A
5.1.32 Page Parameter Details – N/A
5.1.33 Server Interface Details – N/A
5.1.34 Links/Action Controls – N/A
5.1.35 Lists/Inline Page Details – N/A
5.1.36 Cluster Details – N/A
5.1.37 MENU Details – N/A
5.1.38 Evidence Configuration Changes – N/A
5.1.39 Renderers – N/A
5.1.40 Key Words (Hover Values) – N/A
5.1.41 Help Content – N/A
5.1.42 Other – N/A
5.1.43 Java Classes – N/A
5.1.44 Workflow – N/A
5.1.45 Web Service – N/A
5.2 Unit Testing Scenarios
5.2.1 Cúram Unit Testing Scenarios
5.3 ESB Development
5.3.1 Outbound
5.3.2 Initiating System to ESB – N/A
5.3.3 ESB to Source – N/A
5.3.4 Inbound – N/A
5.3.5 Source to ESB– N/A
5.3.6 ESB to Initiating System– N/A
5.3.7 Common Technical Artifacts
5.3.8 Security– N/A
5.3.9 Entity Layer– N/A
5.3.10 Service Layer– N/A
5.3.11 Help Content– N/A
5.3.12 Junit Testing Scenarios– N/A
5.3.13 ESB Operational Platform
5.4 Rules Development – N/A
5.4.1 Rules - <Rules Area 1>
5.4.2 Table of Values
5.5 MMIS Family Recipient Batch Development
5.5.1 MMIS Family Recipient Batch Detailed Design
5.5.2 Overview
5.5.3 Functional Summary
5.5.4 Batch Specifications
5.5.5 Data Retention – N/A
5.5.6 Persistence Requirements
5.5.7 Backup Requirements – N/A
5.5.8 Archiving and Purging Requirements – N/A
5.5.9 Data Validation Checks – N/A
5.5.10 Security Considerations – N/A
5.5.11 Event Sequence Diagram – N/A
5.5.12 Coding Specifications – N/A
5.5.13 Table Names
5.5.14 MMEligibilityDecisionDetails - Eligibility DetailsEvidences
5.5.15 Input Table Names
5.5.16 Output Table Names
5.5.17 Cúram Batch Component Technical Design
5.5.18 Batch Classes
5.5.19 Batch Methods
5.5.20 Entity Classes – N/A
5.5.21 Entity Methods – N/A
5.5.22 Input/Output Structs – N/A
5.5.23 Input / Output Attributes – N/A
5.5.24 System Properties
5.5.25 Code Tables – N/A
5.5.26 Overview – N/A
5.5.27 Message Files – N/A
5.5.28 Messages – N/A
5.5.29 Coding Specifications – N/A
5.5.30 Source-to-Target Mapping – N/A
5.5.31 Input/Output File/Message Layouts
5.6 MMIS Managed Care Batch Development
5.6.1 MMIS Managed Care Batch Detailed Design
5.6.2 Overview
5.6.3 Functional Summary
5.6.4 Batch Specifications
5.6.5 Data Retention – N/A
5.6.6 Persistence Requirements
5.6.7 Backup Requirements – N/A
5.6.8 Archiving and Purging Requirements – N/A
5.6.9 Data Validation Checks – N/A
5.6.10 Security Considerations – N/A
5.6.11 Event Sequence Diagram – N/A
5.6.12 Coding Specifications – N/A
5.6.13 Table Names
5.6.14 Input Table Names
5.6.15 Evidences
5.6.16 Output Table Names
5.6.17 Cúram Batch Component Technical Design
5.6.18 Batch Classes
5.6.19 Batch Methods
5.6.20 Entity Classes – N/A
5.6.21 Entity Methods – N/A
5.6.22 Input/Output Structs – N/A
5.6.23 Input / Output Attributes – N/A
5.6.24 System Properties – N/A
5.6.25 Code Tables – N/A
5.6.26 Overview – N/A
5.6.27 Message Files – N/A
5.6.28 Messages – N/A
5.6.29 Coding Specifications – N/A
5.6.30 Source-to-Target Mapping – N/A
5.6.31 Input/Output File/Message Layouts
5.7 MMIS Medicaid Card Batch Development
5.7.1 MMIS Medicaid Card Batch Detailed Design
5.7.2 Overview
5.7.3 Functional Summary
5.7.4 Batch Specifications
5.7.5 Data Retention – N/A
5.7.6 Persistence Requirements
5.7.7 Backup Requirements – N/A
5.7.8 Archiving and Purging Requirements – N/A
5.7.9 Data Validation Checks- N/A
5.7.10 Security Considerations – N/A
5.7.11 Event Sequence Diagram – N/A
5.7.12 Coding Specifications – N/A
5.7.13 Table Names
5.7.14 Input Table Names
5.7.15 Evidences
5.7.16 APPLICANTCOUNTYOutput Table Names
5.7.17 Cúram Batch Component Technical Design
5.7.18 Batch Classes
5.7.19 Batch Methods
5.7.20 Entity Classes – N/A
5.7.21 Entity Methods – N/A
5.7.22 Input/Output Structs – N/A
5.7.23 Input / Output Attributes – N/A
5.7.24 System Properties – N/A
5.7.25 Code Tables – N/A
5.7.26 Overview – N/A
5.7.27 Message Files – N/A
5.7.28 Messages – N/A
5.7.29 Coding Specifications – N/A
5.7.30 Source-to-Target Mapping – N/A
5.7.31 Input/Output File/Message Layouts
5.8 MMIS Batch Output Process Batch Development
5.8.1 MMIS Batch Output Process Batch Detailed Design
5.8.2 Overview
5.8.3 Functional Summary
5.8.4 Batch Specifications
5.8.5 Data Retention – N/A
5.8.6 Persistence Requirements – N/A
5.8.7 Backup Requirements – N/A
5.8.8 Archiving and Purging Requirements – N/A
5.8.9 Data Validation Checks – N/A
5.8.10 Security Considerations – N/A
5.8.11 Event Sequence Diagram – N/A
5.8.12 Coding Specifications – N/A
5.8.13 Table Names
5.8.14 Input Table Names
5.8.15 Output Table Names – N/A
5.8.16 Cúram Batch Component Technical Design
5.8.17 Batch Classes
5.8.18 Batch Methods
5.8.19 Entity Classes – N/A
5.8.20 Entity Methods – N/A
5.8.21 Input/Output Structs – N/A
5.8.22 Input / Output Attributes – N/A
5.8.23 System Properties – N/A
5.8.24 Code Tables – N/A
5.8.25 Overview – N/A
5.8.26 Message Files – N/A
5.8.27 Messages – N/A
5.8.28 Coding Specifications – N/A
5.8.29 Source-to-Target Mapping – N/A
5.8.30 Input/Output File/Message Layouts
5.9 AuthRep File Generation Batch Development
5.9.1 AuthRep File Generation Batch Detailed Design
5.9.2 Overview
5.9.3 Functional Summary
5.9.4 Batch Specifications
5.9.5 Data Retention – N/A
5.9.6 Persistence Requirements – N/A
5.9.7 Backup Requirements – N/A
5.9.8 Archiving and Purging Requirements – N/A
5.9.9 Data Validation Checks – N/A
5.9.10 Security Considerations – N/A
5.9.11 Event Sequence Diagram – N/A
5.9.12 Coding Specifications – N/A
5.9.13 Table Names
5.9.14 Input Table Names
5.9.15 Evidences
5.9.16 Output Table Names
5.9.17 Cúram Batch Component Technical Design
5.9.18 Batch Classes
5.9.19 Batch Methods
5.9.20 Entity Classes – N/A
5.9.21 Entity Methods – N/A
5.9.22 Input/Output Structs – N/A
5.9.23 Input / Output Attributes – N/A
5.9.24 System Properties – N/A
5.9.25 Code Tables – N/A
5.9.26 Overview – N/A
5.9.27 Message Files – N/A
5.9.28 Messages – N/A
5.9.29 Coding Specifications – N/A
5.9.30 Source-to-Target Mapping – N/A
5.9.31 Input/Output File/Message Layouts
5.10 IEG Script – N/A
6 Use Cases
6.1 MMIS 01
6.2 MMIS 02
6.3 MMIS 03
6.4 MMIS 04
6.5 MMIS 05
6.6 MMIS 06
7 Appendices
CGIS30 - Medicaid Management Information System Interface V1.0 Page 18 of 129
1 Introduction
1.1 Background
MMIS stands for Medicaid Management Information System. It is a claims processing, payment and information retrieval system. As of today, the eligibility decision details (EDD) table stores recipient eligibility information of Medicaid recipients from Medicaid eligibility determination system (MEDS) and Cúram (MAGI). With the implementation of MMRP CGIS, Cúram will also send Non-MAGI Medicaid eligibility information to MMIS
1.2 Purpose
The purpose of this document is to detail the design of the interface data exchange between Cúram and the Medicaid Management Information System (MMIS). MMIS integrates data received from other systems used in determining Medicaid eligibility and Health Care Providers to conduct their business functions such as; claims processing, provider inquiries and services, managed care enrollment, claims submission, and management reporting, etc.
As a part of the data exchange between Cúram and MMIS, five files will be sent to MMIS. These files are the Family / Recipient Record file, Managed Care Record file, Medicaid Card file, Authorized Representative file and the MIS7000 file. These files are sent to MMIS on weekdays by 12:00 AM and on Sundays by 12:00 PM. The files are not sent on Saturdays. The Family /
Recipient record file contains information about the entire household including contact information and a participant’s eligibility information. Similarly, the Managed Care record file includes information about the current Medicaid beneficiaries of the state of South Carolina who are eligible or ineligible to be enrolled in Managed Care. The Medicaid card file contains information for participants new to Medicaid, participants who have requested a replacement card, and participants who were previously Medicaid eligible and have been reinstated with a gap in coverage of more than 24 months. The MIS7000 file contains information about active participants in payment categories (PCATs) 48, 50, and 52.
Currently the MMIS files contain information related to HCR payment categories. With the first phase of the Cúram CGIS implementation, certain Non-MAGI payment categories will be added to the MMIS files. Refer to Appendix C for a conclusive list of payment categories that will be added. The eligibility decision details (EDD) table stores eligibility information for Medicaid recipients from the Medicaid Eligibility Determination System (MEDS) and from Cúram (MAGI and Non-MAGI). Recipient eligibility data is extracted from Cúram via the Cúram nightly MMIS batch process and is sent to MMIS.
1.3 Scope
The scope of the document is to present the design of the interface data exchange between Cúram
Non-MAGI Medicaid and the Medicaid Management Information System (MMIS).
CGIS30 - Medicaid Management Information System Interface V1.0 Page 19 of 129
1.4 Key References
This section lists any key documents that might be helpful to understanding the functionality which are located on the state SharePoint site.
Document Name Location
MMRP CGIS MMIS Interface BRD MMRP CGIS MMIS BRD
MMRP MMA Interface ADD MMRP CGIS29 MMA Interface ADD
1.5 Definitions and Acronyms
1.6 Key Assumptions
• The MMIS files Family / Recipient Record file, Managed Care Record file, Medicaid Card file, Authorized Representative file and MIS7000 file will be transferred from Cúram to MMIS using the existing file transfer protocol currently used which is UC4.
• The Cúram MMIS interface integrates with the existing Mainframe MMIS system. For this document, the MMIS Mainframe system is referred to simply as MMIS.
• The existing MMIS batch programs implemented for HCR will continue to handle the data exchange for the members getting benefits under HCR as well as CGIS.
Term Meaning
AC Application Case
ADD Architectural Description Document
BRD Business Requirements Document
COC Change of Circumstance
EDD Eligibility Decision Detail
FDS Functional Design Specification
IC Integrated Case
MEC Member Eligibility Call
MMIS Medicaid Management Information System
MMRP Member Management Replacement Program
PA Prior Authorization
PCAT Payment Category
RA Remittance Advise
SCDHHS South Carolina Department of Health and Human Services
SSCN Social Security Claim Number
SSI Supplemental Security Income
SSN Social Security Number
TDS Technical Design Specification
TPL Third Party Liability
WF Workflow https://team.scdhhs.gov/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS%20MMIS%20BRD.docx https://team.scdhhs.gov/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS29%20MMA%20Interface%20ADD.docx
CGIS30 - Medicaid Management Information System Interface V1.0 Page 20 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 MMIS. For the detailed file exchange information please refer to
Section 5 of this document.
2.1 Outbound File from Cúram to MMIS Flow
CGIS30 - Medicaid Management Information System Interface V1.0 Page 21 of 129
2.1.1 Outbound File from Cúram to MMIS Flow Narrative
# Task/Process Task ID Narration
1 New Application, COC, Evidence Changes
(1) The system accepts a new application for MAGI and non-MAGI benefits or a change in existing information related to a beneficiary.
2 Annual Case Review- Batch and Online
(2) Annual Case Review triggers reassessment
3 Converted Case (2.1) Something changes in a converted case that triggers reassessment. This includes manual and automatic conversion.
4 Case Assessment/Case Reassessment
(3) The system processes the information and assess or reassess the case
5 Cúram Determinations Stored in Cúram Decision Tables
(4) The system updates and stores the information in Cúram eligibility decision tables
6 Store Updates in EDD (5) The system stores the information in the EDD table
7 Generate Family / Recipient Record File, Managed Care Record File, Medicaid Card File, MIS 7000 File, Authorized Representative file
(6) Cúram batch processes generate the Family / Recipient Record, Managed Care Record, Medicaid Card, Authorized Representative and the MIS7000 files
8 Cúram records are sent to MEDS- Mainframe
(7) Cúram record files are sent to MEDS. Reconciliation process takes place in the MEDS Mainframe system.
9 MEDS records (8) MEDS records are sent for reconciliation
10 Reconciliation (9) The Reconciliation process of the records received
11 MMIS Receives File (10) The files are transmitted to MMIS
CGIS30 - Medicaid Management Information System Interface V1.0 Page 22 of 129
3 Requirements Matrix
The mapping from business requirement to functional requirement is documented in this MMIS
RTM located on JIRA.
Requirement
ID
Business Rule
ID
Description System Feature Date Updated In Scope (Yes or No)
N/A
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.
Requireme nt ID
Business Rule ID
Description System Feature
Date Update d
In Scop e (Yes or No)
N/A https://cuihhsiutl10.clemson.edu/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS%23281&MMIS%20RTM&true%20 https://cuihhsiutl10.clemson.edu/plugins/servlet/com.easesolutions.jira.plugins.requirements/coverage?prj=CGISS%23281&MMIS%20RTM&true%20
CGIS30 - Medicaid Management Information System Interface V1.0 Page 23 of 129
4 Function
This section describes the design details about the daily outbound files to MMIS. The MMIS batch jobs extract information from Cúram regarding eligibility updates and sends it to the claims processing system, MMIS. This information is sent in 5 separate files:
• Family/Recipient Record file
• Managed Care Record file
• Medicaid Card file
• MIS7000 file
• Authorized Representative file
The existing MMIS batch programs implemented for Cúram HCR will be updated to process the
Family/Recipient record file, the Managed Care record file, the Medicaid Card file, the MIS7000 file, and the Authorized Representative File.
4.1 Daily Outbound Family/Recipient Record File
This section provides a description of the Family/Recipient Record file sent to MMIS daily except on a Saturday.
4.1.1 Design Description
The Family/Recipient Record file contains information on an entire Household. The Cúram MMIS batch job pulls current and historical eligibility information about a recipient and the recipient’s primary contact and creates an output file that is sent to MMIS. Data population rules of the file are included in the file layout attached in Appendix A.
4.1.2 Functional Output
The Family/Recipient batch job implemented for Cúram HCR will be updated to generate and send the Family/Recipient Record File for participants who are a part of Non-MAGI Medicaid to
MMIS.
1. Determine the latest eligibility details from EDD.
2. Gather all the required data from EDD which was created or updated for a person.
3. Gather additional data from Person evidences and Integrated Case evidences that are not available in the EDD but are required to generate the Family/Recipient record file. Refer to the details of required data under section 5.1.3 Design Details.
4. Gather the data in steps 2 and 3 for the family members of the primary contact.
5. Generate the Family/Recipient record file using the outcome of step 4.
6. The generated files are transmitted to the MMIS mainframe system.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 24 of 129
4.1.3 Design Details
CGIS_MMIS_1.1 The system shall generate the family/recipient record file when any of the evidences on the Integrated Case are added or modified resulting in an update to the Eligibility
Determination Data (EDD) table.
CGIS_MMIS_1.2 The system shall generate the family/recipient record file when any of these evidences on the Person are added or modified resulting in an update to the Eligibility
Determination Data (EDD) table:
• Contact Preferences (preferred language)
• Phone Numbers (area code and phone number)
• Names
• Gender
• Birth and Death Details
• Addresses (applicant’s county)
CGIS_MMIS_1.3: The system shall generate the family/recipient record file when the certification period is updated.
CGIS_MMIS_1.4: The following changes will be needed to the family record file to accommodate the CGIS data.
CGIS_MMIS_1.4.1: The system shall move ‘CGIS’ to the field MFR-UID-LAST-
UPDATE in the family record file. Note: HCR moves ‘HCR’.
CGIS_MMIS_1.4.2: The system shall move the Applicant’s County found in the Address
Evidence (Primary Address) to the field MFR-CDE-COUNTY in the family file. Note:
HCR moves it from the Primary Applicant’s County Evidence.
CGIS_MMIS_1.4.3: The system shall move ‘CGIS’ to the field MFR-NUM-CIS-PAT in the family record file. Note: HCR moves ‘STATE’.
CGIS_MMIS_1.4.4: The system shall move ‘S1’ for PCAT-52 and ‘S2’ for PCAT-48 to the field MFR-CDE-SLMB in the family record file. Note: HCR moves spaces.
CGIS_MMIS_1.4.5: The system shall move the Living Arrangement from the Living
Arrangement Evidence to the field MFR-CDE-LIVING in the family file. Note: HCR uses the State Residency evidence for Foster and DJJ Children, and defaults to ‘HOME’ for the remaining.
CGIS_MMIS_1.5: The following changes will be needed to the Recipient file to accommodate the CGIS data.
CGIS_MMIS_1.5.1: The system shall move "Y" or "N" found in the Household member evidence- veteran indicator to the field MRR-IND-VETERAN in the recipient record file.
Note: HCR moves zeroes.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 25 of 129
CGIS_MMIS_1.5.2: The system shall move “Y” if worker’s compensation income is found in the Unearned income evidence to the field MRR-IND-WKR-COMP of the recipient record file. Move zero if not found. Note: HCR uses income evidence.
CGIS_MMIS_1.5.3: The system shall move “Y” if citizen status is verified, and “N” if not verified to the field MRR-IND-CITIZEN-VERIFIED in the recipient record file. For
CGIS use Household member evidence. Note: HCR uses Citizenship status evidence.
CGIS_MMIS_1.5.4: The system shall move ‘CGIS’ to the UID-LAST-UPDATE field in the recipient record file. Note: HCR moves ‘CÚRAM’.
CGIS_MMIS_1.5.5: The system shall move the race code found in the Household member evidence to the MRR-CDE-CIS-RACE field in the recipient record file. Note:
HCR uses Demographics Evidence.
CGIS_MMIS_1.5.6: The system shall move “Y” to the MRR-IND-QMB field in the recipient record file when the recipient is eligible for QMB, else move spaces. Note: EDD is used to get the QMB indicator value.
CGIS_MMIS_1.5.7: The system shall populate the value for the MRR-NUM-BUYA-
PERIODS field in the recipient record file from the data stored by the Buy-In Interface.
Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.8: The system shall populate the value for the MRR-NUM-BUYB-
PERIODS field in the recipient record file from the data stored by the Buy-In Interface.
Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.9: The system shall populate the value for the MRR-GRP-PART-B-
BUYIN field in the recipient record file from the data stored by the Buy-In Interface. Note:
HCR moves zeroes to this field.
CGIS_MMIS_1.5.10: The system shall populate the value for the MRR-CDE-BUYB-
MDC-STATUS field in the recipient record file from the data stored by the Buy-In
Interface. Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.11: The system shall populate the value for the MRR-DTE-BUYB-
ELIG-YYMM field in the recipient record file from the data stored by the Buy-In Interface.
Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.12: The system shall populate the value for the MRR-DTE-BUYB-
INELIG-YYMM field in the recipient record file from the data stored by the Buy-In
Interface. Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.13: The system shall populate the value for the MRR-GRP-PART-A-
BUYIN field in the recipient record file from the data stored by the Buy-In Interface. Note:
HCR moves zeroes to this field.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 26 of 129
CGIS_MMIS_1.5.14: The system shall populate the value for the MRR-CDE-BUYA-
MDC-STATUS field in the recipient record file from the data stored by the Buy-In
Interface. Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.15: The system shall populate the value for the MRR-DTE-BUYA-
ELIG-YYMM field in the recipient record file from the data stored by the Buy-In Interface.
Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.16: The system shall populate the value for the MRR-DTE-BUYA-
INELIG-YYMM field in the recipient record file from the data stored by the Buy-In
Interface. Note: HCR moves zeroes to this field.
CGIS_MMIS_1.5.17: The system shall move the Medicaid ID associated with the Case
Participant Role of the primary applicant in the Integrated Case to the MFR-NUM-HH-PI-
MEMBER-ID field in the family record file. Note: HCR uses the Application Details evidence to get this value.
CGIS_MMIS_1.5.18: The system shall move the Medicare Beneficiary Identifier of the recipient, if present as one of the Alternate Identifier to the NUM-MBI field in the recipient record file. If not present, then move spaces.
CGIS_MMIS_1.6: The system shall use the following rules to extract information to populate the family/recipient record file, when an individual is receiving benefits in both HCR and CGIS programs.
CGIS_MMIS_1.6.1: When an individual’s eligibility is changing from an HCR PCAT to a CGIS PCAT or the other way around within 30 days, the system shall send the information from the Integrated Case where the individual has the latest eligibility to
MMIS.
CGIS_MMIS_1.6.2: When an individual’s eligibility is changing from an HCR PCAT to a CGIS PCAT or the other way around, greater than 30 days in the future, the system shall send the information from the Integrated Case where the individual is currently receiving eligibility to MMIS. NOTE: The future eligibility and information will not be sent to
MMIS as it is more than 30 days in the future.
CGIS_MMIS_1.7: In a household where one or more members are receiving benefits in HCR and others in CGIS, the system shall use the following rules to extract information to populate the family/recipient record file.
CGIS_MMIS_1.7.1: For an individual who is receiving benefits under CGIS, the system shall send case related information from the individual’s CGIS Integrated Case.
CGIS_MMIS_1.7.2: For an individual who is receiving benefits under HCR, the system shall send case related information from the individual’s HCR Integrated Case.
CGIS_MMIS_1.8: The system shall not send duplicate MEDS eligibility rows for converted
MEDS recipients present in Cúram.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 27 of 129
4.1.4 Reports
CGIS_MMIS_1.9: The system shall generate an Exception report in an Excel format that publishes the total number of records identified to be processed by the Family/Recipient batch job, the number of records that failed to be included in the Family/Recipient Record file, and the number of records that were successfully included in the Family/Recipient Record file.
CGIS_MMIS_1.10: The system shall generate a control report in an Excel format that publishes the total number of records identified to be processed by the batch job, the number of records that failed to be included in the Family / Recipient record file, and the number of records that were successfully included in the record file.
MMRPMMIS0001 – Family Recipient Exception Report
This is a combined report generated for the MMIS batch job which generates Family/Recipient record files for Cúram HCR as well as CGIS cases.
Report Details
a. Scheduled: Daily, once the outbound Family / Recipient record file is sent to MMIS
b. Frequency: Daily except on Saturday
c. Output: Daily – Stored in SharePHI Location
Requirements
Selection Criteria: Select the type of records that were found to be updated by the MMIS batch job. Select the type of records that failed file generation due to format error or missing mandatory fields
Report Fields
Summary Report
# Report Label
1. 1 New Recipients To Process
2 Re-queued Recipients
3 Recipients Processed
4 Recipients Skipped
Developer Report
# Report Label
1. 1 Error ID
2 ConcernRoleID
3 Error Date
4 Message
5 Stack Trace
CGIS30 - Medicaid Management Information System Interface V1.0 Page 28 of 129
MMRPMMIS0002 – Family Recipient Control Report
This is a combined report generated for the MMIS batch job which generates Family / Recipient record files for Cúram HCR as well as CGIS cases.
Report Details
a. Scheduled: Daily, once the outbound Family Recipient record files are generated
b. Frequency: Daily except on Saturday
c. Output: Daily – Stored in SharePHI Location
Requirements
Selection Criteria: Select the number of records that were processed by the MMIS batch job, and the number of records that were skipped.
Report Fields
Control Report
# Report Label
1. 1 RUN DATE/TIME
2 REPORT NUMBER
3 Number of records identified
4 Number of records failed
5 Number of records processed
4.1.5 Screen Flow - NA
4.1.6 Screen Mockup - NA
4.1.7 Notifications and Tasks – NA
4.2 Daily Outbound Managed Care Record File
This section provides a description of the Managed Care Record file sent to MMIS daily except on a Saturday.
4.2.1 Design Description
The Managed Care file contains information about the current Medicaid beneficiaries who are eligible or ineligible to be enrolled in Managed Care. For data population rules of the file, please refer to the file layout attached in Appendix A.
4.2.2 Functional Output
The Cúram CGIS system generates the Managed Care Record file and sends it to MMIS. The existing batch job implemented for Cúram HCR will be updated to cater for the non-MAGI
CGIS30 - Medicaid Management Information System Interface V1.0 Page 29 of 129 benefit recipients. This batch job will run immediately after the completion of the
Family/Recipient job and has the below mentioned dependencies.
Pre-requisites for this process are:
• Successful run of family/recipient since last successful run of managed care job
• Availability of MEE0300 file (if initiated from UC4)
• This file contains a list of recipients that MMIS is requesting be included on the
Managed Care output file
This batch performs the following steps to process the managed care record file:
1. Verify that the Family/Recipient process has completed successfully, and the corresponding record file is available.
2. Retrieve the data required for the Managed Care process output from the Family/Recipient record file.
3. If any recipients are listed in the MEE0300 file, gather the information for each recipient.
4. The data gathered in the steps 2 and 3 is then mapped (translated) from the values that
Cúram uses to the values that MMIS understands.
5. This mapped information is used to create the output records for Managed Care process.
6. The generated file is transmitted to the MMIS system.
4.2.3 Design Details
Once the selection criteria for the Family/Recipient Record file is processed, information about the members who are eligible or ineligible to be enrolled in Managed Care is processed and sent to MMIS.
CGIS_MMIS_2.1: The system shall generate the Managed Care Record file after the generation of Family/Recipient records.
CGIS_MMIS_2.2: The system shall generate a managed care record file for each new eligible member.
CGIS_MMIS_2.3: The system shall move the Applicant’s County found in the Address Evidence
(Primary Address) to the field MCOMHN-CDE-APLCNT-CNY in the Managed Care record file. Note: HCR moves it from the Primary Applicant’s County Evidence.
CGIS_MMIS_2.4: The system shall move the race value found in the Contact Preferences evidence to the MCOMHN-CDE-RACE field in the Managed Care record file. Note: HCR uses
Demographics evidence.
CGIS_MMIS_2.5: The system shall send the Cúram Managed Care Record file to the MMIS reconciliation process.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 30 of 129
CGIS_MMIS_2.6: The system shall move the Medicare Beneficiary Identifier of the recipient, if present as one of the Alternate Identifier to the MCOMHN-NUM-MBI field in the managed care record file. If not present, then move spaces.
4.2.4 Reports - NA
4.2.5 Screen Flow - NA
4.2.6 Screen Mockup - NA
4.2.7 Notifications and Tasks - NA
4.3 Daily Outbound Medicaid Card File
This section provides a description of the Medicaid Card file sent to MMIS daily except on a
Saturday.
4.3.1 Design Description
The Medicaid Card file contains information for participants new to Medicaid, participants who have requested a replacement card, and participants who were previously Medicaid eligible and have been reinstated with a gap in coverage of more than 24 months. For data population rules of the file, please refer to the file layout attached in Appendix A. This change will be applied for both
CGIS and HCR
4.3.2 Functional Output
The Cúram CGIS system generates the Medicaid Card file and sends it to MMIS. The existing batch job implemented for Cúram HCR will be updated to cater for the non-MAGI benefit recipients. This batch job has the below mentioned dependencies.
The pre-requisite for this process is successful completion of Family/Recipient process when run from UC4
This batch performs the below steps to generate the Medicaid card file.
1. Retrieve the information of the person who has a Medicaid card request from the Cúram communication table with a communication type of ‘Medicaid Card’.
2. The data retrieved is then mapped (translated) from the values that Cúram uses to the values that MMIS understands.
3. This mapped information is used to create the output in the form of the Medicaid card file.
4. The generated file is transmitted to the MMIS system
4.3.3 Design Details
Once the selection criteria for the Family/Recipient Record file is processed, information about the new members who are eligible to receive Medicaid benefits as well as members who have requested for a replacement card, is sent to the Medicaid Card Record file.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 31 of 129
CGIS_MMIS_3.1: The system shall send a Medicaid Card record for newly eligible CGIS
Medicaid benefit recipients. Note:- For Medicaid Card eligibility, please refer to MMRP CGIS25
- Program Rules - Shared Processes ADD - PR_SharedProc_Req.10.2.
CGIS_MMIS_3.2: The system shall send a Medicaid Card record for any newly eligible member if there has been a gap in their coverage for more than 24 months.
CGIS_MMIS_3.3: The system shall send a Medicaid Card record for any member who has requested a replacement card.
CGIS_MMIS_3.4: The system shall not generate a Medicaid card record for any individual who has a benefit type code of either an E, I or C.
CGIS_MMIS_3.5: The system shall not generate a Medicaid card record for any individual who has current eligibility in PCAT 48, 49, 50, 52, 90, 92 or 99.
CGIS_MMIS_3.6: The system shall move 'CGIS' to the RCR-UID-WORKER field in the
Medicaid card record file. Note: HCR moves 'STATE' to this field.
CGIS_MMIS_3.7: The system shall allow a case worker to add a new Medicaid Card request for a recipient.
CGIS_MMIS_3.8: The system shall allow a case worker to add a request for a replacement
Medicaid Card for a recipient.
4.3.4 Screen Flow - NA
4.3.5 Screen Mockup - NA
4.3.6 Notifications and Tasks – NA
4.4 Daily Outbound MIS7000 File
This section provides a description of the MIS7000 file sent to MMIS daily except on a Saturday.
4.4.1 Design Description
The MIS7000 file contains information about all active members in PCATs 48, 50 and 52. For data population rules of the file, please refer to the file layout attached in Appendix A.
4.4.2 Functional Output
The Cúram CGIS system generates the MIS7000 file and sends it to MMIS. The MMIS batch for
Family/Recipient file generated the MIS7000 file also. Refer to 5.1 Daily Outbound
Family/Recipient record file section for design specification of this batch job.
https://team.scdhhs.gov/pmo/ProjectRepository/1211207/_layouts/WordViewer.aspx?id=/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS25%20-%20Program%20Rules%20-%20Shared%20Processes%20ADD.docx&Source=https%3A%2F%2Fteam%2Escdhhs%2Egov%2Fpmo%2FProjectRepository%2F1211207%2FCGIS%2520Business%2520Requirements%2520and%2520Design%2520Documents%2FForms%2FAllItems%2Easpx%3FGroupString%3D%253B%2523CGIS25%2520Program%2520Rules%253B%2523In%2520Review%253B%2523%26IsGroupRender%3DTRUE&DefaultItemOpen=1&DefaultItemOpen=1 https://team.scdhhs.gov/pmo/ProjectRepository/1211207/_layouts/WordViewer.aspx?id=/pmo/ProjectRepository/1211207/CGIS%20Business%20Requirements%20and%20Design%20Documents/MMRP%20CGIS25%20-%20Program%20Rules%20-%20Shared%20Processes%20ADD.docx&Source=https%3A%2F%2Fteam%2Escdhhs%2Egov%2Fpmo%2FProjectRepository%2F1211207%2FCGIS%2520Business%2520Requirements%2520and%2520Design%2520Documents%2FForms%2FAllItems%2Easpx%3FGroupString%3D%253B%2523CGIS25%2520Program%2520Rules%253B%2523In%2520Review%253B%2523%26IsGroupRender%3DTRUE&DefaultItemOpen=1&DefaultItemOpen=1
CGIS30 - Medicaid Management Information System Interface V1.0 Page 32 of 129
4.4.3 Design Details
All recipients in Cúram CGIS who have at least one eligibility date span in payment category 48, 50 or 52 are selected and populated in the file. The number of dates will be the actual number of spans and will be populated in the “WS-SLMB-NO-DATES” field. For e.g. if a recipient has only one date span of payment category 52, then the number of dates should be set as 01. If the date span is open-ended, then the ineligibility date should be set to zeroes.
CGIS_MMIS_4.1: For each member who is receiving a family/recipient or managed care record and who also has new or previous eligibility in payment category 48, 50 or 52 with a new start date the system shall generate the MIS7000 file.
CGIS_MMIS_4.2: For each member who has existing eligibility in payment category 48, 50 or
52 that is ending with a new end date, the system shall generate the MIS7000 file.
CGIS_MMIS_4.3: The following fields will need to populate in the MIS7000 file.
CGIS_MMIS_4.3.1: The system shall move Member’s Medicaid ID to the field WS-
SLMB-RECIP in the MIS7000 file.
CGIS_MMIS_4.3.2: The system shall move the count of eligibility date occurrences to the field WS-SLMB-NO-DATES in the MIS7000 file.
CGIS_MMIS_4.3.3: The system shall move the payment category found in the EDD record (48, 50, or 52) to the field WS-SLMB-PAYCAT in the MIS7000 file.
CGIS_MMIS_4.3.4: The system shall move the start date of eligibility found in the EDD record to the field WS-SLMB-ELIG-DATE in the MIS7000 file.
CGIS_MMIS_4.3.5: The system shall move the end date of eligibility found in the EDD to the field WS-SLMB-INELIG-DATE in the MIS7000 file.
CGIS_MMIS_4.3.6: The system shall store up to 36 occurrences in the field WS-SLMB-
NO-DATES in the MIS7000 file.
CGIS_MMIS_4.4: When an individual’s eligibility changes greater than 30 days into the future, the system shall send the information of the case in which the individual is currently receiving benefits
CGIS30 - Medicaid Management Information System Interface V1.0 Page 33 of 129
4.4.4 Screen Flow - NA
4.4.5 Screen Mockup - NA
4.4.6 Notifications and Tasks – NA
4.5 Daily Outbound Authorized Representative File
This section provides a description of the Authorized Representative file sent to the mainframe system on a weekly basis.
4.5.1 Design Description
The Authorized Representative file contains information on the primary applicant’s authorized representative. Please refer to the file layout attached in Appendix A.
4.5.2 Functional Output
CGIS and HCR programs are required to generate an Authorized Representative File. The existing batch job implemented for HCR will cater to the Authorized Representative for recipients of non-
MAGI benefits. The existing batch job can be used to generate records for Authorized
Representatives under both cases, CGIS and HCR. If an authorized representative exists in both
Integrated Cases, then the batch will generate an Authorized Representative record based on the below conditions:
1. If the same person is registered as an Authorized Representative on both cases, then one
Authorized Representative record will be generated.
2. If the two cases have a different Authorized Representative, then two records will be generated for each Authorized Representative.
4.5.3 Design Details
The Authorized representatives record file is generated for recipients who have an active product delivery case and an active Authorized Representative on the Integrated Case.
CGIS_MMIS_5.1: The system shall generate an Authorized Representative record if there is an active Authorization Details evidence with no end date.
CGIS_MMIS_5.2: When a person is receiving Streamline Medicaid and QMB with an
Authorized Representative on both integrated cases, the system shall generate an Authorized
Representative record using the Authorization Details evidence on the Insurance Affordability case.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 34 of 129
4.5.4 Screen Flow - NA
4.5.5 Screen Mockup - NA
4.5.6 Notifications and Tasks – NA
5 Technical Design
The below section provides details of the changes needed to the technical artifacts for implementing the MMIS batch process requirements.
5.1 Common Technical Artifacts
This section provides the high-level overview of technical changes to be done to the below logical areas. The detailed description of changes to each artifact is provided in the respective sections.
The below diagram depicts the overview of MMIS batch flow
The MMIS batch jobs extract information from Cúram regarding eligibility/evidence updates and send it to the claims processing system, MMIS. This information is sent in 5 separate files each of which is produced by a separate batch process. The files are
CGIS30 - Medicaid Management Information System Interface V1.0 Page 35 of 129
1. Family / recipient - Contains information regarding eligibility. Prior and current products and periods of eligibility are included in this file. Future eligibility changes that occur within 30 days are also included.
2. MIS7000 (for PCAT 48, 50 and 52) – Family/Recipient batch generates MIS7000 file for the members who are eligible for the PCATs 48, 50 & 52
3. Managed Care - Information to help determine if the recipient is eligible for the Managed Care program.
4. Medicaid Card - Used to produce print requests for Medicaid cards.
5. Batch Output - Used to write the records from the database to the batch output files
6. The AR Batch job generates the Authorized Representative file which contains information about the primary applicant’s authorized representative details.
1. High Level MMIS interface changes for CGIS:
1. Case Reassessment and/or EDD table update – Update the EDD record whenever there is a change in person/evidence details that requires to update MMIS.
1. Insert existing EDD records into MMLastEDDRecords if the existing EDD creationDate is not current day
2. Insert existing records into History
3. Modify existing records in the EDD table
2. New evidence controller hook and API to update EDD lastupdatedon field without case reassessment, MMIS batch picks this record and generate MMIS files.
3. Data Gather – Determine type of Integrated Case, Insurance Affordability (HCR) or Income
Support (CGIS) and read the data from associated evidences
4. Generate MIS7000 file for PCATs 48, 50 & 52
5. Update to generate Family/recipient, managed care, Medicaid Card files for CGIS & HCR applicants
6. Modify the Medicaid Card Batch job in such a way that the system shall not generate a
Medicaid card record for any individual who has current eligibility in PCAT 48, 49, 50, 52, 90, 92 or 99
7. Modify AR batch to generate AR file for HCR and CGIS benefit programs.
8. Application County - Read Application county details from primary contact’s Applicant county evidence same as HCR cases.
9. Modify the logic to get the primary contact for CGIS. If the IC integrated case type is ‘Income
Support’ then get the primary contact member information from HouseHold Member evidence with attribute primaryContact = true of participants.
1. MMIS Family / Recipient Batch
The family / recipient batch job generates recipient and a family record files. The recipient record contains information about the recipient and his / her eligibilities. The family record information is focused on the primary contact information. This batch job produces records for all the eligible
EDD rows which were updated since the last successful run or which have either a start or end date in 30 days. It also re-queue the members which failed in the previous run.
CGIS30 - Medicaid Management Information System Interface V1.0 Page 36 of 129
This Batch job also generate MIS7000 files for the members who are eligible for the PCATs 48, 50 & 52. The batch job gathers the required information for Family/Recipient records from eligible member’s person records, evidences and EDD records which can also be reused to generate
MIS7000 file.
Modify the MmisFamilyRecipChunker.sendBatchReport() to generate MIS7000 file, and
MmisFamilyRecipientCuramDataGatherer to read Income support IC evidence data required for
MMIS files.
1. Add new MMIS output record type name ‘MMIS7000‘to the code table
‘CT_MmisOutputRecordType.ctx’. Use this record type to insert MIS7000 file to the
MMBatchOutputRecord table.
2. Modify sendBatchReport() and check whether the extracted Family/recipient record’s PCAT is ‘48/50/52’ then
1. Populate MIS7000 jRecord bean using the gathered data
2. Write the jRecord bean to ByteArrayOutputStream
3. Insert the record into MMBatchOutputRecord with the row type
MMISOUTPUTRECORDTYPE.MMIS7000
Modify the MmisFamilyRecipientCuramDataGatherer.java to read data from Income Support evidence for CGIS
If the IC case type is ‘Income Support’ then
1. Define a list of Income Support IC evidence type, Household Member (Race, Citizen Status, Veteran Status, Marital Status), SSN Details(SSN), Household Relationship (relationship
Type),…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .