Obamacare – “Tax Credit” is not the same as “Tax Credit Functionality” By Scot K. Vorse
The administration required states exchange websites to allow individuals to apply for tax credits, but did not require the same from Healthcare.gov, suggesting that the administration believed that individuals in the 36 states run by the federal government were not eligible for tax credits.
Gotnews.com will publish analysis from our readers.
After my August 26th article “Original Obamacare Website Contract Had No Federal Tax Credit Consumer Functionality Language” numerous healthcare experts and journalists challenged my claim that the original contract to build Healthcare.gov did not include any provision for tax credits to residents in states using the Federal Exchange. This issue became important after a federal appeals court panel dealt a potentially major blow to the Affordable Care Act (“ACA” or “Obamacare”) by ruling on July 22nd in the case of Halbig v. Burwell that individuals in health exchanges run by the federal government in 36 states are not eligible for billions of dollars in tax credits.
On Thursday, the full District of Columbia Court of Appeals announced it will reconsider this 2-1 decision by the court panel. However, several facts have emerged since July 22 which will provide further support to the argument that the intent of Obamacare was that tax credits should only be available for state run ACA exchanges.
The issue of the functionality of the Healthcare.gov contract has the potential to create additional doubt about the intent of the law. As Michael F. Cannon, Director of Health Policy Studies for the Cato Institute told me Friday “The Obama administration wants federal courts to let it continue issuing health-insurance subsidies in the 36 states with federally established health-insurance Exchanges, even though the Patient Protection and Affordable Care Act authorizes those subsidies only ‘through an Exchange established by the State.’ If, back in 2010 and 2011, the administration told states seeking to establish Exchanges they would have to inform applicants of their eligibility for subsidies, but did not require contractors creating federal Exchanges to do the same, it would suggest the administration once understood the law to say the opposite of what the administration is now arguing in federal court.”
The August 26th article had 8 main points:
- In 2010, HHS provided written guidance to states regarding required tax credit functionality for individual enrollment – By November 3, 2010, shortly after Obamacare had been enacted, Health and Human Services (“HHS”) had already begun providing states documents with specific guidance related to required tax credit technology and system specs for their exchange. HHS distributed at least 18 different guidance documents. One document titled Exchange Reference Architecture: Foundation Guidance created by HHS on March 16, 2011 outlined unambiguous required functions related to individual enrollment on exchanges. For example:
- “Core Functions Supported by an Exchange . . . Eligibility determinations for Exchange participation, premium tax credits, and cost-sharing reductions”
- “KEY BUSINESS PROCESS . . . Individual enrollment in a QFHP; determination of eligibility for advance premium tax credits, cost-sharing reductions, and other applicable state health subsidy programs”
A second document titled Financial Management Blueprint – Business Architecture Supplement (the “Blueprint”) detailed the many processes involved with the law. Recognizing the multiple functions and stakeholders in the ACA, the document provided a blueprint as to how each stakeholder should interact with each of the other stakeholders. The Blueprint specified the functions required for each stakeholder related to individual enrollment and tax credits.
- State-Operated Exchange website developer contracts included this required tax credit functionality for individual enrollment as outlined by HHS – Several of the state exchange developer contracts were executed well before the Federal Exchange contract was modified in 2012. Copies of the contract or Request for Proposals (“RFP’) are available on the statereforum.org website. According to these documents, most state exchanges included this specific individual enrollment functionality in their contracts and RFPs. For example, California’s 160 page request for proposals to contractors listed detailed requirements including:
- “The primary business objective of California Healthcare Eligibility, Enrollment and Retention System is to provide a “one-stop shop” to determine eligibility for non-subsidized coverage for individuals in the Exchange and subsidized coverage for individuals eligible for the following Applicable State Health Subsidy (ASHA) Programs: . . . Advanced Premium Tax Credit (APTC) in the Exchange “
- “Eligibility Determination – Key Functionality includes: Processing in real-time, online eligibility for subsidized health and/or dental coverage. The eligibility determination process calculates the APTC and CSRs and displays gross enrollee obligation and the net premiums. Results from determining eligibility are to be displayed online to the applicant. “
- Originally, HHS was confident that most states would establish its own exchange – For several months after the ACA became law, HHS was confident that most states would create their own healthcare exchange. For example, on July 15, 2011, Steven Larsen, a Director in the Office of Consumer Information and Insurance Oversight at HHS, responded to a question at the Annual Governors meeting that he expects only a “small handful” of states will not set up their own exchange. See Saturday July 16 – Session 2, Q + A, minute 33.
- The original 2010 Federal Exchange contract didn’t include any tax credit functionality related to individual enrollment – The original Federal Exchange contract and statement of work that was signed on September 30, 2011 did not include any of the tax credit functionality language outlined by HHS as required for exchanges and as included in the individual state exchange developer contracts. Although the contract was executed in September 2011, the number of specific functions and processes included in the agreement suggests that the contract had been in the process of being developed for several months prior to signing.
- Despite administration pressure, and contrary to what HHS had anticipated, numerous states did not establish their own exchange – The Obama administration pressure and logic for optimism is highlighted in a video published by New Republic of Jonathan Gruber, the architect of Obamacare. In response to a question during a presentation, Gruber explained how states will get “squeezed” and eventually agree to establish their own exchange and added “if you’re a state and you don’t set up an Exchange, that means your citizens don’t get their tax credits”. 36 states did not establish their own exchange.
- In May 2012, the IRS published its final rules – On May 23, 2012, the IRS published its final rules and regulations which concluded that residents from states on the Federal Exchange are entitled to Federal tax credits under the ACA.
- On August 28, 2012, HHS modified the Healthcare.gov contract – The modified contract added a completely new section with 3 pages of specific language related to individual tax credit functionality. This added language was similar to what the HHS guidance documents required of all exchanges and to what the state based exchanges had already included in their contracts several months before this amendment was executed.
- In 2014, a GAO report attributed the contract changes to increased system requirements resulting from “finalized regulations” – In April 2014 the Government Accountability Office issued a report which specifically commented on the HHS modified contract with CGI that “Obligates an additional $35.8 million, primarily to provide for new and increased system requirements resulting from program office decisions and finalized regulations.” The only material language added to the contract related to the 3 page insert regarding individual tax credit functionality.
Critics highlight 5 references to tax credits in the original contract – Critics have challenged my analysis pointing to the five references in the original 2010 contract between HHS and CGI, the primary contractor of Heathcare.gov. They argue that these five references are evidence that the original contract did require CGI to build individual tax credit functionality into Healthcare.gov. This claim supports the Obama narrative that the law was always intended to include residents from all 50 states. Monday’s article acknowledged these references but did not explain why I believe they are not applicable. There are two main reasons why these references are not applicable.
- There are numerous stakeholders in Obamacare – In analyzing these references, it is important to note that numerous stakeholders are involved in the ACA including HHS, the Federal Exchange, the state-based exchanges, the states, the issuers or insurance companies, the reinsurance entity and individuals. Each of these stakeholders interacts with several of the other stakeholders on a variety of different issues. However, related to this issue, there is only one interaction that matters – did the original contract require the Federal Exchange to include functionality that allowed individuals using Healthcare.gov to verify eligibility and then calculate, compare and enroll in various plans based on receiving these tax credits? If the answer is no – this strongly suggests that when HHS began to implement the law in 2010, it acted as if it believed the intent of the law was that residents in states operated by the Federal Exchange were not entitled to receive tax credits.
- HHS has separate roles and the contract required different functionality related to various functions and stakeholders – The contract specifically stated that the system had to address two very different HHS functions and responsibilities: (1) “a Federal Exchange (“FX”) that serves the needs of individuals within states where those states do not have their own state-run exchange” and (2) “the Data Services Hub (“DSH”), which provides common services and interfaces to federal agency information.” For simplicity, these two functions are often referred to as “front end” processes (processes of an individual or “user” interacting directly with an exchange attempting to obtain health insurance) and “back end” processes (processes whereby HHS interacts with other stakeholders to provide common services and administrative or coordinating services). Back end functionality is not the technology which allows individuals to access Healthcare.gov and obtain health insurance. Therefore, any reference to tax credits for back end functions does not relate to allowing individuals to access the website to obtain tax credits.
Specific Response to Each of the 5 References
Reference #1 – On page 1 the Introduction summarizes the ACA and includes a general reference to tax credits. No one would logically argue this general reference required the contractor to build functionality for individuals to obtain tax credits.
References #2 and #3 – Page 4 of the contract stated that “The key Exchange IT systems modules shall include . . . Premium tax credits administration”. And page 5 of the contract stated that “The foregoing Exchange IT modules must support the core business functions of an Exchange. As presently understood, the Exchange consists of the following business functions . . . Premium Tax Credit Administration”.
So the question is – what does the phrase “tax credit administration” refer to? Does it refer to technology “that serves the needs of individuals within states where those states do not have their own state-run exchange” (i.e. the front end) or does it refer to technology “which provides common services and interfaces to federal agency information” (i.e. the back end)?
On February 27, 2012, the Code of Federal Regulations provided an explicit answer to this question. This 127 page section only mentions one “administration” function or process. The reference is in section 155.34 – Administration of advance payments of the premium tax credit and cost-sharing reductions. This section details that an exchange has the:
“Requirement to provide information to enable advance payments of the premium tax credit and cost-sharing reductions. In the event that the Exchange determines that a tax filer is eligible for advance payments of the premium tax credit, an applicant is eligible for cost-sharing reductions, or that such eligibility for such programs has changed, the Exchange must, simultaneously—
(1) Transmit eligibility and enrollment information to HHS necessary to enable HHS to begin, end, or change advance payments of the premium tax credit or cost-sharing reductions; and
(2) Notify and transmit information necessary to enable the issuer of the QHP to implement, discontinue the implementation, or modify the level of advance payments of the premium tax credit or cost-sharing reductions”
The introductory phrase “In the event that the Exchange determines that a tax filer is eligible for advance payments of the premium tax credit . . . the exchange must . . .” clarifies that “tax credit administration” relates only to “back end” responsibilities. The exchange must interact with HHS after an exchange has determined that a tax filer is eligible for tax credits. This is not the “front end” function of an exchange in which an individual or “user” has the ability to log on to the exchange website and determine whether they are eligible for a tax credit, and then calculate the amount of the tax credit, compare plans after affecting for the tax credit and then enroll in a plan with the benefit of the tax credit.
Reference #4 – One critic highlighted that Section 2.3.3 specifically mentions tax credits stating “Financial management services include the services necessary to spread risk among issuers and to accomplish financial interactions with issuers. The risk spreading services include, but are not limited to: payment calculation for reinsurance, risk adjustment and risk corridors, along with required data collection to support these services. The issuer financial transactions include: SHOP and Individual Premium (optional) processing, Advanced Premium Tax Credit (APTC) and Cost Sharing Reduction (CSR), Reinsurance, Risk Adjustment and Risk Corridors payments.”
However, the second and only other paragraph in this section states “The Contractor shall use the Financial Management blueprinting information and the products from the requirements contractor to finalize the services technical and system requirements to develop and deliver the Financial Management services. The Contractor shall present the requirements, design, and implementation approach to CMS. The Contractor shall develop, implement, test, and deliver Financial Management services using the web services model for the DSH.”
There are two points which need to be considered:
- The Blueprint specifically details that the processes addressed in section 2.3.3 (“risk spreading services” and “issuer financial transactions”) which are “back end” processes between HHS, the states, the exchanges, the insurance companies and the reinsurance entity. Nowhere in the Blueprint are these functions ever described as a process between the Federal Exchange and individuals applying for health insurance with tax credits (a front end process).
- Furthermore, the second sentence of this paragraph specifically stated that “The Contractor shall develop, implement, test, and deliver FM services using the web services model for the DSH.” The DSH functions are back end not front end processes.
Reference #5 – On page 46 the last reference in the contract stated “For the purpose of costing out a proposal, the Contractor shall also assume that all Exchanges will access a Federal data services hub that will facilitate transactions between States and federal agencies where federal information is required, for example, to support the determination and verification of consumer eligibility for tax credits.”
It is clear from this last reference that these interactions are between “all Exchanges” and “data services hub” not exchanges and individuals applying for tax credits.
In short, HHS has many roles and interacts with many stakeholders related to managing Obamacare. Many of those roles and interactions with stakeholders involve tax credits. However, there are no references in the original contract requiring the contractor to develop any front end functionality for tax credits. This raises the question, why would HHS require states to create front end functionality for tax credits but not include this same functionality in the contract for Healthcare.gov if it believed all tax filers, regardless if they enrolled on a state-based exchange or the Federal Exchange, were entitled to tax credits?
Oblimination – hoping for change and the reversal of Obama’s failed policies.
Scot K. Vorse is a retired investment banker having spent much of his career at Goldman, Sachs & Co. and is a graduate of Harvard Business School. Mr. Vorse is currently the President of Vorsetrade, a software company based on patent pending technology which uses barter logic and technology used by government entities to reallocate excess assets.