ACCESS€Florida€System€Replacement …dcf.state.fl.us/admin/contracts/floridareplacement/docs/Negotiation... · coupled with two distinct deployments of WODM. The first deployment,

ACCESS Florida System Replacement State of Florida Department of Children and Families Office of Economic Self-Sufficiency

Interim Revised Response #8 ITN# 03F12GC1

Deloitte Consulting LLP Federal ID: 06-1454513

Rick Dorman, Principal 1203 Governors Square Blvd. Suite 400 Tallahassee, FL 32301 Ph. +1 412 402 5170

March 4, 2013

State of Florida – Department of Children and Families Deloitte’s Response to ITN# 03F12GC1 – Interim Revised Response #8

Interim Revised Response #8 Page 2

Identification of Enclosed Documents

Interim Revised Response

Title Page

Identification of Enclose Documents

Transmittal Letter

Interim Revised Response Section 2.1






Peggy Claborn Procurement Manager Florida Department of Children and Families 1317 Winewood Boulevard, Building 1, Room 306 Tallahassee, Florida 32399-0700 US Dear Ms. Claborn: Deloitte Consulting LLP (Deloitte) is pleased to provide our response to the Interim Revised Response (IRR) #8 for ITN 03F12GC1, as requested by the Department of Children and Families (Department) on March 1, 2013. We understand the Department’s goal of gathering and evaluating additional information on the scope, effort, approach, duration, and cost of the ACCESS Florida System Replacement project and we look forward to continued discussions with you on our proposed approach as detailed in our response the Invitation to Negotiation and our subsequent Interim Revised Responses.

We appreciate the opportunity to continue working with you on this important initiative. Should you and the team need additional information, please feel free to contact me (412-402-5170, [email protected]) or John Hugill (850-521-4816, [email protected]).

Sincerely, Rick Dorman Principal, Deloitte Consulting, LLP

Deloitte Consulting LLP 1203 Governors Square Blvd Tallahassee, FL 32301 USA

Tel: +1 850 521 4800 www.deloitte.com

mailto:[email protected]

mailto:[email protected]

www.deloitte.com



Interim Revised Response IRR Section 2.1 Standard Contract and DDI SOW Vendor Instructions

The Vendor is instructed to review the attached DCF Standard Contract, DDI SOW and RDD. After reviewing the DDI SOW, the Vendor shall accept the language as written or submit a proposed modification using track changes directly in the SOW document. The expectation is that the SOW returned with this IRR will be ready for signature.

• The RDD attached represents the business requirements for the solution described in the DDI SOW. The vendor should adjust their pricing accordingly to account for all of the requirements that are listed.

Per the Department’s request, we have reviewed the DCF Standard Contract, DDI Statement of Work, and Requirements Definition Document and have returned an SOW that is ready for signature.

IRR Section 2.2 O&M SOW Vendor Instructions

The Vendor is instructed to review the attached DCF O&M SOW. After the review, the Vendor shall accept the language as written or submit a proposed modification using track changes directly in the SOW document. The expectation is that the SOWs returned with this IRR will be ready for signature.

Per the Department’s request, we have reviewed the O&M Statement of Work and have returned a SOW that is ready for signature.

IRR Section 2.3 Updated DDI Approach Vendor Instructions

Using a contract start date of 4/1/13, provide an updated system solution approach that includes key solution components. Additionally, provide a high-level schedule that includes the proposed start and end dates for each Phase Gate: Plan, Define, Design, Develop, Test, and Implement. The Vendor’s approach must contemplate all of the resources, services, hardware and software needed to deliver the requirements of the DDI SOW within the timeframes specified in the DDI SOW.

As we reviewed the solution requirements, we took into consideration the Department’s revised start date of April 1, 2013, and adjusted our proposed project schedule to address each of the key solution components identified. We have also considered the information received during discussions with you in negotiation sessions and understand your desire to schedule the non-MAGI related activities after the implementation of the solution for MAGI/ACA compliance. As a result, we propose to address Phase 3 in two releases – Phase 3A (Release 1) and Phase 3B (Release 2) as shown in Figure 2.3-1 below. This approach allows the project to deliver the required ACA/MAGI functionality – items #1-5 – before January 1, 2014, and the non-MAGI rules and associated functionality – item #6 – by October 2014. As discussed in our previous meetings with the Department, our approach to the Phase 3 schedule to meet the January 1, 2014 milestone involves overlapping the Systems Development Life Cycle (SDLC) phases.



Figure 2.3-1. Phase 3 Project Schedule.

After the implementation of Phase 3A is complete, we then commence Phase 3B for the addition of non-MAGI medical assistance into the established rules engine. Through discussions with the Department, we chose this approach as it significantly reduces the risk associated with the Phase 3A release while balancing the Department’s time and resource requirements given the additional project scope now included within Phase 3. As a result, this approach allows for Phase 3A to be implemented in December 2013 and Phase 3B to be implemented by October 2014. We believe that this is a viable approach for the Department – providing a realistic project schedule and timeline to achieve the ACA/MAGI compliance milestone while delivering the functionality required for Phase 3.

Table 2.3-2 below provides the high-level schedule for Phase 3A, including the proposed start date and end date for each project phase.

SDLC Phase Start Date End Date

Plan 04/01/2013 04/30/2013

Define 04/08/2013 06/30/2013

Design 05/01/2013 08/15//2013

Develop 05/13/2013 09/30/2013

System Test 08/12/2013 10/31/2013

UAT 10/14/2013 11/30/2013

Implement 12/03/2013 12/13/2013

Warranty 01/06/2013 07/07/2014 Table 2.3-2. Phase 3A SDLC Dates.



Table 2.3-3 below provides the high-level schedule for Phase 3B, including the proposed start date and end date for each project phase.

Phase Begin End

Plan 01/13/2014 01/24/2014

Define 01/27/2014 03/07/2014

Design 02/24/2014 04/18/2014

Develop 03/10/2014 07/11/2014

System Test 06/09/2014 08/15/2014

UAT 08/04/2014 10/03/2014

Implement 10/06/2014 10/24/2014

Warranty 11/10/2014 05/09/2015 Table 2.3-3. Phase 3B SDLC Dates.

In order to address the Department’s required functionality identified for Phase 3, we devised a solution approach that balances effort and manages risk. Our proposed solution approach delivers new capabilities required to support the Department’s functional, operational, and technical needs. These capabilities include real-time MAGI-based eligibility, “No Touch” functionality, use of a business rules engine for both MAGI and non-MAGI rules, integration with the Federal Data Services Hub and the Federally Facilitated Exchange, compliance with MITA and the CMS enhanced funding requirements, SOA-based integration, and enhanced reporting and data analytics. Our solution approach delivers these modifications and enhancements to the Department without introducing significant effort, complexity, and change management requirements that come with completely new application architecture and associated data conversion – items that significantly increase delivery risk while adding no discernible value to the Department, its business partners, and its customers.

The following sections further describe our solution approach and detail a number of the individual components that comprise our proposed solution.

2.3.1 Business Rules Engine Our proposed solution leverages an external Commercial-Off-The-Shelf (COTS) rules engine to provide a flexible, configurable, and modular approach to business rules development, management, and execution. For the ACCESS Florida system, we selected IBM’s WebSphere Operational Decision Manager (WODM) as the business rules engine.

The rules engine architecture we propose to implement in Phase 3 utilizes a single rules repository coupled with two distinct deployments of WODM. The first deployment, shown in Figure 2.3.1-1 below, is a Z/OS native deployment for COBOL applications that provides an API that is directly invoked by legacy COBOL programs. This deployment is used by the EDBC module in the legacy



FLORIDA system and resides on the mainframe to enable high levels of performance of the legacy EDBC transactions.

Figure 2.3.1-1. FLORIDA z/OS Mainframe Rules Engine Integration.

The second deployment, shown in Figure 2.3.1-2 below, is through WebSphere to allow the invocation of rules through either a direct interface with either WebSphere or through Web Services. This deployment is used by other internal and external applications that need to utilize the rules coded within the rules engine, including the Self Service Portal.



Figure 2.3.1-2. Web Service Rules Engine Integration.

Both deployments of WODM access a single rules repository for rule development and rule management. Rules are stored and executed within a DB2 database that is a part of the WODM installation. The DB2 database only contains information related to rule design, storage, and management and does not contain any client, application, or case information.

At the completion of Phase 3A, the rules repository contains the eligibility rules for MAGI-based medical assistance programs. The non-MAGI rules are then moved to the rules engine as a part of Phase 3B. Table 2.3.1-3 below describes the input and output rule flows and the data elements that are necessary to support these activities.

Data Flow Description

Input Rules engine input from the Self Service Portal or the FLORIDA system. This includes all data elements required for the eligibility determination of a Medicaid category group using the MAGI rules (e.g., non-financial and financial information for all individuals who are part of the MAGI based household or Standard Filing Unit). These data include age, residency, citizenship, and financial information required for the calculation of the adjusted gross income as well as the eligibility determination parameters that are used by the rules engine (e.g., the income limits).

Output Rules engine output to the Self Service Portal or the FLORIDA system. This includes the data elements that define the eligibility status of individuals in the MAGI-based household or Standard Filing Unit, such as the non-financial and financial eligibility status (Pass, Fail, Pending), the participation status codes as well as the eligibility budget details. The results are received by the modified legacy eligibility transactions/programs and stored for displaying on budget screens and processing by authorization.

Table 2.3.1-3. Business Rules Data Flow.



2.3.2 Web Portal In lieu of enhancing the Department’s existing Self Service Portal (e.g., WebApp, MyAccount) for customer self service functions, we propose to utilize the self-service functionality within Deloitte’s NextGen platform as the web portal for medical assistance program screening and application data collection and submission. After revisiting the Department’s requirements for self-service, we concluded that leveraging new technologies combined with an improved user interface offer more value to the Department and its customers. The new Self Service Portal provides the combined benefits of functionality that aligns with existing WebApp and MyAccount capabilities while providing an enhanced look and feel and a modern SOA architecture that make it much easier for individuals to apply for benefits and manage their information online. The new Self Service Portal is customized and configured to support real-time eligibility processing for MAGI-based medical assistance, enables the “No Touch” workflow, and provides a platform that can be extended upon in the future.

Table 2.3.2-1 below describes the functions and features of the new Self Service Portal that we are implementing, many of which are pre-built into the base NextGen platform. During the project, we further customize and configure the base solution to fulfill the Department’s Phase 3 requirements and integrate with other ACCESS Florida systems.

Self Service Function/Feature

Description

Pre-Screening • Customers can pre-screen themselves to see if they might be eligible for medical assistance

Application for Benefits

• Customers can apply for services by completing a web application from any location that has internet access

• Application information requested is driven by the benefit selection chosen by the customer

• Customers can also resume their incomplete applications from the self-service portal • Includes summary checkpoints through the application to identify missing information • Supports a streamlined application process for the Customer • Eligibility determination for MAGI-based Medicaid will be performed ‘real time’ which

helps ensure that applications can flow through the system in a ‘no touch’ manner

Check Benefits • Customers can register for an account within the Self Service Portal • Customers can check their benefits as well as the status of their pending requests

Report Changes • Customers can notify the department with any of the changes in their case information from the My Account component of the Self Service Portal

• Includes ten pre-configured change reporting types (e.g., change in income, change in address) that guide users to enter only the requested change type

• Provides capability to pre-populate specific data from the worker portal to aid the user in determining which information to modify – reduces potential for users to submit change reports for information that is current

• Changes including address changes and/or case closure requests reported by customers are automatically updated in FLORIDA system without worker intervention



Self Service Function/Feature

Description

Redeterminations/ Additional Assistance

• Customers can apply for Recertification of their benefits and additional benefits from My Account self-service portal

• The system pre-populates the existing household, eligibility and benefits information of a customer. The customer need not furnish the previously submitted information

Additional Assistance

• Simplified and streamlined Recertification/Additional Benefits application process

Medicaid Card • Customers can view their Medicaid eligibility from the self-service portal • Customers can print a temporary Medicaid card and/or request a permanent Gold

Medicaid card from self-service portal

Upload Documents • Customers can upload supporting documentation related to their application/case as part of the application process, change report process as well as directly from the My Account component

• Customers can also view their existing documents they previously uploaded • Includes capabilities to upload from workstation or from a scanner

Online Client Notices • Customers can view and print notices provided by the Department

Email Notification • Customers can opt out of paper client notices and instead opt in for electronic notices • Customers receive an e-mail notification whenever new client notices are available

Partner View • Community Partner View provides a secure gateway to a customer’s account • Allows partners to view the status of all customer’s for whom they have submitted

application, change reports or recertifications through a single login

Provider View • Allows providers to view the status of all customer’s for whom they have submitted application, change reports or recertifications through a single login

• Service providers can verify Medicaid eligibility and benefit information of their customers Table 2.3.2.-1. Functions and Features of the Self Service Portal.

The Self Service Portal will use the existing identity store for authentication and user provisioning. The NextGen technical framework will integrate with the identity store to provide centralized authentication and user management service. The Self Service Portal will use the common authentication service. In addition to authentication, the service will provide user provisioning capabilities through account registration and user management functions. Authorization is performed in the portal based on user role returned by the authentication service. As the Department offers new services to citizens over the internet, this service can be reused accordingly. The benefit is that all citizen identities are provisioned and managed in a single user repository using a service oriented interface.

Conversion of data from the current portal to the new Self Service Portal will not be required as both solutions currently operate on the Oracle Database platform. Modifications will be made to the data access layer of the Self Service Portal to support integration with the existing data store and enable insert, update, and delete functions associated with the new solution.



2.3.3 System Solution Approach for MAGI Our proposed solution will address the Department’s requirements as defined in the Requirements Definition Document and will support interaction between the Self Service Portal, the ACCESS Florida System, the Florida Healthy Kids Corporation’s CHIP System, the Federal Data Services Hub, and the Federally Facilitated Exchange. The sections below describe the proposed interactions that will occur when a customer applies using the Self Service Portal, through the FHKC, and using the Federally Facilitated Exchange.

2.3.3.1 Customer Applying Through the Self Service Portal Figure 2.3.3.1-1 below represents the key processes that take place when a customer is applying for insurance affordability programs using the Self Service Portal. In the figure, each of the processes, activities and entities are assigned a unique number, and are further described in Table 2.3.3.1-2. The processes are grouped into three major categories as Self Service Portal processes, MAGI Medicaid Eligibility Services, and “No Touch” processes for the FLORIDA System.

Figure 2.3.3.1-1. Process Flow Depicting a Customer Applying Through the Self Service Portal.



No Process/Activity Description

1 Submit Application The customer submits an application at the ACCESS Self Service Portal

2 Individual Clearance

Once the customer application is e-signed, the system performs a look up for the individuals in the FLORIDA System (without performing updates) with match criteria that is defined by the Department. In this process the system determines if an individual is already known to the ACCESS Florida system.

3 Check if the Individual is already receiving Medicaid

If the individual is known to the FLORIDA System, this process will determine if the individual is already open for Medicaid. If the individual is already enrolled in Medicaid, no further action is necessary to process Medicaid, and the customer is informed of the same.

4 Obtain Data from Federal Hub

Invokes the Federal Data Services Hub (FDSH) to obtain additional information and verifications on Citizenship, Incarceration, Income etc.

5 Determine if data needed for MAGI Medicaid Eligibility Determination is available

Validates the data provided by the customer and obtained from the Federal Hub to see if data necessary to build a MAGI based filing group and to determine eligibility is available. If sufficient data to determine eligibility is not available at the time, the customer is informed that the application is accepted.

6 Determine if Information is verified

Checks the information that is submitted by the customer and the information obtained from the FDSH to determine if all necessary verifications (verification thresholds to be defined by the Department) are in place. If necessary verifications are not available, the customer is informed that the application is accepted.

7 Build the MAGI Eligibility Filing Unit Group

Creates the MAGI based Filing Unit group based on Tax Filing Information and other Department specifications for category groups, utilizing the WODM Rules Engine.

8 Determine Eligibility for MAGI Medicaid

Determines eligibility following the MAGI Eligibility rules, utilizing the WODM Rules Engine.

9 Check MAGI Medicaid Eligibility Results

Check the eligibility results. If eligible for Medicaid, the customer is informed of the same.

10 Determine CHIP Eligibility

If not eligible for MAGI Medicaid, determine if eligibility for CHIP need to be performed. If required, perform eligibility determination for CHIP

11 Send application and eligibility information FHKC

If CHIP eligibility is determined, the application and information and CHIP eligibility results are transmitted to the FHKC

12 Worker Inbox Items that require worker intervention is queued to the worker inbox. These include the applications that do not have all of the data and/or verifications necessary for MAGI eligibility determination, applications where individual clearance could not clearly determine if an individual is participating in a FLORIDA case, cases where eligibility for MAGI failed.

13 Perform Client Registration

Client Registration is the first business function that is executed by the “No Touch” process on the FLORIDA system. The process will invoke the Client Registration transactions and will use the individuals’ demographic information, address and program selections to initiate and complete Client Registration transactions.

14 Perform Application Entry

Upon successful completion of Client Registration, the process will systematically invoke the Application Entry transactions and will complete the data entry using application data and verifications from the client submitted application and verification sources.

15 Create MAGI Filing Unit

Upon completion of data entry in the Application Entry screens, the process will invoke and execute the SFU transactions to create the MAGI filing units. SFU process utilizes the same business rules used by the Self Service Portal.




16 MAGI Eligibility Determination

EDBC transaction determines eligibility for MAGI Medicaid groups using the same business rules used by the Self Service Portal.

17 Authorization Upon successful completion of the SFU and EDBC execution, the process invokes the Authorization Transaction. MAGI Assistance Groups that PASS eligibility (all verifications in place) are approved.

18 Send information to FMMIS

The individual eligibility information is transmitted to FMMIS for MAGI Medicaid groups that passed eligibility.

19 Send Notices Notices for customers are created to notify their eligibility for MAGI Medicaid.

20 Rules Engine WODM Rules Engine that host the eligibility rules.

21 FDSH The Federal Data Services Hub. Table 2.3.3.1-2. Activities Performed When a Customer Applies Through the Self Service Portal.

2.4.3.2 Customer Applies through FHKC Figure 2.4.3.2-1 below represents the key processes that take place when a customer is applying for insurance affordability programs and information is transferred between the Department and the FHKC. In the figure, each of the processes, activities and entities are assigned a unique number, and are further described in Table 2.4.3.2.-2.

Figure 2.3.3.2-1. Process Flow Depicting a Customer Applying Through the FHKC.




1 FHKC receives an application

The Florida Healthy Kids receives an application from the customer.

2 The FHKC applications get transmitted to DCF

The applications that are received at FHKC are transmitted to DCF for eligibility determination processing.

3 Individual Clearance

The system performs a look up for the individuals in the FLORIDA System (without performing updates) with match criteria that is defined by the Department. In this process the system determine if an individual is already known to the ACCESS Florida system.

4 Check if the Individual is already receiving Medicaid

If the individual is known to the FLORIDA System, this process will determine if the individual is already open for Medicaid. If the individual is already enrolled in Medicaid, no further action is necessary to process Medicaid, and FHKC is informed of the same.

5 Obtain Data from Federal Hub

Invokes the Federal Data Services Hub (FDSH) to obtain additional information and verifications on Citizenship, Incarceration, Income etc. If FHKC accesses and obtains the additional data from FDSH prior to submitting an application to DCF, this step isn’t necessary on DCF side.

6 Determine if data needed for MAGI Medicaid Eligibility Determination is available

Validates the data provided by the FHKC and data obtained from the FDSH to see if data necessary to build a MAGI based filing group and to determine eligibility is available. If sufficient data to determine eligibility is not available at the time, FHKC is informed of the same and no further processing is necessary.

7 Determine if Information is verified

Checks the information that is submitted by the FHKC and the information obtained from the FDSH to determine if all necessary verifications (verification thresholds to be defined by the Department) are in place. If necessary verifications are not available, FHKC is informed of the same and no further processing is necessary.

8 Build the MAGI Eligibility Filing Unit Group

If all the information is available and verified, the next process creates the MAGI based Filing Unit group based on Tax Filing Information and other CHIP specifications for category groups, utilizing the WODM Rules Engine.

9 Determine CHIP Eligibility

After building the MAGI group, the process will invoke the Eligibility services to determine the CHIP eligibility.

10 Transmit to FHKC Upon successful completion of the Eligibility determination, FHKC is informed of the eligibility results.


12 FDSH The Federal Data Services Hub. Table 2.3.3.2-2. Activities Performed When a Customer Applies Through the FHKC.

2.3.3.3 Customer Applying Through the Federally Facilitated Exchange Figure 2.3.3.3-1 represents the key processes that take place when a customer is applying for health insurance affordability programs at the Health Insurance Exchange. In the figure, each of the processes, activities and entities are assigned a unique number and are further described in Table 2.3.3.3-2. The processes are grouped into three major categories as Self Service Portal processes, MAGI Medicaid Eligibility Services, and the “No Touch process” for the FLORIDA System.



Figure 2.3.3.3-1. Process Flow Depicting a Customer Applying Through the Federally Facilitated Exchange.


1 FFE HIX Intake and submission to ACCESS Florida Systems

The FFE receives the customer application and performs data validations using interfaces with the Federal Data Services Hub (FDSH). FFE submits the Application and Verification data to the ACCESS Florida System.

2 Clearance Upon validation of the data received from FFE, the system performs a look up for the individuals in the FLORIDA System (without performing updates) with match criteria that is defined by the Department. In this process the system determines if an individual is already known to the ACCESS Florida system.

3 Check the Clearance Results

Check the Individual Clearance results to determine if the individual is known to the ACCESS Florida System.

3A Determine if Individuals already on Medicaid

Using Clearance Results, determine if the individuals are already receiving Medicaid in the FLORIDA System.

3B Send Results to FFE

If individuals found eligible for Medicaid on FLORIDA, send the current eligibility status to FFE.

4 Determine if CHIP Determination is required

Based on the Application Data available determine if a CHIP Eligibility Determination is required (based on criteria to be determined by the Department).

5 Build the CHIP Eligibility Filing Unit Group

Creates the MAGI based CHIP Filing Unit group based on Tax Filing Information and other Department specifications for CHIP, utilizing the WODM Rules Engine.




6 Determine Eligibility for CHIP

Determines eligibility following the MAGI Eligibility for CHIP utilizing the WODM Rule Engine.

7 Check CHIP Eligibility Results

Check the CHIP eligibility results.

8 Send application and eligibility information to FHKC

Transmit the application and eligibility results data and information and CHIP eligibility results are transmitted to the FHKC.

11 Perform Client Registration

Client Registration is the first business function that is executed by the “No Touch” process on the FLORIDA system. The process will invoke the Client Registration transactions and will use the individuals’ demographic information, address and program selections to initiate and complete Client Registration transactions.

12 Perform Application Entry

Upon successful completion of Client Registration, the process will systematically invoke the Application Entry transactions and will complete the data entry using application data and verifications from the client submitted application and verification sources.

13 Create MAGI Filing Unit

Upon completion of data entry in the Application Entry screens, the process will invoke and execute the SFU transactions to create the MAGI filing units. SFU process utilizes the same business rules used by the Self Service Portal.

14 MAGI Eligibility Determination

EDBC transaction determines eligibility for MAGI Medicaid groups using the same business rules used by the Self Service Portal.

15 Check MAGI Eligibility Results

Check if the MAGI group passes all eligibility requirements to determine if the Assistance Groups should be opened or denied.

16 Authorization Upon successful completion of the SFU and EDBC execution, the process invokes the Authorization Transaction. Assistance Groups that pass eligibility are opened and those fail eligibility are denied.

17 MMIS Interface For open MAGI Assistance Groups, the Case, Individual and Eligibility Information is transmitted to FMMIS.

18 Send Notices Notices for customers are created to notify their eligibility results for MAGI Medicaid.

19 FFE Interface Eligibility Results for MAGI Medicaid is transmitted to FFE.


21 FDSH The Federal Data Services Hub. Table 2.3.3.3-2. Activities Performed When a Customer Applies Through the Federally Facilitated Exchange.

2.3.4 System Solution Approach for non-MAGI At the time of the Phase 3A implementation, all of the technical, asset, and income eligibility rules for the MAGI-based medical assistance groups will be available in the rules engine. As described above, the Self Service Portal as well as the FLORIDA system will invoke the rules engine to determine eligibility for MAGI-based programs. In Phase 3B, we will convert the eligibility rules for non-MAGI medical assistance groups into the rules engine. Once complete, the eligibility rules for all medical assistance programs will be housed in a single repository.



Table 2.4.4-1 below identifies the key components that will be modified and enhanced as a part of the migration of the non-MAGI Medicaid rules into the business rules engine.

Function Description

Technical Eligibility Rules

Rules that determine eligibility for an individual or an assistance group based conditions such as, Age, Disability or Blindness, Citizenship or Immigration Status, State Residency, Living Arrangement, Medical Emergencies etc.

Asset Eligibility Rules

Rules that determine eligibility for an individual or an assistance group based on assets such as, Liquid Assets, Real Property Assets, Business Assets, Vehicles etc.

Income Eligibility Rules

Rules that determine eligibility for an individual or an assistance group based on income such as, earned income, various types of unearned income, self-employment income etc.

ED/BC Driver and Subroutine updates

Modifications necessary in the ED/BC programs to invoke the rules engine components instead of executing COBOL programming that contains the eligibility rules. Also, modifications will be required to ED/BC data structures and COBOL copybooks to support the invocation of the rules engine and to pass the appropriate data elements that will enable the eligibility determination by the rules engine.

Table 2.3.4.-1. Components To Be Addressed in Phase 3B.

The core ED/BC driver and data handling subroutines will continue to perform their functions as they are currently programmed. These include the handling of database access, data management for eligibility determination of multiple assistance groups and individuals for multiple months in a single execution for the case.

2.3.5 Reporting and Analytics In order to support the Department’s requirements for reporting, analytics, and program integrity, we will implement the SAP Business Objects platform for standard reporting, ad-hoc reporting, and data visualization capabilities. Crystal Reports will be used for standard and parameter based reports, Web Intelligence (WEBI) will provide ad-hoc reporting and data analytics, and Xcelsius will provide dashboard reports and data visualization capabilities.

In Phase 3A, we will implement the SAP Business Objects platform and will address the reporting and analytics requirements identified for MAGI-based medical assistance and ACA compliance. In Phase 3B, we will incorporate reporting and analytics capabilities for non-MAGI medical assistance and will implement medical assistance reports which currently exist in the Data and Reports system in the Business Objects platform. At the completion of Phase 3, the Department’s reporting on insurance affordability programs will be provided through a single, modernized reporting platform that supports day-to-day program operations, provides information to define agency priorities, enables increased productivity, enhances fraud prevention and detection, and supports effective decision making.

Our approach to the reporting requirements will utilize existing Department assets including FLODS and data extract processes to provide a centralized data view for insurance affordability



program reporting. We will utilize Pentaho Kettle and Spoon Community Edition as the Extract, Transform, and Load (ETL) tool to develop new data extracts and will leverage Oracle Golden Gate to provide near real-time synchronization between transactional databases, including the Self Service Portal, to the reporting repository. We will work with the Department during the Requirements and Design phases of the project to determine if the reporting repository moving forward will be FLODS, a copy of FLODS, or a separate operational data store based upon criterion including schema expansion, infrastructure requirements, and ease of integration with the SAP Business Objects suite.

IRR Section 2.4 Updated Bill of Materials Vendor Instructions

Using the SOWs, the Final RDD, and a project start date of 4/1/13, complete a Bill of Materials. The Bill of Materials will be added as an exhibit to the DDI SOW.

Per the Department’s request, we have reviewed the Statements of Work, the final Requirements Definition Document, and project parameters to provide a final Bill of Materials for the project.