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.

 Before we get going, I wanna make you aware of one thing. We've launched clip notes. Now you know that. But let me tell you what's gonna happen. You're gonna get busy and you're gonna miss a couple episodes. You're gonna wonder what happened. Wouldn't be great if you had the email for each episode that had key moments and bullet point format so you could just view and see what was said on the show.

You could see who was on the show, and then it had one to four short clips. . Of one minute to about three minutes of key moments from the show that you could share with your team or that you could just watch real quick. I know that happens to all of us. I know we get busy. That's why we designed CliffNotes.

It has been a huge success. We have over 500 people have signed up in less than, uh, I think five or six weeks at this point, so we're really excited about it. You can sign up as well. Sign up on any episode page on this week, health.com. Or send a note to clip notes at this week in health it.com and it will kick off an automated workflow to get you signed up.

Welcome to this week in Health It where we amplify great thinking to Propel Healthcare forward. My name is Bill Russell Healthcare, CIO, coach 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. This episode and every episode since we started the C Ovid 19 series has been sponsored by Sirius Healthcare.

Now we're exiting in that series, and Sirius has stepped up to be a weekly sponsor of the show through the end of the year. Special thanks to Sirius for supporting the show's efforts during the crisis and beyond. I've been wanting to do an episode on fire, but more specifically, I've been wanting to do an episode on developing an application around fire for quite some time, uh, and I just haven't gotten around to it.

And in today's episode, we are going to be really diving deep into fire, and I'm excited to have, uh, Dr. Kevin Malloy with the, uh, MedStar Innovation . Institute for, uh, Medi MedStar Institute for Innovation, MI two, uh, on the show. And I became aware of him. He and I connected. He's a, a listener of the show. We connected a little while back.

He has shared some stuff with me. Uh, he has since produced some videos. He, uh, has some meetups that he pulls people together who are looking to PR to write fire apps, and I thought great opportunity to have a conversation around what it takes to develop a fire application in healthcare. So here's the show.

Hope you enjoy. All right, today I'm going, we are gonna explore a topic that I have been very interested in for a while, and I found a, i, I don't know if he'll be offended by this, but I found, I found a doctor who's also a nerd, an informaticist. Uh, Kevin Malloy is a doctor. He works for the, uh, he works with the, uh, MedStar Institute for Innovation MI two.

And, uh, I'm looking forward to having this conversation. We're actually going to walk through the process of developing my first, so Kevin, welcome. Yeah, thanks for having me. I'm a longtime listener. Actually. I think what you're doing is great. I appreciate that. I'm, it's, I actually recorded my 300th episode today, so we're recording a little bit before it will, will air our, our episode will air.

But today is actually the day September 8th, we aired our 300th episode. Hard to believe. So thanks for being a listener, but I am, I'm really jazzed about this 'cause some people know this. I was ACII am ACIO, but I'm really ACTO by training. I started my career as a developer. Now we don't write many dBase apps anymore, or dBase three or dBase four apps, or Fox Base or Fox Pro Apps.

But, but I still have some of those skills. And I was wondering, can I translate some of those skills into, uh, where we're going? But before we get there, give us a little background of your background with regard to fire development and what you've been doing. Sure. So probably like you self-taught in kind of web like HTML, JavaScript.

When I was in med school, I was fortunate enough to be able to learn how to code in a way with a group at, uh, MedStar Health, led by Mark Smith, who's now the Chief Innovation Officer at MedStar Health. He's an ER doc, and I randomly reached out to him being like, I'd like to learn how to code, and he said, sure, come over and.

We'll have somebody teach you. So I did a month with him and I swore I'd like never do it again. I don't know if anyone else who you're like, uh, it took me like a month to get the number two from the database onto a webpage or something like that. , and I was reading the JavaScript Bible. I don't know. It was like this thing that was this big.

And it was right around like YouTube videos coming out where you couldn't learn to code on your own and stuff like that. But I swore I'd never do it again. But then I ended up doing residency, um, inside of his emergency department and I started realizing that there's a lot of cool stuff I could make.

For myself when I'm practicing clinically to, to just make the job easier and keep patients a little safer. So I started making stuff in Web and HTML in a system called the XXI at that time, which you had invented and it subsequently got sold to Microsoft and was Amalga. Now it's Carradine. So I started making web stuff flash forward, uh, to now, um, I still work at MedStar, but the web technology stuff is still applicable.

Because of FHIR. When Cerner and Epic, a lot of the stuff behind the scenes is actually like web based in a way. But FHIR is like 100%. It lends itself 100% to web as well as iOS and Android and that type of stuff. So what I do day to day, I still see patients clinically and I'm still able to like dog food, my own stuff that I make.

But I also, um, chaired a fire steering committee at the health system. Yeah. About quarterly we meet up. With the CIO, the CMIO, the CNO, kind of make sure our APIs are on track. I also host a bunch of educational sessions throughout the health system, and the idea with those is that our goal at the Innovation Institute is to catalyze innovation.

So we don't necessarily get consumed five years from now and probably not gonna be doing fire anymore, um, because it's just gonna be the way things are done in the organization. But what we do now is we catalyze and one way to catalyze is by educational events for people who are coders out in the enterprise.

So like people from radiation oncology or radiology or custom dev team or like core team, that type of stuff. Just to have an educational event for them to learn how to. Use fire and kind of incorporate it into their, yeah. And now, and now you're doing meetups on helping people to Yeah. Yeah. So I, as a little side project, I'm trying to teach patients how to code to use the fire APIs.

'cause one of the observations, I don't know about you when you were doing dBase and stuff like that, the. The best way to learn is to have a problem and patients have the problem of whatever's going on in their healthcare journey. So I try to teach 'em how to, if they have a problem, how to actually use fire to maybe help them in some way, or a family member.

Well, well give us an idea of some of those problems. So what are some examples of the applications that you've written and what are some problem sets that lend lend themselves well to fire where it's at today? Yep. Yep. One thing, probably the starter, and where we started with this was just installing like, uh, inside of your environment, the, the basic growth chart app, which is like a provider facing app where providers in Cerner Epic and they click a button and it opens up this fire app and you don't know you're using a fire app, but it's code that's written by, uh, Boston Children's and it's free and it pulls in the height and weight and makes this really nice, uh, graphical user interface.

For the doc to clot out the, the growth chart for the patient. And then there's like a parent facing one, so you could turn the screen around and they can look at it, and then you can print it out for the parents too. So a lot of people start out, I think, and we did too, just with the growth chart app and like an open source available.

App that you can plug into your EHR for providers. The other thing, people I think probably then move on to, um, some kind of single sign-on stuff. And the way fire works, it's actually SmartFi. There's a way to authenticate and then there's a way to get data out. And what you can do is use that authentication mechanism to embed something that you are.

Here on two Macon providers go into like a browser window and enter their username password into, and then pull it up over there. So an example at MedStar was, one of the really early things we did was, uh, embed our antibiogram, which was this little website that was outside of our EHR. We embedded it within the EHR and you just click on a button and it opens and you don't have to put a username, password, or anything like that in there.

Some other stuff we've moved on to is we are using fire for research grants. So there's a large human factors, uh, group at MedStar Health that got a LEAP grant from the Office of National Coordinator. And what we were able to do with them was to embed. Uh, risk calculator inside of the provider's workflow.

So in Cerner there's a, a little workflow thing. You can scroll down and one of those, they usually have like meds and conditions and like upcoming appointments, that type of thing. We're able to put a box there that was actually a fire app that calculated their, uh, cardiac risk score. So you're using it a fair amount internally.

You're Mm-Hmm. the same. , quite frankly, the same way we used to build access databases is what you made. It just sound like, it's like not quite as insecure and they're not quite as messy in the backend. Yeah. But almost as easy it's sitting there going, look, if you know how to access APIs and you know how to create a, a single sign-on.

You're gonna have access to this data set, and then you can embed it wherever you need to embed it, and you can launch it on a mobile app or on a, I mean, anywhere you need to, uh, launch it. That's what you're making it sound like. And again, you're educating me, so feel free to correct me. No, no, no.

Absolutely. I don't know if you ever went to any training courses at like Epic, like I did phy. Position builder and I went there and it struck me that there's this whole educational system built up around training and maintaining your EHR because it's so custom. The cool thing about fire is that it's all just regular web technology.

If you have a regular web developer, you can just point 'em at this spec that's, um, online and they can go at it. They don't really need. They, they need maybe a little like bump of energy to get 'em over using it. I've taken people within an hour, I took one of the radiology people and now he's integrated fire data into the pacs.

He knows a bunch of web, so it's, it's not, I think one of the things that is unique about fire is it's existing stuff that people already know how to do. It's not like I gotta go and do something about M page development or CL development. It's just. Alright, so you're gonna walk me through this, uh, and we can go in two directions.

I'm gonna go in the easier direction first. Okay. And that is, I work for a health system. Sure. So I work for a health system. We are, uh, we're just like everybody else, so we have multiple EHRs. We have, we have a clinically integrated network that has some Cerner. Our core system might be epic. Yep. Uh, we might have some touchworks and that kind of stuff.

Uh, but I have this idea for presenting a, a set of metrics of some kind across the entire clinically integrated network. What questions? So I'm a physician. I'm sitting there going, oh, I'm listening to this podcast. I know that I could do some things with fire. Yep. What kind of questions do I ask at this point?

What kind of questions can you ask? Fire? It's good. No. What kind of questions would I ask my health system? Like where do I go? How do I access it? Does every EHR automatically have fire turned on? Is there certain versions of fire? Where? Where do I. Yep. Yep. But if you're at a Cerner Epic shop, you just go to fire.cerner.com or epic cerner.com, and it has all the documentation publicly available to tell you how to use the authentication and what data is in the APIs.

You have these APIs somewhere, they are probably turned on because you're probably attesting to . MIPS information blocking stuff. So more likely than not, they're turned on. If you have physicians or parts of your team that are interested in building stuff with it, really you just need to check out the documentation@likefire.cerner.com or fire.epic.com, and you gotta, like, internally, you gotta make some stuff.

Like in Cerner's and Preme, you gotta change a few things to get stuff to show up, but it's relatively. Not a heavy lift. So, so it, there has to be a target, right? So internally, I'm going there to get the documentation, but internally at MedStar? Yep. There's ARL or a target to. To get to the data or get to the APIs, correct?

Yep, yep, yep. So, so MedStar will have its own fire, URL, and let's say Beaumont will have its own fire, URL and Hopkins will, you can actually see some of these if you're interested in 'em. If you go at least for the Epic shops, they're at o Open epic.com and you can go to Fire Endpoints and you can see all the patient facing endpoints.

They're not gonna be the internal provider facing endpoints because. Fire, depending on who you are accessing it. Um, we'll give you different information, like it'll give patients the ability to read their information, but providers, it'll give the ability to like, create and as well as read information.

But the URLs themselves, at least for patient access, are publicly available for Epic. I think Cerner's gonna be coming with that in a little bit because it cures for the provider. One you probably have to reach out to, um, like your. Internal is team, although you could figure it out. We have a lot of IT listeners right now who cringed and a lot of other people are like, yeah, tell us how to do that.

Yeah. Uh, , so you did, yeah. Yeah. The, the interesting thing about uh, fire that, and I remember we were talking once about plumbing and how fire is like plumbing, and one of the interesting things about fire is you're probably thinking of your organization as everything behind your firewall, and there's a few public access, like points and whatnot.

But by its very design, fire is, has to have a public access component so that patients can access it. So your provider APIs are probably just piggybacking off of those in some ways. So a lot of this stuff is beyond your firewall and, and it's probably a different way of thinking about your EHR and where it's like touching and where your plumbing is going.

'cause it's going out into the, in the, into the . Worldwide web, which is not to say that it's, this is like something new for the worldwide web Google. Yeah. We've been doing, we've been doing this for. Eons essentially. Yeah. And it's really just OAuth two plus rest API. That's all that this essentially is and it's technology that people already use every day in a very public fashion.

Alright, so let's level set here. It not all data's available, right? What kind of data sets might not be available? Yep. Yep. Why don't I step back and just say that just to underscore point that there's three main roles to get data in FHIR, right? There's gonna be a patient facing role, so that's me. I'm a patient.

I log in to FHIR with my us, my patient portal, username, password, and I can read data about myself. Right now, I currently can't write anything, but I can read stuff out and this is what . Apple Health uses, right? The Apple Health integration that a lot of health systems have uses this patient access. I can only see my own data.

I can see stuff like radiology reports, labs, vital signs, stuff that's in the US CDI, the US core co core data for interoperability, all that stuff patients can access. The second role is a provider access scenario, which is a physician. I am either in my EHR or I'm not in my EHR. And I can use fire to get the same stuff.

Patients can get labs, vitals, radiology reports. Plus I have these other abilities, which in Cerner is I can create an encounter, I can create a patient. I. I can patch a patient and update that their address is no longer valid. I can create clinical documents and have those appear in the normal places where I would expect those appear to appear in the EHR.

So the provider access role, um, has access to pretty much all the information that patients can access, but the ability to create a lot of things. So the patient, we're not creating, we don't have create, create rights yet essentially. No, no one. I, I haven't seen those. Um, yeah. Alright. So I wanna go back to something, 'cause you just said the way that Apple does this, that's probably the easiest mechanism, right?

So I can connect really to almost any health system in the country as long as they provide a portal, because I'm gonna use that portal authentication for the patient, and then I'm going to. I don't know, create new ways of viewing that data, create new ways of utilizing that data through my app. Is that close y?

Yeah. What I would say is that if you were doing it with Apple Health, like Apple Health internally on the iPhone has its own set of APIs that's interacting with the data. It's stored there. If you're a health system and you wanna create your patient portal, V two. Like basically you would have 'em sign in with the same username, password, and you'd have access to a lot of the same things you can do in a portal, except the messaging, the docs, there's the ability to create appointments and stuff like that.

So one way is, yeah, you could put it on a device, on an iOS device and then build on top of that. Um, using Apple's, APIs or if you're a health system that's very forward, uh, looking, what you could do is just roll your own new V two of your portal using these APIs, the same username, password, and you could create novel visualizations.

You could bring in novel APIs. You can create different experiences focused on different patients. In particular using a lot of the data that you're actually gonna see in the, in the portal are, are you finding that health systems. Are struggling with this concept of, 'cause it feels like you've just created a window into the EHR dataset.

Yeah. Which is, as we know, it's just loaded with a lot of value and those kind of things. Or are they seeing it more as we're unleashing the potential of the creativity of the health system to, to do things that we just, we'd wait too long for Cerner and Epic to do it, and we can now do it ourselves. Yeah, you, you, I can really only speak internally about like where I work, but I think it's seen as a, a driver of innovation potentially to direct to patients as well as provider experiences.

Yeah. It's really interesting that you can, uh, I, I, I wasn't under the impression that you could create, I guess through the provider side, you can actually create things that really does open up a whole new host of things. And actually it reminds me of the conversation we had with John Halamka where he said.

They, for the ax, the fax initiative, they redirected all their faxes to, to AWS fax server essentially. Oh, yeah. It took all the stuff in and it, it took all the data and it was just searching for prior authorizations or some aspect of something. Yeah. And then once it found it. It would then go into the record and use fire to just check one box that says authorization received.

Oh, okay. Cool. No hands touching. No, it was really elegant. But that's the kind of thing you can do. You can sit back and go, oh look, yeah, I could check that box. I can, we already have a ton of technology that's available to us in the cloud where we, we can scan these documents, we can pull it, we can pull out the unstructured data and the structured data.

We can then review that and we can even apply AI and machine learning to it. Do things in the ehr. Now we, we've gotta be careful. Obviously we're dealing with the medical record. Yeah. But I think something you're pointing out is that fire itself lends itself to this automation process, right? Because it's standardized across the hrs and um, the spec is open and what you can do with it is you can just go, you can look on fire.turn.com, fire epic.com, and you can actually use a lot of this to automate stuff that's happening in your cloud.

I would say that's absolutely correct. So it is a standard, but we have different versions of the standard is. Yep, yep, yep. So is there a difference and which one are we most likely to see today? Oh, yes. So there's different flavors. So there's something called DSST U two, which is a draft standards for trial use two, which was the original one, which most of the patient facing applications use today, like Apple Health uses it.

That was the earliest. Version of this. Then there's something called SST three, which is a standard trial use three and Epic uses that. Cerner doesn't quite use it. Um, then there's something called R four, which was release four, which is the Cures. Final rule says that within two years, everyone needs to be on R four, right?

It's actually backwards compatible. So if you write something that is doing AI OCR in the cloud and shoving something into your EHR. If you write it in R four, supposedly five, 10 years from now, that will be compatible with R 10 or whatever. So R four is like the most backwards compatible, it's not supposed to break going forward.

Um, now are there, are there any rules or context to how I'm gonna use the data so I can now use fire to get access to the data? Mm-Hmm. , this is one of the concerns, right? I could just suck a lot of data out and then start to utilize that data. Yeah, the fire is really good for kind of one patient at a time scenario.

Not necessarily I'm trying to get a population or like I'm trying to get all the patients who have CHF in my organization. Those, um, queries of patients, like multiple patients at once is supposed to be supported by bulk fire, something that's supposed to come out probably within the next three years or something.

It's in the final role somewhere that the EHR vendors need to offer this. But currently what it's good at is like one patient at a time. So if you were, if you were sending something to AWS for some AI thing, OCR text to, what would it be called? Image to text? Yeah. And then shoving it in one patient at a time.

That's something fire can do. But if you're looking to pull a cohort of people who had that done to them, that would be hard for fire to do. It's better at one at a time. How does the community look at this point? Typically, you have a development community around, if I were learning Java, I can find a ton of communities and resources around this.

Mm-Hmm. , uh, is that starting to really form around fire at this point? There's, there's a bi-yearly conference called Death Days that's put on by a firely, and some of the Cerner engineers I know go there. They do talks. There's, it's this international conference where people who are the nerdy people about fire, like all congregate.

And, uh, they also have a YouTube channel. If you check out Firely on YouTube, they have a channel where they post all the talks and like Josh Mandel has a talk on there from the last dev days, and some of the people from Cerner have stuff up there about like CDS hooks and all the stuff that they're working on.

So there is a rather strong community, um, behind it. So you, you've put some stuff out there. Uh, yeah. Yeah. So talk about some of the things you've done. Yeah. So I won't say that they're very successful, but one of the things I'm trying to do, and we talked about it, was you're comparing yourself against the wrong things.

So people say to me, how many downloads of your podcast you get a day? I say, well, about between 800 and 900 they're going. Oh, you're know Joe Rogan. I'm like, yeah, but there's only this many people who care about health. It Joe Rogan's smoking pot with, with Elon Musk. That's entertaining for everybody.

That's a different, well, now we know what you need to do on your show. . Exactly. Get Elon Musk on here, smoking pot. They don't, they don't lose my health it audience to me. What's he talking about? You'd be surprised. Yeah. So I put this thing out there and it's called patient dev, and the idea is that there's.

People who are patients or, or family members, people with patients with like chronic illnesses or going through something. And most web developers know how to use fire. They just need a little push to, um, actually start using it. So I have a bunch of videos there. It takes about 30 minutes to go through 'em about how to make a patient facing app and like just walk you through registering your app and um, here's some sample code you could use to actually create it.

I think, I think a lot of the innovation from the patient facing stuff is gonna come from family members, patients who have these problems that they can solve more readily. It makes me think of the makers movement. Every once in a while there'll be somebody talking about, Hey, I was able to do this circuitous thing to get all my data from this, and I grafted out and I realized that this was associated with this.

I think those are gonna be, those are trivial to make with fire, especially with, um, healthcare data. From a major health system or LabCorp or anywhere like that. So I'll tell you one of the, one of the panels that I didn't feel like I belonged on at one point, I, I, Anish Chopper was, was moderating Leash Pirro, who was, uh, with Glen Tolman back in the All Allscripts days and now does Seven Wire Ventures was on it.

The founder of Box, whose name I can't remember right now. But he's colorful character, really fun and, and whatnot. Anish is, is he's bringing the audience in. So everybody, it's at the, uh, health Evolution Summit and, and the audience is getting into it, and this woman stands up in the back and she goes, this is the problem I need you to solve.

And we, we had a topic, we were talking about something else, and the entire topic devolved into interoperability. Your EHRs are killing me, essentially, is what she said. And, uh, her daughter had a chronic condition. She had been to Mayo, she had been to, uh, UCL, she'd been to multiple organizations in Southern California, uh, where I was the CIO.

And she was essentially saying, look, I, I now carry two to three binders, or I'm working on my third binder, but I carry two binders with me, and it's the complete medical record because you guys can't share it amongst each other. And then I go to somewhere else and she goes, I'm just terrified that someone's not gonna read the whole binder.

And I, what I, what I was afraid to say to her is, you know what, almost no one's gonna read that whole binder. It's two binders already. It's too big. Yeah. Yeah. But that lends itself, that specific scenario is what FHIR was created for. Mm-Hmm. the patient who's saying, look, I'm going to 10 different organizations.

You haven't figured out how to share my data. Let me gather all my information and create an app that I can share it with the physician when I get to whatever location I'm gonna. Yep. Yep. And, but there's probably gonna be a whole suite of tools for providers to visualize that data in a very quick way.

They're going to need to become essential with all this interoperability happening. We tried at MedStar to do this in er 'cause I, I work in er, like, my observation is like, people come in. And they have, they're a MedStar patient and they have 300, 400 documents in free text, like just sequentially ordered or time ordered, and you can only show 20 at a time with an EHR, but maybe they're there for chest pain.

And the, you know, the thing that's relevant to chest pain, like they had a blood clot five years ago, now they're off anticoagulation. That is buried in like document number 356 or something like that, but it's not on the top 20. And I'm a. You know, if I had all the time in the world I could look through and try to read all this stuff, but it's better to set up like a little algorithm that's always looking for stuff that's pertinent to why that patient is, is having that visit today.

So we set this up, it was fire enabled at one point. We did it with a partnership with Booz Allen because they had some data scientists, um, that we're helping us out. And it, it was an interesting experiment and like. How do you actually, once you have all this data in one place, how do you make it actionable at, to, to a person?

Make it relevant based on why that person is actually there. 'cause they're, if they're in the ER for chest pain, it's different than if they're there for a headache and there's different pertinent things that we're looking for. I think more things like that, like we, we got it, we trialed it out in production and we got some positive feedback, but part of the thing was it.

It just took a while to run and we never quite got around to prefetching everything and setting up. Um, do you think we'll see user groups get stood up at, at most health systems as people start to get more familiar with this? Yeah. Yeah. You know, I, I think 'cause fire, you can be at any health system and essentially use the same code across health systems.

It'll probably be like, it'll probably be like this week in health it workshop on or use a group about, because it, it spans. I, I don't think it would be focused within the organization itself, but it'll be more a bunch of organizations since there's no, it, it's standardized and you don't really need it.

Like, like, uh, it, it doesn't rely on a code set. I. Specific code sets that are only in your EHR to work it. You know, you referred to some code that was open sourced earlier on, uh, it was Boston Children's, I guess. Mm-Hmm. . Yep. Um, is there other code out there that's been open sourced that people can look at?

Yes, some of it is. There's that smart health it.org. If you check it out, it's run by Boston Children's, but people can put their apps on it. So I have one or two up there, and you can look at how other people are doing this. Some of them are open source, some of them are like commercial, but that's probably a good resource if you're looking for some, you know, the thing is if you're using open source code in a healthcare system, you probably want somebody to review that code through your normal pathways.

Right? Yeah. That that makes What, what other, what other resources would you like? Where would people find your stuff and what other stuff would you recommend people look at? So my stuff is at, uh, patient dev. I have a few videos. They're a little more targeted towards the patients periodically. I have a meetup group, DC Medical APIs meetup group that we periodically do a workshop where we, I think, know we, so like we've had people talk about bulk fire from US digital service and the person was the CTO for any Chopra for a little bit.

So periodically we do stuff in that arena. And if you happen to be a Cerner client I, or use a Cerner EHR, I actually have a kind of bimonthly meeting that I do for, 'cause I feel like in Cerner our flavor of fire is, we probably all have the same problems with it. So what I try to do is set up like a little workshop every once in a while, every couple of months, or have a speaker come and talk on something every couple of months.

So if you happen to use Cerner, that might be high value for you. Like we had Anish, uh, Chopra talk, uh, a couple months ago, and then we had, uh, a workshop on making an app a couple of months ago as well. Awesome. Hey, you know, I hope you're, uh, patient.dev, right? Is that what you Yeah, yeah. Yeah. I, I, I hope it gets a few more hits.

I will probably, uh, head, head over there and, uh, download a couple things, or watch a couple things. I'm really curious 'cause I, I think this does have the potential. To, to really create a, a, a new environment within healthcare that we can be very creative, uh, within standards, right, within security models, within standards, which is, uh, that's gonna benefit the providers.

Maybe address some of the, some of the challenges of information overload and, and burnout. Uh, and then on the patient side, the, even the use case that we gave of being able to transport your records. So, uh, a lot of great opportunities. , Kevin, thanks. Thanks. Thanks for your time and thanks for all your work that you're doing in this.

I really appreciate it. Yeah. Thank you for, for all you do. I, I learn a lot by listening to your podcast and hearing all the other, uh, all the CIOs, CMIOs, and how they're. Thinking about stuff at their organization. So it's really high yield for me and I appreciate all the work you do and amplifying. I think that's your amplifying amplify great thinking.

So that puts you in that category. Now you are now great thinking I'm getting amplified. Hopefully make sure you tell your family that I have this. I was put in the category of great thinking today. Still humble you pretty quickly. They, they. You'll have one extra subscriber. My mom will. . Yeah. Mike. Uh, it, it's so funny, I, I, I talked to my parents this weekend.

It's, oh, I'm sorry I didn't listen to your last podcast. I'm like, I can't believe they're listening to all these. I'm like, they, they can't possibly understand a, a bunch of the stuff that we're talking about, but invariably they'll call me up and say. Hey, look, my medical record went from this system to this system and this happened, and we're now using Epic, and here's the portal and here's, and I'm like, they're at least grasping from a patient perspective some of the things that are now.

Happen to them behind the scenes from a technology perspective, it's been really fascinating to watch you put on a good show. And the Newsday thing I think is relevant to, to, like, even your parents are just normal people. It's just, here's this, here's how you think about what's happening in this news article.

I think it's actually, it's reachable to a more general audience as well. So yeah, it's fun. It's fun and it's great to, uh, meet and talk to people like you. We'll have to . To catch up. So you'll have to develop some really cool apps between now and this time next year and we'll catch up to, to get an update on how things are progressing.

Excellent. Sounds good. Thanks so much. Bye-Bye. That's all for this week. Don't forget to sign up for our clip notes. Send an email, hit the website. Uh, we wanna make you and your system more productive. Special thanks to our sponsors, our channel sponsors VMware Starbridge Advisors, Galen Healthcare Health lyrics, serious Healthcare Pro Talent Advisors Health Next.

And our newest channel sponsor McAfee Solutions 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, you check out our website this week, health.com, or the YouTube channel. If you wanna support the show, the best way to do that, share it with peer.

In fact, sign up for clip notes, get those emails, send on to, uh, your team members, peers within the industry, and let them know things that you have been getting value out of. Please check back every Tuesday, Wednesday, and Friday for more shows. Thanks for listening. That's all for now.