USDS in action

In March, the Center for Medicare and Medicaid Services announced a 2.0 release of a capability called Blue Button, which was initially introduced by CMS and the Department of Veterans Affairs in 2010.

(I asked Peter Levin, an old friend from Boston and father of the original system at the VA, where the name came from, and he told me it was originally intended as a placeholder until they could develop a better name, but no better one was developed, and the moniker stuck.)

Oversimplifying -- and this is a post about the U.S. Digital Service and CMS, not about Blue Button -- the first goal of Blue Button at CMS is to provide Medicare recipients with all their Medicare claims data in one place. Prior to Blue Button, such data was either not releasable to individuals at all, or divided among different interventions by many providers.

At a philosophical level, the idea behind this is to empower health care consumers with more information that they can use for greater control over their care; though claims data are not the same as medical records, which are not included in Blue Button, the idea is similar to moves to get patients better access to their medical records. The main change in Blue Button 2.0 is the provision of application programming interfaces (APIs) to third parties, which will allow developers and researchers to develop apps that link treatment data from different sources as a way to provide patients with more information about the success of treatments they are getting and researchers information that can provide new insights about how successful in general different treatments are.

When I read FCW's Blue Button coverage, I reflected on just how little has been written on how USDS works in practice. So I decided that learning a bit more about how Blue Button 2.0 came to be would provide useful information about this (relatively) new feature of the world of government IT.

CMS' parent agency, the Department of Health and Human Services, is one of six with USDS teams -- the others being VA, the General Services Administration, the Small Business Administration, and the Departments of Defense and Homeland Security. USDS put me in touch with Shannon Sartin, executive director of the HHS/CMS Digital Service, informally known as DS@HHS, and we spoke about the genesis of this. (DS@HHS is formally for all of HHS, but most of the team's work to date is for CMS.)

When USDS was formed in 2011, I -- and others -- expressed the fear there would be an inevitable culture clash between young, hoodie-wearing, self-confident (arrogant?) USDS-ers and besuited, older feds. In a blog post from last October, I concluded that somehow this had largely been avoided, and that USDS (and 18F) were becoming part of the federal IT ecosystem. The recent conversation with Sartin gave me better insight into how these relationships work on the ground, how cooperation gets established, and what the division of labor is between USDS teams and feds.

Thinking about a Release 2.0 for Blue Button began about two years ago, not with USDS folks but with career staff in the CMS data analytics office. They even came up with the idea that the big change would be using APIs.

Sartin recalled that her predecessor “had heard” that some in the data analytics office were working on this issue. The problem was that moving the project forward required more than good developers to write code. Two silos within CMS needed to be involved -- not just data analytics but also the CMS communications office that owned MyMedicare.gov, which would provide the login a beneficiary uses to authorize an application to use Blue Button data. The data analytics people had no connections with the communications people, and thus couldn’t move the project forward by themselves.

This was where USDS came in. “We needed attention from a management level above to help the different silos work together,” Sartin said.

As a general matter, she added, USDS must be authorized to get involved. “Typically we want an email we can point back to that says we are authorized to do this," Sartin said. "Once we have that, we can get introduced at a staff meeting.”

Key to this was USDS’ access to top management. “Every agency digital service team in government has a direct or dotted-line relationship to the highest or second-highest person in power,” Sartin explained. At CMS the team reports to the deputy administrator. “People understand when we walk into the room that we have that blessing.”

In this case, CMS Administrator Seema Verma (one of then-President-elect Trump’s first announced political appointees, who ran a health care consulting firm and had earlier worked for then-Gov. Mike Pence in Indiana), took an interest in the project. Verma “identified the potential of this data to drive innovation in the marketplace, value-based care, and tech modernization," Sartin said.

Verma intervened personally to direct a connection, and she gave the project a deadline for announcing the app, a healthcare IT conference in March where she was scheduled to keynote. Certainly the data analytics people welcomed the clout USDS gave them for an effort they had initiated. After Verma’s authorization, cooperation proceeded pretty seamlessly.

Sartin estimates that about 70 percent of in-house work on the project was done by civil servants, and 30 percent by USDS team members. USDS supplied an engineer who mostly worked on architecting the solution, a designer for the front end website, and somebody who knew commercial practices for software product management, including help in prioritizing features to develop.

“We also worked to teach CMS employees how products are built in the private sector, so they can apply these ideas in the future,” she said. In addition, and to my surprise, it turns out that most of the actual coding was done by contractors, not USDS developers. In addition to new code, much of the underlying infrastructure to make Blue Button happen “existed already because of contractors, Sartin noted. The USDS engineer did a bit of code writing and also participated in checking the code.

Most of the work the civil servants did involved dealing with the policy and compliance issues around federal IT development. It is sobering that this was 70 percent of the in-house government work, which seems high. A negative view would be that this shows the large role of non-value-added box-checking imposed on government IT development. A more positive view would be that these issues reflect genuine concerns that add value, and which feds are better at dealing with.

Sartin said there is generally a dialogue between USDS-ers and feds on these policy and compliance issues. “We come in with very particular view of how things should work -- our mindset is like a private-sector startup without the policy and the requirements that you have in government," she said. "We ask how far do we push the envelope on reducing or simplifying these requirements.” (As I listened to her, I thought of the new world Facebook is now entering where the lack of policy and compliance may well become a thing of the past.)

The story of how the collaboration between USDS and CMS emerged for Blue Button reveals only the tip of the iceberg of the ongoing and institutionalized ties between the two. Mina Hsiang, Sartin’s predecessor as head of DS@HHS, notes that “our early work in USDS was fixing things that had gone wrong. But soon we understood that the best medicine is prevention.”

At this point, USDS changed its approach from a SWAT team swooping down into an agency to partners who would work with the agency. Senior CMS political executives helped them get started, including presenting them to the career people. But the real heavy lifting was working one-on-one to establish ties with senior career people in each part of CMS, and to establish a track record of successfully helping folks in the trenches with IT projects. By the time the data analytics people at CMS starting thinking two years ago about using API’s to improve Blue Button, they had strong enough ties to DS@HHS that they requested tutoring on some implementation details for introducing API’s.

There are two ways career people can get requests for help or information to USDS. A request might “bubble up” and make its way to agency leadership, who can then refer it to USDS for followup. “Or a staff person can just shoot me an email, maybe enclosing a document,” Sartin says.

By the end of her time heading DS@HHS, Hsiang reports they got “more requests than we could follow up on.” Under Hsiang, regular meetings with the administrator of CMS were established to go through projects and prioritize. The director of DS@HHS also attends senior CMS staff meetings, which is a good place to gather intelligence about projects they may want to help out with. Finally, as an ultimate sign of bureaucratic respect, DS@HHS is now included in the CMS organizational chart.

To be sure, all this was somewhat easier at CMS than at the other five agencies with a USDS presence, because some on the USDS team had worked earlier on the Healthcare.gov rescue and knew politicals at the agency. Having said that, it appears all six departments with USDS teams have some version of these ongoing ties, though they may take different forms and not be quite as extensive. And it is interesting to note that the relationship between DS@HHS and senior CMS leadership survived the transition to the Trump administration, which certainly had no commitment to the Obama-era Affordable Care Act program or website.

There is an established cliché that feds are attached to their old ways of doing business and resistant to changing. The experience of USDS working with civil servants suggests that this cliché is at best only partly true.

“I don’t think it was challenging” to get civil servant cooperation, Sartin says. “CMS is open to the help -- people are hungry to learn new things so they usually are open to letting us in. But I think people are perhaps less comfortable, maybe more scared or not adequately equipped to change.”

She added that “another thing we do well is to ask uncomfortable questions. People put blinders on, but at USDS we are told to question everything.” Yet even this doesn’t seem to stymie cooperation.” Sartin estimates that half the joint projects between USDS teams and civil servants are initiated by USDS contacting civil servants, half by civil servants contacting USDS. (For initiatives involving citizen-facing applications, the civil servants tend to initiate contact with USDS, for other technologies such as infrastructure, it is USDS.)

My takeaway from the development of Blue Button 2.0 is that at this point USDS is not only present at CMS, but fully embedded there. This is an outcome few would have predicted when the organization started. At least at the agencies where it is active, this is good news for federal IT.