Empowering Healthcare Access: How the US Digital Service at CMS is Shaping Policies and Creating an Equitable Digital Future

This transcript was generated by AI and may contain typos and inaccuracies.

Amie Vaccaro: Welcome to High Impact Growth, a podcast from Dimagi about the role of technology in creating a world where everyone has access to the services they need to thrive. I'm Sarah Strauss, Senior Manager of Revenue Marketing at Dimagi. Your co-host, Amie Vaccaro, Dimagi's Senior Director of Global Marketing and Jonathan Jackson, CEO and Co-Founder, are joined by chief theme leaders at the Digital Service at CMS, Andrea Fletcher, Chief Digital Strategy Officer and Remy DeCausemaker, Open Source Lead.

The Digital Service at CMS, which stands for the Center for Medicare and Medicaid Service, exists to improve how people interact with healthcare in America. In today's episode, you'll get to hear real and honest perspectives on the challenges, strategies and innovations shaping the future of US healthcare through digital transformation and open source initiatives. We hope you enjoy it. Welcome to High Impact Growth. So I am super excited for today's conversation. We are joined by Andrea Fletcher and Remy DeCausemaker, as well as my co-host, Jonathan Jackson.

Hey, everyone. Hi, Amie. Hi. Hey, how's it going? Good. So today we are talking about the role of digital technology in the context of the US government, and in particular, Medicare and Medicaid. But first, let's do a couple of intros. So start with you, Andrea. Andrea, you are the Chief Digital Strategy Officer and Director of the Digital Service at Centers for Medicare and Medicaid Services. Correct me if I'm wrong on that. It's a mouthful. It's a big title. It sounds like a really big job.

And I know you have a history of having worked at DeMaggie, which is how we found you. Tell us, how did you get into this work and what do you do? Yeah. After graduate school, I landed at Dimagi in what was back then a fellowship. I did a master's in public health and I was kind of looking for something mostly in sub-Saharan Africa. And so that's where I ended up. So I helped kind of stand up the Cape Town office and did a lot of early work around building apps with frontline healthcare workers in sub-Saharan Africa.

I remember building like CommCare apps on Java phone. Back in the day, that's how old I am. That's how I think about it. But really, I learned a ton during that time on how to design with users, how to just figure out what the actual problem is and really digitizing a process and build really great technology solutions. So I think I spent four or five years at Dimagi. And then I moved over to another firm called Cooper Smith, still in the international development space, really working with governments more on the policy side of things and like national level strategic planning for technology.

So what does it look like and what does it take to roll out demographic health information system 2 or DHIS 2 to multiple districts or states and subnational levels? What kind of policy do you need in place to do that? So collecting mobile healthcare data on mobile technology is you want to do it secure. You want to make sure that the data is being stored properly and you're complying with all rules and regulations. But it was really tricky back then because a lot of these laws just didn't exist.

So it's kind of helping out some of that work. And then in 2021, I flipped over to the domestic side and I joined the US Digital Service. So the US Digital Service is at the White House. It's a team of technologists in the US government. I have a background in healthcare, so I got sent over to Medicare and Medicaid because it is 12 percent of the federal budget and a behemoth in the healthcare system. And so that's where I've been for the last two years. I just became the chief digital strategy officer.

I've been leading and growing a team within CMS and just building out the US healthcare system's ability to have really great technologists in-house. And I guess I didn't hire you Remy, but we got Remy on about a year ago because we started really thinking more about open source software domestically and what that looks like. Thank you Andrea. That's awesome. And I'm sure all of that is due to your brilliant career here at Dimagi. Yes. But Remy, as somebody who cannot attribute all their success to Dimagi, I'm curious to get your background and what led you into the current role.

Sure. So my name is Remy DeCausemaker and I help contributors work together to use their powers for good. I've been doing this in my professional career for the whole thing. Prior to joining the digital service at CMS about a year ago as the new open source lead and helping to stand up the federal government's first open source program office, which we're currently working on launching, I was formerly the head of open source at places like Twitter for a few years, Spotify after that.

I sat on the open source program office team over at Red Hat for a spell. I helped to found the open source program office at Rochester Institute of Technology, where we launched the first academic minor in open source at an undergraduate university in the United States. Before that I had a civic tech startup. So that's sort of where I got a lot of my sort of roots in doing this type of work. And you know, I've worked in nonprofits, do-gooder stuff, academia, for-profit, Silicon Valley, and now the federal government.

But the common thread between all of it is open source. How do we help people share? How do we help people work together? And how do we work together to solve some of the hardest problems facing the planet today? Awesome. Well, thank you for that background. I'm really excited to have this discussion here today. I think one of the big questions that our audience might have is like, why are we focused on the US? It's high income. It's got money pouring inefficiently in the healthcare system.

Like how does this apply to global health? And I think the lessons that I want to talk to you about how CMS, which is a massive organization within the US government, has thought about the potential of technology, which is obviously huge. All governments recognize digital can make a massive impact on value for money, on engaging their citizens and their constituencies. And yet it's incredibly difficult for governments to figure out structures, approaches, ways to meaningfully, safely, securely deploy technologies, partner with the private sector when appropriate, build it in-house when appropriate.

So we've all seen the headlines of many government failures in all income settings of tech companies. Technology. So at a high level, I'd love to just kind of level set, you know, what has the journey been with the US digital service in the US government and then specifically within CMS and at a high level, what problem was it trying to fix? Right. Because this is a problem faced by many governments outside the US as well. Okay. I'll talk about CMS first and then kind of how our team at USDS got started a bit because it involves CMS.

The CMS is multiple centers and it's $1.7 trillion is our budget. We oversee the entire health care system in many different ways. But our three major centers are Medicare. So people who are over 65 generally. There's about 64 million people enrolled in Medicare right now. Medicaid, which is poverty, like people below the poverty line or at a certain percentage of the poverty line in the US. It's our social safety net program for health care here. It's administered by the states.

Right now, it's at about 88 million people. That's very high because of the COVID pandemic. And then the third major program that we run is the marketplace or healthcare.gov. And this is part of the Affordable Care Act. And this is about 34 million people sign up for health insurance plans to the marketplace every year. I'm not going to go into explaining the complexity of the US health care system and insurance system, but we generally provide health care insurance for about half of the country.

Healthcare is also really instrumental in instituting health care prices in the US and in general, we're in charge of quality of care. We're in charge of fraud, waste and abuse around Medicare. So there's a lot we have a lot of other centers and programs that come into play. I think why CMS has a really interesting story in all of this in technology, in particular in health care, it actually goes back to when I was at Dimagi in 2014. You know, Barack Obama, the Affordable Care Act passes and they have to set up a website, healthcare.gov.

And you know, they're thinking millions of people are going to apply on day one and six people made it through the website or somewhere around there. Very few people on day one were able to sign up for insurance. And there were many reasons as to why this happened. You can go back to how the government, you know, contracts out for building websites. You can go back to the technical talent that was available. The fact that the timelines were maybe a little bit ridiculous. I do remember this vividly.

Yeah, there was a huge news story. It was all over the news and maybe doing a Big Bang launch of a website where like the president is talking about it is not the greatest idea either. So, you know, the launch effort was rocky. I think it's pretty well acknowledged that the launch did not go as smoothly as it could have. And at that time, there were other people within the federal government who were kind of thinking about in-house technologists and how we build technology in the federal government and how we deploy websites and kind of starting to look at, you know, like Todd Park was in the administration at that time.

Jen Pahlka, who just wrote a book about all of that, Recoding America, really thinking about how do we do better technology? Like how do we build better technology? So out of that springs the U.S. Digital Service. USDS has kind of always had a team at CMS. We've worked on several really large projects, in particular, the quality payment program and the Blue Button 2.0, which is a really interesting endeavor that I'll let Remy talk a little bit more about because he's more familiar with it, which is actually how our team really got started in that open source space, like trying to see how do we not just build better technology within the U.S. government, but between the government and the health care system at large?

How are we working together? Because what we often see is that we pass a law or a policy and then everyone in the health care sector in the U.S., which is about a sixth of the economy, it's a lot, it's a very large space. They don't scramble to comply with our laws or our policy. And often that creates new technology that we shouldn't have created or it creates problems with our systems because, you know, we have some new policy that everyone has to comply with. So, Remy, I don't know, do you want to chat a little bit more about Blue Button 2.0 and some of the projects that you've seen at CMS that have been really interesting to you?

Sure. So, if you go to developer.cms.gov, you can see a variety of the open APIs and projects and design systems and clients that all sort of serve developers and end users and third parties who want to have access. And Blue Button is one of those APIs. It's a standards-based API that delivers Medicare Part A, B, and D data on over 60 million people with Medicare. It is something that was launched by, I believe, USDS back in the day and has since sort of gone through a few iterations where the first iteration was sort of like, let's just get the data to you in a human readable format.

It was mostly PDFs and is now delivering, you know, more of a developer experience where you actually get the results in machine readable formats and you can do things with them and create apps and third-party developers can use them for a variety of things. I believe that things like the Apple Health app, if you will, can access some of that data. A lot of these CMS APIs are being used now as sort of the pipeline for getting data in and out of our systems and Blue Button is maybe one of the most famous or popular ones.

We sometimes say that it's potentially, you know, the most widely used FHIR API in the federal government, citation needed, but is a good example of the scope and impact of where open development can really make a difference. That's great. And for those listening, a FHIR API is not a way to start a fire. It's FHIR, which is a Popular Health Data Interchange. And around that, Remy, and the work that we've done to unlock data that the government has on behalf of its citizens. And Andrea, something you mentioned around the gap between technology implementation and the policy or strategy that was set.

So our view right now in many markets, the US, where we're operating globally, there's great policy happening. It's a really good strategy. The potential of technology, the need to be more provider centric, more patient centric, just all these great ideas. And then when the rubber meets the road, it is really hard to pull off these projects. Not necessarily like software developer hard, like you could write the code, but like just the logistics. How are we getting data from this legal organization over to the government or back?

Or how is the citizen accessing their records in order to go do the next step? And so, Remy, the success of Blue Button, as you're talking about, looking at some of the other projects on the website you mentioned, these are great. But I imagine there was a lot of wrangling behind the scenes that caused these things to be possible. And Andrea, I know that's a big part of your role now. So talk to us about how do we do this? So we've got the vision, we've got the policy. We know the potential of open source.

We know the potential of technology. But we're a government that's not used to doing this or that actively gets in our own way due to procurement rules or contracting, et cetera. How have we gone about trying to solve this with the U.S. government? And what's worked and what do we still need to crack? Yeah, that's a really interesting question. I think one thing that our team is kind of demonstrating is that you need capacity. You need people who understand the technology and you need what we call bureaucracy hackers or bureaucracy navigators.

Public lawyers are some of my favorite people to hire because they'll look through the government rules and regulations and say, OK, actually, this is the thing that we need to follow. We could go change this thing or here's where we have wiggle room. And the other thing that we have found that has been really helpful is putting technologists in the room when we're writing the policy, because I'll give you an example. CMS will write a policy that says machine readable format.

We want everyone to submit this in a machine readable format. Well, that could be many things. And so really working then on sub-regulatory processes or guidance or having our team kind of say, OK, this is what this is actually going to look like and working with the people who have to comply with that policy, working with clinics and health care providers, insurance companies, whoever it is, actually talking to them to see if it makes sense to them, working with them on building prototypes and demos rather than just pushing out a policy and like hoping we say demos over memo or demos and memo, but like just build the thing, see if it works and then really craft your policy and how you're doing things around that.

And that's been I think one of the biggest things that I've seen is just like the value of a demo or pilot. We used to do this all the time at Dimagi. We would just go build it, just go build an app, see what happens. And really just using that as a way to show the value of what you're delivering. I love that demo over memo or demo and memo. And I'm curious that this resonates. One of the big challenges I think federal and state have in the U.S. and elsewhere is like you're often faced with the decision by a technology company like Dimagi or internal staff and whatnot saying, I think we could do this big, amazing outcome if you protect my time.

Let me drop my day job. We could do this really hard thing. And you're asking stakeholders to make some very risky decisions. Whereas if you can come in and be like, look at this demo, you should have confidence I can take this demo and then go do those things I said with a lot lower risk than much of the website that falls over on day one. And so I think one of the challenges is how do we create that space for talented people both on the policy side and the program side and on the engineering side to be given the room to run to say, you know, give me six months to bake this so I can come back to you and I'll have de-risked half of the challenge here in making this decision.

Because when you're faced with should we go build a national scale community health system or should we go build a national provider directory, that's a big risk on both can you even pull off the initial thing and then like all the downstream benefits you think are going to happen in the ecosystem may or may not come to fruition. So how has CMS, how do you think about the ways to appropriate? And then obviously you can't be like, I need two years to go think like that's not going to work either.

So yeah, I need two years and a half billion dollars is what it seems to be. Exactly. I feel like how do you create that space for your team, for your staff, for members of CMS or within the digital service and find that right balance of like, yes, let's go build the stem and let's bake it part of the way there. Then obviously this needs like appropriate prioritization discussions. But I find that so hard because there's so little time and head space. People who really deeply understand these problems can dedicate to working with the technologists to be like, hey, can we like be confident this will work and then I can go take it to my boss and be like, yeah, like I'm pretty sure this thing is possible.

Yeah. I mean, the first challenge that at least in the federal context is authority to operate. A lot of folks really want to know sort of like, are we allowed to do this? And the answer is yes. There have been a variety of executive orders and policies that have hit the books over the last 20 years. One that comes to mind immediately is M1616, which is executive order on the agency open government plans that came out. The White House and the administration came forward and said, let there be open source.

And they came out with some pilots that said like 20% of your code should be released openly. Code.gov is a place where we're going to track metadata around these repositories. You have permission, you have authority to do this stuff. So that's a first challenge. And then the second challenge, as you're saying, is like the safety around it. Is this taking away from my other duties or how are we going to balance a need to share things with a need to get things done? And that is a classic problem in every engineering organization.

It's not just the open source ones. It's building things versus building the communities that build things. The sharpening the saw problem, right? Like are you going to cut the trees or are you going to sharpen the saw? One takes more time and it makes cutting the trees easier. So I think the important thing is sort of demonstrating the value, like has been said, and iterative development and picking and choosing your battles. A lot of times open source is not just this, everything needs to be open all the time constantly, right?

Like there are definitely areas where for security reasons, for contracting reasons, for privacy reasons, there are certain aspects of every project or organization that should remain private and understanding that and being intentional about where the risks really are helps you understand where the value really is. Like a lot of organizations need the kind of guidance that comes from an open source program because you help them figure out where the easy stuff is and where the hard stuff is.

So you go to the lawyers and you start by listening. That's one of our values in GreenSack is you listen first, find out where the problems are. So what are the things that keep the lawyers up at night? What are the things that keep the engineering stakeholders up at night? What are the things that keep the business stakeholders up at night? And you come up with a holistic strategy that sort of threads that needle and says like, okay, you're concerned that PHI and PII are like, we can never leak.

Great. Okay. Anything that deals with that over here. But over here is the front end and everybody gets access to the front end. It's a copy of the code goes into the browser for every single person who visits. Maybe instead of doing full review for every single thing that comes through, we can just say, if it's got PII, put it into the hard bucket. And if it's front end, put it in the easy bucket because that's code that everyone's going to have anyway. And once you start compartmentalizing the risk and being intentional about the strategy, you can start to show people and say, hey, look, by releasing the US web design system, everybody gets the same official government look and feel.

It gets a baseline 508 compliance and we can ship things a lot faster and you don't have to have contractors working on reinventing the wheel. You don't have to worry about websites looking and feeling different, operating differently. We can move faster and integrate across lots of units. And that kind of value demonstration builds more trust. You can work in the open more and you can sort of build on that momentum. So that's sort of a three pronged approach. You got to have the policy.

You got to decide where the risks are by listening and then you got to demonstrate value so that people can have buy in and it grows. Yeah. When you asked that, Jon, I was thinking a lot about how our team operates running discovery sprints. So somebody will come to us with a problem like, hey, this system over here is really important to this thing that we're trying to do. Can you take a look at it or, you know, could you build this thing for us? And we put a multidisciplinary team on it.

Usually it's three people. So a designer, a product manager and an engineer. And we basically say, here's your problem statement. Like come back in a couple of weeks with some options. Right. And we spend a lot of time, most of that time is spent building trust and getting to know the people who are the subject matter experts who've been working on this thing for 20 years because they know where the real problems are. And so really kind of taking a different approach to how you're solving your technology problems because 90 percent of the time we do these and the problem is not technical at all.

Right. It's a process problem. It's a people problem. It has nothing to do. Like the technology is a very simple fix or a simple solution. And really what we have to do is get the stakeholders aligned to make the fix that they need to make. But nobody has taken the time or effort to do that. Maybe sometimes the stakeholders are a little challenging or, you know, there's all kinds of fun reasons why that doesn't happen. But really, Reddy can attest to this. We've had projects where the biggest thing that we've done is get the right people in the room talking once a week and just getting them in the same room ends up moving the problem forward, you know, by a decade because they just haven't been talking to each other.

That's such an interesting process, Andrea. And I love that like the discovery sprint idea with these three people that kind of go off and then come back and build trust with the people. And I think that's a theme we come to a lot on this podcast around how technology is one piece of the puzzle, but the people in the processes are also really essential and sometimes way harder. So I'm curious, stepping back a little bit, you've spoken to a number of projects and initiatives within the digital service, within CMS, but I want to hear a bit more like at the highest level, what is your North Star?

Like what are you headed towards? And maybe within that, are there a few examples you want to give us of maybe discovery sprints that have turned into something or some successes that you want to speak to? Oh, man, what is our North Star? Like healthcare that is easy for people to navigate and equitable. I think the U.S. healthcare system right now in particular is very tricky for people to be able to find what they need and understand what's happening. So we've worked on everything from medical billing.

So we've launched a new website called CMS.gov slash medical rights. So people understand when they get a medical bill, they know what their rights are to negotiate or to get help. And then we've done a lot of work around behavioral health as well. We worked with SAMHSA, the Substance Abuse and Mental Health Services Administration on our website, say, CodeFindSupport.gov. Again on how do we help people navigate all of the different options that are out there and find the care that they need.

So we've taken a really kind of public and individual perspective on, you know, I'm a person in the U.S. who needs help. How do I get it? Where am I going? What are my options online? Is it available in Spanish or other languages? Is it accessible if I'm using a screen reader? Is that form in a PDF? Because it was like, you know, how am I getting these services online? So really a service delivery and service design kind of perspective or customer experience perspective.

And then on the other hand, one of the things that I hope is that we kind of leave the next generation of federal employees with better systems because the internal system are often, you know, they're wild. Some of them, we still have COBOL and mainframes at CMS. I've heard of teams that have Fortran still. And then, you know, you hear somebody head and you get excited and we're like, oh, here's the COBOL. The really like upgrading... The recruitment killer there. Yeah. But like really upgrading our systems and building more modern and better tech stacks so that way the next generation who comes in and wants to implement some really cool thing in the health care system, like that they have a fighting chance.

They don't have to go deal with all the tech debt. So I think a lot of what our team has been doing is really just focusing on modernizing systems, modernizing how we contract, modernizing how we hire to really try to get us out of the 1970s in some cases into today. And I saw this when I worked abroad. Like there were many countries where they were kind of still stuck in the past in some ways and we're fighting to get to the here and now. I think it's a lot different when you didn't have the tech debt that we have because the US healthcare system has had technology in place since the 1960s in the case of Medicare.

So there are things that we go look at it and it's like, oh, this hasn't been updated in 20 years. Wow. And Andrea, building on what you just said of comparing systems that you saw internationally with the US, what have been some of the differences in terms of how digital health is being approached and some of the different challenges that you see thinking about your work globally versus your work in the US? One of the main reasons why Remy and myself and a few other people have been going really hard after open source is seeing how internationally countries were able to leapfrog and how they were able to deploy better software cheaper, faster because they were working together.

And I've seen it personally where we didn't have to develop that app because Tanzania had already built it. Or we didn't have to do that module for COVID because somebody else had already built it and we were able to just grab it and tweak a few things and deploy it. And it's a really smart way of kind of working across multiple jurisdictions or states or countries to leverage the work that other people have done. And in the US, that's just not how things are done. It's very territorial and proprietary.

And there's a vision of the future, which is like, hey, we're all working together and building really cool stuff and useful software in a more collaborative manner than we currently do. When we entered the US market in a deeper way at the start of COVID, it was amazingly one of the parallels from our global health work and how certain people were on that trajectory that you mentioned, Andrea, of like, yeah, like obviously open source adds all this value and it's going to be better, faster, cheaper.

And you can have a community in this stuff. And then kind of some more legacy mindsets of like, who's going to implement this? And like, I need a single firm that I can yell at. And it's like, yeah, but if you pay that firm a ton of money, you're not going to get much value for it. So I think the thing that's been surprising to me too is like from an administration standpoint and the relationship between hierarchies in the government, whether that's national to district, province, et cetera, or in the US case, federal, the state, I've been surprised just how common it is that it turns out telling people what to do at lower levels of jurisdictions is not always welcome with open arms.

Most of the time it's not welcome at all. And it's been funny because I forget this most of the times when we're like, oh, we got national buy-in or we got state level buy-in and then the city's like, great, don't talk to me. Like, we're okay. We're doing our own thing. And I'm sure, Andrea, from your policy and right me on the open source side, like, how do you think about being the federal government trying to do this big transformation, having such a deep partnership with the states where they do have autonomy on one of the three things you mentioned, not on the other two.

And so sometimes you can tell them what to do. Sometimes you're asking them, will they do this? It's a very complex thing. And that's completely the same in global health. You have very complex relationships between local jurisdictions and the state or federal government or province. And this is really hard to make technology work under that incredibly complex ecosystem of constraints. So how do you think about adoption? When are you kind of coming up with a strategy that forces the issue versus kind of let people opt in to doing it?

But just talk us through it because it's such a complicated space to navigate. And software providers in particular, I think a lot of them find it so complicated, they're just like, I can't operate. This is too hard for me to try to navigate. I want to go work in a more rational, sane market where I have a buyer who has authority and I can sell. I mean, I can speak more to the software development policy side of things. And generally, like friction is the enemy, right? Like I'm more of a carrots over sticks kind of person in life in general, but particularly in helping people, you really need to demonstrate the value and have it be a pull instead of a push where you say, hey, we can't tell you that you should use these open standards, but if you use this open standard, here are these client libraries, here's this community, here are all of these people who are waiting to help you do that implementation.

And so instead of it being like a, you must do this, it is like, if you do this, then there are all of these benefits that come with it and you're not alone. And also like, there's a lot of power in not being alone in the community of people around you. I think that's the thing that a lot of people get caught up in the value of software is they think about it like the artifact itself is where the value lies. And that's where the exclusivist view of property rights is sort of like, yep, this is my IP and that's where the value lives.

But really, that's like thinking about the value is in the golden eggs instead of the flock of geese. Software is stagnant and it doesn't change and people do. And if you are a part of something that can move and grow and change with the times, then you are more likely to stay abreast of changes. You're more likely to be able to collaborate, find your collaborators that are going to help you with your digital transformation and use the latest and greatest tools. So for me, anywhere where I can automate something that was manual before is the first place that I think of.

If it's a job that takes someone hours a day or hours out of their week to do, the moment you can replace that with automated tooling or a script is the moment that their eyes light up and they're like, cool, I'm on board. So find the hard problems that really computers are good at solving because as we said, technology is not always the number one solution. So places where we can use it and it makes sense, you use that as a lever to help people get buy-in and demonstrate value immediately and have them decide they want to opt in.

And generally that is a lot more successful than saying, you must do this, you shall do that. And in open source, this isn't a strange way of posing the question at all to me because all day they call us cat wranglers, right? Nobody is here because you pay them. Nobody is here because you have the authority over them. In a volunteer driven world, this is how you get work done is by doing the work, demonstrating value and people come along with you based on the meritocracy, which can be a loaded term but as long as you're doing it openly and transparency, equity and inclusion can be a part of that strategy too.

So lead by example and provide value and people will follow. If the federal government or the national level struggles to hire technical talent, then the districts and the states or subnational levels, they really struggle. Let's talk about Medicaid for a minute. Like a lot of those states are contracting out the majority of their work because they don't have the ability to hire and retain full technical teams. They can't hire 10 or 20 engineers to work on a project and keep them there.

The pay rates are too low. People don't necessarily want to work in state and local government because there are higher paying jobs out there. I've seen this both internationally and domestically where we struggle to maintain technical talent. So when I think about how to do this better is building communities and building the capacity of those teams is because that's the only way that it left, right? Is if we get better capacity at the local level to deliver these systems and if the national level can provide some of that support through reference implementations or changing our compliance in certain ways.

A lot of systems in the US are built just to be in compliance with CMS, right? Well, what if we change how often we're auditing them or how we're doing compliance to make it easier for them and incentivize them to use some of these different tools that might be a better option in the long run? So we're looking into some of those different things. I think there's a lot of potential. It's just not Medicaid. It's the public health systems. It's the state survey agencies who are doing quality assurance.

And it's not just in the health care system. It's across government. Unemployment insurance in the US gets a lot of press on how do we do this better? How do we do this differently? How do we rethink the model of state and local government to federal where we're building once and reusing many and rather than this like everything is super bespoke. Every system is different and special, but they're all solving pretty much the same problems. And I think the pandemic in particular has really kind of demonstrated why the current model is not working, right?

When the system is stressed, all of these things break. And I'm sure you guys saw quite a bit of that when you were working at the state level. Yeah, we definitely did. The point that you're bringing up around build once, use many, building these communities and maybe your point around that community allows you to grow from that initial problem statement. I think this is something we do a ton of advocacy around in all of our projects is no matter how well defined the problem statement is today, it's definitely changing tomorrow.

And you want to solve not just for the problem you have today, but to lay the foundation. And that foundation is one part technical, one part process, one part people and 15 parts a lot of things I'm not even naming. But solving the problem is like building the engine that continues to change, that continues to provide more impact, that continues to provide more value rather than building to a static set of requirements. So it's even more important to have that mindset of, yes, I'm solving this one problem right now with an acknowledgement that this problem is definitely changing tomorrow.

And I have four more problems I need to figure out how to solve as soon as I'm done with this one. And so that requires taking a community driven approach, an open approach, whether or not it's open source is a strategic question on any given project. We all know this problem gets harder tomorrow. So like solving just for today is wildly insufficient to actually make any impact here. Unless we're building for the long run, we're all kidding ourselves about the potential here.

I think the hard part, too, is like sometimes we don't, we can't even dream of what the problem of tomorrow is. Right. Like we have no idea what's coming and we have to try to prepare for it. And I would say right now, a lot of government services are not prepared for the future, at least in the U.S. We're still stuck in the past in many ways. And so it's like dealing with your technical debt while trying to prepare for the next generation of problems that are coming at you. It's a we have a really fun job.

Yeah. So this is so fascinating. And I'm taking furious notes here. Could you say a little bit more, Andrea, about like what were some of the things that you saw go wrong during covid? And then I also would love to like dig in more on how you're thinking about that build once we use many approach. Right. And that's something we also see mirrored globally. Right. Where there's just all these standalone applications for one particular use case. And so there's the covid response, which we could talk about for probably multiple days on like all of the things that went wrong there.

A lot of that, it seemed to be with the flow of information, the flow of data, the flow of public information, getting having people trust what they're hearing and understand what they're being told to do or how to react. Why? Because just the flow of information throughout the public health care system was a bit of a mess in general, not just in the US. Internationally, I would say a lot of countries didn't get that right for many reasons. And then what's happening now is also interesting, which is, OK, we went into a national public health emergency.

And then how do you come out of something like covid or an Ebola response or SARS or whatever you're in? Is you have shocked the system and you put in a bunch of things in place that you have to try to undo and undoing things is almost sometimes harder. I think we're seeing that right now with the public health emergency unwinding in the US where we're trying to kind of back out of some of these rules that were made and things that were put in place. And it is not smooth at all.

In fact, it's a really difficult process. And everyone thinks like, oh, you know, you just end it and everything is over. And that's not the way that it works at all. In fact, we're dealing with, I would say, multiple crises post public health emergency, whether it's workforce or people being uninsured, losing health care insurance and lots and lots of challenges just because we've had this huge shock to the system. So there's the initial response. But then there's also the recovery efforts that I think get really overlooked and are maybe even sometimes a bigger problem to try to solve.

And just to jump in really quick, one of the good stories that came out of that challenge that we faced was the Office of Science and Technology Policy out of the White House last year released some guidance to agencies encouraging them that any results of taxpayer supported research needs to immediately be available to the American public at no cost and gave a deadline of December 31st, 2025 for agencies to update their policies. So from that emergency, it was clear that the information sharing was really important and that we needed to make changes so that more people could work together and coordinate.

And this is a good example of the lemonade out of the lemons where a crisis is still an opportunity for us to improve and learn from and make things a little bit easier for everyone. Crises are obviously terrible in the impact they have on governments and providers and citizens, but they allow you to cut through bureaucracy in a way that wasn't available pre-crisis and won't be available post-crisis and tend to come along with a lot more funding for technology. So using that moment of crisis from a strategic standpoint to not only solve the immediate problem that's in front of us, but to recognize like, okay, there's a moment here where we can prove value on possibly a new way to do things that we can create a lot of direct impact on our solutions.

But also we need to know the default plan is for this to revert back at some point in the future. How are we going to survive that reversion to the status quo? And that is something that I think during the public health crisis, it was interesting because from a global health community, you know, we have a team that goes into all these crisis areas and supports our partners, whether it's Ebola or SARS. And when COVID happened, it was so big that I think there was this initial brief optimism that the global community was like, finally going to do it right for once.

And like there was going to be open data sharing and, you know, everybody's like, not every time. And like, I remember there's like that one month, you know, that one month in March or April, but obviously it didn't play out that way. And then the same thing that always happens happen, which was some pockets of really great projects, but a lot of ineffective spending, a lot of fighting against their bureaucracy. And then to Andrea's point, unwinding this. And in our crisis response work and humanitarian response, we always talk about like in the moment, it's almost too late to do much about it.

Like you needed to have created your community two years ago. So that when the unknown happened, you were ready. You had the trust. You had the team to go tackle this because in the moment of crisis, it's often too late to start. And this is why open knowledge, open science are so important for me in this regard is that you can't put that genie back in the bottle, right? Like once it's out there and that knowledge is free and people can have it, everyone gets to benefit from it.

So all along the way, the more that we can share, even if some of our bureaucratic processes or some of our infrastructure, you know, even if things sort of try to roll back, at the very least, some of the products, some of the outputs, some of the inputs, some of the things that go into that engine, we at least know where it came from or where it could go. And that's a key win and a key strategy to helping move things along. When we think about like the OSI model from the transport layer and the data layer and all of that, like the unsaid layers are like the political layer, the financial layer, the legal layer.

And, you know, I as a hacker, you know, believe that we can figure out how to share more of that stuff the same way that we share TCP IP. And that's going to help us to really prevent or break the habit, if you will, of wanting to go back to some of the other inefficient ways of doing work or some of the ways that are more privately beneficial to certain parties and not publicly beneficial to everyone, especially with some of the biggest problems like a global pandemic. So in our last couple of minutes here together, I'm curious to hear from both of you looking ahead at the future.

What are you excited about? What are you worried about? Possibly sprinkle in there. How are you thinking about AI, which obviously is all the rage these days? Speaking of ways to prevent bad things from happening, AI models are a great example of if you have the source code, then you can better understand what's going on. And I think that right now, at least a lot of the best tools in that area are open source and are based on open source libraries. And there is a culture of sharing around it.

Much like any cultural phenomenon, you know, the subject to change is not a given. But at the moment, I think that the value of data scientists, they understand that if the tools that build this thing are beneficial and moving quickly because they're open, then the models should also be open and the weights and the algorithms and all of this sort of algorithmic transparency. CMS actually has our own AI policy. HHS has an AI policy. The White House this year released an AI bill of rights.

So there's a ton of sort of heat and light around this issue right now. I'm excited about privacy enhancing technology. So there's open source projects like openmind.org. M-I-N-E-D.org. Where they're doing like federated data science, where data sharing can happen with homomorphic encryption on both sides and you don't actually have to share the data. You can actually just encrypt the queries and encrypt the data and do the processing. And it sidesteps a lot of the gremlins, if you will, or monsters under the bed that people have around data sharing.

So hopefully that can unlock a lot. And again, all that tech is very much open source as well. So I will stop there and let Andrea get in here in the end. Yeah. I get really excited about the people who are coming into government and we have some amazing people already here. There's some really stellar talent in the federal government around technology right now. Remy and I have had a lot of success in hiring digital core fellows and coding it forward fellows like interns and early career technologists who are just, you know, blowing our minds on what they can do.

And we're part of a bigger, larger movement of really trying to invest in talent in the government on how we build and buy and use technology. And I think it's a pretty powerful movement that's happening and it's kind of cool to be a part of it and see it grow. And we're one of the first agency teams for the U.S. Federal Service. It was really us and Veterans Affairs. And now there are agency teams popping up all over the place. NASA has a new one. The Administration for Children and Families is kicking up their team.

Defense has always had a digital service team, but there's just a lot of like movement in the technology space or civic tech space, which is really cool to see happening. And I will always encourage people to apply to the federal government. We're here. We'd love to have you. And so that's what gets me really excited is all of these really cool people coming into the government to solve big problems. What I get excited about in the future with technology, AI, or a large language model, like we're pretty excited to hire in more data scientists and engineers to be able to build and work on those ourselves, to be able to think through some of these really like tricky problems that we have, like modernizing old systems and kind of calculating the data sets that we have with these new tools and models.

But to me, in order to do any of that, we have to have staff to do it. So like I've been pretty focused on how do I build a team? How do I build multiple teams? How do I take what we're doing and amplify it and work with other parts of the government to make sure that they're also able to get the capacity that they need. So if you're looking for a job, call me. Yes. Great. Great CTA to leave our audience with. Awesome. Well, this has been so fascinating and such a rich conversation.

So thank you so much, Remy and Andrea, for your time today and your insights and I appreciate the work you're doing. It sounds really complex and really hard and very important. So thank you. Thanks for having us. Thank you. Thank you so much for coming on both of you. It was great to hear and yeah, for our listeners, we'll drop the link to apply to Andrea and Remy's team in the show notes. That's our show. Please like, rate, review, subscribe, and share this episode if you found it useful.

It really helps us grow our impact. And write to us at podcastatdimagi.com with any ideas, comments, or feedback. This show is executive produced by Amie Vaccaro, produced and edited by Michael Kelleher and myself with cover art by Sudhanshu Kanth.