Former CTO of the US and current President and CEO of CareJourney Aneesh Chopra talks with Datavant Chief Product Officer Shannon West about his journey through healthcare, technology, and politics, patient access to medical records, and how to improve digital standards for data exchange in healthcare.
<Theme music>
Audio version only:
I'm Shannon West. I believe we all want a better future for healthcare. I've spent much of my career on core issues, serving as the Executive Director for Healthcare at the United States Digital Service, CTO at the Innovation Center at the Centers for Medicare & Medicaid Services, and today, I'm the Chief Product Officer at Datavant. I want to support patients in accessing their medical data any way they can, whether that’s through apps, fax, email, or people walking in the door. On this show we invite guests to talk about exactly that.
Shannon: Aneesh, thank you so much for joining me on this inaugural podcast- not-podcast-video-cast-whatever the cool kids are doing now.
Aneesh: Thank you for having me. It's an honor to join you.
Shannon: Of course. Of course you were going to be my first guest. Always top of the list, always someone I love to chat with.
I realized that I actually don't know much about you from your time before the White House. I was telling this earlier, I said, I think that Aneesh was born the year that he was made the CTO of the United States. But I know that there is an origin story. What were you doing before you were the CTO?
Aneesh: Yeah. So the origin story is that I actually was a healthcare banker at a college, and - at Morgan Stanley - around the time that my colleagues at Morgan Stanley took Netscape public. So I was enamored by this thing called the internet, and I hadn't…so browser technology, I didn't have it in college. I've just graduated, I'm in New York, I'm doing my banking job, and I'm like, “What?! This thing is transformational! This is going to change the world!”
And so I dedicated myself to healthcare-tech/internet. So I did grad school, my master's thesis was on how basically internet technologies would improve academic medical centers. And I did you know, Halamka is a buddy of mine.
Nick: Hey Shannon, it’s Nick. Sorry to interrupt your conversation with Aneesh, but he keeps bringing things up that I’m not sure everyone will know what he’s talking about. So for starters, I wonder if you could clarify, who is “Halamka?”
Footnote Shannon: John Halamka. He is a pretty well known gentleman, known in healthcare, a physician who's really paved the way for a number of changes in technology, was the former CIO at Beth Israel Deaconess in Boston and currently leads the platform at Mayo Clinic, is just a really prolific thinker about all things health data and how they impact care delivery.
Nick: I might just keep popping back in here every so often to make sure we all stay on the same page.
Aneesh: He was an ER doc at the time. He wasn't like the masterclass John Halamka we know today. We rode an empty shuttle bus together.
I spent a decade in healthcare. That's probably overstretching. Let’s call it seven or eight years, where I was at the advisory board company writing research studies and I asked permission to write one on the internet because it wasn't something CEOs were asking the advisory board to write. So I had to push a research study that wasn't asked for. Ended up being pretty popular because it caught the wave of the first internet 1.0 revolution. And so my case studies on Halamka at the time and other things caught up and were like, wow, that actually can be meaningful to my hospital.
So I had been mostly a healthcare policy wonk with a technical focus in the private sector. And then when I went to the governor's office, I was Virginia's secretary of technology before I went to the White House. In Virginia, Governor Warner was the first to create the electronic health records Task Force. I served on it.
We had two of four or Brailer HIEs
Nick: Is a Brailer HIE a…machine?
Footnote Shannon: Brailer HIEs were the first health information exchanges, that were basically championed by David Brailer, who I believe was the first National coordinator of the United States, ever. Full stop.
Aneesh: So we had four. Two, in Virginia. And so when I came in, I spent a good deal of time... In fact, ironically, day one, I asked the health secretary, Could we launch administrative burden reduction / EHR initiative? So she's like, what? We just started. I'm like, Come on, let's get on the call. Let's get the healthcare stakeholders. We're going to commit to this. And we had a lot of fun together. But so that was Marilyn Tavenner who went on to be CMS administrator. So the two of us worked on it in state government. Governor Kaine, my boss… I had $1,000,000 (“ONE MILLION DOLLARS!”) of discretionary innovation money, and we were able to seed grants. I had four or five bets we could make on the million bucks to test out different ways to do data sharing and consumerism and everything else. So, you know, coming into the White House was very much like, “do all technology across all use cases.” But my heart was always in healthcare.
Aneesh: Wow. That's a great question.
Shannon: So I'm going to give you a couple of triggers. One, there was a public apology at HIMMS involved. Do you remember this?
Aneesh: I don't okay. Now I’m intrigued. Please share! Spill the beans!
Shannon: You and I met two ways. One: Aneesh is notorious for a very long form email that shows up in the inbox of a lot of political people.
Aneesh: Yes.
Shanon: …with various ideas on what we should do to make government and healthcare better. I had just taken my job as executive director of Digital Service at CMS and I got my first Aneesh email and I turned to Mina Hsiang and I went. “Who is this?”
Aneesh: Yes. Mina was with us at the hearing. Yes, of course.
Shannon: Yes. Okay, so when you first meet, I get the Aneesh email. I ask everyone. Who is this guy? I think we get on a phone call and then all of a sudden the US digital service is involved in the Blue Button API. And you and I have another meeting at the White House, and this is where the public apology comes in: you told me that we could not vet apps before letting them connect to Blue Button.
Nick: What is the Blue Button API?
Footnote Shannon: Honestly, Blue Button API is one of the things that I'm most proud of in my career, which is why I get kind of excited about it.
The Blue Button API is an API - Application Programing Interface - that was built using the FIHR standard to share claims data from Medicare with 53 million Medicare beneficiaries to the third party application of their choosing. The concept was, take the original version of of Blue Button, which would spit out a PDF of your claims data or your medical record at the push of a button, and instead make it so that data could be accessed digitally by any application that a beneficiary or patient would choose.
Shannon: And you asked me over and over again and I said no, I'm doing it like we are going to vet apps. We cannot let 1-800-Russia take all my data, connect to the Medicare Claims API. And you said I will give you a public apology at HIMMS if I am wrong. And the next, I think it was 2017, we did like a small showcase. And you stood true to your word there.
Aneesh: And by the way, this is an area where rulemaking and reality need to be more aligned. And so I was speaking a little bit defensively about rules that, basically, developer portals couldn't put them on scale.
Shannon: Yep. Yeah.
Aneesh: And then in the real world, you're like, Look, I'm going to do some process and the reality is you were right, are right, as you always are. And frankly, it probably gave some air cover to figuring out what should the tweaks to the policy be to balance not anti-competitive behavior with security and privacy, reasonable protection. So in many ways, that story is a great one for the audience to understand theory, reality, and the closer we bring that into harmony in terms of testing, feedback, iteration, that's the right way to solve policy making in the digital age.
Shannon: So I'd love to spend a little bit of time talking about Blue Button patient access. As you know, kind of as a continuum of that - I love FHIR, I love digital access. I want to support patients being able to get their data and apps any way they can. I also know that at Datavant we fulfill a ton of requests for patient access to medical records through fax, through email, through people walking in the door.
I care deeply that the digital divide does not leave people behind. And so for us announcing free patient medical records for folks who are using our digital technology was a huge step forward to say, “Don't care if you have a smartphone, you're still gonna be able to get access to your medical records for free,” and being really excited about that.
So I would love to just spend a second…
Yeah, I'd love to dig in there.
Aneesh: Well, when we started, it was like, “No.” The origin story of, you know, Peter Levin and Todd Park were in New York at the Markle Foundation. I was not there. They were inspired by the conversation. Adam Bosworth famously, you know, kind of the engineer behind XML sort of said, “I want a Blue Button to download the data.” It made a lot of sense to Todd, to Peter. They came back, briefed me right away, and they said, let's pursue this. Let's do it.
My role was around when the president should get involved in many ways. And so, as you recall, White House role doesn't get in the weeds on many of these things. We sort of have this translation layer. So, [the president] was going to give a speech at the Disabled Veterans of America…
Nick: …and by “he,” he means Obama.
Aneesh: …in August of 2010, if my math is right and yeah, August 2010. So he was going to announce the end of the combat mission in Iraq, obviously a very big announcement. And the question was, could we introduce this idea of Blue Button at that speech? And so the “no,” it came because we sent word - the way this White House thing works is like you if you're going to say it, you got to ask the agency to confirm that they'll do it.
And so the VA got a message saying, “hey, the president wants to say effectively, we're launching Blue Button this fall. Would you get behind it?” And the answer came “no.” Because the culture was such that, you know, it wasn't about like, is it technically feasible? Obviously, yes. It wasn't about you know, of course, there were some misunderstood concepts of security risk. And so we had to overcome this, what was essentially a historical bias against making it easy for patients to get their records. And that was a microcosm, I think, of what the industry generally believes, right? It's sort of like, “What? You can consent for me to share it behind your back, but asking for a copy yourself, what are you going to do with it? Like, Whoa, who are you? Why do you want it?” So we had that mind shift.
I did ask the team that was briefing the president to kind of get deciding on whether we're going to take it out or put it in. I said, look, I'm going to double check that if the president's willing to say it. And he endorsed that, he wanted to say it. But now you got this bad feedback. Let's just go through this staff level. I called Peter Levin, the CTO. I said, “Peter, if he says it, will you ship it?” And he's like, “I swear I will ship it. I will hell or high water ship it.” And I said, Well, all right, I'm giving it the green light. And I said to the team, “We got the green light.” It was the second loudest applause line of the speech, right after the, of course, the end of the combat mission was this. And the crowd loved it. And over a million veterans pushed the Blue Button, even though it was crappy text downloading.
So point taken, the “no” was a cultural phenomenon. With your announcement. My sense is we were already on the verge of tilting towards. “Yes.”
And so the thanks I have for what you've done is to sort of say, I'm not required to make this easy for “Yes,” but I'm going to voluntarily make it “Yes.” And I think that may be the signal to light the FHIR that we should go from “no” to “yes.”
And it's never been about the technical burden, although the upgrades you made on 2.0…
Nick: 2.0?
Footnote Shannon: So the Blue Button API and Blue Button 2.0 are the same thing.
Aneesh: ...really did usher in a FHIR based, standards based approach to doing it. And I'm grateful that you did that. But it's always been a mindset shift problem.
Shannon: Right. Right. Even inside CMS, when we were doing it, I think about the series of events that got us to a place where we could do this and have the support that we did.
I tell people all the time, like, I'm always requesting my medical records. They live in a Google drive. They're not on my phone. I'm not using a smart app. I don't really want to. I like them in that format, but just the ability to request them in the way that I want them is so critical to anyone as a patient as they're moving through the health system.
Nick: So the big middle section [coming up] about X12 versus FHIR. I feel like we need some kind of preface because it's pretty in the weeds. So can you give us a little primer on X12?
Footnote Shannon: Effectively, X12 is the standard that the entire payment infrastructure for the US healthcare system is based on. It’s how claims get paid. It’s how they get submitted. It’s how health insurance companies and providers communicate.
X12 is in some circles considered a pretty legacy standard. It’s proprietary. It’s not based on modern computing standards. In a world where clinical data exchange and really the exchange of health data at large is moving toward something called FHIR (Fast Healthcare Interoperability Resource) there is a push from certain segments of the industry to move away from X12. You see this in the context of the prior authorization regulations released by CMS, or in the No Surprises Act. There is some debate there as well.
Personally, I think there are two pieces to this. Xi12 is a legacy standard. It is proprietary. That does mean it’s more difficult for developers and other people in industry to deal with. However, I think unraveling the dependence of our payment ecosystem on X12 will be extremely difficult, and could potentially be detrimental to how we process claims, make payments, and create additional burden for anyu developer who is working on booth standards to develop a service for a payer or provider.
Do you want me to make that shorter?
Nick: Do you want to add a hot take about X12? I hear you tried to dismantle it.
Shannon: My one hot take is that when I was at CMS my goal was to push FHIR as the standard the industry was rallying around. We did this in a number of ways.
I learned that X12 is required in legislation so that it means it literally requires an act of Congress to potentially change it. I believe that most technical standards should not be in legislation because it takes a really long time for congress to agree on things, and instead should be in regulation or sub-regulatory guidance. So I did start an effort inside CMS, which ultimately failed, to use a circular that you can ask congress to make certain changes from the agency to get X1 removed from legislation.
It’s still there today. I lost. Maybe in my next round in government we’ll pull it off.
Shannon: I saw the Linkedin exchange earlier with Brendan Keeler
Aneesh: Hey, great recording time!
Shannon: But doubly great recording time, I got a phone call from someone who is working on the price transparency regs earlier today who said, talk to me about X12 versus FHIR. And we had this conversation about standards that are not in development or widely used and using regulation to push something like FHIR forward.
And so I do have a question in here…
Aneesh: Let’s go, this is a great topic.
Shannon: So would love to hear more about your reaction to that. The post that Brendan made about your cousin and the comment around banking standards and leaving that as more of kind of an open garden versus having specified standards in each case. And I think your reaction had some reflection in it, both in terms of things that you have pushed in the past.
I think the quote is, “I fear we have missed this ethos over the past few years with an overreliance on drafting health I.T. FHIR standards long before we've had any real world implementation and testing.”
Aneesh: Yes,
Shannon: But would love to double click that with you.
Aneesh: So if we have time, let's do it thoughtfully. So I think this is a critical juncture. So in the High Tech Act, and frankly, the Recovery Act, more broadly, which was the foundation of the investments in the electronic health records program, I had some hand in three industry verticals under the same premise of, the US government will underwrite some of the underlying technology, but will compel the industry to open up the infrastructure for use.
And so the electrical grid, the Smart Grid, we were putting about $10 billion to put meters into people's homes. 35 billion into the health records, and then maybe three quarters of a billion for learning health system, not health systems, learning technologies for schools.
So in each of these areas, we had a kind of a common frame will subsidize infrastructure. It must be open and it can't be anti-competitively deployed. And hopefully they'll be incentives to put the data to its highest and best use to make the world a better place.
Now, in contrast, just a little bit where the LinkedIn post went earlier today. Banking, by the way, came later with our friends at the Consumer Financial Protection Bureau, the Dodd-Frank bill. They all had - all four had the same general construct, which is that we wanted anti-competitive protections in a digital infrastructure.
The Smart Grid was an interesting case study in that there was no such thing as an ONC. We kind of created one out of thin air in the Commerce Department and we gave them maybe a couple million bucks, 5 million bucks, ten? It was very small one-time funding on a $10 billion program to deploy the meters. No industry consensus on standards, no concept of consumer action, so that my meter in the home all of a sudden got smart, but I can't connect it to my phone to understand what's happening in the utilization of energy in my home to make changes, if that was a priority of mine.
So we put the course in play of industry consensus. And we said “no opinions, we're not going to dictate a technical architecture.” We're going to basically say, you must do something to share the data. And my role at that time was light touch industry consensus saying Green Button…
Nick: I have a continuity check. A minute ago, he was talking about a “blue button.” Now the button is green.
Footnote Shannon: Yeah. So, Aneesh Chopra loves buttons. The Green Buttons…
Nick: Can we make a t-shirt that says Aneesh Chopra Loves Buttons? Actually, It wouldn’t be a t-shirt. It would be a button-down shirt.
Footnote Shannon: Yeah, Yeah. Or it would just be a shirt with a big button on it.
The concept of the Green Button started I believe as an effort to get energy consumption related information in the hands of consumers. Blue Button was a natural extension of the concept that I could just push a button as a consumer and get access to information that I need, that is mine, that I should be able to have to make decisions or to use in whatever way I want.
Aneesh: Green button. Self-organize, we’ll do what we can to give you technical assistance, and will anybody raise their hands and step up? And boy, Shannon, I got crickets. The utility companies were like, “Who are you? I don't have to do this. Not required. Go away.” Long winded story ended with a session in Northern California where the CIO at PG&E - yeah, Pacific Gas and Electric - PG&E said “Look I'm from, I came from retail. This sounds like the right thing to do. Why don't we try to figure out a way to make it happen?”
So I asked her to convene her CIO friends from San Diego in L.A., and I'll bring the way to the White House in the executive branch. So we all flew out to Northern California, had like a full day working session, and then the press was gathering outside and I kind of prepped her. I'm like, “Would you get the ball rolling?” So she said, “I'm here to say I am committing to the next 90 days to work on Green Button standards for the American people, and we're going to do it.” And she's a woman. And these two old white dudes were behind her and they're like, “WHAT? Security, privacy. Are we allowed to do this?
So but I got the job done. They all had to, you know, engage. And so 90 days later, Green Button launched and they all worked by themselves on an API standard for Green Button. So that kind of was like, no regulation required, no CURES Act, just like go.
In healthcare. We had the challenge of the opposite. We basically said you have to do a minimum data set and we're going to start with like a starter kit. Here's like a dozen pieces of information that you have to collect and share, and then we expect you to kind of self organize and go forward. By the time CMS administrator Seema Verma, your boss, went on stage at HIMMS in 2019 or 2020, whatever that date was, she basically came out and said, No, it's 2019. No. 18, 2018. My Lord. She's like, in the eight years since we had the HITECH Act, guess how many new industry consensus standards were added to the minimum data set? None. So we had a market failure in healthcare where there was like anti-matter, like no other than what was minimally required to do it.
So it's a long winded way of saying I was observing this really volatile world where the banking industry, banking industry didn't do standards, which is why that particular post is relevant. They did vendor. So basically everyone just bought Plaid. Yeah. So the standard, if that's a word, is Plaid.
So now let's fast forward to this tweet or this, this LinkedIn post. So my cousin who I teased him the minute he took the CFPB job, I'm like, Dude, you better write the final rule for the Dodd-Frank bill, for, you know, the Blue Button, the Green Button, and now open banking button, give it a name. It was in Dodd-Frank. We never wrote the rul.e Cuz, you got to write the rule.
And so his rule basically said, I don't want to make Plaid a mandate for everyone. I'm paraphrasing. So it needed to be open, standards open, then there's not one to rule them all. And so in that world, there's a little bit of market dynamic that had him say, I want functionally price transparency. So your APR has to share, and I want all your checking account data. I want it all available to me and it's got to be safe and secure and all reads like an internet based API. That's essentially what he said is in the rule. But that like if the current standards process, i.e., you know, one vendor or maybe a small number of vendors does it work with, there could be others.
And so his point was open internet based APIs are probably the way to go. He didn't have to say that. He said, look, I'll let the industry resolve the functional requirements and then we'll get there. So I actually agree that that's what's needed in banking. In energy, we needed to create the motion started and that kind of flywheel. In healthcare, we have this misalignment problem.
So here the challenge is the functional requirements have been on the books basically forever, like share everything to everyone. But the details are not sufficient, so therefore you're not really forced to comply. And we see this in the patient access story. You're in the middle of doing a great thing to open it up. But in reality, the HIPAA Right of Access has been on the books since the nineties and absent a technical mandate, I can be conformance with the right of access, but making it effectively unusable. So we needed to have something.
So I am of the opinion that internet based APIs are the floor. The industry should work on that infrastructure and move use case by use case through consensus and testing. And FHIR, the reason FHIR gets short handed and if this gets wonky, we're going to lift up and you're going to bring me back to the discussion, is it's actually got two technologies embedded.
The Smart on FHIR Authorization server is the open banking edge. It's where I can declare that I'm a consumer app or a physician app or a health plan app, and the authorization server interacts with me. And that payload today could be FHIR, where clinical data is expressed, but scheduling is today not really deployed as a FHIR resource. So maybe there could be an alternative API for scheduling or benefits, checking for, you know, who qualifies for Meals on Wheels that may not be currently in FHIR. Maybe it could be an alternative API.
So we need to have a…my, my, my spirit was let's get the industry to self organized, drive faster. So for whatever reason there was some misperceptions that, you know, I'm on the side of write standards like Moses tablets and then forced the industry to adopt, which has never been my case. My case is early adopters, test, and learn.
And my comment, my final comment is that to the extent that we had a negative comment about where we are in the last few years, is that the supply of FHIR implementation guides has gone out of control. We now have like, every, it's like “You get a car! You get a car!” I feel like, “You get an IG!” and we've lost that feedback loop.
Shannon: You might remember a meeting in the White House after we launched the Blue Button Claims API. And there was this moment when Josh Mandel and I were talking about it and he said, But you did - I can't remember what it was, but it was something that we did in deviation of the IG - And I said, “Of course we did. Josh No one had ever built this before. It had never been implemented. You can write academic standards all day long, but we have to implement them.”
And for me, in the regulator section builder seat, what I recognized was no matter how many IGs we built, no matter how many times we thought that there was some reference implementation that happened the second that you had real world data and real world exchange, there is something that is different.
And it was - I remember the conversation ended with Josh recognizing the power of this small team inside CMS, now being able to contribute back into the standard, which is what we really want.
Aneesh: You nailed it.
Shannon: So just such a great example there. I want to this X12 / FHIR conversation.
Aneesh: Even more spicy.
Shannon: Yes, I'm sure you know that at one point in time while I was in government, we sent around - I can't remember what the circular was - but we tried to strip the requirement for X12 out of legislation. It died. We got it past one office and everyone was like, “Don't you dare touch that.”
Aneesh: But let's make some news today, Shannon. I think this may be the path forward post Change.
Shannon: Okay, But let's talk. I think my big question is, you know, I've had a number of years in industry now out on the other side, have also spent a lot of time with folks that are in the claims processing side. We are rebuilding the claims processing systems at CMS. My big question is:
Aneesh: How about we let's not - that feels like a technical battle royale. So let's peel the onion back. You built the QPP Submissions API. It doesn't have to be FHIR based. An internet based protocol, open API, allowing every doctor to submit their quality measure data to CMS. What would stop CMS from creating a submit claim submission API?
Shannon: The typical bureaucratic hurdles, but not much. Right? Like it could be done.
Aneesh: But let me ask you this question, and I laugh about this a lot, the same office that regulates the X12 standard also allows for what's called DDE: direct data entry.
So no X12, no interoperability. A doctor can log into a portal, enter the claim, hit submit, and it goes on the back end, either to a clearinghouse, or it could conceivably be functionally the same as the claim submission API.
In the pandemic, the physician practices were like, We don't have staff, so can I designate a robot to automate the submissions in the direct data entry? And the answer was yes. CMS came out with a blanket perception. Yes, you can.
And so here's the question, acts like a duck, quacks like a duck, call it a duck! You can go to a portal, you can have a machine on your behalf, fill it out, hit, enter, and it goes to the plan. So direct data entry is not necessarily linked to an interoperability standard.
It's like I can log into every portal that exists from every plan. And so as I think about the resiliency of Change, we are in a place now where there's like heavy vendor dependency and we have to assume with cybersecurity risks that anyone can go down.
So if you had an API, if there was a claim submission API, I could instantly offer, someone could offer the ability to create an alternative pathway that didn't require you to switch EDI vendors to one more vendor that could conceivably have the same vendor dependency issues. So it's not about Change is bad in someone else's good. It's like structurally one pipe to rule them all for my entire financial life as a doctor, no bueno.
So if we start with the premise that right now there's no option, if it's electronic, it must be X12 through a clearinghouse. One to rule them all. But then you have these portals that allow automation, so why can't I make the portals an API and give me choice the minute that.
Shannon: Got it. Okay.
Aneesh: Call it Enforcement Discretion.
Shannon: I guess in the context of choice, it does make sense that I think that the like scar tissue that isn't mine that I feel like I carry around are the amount of people that I would have the X12 conversation with after would say, you don't remember 20 years ago before X12 when it was impossible to submit electronically, when there were all of these other issues happening. And I think I've inherited a little bit of anxiety around that, that's like, is it broken? If yes, can we really clearly define where it's broken and understand how to fix it? I hear you on the multiple options part.
My question in industry is does that then take us to a place where actually we put more burden on providers and if we regulated into plans, do plans now have to offer this plethora of options? And, you know, I mean, I hear plans talk all the time about the CMS regs now, and they're like, that compliance reg? We've got like one patient who requests from it or something like that. Like how do we make sure regulation is meaningful in the context of, well, paying for healthcare, delivering care?
Aneesh: Here's the best part. The action by CMS would be Enforcement Discretion on enabling HIPAA submission or transactional APIs. And then it's my choice as a plan. Do I offer this option? And the reality is it's going to be better, faster, cheaper.
Remember the US digital Services playbook? Playbook 13. My favorite. Okay, if you're going to build a digital service, where feasible, offer an API with the service, or in me and Nick Sinai's words, wholesale Digital Services ship with retail Digital services.
So it's already accepted to do retail digital services. It is today not allowed to make them wholesale. So all I'd be asking CMS to do is make it wholesale.
Shannon: Got it. And that would look similar to what they just did for the prior authorization reg.
Aneesh: You nailed it. And so in that example, you could do the X12 transaction for prior authorization, or if you only supported the API and you turned off the X12, “Enforcement Discretion.” You don't have to support both.
Shannon: But I think that the piece that I pay so much attention to now, especially having moved from, you know, being there…actually, I think I told you the other day, we are almost that the four year anniversary of the day that the regs were finalized for 21st Century Cures at ONC and patient interoperability and access at CMS.
Aneesh: I got you.
Shannon: The piece that's most interesting for me is four years later, are we where we thought we would be?
Aneesh: No.
Shannon: And when I reflect that, the answer is no.
Aneesh: Of course.
Shannon: But if I look at things through the lens of unintended consequences, it doesn't feel like there were a lot of unintended consequences in those regs.
In the context of thinking about removing enforcement discretion here. If I am a provider, and maybe I'm a small provider and I contract with 30 different plans, half of whom use an API, probably only half of those have been implemented in a standard way, and then the other half still use X12, I'm now in a position where I have to take on the burden of building multiple mechanisms for me to share, to share claims data, or we build a new industry with a layer that sits in between, that does the translation.
And maybe that's what happens in the wake of clearinghouses going away. I don't know.
Aneesh: I don't know who goes away. And let me be clear, just in case folks are like, “Aneesh, are you anti-X12?” No, I love X12. I was in state government in the Commonwealth of Virginia, and I worked on a public-private partnership where we selected Availity to be the platform for the administrative burden reduction. So I'm all in on collaboration, and burden-reducing standards and the CAQH frameworks.
There's nothing evil, bad, wrong, or inappropriate - like they do a great job. However, in today's world, with the consolidation in the market, we're now vendor dependent on a technology architecture. So if my practice is not getting paid, I'm logging into every portal and doing everything I can to get paid.
Shannon: Right? Right.
Aneesh: And if there was an API where a competitor application - look - our friends at FlexPa has connected to 500 points. I don't even want to count how many Datavant’s connected to. Like you guys are all connected, right? So the marginal cost of connecting to endpoints is falling. So if there were APIs on their FHIR servers, meaning Smart on FHIR, remember I care about the authorization server. If I could authorize a physician designated application, which is the Provider Access API rule that CMS just finalized in January. If that if I have to build as a plan the infrastructure to support that, but I'm only going to drink a narrow straw, I can only pull claims data and lab values, but I can't submit claims, and I can't like do eligibility verification? Rhat feels bass-ackwards. Like I'm already going to connect to that endpoint for my physician Access API. Why can't I use that same connection to do more transactions?
Shannon: Yeah, I mean, I think the piece that I look at and I've seen a number of companies who've been presenting on basically their strategy to be the CMS compliance company. The piece that's always been striking to me is the FHIR server that supports the build of the of the last and the most recent regulations from CMS is distinctly different than where you need some FHIR submission server to sit. It would be a different end point for me to check eligibility or for me to submit a claim because those systems inside the pair distinctly different.
Aneesh: But remember and again, let's take a minute on the technical design of Smart on FHIR versus FHIR Server, because you're making an extremely important point, but I'm going to suggest to you that maybe we're going to pivot off of that question.
So we've been working on the idea that images, images of like X-rays or, you know, my wife and I with the baby and, you know, the whatever the ultrasounds, those should be available through the same Smart on FHIR servers that allow me to pull my clinical data out.
Well, the images themselves are not natively stored in the EHR FHIR server. So there is a construct that we've endorsed in the Argonaut Project, which is called token introspection.
Nick: Argonaut Project.
Footnote Shannon: Yes. The Argonaut Project was originally born as a mechanism for people who wanted to promote open standards in clinical data exchange, to build implementation guidance, other versions of recommendations for standards bodies to support real-life implementation of standards.
The people who work on the Argonaut Project are Rock Stars in the world of health data interoperability. Aneesh Chopra, Josh Mandel, Ricky Bloomfield. The list goes on. My understanding is that the concept for it was created over a dinner with a host of those people and it now has become a very prolific group where most new requirements for data exchange or interoperability go to to help sus out what will actually work and what won’t in that process.
Aneesh: And the idea is I authorize through the developer portal a whole bunch of features. Scheduling could be one in the future. So too could image retrieval or claim submission or eligibility verification. And it roots me to the appropriate server that can facilitate those conversations.
So let's drop the word FHIR for a minute and add to the infrastructure burden. What is the back end for the direct data entry portals for each and every one of the health plans that support them? 100% of plans support a directed entry portal. There's a back end to that, a database and they've already allowed a machine to talk to it.
So the level of effort to kind of clean that up into an API is not nearly as crazy as…It literally could be, you know, even ten fields, because I think X12 only, as you know, there's not that many fields that flow through. So it doesn't have to be a whole new restful API complicated with the, you know, the JSON payload. It could be just like - the QPP submissions API is not that technically complicated.
So my hope is with token introspection, the provider Access API portal allows you to find all the transactions. And it comes down to this, Shannon. What you're doing at Datavant is you want this to work, so you spend your time with your colleagues delightfully building digital services because people want this to work and they pay you to make them work.
So you're investing in it working.
Every vendor that's selling compliance on the cheap is what's wrong with the industry. You want it to be, “I'm helping you do your work.” That’s a mind shift.
Shannon: Yeah, totally. Yeah. Totally. Okay. I'm going to pick us back up a little bit. You and I love to be in the weeds and I love it. I think there's ten people who will love that part of the conversation.
Aneesh: But those ten are going to be influential. So we're making policy changes on this call, Shannon!
Shannon: They usually are!
I don't think I've ever asked you this, but I love to ask everyone who's served in government.
Aneesh: Well, I would say there in general, I regret leaving early. My biggest regret is leaving early. For those who are listening, I ran for lieutenant governor of Virginia for complicated reasons. Friends of mine in the party said, Look we got basically shellacked in the Tea Party wave. And so the Democrats were not looking very good. And we didn't have a lot of folks, you know, kind of standing up to run. And I thought maybe in the future, like 20 years from now, I'd run. And there was a like, look, these things sometimes happen where timing is such that you can't really control it. And this is a good window. So anyway, I made that call, right or wrong. Grateful for the experience, but boy, boy, leaving, you know, I was having the time of my life. And so, you know, that was a little bit of a challenge.
I would say the functional regret is not going deeper on a couple of areas where we kind of had high-level policy agreement, but we didn't quite take it to the finish line.
I obviously have a ton of regret on healthcare.gov, and I think it's been written up elsewhere. But like I had a concern about what we were doing and try to engage on those issues. I wasn't as successful in the beginning, but it was still early. So there's plenty of time for it to kind of get righted.
I think mostly it's the execution and implementation of a few key ideas versus a lot of them at the wall to see which ones would catch.
Aneesh: Well, to me, the part that's always been missing is the marketplace of applications and services to help you make sense of it. So, Peter Lee, who was a friend of mine, is a friend of mine, but worked with me when he was at DARPA and I was in the administration. He got his lab results back in a PDF. Like, who cares? Whatever the format is. He uploaded it to GPT-4 the version that's inside the Microsoft vaul.t And he said, Anything in this report I should be worried about? And it came back and said, You have some form of anemia and explained where he was and said, this is not medical advice. Go ask your doctor.
I think we all deserve some form of a digital guardian angel. As Isaac Kohane and team wrote back in the nineties with their Digital Guardian Angel project. And so at the moment I can look at the data, I can store the data, with my brain, I can interpret the data, but I'm not really connecting it to a generative AI-powered decision support engine about where and how to go next in my journey.
For chronically ill patients that are dealing with co-morbidities that have lots of issues, no one doctor is advocating for them universally. And so there's a lot of this. If you look at every single data set, which we do at CareJourney every day, it is the co-morbid patients that are complex and chronically ill that all of the avoidable spend. It's not you and me deciding to get a, you know, a procedure done or an imaging study done, like, yeah, we could use some quote, digital help, maybe for convenience, but it's not going to change the quality of our health outcome. Those folks who struggle the most, they're a small share of the population, but boy, they're in the E.R. for reasons they don't need to be and everything else. That's the group I think we want to almost prescribe some kind of digital health navigator to support them.
And the dilemma at the moment is if it's sponsored by the hospital, it's not going to promote the cheaper surgery center down the street. If it's sponsored by, you know, the MA plan, it may be designed in a way that affects their benefit structure.
So, like who's doing it for me on my best interests without any sort of bias?
Shannon: Totally. Maybe pulling on that thread a little in the last few minutes. We have you mentioned CareJourney. We just talked about better care for patients: value based care and data. This is a space that feels like we've made a tremendous amount of progress from the first models that eventually became MSSP.
Footnote Shannon: Ask me the question
Nick: Shannon, what’s MSSP?
Footnote Shannon: MSSP is the Medicare Shared Savings program. It is an accountable care organization-based payment model that allows Medicare physicians and ACOs to participate in risk-based contracts for a fee for service Medicare beneficiaries.
In this context, I bring it up because it was one of the original models that fall into what we sometimes referred to as “alternative payment models” or “value based care.” And it really had emphasis on data sharing between both the entity that would pay for care, in this case Medicare, and also between providers who were participating in the model.
Shannon: That was really the first one where there was a lot of impetus for data sharing with providers. We now have the - I'm super, super excited that Data at the Point of Care is effectively in the regulation.
Nick: Seems like an important concept.
Footnote Shannon: Yes, I love this project. I think I lied earlier when I said Blue Button was one of the things that I'm most proud of. It might be Data at the Point of Care.
Nick: Go on
Footnote Shannon: So yeah, so Data at the Point of Care effectively built on the work that was done in Blue Button to share data with individual Medicare beneficiaries. In this context, it was using the same backend FHIR server that would support a third party application to access data. In this case, in the case of Data at the Point of Care, it's actually about providing claims data directly to providers in order to give a view of history for any patient that they're seeing.
So the concept is a provider could create an application that would integrate with our FHIR server in order to pull back historical claims data on any patient that they might be seeing or have seen in order to get that more robust picture of their overall health.
Claims data is one of the most underrated tools for creating the underpinning of that longitudinal history of any patient. The claims data does not have full clinical data. If you think about that, is like notes or specific data elements associated with it, but it is essentially like a set of clues to diagnosis, what provider someone has seen, when they saw them, and could be used to go and get all of that additional clinical data and bring it back to the provider or back to the entity that was looking at those claims data?
Nick: It’s like the trail of breadcrumbs through the forest.
Footnote Shannon: Yes, absolutely.
Shannon: I hope that CMS opens up the program for people to access it soon, but is huge for us to think about how plans share data with providers and how we think about that in the context of a future where we pay for value.
Aneesh: Well, so where I think you're heading is that we did a lot of magical arts in the first area, Value Based Care. You had to organize all this data, you had to build all this infrastructure, you had to do all of this incredibly hard work and change your practice patterns. And the benefit of that is you got a shared savings check on the other side.
But what's happening with the regulations and frankly the technological improvements, why can't that just be “care?” So a lot of the tech stack is simplifying and it's going to get more and more democratized. You're going to help democratize some of that as well. And the more we can get to the place where it's just how care is delivered. The “value based” part is this overly complicated mathematical formula about what the cost would have been if you weren't there and what the costs are now. And I agree with you or I disagree with you and you're not paying me fairly. So there is a financial engine that needs more work.
But on the side, we don't have to subscribe to any engine. We can effectively deliver it. The data will flow. The algorithms are largely public. The analysis can be done in a clean and simple way. And if I'm motivated to deliver that kind of care…What did the president do in the most recent physician fee schedule? He created a new billing code for Clinical Care Navigation - PIN - Principal illness Navigation.
My doctor can now give me a service that could be tech enabled, by the way. I think that'd be a great place for Datavant to kind of help support the PINs, and to say, look, you've been recently diagnosed with whatever. It's a big deal and it's going to take a while to deal with this and you're going to have to interact with lots of doctors.
I'll help you, and I'll make sure that you interact in a way that will give you more value for the societal investment in the care that you deserve. In an ideal way. That's what we need. We need a democratization step, and we need the stakeholders who support those practices to bring that. We need deflationary innovation to bring this to everyone.
And, you know, I keep asking - my mom and dad are on Medicare. They don't know if they're in an ACO or not. They're getting routed all over the place. Low value care. I'm observing it every day. Unnecessary tests, unnecessary things. I'm like, Mom, this is horrible. Dad, stop this wrong. And like, who's advocating for them? Nobody. Nobody. Yeah. So that's what I want.
Shannon: Yeah. I think about this often. I'm so lucky to come from a family who is very health literate, who knows how to navigate the health system. I have lots of friends who are not and whose families are not, and I'm watching them on these journeys with their parents as they're aging and they're ending up in plans that don't work for them or not being able to find a primary care doctor that supports them in navigating that space.
And you just recognize there's so much additional room for improvement, especially for people that are in these more vulnerable communities or populations. And there's so much work to do. And do I fundamentally believe that until we solve the problem of making sure our data is free flowing in healthcare, that we can't solve how we pay for it, we can't solve how we measure how good it is. We can't software patients, adult patients can’t navigate their own care. It is the piece that underpins the future of the healthcare system we all want to live in.
Nick: What are we going to do to wrap this thing up? I feel like we need some kind of closing bit. Maybe like a lightning round. Three questions you could ask all your guests - the same three questions. You know, it'd be like a fun sort of Shannan-signature-signoff. What do you think?
Footnote Shannon: Maybe
The two sentences or less is the hard part for you in this.
Aneesh: It is. Let's start with:
Shannon: Sold. Okay. Aneesh for president. When are you running?
Aneesh: I do believe the tide has turned towards transparency versus opacity. And every day we're finding more and more ridiculous things that were private and secretly held and now are being shined light on. So I love that.
I also, I guess more metaphorically believe, you know, best team wins, best talent wins. We're attracting some insanely great talent from the smartest parts of the country and the economy coming into healthcare. So if you sort of think about it like where is the talent flowing and what are they going to be working on, whatever that is, it's going to be great and it will be beneficial for families.
Shannon: Love it. Okay.
Aneesh: So in thinking about it, the most timely and recent book is
Shannon: That is a great one. I got to run into him at ViVE. Always a character to get to see.
Thank you so much for joining me today in this conversation. We talked about X12 and value based care, Blue Button, your journey to the White House - all of the things. So grateful. Thank you for being the first person to join!
Aneesh: Shannon, thank you for the work you're doing and keep it up. I'm on your side.
Shannon: Thank you, Aneesh.
.svg)
Explore how Datavant can be your health data logistics partner.
Contact us
