florida department of children and families - interim revised ... · web view2013/02/25 · is...

ACCESS Florida System Replacement

State of Florida Department of Children and Families

Office of Economic Self-Sufficiency

Interim Revised Response #7AITN# 03F12GC1Deloitte Consulting LLPFederal ID: 06-1454513

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

February 25, 2013

Identification of Enclosed Documents

Interim Revised Response

Title Page

Identification of Enclose Documents

Transmittal Letter

Interim Revised Response Section 2.1






Appendix A – DDI SOW Table

Appendix B – O&M SOW Table

State of Florida – Department of Children and Families

Deloitte’s Response to ITN# 03F12GC1 – Interim Revised Response #7

Interim Revised Response #7 Table of Contents

Deloitte Consulting LLP

1203 Governors Square Blvd Tallahassee, FL 32301

USA

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

February 25, 2013

Peggy ClabornProcurement ManagerFlorida Department of Children and Families1317 Winewood Boulevard, Building 2, Room 304

Tallahassee, Florida 32399-0700

Dear Ms. Claborn:

Deloitte Consulting LLP (Deloitte[footnoteRef:1]) is pleased to provide our response to the Interim Revised Response (IRR) #7A for ITN 03F12GC1, as requested by the Department of Children and Families (Department) on February 22, 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. [1: As used in this document, “Deloitte” means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.]

As we continue to work with the Department through the IRR process and demonstrate the merit of our proposed approach and solution, we have also been closely monitoring the communications and directions from CMS and updates in approaches that other states are employing for ACA/MAGI compliance. In addition, we have also been working with our technology solution partners to re-evaluate our original proposed project and technical approach to find further efficiencies in developing a complete solution in the reduced duration and to help reduce delivery risk for this important project. Our detailed response in updated DDI approach section (2.4) describes our updated approach for each of the following items.

Business rules engine containing MAGI eligibility rules for medical assistance programs

Web Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My Account

Interfaces to a health insurance exchange, the federal data hub and other data verification sources

Integration between the new system components and the ACCESS Florida System to accommodate new MAGI data and business processes to support the ACA

Support for MAGI application processing

Addition of non-MAGI eligibility rules for medical assistance programs to the business rules engine

Key changes to our proposed approach outlined in our response are as follows:

1. We have a new web portal that better aligns with the State’s defined expectations

In lieu of leveraging the existing My Account solution, we are proposing our Next Gen Self-Service portal to support Integrated Eligibility program screening, application data collection and submission. As we have revisited the State’s requirements for self-service, combined with the expectation of increased volumes that will come with the Medicaid expansion, we have concluded that leveraging new technologies combined with an improved look and feel, will offer more value to the State. Our Next Gen Self Service portal provides the combined benefit of functionality that closely aligns with your existing My Account functionality, while providing a new look and feel that will make it much easier for higher volumes of constituents to easily apply for benefits on-line. Next Gen Self-Service is easily configurable to support the State’s desire for a “no case-worker touch” work-flow, and will provide a platform that can be extended for programs in the future.

2. We have modified our approach to our rules engine implementation to reduce risk.

Our modified technology approach for IBM WODM Rule Engine solution is based on our commitment to make sure that the implementation of the Rule Engine for Eligibility Determination does not negatively impact the response time of the ED/BC transactions on the mainframe FLORIDA system. Our approach is to deploy the IBM WODM Rules Engine on the FLORIDA mainframe system rather than over on an external distributed server. This approach not only reduces the inherent technology integration risk integrating the legacy IMS/COBOL online transactions and batch programs with a distributed server, but also significantly reduces or eliminates potential transaction performance issues.

3. We have limited our terms and conditions markups to a small subset of issues in the two Statements of Work (SOWs)

Given our long standing relationship working with the Department and our track record of achieving mutually agreeable contract terms & conditions with the State on numerous large-scale technology projects, we are confident that we can successfully complete contract negotiations with the Department and execute a contract on this procurement in an expedited timeframe. As we have discussed with you previously, we will look to commence the project and execute initial project activities in good faith once the Department announces the intent to award. In doing so, we will look to leverage our approach as proposed, as well as our proven methods, tools, and investments – including hardware environments, and vendor relationships – to jump start the project, prior to receiving formal Federal approval of the negotiated contract.

4. We have included support for streamlined MAGI application processing

Our modified solution offering includes “no-touch” capability for processing Medicaid applications. The “no-touch” will provide much needed relief for case workers in light of an anticipated increase in application volumes.

5. We are maintaining our commitment to meeting the federally mandated deadlines for ACA compliance

We have carefully thought through our approach and work plan, and are confident that we can achieve the State’s objectives within the required timeframes to achieve ACA/MAGI compliance. As we continue to work with numerous States to achieve the same goal, we are able to leverage solutions and lessons-learned to expedite the FLORIDA system replacement project.

Based on feedback received in our prior meeting with the Department’s negotiation team, we have not included detailed explanations for all of the changes redlined in our attached SOW and Standard Contract as many are self-explanatory. We are prepared to discuss any and all items the Department has questions or comments on.

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 (+1 412 402 5170, [email protected]) or John Hugill (+1 850 521 4816, [email protected]).

Sincerely,

Deloitte Consulting LLP

By: __________________________Rick DormanPrincipal

Ms. Peggy ClabornFebruary 22, 2013Transmittal Letter Page 2

Member of

Member of

Deloitte Touche Tohmatsu Limited

Interim Revised Response #7 Transmittal Letter Page ii

Interim Revised ResponseIRR Section 2.1 DDI SOW

Vendor Instructions

The Vendor is instructed to review the attached Standard Contract and the DDI SOW included with IRR #7. 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 Department expects material changes only. If the Vendor cannot consent to the language as written, the Vendor must submit proposed language for the Department’s consideration. In addition to the changes in the SOW the vendor is instructed to use the tables in Appendix A when needed to provide feedback and explanation as to why changes were made.

Update the names of the Key Named Staff, the Rate Card and the Deliverable Payment Schedules in the appropriate locations of the attached contract documents.

Redlined SOW should be Vendor signature ready.

DCF will not execute a contract containing assumptions. The Vendor shall convert any assumptions from previous IRR submissions to proposed contract language within the framework and structure of the SOW. Finally, please update the pricing, Bill of Materials or SOW accordingly.

Per the Department’s request, we have provided feedback on the DDI SOW in a redlined version of the document and have outlined our additions, modifications, and deletions in the Table in Appendix A.

IRR Section 2.2 O&M SOW

Vendor Instructions

The Vendor is instructed to review the attached Standard Contract and the O&M SOW included with IRR #7. 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 Department expects material changes only. If the Vendor cannot consent to the language as written, the Vendor must submit proposed language for the Department’s consideration. In addition to the changes in the SOW the vendor is instructed to use the tables in Appendix B when needed to provide feedback and explanation as to why changes were made.

Update the Rate Card and the Services Payment Schedules in the appropriate locations of the attached contract documents.

Redlined SOW should be Vendor signature ready.

DCF will not execute a contract containing assumptions. The Vendor shall convert any assumptions from previous IRR submissions to proposed contract language within the framework and structure of the SOW. Finally, please update the pricing, Bill of Materials or SOW accordingly.

Per the Department’s prioritization of activities in this IRR, we will provide a response to this section in the next iteration of our IRR response, due to the Department by 11:00 AM EST on February 26, 2013.

IRR Section 2.3 Updated DDI Approach

Vendor Instructions

Using a contract start date of 4/1/13, provide an updated summary 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 items 1-5 (below) to the Department no later than the ACA deadline of 1/1/14 and item 6 (below) with a schedule that shows release 2 starting at a time to best balance risk.

1. Business rules engine containing MAGI eligibility rules for medical assistance programs

2. Web Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My Account

3. Interfaces to a health insurance exchange, the federal data hub and other data verification sources

4. Integration between the new system components and the ACCESS Florida System to accommodate new MAGI data and business processes to support the ACA

5. Support for MAGI application processing

6. Addition of non-MAGI eligibility rules for medical assistance programs to the business rules engine

While reviewing the IRR 7 requirements, we took into consideration the Department’s revised start date of April 1, 2013 and the compressed schedule for completing all of the six items listed. In addition, we have also taken into consideration the discussions that we had with you during our face-to-face meetings on February 22, 2013, and your desire to schedule the starting of 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 and Phase 3B, as shown in Figure 1 below. This approach allows the project to deliver the required ACA/MAGI functionality by the January 1, 2014 milestone and the non-MAGI rules by December 2014. As discussed in our prior negotiation meetings with the Department, our approach to the compressed Phase 3 schedule to attain the January 1, 2014 milestone involves overlapping of the project System Development Lifecycle (SDLC) phases. As part of Phase 3A, functionality for the business rules engine containing MAGI rules, development of the Self Service Portal, and Interfaces to meet your MAGI/ACA requirements are performed.

Figure 1- Revised Phase 3 Project Schedule

Upon the successful implementation of Phase 3A is complete, we commence a second Phase 3B for the addition of non-MAGI medical assistance into the now established rules engine. We chose this approach as it significantly reduces the risk associated with the Phase 3A release and helps meet the compliance deadline while delivering the remaining Phase 3 functionality as soon thereafter as possible. It was also chosen to help balance the Department’s time and resource requirements given the additional project scope now included in Phase 3. As a result, this approach allows for Phase 3A to be implemented in December 2013 and Phase 3B to be implemented by December 2014.

We believe that this approach is the most viable for the Department and provides the most realistic schedule and timeline to achieve the ACA/MAGI compliance milestone and deliver all of the functionality required in Phase 3. Our knowledge of the ACCESS Florida systems means that we already have a deep understanding of the enhancements and modifications that need to be made to the applications for ACA. Over the last 18 months, we have been working with you to assess the changes required for ACA compliance and how such changes would impact the people, processes, and technologies of the program. This experience, combined with established assets – including Medicaid rules in WODM, interface definitions, deliverable templates, and test cases – brings knowledge and capabilities to the Department that are critical to accomplishing Phase 3 on time and on budget.

The following table provides the high-level schedule for 3A that includes the proposed start and end dates for each of project phases.

Phase

Begin

End

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

Stabilize

12/13/2013

03/13/2014

Warranty

03/14/2014

09/10/2014

Table 2- Project Phase Gate Schedule for Release 3A for MAGI/ACA compliance

The following table provides the high-level schedule for 3B that includes the proposed start and end dates for each of project phases.

Phase

Begin

End

Plan

02/15/2014

02/28/2014

Define

03/01/2014

04/15/2014

Design

04/01/2014

05/31/2014

Develop

04/15/2014

08/14/2014

System Test

07/15/2014

09/30/2014

UAT

09/18/2014

11/15/2014

Implement

11/15/2014

12/12/2014

Stabilize

12/13/2014

03/13/2015

Warranty

03/14/2015

09/10/2015

Table 3 - Project Phase Gate Schedule for Release 3B for Non-MAGI Medical Assistance Programs rules conversion to Rules Engine

The scope of work related to the business rules engine for Phase 3A and Phase 3B includes the eligibility rules for MAGI and non-MAGI related Medicaid/Medical Assistance category groups. This includes eligibility rules that determine the technical, asset, and income eligibility for assistance groups within the FLORIDA Eligibility Determination and Benefit Calculation (ED/BC) module.

2.4.1 Business rules engine containing MAGI eligibility rules for medical assistance programs

Deloitte’s solution leverages an external COTS Rules Engine to provide ACCESS Florida with the flexibility, configurability, and modularity for business rules. For ACCESS Florida, we have selected IBM’s Web Sphere Operational Decision Manager (WODM).

Figure 2 depicts our Rules Engine architecture for Phase 3. This architecture uses two distinct deployments of WODM. The first deployment is a Z/OS native deployment for COBOL applications that provide a native COBOL API that can be directly invoked by legacy COBOL programs. The second deployment through Web Sphere allows the invocation of the rules through direct interface with Web Sphere or through Web Services. The Z/OS native deployment of WODM for COBOL as shown is used by the EDBC module in the FLORIDA legacy system. The primary reason for this deployment is to achieve high levels of performance of the legacy EDBC transactions with less complex architecture for low risk integration points. The figure also depicts the connectivity between an instance of WODM deployed in the Web Sphere environment that may be utilized by other internal or external applications that needs to use the rules coded in the Rules Engine (Example: Florida Healthy Kid’s KidCare (CHIP) system for MAGI Medicaid eligibility rules).

Both instances of WODM accesses the same rules repository and the same set of eligibility rules for MAGI–based Medical Assistance programs in our first release Phase 3A in December 2013. The Non-MAGI rules will be implemented in the rules engine in our 2nd release (Phase 3B).

Figure 2 – Phase 3 Architecture - MAGI rules components and ACCESS Florida Systems

The external rules engine that hosts the MAGI-based Medicaid rules is exposed to external systems through the Enterprise Service Bus. This enables the same eligibility rules to be available to the Florida Healthy Kids (FHK) KidCare (CHIP) system, if FHK has a need to determine eligibility directly in their system. The Z/OS deployment of WODM will be accessed directly from the EDBC COBOL programs within the FLORIDA system. The following table 4 defines the input and output flows, as well as an overview of the data elements necessary to support these flows.

Data Flow

Description

Input

Rules engine input from the ACCESS Florida system and/or FHK KidCare system. This will include 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 include age, residency, citizenship, financial information required for the calculation of the adjusted gross income, etc. In addition, this also includes the eligibility determination parameters that will be used by the rules engine (e.g., the income limits).

Output

Rules engine output to the ACCESS Florida system and/or FHK KidCare system. This will include 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. In addition, this will also include details of the eligibility budget details. The results will be received by the modified legacy eligibility transactions/programs that will be stored in the legacy databases for display budget screens and processing by authorization.

Table 4 - Input / Output Flow Descriptions of MAGI Rules components and ACCESS Florida Systems

2.4.2 Web Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My Account

In lieu of leveraging the existing My Account solution, we are proposing our NextGen Self-Service portal to support Integrated Eligibility program screening, application data collection and submission. As we have revisited the State’s requirements for self-service, combined with the expectation of increased volumes that will come with the Medicaid expansion, we have concluded that leveraging new technologies combined with an improved look and feel, will offer more value to the State. Our NextGen Self-Service portal provides the combined benefit of functionality that closely aligns with your existing My Account functionality, while providing a new look and feel that will make it much easier for higher volumes of constituents to easily apply for benefits online. NextGen Self-Service is easily configurable to support the State’s desire for a “no caseworker touch” workflow, and will provide a platform that can be extended for programs in the future NextGen and its benefits for DCF.

A solution designed to meet your needs

The Deloitte NextGen solution can significantly reduce risk for Florida by offering a solution that meets most requirements without change while being flexible to adapt to your unique needs.

The solution is built on an enterprise framework, which provides simplified maintenance and can also be used to transform other legacy applications in the future.

Our solution consists of best of breed, production proven transfer components, and COTS products.

The following table highlights some of the business driven features of our NextGen self-service portal and the benefits provided to customers.

Features

Benefits

Single, Integrated Online Application

Eliminates the need for multiple applications that ask for repetitive information, and navigates the user through applicable questions based on their input and the services requested. This saves clients time by reducing the effort required to complete an application and decreases the State’s overhead by eliminating paper application maintenance and duplicative processing.

Client Accounts

Customers can create accounts that allow access to account specific information and serve as a gateway to other services such as change reporting and online redeterminations.

Common Screening Tool

The common screening tool becomes the user’s one stop shop for screening for assistance. Allowing the screening tool to pass information to the online applications reduces the customer’s time needed to enter the required information, as there is no reentry of data.

Improved Customer Service

Applications are more accessible, by introducing alternatives to meeting with or calling a worker and providing services outside of traditional business hours.

Increased Program Participation

Raises the awareness about programs and services and encourages new applications, making it easier for the residents of Florida, authorized representatives and application counselors to apply for and maintain benefits, and reducing the stigma associated with applying for and receiving public assistance or other services.

Reduced Workload for Workers

Reduces the time the State’s workers spend answering questions, performing data entry and managing paper, leading to expedited application processing times by streamlining workflow and reducing work duplication.

Improved Accuracy and Consistency

Errors are reduced by simplifying the process for residents, authorized representatives and application counselors to submit applications resulting in improved program integrity and faster benefit determinations.

Provides a Technological Framework for the Future

Provides the State with a scalable and flexible application that allows new programs or services to be added quickly, enabling new opportunities for growth and future expansion.

Table 5 - Features and Benefits of our NextGen Self-Service Portal

The NextGen platform is a combination of business logic pre-coded in Java and Commercial off the Shelf (COTS) components that are blended together to provide an integrated, modern system. The custom Java code we provide has been verified in other states and represents the core business logic necessary to provide significant functionality and automation for citizens.

NextGen is open and extremely flexible platform and supports both client self-service and case worker eligibility processing. Our solution for Phase 3 provides a NextGen client self-service portal with a single point of entry and consistent workflow for citizens seeking access to public assistance or managing their ongoing account. Our solution for is based on the following principles:

Meet Business Needs: Creating a single point of access for customers simplifies the process to apply for assistance, increases the ability of clients and community partners to manage their own accounts and service requests, and increases the availability of relevant program and policy information.

Open Architecture: The NextGen platform is open and flexible platform that provides a maximum amount of reuse without locking the state into a software vendor or systems integrator. NextGen provides coarse-grained business services, fine-grained technical services and COTS adapters implemented on the latest Java platform. These services provide a significant functional and technical match to the DCF requirements.

Flexible: The NextGen platform includes built in tested services based on an open n-tier architecture platform, which is flexible to expand and easy to maintain by State staff.

Service Oriented: Service-oriented architecture based on open standards based Java EE framework and reusable services.

Integrated Application Development. An Application Development Environment built with recognized industry tools and augmented with Application Life cycle Management tools to manage issues, risks, plan, schedule, etc.

Scale: Scaling for increased workload on any of the integrated channels – workers, citizens, and providers.

Secure: Protection of data from unauthorized access via efficient security and privacy services that include Authentication, Authorization, and a robust set of Security Controls.

NextGen Project Accelerators –We have performed more successful IE jobs than all of our competitors combined, so we have a significant library of project accelerators such as a full set of business rules for SNAP, TANF, MAGI and Non-MAGI Medicaid, full design documentation, regression test cases, performance test scripts, functional requirements base, Technical Architecture, Business Architecture artifacts, all housed in our Enterprise Value Delivery for Systems Integration (EVD for SI).

Industry leading COTS: The NextGen platform uses commoditized COTS wherever possible. Examples of this include:

External business rules engine logic, supported by WODM, to reduce the amount of business logic that would be duplicated across both business functions and make business rules more maintainable for the future.

Data sharing is enabled through the use of a modern Enterprise Service Bus (IBM Web Sphere ESB) supporting Florida’s integration needs with the Federal Data Services Hub and the Federally Facilitated Exchange (FFE).

Extensible: The NextGen platform will meet the current needs of Florida and provides the ability to create and add new components. This is a key part of achieving Florida’s long range vision.

Enhanced User Experience – Deloitte has invested in refining NextGen to deliver a user experience that depicts information clearly and guides the customer through processes in an efficient and expeditious manner. The following screenshot illustrates the customer-friendly orientation and intuitive screen layout of existing NextGen self-service functionality.

Figure 4 – Sample Deloitte HHS NextGen Self Service Portal Screens

Description of Application Architecture

Our proposed self-service application architecture is a layered n-tiered, Web-based system that is scalable and modular and designed for extensibility and flexibility. The diagram below depicts the various self-service features of our NextGen solution and how it interfaces with the existing ACCESS Florida sub-systems.

Figure 5 – Application Architecture with Deloitte HHS NextGen Self Service Portal

The table below describes the salient features of the Self-Service Portal. Most of these features are pre-built in the base NextGen solution. We configure and customize the base solution to fulfill Phase 3 requirements and integration with other ACCESS Florida sub systems.

Self Service Function/Feature

Description

Pre-Screening

· Customers can pre-screen themselves to see if they might be eligible for SNAP, Cash and Medicaid benefits

· Although Pre-Screening tool does not determine eligibility, it is helpful for the customers before they complete the full application process

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

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

· Any demographic changes including address changes and/or case closure requests reported by customers are automatically updated in FLORIDA system without a worker’s intervention

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 DCF

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 5 – Features of our Self-service portal

The solution provides optimal application architecture to seamlessly interface with external systems (e.g., Federal Data Services Hub, SCHIP) via the ESB. It interfaces with the Access Management System (AMS) worker portal to provide a mechanism for smart routing of regular as well as ‘No Touch’ workflows.

2.4.3 Interfaces to a Health Insurance Exchange, the Federal Data Hub and other data verification sources

To depict the interaction between the Phase 3 solution, the Federal Data Services Hub, the Health Insurance Exchange (i.e., the Federally Facilitated Exchange based on the State’s selection presented to the Department of Health and Human Services)) and other external sources that support data verification we provide two flows: (1) an application submitted via Florida ACCESS Self Service portal and (2) an account transfer is received from the Federally Facilitated Exchange.

Figure 6 represents a scenario where a household member is applying for health coverage via the NextGen Self-Service Portal. Applications that are submitted through the new ACCESS Self Service Web Portal will utilize the real-time verification services for Identity Verification and Authentication that is currently being implemented in the current ACCESS Florida Self Service Portal. Once the applicant has completed the online application, the Self-Service Portal sends a verification request through the ESB to the Federal Data Services Hub to request household composition, incarceration, Social Security Number (SSN), citizenship and income (including tax filer status) information.

The completed application, including verification information, is sent to the ACCESS Florida system for further any further processing that is required. As DCF has indicated a preference for “no touch processing”, as part of the Validate Application Completeness process the Phase 3 solution will assess if the applications include verifications that are pending for individuals eligible for MAGI. The solution will route applications that have pending information to the intake process, while MAGI applications that do not have pending verification will bypass the intake process that requires worker intervention. The ACCESS Florida system and users will use other data verification sources, based on the State’s Verification Plan, to verify information that is pending. Automated verification processes that are currently supported by the FLORIDA system through interfaces with other federal and state agencies and manual verification processes will continue to be utilized for cases where verifications are not available through the Federal Data Services Hub and other real-time verification sources.

For individuals that are determined to be CHIP eligible, the ACCESS Florida system will send application data to the FHK KidCare system. The ACCESS system will transfer account information for individuals that are determined to be ineligible for Medicaid, both MAGI and non-MAGI categories, and are screened to be APTC eligible to the Federally Facilitated Exchange. For individuals that are determined to be eligible for Medicaid, MAGI and non-MAGI categories not including CHIP, the ACCESS system will send enrollment information to Florida’s MMIS system via the current process.

For each member of the household that is determined to be ineligible for MAGI or non-MAGI related Medicaid, but potentially eligible for APTC, the ACCESS Florida system will send a notice to the applicants notifying them of their ineligibility for Medicaid and that their application has been transferred to the Federally Facilitated Exchange for processing APTC eligibility.

Figure 6 - Phase 3 Solution interface with the Federal Data Services Hub, Florida Healthy Kids, the Federally Facilitated Exchange and other third party data sources.

Figure 7 below represents a scenario where a household member accesses the Federally Facilitated Exchange to evaluate health care coverage options. As part of the Federally Facilitated Exchange health coverage application process, the FIELDS ESB will receive a request to send to the ACCESS Florida system as well as the FHK system to provide the current eligibility status for each individual eligibility status request. The FIELDS ESB will send a response to the Federally Facilitated Exchange with the eligibility status. In this particular scenario, if no one is eligible for coverage through the exchange, it will trigger the Federally Facilitated Exchange to initiate an account transfer, containing application information received by the Federally Facilitated Exchange, to the FIELDS ESB.

The FIELDS ESB will route individuals, and their application information, that have been determined to be eligible for CHIP to the FHK system. In cases where the application for CHIP is received by the Florida Healthy Kids, CHIP eligibility will be determined by sending a request to FIELDS which maintains the common rules engine and associated MAGI eligibility rules. The FIELDS ESB will also route individuals, and their application information, to the ACCESS Florida system to complete application processing. Applications received from the Federally Facilitated Exchange will follow a process similar to those received from the Self-Service Portal. The only difference in this scenario is that FIELDS ESB will send responses to the Federally Facilitated Exchange for eligibility determination results for both eligible and ineligible individuals.

Figure 7 - Phase 3 Solution interface with the Federally Facilitated Exchange, Florida Healthy Kids and other third party data sources,

2.4.4 Integration between the new system components and the ACCESS Florida System to accommodate new MAGI data and business processes to support the ACA

Our Phase 3 technical solution approach and components not only helps the Department meet its objectives to meet ACA compliance with reduced project schedule and technical risk, but also enables it to meet the CMS Seven Conditions and Standards.

Figure 7 depicts an overall architecture view of the implementation of the solution and its integration with the current ACCESS Florida System, and the flow of data and information between data sources, interfaces and data stores.

Figure 8 – Overall Solution Architecture and Data Flow including the “No Touch” process

2.4.5 Support for MAGI application processing

We have an intimate understanding of the current challenges facing the Department. Some of these challenges include limited budget and staff headcount, while facing policy and programmatic changes that will likely drive increased applications and the resulting caseload increase for Florida. Our understanding of the ACA policies has been gained through our national integrated eligibility practice working closely with CMS and by also working closely with numerous states to drive solutions – solutions that span from enhancing legacy assets to replacing legacy assets with our NextGen solution platform. As a result, we understand the impending challenges that the Department faces better than any of our competitors. Combining this with Deloitte’s deep understanding of Florida’s policy, processes and technology assets is critical to being able to deliver a solution for Florida that meets the October, 2013 deadline imposed by the ACA.

Our approach leverages the Department’s current technology assets optimally – where additions and enhancements to the current environment are performed by a team that built and has been maintaining and enhancing these assets for over six years; with many members of our team having over 20 years of hands-on experience with the Department systems.

As part of our preparation activities to help our clients get a head-start, our national practice has developed the eligibility rules for MAGI-based Medicaid based on CMS specifications of the MAGI rules. These rules are pre-loaded into the Business Rules Engine that we have proposed for Florida, which provides you a distinct advantage in terms of the project timeline and a reduced risk of meeting the timeline.

In addition to the direct advantages that are stated above, our solution also eliminates the complexities and additional challenges that would be posed by a replacement solution involving a stand-alone system for MAGI based Medicaid separate from the current ACCESS Florida systems. The following describes a list of the most critical challenges associated with this particular approach, all of which are avoided by Deloitte’s Phase 3 approach.

Challenge

Description

Workload Increase

Need to create two cases – one in the new MAGI Medicaid System and one in the ACCESS Florida system for the members of a household that are applying for MAGI based Medicaid and/or Non-MAGI Medicaid, SNAP, TANF or Refugee Programs.

Staff Productivity

Need for Department staff to use two distinct and disparate systems with different User Interfaces and Work Flows which will likely result in unnecessary complexity, increased training and re-training, and overall reduced productivity.

Data Integrity

Data integrity challenges that result in potential data discrepancy between the two systems and an increased likelihood of eligibility errors in the absence of a complex and potentially error-prone interface between the two systems for data sync-up.

Interface Challenges

Interface challenges with the current interface partner agencies as a result of interface files originating from two distinct systems, as well as having to transmit files to both systems in the potential absence of sophisticated merge/consolidation and split processes.

Two Medicaid Systems

Correspondence challenges that potentially negate the gains that the Department has accomplished in the recent years through consolidation of notices.

Table 7 - Potential Challenges posed by a two system solution for MAGI Medicaid Implementation

As a result of the ACA, the Department faces a substantial increase in the number of applications filed for Medicaid and/or other insurance affordability programs. With the increases in application numbers and caseload size, it is imperative that the Department alleviates the chance of induced inefficiencies.

Through our conversations with the Department through the IRR process, we understand that the Department has an in-depth understanding of these challenges and are looking forward not only to acquire the most effective solution with the lowest risk, but one that can support process efficiencies and “no touch” automation capabilities that eliminates or at least minimizes the need for worker intervention in processing applications and cases.

Deloitte’s proposed solution for Phase 3 not only overcomes these challenges, our solution also supports and provides opportunities that allow for the addition of functions and features that further increase process efficiencies and automation for the Department. Our track record delivering for the Department proves this, as we have delivered proven “no touch” automation solutions within the current ACCESS Florida system.

Our experience building automation and efficiencies at DCF

Over the past six years, Deloitte has worked with DCF side by side on all of its eligibility modernization efforts. The Department has made great strides in modernizing Public Assistance in Florida since the legislative action in 2003 initiating “ESS Modernization” which mandated greater efficiencies in the operation, administration, and delivery of Public Assistance programs. During this time, the program underwent mandated budget and staff reductions. The number of field delivery staff was reduced from a level of 7,200 in 2003 to 4,109 by July 2006, resulting in backlogs in processing applications and increased error rates. With no additional funding support available, the management and delivery staff worked to re-engineer the delivery model eliminating unnecessary and burdensome processes and utilizing Federal and State rules and waivers to the Department’s advantage. Since 2006, Deloitte is working hand in hand with the Department to implement IT solutions that support process re-engineering, automation, addition of new systems and to perform improvements to the legacy systems.

Figure 9 - ACCESS Florida – Modernization and Automation Impact

ACCESS Florida Modernization efforts have resulted in lower error rates despite increase in workload and decrease in staff.

Figure 8 illustrates the impact of these efforts in terms of the caseload size and the number of delivery staff who support the program. The process re-engineering, capabilities of the new systems, and improvements to the legacy systems not only helped weather the multi-fold caseload growth as a result of the economic downturn that started in 2008, but also helped Florida become the state with the least errors in processing SNAP benefits, resulting in multi-year bonuses from the Federal government that have reached nearly $40M – all while increasing the overall customer satisfaction.

“No Touch” Solution

We are proposing an enhancement to our original proposed Phase 3 solution that adds an additional “No Touch” capability for the processing of Medicaid applications. As depicted in Figure 7 in the previous section, the department will continue to receive applications for Medical Assistance through multiple channels, including the newest one, the Health Insurance Exchange (HIX).

A large portion of the applications that are received through the ACCESS Self Service portal are anticipated to be applications for MAGI based Medicaid and are expected to be verified through the Federal Data Services Hub. Referrals received from the HIX are also expected to be falling in this category. This provides the opportunity to have an automated Application Processing, Eligibility Determination and Authorization process that can be completed without manual intervention.

Applications that are submitted through the current channels and through the HIX referrals are collected and accumulated within the ACCESS Database. Currently, e-signed applications are routed into the inboxes of various Administrative Units within AMS for processing by staff. As part of the “No Touch” solution, this process will be modified to identify and validate applications that are complete and with the necessary verifications (from Federal Hub and other approved electronic verification sources) that can be processed without worker review or intervention. Deloitte will collaborate with DCF staff to define the selection criteria for “No Touch” applications that do not require worker reviews.

The applications identified and pass the validation for the “No Touch” automated process will go through a “Data Preparation” sub process that will ready the application data for case processing. The automated “No Touch” process will subsequently execute a systematic process that will invoke transactions in the AMS and FLORIDA systems to perform the Client Registration and Clearance, Application Entry, Standard Filing Unit (SFU), Eligibility Determination and Benefit Calculation (ED/BC) and Authorization Transactions using the application and verification data. Upon completion of the Authorization transaction, the Work Item in AMS will be disposed if no manual action is required on the case or application. Applications that do not successfully undergo all the necessary transactions or sub processes are routed to an exception process. Workers are expected to complete the processing of applications in the exception queue.

The “No Touch” solution will be developed using Java and Oracle technologies and will simulate actions by the Department’s case workers. The process executes the same transactions that are executed by case workers to complete the processing of applications in the ACCESS Management System (AMS) and the legacy FLORIDA system. This approach helps ensure that every application and case undergoes the same eligibility determination process regardless if it is executed by a case worker or through the “No Touch” automated process. It also helps ensure that the system creates the appropriate triggers that generate client notices and interface actions.

Table 8 below provides descriptions of key functions and features of our proposed “No Touch” solution.

Function

Description

Identify and Validate Applications

This sub process identifies Medicaid applications that are complete and have the necessary verifications that do not require review by workers. Applications that meet all requirements for “No Touch” process are selected and routed to the automated process. Applications that do not meet the conditions are routed as usual to the appropriate Administrative Unit inboxes in AMS for processing by workers.

Data Preparation

This process validates the necessary data elements that are required for the Automated Processing and assigns appropriate default values in places of missing data elements (data that is not necessary for the processing of Medicaid Eligibility but are required by the system) to complete transactions and processes. Deloitte will collaborate with DCF staff during fit-gap to define the appropriate default values that are allowed to be used in places where data is not available in the application or in other sources (For example: Federal Hub). The process is designed and developed after a careful and close analysis of the data element requirements for transactions that constitute the FLORIDA processes.

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. Exception records will be generated if and when the tool is unable to complete Statewide clearance due to missing or conflicting Demographic data in the FLORIDA system.

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.

Perform SFU and EDBC

Upon completion of data entry in the Application Entry screens, the process will invoke and execute the SFU and ED/BC transactions and programs. Depending upon the program selections, household composition and technical conditions, these processes will build the Standard Filing Units of categories and determine their eligibility.

Perform Authorization

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

During fit-gap, Deloitte will collaborate with DCF staff to define the rules for Authorizing/Not Authorizing Assistance Groups and the appropriate reason codes to be used.

Perform AMS Update

The Work Item Update process updates AMS Work Item details to help ensure that the work item is disposed in the case of successful process completion or to update the progress in case of exceptions.

Perform Exceptions Reporting

Applications that are selected for “No Touch” process could potentially encounter issues that prevent the automated process from completing all the necessary actions for application processing. Potential reasons include data discrepancy between the new information in the application and already existing data in the FLORIDA system.

During fit-gap, Deloitte will collaborate with DCF staff to define the exception rules and the exception reporting functions within AMS or the Exception Management System.

Table 8 - Critical Functions that Support the Automated “No Touch” Process

We understand that the State of Florida has not decided if it is planning to expand Medicaid as recommended by the Affordable Care Act. In case the State decides to expand Medicaid, there will only be minimal changes that will be required for the “No Touch” tool. This is accomplished as a result of the modularity of our solution that does not directly interfere with core Client Registration, and Application Entry transactions and Eligibility Transactions.

2.4.6 Addition of non-MAGI eligibility rules for medical assistance programs to the business rules engine

At the time of implementation of MAGI, all of the technical, asset and income eligibility rules for the new MAGI based Medicaid groups will be coded in the IBM WODM Rules Engine. As described in section 2.4.1, the FLORIDA system EDBC programs will invoke MAGI rules for Eligibility Determination. We agree with the Department’s plan to convert the eligibility rules for non-MAGI Medical assistance groups also into the rules engine. This not only allows the storing and managing all of the eligibility rules for all Medical assistance programs in one single repository, but extents the functionality and flexibility offered by the rules engine to the non-MAGI Medicaid categories also.

We took into consideration of the proposed start date of April 1, 2013 for the project and the compressed timeline for the implementation of the solution for MAGI compliance by January 1, 2014. We agree with the Department’s low risk approach to perform the conversion of Non-MAGI rules as a separate project release after the implementation MAGI. As a result, we propose to address Phase 3 in two releases – Phase 3A and Phase 3B earlier in this section and depicted in the project time line. This approach allows the project to deliver the required ACA functionality by the January 1, 2014 milestone and the non-MAGI rules shortly thereafter.

The scope of work related to the business rules engine for Phase 3A and Phase 3B includes the eligibility rules for MAGI and non-MAGI related Medicaid/Medical Assistance category groups. This includes eligibility rules that determine the technical, asset, and income eligibility for assistance groups within the FLORIDA EDBC module.

Table 8 below provides descriptions of key components that are included in the conversion of the non MAGI Medicaid rules to the 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 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 9 - Critical Functions that Support the Automated “No Touch” Process

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.4.7 Our Hardware and Software Approach

Based on our IRR 7 meeting on February 22, 2013, we have reviewed our original hardware and software configuration and aligned it in accordance with feedback received from the Department. To meet the Department’s objectives of PPACA compliance under a tight timeline, with less risk, and in a cost effective manner, we have developed the approach detailed in this section. Our approach is centered on three critical considerations, as depicted in figure 10 below.

· Developing an efficient way to modify the state’s existing ACCESS Florida applications to meet your business requirements while mitigating performance and systems integration risk.

· Implementing a solution that uses turn-key infrastructure capabilities for impacted open-systems environments that include the Self Service portal environment and the Enterprise Service Bus (ESB).

· Re-using existing software licenses to the extent possible thereby helping the Department reduce costs incurred for this initiative.

Figure 10 – Deloitte Hardware/Software Approach – key considerations

Re-use existing ACCESS Mainframe Environments

The Department and its partner NSRC currently operate an extensive Mainframe infrastructure that supports production and multiple test environments that house the ACCESS Florida systems and applications. Given the short timeline for completing Phase 3A for ACA compliance, we believe that it would be most efficient and less risky for the Department to consider leveraging the current Mainframe Infrastructure for the development and testing functions (as opposed to procuring, installing and configuring a new mainframe environment for the project). The benefits of this approach are

· requires significantly less resources from the our team, the Department as well as NSRC staff

· protects valuable time for the project schedule to focus on new solution development and integration activities

· eliminates the time required to smoke test new environments before they could be used for functional development and testing.

Since such new environments would only be used for development and testing specific to this initiative, it will create more complexity and configuration management risk to merge back to the state’s existing ACCESS Florida Mainframe system environments. Given that your current infrastructure offers FLORIDA system test environments that are available and ready for the project’s use, we propose leveraging these together with a new hardware and system software environments for the NextGen self-service portal solution to meet the project’s requirements.

The majority of new changes to the software on the Mainframe will involve standard changes to the COBOL program elements and IMS databases. Currently, the Department uses a mature and established configuration management process for the management of these assets. In addition to these, our proposed solution of WODM on Z/OS will require minimal additional access for Deloitte team members to the current environments to install the necessary libraries. We have skilled staff members in our proposed team to perform the installation and configuration of this software. The approach to the Mainframe software is to follow the existing configuration management processes and follow established processes for code stream management on the mainframe. This reduces significant challenges for the Department as well as reduces implementation effort to deliver the new solution and meet the ACA timeline.

Turnkey Open Systems Infrastructure

We understand the state’s desire to have quick turnaround for installation and provisioning of servers required to support self-service and other open systems infrastructure such as the ESB, Oracle database and utilities. Our proposed approach uses VCE VBLOCK which combines the power of Cisco UCS Blades, EMC Storage, VM Ware and Cisco networking. Having a single vendor to coordinate with implies a single point of contact for all troubleshooting and resolutions. The infrastructure ships pre-assembled and the installation services which are part of our quote include complete configuration that allows the Deloitte team to start provisioning servers using VM Ware in a turnkey fashion. All the management utilities for the VBLOCK infrastructure come packaged with it. This allows for our infrastructure teams to efficiently provision servers and reduce turnaround time to load system software and configure environments for use. The infrastructure’s explicit use of VM Ware allows us to maximize on the hardware resources.

To meet the Department’s requirements cost effectively, we will procure a VBLOCK infrastructure for development and production. We will use the production environment to support the project’s system and user acceptance testing efforts. Once user acceptance testing is completed, we will refresh the environment and prepare it for production cutover. Once the new self-service portal is deployed, we will decommission the current ACCESS self-service portal and re-purpose the application servers for use as the new test environment servers.

Re-use State’s Existing Software investments

The Department has made significant investments in certain software components and underlying infrastructure for enterprise use such as Pitney Bowes Address Validation products and HP Exstream for Client Notices generation. Our approach is to leverage the state’s existing assets around these components, thereby reducing the cost of development, testing and implementation as well as time required to procure, provision and configure environments around these components. We propose to map the state’s existing environments for these tools and components to the new environments we provision for the open systems.


Deloitte’s Response to ITN# 03F12GC1

Vendor Assumptions Page 31

2.4.8 Level of State Participation

State resources will be expected to work with Deloitte in order to meet the milestones identified in the work plan and the proposed project schedule. The following table identifies the additional skill sets that Deloitte will require to support Phase 3 project efforts. The table further defines the high-level responsibilities during each phase of the project life cycle. As these tasks and activities may be conducted by one or more individuals in each phase and throughout the project, the exact number of Department staff required to carry out these tasks may vary. Also, the required staffing levels for both Deloitte and the Department will increase if the projects do not commence as per the identified start dates and the timelines are further condensed.

Skill Set

Fit/Gap – Requirements

Fit/Gap – Design

Development

Test

UAT

Train

Deploy

State and Federal policy subject matter expertise across) Medical Assistance

(6-10 staff members)

18-25 sessions

Deliverable Reviews

25-35 sessions

Deliverable Reviews

Design/ Requirements Clarification

Deliverable Reviews


Deliverable Reviews

Test Execution (~500 cases)

Operations Clarification


Process and procedure subject matter expertise associated with Medical Assistance including knowledge to cover all roles supporting the current and future operational model

(6-10 staff members)

18-25 sessions

Deliverable Reviews

25-35 sessions

Deliverable Reviews


Deliverable Reviews


Deliverable Reviews

Test Execution (~500 cases)



Technical infrastructure and operations subject matter expertise

(3-4 staff members)

3-5 sessions

Deliverable Reviews

3-5 sessions

Deliverable Reviews


Deliverable Reviews

Deliverable Reviews

Deliverable Reviews

Operational Readiness Review Support

Support Go-Live

Security policy, procedure, and tool subject matter expertise

(1-3 staff members)

2-3 sessions

Deliverable Reviews

2-3 sessions

Deliverable Reviews


Deliverable Reviews

Deliverable Reviews

Deliverable Reviews

Operational Readiness Review Support

Support Go-Live

Resources to support training sessions, logistics, and go-live

(3-8 staff members)

Training Material Review

Training Material Review

Support Training Sessions

Support Go-Live

Table 10 - Phase 3 DCF staff member and role requirements.

2.4.9 Deliverables List

Deliverable Name

Deliverable to be Created in Phase 3?

Deliverable Expectations Document (DED) to be Created?

Number of Interim Draft Deliverables to be Created

Days for DCF to Review Deliverable

Days for Deloitte to Modify and Resubmit Deliverable after DCF Review

Days for DCF to Review Deliverable After Deloitte Resubmission

INCEPTION PHASE

Disaster Preparedness Plan

Yes

Yes

0

5

5

2

Baseline Project Management Plan

Yes

Yes

0

5

5

2

Baseline Deliverable Expectation Documents

Yes

No

0

5

5

2

ELABORATION PHASE

Detailed Requirements Definition Document

Yes

Yes

2

10

10

3

Detailed Requirements Traceability Matrix

Yes

Yes

2

10

10

3

Updated Project Management Plans

Yes

No

0

5

5

2

Data Conversion Plan

No

Data Conversion Design

No

Functional Design Specifications

Yes

Yes

2

10

10

3

Technical Design Specifications

Yes

Yes

2

10

10

3

Database Design

Yes

Yes

2

10

10

3

Development/QA Environment

Yes

No

0

5

5

2

Disaster Recovery Plan

Yes

Yes

2

5

5

2


Yes

No

0

5

5

2

CONSTRUCTION PHASE

Master Test Plan

Yes

Yes

2

10

10

3

Application Architecture Development

Yes

No

0

5

5

2

Training/Performance Environments

Yes

No

0

5

5

2

Production Environment (letter)

Yes

No

0

5

5

2

Code and Unit Test Data Conversion Software

No

Test Materials

Yes

Yes

2

10

10

3

Organizational Change Management Plan

No

Staffing and Productivity Impact Analysis Report

No


Yes

No

0

5

5

2

System Test Results

Yes

Yes

0

5

5

2

Technical Test Results

Yes

Yes

0

5

5

2

Performance Test Results

Yes

Yes

0

5

5

2

Conversion Test

No

Converted Data Test Results

No

UAT Results

Yes

Yes

0

5

5

2

SNAP Production Pilot Results (SNAP system functionality only)

No

Implementation Plan

Yes

Yes

2

5

5

2

Training Plan

Yes

Yes

2

5

5

2


Yes

No

0

5

5

2

TRANSITION PHASE

Training

Yes

Yes

0

5

5

2

Operations Documentation

Yes

Yes

2

5

5

2

System Implementation

Yes

Yes

0

5

5

2

Transition Plan

No

Closeout Letter

Yes

No

0

5

5

2

System Operations and Maintenance Plan

Yes

Yes

2

5

5

2


Yes

No

0

5

5

2

Table 11 - Phase 3 deliverable parameters.

IRR Section 2.4 Project Location

Vendor Instructions

Using the table below, please provide the number of project staff that DCF will need to provide space for during the project.

Per the Department’s request, we have provided the number of project staff that DCF need to provide space for during the project.

Team

Total count

Project Management Team

7

Business Analysts & Functional SMEs

20

Technical Leads

4

Developers/Programmers

30

Testers

10

OCM & Trainers

2

Technical Team – Configuration, Infrastructure, DBA, ESB, Rules Engine

14

Max number of staff at any point of the DDI project

87

Table 9 - Project Staff counts

IRR Section 2.5 Updated Pricing

Vendor Instructions

Using the SOWs, a start date of 4/1/13, and the instructions provided in 2.4 of this IRR, and update your solution pricing and Bill of Materials.

Assume DCF will provide space for the vendor project and O&M teams.

Assume the following Training guidelines:

· CBT for all new system components is required – This is required for internal and external facing components.

· In person classroom training for 300 staff is required. This may be a combination of train the trainer or true instructor lead classes depending on the topic or user-base population.

The Vendor shall convert any assumptions from previous IRR submissions to proposed contract language within the framework and structure of the SOW. Finally, please update the pricing, Bill of Materials or SOWs accordingly.

Per the Department’s request, we have updated our solution pricing and Bill of Materials and have included updated cost reply forms and a revised BOM listing with this submission.

IRR Section 2.6 O&M Rate and Hours Clarification

Vendor Instructions

Using the attached RDD, update to show how the vendor’s proposal fits the solution and what items may be out of scope.

Per the Department’s prioritization of activities in this IRR, we will provide a response to this section in the next iteration of our IRR response, due to the Department by 11:00 AM EST on February 26, 2013.


Deloitte’s Response to ITN# 03F12GC1 – Interim Revised Response #7

Interim Revised Response #7 Page 2

Appendix A

DDI SOW Section Number

Description of Vendor Change

Explanation

4. Solution Overview

Added specifics on the approach and scope

Clarify the scope of work.

7.2 Warranty Performance Period

Added language “defined as deploying the system to Production”

Need mutual agreement on the successful completion of DDI

9.1 Plan Phase

Deleted “The Provider is responsible for preparing the work site for occupation by the Project team and the installation of all work site hardware and software”

Project facility vendor is no longer required

12 Deliverables

Modifications to reflect the changes in the number of DEDs, number of interim reviews and review period

Modifications to reflect the changes in the number of DEDs, number of interim reviews and review period

12.1.2 Completion Criteria

Modified as a result of altering or removing items

Modified as a result of altering or removing items

Appendix B

O&M SOW Section Number

Description of Vendor Change

Explanation

*Expand the table as needed.

Performance risks mitigated using in-process MAGI Rules using WODM for z/OS

Re-use existing mainframe to reduce configuration management and merge challenges.

New VBLOCK based datacenter-in-a-box infrastructure for all open systems environments.

Re-use State's existing software investments

Address validation integration with existing State Pitney Bowes enterprise infrastructure.

Re-use state's existing HP ExStream Server Infrastructure for any notice changes.

Maximize on hardware capacity across environments using turn-key virtualization and provisioning with VBLOCK.

Turnkey Open Systems Infrastructure :

Re-use Existing Mainframe:

JFMAMJJASONDJFMAMJJASONDJFMAMJJASOND

Plan

Define

Design

Develop

Sys Test

UAT

Train

Deploy

Stablize

Warranty

Plan

Define

Design

Develop

Sys Test

UAT

Deploy

Stablize

Warranty

Phase 3B - Non-MAGI Medicaid in Rules Engine

201320142015

Phase 3A - ACA/MAGI Project Schedule with No Touch

Z/OS Mainframe

IMS DB

DriverTANF

ED/BC

MAGINon MAGISNAP

SFU

DriverTANFNon MAGISNAPMAGI

Client Registration

Application Entry

Authorization

Benefit Issuance

Benefit Recovery

Case Management

Scheduling

Quality Assurance

Reporting/

Periodic Reporting

Data Exchanges

Interfaces

FLORIDA SYSTEMIBM Web Sphere for Z/OS

MAGI Rules Web Service ProviderDB2 DB

WODM Rules Execution

Server

Florida Kid Care

System(CHIP)

Start Up Task

(Web Sphere for Z/OS)

WODM

Decision Center Repository (for Rules)

Rule

Designer(Rules Development)

WODM

Decision Center (Rules Management)

IBM WODM

FL_ACCESS_IE-202

NEXTGEN SELF-SERVICE PORTAL

ENTERPRISE SERVICE BUS

WORKER

PORTAL (ACCESS

MANAGEMENT

SYSTEM)

FLORIDA SYSTEM

IBM

WODM

RULES

ENGINE

N

O

-

T

O

U

C

H

P

R

O

C

E

S

S

PRE-SCREENINGAPPLICATION

REDETERMINATIONCHANGES

ADDITIONAL

ASSISTANCE

ELECTRONIC

APPLICATION

UPLOAD

DOCUMENT

PRINT/REQUEST

MEDICAID CARD

CHECK BENEFITSPARTNER VIEW

PROVIDER VIEW

SIGN-UP/VIEW

ELECTRONIC NOTICES

FEDERAL DATA

HUB

SCHIPFFE

CUSTOMERPARTNERPROVIDERELECTRONIC APPMANUAL APPLICATION

�

NEXTGEN SELF-SERVICE PORTAL

ENTERPRISE SERVICE BUS

WORKER PORTAL (ACCESS MANAGEMENT SYSTEM)

FLORIDA SYSTEM

IBM WODM RULES ENGINE

NO-TOUCH PROCESS

PRE-SCREENING

APPLICATION

REDETERMINATION

CHANGES

ADDITIONAL ASSISTANCE

ELECTRONIC APPLICATION

UPLOAD DOCUMENT

PRINT/REQUEST MEDICAID CARD

CHECK BENEFITS

PARTNER VIEW

PROVIDER VIEW

SIGN-UP/VIEW ELECTRONIC NOTICES

FEDERAL DATA HUB

SCHIP

FFE

CUSTOMER

PARTNER

PROVIDER

ELECTRONIC APP

MANUAL APPLICATION

ACCESS Self Service Portal

Access Health CoverageHIX

Verify MAGI Application

Information

Confirm/Submit

Yes

X

No

Federal HubIncomeCitizenshipIncarcerationAssistance GroupMedicalAssistance Status

ACCESS DB

AMSFLORIDA

ACCESS Florida Worker

No Touch Process

1.Selection/Validation2.Data Preparation3.Client Registration4.Application Entry5.SFU and EDBC6.Authorization7.AMS Updates8.Exception Reporting

Submit

Account

Transger

HIX

CHIP EligibilityMedicaid

Enrollment

4

Electronic Application Partners

CHIP

Application

WODM Rules EngineESB

ESBESBESB

ACCESS Florida –Modernization Impact

July 2003EligibilityStaffJuly 2010

8,0007,0006,0005,0004,0003,0002,000

Eligibility FTEPersons Receiving Benefits

3,800,0003,600,0003,400,0003,200,0003,000,0002,800,0002,600,0002,400,0002,200,0002,000,0001,800,000

FL_ACCESS_IE-011_4

37%

Beneficiaries

Unduplicated Persons Receiving Benefits

45%

Deloitte –March 2006

Pre-screeningACCESS Web AppllicationMyAccountAMSIVR/ARU