The Patient Protection and Affordable Care Act (ACA), commonly known as Obamacare, represented the most significant overhaul of the US Healthcare system since the passage of Medicare and Medicaid in 1965.

ACA’s future might be uncertain at the moment. But the story of its implementation provides essential learnings for ICT officials striving to achieve the digital transformation agenda. Notwithstanding certain unique characteristics, many of the challenges from ACA appear often in the implementation of massive scale, complex projects. Some of those challenges are internal, some are external.

The centrality of IT to business, whether government or otherwise, means that ICT projects do not happen in a vacuum. They are susceptible to factors beyond the control of ICT executives, such as political headwinds, expanding the range of contingencies to be taken into account.

A big part of the ACA is HealthCare.gov, the website that offers insurance through exchanges operated by the federal government, to serve the residents of the U.S. states without their own state exchanges.

ICT requirements included integration of a dizzying array of disparate data from national and state government entities and private and public sector players. It would be called on to process thousands of complex transactions per second. Hundreds of thousands of users would concurrently visit the website. Enrolling, shopping for plans and applying for tax credits would have to be a seamless experience for the end-user. Later on, applications would have to be reconfigured or replaced, without incurring an increase in database interference, data loss or security risks. All this, while guaranteeing security for highly sensitive data.

OpenGov spoke to Henry Chao, Former Deputy CIO & Deputy Director of the Office of Information Services, Centers for Medicare & Medicaid Services (CMS). He was at the centre of it all, building healthcare.gov from the ground-up.

Mr. Chao spent around 21 years working for CMS. He served in the role of Chief Technology Officer from December 2007 till July 2010 and then he moved on to the office that was created to take care of many of the critical sections of the ACA, including the Insurance Exchange.

The beginning

Transforming healthcare was part of President Obama’s election platform. Work groups were established to look at potential implementation options during the early days of his administration.

The objective was to provide affordable access to healthcare for the uninsured. There were two broad options under consideration. The first one, called the public option, originated in the US House of Representatives.

The second approach, involving state-based exchanges, originated in the US senate. Ultimately, the House and the Senate reached a consensus on the latter. The ACA was signed into law by President Obama in March 2010. The intent was for each state to have a Health insurance marketplace or health exchange. An office was established after 3-4 weeks, called the Center for Consumer Information & Insurance Oversight (CCIIO).  

CCIIO was established out of the office of the United States Department of Health & Human Services (HHS). The HHS secretary was the lead cabinet executive to oversee the implementation.

Implementation starts – Uncertainties

Number of states and co-operation between federal and state agencies

Even though nearly all the states took grant money from the federal government to work on the project, till early 2013, there was no firm count of how many of them were committed to start their own exchange. This posed a huge challenge in the process of understanding the scope of the project.

Mr. Chao said, “It was not going to be zero and it was certainly not going to be 50. The fear was that with all the politics involved, the number of states that choose to stand up their own marketplace and be able to do so would be a very small number. It turned out that in 2013, only about 14 states and DC opted to have partially working exchanges.”

Due to political issues, some state governors passed laws preventing state administrations from working on Obamacare. The federal agencies operate the exchange on behalf of those states, for the uninsured in the state.

For an applicant who is applying on behalf of the household, eligibility for the family members has to be coordinated between three programs, the insurance marketplace, the Medicaid programme in that state and the State Children's Health Insurance Program (SCHIP) in that state.                                            

In the case where states are not cooperative or not operating their own exchange, there still has to be a high degree of co-ordination between the three programs.

Converting abstract laws into specific regulations

The law was a conceptual rendering of what an insurance program would look like for the uninsured and the macro steps required.

CMS had to write several dozens of regulations, that specified in detail how the programme would operate. For instance, there was one regulation written about the parameters for participating in the marketplace as a qualified insurer. The eligibility to apply for premium tax credits and how it would be coordinated with Medicaid and SCHIP was another regulation. The regulations came out at different times. The earliest one was in 2011. The latest one was in the middle of 2013.

"You have to keep track of all those requirements, from the highest to the lowest level, to get your IT scope correct in terms of business and functional capability,” Mr. Chao explained. Political complications hampered the process of publishing the regulations and obtaining public comments.
         
         
         

Budget

The ACA was passed with about a billion dollars appropriated to support the rollout of the insurance marketplace. It didn’t specify who is going to get that money. There were several departments with expanded responsibilities, competing for the funds. For example, the treasury and the internal revenue service had to administer the premium tax credit.

In Mr. Chao’s words, “A billion dollars was a drop in the bucket for something of this magnitude. The IRS and Treasury took more than half of that billion dollars. Funding was the first challenge.We didn’t get all the money at once. Whatever money we were getting for the first two years was in the form of monthly stipends. You can’t award a 100-million-dollar contract when you are only getting a million dollars a month.”

Through the start and stop, around USD 380 million was directed towards IT development during the first 3 years. All these variables meant that the team had to build systems that could tolerate that kind of volatility. And it had to be done using commodity models.

CMS selected infrastructure-as-a-service model as it could be scaled up over time as required.

Requirements

Acronyms: HIGLAS– Healthcare Integrated General Ledger Accounting System, SSA- Social Security Administration, IRS- Internal Revenue Service, DHS– Department of Homeland Security, DHA– Defense Health Agency, VA– Department of Veteran Affairs, NAIC – National Association of Insurance Commissioners, SERFF– System for Electronic Rate and Form Filings. DOI- Department of Insurance

Estimating user volume – model for verification, determination and enrolment

Users would include potentially 7 million customers buying insurance during the first year, healthcare providers, and people who work for healthcare providers, for labs, hospitals, adding up to millions. All the users would have to be authenticated, information taken from them and right outputs provided. A summary design and architectural principles for such large-scale complex systems had to be decided.  

After the launch there would be additional labour considerations, call centre people required in a situation where the consumers know very little about the product.

Requirements derived from government in general – security and privacy

Key Federal government stakeholders for the Insurance Marketplace program (aka Insurance Exchange) are Departments and Agencies with programs and their associated data that were needed to perform certain verifications of status and eligibility for enrolling in the Insurance Marketplace.  These "systems of record" serve as the authoritative source for essential data were connected in real time to facilitate the online process to apply for enrolment in to a Qualified Health Plan (QHP) offered by the Insurance Marketplace.

This included the US Treasury Department and the Internal Revenue Service. In addition to being the authoritative source for federal tax filings, the Treasury and IRS were assigned the responsibility for administration of the premium tax-credits, which are meant to subsidize or offset the cost of monthly premiums.

The Department of Homeland Security (DHS) was involved for verification of lawful presence in the US under immigration and naturalization laws and the Social Security Administration (SSA) for valid Social Security number, lawful presence in the US by way of marriage or birth, and other sources of income such as disability payments. The list went on to include the Medicare Program, Veterans Administration, Department of Defense, Office of Personnel Management, and the Peace Corps.

 Each agency and program implements Federal laws and regulations relating to security and privacy a little bit differently under a Risk-Based Framework. In addition, there are the state agencies and programs that are also part of the overall ACA ecosystem.
         
         
         

CMS took the lead to create a “common controls catalogue” and a companion “harmonised privacy security framework” so that the different agencies could agree on the overall framework within which they could share data and connect to systems that furnish that data, down to the state level. Those umbrella agreements took about 17 months to negotiate, create and get signed by the agencies’ CIOs.

Converting a 90-day underwriting process to real-time

In the pre-ACA days, the premium you were quoted while purchasing insurance online was subject to change during the underwriting process. ACA provides for "guaranteed issuance" of healthcare coverage, regardless of "pre-existing conditions”.  

Guaranteed issuance served as the imperative to transform the non-real-time business model for the Individual and small employer insurance marketplace into a real time, online experience in applying for, purchasing, and confirming coverage.
         
         
         

The previous model of shopping and purchasing health insurance that had been in place for decades needed to dramatically and swiftly change (months versus years).

Healthcare.gov while in the eyes of many was perceived to be “just a website”, really represented one of the most significant transformations of healthcare access and delivery with a business model that demands consumer-facing transactions of verifying eligibility, evaluating eligibility for premium tax credit assistance, and facilitating the comparison and selection of a health plan with guaranteed issuance and with a concrete price, to all be conducted in real-time.

Mr. Chao said that for properly framing the discussion, we need to look at programmes like Medicare and Medicaid, which have been running for nearly 50 years.  Then we can see that implementation of  Healthcare.gov is not the final destination, but rather a junction in the journey towards improving the health and wellness of a nation.

Effectively, healthcare.gov had to become the centralised booking and reservation system, which guaranteed the issuance of the healthcare coverage at a premium that you will be billed at, once your coverage starts. To do this, the system has to know about all the federal and state insurance availability and conduct tests and checks of eligibility, and move the candidates to the right programme. It was a huge business process change.

This was similar to how you would get a quote for an airline seat say on a travel aggregator website. The price you see is what you pay. All costs have to be known at the time of purchase.

Mr. Chao used the analogy of  Sabre, the booking system used by 425,000 travel agents and 400 airlines keep track of seats sold directly or through third parties. This Sabre system represents an inventory of the supply of all the airline seats.

The insurance companies were bringing in over 1600 different types of products. These products had to be organised and structured. Insurance companies supply the data to the marketplace program and the marketplace renders it with the right premium and the potential premium offsets, if they apply for financial assistance, and then displays the correct output.

Simple and intuitive end-user interface

With all the premiums, co-insurance, co-pays, deductibles, understanding health insurance is not easy under the best of circumstances, for people who have always had insurance.

         Now they were targeting people, who have had little to no contact with insurance. It had to be as easy as possible for them to understand the product. For example, understanding that a high deductible plan might be good if you are young and healthy, because you get a low monthly premium. But if you ride motorcycles, it would be a gamble. If you get into an accident. you might have to pay the first 10,000 out of your pocket.
         
         
         

Acronyms: DSH- Data Services Hub, FFM- Federally-Facilitated Marketplace, QHP-  qualified health plan, OCIIO– Office of Consumer Information and Insurance Oversight

The process of IT design

When the requirements are sketchy and are going to take a long time to be finalised, if ever, it becomes critical to understand how much of the system we need from day one. We had to stagger and to prioritise correctly and find the optimum sequence to develop the capabilities.

Mr. Chao talked about how the initial systems were built on open source but gradually licensed support was brought in. He said, “Up the stack, when you are looking at OS, applications and software, you can start with open source, because of its relatively low cost. But when you are putting a code into production and that production system is supporting critical programs, the debate about open source becomes nonsensical because it is not about whether it is open source or not. It is about whether someone will support it. If it has an issue, will there be someone on site, to work with you to fix it? Is it secure or do you have multiple versions of it being shared by many around the world? Security and supportability are the two key aspects of why open source is not a meaningful topic after you are in production.

We chose Red Hat Enterprise Linux as the OS. We started initially with the open source. But as we started building our environments for development and testing, we needed Red Hat’s enterprise licensing.”

Mr. Chao said that they received a lot of requests asking why didn’t they put the website code out for everybody to use, so that each state could build their own. He cited security concerns. It might have led to hundreds of ghost sites mimicking and trying to take people’s personal information.

Managed service type models were negotiated, rather than direct purchase of various units of software.

The initial launch – What went wrong?

Mr. Chao said, “We had 42 months. But we didn’t have majority of the requirements for eligibility and enrolment till February of 2013, leaving us with 9 months to actually build the system.”

The administration wanted to have an early launch in order to market it. In June 2013, a Beta version of the website was launched. It didn’t have all the application functionality. But you could register, and enter your email to receive updates.

The team which was working on this had to spend a lot of time working on the early launch of the Beta version, rather than the actual launch.

At this early launch, the team could see a lot of application errors. The enterprise identity management system for authentication, including remote identity proofing, did not scale as intended. The estimate was that it would handle around 50,000 concurrent users. But it was beginning to show significantly diminished performance at 4000-6000 users, during the first evening of the rollout.

On the evening of September 30th and early on October 1st, there was huge traffic coming from around the world.

The first step was to register, create an account, be authenticated. That was operating at a fraction of what was intended. In addition, the traffic was one to two hundred times the anticipated numbers.

By the first hour, a sort of waiting room was created for people, until others moved out from inside the applications. It was like the crowds parked outside a store, waiting for it to open on Black Friday. Not everybody actually wanted to shop. Press from around the world wanted to see what this looked like on Day 1. It flooded the network and the website.

By the second week, traffic began to die down and it was mostly from the continental US. But a large number of people were frustrated that they could not get through.

The key was the lack of adequate testing. Mr. Chao elaborated, “In the face of inflexible launch dates and limited resources, testing suffers. Because you are spending all your time, validating changing requirements, coding to those requirements and doing low level tests of those requirements.
         
         
         

You haven’t yet done the integration testing with multiple business partners or volume testing, performance testing, to see how many users can the system handle. You have to wait for a stable code base to do those. If you try to run a performance test and you haven’t got the error handling down correctly, you are chasing multiple problems which makes it much harder to identify where to fix the code.

In essence, you end up testing in production. The first release of the system begins to show you, in live interaction with the users, exactly what’s wrong with the system.”

That’s what happened. By the third month it started getting better. Problems were narrowed down. Multiple instances of the system were built, which could run in parallel at the application level. The team began to learn how to tune and optimise it. 

Lessons – Define the business problem

Mr. Chao said the key lesson was to define the business problem before looking for solutions.

It is important to understand the program, policies, implementation and expected objectives on Day 1 and Day 1000. Jumping to conclusions about databases or application frameworks without knowing anything about the overall program, the information that it collects, the criticality or sensitivity of that data is useless.

 Mr. Chao said that you can have only two of the troika of Time, Scope and Money. You cannot win on all three. For instance, you can’t expect to have no time, less money and increased scope.
         
         
         

Once you understand the business problem, the business people who are driving the schedule can suddenly see that what they are asking for may not be achievable in the given context.

It’s almost prosaic, but this frequently gets cast out of the window, as soon as passionate business or policy people in the room say that it had to be in place by this date and it has to be able to do these things. How you make it happen is somebody else’s problem.

Good leadership in this case means seeing the writing on the wall, admitting the constraints and taking appropriate steps to mitigate them. This would involve a pragmatic approach, continuously managing risks and choose technology solutions appropriate to the problem. 

Henry Chao was the keynote speaker at the OpenGov Leadership Breakfast Dialogue on ‘The Big in Big Data – Managing the unmanageable’ in Singapore on the 10th of November, presented by MarkLogic.