After spending some time trying to shop for insurance for my parents, and facing the same issues everyone has been having, I decided to put on my developer hat and try to figure out how this web application works. Using my browser's developer tools (I use Safari and Chrome) I was able to identify some of the various technical components of the application, and created the info graphic below. I also listened to the entire YouTube video and reviewed the documentation published on the U.S. House, Committee on Energy and Commerce. PPACA Implementation Failures: Didn't Know or Didn't Disclose?, Hearing, which aired on Thursday, October 24, 2013 - 9:00am.
According to the testimony from 4 of the main contractors associated with the Healthcare.gov project, specifically CGI Federal and QSSI/Optum, the "Federally Facilitated Marketplace" or FFM is a complex web application which serves as the face of the Obama Administration's highly touted Affordable Care Act. From my review of the FFM, it appears it has been built using a combination of HTML5 technologies including Twitter's Bootstrap Responsive Framework, jQuery, and Backbone.JS. The site also uses pingdom for monitoring, optimizely for testing and optimization, and virtual server infrastructure provided by Terremark, a Verizon subsidiary. The FFM was developed by CGI Federal under a $293 Million contract from the Centers for Medicare and Medicaid Services (CMS), a branch of the Department of Health and Human Services (HHS).
A key component that was cited as a source of 'bottlenecks' is the Enterprise Identity Management or EIDM, which was developed by Optum/QSSI under a $85 Million contract from CMS as well. In my initial review it was unclear what technologies this system is exactly built on, but it was clear that it has a RESTful API that provides authentication, authorization, and access to FFM and, presumably, other CMS applications. It would've made sense to use this system, especially if it was already in place prior to the development of the FFM, since, presumably, it already has integrations to other systems built, and existing user data. Cheryl Campbell, SVP of CGI Federal, in the aforementioned committee hearing, kept referring to EIDM as "the front door" of the application. However, EIDM appears to be acting more like a AAA gateway and/or proxy, providing secure access to all back-end systems.
Another critical component, and to me, the core of the Healthcare.gov web application, is the "Data Services Hub". This system was also developed by Optum/QSSI, and acts as a transactional-based data integration and web services layer to all the insurers' databases, CMS databases, and Equifax Income Verfication Services' systems. Given some of the error messages that I was able to view during my interaction with Healthcare.gov, I can tell that this system consists of a JBoss Application Server with data access components and RESTful web services developed using Java. Given my prior experience with JBoss and Java, although they are great for middleware development, they're known to be a bit slow.
Finally, CMS has contracted with Serco to process all paper-based applications, which get entered onto the FFM using the same interface as consumers use, sans the account creation process. Presumably, Serco has special accounts in the EIDM. Obviously, if the FFM is not working properly, those paper applications will not be able to get processed.
In closing, I look forward to the prompt resolution of all the bugs and infrastructure issues, and hope that this article provides everyone more clarity onto how Healthcare.gov really works. Please do share your comments on the section below.
This appears to come from the Data Services Hub, which is running on a Jboss AS server. The 500 Internal Server Error was returned from this system, presumably, in response to a REST request from FFM.
It appears that there were issues (possibly) with the Enterprise Identity Management or EIDM, where 500 internal server errors were causing the front-end (Healthcare.gov) not to be able to submit my application.
When a user tries to retrieve the 'Eligibility Results', a new page launches, which fails to load as the "fileIdentified" variable passed on the URL is NULL! Also, the error message is truncated by the page, which appears to be a CSS issue.
Line 18415 of individualApplication.js appears to have an issue with the firstName variable.
Spelling mistakes abound
This was pretty silly... when given the option to 'export' your application, the browser prompts you to save the page as HTML source. It appears as if the development team ran out of time and did not provide a proper PDF export option.
CORRECTION: A previous version of this post claimed Amazon Web Services provided services for Healthcare.gov. Amazon Web Services is not involved with Healthcare.gov.
Follow Eduardo Garcia on Twitter: www.twitter.com/egpierro