Interim Revised Response #7A - Florida Department of ...



941070954405ACCESS Florida System ReplacementState of Florida Department of Children and FamiliesOffice of Economic Self-SufficiencyInterim Revised Response #7AITN# 03F12GC1Deloitte Consulting LLPFederal ID: 06-1454513303847533020000Rick Dorman, Principal1203 Governors Square Blvd.Suite 400Tallahassee, FL 32301Ph. +1 412 402 5170February 25, 2013Identification of Enclosed DocumentsInterim Revised Response ?Title PageIdentification of Enclose Documents?Transmittal Letter?Interim Revised Response Section 2.1Interim Revised Response Section 2.2Interim Revised Response Section 2.3Interim Revised Response Section 2.4Interim Revised Response Section 2.5Interim Revised Response Section 2.6Appendix A – DDI SOW TableAppendix B – O&M SOW Table4587875-152400Deloitte Consulting LLP1203 Governors Square Blvd Tallahassee, FL 32301 USATel:+1 850 521 4800 00Deloitte Consulting LLP1203 Governors Square Blvd Tallahassee, FL 32301 USATel:+1 850 521 4800 0-45720000February 25, 2013Peggy ClabornProcurement ManagerFlorida Department of Children and Families1317 Winewood Boulevard, Building 2, Room 304Tallahassee, Florida 32399-0700Dear Ms. Claborn:Deloitte Consulting LLP (Deloitte) 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.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 programsWeb Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My AccountInterfaces to a health insurance exchange, the federal data hub and other data verification sourcesIntegration between the new system components and the ACCESS Florida System to accommodate new MAGI data and business processes to support the ACASupport for MAGI application processingAddition of non-MAGI eligibility rules for medical assistance programs to the business rules engineKey changes to our proposed approach outlined in our response are as follows:We have a new web portal that better aligns with the State’s defined expectationsIn 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. 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. 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. 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.We are maintaining our commitment to meeting the federally mandated deadlines for ACA complianceWe 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, rdorman@) or John Hugill (+1 850 521 4816, jhugill@).25717522860000Sincerely,Deloitte Consulting LLPBy: __________________________Rick DormanPrincipalInterim Revised ResponseIRR Section 2.1 DDI SOWVendor InstructionsThe 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 SOWVendor InstructionsThe 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 ApproachVendor InstructionsUsing 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.Business rules engine containing MAGI eligibility rules for medical assistance programsWeb Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My AccountInterfaces to a health insurance exchange, the federal data hub and other data verification sourcesIntegration between the new system components and the ACCESS Florida System to accommodate new MAGI data and business processes to support the ACASupport for MAGI application processingAddition of non-MAGI eligibility rules for medical assistance programs to the business rules engineWhile 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 ScheduleUpon 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.PhaseBeginEndPlan04/01/201304/30/2013Define04/08/201306/30/2013Design05/01/201308/15//2013Develop05/13/201309/30/2013System Test08/12/201310/31/2013UAT10/14/201311/30/2013Implement12/03/201312/13/2013Stabilize12/13/201303/13/2014Warranty03/14/201409/10/2014Table 2- Project Phase Gate Schedule for Release 3A for MAGI/ACA complianceThe following table provides the high-level schedule for 3B that includes the proposed start and end dates for each of project phases.PhaseBeginEndPlan02/15/201402/28/2014Define03/01/201404/15/2014Design04/01/201405/31/2014Develop04/15/201408/14/2014System Test07/15/201409/30/2014UAT09/18/201411/15/2014Implement11/15/201412/12/2014Stabilize12/13/201403/13/2015Warranty03/14/201509/10/2015Table 3 - Project Phase Gate Schedule for Release 3B for Non-MAGI Medical Assistance Programs rules conversion to Rules EngineThe 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 SystemsThe 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 FlowDescriptionInputRules 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).OutputRules 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 Systems2.4.2 Web Portal that supports integrated eligibility program screening, application data collection and submission, including functionality as currently included in My Account4781550127000A solution designed to meet your needsThe 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.00A solution designed to meet your needsThe 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.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.The following table highlights some of the business driven features of our NextGen self-service portal and the benefits provided to customers. FeaturesBenefits Single, Integrated Online ApplicationEliminates 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 mon Screening ToolThe 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 ServiceApplications are more accessible, by introducing alternatives to meeting with or calling a worker and providing services outside of traditional business hours.Increased Program ParticipationRaises 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 WorkersReduces 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 ConsistencyErrors 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 FutureProvides 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 Portal029210The 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 ScreensDescription of Application ArchitectureOur 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 PortalThe 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/FeatureDescriptionPre-ScreeningCustomers can pre-screen themselves to see if they might be eligible for SNAP, Cash and Medicaid benefitsAlthough Pre-Screening tool does not determine eligibility, it is helpful for the customers before they complete the full application processApplication for BenefitsCustomers can apply for services by completing a web application from any location that has internet accessApplication information requested is driven by the benefit selection chosen by the customerCustomers can also resume their incomplete applications from the self-service portalIncludes summary checkpoints through the application to identify missing informationCheck BenefitsCustomers can register for an account within the Self-Service PortalCustomers can check their benefits as well as the status of their pending requestsReport ChangesCustomers can notify the department with any of the changes in their case information from the My Account component of the Self-Service PortalIncludes ten pre-configured change reporting types (e.g., change in income, change in address) that guide users to enter only the requested change typeProvides 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 currentAny demographic changes including address changes and/or case closure requests reported by customers are automatically updated in FLORIDA system without a worker’s interventionRedeterminations/Additional AssistanceCustomers can apply for Recertification of their benefits and additional benefits from My Account self-service portalThe system pre-populates the existing household, eligibility and benefits information of a customer. The customer need not furnish the previously submitted informationAdditional AssistanceSimplified and streamlined Recertification/Additional Benefits application process Medicaid CardCustomers can view their Medicaid eligibility from the self-service portalCustomers can print a temporary Medicaid card and/or request a permanent Gold Medicaid card from self-service portal Upload DocumentsCustomers 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 componentCustomers can also view their existing documents they previously uploadedIncludes capabilities to upload from workstation or from a scannerOnline Client NoticesCustomers can view and print notices provided by DCF Email NotificationCustomers 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 ViewCommunity Partner View provides a secure gateway to a customer’s accountAllows partners to view the status of all customer’s for whom they have submitted application, change reports or recertifications through a single loginProvider ViewAllows providers to view the status of all customer’s for whom they have submitted application, change reports or recertifications through a single loginService providers can verify Medicaid eligibility and benefit information of their customersTable 5 – Features of our Self-service portalThe 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 sourcesTo 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 ACAOur 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” process2.4.5 Support for MAGI application processingWe 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.ChallengeDescriptionWorkload IncreaseNeed 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 ProductivityNeed 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 ChallengesInterface 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 SystemsCorrespondence 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 ImplementationAs 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 DCFOver 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 ImpactACCESS 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” SolutionWe 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.FunctionDescriptionIdentify and Validate ApplicationsThis 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 PreparationThis 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 RegistrationClient 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 EntryUpon 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 EDBCUpon 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 AuthorizationUpon 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 UpdateThe 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 ReportingApplications 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” ProcessWe 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 engineAt 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.FunctionDescriptionTechnical Eligibility RulesRules 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 RulesRules 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 EligibilityRules 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 updatesModifications 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” ProcessThe 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 considerationsRe-use existing ACCESS Mainframe EnvironmentsThe 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 activitieseliminates 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 InfrastructureWe 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 investmentsThe 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.2.4.8 Level of State ParticipationState 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 SetFit/Gap – RequirementsFit/Gap – DesignDevelopmentTestUATTrainDeployState and Federal policy subject matter expertise across) Medical Assistance(6-10 staff members)18-25 sessionsDeliverable Reviews25-35 sessionsDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsTest Execution (~500 cases)Operations ClarificationOperations ClarificationProcess 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 sessionsDeliverable Reviews25-35 sessionsDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsTest Execution (~500 cases)Operations ClarificationOperations ClarificationTechnical infrastructure and operations subject matter expertise(3-4 staff members)3-5 sessionsDeliverable Reviews3-5 sessionsDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsDeliverable ReviewsDeliverable ReviewsOperational Readiness Review SupportSupport Go-LiveSecurity policy, procedure, and tool subject matter expertise(1-3 staff members)2-3 sessionsDeliverable Reviews2-3 sessionsDeliverable ReviewsDesign/ Requirements ClarificationDeliverable ReviewsDeliverable ReviewsDeliverable ReviewsOperational Readiness Review SupportSupport Go-LiveResources to support training sessions, logistics, and go-live(3-8 staff members)Training Material ReviewTraining Material ReviewSupport Training SessionsSupport Go-LiveTable 10 - Phase 3 DCF staff member and role requirements.2.4.9 Deliverables List Deliverable NameDeliverable to be Created in Phase 3?Deliverable Expectations Document (DED) to be Created?Number of Interim Draft Deliverables to be CreatedDays for DCF to Review DeliverableDays for Deloitte to Modify and Resubmit Deliverable after DCF ReviewDays for DCF to Review Deliverable After Deloitte ResubmissionINCEPTION PHASEDisaster Preparedness PlanYesYes0552Baseline Project Management PlanYesYes0552Baseline Deliverable Expectation DocumentsYesNo0552ELABORATION PHASEDetailed Requirements Definition DocumentYesYes210103Detailed Requirements Traceability MatrixYesYes210103Updated Project Management PlansYesNo0552Data Conversion PlanNoData Conversion DesignNoFunctional Design SpecificationsYesYes210103Technical Design SpecificationsYesYes210103Database DesignYesYes210103Development/QA EnvironmentYesNo0552Disaster Recovery PlanYesYes2552Updated Project Management PlansYesNo0552CONSTRUCTION PHASEMaster Test PlanYesYes210103Application Architecture DevelopmentYesNo0552Training/Performance EnvironmentsYesNo0552Production Environment (letter)YesNo0552Code and Unit Test Data Conversion SoftwareNoTest MaterialsYesYes210103Organizational Change Management PlanNoStaffing and Productivity Impact Analysis ReportNoUpdated Project Management PlansYesNo0552System Test ResultsYesYes0552Technical Test ResultsYesYes0552Performance Test ResultsYesYes0552Conversion TestNoConverted Data Test ResultsNoUAT ResultsYesYes0552SNAP Production Pilot Results (SNAP system functionality only)NoImplementation PlanYesYes2552Training PlanYesYes2552Updated Project Management PlansYesNo0552TRANSITION PHASETrainingYesYes0552Operations DocumentationYesYes2552System ImplementationYesYes0552Transition PlanNoCloseout LetterYesNo0552System Operations and Maintenance PlanYesYes2552Updated Project Management PlansYesNo0552Table 11 - Phase 3 deliverable parameters.IRR Section 2.4 Project LocationVendor InstructionsUsing 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.TeamTotal countProject Management Team7Business Analysts & Functional SMEs20Technical Leads4Developers/Programmers30Testers10OCM & Trainers2Technical Team – Configuration, Infrastructure, DBA, ESB, Rules Engine14Max number of staff at any point of the DDI project87Table 9 - Project Staff countsIRR Section 2.5 Updated PricingVendor InstructionsUsing 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 ClarificationVendor InstructionsUsing 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.Appendix ADDI SOW Section NumberDescription of Vendor ChangeExplanation4. Solution OverviewAdded specifics on the approach and scopeClarify the scope of work.7.2 Warranty Performance PeriodAdded language “defined as deploying the system to Production”Need mutual agreement on the successful completion of DDI9.1 Plan PhaseDeleted “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 required12 DeliverablesModifications to reflect the changes in the number of DEDs, number of interim reviews and review periodModifications to reflect the changes in the number of DEDs, number of interim reviews and review period12.1.2 Completion CriteriaModified as a result of altering or removing itemsModified as a result of altering or removing itemsAppendix BO&M SOW Section NumberDescription of Vendor ChangeExplanation*Expand the table as needed. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download