Pharmacy Point of Sale (POS) Module Replacement Project

STATE OF WASHINGTON HEALTH CARE AUTHORITY REQUEST FOR PROPOSALS (RFP) RFP NO. 2020HCA28 NOTE: If you download and respond to this RFP from the Health Care Authority website, you are responsible for sending your name, address, e-mail address, and telephone number to the RFP Coordinator in order for your organization to receive any RFP amendments or bidder questions/agency answers. HCA is not responsible for any failure of your organization to send the information or for any repercussions that may result to your organization because of any such failure. PROJECT TITLE: Pharmacy Point of Sale (POS) Module Replacement Project PROPOSAL DUE DATE: April 12, 2021 by 12:00 p.m. (noon) Pacific Standard Time or Pacific Daylight Time, Olympia, Washington, USA. Only E-mailed bids will be accepted. Physical mail and faxed bids will not be accepted. ESTIMATED TIME PERIOD FOR CONTRACT: September 17, 2021 to March 16, 2027. The Health Care Authority reserves the right to extend the contract for up to 3

additional years at the sole discretion of the Health Care Authority. BIDDER ELIGIBILITY: This procurement is open to those Bidders that satisfy the minimum qualifications (see Section 1.11) stated herein and that are available for work in Washington State. DEFINITIONS: A list of definitions for this RFP are found in Attachment 1, Definitions. LETTER OF INTENT TO PROPOSE: To be eligible to submit a Proposal, a Bidder must submit a Letter of Intent to Propose in accordance with Section 7.5, Letter of Intent to Propose. SECTIONS REQUIRING A RESPONSE: See Section 7.6.3, Proposal Format Instructions for a list of the sections and attachments requiring a response for this RFP, in addition to the Letter of Intent to Propose. Response forms are attached on the last page of this document. ATTACHMENTS: A list of all attachments for this RFP is located on the last page of this document. HCA RFP No. 2020HCA28 Page 1 of 129 HCA RFP No. Page SECTION 1. OVERVIEW AND BACKGROUND 5 1.1 PURPOSE AND SCOPE OF REQUEST FOR PROPOSAL 5 1.2 BACKGROUND AND OBJECTIVES 5 1.3 HCA’S NEED TO PROCURE CURRENT POS 6 1.4 OPERATIONS AND MAINTENANCE MODEL 6 1.5 OVERVIEW OF CURRENT MEDICAID ENTERPRISE SYSTEM 7 1.6 BUSINESS PROCESS CHANGES 10 1.7 LEADERSHIP AND GOVERNANCE 11 1.8 PROJECT SCHEDULE 13 1.9 FUNDING 14 1.10 PERIOD OF PERFORMANCE 14 1.11 BIDDER MINIMUM QUALIFICATIONS 14 1.12 CONTRACTING WITH CURRENT OR FORMER STATE EMPLOYEES 14 1.13 AMERICANS WITH DISABILITIES ACT 14 SECTION 2. MANAGEMENT PROPOSAL 15 2.1 GENERAL INFORMATION OF BIDDER (MR) 15 2.2 EXECUTIVE SUMMARY (MS) 10 Page Limit 16 2.3 SOFTWARE DEVELOPMENT LIFECYCLE METHODOLOGY (MS) 17 2.4 PROJECT APPROACH / METHODOLOGY (MR & MS) 17 2.5 BIDDER QUALIFICATIONS (MR & MS) 20 2.6 APPROACH TO ORGANIZATION AND STAFFING (MR & MS) 23 2.7 PROJECT DELIVERABLES (MR & MS) 25 2.8 DESIGN, DEVELOPMENT AND IMPLEMENTATION REQUIREMENTS (MR & MS) 25 2.9 OPERATIONS AND MAINTENANCE (MR & MS) 33 SECTION 3. TECHNICAL PROPOSAL 36 3.1 OVERVIEW 36 SECTION 4. FUNCTIONAL PROPOSAL 51 4.1 ELIGIBILITY & PHARMACY BENEFIT PLANS 51 4.2 PROVIDER 55 4.3 DRUG REFERENCE FILE 58 4.4 EDITS/BUSINESS RULES 60 4.5 PRIOR AUTHORIZATION 66 4.6 CLAIMS AND ENCOUNTERS 76 4.7 COORDINATION OF BENEFITS / THIRD-PARTY LIABILITY 84 4.8 DRUG REBATE 87 4.9 OPERATIONAL REPORTING 95 4.10 USER AND SYSTEM DOCUMENTATION 99 4.11 OPERATIONS 102 SECTION 5. COST PROPOSAL 110 5.1 IDENTIFICATION OF COSTS 110 SECTION 6. REQUIRED MISCELLANEOUS FORMS 111 6.1 CERTIFICATIONS AND ASSURANCES (MR) 111 6.2 EXECUTIVE ORDER 18-03 (MS) 111 6.3 DIVERSE BUSINESS INCLUSION PLAN (MR) 111 6.4 WAGE THEFT PREVENTION (MR) 111 SECTION 7. GENERAL INFORMATION FOR BIDDERS 112 7.1 RFP COORDINATOR 112 7.2 ESTIMATED SCHEDULE OF PROCUREMENT ACTIVITIES 112 7.3 QUESTIONS AND ANSWERS 112 7.4 REVISIONS TO THE RFP 112 7.5 LETTER OF INTENT TO PROPOSE 113 7.6 SUBMISSION OF PROPOSALS 113 7.7 PROPRIETARY INFORMATION / PUBLIC DISCLOSURE 115 7.8 ACCEPTANCE PERIOD 115 7.9 MOST FAVORABLE TERMS 115 7.10 COSTS TO PROPOSE 116 7.11 RECEIPT OF INSUFFICIENT NUMBER OF PROPOSALS 116 7.12 NO OBLIGATION TO CONTRACT 116 7.13 REJECTION OF PROPOSALS 116 7.14 COMMITMENT OF FUNDS 116 7.15 ELECTRONIC PAYMENT 116 7.16 INSURANCE COVERAGE 116 SECTION 8. EVALUATION AND SELECTION 119 8.1 EVALUATION TEAMS 119 8.2 EVALUATION PROCESS 120 8.3 BIDDER SELECTION 124 8.4 COMPLIANT AND PROTEST PROCEDURES 125 8.5 CONTRACT PROCESS 127 SECTION 9. RFP ATTACHMENTS 128 HCA RFP No. 2020HCA28 Page 3 of 129 OVERVIEW AND BACKGROUND 1.1 PURPOSE AND SCOPE OF REQUEST FOR PROPOSAL The Washington State Health Care Authority (HCA) is initiating this Request for Proposals (RFP) to solicit Responses from qualified Bidders for the Design, Development and Implementation (DDI) and maintenance of a modular Pharmacy Point of Sale (POS) solution. The POS solution encompasses the automated functions necessary to receive and adjudicate all pharmacy Fee-for-Service (FFS) claims, Managed Care Organization encounters, and process drug rebate invoicing. The overall services and components to be acquired through this RFP encompass the following: · Fully functioning Pharmacy POS solution that will seamlessly integrate with HCA’s Medicaid Management Information System (MMIS) named ProviderOne; · Flexible and configurable rules for easy program updates by state staff; · Prior Authorization (PA) database that allow staff to perform prior authorization request processing and determination; · Drug Rebate database that allows staff to manage the invoicing and dispute resolution processes; · Self-service portal features for providers to submit prior authorizations online, inquire on status and to retrieve PA correspondence; · Robust PA workflow processes and procedures including dashboard and reporting capabilities to effectively manage workloads; · Self-service portal features for manufacturers to retrieve drug rebate invoices and claim level detail; · Operational reports that provide for the effective management of pharmacy and drug rebate programs; · DDI project management and staffing services, staff and provider training and certification support; and · Ongoing system operations and maintenance. HCA intends to award one contract to provide the services described in this RFP, which includes the DDI effort. On-going operations and maintenance services will begin at the conclusion of DDI after the Vendor meets the State’s system acceptance criteria. 1.2 BACKGROUND AND OBJECTIVES The Health Care Authority is a cabinet level agency led by a Governor-appointed executive, the HCA Director. HCA is Washington’s largest health care purchaser, responsible for administering programs that provide health coverage to more than 2.5 million residents through the Washington Apple Health (Medicaid), the Public Employees Benefits (PEBB) Program, the School Employee Benefits (SEBB) Program and the Compact of Free Association (COFA) Islander Health Care Program. More information about the HCA mission and organization can be found at https://www.hca.wa.gov. The high-level goals and objectives of the ProviderOne POS Replacement Project include the following: · Select a qualified vendor to design, develop, implement and/or analyze, configure, deploy a Commercial-Off-The-Shelf (COTS) or service hosted model (e.g., SaaS) that meets or exceeds the requirements listed in this RFP to support WA State’s Medicaid pharmacy and drug rebate programs. · Procure all major components including a pharmacy point of sale (POS) system, as well as prior authorization and drug rebate databases that offer a web-based solution with flexible architecture that is scalable and able to accommodate future State business needs and Federal requirements. · Automate labor-intensive manual processes by providing self-service features through online portals for providers and manufacturers. · Meet or exceed Federal enterprise architecture and security certification standards, and the Center for Medicare and Medicaid (CMS) conditions referenced in 42 C.F.R 433.112(b) that are required for enhanced Federal funding. · Ensure compliance with all applicable federal and state security and privacy requirements including, but not limited to, HIPAA, HITECH and OCIO. · Enable integration, interoperability and sharing of information with the ProviderOne system. · Increase Medicaid Information Technology Architecture (MITA) maturity and maintain an emphasis for the reuse of solutions that can be shared with other entities. 1.3 HCA’S NEED TO PROCURE CURRENT POS Several factors contribute to HCA’s need to replace the current POS. Primarily, the current system does not address the State’s business needs. Additional drivers include the need to align with CMS requirements related to the Modularity standard within the Seven Standards and Conditions and the CMS Final Rule. CMS requires states to follow a modular approach; loose coupling of components or services is central to the modern implementation of modularity. ProviderOne was implemented prior to CMS modularity requirements. While ProviderOne was architected using modular principles, the subsystems are tightly coupled and remain highly dependent upon each other. In planning for the future, the HCA is developing a modular strategy that enables flexibility to replace core ProviderOne components as regulations, technologies and business/user needs change. HCA’s ProviderOne strategy seeks to incrementally replace ProviderOne modules in order to maintain a modern MMIS into the future. The POS is the first module to be replaced. More information regarding CMS policy and regulations can be found here: https://www.medicaid.gov/federal-policy-guidance/index.html 1.3.1 CMS Certification All State MMIS and MMIS-related implementations must adhere to federal guidance for HCA to receive enhanced federal funding for the operation of the MMIS and other modular replacement projects. HCA will seek enhanced funding to the maximum extent possible and therefore the POS solution will undergo required certification as specified by CMS. The Apparent Successful Bidder (ASB) will need to fully support this process through all activities and artifacts requested by HCA and QA/IV&V vendor(s). HCA has been approved as a pilot state for Outcomes-Based Certification (OBC) by CMS. CMS has begun transitioning its system certification process to one that evaluates how well Medicaid technology systems support desired business outcomes while reducing burdens on states. Additional information regarding Outcomes-Based Certification can be found here: https://www.medicaid.gov/medicaid/data-systems/outcomes-based-certification/index.html 1.4 OPERATIONS AND MAINTENANCE MODEL The current MMIS (including the POS) is largely configured in-house. State staff manage key processes while CNSI, the current MMIS vendor, operates the MMIS using cloud computing and provides ongoing maintenance and modification to the MMIS. Teams of state staff perform the bulk of operational services including the following: · Provider enrollment and relations · Clients services and relations · Call Center staffing and management · Prior Authorization · Claims processing · Pharmacy services · Imaging and document automation services · Reference file and rules engine (MMIS) configuration and updates · Coordination of Benefits/Third Party Liability · Drug Rebate services · Financial Operations · Financial Recovery · Program Integrity and Audit functions When the new POS is in place, the HCA will continue with this Facilities Management operations and maintenance model, where state staff perform the majority of operations as identified above, and the ASB provides system maintenance and operations support. 1.5 OVERVIEW OF CURRENT MEDICAID ENTERPRISE SYSTEM Washington’s Medicaid enterprise system is a compilation of an integrated architecture of three systems named ProviderOne, Automated Client Eligibility System (ACES), and HealthPlanFinder (HPF), including additional subsystems to ProviderOne and ACES. ACES is administered by Department of Social and Health Services, and HPF is administered by Health Benefit Exchange. ProviderOne interfaces with ACES, which was enhanced in 2013 to include a modular Eligibility Service (ES) that determines eligibility for new Modified Adjusted Gross Income (MAGI) based Medicaid clients as well as Qualified Health Plan (QHP) clients. The ES and ProviderOne interface with Washington’s state-based Health Insurance Exchange system, HealthPlanFinder (HPF). This modular architecture aligns with MITA principles and provides the flexibility to support efficient operations of an enterprise MMIS. ProviderOne was implemented in May 2010 and was certified by CMS in July 2011. The system supports over 1.9 million Medicaid clients; approximately 83% are enrolled in managed care and 17% are fee-for-service. ProviderOne paid over $12 billion in SFY20 to over 230,000 providers that include medical and social service providers. This includes reimbursing over $1.6 billion to pharmacy providers. ProviderOne is a web-based Java system running on an Oracle RDBMS database platform. The system leverages an enterprise service bus to interact with Commercial Off-The-Shelf (COTS) products and web services to facilitate data sharing across some components. ProviderOne is built on modular principles with a rules engine at the core of business processing. Overall services and functions include the following: · Client, provider, reference, prior authorization, claims receipt and adjudication, managed care, coordination of benefits and financial components; · Integrated Pharmacy POS module including a drug rebate invoicing component; · Data warehouse including Fraud and Abuse Detection System (FADS); · Contact/call management system and integrated voice response components; and · Imaging and Document Management system. Washington’s MMIS also includes other COTS products and subsystems that integrate with ProviderOne. The current environment includes the following modules that were not procured under the ProviderOne contract with Client Network Services, Inc. (CNSI): Individual ProviderOne (IPOne), Enterprise Data Warehouse and Fraud and Abuse Detection System. IPOne provides payroll-like functions for individual social service providers. The figure below illustrates the components and subsystems that make up the Washington Medicaid Enterprise System. Figure 1. WA MES Enterprise 1.5.1 Overview of current Pharmacy Point of Sale (POS) subsystem The Pharmacy Point of Sale (POS) subsystem was procured in 2005 as a subsystem of ProviderOne. The POS was implemented in an early release in October 2008 and was certified with the MMIS in 2011. Optum is the POS vendor and sub-contractor under the HCA-CNSI MMIS contract. The POS supports real-time and batch adjudication of pharmacy claims and encounters for HCA-eligible clients. ProviderOne is the system of record for all POS information except for the following: · Detailed pharmacy benefit plan design specifications; · Drug file data including National Drug Code (NDC) definitions and historical pricing data; and · Pharmacy Prior Authorization (PA) records, both current and historical. Below is a description of common functions between the POS and ProviderOne. 1.5.1.1 Eligibility Information – Eligibility information is passed from ACES to ProviderOne via a nightly batch. Based upon ACES data and other client attributes, ProviderOne assigns benefit plan codes. ProviderOne then feeds all applicable eligibility information to the POS system. POS maintains a copy of that information as well as receive and process eligibility updates from ProviderOne every 15 minutes if changes occur. 1.5.1.2 Pharmacy and Prescriber Information – Detailed pharmacy and prescriber information is transmitted to POS from ProviderOne every night. During the batch load process, pharmacies that share the same reimbursement rate are placed in the same pharmacy network. Each variation of reimbursement rate will have a separate pharmacy network and is based on dispensing volume, unit dose specialization and pharmacy 340B status. These networks of pharmacies and prescribers are used later in the creation of plan definitions. 1.5.1.3 Prior Authorization – The POS supports centralized capture, administration, tracking and ultimate resolution of prior authorization requests regardless of their source of origin (e.g., fax, phone and paper). Faxes are received and processed through the imaging subsystem via optical character recognition and are loaded into the PA subsystem of the POS. Outgoing correspondence is initiated in the POS PA subsystem and then integrated within ProviderOne where letters are generated and sent to the state printing facilities for mailing. State staff also fax letters to applicable parties. 1.5.1.4 Drug Reference File Information – Weekly updates to POS drug detail and pricing information are provided by Medi-Span. Following the updates, changes are calculated to the HCA programs AMAC (Automated MAC Maximum Allowable Cost). A number of Medi-Span elements can be overridden to meet the operational needs of the HCA. First Data Bank information is also available in the system and used primarily to determine rebate status of products. 1.5.1.5 Transaction Processing: Pharmacy Claims – Fee-For-Service (FFS) Pharmacy claims are passed to the POS via switch vendor. Detailed drug coverage specifications, benefit plans, provider networks, compound processing, step therapy, days’ supply, prior authorization and drug utilization review rules are developed and maintained by HCA personnel and entered into the POS production environment directly without vendor intervention. All pharmacy claims are adjudicated using user-maintained edits. The POS provides functionality to perform corrections and/or adjustments to pharmacy claims already in the system. POS has the ability to reverse and/or reprocess claims for payment or for no payment. These claims and the adjudicated results are passed to ProviderOne on a daily basis for inclusion in the weekly payment cycle. 1.5.1.6 Transaction Processing: Managed Care Organization (MCO) Pharmacy Encounters – MCO pharmacy encounter claims are claims paid by the MCO and reported to HCA in the NCPDP format. These files are accepted or rejected by ProviderOne. Files in an accepted status are passed to the POS for encounter claim creation. A pharmacy encounter claim is created for each claim record in the NCPDP file. Encounter claim records are not paid, but instead are adjudicated and “shadow priced” within the POS. Each encounter claim gets a status of either accepted/captured or rejected based on rules applied during adjudication. Encounter claims in an accepted status will receive a shadow price which displays the applicable price the product would have been reimbursed under the FFS program and this information is also passed to ProviderOne on a daily basis. 1.5.1.7 Transaction Processing; Medical FFS Claims and MCO Encounter Claims with NDC’s. Some physician-provided drugs, primarily injectables, are submitted to the ProviderOne system via an 837 and are processed as medical FFS claims or MCO encounter claims. Once the claims have been fully adjudicated in the ProviderOne system and is in a “to be paid” status, ProviderOne creates an extract of the claim line with the NDC to pass to the POS system for adjudication and inclusion in the drug rebate process. A response file with the POS adjudication information is sent back to ProviderOne and associated with the claim line. The claim in the ProviderOne system then moves on to the payment process. These claims are not paid out of the POS system. 1.5.1.8 Drug Rebate – Claims and pricing information is passed from the POS system to the drug rebate component, which adjudicates invoice information for the calendar quarter by consolidating data from pharmacy and ProviderOne claims with covered outpatient drug information, producing separate invoices for federal and supplemental rebates. The drug rebate component then feeds all information to ProviderOne. The drug rebate component maintains this quarterly information in order to process prior period corrections. State staff manage the drug rebate invoicing and dispute processes, including corrections and adjustments. Collection of monies from manufacturers occurs outside any system, but the accounts receivable data is recorded within a drug rebate subsystem of ProviderOne. Below is a diagram that indicates the current data flow and interaction between the POS and ProviderOne. Figure 2. Current MMIS/POS Interactions 1.5.2 Transaction Volumes The Washington State Medicaid program pays in excess of $12 billion a year in provider payments for health care services to needy Washingtonians. Of the over $12 billion, it is estimated that $1.6 billion are paid Fee-for-Service (FFS) to pharmacy providers. Approximately 1.96 million clients are supported by the ProviderOne and the POS system, of which 83% of the client base receive services via the Medicaid Managed Care program, referred to as Apple Health, each month. The current POS processes approximately 300,000 fee-for-service and managed care encounter transactions per month, and payments are processed weekly by the MMIS and managed by the Office of the State Treasurer. The Health Care Authority’s Division of Clinical Quality and Care Transformation manages the Prior Authorization process and receives on average 3000-3500 pharmacy prior authorization requests (new and previously denied) a month. The vast majority of the requests arrive by toll-free line and fax; however, providers can also mail in prior authorization requests. 1.6 BUSINESS PROCESS CHANGES The HCA is very interested in working with the ASB to effectively manage any business process changes resulting from this procurement. The current POS has been in place for over 12 years and changes are anticipated and welcomed. The HCA expects to learn much from the ASB as the new system is introduced and business processes inherent to the new system are explained to key staff within the Pharmacy program, Prior Authorization, Drug Rebate, Coordination of Benefits (Third Party Liability), Systems and Operations, Call Center, Data Warehouse and Audit staff. It is expected that the ASB will assist in training HCA staff to assume responsibility for business operations. 1.7 LEADERSHIP AND GOVERNANCE 1.7.1 Medicaid Enterprise Steering and Governance Committees Washington’s Medicaid systems and operations are managed in a distributed enterprise across multiple state agencies/organizations. In 2018, the State of Washington Health and Human Services (HHS) Enterprise Coalition was established as a multi-organization collaborative that provides strategic direction, cross-organizational project support and federal funding guidance across Washington’s health and human services organizations. The agencies comprising the enterprise coalition include: · The Health Care Authority (HCA) · The Washington Health Benefit Exchange (HBE) · The Department of Social and Health Services (DSHS) · The Department of Children, Youth and Families (DCYF) · The Department of Health (DOH) The Washington State Office of the Chief Information Officer (OCIO) and the Washington State Office of Financial Management (OFM) are non-voting members of the HHS Coalition. The Medicaid Enterprise Governance structure focuses on three areas: (1) cross-agency/organization governance and management; (2) modernization and modular replacement of technology; and (3) improving the client/customer experience. Goals of the Enterprise Governance structure include: · Establish a collaborative decision-making and management structure and culture across the enterprise · Leverage and reuse technology investments (IT infrastructure, resources and assets) and increase operational efficiencies · Consider system enhancements that improve client/consumer experience for enterprise applications · Ensure coordination among projects when Design Development Implementation (DDI) efforts cross multiple agencies · Provide the HCA with the authority and the information needed to effectively perform their role as the State’s Single Medicaid Agency · Ensure enterprise compliance with federal Medicaid requirements/guidance The State has implemented a four-tiered governance structure: Level 1: Executive Sponsor Committee provides the mechanism by which Medicaid Enterprise investments are vetted, approved, prioritized and monitored through their lifecycle by providing strategic insight, cross-organizational project support and federal funding guidance across Washington’s health and human services enterprise. The HCA POS Replacement Project has been approved by the HHS ESC. Level 2: Enterprise Steering Committee ensures business alignment and provides operational direction for enterprise projects in support of the Executive Sponsor Committee and acts as the Steering Committee for Coalition-led projects. Level 3: Integrated Enterprise Project Group brings Project Management functions from the organizations/agencies together to ensure holistic project coordination with an Enterprise view of projects with a cross-agency Medicaid system impact. Level 4: Project Delivery Teams are agency-sponsored and responsible for operational and tactical oversight of a specific project. The POS Replacement Project is an HCA-sponsored project team. 1.7.2 The POS Replacement Project Leadership and Governance An HCA Executive Steering Committee (ESC) along with an Executive Sponsor (ES) will set the direction and support the planning and subsequent development of the POS Replacement Project. The ESC will make decisions for the agency, set priorities, provide oversight and governance, and ensure that properly skilled resources are available across the agency. The ESC is chartered and interacts closely with the HHS Coalition and four-tiered governance structure as indicated above. The following diagram illustrates the Project Organization and Governance, anticipated Project Team as well as other the HCA supporting teams that will contribute to the success of the project. Figure 3. The POS Replacement Project Organization and Governance 1.8 PROJECT SCHEDULE The following table shows the proposed timeline for the procurement tasks, as well as the Design, Development, and Implementation tasks for the Pharmacy POS system. The dates provided are estimates based on goals established by the Health Care Authority. As the procurement tasks progress, the start dates for some of the tasks may change based on the amount of time required to secure review and approval of the plans by CMS and state oversight bodies. Task Phase/Milestone/Deliverable Planned Start Date Planned End Date 1. POS Replacement Project 08/1/2019 08/30/2023 Planning and Requirements Analysis 1.1 Planning/Requirements Definition 08/1/2019 06/30/2020 1.1.1 Project Planning 08/1/2019 12/31/2019 1.1.2 Prepare Project Partnership Understanding (PPU) 08/1/2019 08/14/2019 1.1.3 Submit PPU to CMS 08/14/2019 08/14/2019 1.1.4 Prepare Planning Advance Planning Document (P-APD) to CMS 08/15/2019 08/31/2019 1.1.5 Submit P-APD to CMS 09/10/2019 09/10/2019 1.1.6 CMS approval of P-APD 09/10/2019 11/10/2019 1.1.7 Requirements Planning and Analysis 09/01/2019 06/30/2020 Acquisition 1.2 Procurement 08/15/2020 03/31/2021 1.2.1 Prepare Request for Proposal (RFP) 08/15/2020 12/31/2020 1.2.2 Submit RFP to CMS 12/21/2020 12/17/2020 1.2.3 CMS Approval 12/21/2020 01/19/2021 1.2.4 Release RFP 01/26/2021 01/26/2021 1.3 Select DDI Contractor 01/27/2021 05/28/2021 1.3.1 Bidders Prepare Responses 01/27/2021 04/12/2021 1.3.2 Prepare Implementation Advance Planning Document (I-APD) 02/18/2021 04/01/2021 1.3.3 HCA Receives Responses 04/12/2021 04/12/2021 1.3.4 HCA Evaluates Responses 04/13/2021 05/27/2021 1.3.5 HCA Announces Apparent Successful Bidder (ASB) 05/28/2021 05/28/2021 1.4 Negotiate DDI Contract 06/01/2021 07/15/2021 1.4.1 Conduct Negotiations 06/01/2021 07/15/2021 1.4.2 OCIO Review and Approval 06/15/2021 07/15/2021 1.4.3 CMS Review and Approval of the I-APD and Contract 07/16/2021 09/16/2021 1.4.4 Sign Contract 09/17/2021 09/17/2021 Design 1.5 Design 10/01/2021 02/28/2022 1.5.1 Complete Technical Design 10/01/2021 02/28/2022 1.6 Development 03/01/2022 08/01/2022 1.6.1 Complete Development 03/01/2022 08/01/2022 1.7 Testing 08/02/2022 10/30/2022 1.7.1 User Acceptance Testing (UAT) 10/01/2022 12/15/2022 1.8 Implementation 10/01/2022 12/15/2022 1.8.1 Readiness 11/01/2022 12/15/2022 1.8.2 Go-Live 12/16/2022 12/16/2022 Certification 1.9 Pharmacy Replacement Module Certification 12/17/2022 06/16/2023 1.9.1 Prepare for Certification 12/17/2022 06/16/2023 1.9.2 Conduct POS Certification 06/16/2023 07/16/2023 Maintenance 1.10 Begin Pharmacy POS Module Maintenance 12/17/2022 On-going 1.9 FUNDING HCA has budgeted an amount not to exceed $35.9 million ($35,900,000), inclusive of tax, for this project. Proposals in excess of $35.9 million will be considered non-responsive and will not be evaluated. This $35.9 million budget is comprised of $5.5 million for DDI and $30.4 million for O&M over the potential 8.5-year term of the awarded contract (5.5-year initial term with 3 optional extension years). See Section 5.1, Identification of Costs for more details. Any contract awarded as a result of this procurement is contingent upon the availability of funding. 1.10 PERIOD OF PERFORMANCE The period of performance of any contract resulting from this RFP is tentatively scheduled to begin on or about September 17, 2021 and will continue for 5.5 years from the effective date. Amendments extending the period of performance, if any, will be at the sole discretion of HCA. HCA reserves the right to extend the contract for 3 additional years, in any time increments. Due to the varying nature of DDI work, the initial term of the resulting contract will be extended, at HCA’s sole discretion, to include 4 full years of Operations and Maintenance without affecting HCA’s option to extend the contract for an additional 3 years. 1.11 BIDDER MINIMUM QUALIFICATIONS This section will not receive a score; however, Bidder and its proposed Project Manager are required to meet the following minimum qualifications (See Section 7.5): 1.11.1 The Bidder must have at least 5 years’ experience managing and staffing projects of comparable size and complexity to that required by HCA for the POS. 1.11.2 The Bidder’s proposed Project Manager must have at least 5 years’ experience leading projects of comparable size and complexity to that required by HCA for the POS. 1.12 CONTRACTING WITH CURRENT OR FORMER STATE EMPLOYEES Specific restrictions apply to contracting with current or former state employees pursuant to chapter 42.52 of the Revised Code of Washington. Bidders should familiarize themselves with the requirements prior to submitting a proposal that includes current or former state employees. 1.13 AMERICANS WITH DISABILITIES ACT HCA complies with the Americans with Disabilities Act (ADA). Bidders may contact the RFP Coordinator to receive this RFP in Braille or on tape. END OF SECTION 1 MANAGEMENT PROPOSAL Bidder’s Management proposal must respond to each of the subsections below. Sections labeled as Mandatory Requirements (“MR”) means that prompt will be evaluated on a pass/fail basis and no numerical score will be given. Sections labeled as Mandatory Scored (“MS”) means that prompt is both required and will receive a numerical score. DO NOT include any marketing material in your responses. 2 2.1 GENERAL INFORMATION OF BIDDER (MR) The prompts within this section consists of Mandatory Requirements, and will be evaluated on a pass/fail basis. Respond to the following: 2.1.1 Identify the name, address, principal place of business, telephone number, and e-mail address of legal entity or individual to be named as a party to the contract. 2.1.2 Identify the name, address and the telephone number(s) of the Principal Officers or Owners of Bidder’s company/corporation. 2.1.3 Identify the legal status of the Bidder (sole proprietorship, partnership, corporation, etc.) and the year the entity was organized to do business as the entity now substantially exists. 2.1.4 Federal Employer Tax Identification number or Social Security number and the Washington Uniform Business Identification (UBI) number issued by the state of Washington Department of Revenue. If the Bidder does not have a UBI number, the Bidder must state that it will become licensed in Washington within 30 calendar days of being selected as the Apparent Successful Bidder. 2.1.5 Identify and describe any merger or acquisition in which the Bidder is involved or may become involved during the period of this contract. State “Not applicable” if this section does not apply. 2.1.6 Identify the location of the facility from which the Bidder would operate. 2.1.7 Identify any state employees or former state employees employed or on the firm’s governing board as of the date of the proposal. Include their position and responsibilities within the Bidder’s organization. If following a review of this information, it is determined by HCA that a conflict of interest exists, the Bidder may be disqualified from further consideration for the award of a contract. State “Not applicable” if this section does not apply. 2.1.8 If the Bidder or any subcontractor contracted with the state of Washington during the past 24 months, indicate the name of the agency, the contract number, and project description and/or other information available to identify the contract. State “Not applicable” if this section does not apply. 2.1.9 If the Bidder’s staff or subcontractor’s staff was an employee of the state of Washington during the past 24 months, or is currently a Washington State employee, identify the individual by name, the agency previously or currently employed by, job title or position held, and separation date. State “Not applicable” if this section does not apply. 2.1.10 If the Bidder has had a contract terminated for default in the last five years, describe such incident. Termination for default is defined as notice to stop performance due to the Bidder’s non-performance or poor performance and the issue of performance was either (a) not litigated due to inaction on the part of the Bidder, or (b) litigated and such litigation determined that the Bidder was in default. State “Not applicable” if this section does not apply. 2.1.10.1 If applicable, submit full details of the terms for default including the other party’s name, address, and phone number. Present the Bidder’s position on the matter. HCA will evaluate the facts and may, at its sole discretion, reject the proposal on the grounds of the past experience. 2.1.11 If Bidder’s proposal includes subcontractors, provide similar and separate information for every proposed subcontractor in response to all Section 2.1 requirements. State “Not applicable” if this section does not apply. 2.1.12 Any information in the proposal that the Bidder desires to claim as proprietary and exempt from disclosure under the provisions of RCW 42.56 must be clearly designated. The page must be identified and the particular exemption from disclosure upon which the Bidder is making the claim must be listed. Each page claimed to be exempt from disclosure must be clearly identified by the word “Proprietary” printed on the lower right-hand corner of the page. In your response, Bidder must list which pages and sections that have been marked “Proprietary” and the particular exemption from disclosure upon which the Bidder is making the claim. State “Not applicable” if this section does not apply. 2.1.13 Agree that Bidder will collect, report, and pay all applicable State taxes if selected as the Apparent Successful Bidder. 2.2 EXECUTIVE SUMMARY (MS) 10 Page Limit The prompts within this section consists of Mandatory Scored Requirements, and will be scored. Limit the overall response to all requirements in this section to a maximum of 10 pages. Respond to the following: 2.2.1 Identify and describe the product the Bidder proposes as the basis of its Pharmacy POS solution. 2.2.2 Briefly summarize the proposed project management (PM) approach and overall services in order to give the evaluators a strong general overview of the Management, Technical, and Functional proposals of the Bidder. 2.2.3 Identify any unique or innovative features. 2.2.4 Provide a brief overview of the risks associated with this project, critical success factors, and actions HCA should consider during the analysis and implementation stages. 2.2.5 Explain how the proposed solution represents to HCA the best option for its Pharmacy POS, and why HCA should select the proposed solution. 2.2.6 Briefly describe Bidder’s, and any subcontractor’s, experience in implementation and/or operation of the proposed Pharmacy POS solution in other state’s Medicaid programs. Include timeframe, cost of implementation, number of users or other solution sizing information, and whether the system was certified or pre-certified by CMS. 2.2.7 Briefly describe Bidder’s, and any subcontractor’s, experience in implementation and/or operation of the proposed Pharmacy POS solution for non-state, comparably sized organizations. Include timeframe, cost of implementation, and number of users or other solution sizing information. 2.2.8 Agree that the Bidder will comply with the procurement process described in the RFP. 2.2.9 Agree that the Bidder understands the scope and objectives of the project and agrees to meet the requirements specified in the RFP. 2.2.10 Agree that the Bidder will perform the services described in the RFP. 2.2.11 Agree that the Bidder will work cooperatively with HCA and HCA’s designees. 2.2.12 Agree that the Bidder’s proposed solution will meet all federal MMIS Certification requirements relevant for a Pharmacy POS solution. 2.2.13 Agree that the Bidder’s proposed solution is fully HIPAA compliant. 2.3 SOFTWARE DEVELOPMENT LIFECYCLE METHODOLOGY (MS) The prompts within this section consists of Mandatory Scored Requirements, and will be scored. Respond to the following: 2.3.1 Describe the proposed system development lifecycle (SDLC) methodology you will use to set-up, configure, and if needed, customize the proposed Pharmacy POS solution to meet all HCA requirements, including the integration with the current MMIS. 2.3.2 Describe the proposed SDLC to be used during the Operations and Maintenance phase. 2.3.3 Explain the benefits of the recommended methodologies. 2.4 PROJECT APPROACH / METHODOLOGY (MR & MS) This project will be assessed by internal and external oversight for its compliance with project management practice standards defined in the Project Management Institute’s Project Management Book of Knowledge. For example, independent non-HCA Quality Assurance monitoring will be conducted throughout the term of the project. The ASB will be expected to apply industry best-practices to manage this project. In addition to bi-weekly project status reports, the ASB may be required to generate status materials and attend additional meetings with oversight/stakeholders upon the request of the HCA project manager. The prompts within this section consists of both MR and MS Requirements. Only the “Agree” prompts are MR. Respond to the following: 2.4.1 Describe the Bidder’s proposed project management approach and methodology for the project. This description should convey Bidder’s understanding of the proposed project and should include, but not be limited to, planning, organizing, and managing the staff and activities throughout the life of the project. 2.4.2 Explain with specificity the Bidder’s approach to promoting teamwork, facilitating open and timely communication, and ways the Bidder’s staff will support a collaborative effort among the Bidder, any subcontractors, HCA, and HCA designees. 2.4.3 Describe how the Bidder will coordinate efforts with the HCA project team to address multiple stakeholder needs. 2.4.4 Agree that the Bidder will provide on-going assistance to HCA and its contracted MMIS vendor (and any other contracted entity) throughout the contract phase and will work directly with HCA when coordination and collaboration efforts are needed. Bidder will not directly contact any contracted entity of HCA without HCA’s prior approval. 2.4.5 Agree that the Bidder will either conduct internal quality assurance or will retain an independent firm to conduct quality assurance. 2.4.6 Agree that the Bidder will provide to HCA any quality assurance reports that are produced during the project. 2.4.7 Agree that the Bidder will provide overall management of the Bidder's proposed solution. 2.4.8 Project Risk Assessment and Mitigation Requirements Respond to the following: 2.4.8.1 Describe an overall approach to risk management and mitigation for the project. 2.4.8.2 Describe the Bidder’s process for documenting, monitoring and reporting risks and risk status to HCA. Include information related to the proposed tools you will use to manage this process. 2.4.8.3 Describe potential risks currently foreseeable to the Bidder for this engagement, rank in order of highest risk, and identify recommended steps to mitigate those risks. 2.4.8.4 Explain the benefits of the Bidder’s proposed risk management process to HCA. 2.4.8.5 Agree that the Bidder’s proposed risk management tools will be accessible by Bidder staff, HCA staff, and HCA designees. 2.4.9 Project Issue Resolution Requirements Respond to the following: 2.4.9.1 Describe the Bidder’s approach and process for issue identification, communication, resolution, escalation, tracking, approval by HCA, and reporting. 2.4.9.2 Identify and describe the Bidder’s proposed tool to track, manage, and report on issues/action items and facilitate its issue resolution process that includes an automated tracking and management system. 2.4.9.3 Explain the benefits of the Bidder’s issue resolution approach. 2.4.9.4 Agree that the Bidder’s issue resolution tool will be accessible by Bidder staff, HCA staff, and HCA designees. 2.4.10 Project Change Control Requirements Controlling scope and providing for system changes caused by legislative mandates or other causes is extremely important to HCA in maintaining project accountability. Change control will be ongoing throughout the entire duration of the contract. During DDI, HCA may exercise its option for change requests for system enhancements consistent with the change control process outlined below. During Operations and Maintenance, HCA may exercise its option for change requests for system enhancements as outlined below. These system enhancements are more complex in nature, may require customized coding and cannot be accomplished by state staff. See SECTION 5, Cost Proposal for more details. Respond to the following: 2.4.10.1 Describe both graphically (e.g., via a flowchart) and in text a recommended approach to change control, including steps, roles and responsibilities, and decision points. 2.4.10.2 Describe the Bidder’s cost estimating steps and process for providing a written estimate to HCA of the cost and duration for every change. 2.4.10.3 Identify and describe the Bidder’s proposed tool(s) to track, manage, and report on change control items and to facilitate the Bidder’s change control approach, including an automated tool that tracks history in a database. 2.4.10.4 Describe steps for updating the work plan for changes identified during DDI and approved by HCA. 2.4.10.5 Explain the benefits of the recommended change control approach for HCA. 2.4.10.6 Agree that written approval by HCA is mandatory for every change before the Bidder begins development of that change. 2.4.10.7 Agree that written approval by HCA is mandatory for every change before the Bidder begins implementation of that change. 2.4.10.8 Agree in the proposed change control process that the Bidder will provide HCA with justification of every change suggested by the Bidder. 2.4.10.9 Agree that any changes must be provided at a reasonable price to be negotiated between the Bidder and HCA, and that if the Bidder and HCA cannot come to an agreement on price and schedule to implement such mandated changes, the Bidder agrees to perform the work at the price proposed by the State’s project manager and to pursue the dispute resolution process to resolve open issues. 2.4.10.10 Agree that the Bidder’s proposed change control tools will be accessible by the Bidder, HCA, and HCA designees. 2.4.10.11 Agree that the Bidder must include the estimate and actual cost and duration for every change request as well as cumulative cost and schedule impacts for all changes for all periods HCA specifies. 2.4.11 Project Communication and Coordination Requirements Respond to the following: 2.4.11.1 Describe the Bidder’s approach to communication and coordination and the Bidder’s proposed tools to facilitate its approach. 2.4.11.2 Describe the proposed lines of authority, coordination, and communication to include communication between the parties. At a minimum it should describe lines of authority/communications between HCA and Bidder executives, directors, and officers and lines of authority/communications between HCA and Bidder project management. 2.4.11.3 Provide an example status report(s) from past projects of Bidder and a recommended sample report format. 2.4.11.4 Agree that every other week the Bidder will provide such reports in a format and level of detail subject to HCA acceptance. 2.4.11.5 Agree that the status reports will describe the following: (1) the previous two weeks’ activities, including problems encountered and their disposition, results of tests (if applicable), what was accomplished as expected and on-time, what was not accomplished as expected and on time, recommendations on meeting missed deadlines; (2) plans for the coming two weeks; (3) tasks behind schedule, e.g., tasks at risk of not being completed by their deadline, and what the Bidder is doing to mitigate the risks; and (4) any action items or problems that have arisen that need to be addressed immediately. 2.4.11.6 Agree that HCA reserves the right to formally state disagreements with status reports and may, at the discretion of HCA, require revised status reports. 2.4.11.7 Agree that the Bidder’s Project Manager will attend weekly status meetings, with the understanding that HCA may agree to the Project Manager's remote attendance to the extent that it will not jeopardize project progress. 2.4.11.8 Agree that the Bidder will actively participate with project staff to ensure effective communication and coordination within the project, including Bidder staff, subcontractor staff, HCA, and other stakeholders within and external to the agency, including providers. 2.4.11.9 Agree that the Bidder will cooperate with internal and external oversight to this project whenever necessary in the State’s opinion. 2.4.11.10 Agree that the Bidder will attend additional, albeit infrequent, oversight/stakeholder management meetings at HCA’s request. 2.4.11.11 Agree that the Bidder’s proposed communication and coordination process is subject to HCA approval. 2.4.12 Project Work Plan Keeping a structured work plan that facilitates tracking of the stages, activities, and implementation phases required to implement the Pharmacy POS solution is critical to project success. The ability to identify, discuss and report on the critical path of the project is required. HCA expects the Bidder to track all tasks assigned to Bidder staff, and any subcontractors. Respond to the following: 2.4.12.1 Include a preliminary proposed project work plan in electronic form using Microsoft Project that aligns with HCA’s Design, Development, and Implementation (DDI) stages in Section 2.8. This should be separately attached to your proposal. 2.4.12.2 Include in the schedule the tasks, milestones, deliverables, task dependencies and resources, including HCA resources, for delivering the proposed solution. 2.4.12.3 Identify activity start and completion dates and the planned dates for initial submission, HCA’s initial review, HCA’s return to Bidder for revision/correction, and HCA acceptance of each deliverable. 2.4.12.4 Identify all proposed resources by name. 2.4.12.5 Show tasks requiring HCA resources, summarize the proposed use of HCA resources, and state any assumptions regarding anticipated involvement of these resources. 2.4.12.6 Show task and individual time assignments and schedules in a Gantt type chart. 2.4.12.7 Provide a critical path diagram showing all significant tasks/activities and inter-dependencies. 2.4.12.8 Agree that throughout the Contract period, all deliverables will be developed in the form and format agreed to by HCA and the Bidder using a Deliverable Expectations Document (DED) delivered within timeframes outlined in the Project Work Plan. 2.4.12.9 Agree that the Project Work Plan must have tasks delineating the deliverable process and all approval and review periods. 2.4.12.10 Agree that the Bidder must allow 10 business days for State approval of each submission of each Deliverable. If re-submission of a deliverable is needed, agree that dates of final acceptance are negotiable and may not take an additional 10 days. 2.4.12.11 Agree that the Bidder retains final responsibility for the quality of the deliverables. 2.4.12.12 Agree that the Bidder will finalize and baseline the Work Plan, developed jointly with and accepted by HCA no later than 45 calendar days after contract signing. 2.4.12.13 Agree that the finalized Work Plan becomes part of the Bidder’s response and that it will be incorporated in the contract by reference upon its acceptance by HCA. 2.4.12.14 Agree that the Bidder will meet with HCA every two weeks to walk-through proposed updates and to obtain HCA’s consent to updates proposed by the Bidder. 2.4.12.15 Agree that the Bidder will maintain its detailed work plan and publish the plan where the Bidder, HCA, and HCA designees have access. 2.5 BIDDER QUALIFICATIONS (MR & MS) The prompts within this section consist of both MR and MS Requirements. Only the “Agree” prompts are MR. 2.5.1 Bidder’s Prior Experience Requirements Respond to the following: HCA RFP No. 2020HCA28 Page 17 of 129 2.5.1.1 Complete the following table for each POS solution that the Bidder has implemented or is implementing in other states that support that state’s Medicaid program: State Start & End Month/Year Certification Month/Year Platform Primary Language Database Annual Claim Volume Annual Claim Dollars # of Users Contract Amount Client Contact (name/role/phone/email) 2.5.1.2 Complete the following table for any other relevant, large-scale components the Bidder has implemented or is implementing that are not identified above: Client Start & End Month/Year Platform Primary Language Database Annual trans. Volume Annual trans. Dollars # of Users Contract Amount Client Contact (name/role/phone/email) HCA RFP No. 2020HCA28 Page 22 of 129 2.5.1.3 Explain why this is the system the Bidder is proposing and the degree of fit with Washington’s requirements, including the percentage of Washington’s requirements that the system meets without modification and the basis for that assessment. 2.5.1.4 Describe the Bidder's role in each engagement described above and state Bidder’s level of responsibility (for example, primary, subcontractor) for all phases of the project including requirements analysis, process design, construction, testing, and final implementation. Also, describe any pilot implementation phases. 2.5.1.5 Clearly describe the scope and scale of those projects, including the Bidder's performance in terms of schedule and budget. Also, explain positive and negative variances from the schedule and budget. 2.5.1.6 Describe the Bidder’s experience in developing and operating systems on the hardware (if applicable) and software platforms proposed for Washington. 2.5.1.7 Identify and describe any units in Bidder’s organization that have reached Capability Maturity Model (CMM) Level 3 or higher certification, and describe those units’ involvement in this project. 2.5.1.8 Describe how Bidder will employ CMM processes and practices in this project. 2.5.1.9 Agree that HCA reserves the right to contact all above client contacts and any other contacts provided by current or former clients, and that HCA reserves the right to disqualify Bidder based upon said contact. 2.5.2 Bidder Customer References Requirements This section is mandatory and will receive a score. These references are for the Bidder organization (Section 2.6.2.2 relates to Key Staff references). HCA reserves the right to conduct checks of Bidder references, by telephone or other means, and evaluate the Bidder based on these references. HCA considers references to be extremely important, and HCA reserves the right to disqualify Bidder based upon poor reviews/references. It is the Bidder's responsibility to ensure that every reference contact is available during the evaluation period. (See Section 7.2, Estimated Schedule of Procurement Activities, for the planned RFP evaluation period). HCA will e-mail Bidder’s references a questionnaire to complete and return to HCA. HCA will evaluate and score this section based on the references’ responses to the questionnaire. HCA may also call references. Respond to the following: 2.5.2.1 Refer to Attachment 2, Bidder References Form and complete a copy of that form for the Bidder organization. Bidder must include 3 customer references for the Bidder organization. At least 2 of these references must be from POS comparable projects. For every reference, the Bidder’s proposal must provide the company name, contact name, contact job title, address, telephone number and email for that reference. Combine completed Bidder Reference Forms into one document and include as a separate attachment to your proposal. 2.5.2.2 Provide similar and separate references for every proposed subcontractor. 2.5.2.3 Agree that all references must be independent of the Bidder’s and subcontractor’s company/corporation (e.g., non-Bidder owned, in whole or in part, or managed, in whole or in part). 2.5.2.4 Agree that HCA reserves the right to contact all above customer references, and that this contact will be considered by HCA in scoring the Bidder. 2.5.2.5 Agree that HCA reserves the right to contact any other entity or person it wants to contact with regard to the Bidder and subcontractor, including parties in addition to those recommended by the Bidder. This contact may be used by HCA in scoring the Bidder. 2.5.2.6 Agree that the Bidder and subcontractor has or will timely notify each customer reference that they may be contacted by HCA and has assured that each reference will be available during the evaluation period. (See Section 7.2, Estimated Schedule of Procurement Activities for the approximate RFP evaluation period). 2.6 APPROACH TO ORGANIZATION AND STAFFING (MR & MS) The prompts within this section consists of both MR and MS Requirements. Only the “Agree” prompts are MR. The organization of Bidder staff and the appropriate assignment of tasks are extremely important to HCA to ensure the overall success of this project. HCA expects that Bidders will propose their best-qualified staff for this project. Should proposed staff not be available when work begins, Bidder must provide evidence in the form of résumés and descriptions of relevant experience for any staff proposed as alternates to the proposed team members. 2.6.1 Overall Project Organization Approach Respond to the following: 2.6.1.1 Include a description of the overall approach to project organization and staffing, including subcontractors if applicable, that addresses the entire scope of the project. 2.6.1.2 Include a project organization chart identifying by name and position the Bidder’s staff (e.g., down to at least the lead level), including subcontractors, responsible for carrying out the entire scope of the project. 2.6.1.3 Identify by name and position in the project organization chart the Key Staff person(s) that will perform the following during the DDI phase (individuals may fill more than one role): a. Account Director b. Project Manager c. Pharmacy Business Lead d. Drug Rebate Business Lead e. Solutions/Technical Manager f. Test Manager g. Implementation Manager h. Certification Manager 2.6.2 Project Management and Key Staff Qualifications Requirements Scores for this section will be based on the proposed Key Staff’s qualifications and experience. Experience from projects where the work performed was different than this project may not score as well as experience where the work performed was similar to this project. At its discretion, HCA will contact the project manager and key staff references. Respond to the following: 2.6.2.1 Refer to Attachment 3, Résumé Form and complete a copy of that form for each of the proposed Key Staff. Combine completed Résumé Forms into one document and include as a separate attachment to your proposal. 2.6.2.2 Refer to Attachment 4, Key Staff References Form and complete a copy of that form for each of the proposed Key Staff. Bidder must include 3 customer references for each Key Staff. Combine completed Key Staff Reference Forms into one document and include as a separate attachment to your proposal. HCA will e-mail Key Staff references a questionnaire to complete and return to HCA. HCA will evaluate and score this section based on the references’ responses to the questionnaire. HCA may also call references. 2.6.3 Project Staffing Requirements For the purpose of this section, “Project Staff” includes Bidder personnel and all subcontractor staff. Respond to the following: 2.6.3.1 State the minimum number of staff that will be assigned to this project throughout the life of the project. If this number will change throughout the life of the project, identify when those changes will take place and the minimum number of staff that will be assigned to this project during those changes. 2.6.3.2 Identify where all staff assigned to this project, including developers, will be geographically located (city, state, country) throughout the lifecycle of the project. 2.6.3.3 Explain how and to what extent they will be accessible to the HCA project team. 2.6.3.4 For staff geographically located outside of Olympia, Washington, identify what Bidder staff will come on-site to work with stakeholders (e.g., for requirements validation, testing, and business process change) and describe in detail the tasks or phases for which they will come on-site, when, and for how long. HCA recognizes the seriousness of COVID-19, and this local/on-site requirement will be adjusted to conform to state and HCA COVID-19 requirements and guidelines. 2.6.3.5 Describe the process and timeline for bringing proposed staff onto the project. 2.6.3.6 Agree that the Project Manager will be in Olympia full-time throughout the project or as otherwise agreed to in contract negotiations. HCA recognizes the seriousness of COVID-19, and this local/on-site requirement will be adjusted to conform to state and HCA COVID-19 requirements and guidelines. 2.6.3.7 Agree that the Bidder must provide all office space and equipment for its staff. 2.6.4 Continuity of Project Personnel Requirements In order to ensure the success of this project, it is important that there is a continuity of Key Staff assigned to the project. Respond to the following: 2.6.4.1 Describe policies, plans, and intentions with regard to maintaining continuity of personnel assignments throughout the performance of any agreement resulting from this RFP. 2.6.4.2 Address whether availability of any of the proposed personnel could be impacted from existing or potential contracts to which such staff are assigned or proposed. 2.6.4.3 Describe what priority HCA would have in cases of conflict between existing or potential contracts. 2.6.4.4 Discuss the Bidder's plans to avoid and minimize the impact of personnel changes. 2.6.4.5 Identify planned backup personnel assignments. 2.6.4.6 Agree that Bidder’s proposed project personnel may not be reassigned, replaced, or added during the project without the prior written consent of the HCA Project Manager. Should a key staff position be vacated, Bidder must give HCA résumés of, and an opportunity to interview and approve, potential replacements for that employee. 2.6.4.7 Agree that the HCA Project Manager reserves the right to require a change in Bidder's project personnel at the HCA Project Manager’s sole discretion and that HCA must be given an opportunity to interview and approve potential replacements for that employee. However, HCA will not unreasonably exercise this option and will take reasonable steps to work with the Bidder toward a solution. 2.6.4.8 Agree to HCA’s use of the Key Staff personnel identified in the proposal and agree to HCA's right to approve proposed personnel changes to Key Staff during the term of the contract. 2.6.4.9 Agree that responses to Section 2.6.3 requirements apply to proposed Subcontractor key staff as well as Bidder’s proposed staff. 2.7 PROJECT DELIVERABLES (MR & MS) The prompts within this section consists of both MR and MS Requirements. Only the “Agree” prompts are MR. The Bidder must identify its approach to developing and submitting the project deliverables identified in this RFP. The approach to project deliverables must identify the proposed steps in the deliverable development process, from development of Deliverable Expectation Documents, templates, and acceptance criteria through review, finalization, and acceptance. Bidders are encouraged to deliver partial drafts (e.g., section by section) especially when deliverables are lengthy to manage mutual expectations and to ensure the satisfactory completion of deliverables. Bidders also must consider the impact on reviewers when multiple deliverables are under review simultaneously by the same stakeholder group and adjust review and correction periods accordingly. Respond to the following: 2.7.1 Include a full list of all deliverable titles and expected delivery dates. 2.7.2 Describe the Bidder’s general approach to deliverables development, acceptance criteria, draft submission, revisions, and final acceptance. 2.7.3 Agree that Bidder will submit for State approval acceptance criteria before work begins on the deliverable. 2.7.4 Agree that Bidder will produce deliverable outlines or templates for HCA acceptance before work begins on the deliverable. 2.7.5 Agree that the Bidder will incorporate comments and distribute revised draft deliverables to HCA project staff for review and comment. 2.7.6 Agree that the Bidder will include a change log specifying the section, page number and brief description of any changes with the submission of a revised deliverable. 2.7.7 Agree that upon HCA request, the Bidder will conduct formal walk-throughs of draft deliverables with identified HCA stakeholders. 2.8 DESIGN, DEVELOPMENT AND IMPLEMENTATION REQUIREMENTS (MR & MS) The prompts within this section consists of both MR and MS Requirements. Only the “Agree” prompts are MR. HCA has defined the following high-level stages for this project: 1. Planning and Start-Up 2. Requirements Verification and Design 3. Set-up, Configuration, and Customization (including integrations) 4. Data Conversion 5. System and Integration Testing 6. Operational Readiness 7. User Acceptance Testing 8. Deployment/Implementation 9. Certification Within this section, Bidders are asked to respond to the requirements of each major stage. Responsibilities include, but are not limited to, the following: State Responsibilities: · Review and acceptance of the proposed Deliverable Expectation Document (DED) of all Deliverables prior to development; · Review ASB deliverables, determine whether the deliverable complies with applicable specifications, and provide written comments to the ASB within timeframes mutually agreed to; · Participate in bi-weekly status meetings with the ASB to review progress against the work plan; · Review bi-weekly written status reports and bi-weekly work plan/task schedule updates; · Monitor ASB progress to task milestones; and · Work with the ASB to resolve issues. Pharmacy POS ASB Responsibilities: · Prepare a DED and obtain acceptance from HCA for the contents and format for each Deliverable before beginning work on the Deliverable; · Obtain written acceptance from HCA on the final Deliverables; · Revise Deliverables, if required, using HCA review findings to meet content and format requirements and comply with applicable specifications; · Report progress and status through bi-weekly status reports; · Conduct bi-weekly work plan reviews; · Attend bi-weekly status meetings with the HCA Project Manager and project team members; · Deliver written status reports and updated work plans/schedules 1 business day, at least 24 hours, before the status meeting; and · Identify scope of work issues and seek HCA acceptance before commencing changes to work described in the RFP. 2.8.1 Approach to Planning and Startup Respond to the following: 2.8.1.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Revised Project Work Plan See section 2.4.12 Project Management Plan A formal, approved document used to guide both Project execution and control of the Project consistent with the guidance of the Project Management Body of Knowledge that includes processes Bidder proposes in response to section 2.4 Certification Plan A formal planning document that details the approach for achieving federal Certification. The plan describes the processes for assisting HCA in the Operational Readiness Review and Certification Review stages of Outcome Based Certification. Risk Register See section 2.4.8 Bi-weekly Status Reports See section 2.4.11 2.8.1.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.1.3 Demonstrate the Bidder’s understanding of the certification requirements and the process for obtaining CMS certification by describing in detail the steps that Bidder will take to achieve certification, including how the Bidder will support HCA in the CMS certification process. 2.8.1.4 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the responsibilities for HCA, MMIS vendor and Bidder staff during this stage. 2.8.1.5 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder’s to ensure overall project success. 2.8.2 Approach to Requirements Verification and Design Respond to the following: 2.8.2.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Requirements Traceability Matrix (RTM) – Interim An interim document that links requirements throughout the requirements validation process showing how HCA requirements, user stories, and use cases will be certified as functional and complete during solution configuration. Solution Requirements Documentation Documentation including Business Requirements document (BRD), System Requirements Specifications (SRS) or equivalent, features, epics and user stories Solution Integration Plan A document describing plans to achieve modularity and how the Pharmacy solution will interact with ProviderOne to provide a fully functional system that operates as one module of the interconnected MMIS. Solution Design Documentation Final documentation of the functional and technical designs traceable back to the Requirements Traceability Matrix (RTM) and process flows, including at a minimum: · Configuration elements such as business rules · Reporting (dashboards, reports, cadence) · Interface specification documents · System architecture, including security and database designs 2.8.2.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.2.3 Describe Bidder’s proposed Solutions Requirements Documentation to include the items above and other items the Bidder feels are necessary. 2.8.2.4 Describe Bidder’s proposed content of a Solution Integration Plan to include the items above and other items the Bidder feels are necessary. 2.8.2.5 Describe Bidder’s proposed Solution Design Documentation to include the items above and other items the Bidder feels are necessary. 2.8.2.6 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the responsibilities for HCA, MMIS vendor and Bidder staff during this stage. 2.8.2.7 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.3 Approach to Set-up, Configuration and Customization Respond to the following: 2.8.3.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Solution Configuration Documentation Documentation provided that conveys how the solution is configured to meet HCA start-up business needs. DDI Environment and Configuration Management Plan Documentation of the development, test, and training environments to be used throughout the Contract period, including definition of responsibilities for set-up and configuration tasks for each. Must describe how the Bidder will identify, control, and manage code releases throughout DDI. 2.8.3.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.3.3 Describe Bidder’s proposed content of a DDI Environment and Configuration Management Plan to include the items above and other items the Bidder feels are necessary. 2.8.3.4 Describe approach to developing the Deliverables required for this DDI stage. List the responsibilities of HCA, MMIS vendor and Bidder staff during this stage. 2.8.3.5 Describe approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.4 Approach to Data Conversion Respond to the following: 2.8.4.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Data Conversion Plan A description of the strategy, preparation, and specifications for converting data, including but not limited to claims and prior authorizations, from the source system(s) to the target system(s) or within an existing system. Data Conversion Test Results Documentation of the Data Conversion Test Results which detail issues encountered and the impact upon other table or file conversions: · Methods used to resolve issues or an action plan for resolving outstanding issues · Pre-conversion and post-conversion versions of each table or file converted and each interface file · Auto-generated reports as required by HCA to spot-check and validate pre-conversion and post-conversion results at a detail and summary record levels · A summary and metrics for the status of the conversions, including the effect of any findings on the implementation schedule 2.8.4.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.4.3 Describe Bidder’s approach to defining detailed conversion requirements. 2.8.4.4 Describe Bidder’s final conversion verification process. 2.8.4.5 Describe Bidder’s approach for making converted files available for review online, where appropriate. 2.8.4.6 Describe approach to developing the Deliverables required for this DDI stage. List the responsibilities of HCA staff, MMIS vendor and Bidder staff during this stage. 2.8.4.7 Describe approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.4.8 Agree that Bidder will convert 4 years of data from the current Pharmacy POS including any lifetime or special limit information over the 4 years. 2.8.4.9 Agree that Bidder will work directly with HCA to coordinate receipt of conversion files from current POS vendor. 2.8.5 Approach to System and Integration Testing Respond to the following: 2.8.5.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Master Test Plan A technical document that details a systematic approach to testing the new Pharmacy solution to ensure it will successfully perform to HCA’s requirements as a module of the overall MMIS. · Testing must include end-to-end testing of all interfaces. · Demonstrations of working software (e.g., module demo, interaction with other modules/systems) must be provided as specified by HCA System and Integration Test Results and Demonstration Documentation of the System and Integration test scenarios and test cases, testing results, issues and defects identified during testing, as well as the scenarios and degree of system functionality demonstrated for HCA. Requirements Traceability Matrix (RTM) – Final A final document that links requirements throughout the requirements validation process showing how HCA requirements will be certified as functional and complete during solution configuration. Training Plan A document for defining the strategies, tasks, and methods that will be used to meet the training requirements. 2.8.5.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.5.3 Describe any automated testing capabilities that you may utilize and include those to test specific business scenarios. 2.8.5.4 Agree that the Bidder will adopt, implement and document rigorous and professionally sound unit, system, integration, and regression test procedures. 2.8.5.5 Agree that Bidder will agree to demonstrate functionality identified by HCA that will ensure system is ready to enter UAT. 2.8.5.6 Agree that the Bidder will ensure that preproduction testing of the solution validates capability of required test objectives and will produce required data to support objectives and identified key performance indicator measures. 2.8.5.7 Describe Bidder’s proposed tool and procedures for tracking, managing, reporting and correcting system bugs or discrepancies discovered during testing. 2.8.5.8 Describe Bidder’s approach for updating documentation based on test results. 2.8.5.9 Describe Bidder’s proposed training model for the project which must include Knowledge Transfer sufficient to ensure operational readiness of the HCA team that will support the solution in Operations 2.8.5.10 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the proposed responsibilities for HCA, MMIS vendor and Bidder staff during this stage. 2.8.5.11 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.6 Approach to Operational Readiness Respond to the following: 2.8.6.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Operational Readiness Plan A document detailing the approach to validating all the operations processes, system environments, software, and connectivity aspects of the solution to ensure it will be fully operable upon implementation. Describes how the Bidder will achieve certification of Operational Readiness. Operations Guide A document that describes all required systems operational activities and provides guidance on data management, incident management, root cause analysis, corrective action plans, performance management, system maintenance, change management, tools, and approaches. Training Materials Documentation used to perform provider and user training (user guides and tutorials) on the solution. 2.8.6.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.6.3 Describe Bidder’s approach to demonstrating operational readiness and proposed content of an Operational Readiness Plan to include the items above and other items the Bidder feels are necessary. 2.8.6.4 Describe contents of the Operations Guide to include the items above and other items the Bidder feels are necessary. 2.8.6.5 Describe Bidder’s procedures for maintaining the Operations Guide throughout operations, including distribution of amendments. 2.8.6.6 Describe the roll-out of training materials to ensure staff and providers/manufacturers are ready to use the system. 2.8.6.7 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the responsibilities of HCA, MMIS vendor and Bidder staff during this stage. 2.8.6.8 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.7 Approach to User Acceptance Testing Respond to the following: 2.8.7.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description User Acceptance Testing (UAT) Test Results Test results should include the following: · Summary of testing results · Pass/fail rate · Defect IDs and severity level of failed test cases Certification Artifacts (CMS’ Operational Readiness Review stage) A series of system demonstrations necessary including a collection of information, including but not limited to, data, documents, automated test results, 508 compliance test reports, screenshots, other reports and/or artifacts produced in coordination with the HCA UAT cycle to support the CMS “Operational Readiness Review” certification process. 2.8.7.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.7.3 Agree that Bidder will fully and promptly cooperate with HCA in the UAT process to include providing any Certification Artifacts for CMS review. 2.8.7.4 Agree that Bidder will be solely responsible for making changes; providing refinements and/or upgrades; providing software, hardware, programming, and professional and/or technical services as may be necessary to correct any deficiencies, problems, failures, incompatibilities, and/or errors identified during UAT. 2.8.7.5 Agree that Bidder will provide a separate User Acceptance Testing environment for the entire UAT period as well as the operations period of the contract. 2.8.7.6 Describe Bidder’s approach to supporting UAT. Include availability of UAT environment, preparation of test data, response to discrepancies and resolution of problems. 2.8.7.7 Describe the support that will be provided to HCA for creation of test cases that cover all system functions, processes, and interfaces. 2.8.7.8 Describe the Bidder’s approach for supporting HCA staff in the analysis of test results. 2.8.7.9 Describe the process and timelines for correcting discrepancies and ensuring corrected code is thoroughly tested and migrated to the UAT environment for re-testing. 2.8.7.10 Agree that the Bidder will perform regression testing during UAT. Further, agree that the Bidder will coordinate with HCA on timing of regression tests. 2.8.7.11 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the responsibilities for HCA, MMIS vendor and Bidder staff during this stage. 2.8.7.12 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.8 Approach to Implementation/Cutover Respond to the following: 2.8.8.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Disaster Recovery Plan A plan for resuming operations in the event there are significant adverse conditions that disrupt service. See Technical Requirement 3.1.7. Solution Implementation/Cutover Plan A document reflecting the final requirements and implementation approach for the solution. Must include Cutover Schedule, plan for final data conversion and a contingency back-out plan. Certification of Operational Readiness A formal review with key stakeholders to ensure the system/application completed its implementation processes according to the Operational Readiness Plan and that it is ready for turnover to the Operations & Maintenance team and operational release into the Production environment. Must include Bidder’s statement of readiness to perform production operations. 2.8.8.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.8.3 Describe Bidder’s approach for minimizing interruption to Pharmacy claims processing during implementation/cut-over to the new solution. 2.8.8.4 Describe contents of the Solution Implementation/Cutover Plan to include the items above and other items the Bidder feels are necessary. 2.8.8.5 Agree that final go-live of the Bidder’s solution will be dependent on formal acceptance of Certification of Operational Readiness Deliverable by HCA. 2.8.8.6 Agree to support HCA as needed in Operational Readiness review activities that may be required in order to obtain approval from the Washington State Office of the Chief Information Officer. 2.8.8.7 Describe Bidder’s approach to developing the Deliverables required for this DDI stage. List the responsibilities of HCA, MMIS Vendor and Bidder staff during this stage. 2.8.8.8 Describe Bidder’s approach to coordinating the responsibilities of HCA and the current MMIS vendor with those of the Bidder to ensure overall project success. 2.8.9 Approach to Final Certification Respond to the following: 2.8.9.1 Agree that the Bidder must produce, at a minimum, the following deliverables in this stage: Deliverable Name Description Certification Artifacts -production screenshots, reports and data for final Certification Review with CMS. A collection of data, documents, and information provided as evidence for CMS’ final certification review. Evidence includes but is not limited to samples of production data, substantive and representative sets of reports (including performance) and any other information or data in order to validate business outcomes and applicable metrics related to Outcome Based Certification needs. 2.8.9.2 Describe any recommended changes or additions to the deliverables listed in the table above. State “Not applicable” if Bidder does not have any such recommendations. 2.8.9.3 Agree that Bidder will deliver a Pharmacy POS solution that will meet or exceed all CMS certification requirements. 2.8.9.4 Include a proposed timeline for preparation of certification materials and presentation of the materials to the HCA Project Manager. 2.8.9.5 Describe Bidder’s approach to coordinating the responsibilities of HCA and the MMIS vendor with those of the Bidder to ensure overall project success. 2.9 OPERATIONS AND MAINTENANCE (MR & MS) The prompts within this section consists of both MR and MS Requirements. Only the “Agree” prompts are MR. With cutover of live operations to the new POS, the former system will be taken out of service and operations and maintenance of the new system will begin. When the new POS solution is in place, HCA will continue with this Facilities Management operations model, where state staff performs the majority of operations as identified in Section 1.4, Operations and Maintenance Model. The successful Bidder will provide the system maintenance and operations described in this RFP for the life of the contract. 2.9.1 Organization and Staffing Respond to the following: 2.9.1.1 Provide a project organization chart identifying by position and roles/responsibilities of the Bidder’s staff (down to at least the lead level), including subcontractors, responsible for carrying out the operations and maintenance of the POS after implementation. 2.9.1.2 Agree that the Account Director and Operations Manager will be considered as Key Staff designees during the Operations and Maintenance period and that HCA has the right to approve initial selection and any subsequent change to these personnel during the term of the contract. 2.9.2 Operations and Maintenance The ASB must perform operations and maintenance throughout the life of the contract and in accordance with the fixed price O&M bid including cloud hosting operations and updates, patches and repairs to Pharmacy POS solution in the production, test and all other Washington accessible environments as well as troubleshooting with HCA, correction (including development, testing, training and implementation) of any deficiency or problem with the solution. Respond to the following: 2.9.2.1 Describe the Bidder’s approach to systems operations and maintenance. 2.9.2.2 Describe Bidder’s approach to maintaining and enhancing its Pharmacy POS product to ensure it continues to comply with industry standards and CMS regulations. 2.9.2.3 Describe how changes and enhancements to the Bidder’s Pharmacy POS solution would be introduced to HCA and agree that Bidder will comply with the operational requirements in Section 4.11. 2.9.2.4 Describe Bidder’s approach for promoting approved changes into User Acceptance Testing and from User Acceptance Testing to production environment. 2.9.2.5 Describe Bidder’s process for dealing with emergency fixes. Include how Bidder’s fix will be tested and promoted through testing environments to production. 2.9.2.6 Agree that Bidder will respond to HCA on non-emergency troubleshooting requests within 3 days of discovery. 2.9.2.7 Agree that the tasks identified above will be included as part of the proposed fixed price for operations and maintenance as identified in Attachment 10, Response Form for Section 5, Cost Proposal. 2.9.3 Contract Administration Respond to the following: 2.9.3.1 Describe the Bidder’s approach for monitoring and reporting performance of the system during operations. Include metrics that will be tracked, frequency of reporting and access methods to data. 2.9.3.2 Describe the Bidder’s approach for transitioning to another entity at the end of the contract period. Further, agree that the Bidder will cooperate completely with HCA and the subsequent entity including, but not limited to, a transition plan that includes data conversion, parallel testing, and system cutover activities. 2.9.3.3 Agree that the Bidder will continue to follow all project management processes established in Section 2.4 throughout the operations phase or the Bidder must propose alternate processes. 2.9.3.4 Agree that the Bidder will establish a problem resolution process including a help desk that satisfies requirements in Section 4.11. 2.9.3.5 Agree that the Bidder will develop an Annual Business Plan. The Plan should include the following elements; an road/map or outline of major activities planned for the coming year, business improvement objectives and outcomes for the coming year, methodology for performing activities and meeting objectives, methods for measuring customer service performance, methods for identifying where customer services performance is inadequate, approach for developing and implementing corrective actions. 2.9.3.6 Agree that the Bidder will develop a monthly report for HCA to describe compliance to the Annual Business Plan and update on any corrective action plans. 2.9.3.7 Agree that Bidder will walk-through performance reports at the request of HCA. END OF SECTION 2 TECHNICAL PROPOSAL The prompts within this section consists only of MS Requirements, and each requirement will be scored. Bidders must respond to the requirements below in accordance with Section 7.6.3, Proposal Format Instructions, which includes instructions on filling out each cell within the requirements tables within this Section 3. 3 3.1 OVERVIEW HCA’s technology requirements are driven by a set of guiding principles for enterprise architecture that are designed to maximize value for HCA and the clients, providers and communities it serves. These principles include the following: Cloud-based solutions that: · Allow HCA to dynamically expand and contract capacity quickly to respond to business needs, such as handling peak capacity periods. · Reduce cost by not owning hardware and infrastructure. · Better manage robust security across applications. SaaS/COTS solutions are preferred over custom-built and/or custom-components in order to: · Share and leverage best practices that have been developed across the industry and more quickly respond to industry changes. · More effectively plan, track and monitor development, administration and operations costs. · Limit code development as much as possible to configuration. · Implement new features on shorter and predictable implementation cycles. Maintain loose coupling between systems based on natural system boundaries to: · Dramatically reduce integration costs through the use of open Application Program Interfaces (APIs). · Minimize cost and disruption in the event a major component of the system has to be replaced. HCA requires the ASB meet or exceed Federal certification and performance standards by meeting the conditions defined in 42 C.F.R. 433.112(b) and those principles established under the Medicaid Information Technology Architecture (MITA) initiative and framework. This includes the goals and technical principles that promote rules engines, where possible, to extend the system’s configuration abilities to be managed by the business community. All conditions must be met in order for HCA to remain eligible for Federal Financial Participation (FFP) funding. HCA requires that the ASB establish and maintain a performance record of high availability. HCA requires the ASB meet or exceed HIPAA security, privacy and transaction standards, accessibility standards established under section 508 of the Rehabilitation Act or standards that provide greater accessibility for individuals with disabilities and compliance with Federal civil rights laws; standards adopted by the Secretary under section 1104 of the Affordable Care Act (ACA); and standards and protocols adopted by the Secretary under section 1561 of the ACA. In addition to Federal requirement compliance, the ASB’s system must comply with all applicable State of Washington Office of the Chief Information Officer (OCIO) standard and security requirements including a cyber-security design review. The OCIO sets information technology (IT) policy and direction for the State of Washington and the State CIO is a member of the Governor’s Executive Cabinet and advisor to the Governor. The ASB will be required to participate in a yearly disaster recovery exercise with HCA in which results will be made available to the State Auditor’s Office (SAO). REQUIREMENTS TABLE ON THE FOLLOWING PAGE HCA RFP No. Page 3 of 128 HCA RFP No. 2020HCA28 Page 23 of 129 3.1.1 General Req. # Requirement (1) Comply (a) Core (b) Custom (c) 3rd Party 3.1.1.1 Describe your product's technical offering and include any ranges of high availability and business continuity options available. Describe any unique, innovative or additional features available in your offering and the advantages they bring to HCA. Response: 3.1.1.2 Describe your product’s architecture design. Include your current and target architecture and design principles and degree to which your current product meets those principles. List your use of included technologies and versions and include when your product last had a significant upgrade as well as your product roadmap for future technology enhancements. Response: 3.1.1.3 The Bidder must maintain all Third-Party Software products at either their most current version or no more than one version back. Describe your ability to meet this requirement. Response: 3.1.1.4 Identify, if any, the third-party providers, organizations or other organizational resources other than your company that you intend to use to support these technology requirements. Indicate the nature and overall content of the contractual agreement that you plan to have with this external resource. Indicate the viability of the proposed resource(s) in terms of the following: market position, ability to meet requirements, alignment with industry standards and practices, industry implementation track record and Bidder implementation track record. Response: 3.1.1.5 The Bidder must collaborate with HCA and the MMIS contractor to develop and/or update conceptual and logical data models. Describe your ability to meet this requirement. Response: END OF SECTION 3.1.1 3.1.2 Standards Req. # Requirement (1) Comply (a) Core (b) Custom (c) 3rd Party 3.1.2.1 Describe how the Bidder’s solution complies with applicable Washington State Office of the Chief Information Officer (OCIO) standards. Please respond specifically to the link and standard below and attach any evidence of compliance. https://ocio.wa.gov/policy/securing-information-technology-assets Security 141.10 Response: 3.1.2.2 Describe how Bidder would ensure that any components installed on State workstations, now and in the future, must be compatible with HCA currently supported software versions of, and future updates and patches for, the Microsoft Operating System, Microsoft Office Suite, and all modern internet browsers. Response: 3.1.2.3 The Bidder’s solution must comply with all applicable current and future Center for Medicare and Medicaid Services (CMS) certification requirements. Attach any evidence of previous certification from other implementations. Response: 3.1.2.1 3.1.2.2 3.1.2.3 3.1.2.4 Describe how the Bidder’s solution complies with all NIST standards for cloud computing. Relevant links are listed below. Attach any evidence of compliance and/or certification. https://www.nist.gov/itl/nist-cloud-computing-related-publications https://www.nist.gov/news-events/news/2018/02/nist-releases-evaluation-cloud-computing-services-based-nist-sp-800-145 https://csrc.nist.gov/publications/detail/sp/500-299/draft https://bigdatawg.nist.gov/_uploadfiles/M0008_v1_7256814129.pdf Response: 3.1.2.5 Describe how the Bidder’s solution complies with all applicable Section 508 of the Rehabilitation Act of 1973 standards and attach your response to the checklist referenced in the link below. https://www.hhs.gov/web/section-508/index.html https://www.hhs.gov/web/section-508/accessibility-checklists/index.html Response: 3.1.2.6 The Bidder must provide HCA an annual report from its external auditor on effectiveness of internal controls. The report must be provided at go-live and annually thereafter. The report must be compliant with the American Institute of Certified Public Accountings (AICPA) Statement on Standards for Attestation Engagement (SSAE) No. 18, Reporting on Controls at a Service Organization, Service Organization Control (SOC) 1, SOC 2, and Type 2 Report. Describe your ability to meet this requirement. Response: 3.1.2.7 Describe how the Bidder’s solution complies with any applicable Americans with Disabilities Act (ADA) standards. Attach any evidence of compliance. Response: 3.1.2.8 The Bidder’s solution must inform a user of applicable privacy policy and terms of service prior to granting access. Describe your ability to meet this requirement. Response: END OF SECTION 3.1.2 3.1.3 Security Req. # Requirement (1) Comply (a) Core (b) Custom (c) 3rd Party 3.1.3.1 Describe how the Bidder’s solution’s security integrates with the State's access and identity management tools and Active Directory authentication system for HCA users through single sign on as described in OCIO 141.10. Solutions which use Domain trusts will not be acceptable. Response: 3.1.3.2 Describe how the Bidder’s solution will deliver services through the state's identity access management infrastructure that provides single sign on to all modules/functions within the system enabled in the user's security profile. Response: 3.1.3.3 The Bidder’s solution must provide secure access to vendors and Providers working outside the State's firewall in compliance with OCIO 141.10 policy via Secure Access Washington (SAW). Describe your ability to meet this requirement. Response: 3.1.3.4 Describe how Bidder’s solution security will dynamically control and administer role-based user access for all users, including the ability for users to have more than one role. Include a description of how role hierarchy is addressed in Bidder’s solution. Response: 3.1.3.5 The Bidder must participate in the Office of Cyber Security (OCS) design review process and successfully pass the review using the Office of Chief Information Officer (OCIO) 141.10 standard and OCS vendor design review checklist. A copy of the OCS checklist is included herein as Attachment 5, OCS Design Review Checklist. The Bidder must complete Checklist B of this Attachment 5 and return the completed version in their response for this requirement. The Bidder is also required to add in Notes within Checklist B to indicate current and future ability to maintain compliance with the Checklist B items. Bidder understands that a full design review including the ability to successfully pass the review will still be required if selected as the ASB. This design review will also include any third-party providers that will support the technology requirements. Response: 3.1.3.6 The Bidder’s solution, data, and all facilities and services provided to Washington State will be located within the United States. Data cannot be moved offshore. Describe your ability to meet this requirement. Response: END OF SECTION 3.1.3 3.1.4 System Auditing Req. # Requirement (1) Comply (a) Core (b) Custom (c) 3rd Party 3.1.4.1 The Bidder’s solution must ensure that all system events are written to a system event log. Describe your ability to meet this requirement. Response: END OF SECTION 3.1.4 3.1.5 Database Req. # Requirement (1) Comply (a) Core (b) Custom (c) 3rd Party 3.1.5.1 The Bidder’s solution must maintain historical records (e.g., a log file) of table updates and data logged including but is not limited to, user ID, data before change, change data and date/time stamp. Describe y