The ACA enrollment site is plagued with usability issues due to architectural and implementation constraints, which are aggravated when there is heavy concurrent usage which ultimately prevents users from creating accounts and enrolling in the program.
Since we already know the website cannot handle high concurrent usage, and a proper resolution ranges from a full architectural redesign to rewriting of major components – none of these issues can be addressed quickly. Taking this approach we are doomed to weeks or months of a long and painful process or iterative defect resolution at the expense of the website’s users. Let’s just acknowledge the limitations of the software as it currently is and work around it.
My Proposal in a Nutshell
- Replace the account creation page with a lightweight version.
- Manage the demand of the Research and Enrollment process by implementing an appointment system.
- Give priority access to users with the greatest need.
- Users would provide minimum input with no validation to get started; appointment hours preference and basic need info such as income and family size.
With my plan, utilization of the heaviest components of research and enrollment would be governed such that the site would never receive more load than it’s known capacity. The users with the greatest need would get enrolled first and they would be guaranteed a good experience without load-related issues. Users who would not be able to signup immediately would have the assurance they are in the system and will have a guaranteed time slot to sign up. Appointments can be rescheduled by the consumer; no harm here since the system will control the demand it can handle.
The Enrollment Process
The enrollment process can be simplified as these general steps take by the consumer at the AHA website.
1. Create an account on the site.
2. Calculate the consumer’s need and ability to pay.
3. Research plans available to this consumer based on input from the user.
4. Enroll in a plan.
A New Enrollment Process
We know we have very high demand to research and enroll into ACA. There are potentially tens of millions of consumers who want to enroll or research ACA insurance plans.
Since the website cannot handle the demand, we need to manage the demand.
My proposal would lighten and manage the demand of the enrollment process.
1) Create an account on the site. “Strip down the account creation process.”
- Replace the current enrollment page with a new simplified account creation page comprised of two steps, the first to validate the email address, the second to create an account using bare bones input. The first new page takes as input only 1 field: email address. The page explains to the user to confirm their email address via an email, which is being sent. This page saves nothing since the email address has not yet been validated. The email address is checked against the database to determine if an account has already been created. An email is sent to the user with a link to the site to validate the email address. If the email address is already in use, redirect the user to the login page. If we find that the volume of new email addresses to be overwhelming, we can always send these to a queue for a paced send via SMTP, but prefer to avoid complexity in this step to minimize load if we can get away with it.
- When the user is redirected to the site to confirm the email address they are given an account creation page where they will enter: password, select income and family size from a dropdown, select appointment time preferences to complete the registration process. Family size and income selections would be based on existing data for these groups with a goal of managing demand. All of these variables can be changed later and there will be no validation of these things at this time. Some users will game the system by inputting values they think will help them get a priority appointment so a warning should be posted that if anything is incorrect, the appointment may be rescheduled. Some users will get away with false info, but so what. We want everyone signed up and they would not do this if they didnt need the insurance. We are going to control the load so no harm to the user experience can occur from this.
2) Calculate the consumer’s need and ability to pay. “By Appointment.”
- The site already has this in place, not too much needs to be changed here. We are going to work around its limitations with an appointment system, accepting the number of users the system can handle. The only thing we change is a users ability to reach this page based on their appointment.
3) Research plans available to this consumer based on input from the user. “By Appointment.”
- Same as 2. Nothing much to change, just need to implement a restriction to use these pages based on their appointment.
4) Enroll in a plan. “By Appointment.”
- Again, not much to do here except to implement a restriction to use these pages based on appointment.
Estimates
The appointment system will require four developers:
1) A developer who knows the database schema.
2) A developer who knows the enrollment code.
3) A developer who is a quick hand at creating new pages.
4) A good services developer familiar with the service implementation currently in use.
5) A Tech Lead who coordinates the efforts of the developers and provides solutions to unexpected issues.
For item 1:
SQL Developer to create appointment tables and CRUD queries. – 4 hours.
Services developer to create a service to implement appointment data access. 8 hours
Quick page developer to create the new lightweight email validation and account creation pages: 8 hours
Enrollment developer to disable existing account creation and enrollment pages and redirect to the new: 4 hours
For items 2-4
Enrollment developer and quick page developer to implement appointment check, base page functionality, into the calculate, research, and enrollment pages: 8 hours each.
This plan can be implemented by an existing Tech Lead or by me. If I do it, the cost will be zero to the government because I will use my volunteer PTO time, 16 hours, to do the job.
Gary Smith
Charlotte, North Carolina
One Smith 