The Past, Present and Future of Interoperability with Micky Tripathi
Episode 3256th November 2020 • This Week Health: Conference • This Week Health
00:00:00 00:48:42

Share Episode

Transcripts

This transcription is provided by artificial intelligence. We believe in technology but understand that even the most intelligent robots can sometimes get speech recognition wrong.

 Today, on this week in Health, it, we have a great conversation with Mickey t. We're gonna cover the, the past, the present, and the future of interoperability. And Mickey is, uh, fantastic 'cause he's been there from the beginning and, uh, he's leading us into the future. So I really appreciate his, uh, insights and look forward to sharing that with you.

My name is Bill Russell, former healthcare, C-I-O-C-I-O, coach. . Consultant and creator of this week in health, it a set of podcast videos and collaboration events dedicated to developing the next generation of health leaders. Uh, I wanna thank Sirius Healthcare for supporting the mission of our show to develop the next generation of health leaders.

Uh, their weekly support has given us the ability to expand our services and develop new offerings for the community. Special thanks to Sirius for that. Sponsorship. Let's see. Oh, couple. Couple just quick bullet points. We have. You guys are taking advantage of the Clip nos referral program and keep doing that.

Send your friends over to the website this week, health.com and have them sign up. Put your name in as the referred by and you'll get signed up for potentially winning a uh, work from home kit from this week in Health. It 10 referrals get you this, this week in health it moleskin notebook and uh, one.

Whoever gets the most referrals will have the opportunity to sit with me on, uh, the Tuesday Newsday show. And uh, that will be fantastic. We'll have a good, uh, time. You'll get to take Drex to Ford's spot for a week and we will have a conversation about the news. So, uh, keep those coming. Um, Mickey and I talk for about 50 minutes here.

This is a little longer than usual. I just want you to know it's worth every minute of your time. So I'm gonna get right to the show. Here we go. So today we're, I'm, I'm excited. We're gonna talk about the history future and promise of interoperability with, uh, Mickey Tripathy, who has really been there from al what feels like almost the beginning.

Welcome to the show, Mickey. Great, thanks. Really delighted to be here. I'm reading your bio and it's, I'll just read it to the group. It has every group and acronym related to interoperability, so we'll establish your credibility pretty quickly here. So you were, uh, Mickey Pathy is a pioneer in healthcare, interoperability, active in the industry.

At the local national level, including memberships of the board of directors of HL seven, Sequoia Project, Commonwealth Health Alliance, the Care and Alliance, and the HL seven Fire Foundation, and the project manager of the Argonaut Project, an industry collaboration of to accelerate the adoption of fire.

Uh, he's a former CEO of the, I'm gonna say this wrong, Massachusetts, EHC, which is health. Collab collaborative and recently joined Arcadia as Chief Alliance Officer. That covers everything right there. Karen Alliance, Commonwealth HL seven. Fire. You've been a part of this for, for a long time. I have. I try to help where I can and try not to be spread too thin.

Um, , which is a challenge. , yeah, you probably get a lot of phone calls I would think. What I'd like to do is I'd like to talk about interoperability, really past and future since you've been a part of it. Then I'd like to really transition into the, the promise of why are we doing all this? What's the promise of data and analytics and healthcare?

re, I came into healthcare in:

Share our data with you. That was to me, I was like, man, this is a complicated deal that you don't just solve with technology. There's a lot of different aspects to it. You know what, give us an idea of where you started with this and what pro progress you've seen. Let, let's just say over that timeframe, that from when you started.

Sure. Yeah, no, happy to. So, yeah, and I, I started, I first got into, into healthcare. It really just jumping right into interoperability where a lot of people enter healthcare and health. It starting like in a provider organization where you're working on all the various systems that are within a hospital, let's say, as you were describing, and then you start to think about how it builds up from there.

And that's where you start to confront the interoperability of things. I came in a, you know, a different path almost sideways where we were. I was working for a consulting firm at the time, the Boston Consulting Group. And we, um, were hired by a, a group of organizations in, um, Indianapolis to come and help to do some business modeling and business plan development for what ended up becoming ihi, the Indiana Health Information Exchange.

So I spent a lot of time in Indianapolis working with the. Legendary fee figures at the Reagan Reef Institute, like CLE McDonald and Mark Overage working on developing a business plan for taking all the great stuff that the Reagan Reef Institute had been doing in interoperability and figuring out a retail, more commercial type of model to help expand that into the community.

hat you had just described in:

It was really just the hospitals. So everything that Indianapolis and the Registry Institute had accomplished had been connecting up the hospital systems across the city. And then you have the wide swath of care that's out in the ambulatory setting, which as we, which as we know, is where, you know, the vast majority of care happens.

Was unconnected because no one had electronic health record systems. So that was the first issue that we, that we confronted. All the other issues that you were talking about were were definitely there as well. The issues around standards, the issues around . Curation of data and normalizing data across those systems that none of that's been cured yet.

And we can talk about why some of those problems still persist and some of the competitive issues that you talked about as well. I think that's getting better and better, but over time, but certainly when we were, you know, launching IHI in Indianapolis, one of the things that we spent a lot of time doing is working with the hospitals to, to get a consensus among them.

Doing interoperability in the ways that we were talking about with the health information exchange wasn't really competitive. It was more like a joint venture, the same way that they were pooling money to do joint laundry services. That was the analogy that I like to use. They used to say, you guys are all spending money pooling your money to get more efficiency out of laundry for all your hospitals.

You should be doing that for lab results delivery as well, , because it doesn't give you a competitive advantage to have your own . Provider portal physicians actually hate that. They'd rather get everything through one place. Yeah. And I, I'm gonna really fast forward a lot and we're gonna start talking about 21st Century Cures, Teka and some other things, but, uh, you make the jump to Massachusetts.

Does the, does the policy environment and the regulatory environment in Massachusetts make a difference in terms of, of what you were able to do in Massachusetts? Yeah, I think, I think it was less the, uh, it wasn't necessarily the policy environment, but it was more, the business environment was a little bit different, which, which allowed the creation of the Massachusetts Health Collaborative and, and working with a number of other organizations who had already been, been in the state.

that was founded in the late:

And, and that was up and running for, uh, came right after the passage of hipaa. Where a group of very leading CIOs like John Glasser, who you know was the CIO of partners and John Lanka, who's ACIO of Beth Israel and a couple of others got together and said, Hey, we should, before we all spend money on this new HIPAA set of transactions that all of us know we have to do, why don't we get together and do this together?

So you had that, you know, that climate where people had developed that trust from something that was successful, which I think is really important. But another really important thing that I think is. Makes every market different than Massachusetts is. You've got this, uh, I think of this theme theory, which is you've got the providers, um, ambulatory providers, let's say, and you've got the government and you've got healthcare payers, and you have the payers.

And in each market there's differences in the relative power of each of those groups. I think when you think about, and when you look at it market by market, it's really different. Massachusetts, because it's so concentrated among the payers, it's really three or four nonprofit payers who are Massachusetts base who account for 98% of the covered lives in the state.

That's a very different dynamic than like in Indianapolis where it was something like 10 national commercial payers who accounted for 50% of the covered lives, and then the rest was like a long tail, right? So in Massachusetts, you're able to get three or four payers together and agreed they're gonna do something, and all of a sudden you've got a lot of the market.

The, sorry I captured. And that's what happened with the MassHealth Collaborative. The Blue Cross Blue Shield of Massachusetts agreed to put some money forward to run a large scale health it experiment that would be community based. And that got, and it didn't take that, that much effort after that to get a lot of the market together to be able to, um, agree to move forward on something like this.

So it, it, it feels like I've referred to this as the starting line, and that might be a little offensive to someone like you who's been doing this for, for, you know, 20 some odd years, but 21st Century Cures really, maybe not the starting line, but it really does set the foundation to, to. To change how we do this on a national level and, uh, really on a local level, but nationally really address this problem.

And part of that is, is teca, and part of that is CEEs and U-S-C-D-A and I, I wanna walk through that acronym soup with you. If, if, if, sure. So let's start with 21st Century Cures and Tef fca. Why, why is 21st Century Cures important and what is TEF fca? Sure. Yeah. So 21st Century Cures was passed. Just, just to get perspective to, to everyone who's listening.

That was passed at the end of the Obama administration, which I know feels like about five generations ago. But that law, a lot of people confuse, confuse it with the CARES Act, which of course was to address Covid. The Cures, the 21st C Century Cures Act was passed in what the very end of the Obama administration, and it's only now coming into force because it took that long for the rules to come out.

But now that the rules are out, what's important about about 21st Century Cures, I think is, I think of three things as being really important. One is Teka, as you pointed out. Teka is the trusted Exchange framework. Framework and cooperative agreement, I think is what it's called. And that is. The, the creation of a nationwide framework for interoperability with, you know, a governance mechanism and an approach to managing interoperability at a nationwide level.

Bringing the networks together under a single governance I. Framework, so that's work that's underway. The RCE that you referred to is called the the recognized coordinating entity, which is supposed to be the organization that plays that governance role. That's supposed to be the forum for having these networks, let's say we don't know how many networks, but where it'll define the standards that'll define the policies.

Working closely with the federal government to define what are the rules of the road of nationwide interoperability, and how would we think about that. That's the, the Sequoia project is the RCE right now, and they're hard at work working with the, with the federal government as well as with, with key stakeholders to develop that framework and develop that first set of rules of the road to be able to launch that.

Obviously, COVID has slowed things down a little bit, and I think one of the, one of the interesting features of Tef FKA is that it's not required. There's nothing that requires that anyone participate in Tef fca. So that'll be a little bit of the experiment here for us to figure out how valuable is Tef FCA to people, because it's not like meaningful use.

It's not like the information blocking rule. There is nothing in the law that says you must connect to Teca. There's nothing about payment. That says you must be connected to a Tef FCA eight, you know, health information exchange in order to get paid. So that's a, you know, that'll be an interesting thing that's going on.

We hope that'll, you know, have a number of large participants, network participants like Commonwealth and Care Quality, who will join that and become a part of those networks. But it's really an open question of, is that going to be something that accelerates. Interoperability or is that already happening on its own?

And Tef FCA is a nice overlay, but isn't always it necessary to, you know, accelerate the market. The other things, the other parts of of 21st Century cures that I think are really important are information blocking. So the law, the information blocking law that, you know, that basically said to providers and to their vendor and to vendors to EHR vendors that your default should be to share information.

Assuming that it's happening under appropriate, uh, permissions related to HIPAA and any other regulatory constraints that might exist in the market, but subject to those that the default should be that you're sharing information and it identified a certain number. I think it was seven exceptions. You could claim for not sharing information if it's being requested by another, by another authorized party, but that really flips a little bit of the conversation as you were describing with your experience with St.

Joe's. It was asking to share information with another organization and they say, no, I don't wanna do it now. That kind of flips the equation to say. They have to have a reason essentially, to say why they wouldn't do it, where the answer should be yes. Right away. And, and so information blocking is really important.

Um, it's important for the providers as well as importantly for the EHR vendors because there's real penalties, um, associated with it that that could be enforced. So that's a really important part of this. It's a policy framework that applies nationwide. There is a draft rule right now that's about to be released.

It could get released actually today or tomorrow. That could delay the deadlines for information blocking, which I think would be disheartening to some of us. But on the other hand, we are in a, in a national crisis, I think a global crisis. So I think it's certainly fair to think that in a global crisis it probably makes sense to, to give a little bit more time to some of these things, given that provider organizations in particular have a lot of other things that they're trying to focus on right now.

The last important piece of, of 21st Century Cures, and then I'll pause, I promise. Um, is, is the requirement, what flowed from that is the requirement that, that we use? Fire restful APIs in particular, a particular version of fire a, an interoperability, uh, standard that we can certainly talk about more. As the basis for these interoperability paradigms that you know, that are going to be a part of the future.

So up until that point, there had been no requirements for what? What would constitute a requirement for interoperability on a nationwide level? I. And, and in particular for the use of restful APIs or a specification for a restful API and what flowed from 21st Century Cures was the most recent ONC rule that said that you, that in order to fulfill the requirements of this law, you actually have to implement a specific version of fire so that we have as well close to

Standardization of API based exchange across the industry is possible. The other dimension that flowed from that was CMS, extending it to payers. Payers have never been a part of this. And as you start to think about the importance of saying that payers should be making data available and interoperating in the same manner that providers have been required to, is really an important part of extending the ecosystem, the interoperability ecosystem out to um, another critical part of the healthcare delivery system.

And which, uh, version of fire did we, we end up at four Or what? Which it's, yeah. It's a specific implementation guide for R four. Yeah, so R four is what's required. It was a particular implementation guide that's called the US Core. It's a US core implementation guide, STU blah blah, . Uh, he could find it in the rule, but it was a version that was passed, uh, just this past September.

And that, that is the rule that, um, or is the specification that's required to be implemented both by providers as well as payers. That's a, that's a great foundation for the 21st Century Cures Act. I, I get questions from time to time. Hey, this U-S-C-D-A thing over here, is that a part of 21st Century Cures?

What part is that gonna play in interoperability? What, yeah, so the what? ? Yeah, so the SCDI is a really important part. So the SCDI is. A evolution of what used to be called the CCDS. Uh, just to throw another acronym in the mix, which was the Common Clinical Dataset. So the common Clinical dataset got defined as a part of the Meaningful use program, and it was basically, you know, what we were, what was being set at the time was.

There is a certain amount of information that we want to have captured in these CCDs that are required to be made available to, to providers and provider, to provider exchange, let's say, as a part of a referral, you know, a, a referral transition of care, for example, and that that begged the question of, alright, I've got ACCD, which is just an XML document.

What am I required to put in there? Is there, you know, like a minimum set of data? And the answer to that is yes, it was called the common clinical data set, and it was about 21, 22 data elements that if you and I bill sat down naively and without any background and informatics and said, what are the things that we think most doctors would wanna have in front of 'em?

For that next patient who's walking in, we would on our own, come up with 90, 95% of the CCDs . It's very intuitive, right? It's allergies, meds problems, right? Very common kinds of things that are contained in the common clinical dataset. So when the new rule, the new administration came in and and issued the new role, they basically renamed the CCVS, the US CDI, which is the US core data for interoperability.

But it's the exact same concept. It basically said it's a core set of data that's required to be made available now through a fire API, so that when I request data through a fire, API, from provider A, from Mass General Hospital or St. Joseph's, or from Cleveland Clinic. I will have the same expectation that what I get back will be at a minimum, the U-S-C-D-I, so I can at least count on that and then they may, each of them may add more on top of that, but it's the common denominator that's required of every API to be able to make that available.

Are, are we getting, are we getting discrete data elements at that point? Yes. Yep. Yep. Interesting. And actually we are, you know, I mean, I think one thing for us to just, and this is a little bit of a salty of interoperability, but that's what this self podcast is about, right? Not just the superficial, but you know about the deep, deep understanding.

Is that even with, with CCDs, which are required to be exchanged, um, for certain transitions of care under meaningful use, and then promoting IM profitability, those were discrete data elements as well In a continuity of care document. The beauty of an XML document is that it's human readable as narrative, or it can be rendered as human readable, but it actually has the structured data in each of those, in each of those sections.

The problem with it is that. It's really clunky and you get that whole document every single time. So you might just want labs, but you have to get the whole document in order to get the labs. And some of those XML documents can, if you were gonna paginate them, could be dozens of pages long. And you're thinking, all I want was the labs.

That's it. That's, I didn't want all this other stuff. Um, so it's really clunky and it also was a real bear. Which one of the things we can talk about is how does this innovate, you know, the industry. Is that if you are outside the industry, you don't wanna be dealing with these weird XML documents, right?

You wanna be dealing with discrete data elements. So the data elements were always there, but in a very unwieldy and clunky form that really was a barrier to better and richer and cleaner interoperability. The beauty of the fire API is that it does allow that data element interoperability for me to just say, I just want the allergies.

Don't send me anything else. Yeah, we're gonna go in a lot of those directions. I, I, I jokingly, uh, refer to this as we could rename this podcast tomorrow as the education of Bill Russell. So I, my job is to ask. Some questions that just might appear like, I don't know what I'm talking about, but I'm really okay with that because with every podcast I get a little smarter U-S-C-D-I, the, so that's the core clinical data set.

I, is the government gonna keep expanding that or do we anticipate that health systems will come together like they did in Massachusetts, start to define other data sets around oncology and other things and or will those all end up becoming a part of U-S-C-D-I? Yeah, that's a great question. So the answer to that is, is actually both.

So the government is planning on expanding the U-S-C-D-I. So the idea of the U-S-C-D-I is that it is a, you know, it's a, it's a concept and it will continue to grow over time. So we start off with the U-S-C-D-I is this set of data elements which were, you know, derived directly from the CCDS, the common clinical dataset.

And that over time as we get more and more maturity and the industry gets, has more and more demands in terms of the kind of data they want to have interoperable the, the federal government through a standards development process will add to the U-S-C-D-I. So the idea is let's not do that overnight because there's a whole bunch of data that's not really mature enough right now to be made available in standards based ways.

But as we push for, as an in, from an industry perspective to make that data better and more standardized, that at the point of maturity of those. Then ONC would say, all right, for the next version two of the U-S-C-D-I, it will now include these additional elements. And the idea is that we'll continue to grow.

l dataset was defined back in:

So it's up from:

And there are other data that now got added to the U-S-C-D-I, but that's the first upgrade to it. So that just shows that it's been very static for a while and we really want to make it more as a growing thing. The second thing. Is that right now it's just clinical data that's contained in there. So there's no administrative or, you know, claims or payer related data in the SCDI.

So you talk about exchanging information. Anything that you know that a payer would care about. Like claims-based data, eligibility data, benefits data, explanation of benefits, data for patients payment. None of those things are ca are in the U-S-C-D-I right now. So even as we think about these fire APIs, it's like, oh, there's a whole bunch of data that actually isn't included in that right now because it's so clinically focused.

So payers are, are being required to share their data. Is that part of 21st Century Cures or is that. So it's derivative of 21st Century Cures. So 21st Century Cures Act Law itself didn't require that, but CMS as they were looking at ONC, creating the rule to implement 21st Century Cures CMS. Really decided, I think, and it was a great decision and something that was really beneficial to the industry.

Just said, you know what, we're gonna lean way forward into this. And we're gonna say that, that, uh, as a part of the regulatory authority that we have over any health plan that's regulated by CMS, which is not just Medicare and Medicaid, it's a commercial plans that are a part of the ACA exchanges in every single state.

And that starts to cover a whole bunch of health plans and a whole bunch of the market. They basically said, we're gonna require that you abide by these rules that came out of 21st Century Cures, because interoperability doesn't work if it's just the providers, the payers should be required to do this too.

So it wasn't explicitly required by 21st Century Cures, but through rulemaking, CMS basically. Put it under that umbrella and said, we're gonna write a rule that says that the payers need to abide by the principles and the concepts of what's in 21st century cure. So have we seen groups self-organize or is there an example of that yet?

Or are we hopeful that's gonna happen? And and where will that happen? Will that happen with maybe an academic medical center taking the lead? Or will that happen with industry organizations taking the lead? Yeah, no, that's a great question. Um, and it's actually all of the above. That's already happened and you named some of those organizations when you were doing, you know, the intro.

naut Project, which formed in:

I. A group of EHR vendors and large providers got together and said we should act ourselves without waiting for the government to try to get some market input into accelerating these standards to make them as ready as possible once they reach the point of being required by regulation. So let's try to, you know, accelerate that and, and make that stuff more mature so that it's ready for prime time, once it becomes right, once it becomes ready.

Uh, uh, a part of regulation and that was really focused on a group of stakeholders who were like a coalition of the willing around a certain set of things, and it was focused on clinical care. And provided a provider exchange or provider to patient exchange, but basically like electronic health records and what's in electronic health records.

That ended up becoming pretty successful. That led to the creation of the requirements that are now in regulation for the use of APIs and the use of fire and led to, for example, the specification that's in the Apple Health record. Is based on the Argonaut project, um, specification that got created out of that.

But one of the things that we recognized as we were starting to reflect on the Argonaut project was that, that not only the out the output of what we did was important, but it was actually the forum. The approach that we took that this was really just something that we noticed as we, it wasn't as if we had all this in mind at the beginning.

It was more just people getting together saying, Hey, let's take the next step and do some stuff. But we recognized that, oh, this market-based thing is really important. And one of the things that's really important is just having focus around something that you really want to do. And so that led to like the Da Vinci project.

Moving forward where you had a group of payers who said, we're really interested in payer oriented use cases, and we wanna focus on that part of fire that's really important for payers and get together and collaborate among competitors, getting together and saying, let's collaborate around these standards to help move everyone forward.

And so the Da Vinci project then came, and then the Karen Alliance. So DaVinci is focused on payer type exchange. The Care Alliance focused on, um, commercial payers and, um, patient access from, from payers, first and foremost, but patient access generally. And then you have a gravity project, which is focused on, on social determinants of health.

You have Codex, which is focused on cancer data, just as you're describing. There are a lot of these communities that are now forming all with an eye towards saying, I wanna accelerate this part of the fire world so that I can make it mature faster. Ultimately, not only for this purpose, but ultimately with one part of the goal being that ONC would say, ah, that cancer data is now mature enough and standardized enough that we'll make that a part of the U-S-C-D-I now.

And so you start to get that feeds into a process where the SCDI starts to expand faster, um, than it would otherwise because you have this market-based organic activity helping to accelerate things that people find are important in the market. , I was in some of those rooms early on where, uh, you, you know, niche would grab you or Halamka would grab you and say, Hey, come to this session.

It would be in a side room for hymns and they'd be talking about fire and where this thing's going and whatnot. But that wouldn't be the case today. The fire has a, an awful lot of legs and it even had it before 21st Century Cures. A lot of people were seeing the promise of it. And so I want to talk about two aspects.

One is, do we anticipate this is the foundation for really a, a renaissance and, and digital health, that we're going to open up this data to this world of developers and, uh, in collaboration with health providers and, and even payers and just see a whole new set of applications. I that, that's the promise of it, right?

And do we anticipate that happening? Yeah, I think it's already happening and I think it's gonna really start, you know, happening in exponential ways as we, you know, start to see that ecosystem start to. But I guess it, it is a, it's an interesting question. 'cause on the one hand, fire is just a standard, right?

So you would say it's just a standard. And we had HL seven V two and then we had CCDs. It's like, how could, just a technical, because my alternative is I have to go through, I have to go through this app store and I have to pay significant amounts of money. It's challenging, it's difficult, it's costly, so, right, right, right, right.

Yeah. And, and so you ask yourself, how could a technical standard. As you and I discussed before, this isn't a technical problem, right? It never was a technical problem. It's all about business and. The socioeconomic climate of healthcare are not about, you know, the technical standards or lack of technical standards, but the reason I think that fire itself actually is really important, and we're starting to see that is, is a couple of things.

One is that it's, uh, very, it's really democratizing in a way because it is much more aligned with the west, with the way that the rest of the internet economy works. And so you don't have the, as I was describing before, developers, most of whom live outside of healthcare, right? As much as we like to think healthcare is the fulcrum of the universe, most of the internet and most developers live outside of healthcare and any of them who looked at healthcare and thought about making a step or two into healthcare, like Google Health, early on, they had the patient portal at Google Health.

t's healthcare specific. It's:

There's no way in the world they're gonna do that. And so they, they just stayed out, right? They stayed outside on the periphery. And I think if we've learned nothing else from the internet, crowdsourcing is everything, right. The more eyeballs and the more people you have working on stuff. The greater the odds that really cool things are gonna come of it.

And so it's democratizing in that way and that restful APIs are the way the rest of the internet economy works and it opens it up in that way. I think the other thing that's really important is that it because of the data, the data element transaction that we're talking about, it allows for really refined and rich applications that can be really targeted at things that, you know, that drive people's lives.

An app that is just focused on your allergies with whatever other comorbidities you have, right? And being able to a developer to be able to create that kind of app that just tries to get that data. Any developer who would, was stuck in a world where they would have to get ACCD every time and sift through 20 million.

Lines of XML code, , and all this other extraneous data that they didn't want in order to be able to make that app work would say, I'm not gonna do that. There's no way that I can make that app work. But if you tell them that there's a fire, API on the other end of it and you can just get the data you need to have your app work.

I think that's, that is, you know, enticing to people. And is, is a part of that flourishing of that app economy that we're just at the, you know, at the threshold. So the, let's see, how do I say this? The arguments against the final rule had things in it or had people saying things like, uh, what about the Chinese hacker app, which is going to, are you gonna get me or my parents to download it?

They're gonna get access to my medical record. Those kind of things. So there's that aspect. The other aspect was, hey, we just moved it from a HIPAA compliant data store to Apple, which is technically . Not a, not req, not under hipaa. And so that data stores outside of it, I have, have, are those arguments falling by the wayside or, or have they been addressed?

Neither

that those are really big issues. And, and just to, just to put a fine point on what you just said, 'cause you know, it's a, it's a great question. That's a really important question, is when patients. Start to access the data on their own. See Apple Health record, for example. One thing that now I think just to be fair to Apple, apple does a fantastic job.

Of making sure that patients understand what's going on, right. But they do that as a part of Apple policy, not because the law requires them to, and there are lots of other actors out there who may not be as good actors as Apple has been. Apple, I mean, apple has staked their claim on secure, so that's their, that's that's part of their brand though.

Even they don't have access to the information. So Apple literally. Couldn't tell you if you ask Apple the question how much, you know, how many patients have downloaded their medical records onto their, onto the iPhone? They actually literally can't answer that question because they're not a part of that transaction.

Right. It's a, it's all between the device and, and, uh, through the API and that doesn't go through that central infrastructure quite in the same way. But the point is that the minute that I as a patient download that information myself, it's now no longer covered by HIPAA or no longer protected by hipaa.

And that's really confusing to 99.9% of people in in the country . They think that HIPAA protects medical data, right? Of course it does, but HIPAA doesn't protect medical data. HIPAA only protects the data that a provider has or another, or a payer has when it's in their. But when, when they're in control of it, and it covers their release of the data.

But once it's in your hands as a patient, if someone else hacks in or you make the data available, one, one nightmare scenario is you get the data onto your phone, unbeknownst to you, you think it's covered. It's not. And the data is now sitting there on your phone and let's say a recruiting app. You download a recruiting app as well.

You're looking for a job, right? And you download a recruiting app. The recruiting app notices in on the backend that, Hey, you have medical record data on your phone. Can we have, would you like to make some of that data available to the recruiting app to demonstrate your productivity potential to new employers?

And somehow it extracts information about some chronic condition that you have. All of a sudden you're not getting any, any requests for your resume and you don't know why. HIPAA doesn't protect that there is no protection actually in the us. GDPR in Europe protects that, but in the US there is no protection, uh, against that.

And I'm gonna guess that the vast majority of patients have no idea. I. That, that's the kind of risk that they can face if they don't, uh, aren't really careful about their data. Now, that's a nightmare scenario, but that's absolutely, we trade as individuals. We trade our security, our privacy for convenience all the time.

Right? That's what we do. Every time we, every time we do a search. . We either know or we kind of know, but we pretend we don't, that oh, I've actually got a beacon on my head as I go through the internet and Google knows it and all these other places know it. But damn, I, I really wanna buy that, that patio heater,

So I'm gonna trade that off for the convenience of just being able to order it and have it delivered to my door in the same way you could imagine an open table. I'm not saying OpenTable is doing this, but what, what would stop someone from thinking about the great convenience if I had celiac disease?

If I had real food allergies, being able to say, Hey, I would love to upload that part of my medical record, or give access to OpenTable so that they, when I make a reservation, they tell the restaurant that, Hey, this person has celiac disease. Right? People do those kinds of convenience trade-offs all the time.

It's like, oh, now all of a sudden you've just allowed your medical record information to remain available over the internet with no protections. That's the kind of, that's that kind of concern people have. Just the last point, the Care Alliance is working on and has created a code of conduct, an industry code of conduct.

that the idea would be that, well, there's no regulation that steps in right now and protects that information outside of the walls of hipaa. But maybe there's an industry code of conduct that, you know, that we can get companies to sign that at least will, you know, have them in a non-binding way, but publicly committing to the protection of data, um, that's made available on their app.

And that's at least one step to try to close that gap. Well, and this is the brilliance of Apple's strategy, right? So every time somebody, every time something tries to access the camera or access the microphone or access or the medical record, I guess you, you would get that alert and you'd be able to see that.

And they might even have a. I know in the case of the camera, there's a little, little circular thing that shows up if an app is actually accessing your camera at a certain time. And, and so that's the, the brilliance of their strategy is, is to know who's accessing that. But again, that's not a hundred percent of market share that in fact, that's only 60% of market share in the U us.

And globally, obviously Android has more market share and I'm not sure because I'm not an Android user. I'm not sure what their protections are against that kinda stuff, but I think, we'll, I, my hope is that we're gonna see an ecosystem sort of evolve that puts a bubble around that information lets us know when we're sharing.

It lets us know what pieces we're actually sharing. And I guess that's the, the code of conduct and maybe we'll see A-G-D-P-R kind of thing in the us. I. I don't know. Yeah, I don't either. But that is a big gap and it's a real concern that, uh, has been a concern for, for a few years now. So, so you moved to Arcadia te, tell us about that move.

What does, what does Arcadia do? I. Yeah, so Arcadia is a population health management, um, and value-based care technology vendor. So what we do is we do analytics and other applications to support provider organizations, accountable care organizations, payers, and others who are, um, in value-based care. Who are trying to do everything they can to move to more value-based purchasing types of approaches of healthcare, and to provide the foundation, the analytic foundation and the application foundation for them to be able to do that.

So being able to take in clinical and claims data, analyze that patient data, um, to be able to identify who's at risk, what are the risk ratifications, how do we measure quality in a better way? How do I identify where there are gaps in care? And how do we then deliver applications to those front, those people on the front line, like care managers who can then reach out to patients and help them come in and get the care they need to be able to fill those gaps in care.

So end-to-end product to take data in and then deliver applications to the people at the front lines who, who make those kinds of interventions. So are those applications like just a set of tools like R and that kind of stuff? Or is it like . Like a package set of reports and analytics tools. Yeah, it's, uh, both of those.

So we have, we have a couple of different ways that people can consume that information. So we have something, as you suggest, like our, we have a product called Foundry, which basically allows a provider, it makes their data available to them so they can use whatever tools they want, SQL R or whatever.

Their own data to be able to do any kinds of, you know, an analyses that they want to do with data marts that we create, you know, for them from their data. So they can do that if they want, if they have some of our, a lot of our more advanced customers will do that. They have their own data scientists who wanna come in and just wade through the data, which is, which is fine.

We also have reports that, that we can. Publish on their behalf through a product called Bindery that basically will allow them to define the set of reports that they want to be able to deliver to their providers that show how their providers are doing on different dimensions of care and different dimensions of quality and performance.

And to be able to distribute those to them in static form that they can at least say, ah, okay, here's my last quarter report. I can see how I did against all these measures. I can do benchmarking all of that. And we also have just interactive user interfaces that people can come in and dynamically look at data so they can, you know, look at through applications, they can look at their quality measures.

There are cure man. There's also a cure management suite that allows them to come in and look at risk stratifications. Look at patients who are, create cohorts of patients based on criteria that they'll define or they can, you know, use the ones that we have, um, you know, predefined and then be able to say, all right, here are the high risk patients for certain types of risks that I define, and now let me generate campaigns for example.

They can either, you know, have care managers on their own go out and do that work, or in addition to that, they could generate campaigns to say, here are the 353 patients who I know need a flu vaccine in the next three months. Let me, with the push of a button, send out an email to all 353 of those to generate that campaign to, you know, try to bring them into the offices.

So it's got that full end-to-end capability with a wide variety of ways for them to be able to access data. And then increasingly what we're doing is moving that to a platform so that people can actually bring their own applications to it so they don't have to use our applications. They can do a fire, API or a set of fire APIs, say.

Hey, I, I love the way you curate data for me and the other value add that you bring in, but I have my own applications that I'd like to use. I don't wanna be stuck with yours. So we have fire APIs that allow them to do as. It's interesting. A lot of this stuff wouldn't even be possible without the interoperability work you did before.

I assume you guys probably, you're probably using HL seven, but you're probably scooping whole data sets as I would. I would imagine you're probably using fire, you're probably using anything at your disposal to aggregate that data. Is that. Pretty accurate. That's a Yeah. Yeah, yeah. That's a great intuition that you have and it's absolutely right.

Customer experience as ACIO, you can't say, I'm just doing HL seven. It's like the world is a messy place. So yeah, we have a complete portfolio of, of a whole bunch of proprietary connectors that we use. For places where if you have direct access to the data, to the database, like if it's an on-premise, CHR, for example, we can just connect it up with on the backend with like an ODPC or SQL extract kind of software agent that can just pull the data out.

That's easy and fast, but increasingly with more and more cloud hosting of systems provider, him or herself doesn't have direct access to or can't provide direct access to their EHR. ANS standards get better. We're able to say, oh, now we're in a place where HL seven B two CCDs and increasingly fire will be approaches that can get us more and more of that data.

Part of the challenge of that, as we alluded to before with the U-S-C-D-I, is that as you think about all the needs that are required for population health and value-based care, there are some types of data that aren't a part of the U-S-C-D-I and but that are really important to be able to be able to do appropriate care.

For example, scheduling data. It's hugely important, right? If I know that a patient is coming in next week and I know that patient has two gaps in care, you can imagine the importance of that to a care manager to be able to say, get to that provider and make sure they know that when that patient comes in, hit 'em up with, do you want a flu vaccine and do you want whatever else?

They're missing scheduling data is not a part of the U-S-C-D-I, so how do we get that additional data out of those systems? Often it requires separate types of approaches, seven, two or even proprietary approaches or flat files if we have to, we just have to be very mercenary and try to do it in whatever way we can.

Chief Alliance officer, what, what, what exactly is that? I negotiate treaties like Alta and . It's me and Churchill and Roosevelt and, you know, Stalin sitting at a table. Um, now I really, I work on partnerships, on strategic partnerships. Um, in particular we have, we have a, a great growth team, um, that works on what you would think a growth team works on, which is sales.

And we have a great strategy team that works on the company strategy. And somewhere in the gray area, there are things that aren't about a direct sale. And that aren't pure strategy that we do internally, but you know, that are strategic partners, relationships that we want to have with other organizations that are about long-term mutual shared benefit for a set of things that we can go to market together with.

And so that's what I work on and part of that is with other companies. Like we just announced a, you know, partnership with Patient Ping, for example, and, and with Aex and we have an ongoing partnership with, with AWS 'cause we're a big AWS user. So we have a number of those things. And when we're growing those.

But it's also the connection to those national level activities that, um, that you described before. Being able to maintain, uh, a presence in those national forums like the Sequoia project like HL seven, to be able to bring that to Arcadia, but also help to bring Arcadia's experience to help better help inform what's going on at the national policy level based on the ground experience that we have.

Mickey, I wanna, I want to thank you for your time. This is a, this is a phenomenal episode. I'll probably go back and listen to it a couple of times. Just, we covered so much ground and so much of what is going on today, so it's, I'm really excited to have this conversation. Is there a way for, uh, if people wanted to follow the things you're doing and, and those kind of things, are you active on social media or other places?

I am, yeah. So I am on Twitter at Mic one, I think is my handle and certainly people should feel free to reach out to me directly, mic Dr. pathy@arcadia.io and, and I occasionally blog on the his talk site and in other places as well. So, um, very much look forward to continuing the conversation with everyone and you really appreciate your time.

Bill. This has been fun. Yeah. Thank you very much. This has been fantastic. That's all for this week. Mic is fantastic. I hope you appreciated that show. Don't forget to sign up for clip notes. Send an email, hit the website. We wanna make you and your system more productive. Special thanks to our channel sponsors VMware Starbridge Advisors, Galen Healthcare Health lyrics, sir Healthcare Pro Talent Advisors, HealthNEXT and McAfee, for choosing to invest in developing the next generation of health leaders.

This show is a production of this week in Health it. For more great content, check out the website this week, health.com. Or the YouTube channel if you wanna support the show. Best way to do that. Sign up for clip notes, participate in the referral program, send it out to your peers, and let them know that you're getting value outta the show.

Please check back every Tuesday, Wednesday, and Friday for more shows. Thanks for listening. That's all for now.

Chapters