HealthCare.gov Turns Five
A Case Study in Government Digital Services Growing Up
Over the past five years, Ad Hoc has played a critical role in the recovery effort for HealthCare.gov. Our efforts embody the core values we hold today: an emphasis on practicality and a focus on the people impacted by our work. But making lasting change in our government institutions requires a maturity that goes beyond top tech talent and short-term involvement. Government needs a partner that can build and guide the delivery of digital services over the long haul. As we’ve grown up with HealthCare.gov, so has our understanding of what it means to be that partner.
Things We’ve Learned
Since our experience during our initial recovery effort, we’ve learned from our work with CMS (Centers for Medicare and Medicaid Services) how best to organize our teams, refine our tools, and structure our work around the delivery of HealthCare.gov. Our teams are structured to deliver on the vision of helping people get access to care for the long term.
1 - Have a purpose, build teams around the mission
Focusing on the mission means we feel a sense of responsibility for the end-user experience. You don’t hear things like “that’s not our job” from our team. At the end of the day, we feel it is our responsibility to deliver an outstanding experience for citizens, and we’ll do what it takes to get it done.
2 - Stay practical and focus on outcomes
Turning around the initial performance & user experience of HealthCare.gov in a short amount of time required a focus on outcomes and taking the most practical approach to achieving them. Instead of rewriting the entire service, the team focused on replacing the portions of the original system that had the highest impact. This phased approach allowed HealthCare.gov to continue enrolling consumers while reducing the load on problematic components.
We used that same practical, outcome-focused approach when we chose to use commercial services like Amazon Web Services (AWS) for infrastructure, or open source components for building accessible user interfaces. By not over-engineering unnecessarily complex solutions, we could focus on the thing that mattered: making sure people who were enrolling in healthcare had a stable, fast, first-class user experience.
3 - Writing code is only a part of the job
Ad Hoc started out as an engineering team, writing code for a specific section of HealthCare.gov. We’ve learned that it takes more than high-quality, fully-functional code to have a lasting impact on a government digital service.
As we’ve expanded our role in delivering HealthCare.gov, we’ve changed how we work just as much as we’ve changed the technology we use and the user experience. Like Conway’s Law states, the structure of an organization will constrain the services it delivers. Our collaboration with CMS has developed through listening to their product and development leadership. Through better understanding their needs and by suggesting changes to the ways our government customers communicate and work alongside us, we’ve collaborated to build a foundation for better digital services.
We’ve expanded our team of engineers with experts in design, research, and product management. These mission-driven teams work hand-in-hand with CMS product owners, technical leaders, and subject-matter experts to build digital services capabilities and capacity within CMS. Our product teams hold workshops, introduce new processes, and share best practices.
We still build features, scale infrastructure, and ship releases. But we also build expertise, scale team capabilities, and ship best practices across CMS.
4 - Building for the long haul means building beyond our contract
We also learned early on that a strong, integrated team could best address problems across CMS. In 2014, we supported a single tool on HealthCare.gov that improved user experience and reduced load on legacy systems. We now deliver more than 20 applications and tools like:
- Marketplace API for HealthCare.gov plan and coverage data
- CMS Design System, a React-first version of U.S. Web Design System that emphasizes 508 compliance & performance
- Deployer, a tool for deploying AWS AMI based applications
- ThreadCount, shared tooling based on JMeter for performance testing
HealthCare.gov, Medicare.gov, CMS’ Quality Payments Program, along with third-party vendors like Quicken and eHealth Insurance, make use of these tools to deliver modern digital services that are automated, secure, and more efficient.
We operate in a complex, intertwined environment at CMS. We work with other departments, divisions, and contractors on infrastructure, security, testing, and more. By looking at problems holistically across the organization, our solutions can raise the tide for all the digital services CMS delivers.
Seeing ourselves clearly
HealthCare.gov, and Ad Hoc have matured over the last five years: we provide a better user experience to more people in a more stable and secure environment. We build tools and teams. We’ve adapted to what makes government digital services unique by focusing on practical solutions that put people first.
There’s still more work to do. We’ve made it five years into a continuing mission to deliver government digital services people want to use. Now, like any five year old, we can start to dream about what we want to be when we grow up.
So, What’s Next for HealthCare.gov?
Continue to deliver evergreen services
Many see the tools that make up HealthCare.gov ready for O&M mode (operations & maintenance). We think nothing could be further from the truth. We see our applications and tools on HealthCare.gov as the evergreens of digital services; always growing and responding to the changing cultural and technical environment. Meeting people’s needs for critical digital services requires constant improvement. Similar to agile development, continuous improvement reduces the risk and cost compared to orchestrating a “big bang” replacement.
Drive adoption through delight
We’d like to share more and duplicate less while keeping small teams empowered. How can we do that? Typically, uniformity across a portfolio requires a top-down approach: an enterprise architect or CTO dictates, “you have to do it this way.”
We have a different posture: we want to make tools, platforms, and processes so good, teams choose to use them with zeal. We’ve already started to see this with Deployer and CMS Design System, but we see other areas of opportunity to share our expertise. Performance testing, API creation & management, content management, and build tooling all represent areas where we can build tools to make services better. By sharing our expertise in incident management, game days, and security compliance, we can build a solid foundation for digital services across CMS.
Expand our customer’s role in delivering government digital services
We have partnered over the years with a handful of like-minded engineering teams that help us learn new things, and expand the pool of digital services vendors. We’ve expanded our relationship with Corbalt to deliver shared tooling around APIs, container security, and automated certificate rotations that could benefit the entire CMS portfolio. That work will soon provide CMS with significant savings and increased uniformity across the tech stack. Our relationship with Oddball has grown from one or two individuals into full teams working autonomously to deliver vital tools and services on HealthCare.gov. Our goal is not just to solve our own problems, but productize and promote excellent solutions to benefit the entire ecosystem. At the end of the day, it’s about the user experience, regardless of who is helping deliver the code.
Improve security and infrastructure in the marketplace
One of the lessons we’ve learned while working with CMS is that monitoring and automated compliance presents a huge opportunity for government digital services. With the help of leadership at the Department of Web Operations (DWO), our teams have started to ask questions about how we can continue building transparent monitoring systems that allow engineers and leadership alike the ability to transparently judge the efficacy of our tools and sites in real-time. Questions we constantly ask our teams drive our emphasis on serving as good stewards of security:
- How can we share our security easily across teams and across the broader ecosystem?
- How can we ensure that security controls are aligned with truly secure systems?
The answers to these questions are not going to be based off any existing roadmaps. They are the next-level challenges facing a more mature program. We’ve set our teams up to be pioneers in that effort - hiring and training senior engineers and product staff to understand the intricacies of how CMS works and what our customers need in order to remain compliant in monitoring how their systems remain secure. In the near future we also aim to expand upon an operations posture that focuses on efficiency. Trends like containers and serverless apps are a breeze to adopt in the private sector, but their implications for operations and security in government are complex. We’d like to work through those issues to ensure that our infrastructure is outstandingly reliable and cost-efficient. We have been driving the marketplace discussion around best practices in DevOps, security, and infrastructure and we are primed to develop ways to share those best practices across CMS in the near future.
To the next 5, 10, or 50 years!
Given the progress we’ve made so far, and seeing the talent and tools we have in place, I’m confident we can get it done. We feel privileged to work on HealthCare.gov with CMS and the broader marketplace. We’ve come a long way, and we’re excited about what’s next. Here’s to a smooth Open Enrollment this year, and for years to come!