For the 30 or more states that were waiting to decide upon their approach, the options may be dwindling given the timeline for implementation (Jan.1, 2014, but in reality Oct. 1, 2013 to manage open enrollment).
The transfer solution is a challenge; there is scant time for states to build a solution from scratch even if they leverage out of the box components for core functionality. To be ready for open enrollment, these states should have all Qualified Health Plans (QHPs) certified, tested and in place by Oct. 1.
Other options to include:
- Going with the federal exchange (FFE)
- Leveraging a 3rd party cloud/SaaS based solution
And there is a third option that I reveal later in this text, as is my wont!
The two options can represent a challenge in that they are technically feasible but may require a lot of surrounding work. Unfortunately, it is not all about technology. There is the aspect of:
- governance, especially in case of FFE with shared responsibilities across federal and state governments
- operational issues such as integration with existing eligibility systems with respect to ‘no wrong door’ compliance
- consumer and navigator assistance, and
- communication and training issues.
The FFE option comes in multiple flavors, one of which is a non-partnership approach wherein the federal government executes the exchange without contribution from the state, thereby minimizing state influence on the direction of the exchange. The other flavors are variants of a partnership model wherein the state executes and controls certain aspects of the exchange, such as consumer outreach and plan management. The balancing act under this scenario can be how much control to cede to the federal government which is in inverse proportion to the amount of work the state is willing to own. Even if the federal government executes the exchange exclusively, some tasks require state involvement, for example setting up the connection between the state’s eligibility system and the FFE to facilitate eligibility determination (for example, Medicaid and CHIP) for the applicants.
The cloud/SaaS model involves the state subscribing to a service for a configurable HIX platform and leaving the vendor to manage the platform. In addition, the state may or may not decide to outsource business processes, like consumer support, to the vendor. One possible benefit is the state does not have to invest huge capital upfront. Also the state doesn’t have to wait for a solution to be built from scratch, and they are less involved with the operational issues such as data center and call center management, infrastructure upgrades etc. So is SaaS is the way to go?
SaaS products are usually horizontal in nature, that is, they can apply to a large number of consumers with little or no customization. That is the core to reducing the administrative costs per customer. Unfortunately the HIX platform requires significant amount of customization/configuration to meet a specific state’s requirements in terms of eligibility rules and other workflows. This could limit one of the advantages of a SaaS model.
In addition, the HIX platform should interact with a number of state and federal systems in determining eligibility, and systems related to incarceration data, labor and license data, income data.. The security requirements specific to such confidential personal data could make the multi-tenancy aspect of a typical SaaS model less effective and attractive to states.
Another concern with the SaaS model can lie in the fact that ACA funding is a front-loaded model. The federal government will fund the initial build and stabilization of the state Health Benefit Exchange (HBE) and the first year of operational cost. Beyond that the states are responsible for operational costs. In a traditional SaaS model the upfront cost is often absorbed by the vendor in lieu of higher per unit cost, which tends to increase over time as more constituents take to the exchanges. This could create more problems for the states in terms of outer year costs when financial sustainability is essential. So, while states can hope to speed up implementation using a private, cloud-based SaaS platform, there may not be a ready-to-launch solution that can maintain the same level of sustainability for states as a front loaded transfer solution.
So what is the third option?
How about leveraging the FFE in an SaaS environment for a year, then switching to a state specific transfer solution for the October 2014 open enrollment period that supports 2015 transactions? It could bring advantages because:
- Delaying the state specific transfer solution for a year may give states a better chance of achieving the mandate.
- The transfer solution will be built during 2013 and 2014 and fall under the federal funding paradigm. States don’t have to bear the outer year costs, possibly improving the sustainability percentage.
- The interfaces with state and federal systems that are going to be built for state-specific exchanges could be used for the transition period wherein FFE uses the same interfaces to interact with state systems.
- An integrated portal could be provided for state constituents for both HIX and other public services programs such as CHIP andTANF, albeit a year late. This option may not be available with a continuing FFE option as FFE will have its own portal (maintained by federal government) and other public services programs will be accessible through state portal. This can cover the requirement of ‘no wrong door’ at a single point of entry.
- A private cloud model post 2014 could offer the benefits of SaaS without the associated increased outer-year cash layouts.
So option three may be worth considering in making the best out of a tricky situation.
Whichever option the states prefer, the implementation will require effort and discipline to meet the timeline, which may have looked plausible when the bill was passed, but now is looking increasingly difficult to attain.
Rajiv Sabharwal is director at Deloitte Consulting LLP, a member firm of Deloitte Touche Tohmatsu Limited (DTTL).
This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.
As used in this document, "Deloitte" means Deloitte Consulting LLP, a subsidiary of Deloitte LLP. Please see www.deloitte.com/us/about for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting.