USDS in action

Steve Kelman digs into the actual mechanics of a U.S. Digital Service team's partnership with a particular agency.

blockchain

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.

X
This website uses cookies to enhance user experience and to analyze performance and traffic on our website. We also share information about your use of our site with our social media, advertising and analytics partners. Learn More / Do Not Sell My Personal Information
Accept Cookies
X
Cookie Preferences Cookie List

Do Not Sell My Personal Information

When you visit our website, we store cookies on your browser to collect information. The information collected might relate to you, your preferences or your device, and is mostly used to make the site work as you expect it to and to provide a more personalized web experience. However, you can choose not to allow certain types of cookies, which may impact your experience of the site and the services we are able to offer. Click on the different category headings to find out more and change our default settings according to your preference. You cannot opt-out of our First Party Strictly Necessary Cookies as they are deployed in order to ensure the proper functioning of our website (such as prompting the cookie banner and remembering your settings, to log into your account, to redirect you when you log out, etc.). For more information about the First and Third Party Cookies used please follow this link.

Allow All Cookies

Manage Consent Preferences

Strictly Necessary Cookies - Always Active

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Sale of Personal Data, Targeting & Social Media Cookies

Under the California Consumer Privacy Act, you have the right to opt-out of the sale of your personal information to third parties. These cookies collect information for analytics and to personalize your experience with targeted ads. You may exercise your right to opt out of the sale of personal information by using this toggle switch. If you opt out we will not be able to offer you personalised ads and will not hand over your personal information to any third parties. Additionally, you may contact our legal department for further clarification about your rights as a California consumer by using this Exercise My Rights link

If you have enabled privacy controls on your browser (such as a plugin), we have to take that as a valid request to opt-out. Therefore we would not be able to track your activity through the web. This may affect our ability to personalize ads according to your preferences.

Targeting cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Social media cookies are set by a range of social media services that we have added to the site to enable you to share our content with your friends and networks. They are capable of tracking your browser across other sites and building up a profile of your interests. This may impact the content and messages you see on other websites you visit. If you do not allow these cookies you may not be able to use or see these sharing tools.

If you want to opt out of all of our lead reports and lists, please submit a privacy request at our Do Not Sell page.

Save Settings
Cookie Preferences Cookie List

Cookie List

A cookie is a small piece of data (text file) that a website – when visited by a user – asks your browser to store on your device in order to remember information about you, such as your language preference or login information. Those cookies are set by us and called first-party cookies. We also use third-party cookies – which are cookies from a domain different than the domain of the website you are visiting – for our advertising and marketing efforts. More specifically, we use cookies and other tracking technologies for the following purposes:

Strictly Necessary Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Functional Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Performance Cookies

We do not allow you to opt-out of our certain cookies, as they are necessary to ensure the proper functioning of our website (such as prompting our cookie banner and remembering your privacy choices) and/or to monitor site performance. These cookies are not used in a way that constitutes a “sale” of your data under the CCPA. You can set your browser to block or alert you about these cookies, but some parts of the site will not work as intended if you do so. You can usually find these settings in the Options or Preferences menu of your browser. Visit www.allaboutcookies.org to learn more.

Sale of Personal Data

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.

Social Media Cookies

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.

Targeting Cookies

We also use cookies to personalize your experience on our websites, including by determining the most relevant content and advertisements to show you, and to monitor site traffic and performance, so that we may improve our websites and your experience. You may opt out of our use of such cookies (and the associated “sale” of your Personal Information) by using this toggle switch. You will still see some advertising, regardless of your selection. Because we do not track you across different devices, browsers and GEMG properties, your selection will take effect only on this browser, this device and this website.