Each marketplace created under PPACA is intended to provide a seamless, single point of access for individuals to enroll in qualified health plans, apply for income-based financial subsidies established under the law and, as applicable, obtain an eligibility determination for other health coverage programs, such as Medicaid or the State Children’s Health Insurance Program (CHIP). To obtain health insurance offered through the marketplace, individuals must complete an application and meet certain eligibility requirements defined by PPACA, such as being a U.S. citizen or legal immigrant. For those consumers determined eligible, the marketplaces permit users to compare health plans and enroll in the plan of their choice. States had various options for marketplace participation, including (1) establishing their own state-based marketplace, (2) deferring to CMS to operate the federal marketplace in the state, or (3) participating in an arrangement called a partnership marketplace in which the state assists with some federal marketplace operations. In our June 2013 report on CMS efforts to establish the federal marketplace, we concluded that certain factors—such as the evolving scope of marketplace activities required in each state—suggested the potential for implementation challenges going forward.draft of that report, HHS emphasized the progress it had made since PPACA became law and expressed its confidence that marketplaces would be open and functioning in every state on October 1, 2013. PPACA required the establishment of marketplaces in each state by January 2014. Based on the expectation that individuals and families would need time to explore their coverage options and plan issuers would need time to process plan selections, HHS established October 1, 2013, as the beginning of the enrollment period for all marketplaces, including the federal marketplace.legal or regulatory, and organizational events during that development period, as well as future milestones through the beginning of open enrollment for 2015. The Healthcare.gov website is supported by several systems, including the FFM and the federal data services hub. Additional components include the Enterprise Identity Management System that confirms the consumer’s identity when entering the system. Healthcare.gov is the Internet address of a federal government-operated website that serves as the online user interface for the federal marketplace. The website allows the consumer to create an account, input required information, view health care plan options and make a plan selection. The FFM accepts and processes data entered through the website and was intended to provide three main functions: Eligibility and enrollment. This module guides applicants through a step-by-step process to determine their eligibility for coverage and financial assistance, after which they are shown applicable coverage options and have the opportunity to enroll. Plan management. This module interacts primarily with state agencies and health plan issuers. The module is intended to provide a suite of services for activities such as submitting, monitoring, and renewing qualified health plans. Financial management. This module facilitates payments to issuers, including premiums and cost-sharing reductions, and collects data from state-based marketplaces. Other FFM functions include services related to system oversight, communication and outreach strategies, and customer service. The data hub routes and verifies information among the FFM and external data sources, including other federal and state sources of information and issuers.Security number with the Social Security Administration and connects to the Department of Homeland Security to assess the applicant’s citizenship or immigration status. For example, the data hub confirms an applicant’s Social The data hub’s connection with other federal and state databases enables exchanges to determine whether an applicant is eligible for or enrolled in some other type of health coverage, such as the Department of Defense’s (DOD) TRICARE program or Medicaid—and therefore ineligible for subsidies to offset the cost of marketplace plans. hub also communicates with issuers by providing enrollment information and receiving enrollment confirmation in return. See figure 2 for an overview of Healthcare.gov and selected supporting systems. These subsidies include premium tax credits to offset qualified health plan premium costs and cost-sharing reductions to reduce policyholders’ out-of-pocket payments, including deductibles and co-payments, for covered services. While CMS was tasked with oversight of marketplace establishment, several other federal agencies also have implementation responsibilities. Three agencies—CMS, the Internal Revenue Service (IRS), and the Department of Veterans Affairs (VA)—reported almost all of the IT-related obligations supporting the implementation of the Healthcare.gov and its supporting systems. IT-related obligations include funds committed for the development or purchase of hardware, software, and system integration services, among other activities. These obligations totaled approximately $946 million from fiscal year 2010 through March 2014, with CMS obligating the majority of this total. As of March 2014, CMS reported obligating $840 million for the development of Healthcare.gov and its supporting systems, over 88 percent of the federal total. According to agency data, these obligations were spread across 62 contracts and task orders. We focused our review on two CMS task orders issued under an existing 2007 contract. The task orders were for the development of two core Healthcare.gov systems— the FFM and the data hub. We also reviewed a letter contract awarded by CMS in January 2014 to continue FFM development. The two task orders and the additional contract account for $369 million, or more than 40 percent, of the total CMS reported obligations as of March 2014. The contract and task orders we examined are subject to the Federal Acquisition Regulation System, which provides uniform policies and procedures for acquisition by all executive agencies. The system includes the HHS acquisition regulation, which implements or supplements the FAR. HHS’s supplement to the FAR, which contain additional HHS policies and procedures, is referred to as the Department of Health and Human Services Acquisition Regulation (HHSAR). The FAR and HHSAR address issues pertaining to the contracting process and include activities related to three phases: pre-award, competition and award, and post- award. See figure 3 for an overview of these phases and selected activities related to each. To implement and oversee PPACA’s marketplace and private health insurance requirements, HHS established the Office of Consumer Information and Insurance Oversight (OCIIO) in April 2010 as part of the HHS Office of the Secretary. In January 2011, the OCIIO moved to CMS and became the Center for Consumer Information and Insurance Oversight (CCIIO). Within CMS, establishment of the federal marketplace was managed by CCIIO, with responsibilities shared with the Office of Information Services (OIS), and the Office of Acquisition and Grants Management (OAGM). HHS’s acquisition process for the data hub and FFM task orders involved multiple participants, including: The contracting officer. The contracting officer has the authority to enter into, administer, and/or terminate contracts and make related determinations. The contracting officer is responsible for ensuring performance of all necessary actions for effective contracting, ensuring compliance with the terms of the contract, and safeguarding the interests of the United States in its contractual relationships. The contracting officer’s representative (COR). The COR—also referred to as the contracting officer’s technical representative—is designated in writing by the contracting officer to perform specific technical or administrative functions. Unlike the contracting officer, a COR has no authority to make any commitments or changes that affect price, quality, quantity, delivery, or other terms and conditions of the contract and cannot direct the contractor or its subcontractors to operate in conflict with the contract terms and conditions. The government task leader (GTL). The GTL is a representative of the program office who assists the COR and is responsible for day-to- day technical interaction with the contractor. The GTL is also responsible for monitoring technical progress, including the surveillance and assessment of performance, and performing technical evaluations as required, among other responsibilities. CMS undertook the development of Healthcare.gov and its related systems without effective planning or oversight practices, despite facing a number of challenges that increased both the level of risk and the need for oversight. According to CMS program and contracting officials, the task of developing a first-of-its-kind federal marketplace was a complex effort that was exacerbated by compressed time frames and changing requirements. CMS contracting officials explained that meeting project deadlines was a driving factor in a number of acquisition planning activities, such as the selection of a cost-reimbursement contract, the decision to proceed with the contract award process before requirements were stable, and the use of a new IT development approach. These actions increased contract risks, including the potential for cost increases and schedule delays, and required enhanced oversight. However, CMS did not use information available to provide oversight, such as quality assurance surveillance plans. CMS also missed opportunities to consider the full range of risks to the acquisition by not developing a written acquisition strategy, even though the agency was required to do so. As a result, key systems began development with risks that were not fully identified and assessed. Meeting project deadlines was a driving factor in a number of acquisition planning activities. HHS had 15 months between enactment of PPACA and the agency’s request for proposal to develop requirements for the FFM and data hub. In a prior report on acquisition planning at several agencies, including HHS, we found that the time needed to complete some pre-solicitation planning activities—such as establishing the need for a contract, developing key acquisition documents such as the requirements document, the cost estimate, and, if required, the acquisition plan; and obtaining the necessary review and approvals— could be more than 2 years. The time needed depended on factors that were present for this acquisition including complexity of the requirements, political sensitivity, and funding.developing requirements for a complex, first-of-its-kind system in these compressed time frames and indicated that more time was needed. CMS program officials noted challenges The FFM and data hub task orders were issued under an existing 2007 contract for enterprise system development. This approach was reasonable in these circumstances because, according to contracting officials, the task orders could be issued more quickly than using a full and open competitive approach.