In Part 1 I suggested some reasons there were several simultaneous failures in the establishment of the computer systems supporting the Affordable Care Act including:
- Too many of the implementation leaders were “policy” experts and the implementation of the computer programs required more “operations” expertise instead
- There seemed to be some “latent hostility” towards private insurers by many of the public implementation leaders even though implementation required close cooperation and coordination between public systems and insurer systems (this generated most of the comments I received from readers of Part 1)
- That most of the primary systems contractors were widely known companies (Oracle, IBM, etc.) but that the firms most familiar with computer systems used by major insurers (a small niche in the computer business) were not contracted for this effort and therefore did not have a good understanding of what was needed to integrate multiple systems
- That nearly all involved severely underestimated the complexity of the development and integration of systems – included older “legacy” systems running many Medicaid systems using antiquated hardware and older languages
In Part 2 I want to suggest a further apparent issue that I briefly noted in the first discussion, namely that this generally means that this was a case of a failure to define the challenge or problem correctly.
What do I mean by that assertion? Even now there are frequent comments in the media, by elected officials, by commenters on various social media platforms that this was a ‘botched website’ or several “botched websites”. Many claim that perhaps we should have just asked a firm like Amazon to build a website for the Affordable Care Act instead. My contention is that assuming that this was a simple case of bad website development is exactly why there were so many failures but also why many of the critics of the failures are oversimplifying the problem, too.
Consider if you and I both log on to Amazon today and we are both looking to buy the same item or a similar item. We both will see the same product(s) displayed with the same price tag at the same time. If you or I decide to purchase the item, we provide a means of payment (a card ID) and a shipping address. Now consider if you and I each want to buy a public exchange policy or perhaps we will be directed to Medicaid. But let’s assume you live in Vancouver, Washington and I live in Portland, Oregon – close to each other but across a river and in two different states. We will both need to provide our names and identification, the others in our household and identifications, our age and the ages of each person in the household (or even if our dependent child lives elsewhere), our household income, and then select from entirely different menu choices and different prices. All of these pieces of information are then fed to IRS, Homeland Security, and to the relevant state programs and then we will presumably learn if we will be automatically directed to Medicaid or if we are eligible for a subsidy and what level of subsidy and then we can choose a policy. Amazon does not care where I live, how much money I make, if I am a citizen, my age, if I am married and if I have children and if so, how many and what ages as well as each one’s citizenship status. So while Amazon has developed a fantastic website and incredibly efficient distribution systems – Amazon does not have to obtain all manner of information and wait for other independent systems to filter that information before it can offer me a product and determine how much I will pay Amazon and how much may be paid from another independent source as is the case for those who are subsidy eligible. Amazon’s product availability does not vary because one customer lives in Vancouver, Washington and the other in Portland, Oregon.
Now consider that when you or I buy a product from any retail point of sale website or even from a brick and mortar store, we usually just make a single transaction – we pay one price and we pay the same price if we buy at the same volume at the same time. Now instead we buy an exchange policy = we pay a monthly amount but the policy and the price and the subsidy can change. The price you pay for a similar or nearly identical policy will be entirely different from the price I pay. If I buy a lamp from Amazon and later on I move from say, Bakersfield to Fresno, California (or vice versa) I can take the lamp with me and I don’t need to notify anyone or change the payment or return the lamp for a different lamp. However, if I have a policy from Covered California I am supposed to notify the Covered California system (or any other public exchange system) and if the move has resulted that I am in a different area with different policies and prices – I have to drop the old policy, select a new policy, and pay any differences as a result. In other words, the public exchanges are not at all like a retail ‘point of sale’ system. A similar process occurs as income changes – after I buy a product from Amazon, Amazon could care less if my income changes or if I move or if my household size changes, if I become a parent, get married or divorced – but under the public exchange system all of these events may trigger a change in the policy and coverage, the subsidy level, and the premium.
In other words, the public exchange system is infinitely more complex than a retail point of sale system. This complexity must be understood in order to correctly diagnose the challenge (or problem) and even now many have not understood that the complexity of the challenge is a key reason there were so many failures and why there is still much work to do to build systems capable of managing this complexity.
In a future discussion I will discuss some of the continuing challenges with computer systems that are proving far more difficult than was originally anticipated. I will also address my reference to apparent “latent hostility” towards insurance companies from the leaders of ACA implementation and why that contributed to failures. To be clear, I am no apologist for the insurance industry and hope that readers will not assume this assertion means that I am claiming the public sector leaders are the ‘bad guys’ and the insurers are the ‘good guys’.
So, in summary, the ACA computer system implementation involved far more than a website – it involved a complex and challenging data systems “build and integrate” project. To repeat a tortured analogy from Part 1 – it is as if the original leaders of implementation were anticipating a minor outpatient procedure like removing a bunion when the task was really simultaneous cardiac and neurosurgery.
Patrick Pine is the chief administrative officer for the Robert F. Kennedy Medical Plan and Juan De La Cruz Pension Plan. Both are Taft Hartley benefit trusts that provide benefits to approximately 10,000 to 12,500 employees and dependents. He directs a staff of 15 with a main office in Keene, California. Mr. Pine is a current member of the Southern California Association of Benefit Plan Administrators (SCABPA), the International Foundation of Employee Benefit Plans (IFEBP) and the National Coordinating Committee for Multi-employer Plans (NCCMP). He is a past president of the Oregon Health Care Purchasers Coalition and past president of the Oregon Municipal Finance Officers Association. Mr. Pine has an MBA and BA from Willamette University.
Patrick Pine can be reached at [email protected].
