Why Healthcare AI Agents Need Narrower Data Access

From the episode captions, lightly cleaned. Speakers are not labeled, and the text may contain small errors. Time links play the episode from that moment.

0:00 In MedTech, the difference between a good quarter and a great one isn't always the product. It's the friction standing in the way. Broken sales cycles, misaligned teams, deals that stall at the finish line. Every leader feels it, and the best ones know how to remove it. Welcome to Zero Friction, the podcast where we go inside the minds of MedTech's top commercial leaders to uncover the real barriers they face, the decisions they make, and the systems they build to keep the revenue moving. I'm your host, Terry Coutsolioutsos. Let's remove some friction.

Welcome Zero Friction podcast. Terry Coutsolioutsos here today, and once again, we have another guest who's removing friction from our healthcare system. Today, I have MK Barton. He is the co-founder and head of cloud experience for Rootwork Labs. They're based out of Chicago. And they do a lot of work across multiple industries, but you know, basically, they are a developer of data infrastructure. MK, I'll let you kind of lean into your professional background, and give us a little background on yourself personally, and tell us a little bit about Rootwork and what you guys do, and how you do it, and who you do it for.

Great. Uh, thank you so much, Terry, for having me. I really appreciate it. Yeah, I'm MK Barton. My company is Rootwork Labs. We're a small boutique consultancy that works with early-stage startups, primarily in the data space, DevOps space, and uh, DevEx space. So, we are looking to work with companies that have maybe scaled from two engineers to 15 engineers, and some of the the problems, the coordination, observability, ease of shipping, some of those problems start to appear as a company gets a little bit bigger. We primarily work with AWS shops.

I've had a lot of work with healthcare companies, and currently, I'm working with some EdTech companies and a pet care company. How did you get all this expertise to design and develop your own company to go take this forward? Sure. Yeah. When I first started out in tech I found that I kind of naturally gravitated in data roles to working with my colleagues on a team to set up things like automated testing, automated delivery, continuous delivery, and continuous integration. And I found that I really enjoyed enabling my teammates to work faster.

And that led to a a series of data roles in different industries. And then when I landed in the healthcare space, I was really excited because I was working with a gentleman over there who had been in the healthcare space for a very long time, was very security conscious and knew a lot about HIPAA and HIPAA compliance. And he was a great mentor to learn from. And I like to say that my time with Healthvana made me paranoid, but paranoid in the best way possible. How do you handle like a new framework or a new network language or new programming language?

2:55 You know, like is it does it take as long to read and understand that language as it does a normal foreign language? You know, programming languages tend at least in my experience are a bit easier than learning that than human languages. Um but the way I usually approach a new programming language is I try to solve a problem that I've already solved before in another language. So, something where I know the ends the inputs and the outputs. And when I started with this client, I had to learn Rust. That was my my new language. And I basically was in a position to re-implement a few things that I had done with Python in Rust. And I found that was a really great way to start to learn how the language worked. You know, and I would be remiss if I didn't mention AI at this point.

My my take on AI is I think it's a great learning tool. And one of the things that I've loved about it is I can take a line of code and drop it into chat GPT or Claude and say, "Hey, I think this line of code means I'm doing X. Is that correct or is that incorrect?" And I I found that the more you can push like AI to answer specific question, the better output you get. Yeah, as opposed to, you know, you hear a lot about vibe coding and people kind of not understanding the code that they're writing.

But that's that's not really what I'm about. It's more trying to dig in and understand the parallels between a language I'm familiar with and one that I'm not. Well, you've been in healthcare quite a bit. What are some of the friction points when it comes to data, data infrastructure, data security? What are the big things that, you know, your customers are most concerned about? Yeah, I mean, healthcare data is governed by HIPAA in the United States and that is a framework, I think it was first passed in '96 and it's been revised a few times. But the key parts of that for a data engineering or DevOps engineering are the data has to be encrypted, you know, both in transit and at rest. So, if you're sending a packet of data across the a network, it can't be in plain text. It has to be encrypted. And when it's sitting on a database, it also has to be encrypted.

And perhaps most importantly, you can't let people have access to that data unless there is a real specific need for it. Now, the the patient themselves have access to their data. The physician, the providers also do, but when I'm working with, say, a developer on a new feature, I can't just let them have customer data to use to build that feature. We have to either create fake data or synthetic data. And I have a funny story about this, how how easy it is to get in trouble. The company I was working at, they were highlighting a new feature and they they put up some billboards.

5:46 And the billboard was showing what the feature looked like and what it could do, and we had one of our our fake patients in there, you know, demonstrating like showing what the feature was doing. Unfortunately, of all the the weird coincidences, a person with that exact name happened to see that billboard and thought that we were putting their data their healthcare data on a billboard. So, we did have to sit with them and go through it with the attorneys and just explain that this was a wild coincidence and we're never going to put any kind of fake data on any kind of advertising again because Wow, that's crazy. So, how did how did that end up finishing up for you?

It ended up finishing fine. The person understood that it was a mistake and we just had to promise not to even attempt to use any fake-looking data or anything that could plausibly look like a real person's data. That was the real the real big takeaway there and it was kind of funny, you know, no one's data leaked, so that's fine. So, it was a it was a happy ending. But, it I have to say I was reminded several times and I'd be working in the databases and things like that and and seeing, you know, a lot of times I'm making a query and I'm maybe seeing how many records there are or what an average is or how many patients have done this, but every so often I would have to stop and think like these are real people.

And this is really important data about their health and it's an honor and a tremendous responsibility to be tasked with protecting that. And I was very fortunate at Healthvana that everyone on the team took that extremely seriously. There was never any shortcuts made for well, we'll fix it later, you know, you can't move fast and break things when it comes to data security. Especially with the risk that is associated with a breach, right? I think there are concerns with AI and how AI could potentially create leak zones maybe where people can sort of you know, find their way in and you know, there's always bad actors out there too. So, since sometimes these breaches aren't like, you know, they're not by accident, they're by intent and purpose and you know, have you had any experiences with that before?

I've been fortunate enough that we haven't had a a a breach of that manner in my career, but it's not for people lack of trying. It's uh you know, you can continually anything that's open to the internet is continually getting scanned. Some of it's by bad actors, some of it's by researchers, some of it's who knows what's going on there. I think that kind of circles back to some of the danger with AI. Like if you're not super clear, you can maybe get a script that does way too much.

8:35 And also, I mean, one of the things in the healthcare space that I concerned about is people hooking up AI agents to infrastructure because there's a lot of data that's contained on that infrastructure and I don't know where it all goes. So, I really try to avoid that sort of agent autonomous workflow. You know, if we if we put a cloud agent in there, I don't know if they're reading a database. Do they store that? I think their terms of service they say they don't. And I have no reason not to believe them, but also as I mentioned, I'm fairly paranoid. So, that's that's kind of my concern is like making sure that patient data never got sent out to an AI service.

There's a lot of agents in practices today, too. Yeah. Yeah, that that's a great question. We we actually implemented like an AI agent for one of our major customers to help with scheduling, hours, availability, that that kind of thing with the goal of really a goal of reducing phone calls to the clinic. If people can interact with the agent, then they don't have to take up people's time with phone calls. And for a long time, we actually reviewed we had a team set up to review every conversation.

I actually wrote data pipelines to pipe out the outputs of those conversations. And then we had a team that would like rate them on appropriateness or I'm forgetting what the whole matrix, but they like appropriateness, like was the tone correct, but also to make sure they're not actually giving health insurance or health information to them like they're not diagnosing them. And it was a fairly laborious process for a while. And eventually, we took those learnings and built them into evals to to kind of keep our AI our kind of in its proper lane.

And that worked pretty well. And it did help the company a great deal that a lot of their phone traffic went down. People could find out the hours for things, what time their appointments were just from their their phone in most cases. So, it it was a big success. Here's the other thing is that we can talk about protecting data, but now I have all these agents creating data. Mhm. So, I'm sure that the velocity and the volume of data is getting massive. And so, how do how do companies start managing that volume and that velocity? That is a great question. Uh but for us, the current climate map right now, it has been more of a push on making sure the developers have access to good AI tools, not necessarily like our outside users. And within there, we've also locked down. I've been tasked with a lot of things around like making sure that people don't have credentials in plain text on their machines. So, that if an AI agent is doing something there, they can't

11:28 Grab a API token or an AWS token. Right. And you know, if you lose that laptop or someone gets access to it, like everyone knows where those keys are located. Right. And as I've been working with this team, we've been eliminating using those keys at all and using some AWS's more modern products that will issue a temporary credential for, you know, say an hour, half hour, 90 minutes, whatever. You can configure that. And that way it helps me sleep better at night knowing that the lost laptop problem doesn't mean that someone has the keys to the kingdom.

Right. What are some of the biggest challenges that they're going to face with regards to data, data infrastructure, data security, like what are the biggest friction points that they're going to have to deal with? I think from a compliance standpoint, the one that makes me the most nervous is the rise of autonomous AI agents, specifically in the healthcare space, because like a lot of we've all in the in the tech business spent a long time making sure that people have what are called least privilege permissions, so that you can only do the things that you're allowed to do and that's appropriate for your job level.

Right. my mentor at Healthvana had kind of a philosophy that if a junior developer could do something destructive, that wasn't the junior developer's fault. That was the DevOps engineer's fault because the junior developer should never be in a position to be able to do something destructive. Right. You know, it's our job like you sometimes hear these stories about like my first day on the job and I dropped the production database. Well, that's not that's not the the dev's fault. That's the framework's fault. Right. And I haven't seen this anyplace that I've worked, but I get worried that these agents are so cool, we can just turn them loose and they'll make us so much more efficient, but they don't always have the full context and I wouldn't do that with a human that I can supervise and talk to.

I'm a little concerned about letting a robot do that that I can't supervise and can't talk to and can only maybe find out after the fact. So, I think there's a risk from a compliance standpoint. But, I also think on the upside like what we saw at El Paso was a big reduction in like toil and friction and what time is my appointment and are my test results in. You know, all these questions used to be mostly phone calls. Someone has to answer that phone call.

14:00 If they're answering the phone call, they're they're not checking someone in or they're not reaching out to someone whose appointment is like later that day to make sure they're coming. You know, no shows was a was a tremendous problem. The the AI that we implemented helped a lot with that. And freeing up the time for the say the front desk staff to follow up on likely people who might who are more likely to miss their appointments than others. Like we had data on on that like people who attended and missed appointments.

And so, we would were going to be before the problems were even there, huh? Where we could, yeah. And tried to highlight those so that, you know, if you if you can only make 50 phone calls in a day, make the 50 that count the most. What else do you feel like is a big risk in the healthcare space from a hospital system perspective? Is it the autonomous agents kind of roaming around? Is it, you know, is cybersecurity becoming a bigger issue? I think it it is becoming a bigger issue. I mean, I would say, you know, the the rise of agents is a is a concern, but also good old-fashioned keeping your systems up-to-date.

That still remains a problem to the to this day and it it costs money and takes time to keep systems up-to-date. But, I'm still concerned about that in the healthcare space. And then the the new one that kind of scares me the most actually about AI is how good the phishing attacks are getting. You know, you can craft a really good really good introductory email with with AI that and and we're not talking about like misspellings and you know, the the traditional Nigerian prince type type type scam like the these are these can be very difficult to discern that they're real or fake.

And the weakest part of any security system is always the human. And it's getting harder to identify. You know, it used to be that sort of game was a numbers game. You would send out millions upon millions of phishing emails and hoping that one might hit. Well, now you can turn an agent loose and say, "Hey, tell me everything you know about this person. Go go check out their LinkedIn. Go check out whatever they post on the internet." People post a lot of things. Sure. And you can you can craft something very compelling and it looks legit.

The industry's got to figure out how to train and create awareness. What are some of the things that our companies can do today? Yeah, we we worked with a really great company and this company would send like heavily personalized emails to our employees to quite frankly to attempt to trick them to click on something they weren't supposed to. I personally thought it was a a tremendous tool. Some people felt that it was they were that that it was like we're trying to trick them, but I don't know. I I thought it was useful. I remember one particular story that I was just getting ready to go to work and I got an email in my work account that said my Dropbox account needed to have its password reset.

17:03 But I saw that my Dropbox account password needs to be reset. What happened? And I instantly panicked and stopped what I was doing and I was just about to click on the reset your password link. Figured out that oh, think this might be a test. It was, fortunately. But, that was a very effective tool. And that's a lot of times how these sorts of things, these like social engineering or phishing attacks work, is they and attack people with urgency. Like, something bad has just happened. You need to react right now.

And I think the important thing with these types of tools is try to make them not not punitive to the developers and to the people who have access to this data. Like, the object isn't isn't to trick them so you can fire them for being bad or something like that. You know, the object is to we all can be we everyone's susceptible to this kind of thing. They just have to catch you in the right day. Maybe you're a little hungry. Maybe you're a little tired.

Maybe it's because that Dropbox account is only used under very specific circumstances. And you know, that caused me to panic. And once you start panicking, your your higher functions all disappear. I think the the biggest thing that people can learn from this is like just take a breath and slow down. And but it's important that if you're going to implement something like that, that it's clear to all the people using that tool that this isn't a tool to to punish employees. So, where in the future is DevOps and infrastructure heading? Like, where do you think like the next frontier is?

What you're going to be doing in the future for your customers? Sure. I I have a kind of a thought on this. Uh it's something I've been saying a little bit is like in the future everything is going to be DevEx. Everything's going to be developer experience. And that means DevOps, that means data engineering, that means front-end engineering. The tools for a given developer to deliver faster than they could even a couple years ago are amazing. You know, for me personally, I learned more about Rust in a few weeks I probably could have done in a few months years ago.

So, the average developer productivity I think, is going to go up. But, as that happens, as there's more demand for software, as there's more ability for engineers to deliver faster, that's more pieces of infrastructure out there. That's more kind of moving parts to a system working out there. You know, it's one thing if you have one service, but if you have 50 services, it's a very different thing altogether. Right. And you have to my my when I say in the future everything will be developer experience, the way that the developer interacts with getting their code deployed is going to become the bottleneck, if it isn't already.

19:46 Okay. And the the friction of, you know, for example, where the client I'm working with right now, it's an unfamiliar system, we're literally learning how to deploy code to this system right now, and it it's making our it's slowing down the velocity of our developers to get their code out there. You know, they're working in an unfamiliar language, but they're they're actually working faster than the DevOps team is right now, because it's a little bit harder to take like, here's a bunch of infrastructure and give it to an AI and say, "Tell me what's going on here." First of all, that might not be in a way that an AI can understand. So, when I say DevEx, I mean really like the the velocity of an idea for a product getting to the developer, getting implemented, and then most importantly, getting it deployed.

Because you can't just ask chat GPT to go deploy this code faster. There has to be a system that allows the engineer to deploy that code faster. And how do you create that? A couple things, I think. One is first fit there's a there's a culture of continuous integration and continuous deployment that people need to embrace that we're going to be releasing code a lot. Okay. Sometimes that can scare people. Like, well, you know, I don't know if my changes are going to work, and if I pushed out there, maybe I just want to test this a little bit more. But the longer it takes to get code deployed, the more changes get built up in there and the more possibility things can go wrong. It's paradoxical, but the more often you deploy, the less likely you are to have mistakes cuz you're deploying tiny little pieces of changes at once. And ideally, like, what I like to say is a deployment should be fast, constant, and

Boring. Like, ideally, as a DevOps engineer, the best thing you want to know about deployments is you don't have to pay attention to them. And at Healthvana, again, the fellow I worked with was a very big believer in this and we might deliver code 15, 20 times a day. I didn't know. You're talking updates, right? Like updates. Yeah. Yeah. Yep. That's a lot. That's sort of a disruptive on the on the operational side. I just remember building CRM systems. You know, I remember we'd have an update and we'd have to do it in the middle of the night. As much as you were saying that it's better to do more updates and less problems, I I I never had an update that didn't have a problem. I always find that the minute we fix one thing, we've just created another problem.

I agree and there are I don't want to give the impression that I didn't have to be up at 2:00 in the morning doing things fairly often as well. Like that that's still a reality. What else would you like to leave us with, MK? You know, I think a couple things. I think I want to leave the audience with the idea that, you know, you're in a tech company or in a tech focused company, your developers are really your greatest asset and whatever you can do to help them go faster, be more accurate, and be happier in their work. People want to feel like their work matters.

22:51 That's that's I I think every engineer that I've ever worked with, they don't just want to sit there and collect a paycheck. They want to ship features that their users use and that make them happy. Engineers love to solve That's That's why they That's why you go into that kind of work. So, make it easy for them to solve problems. Make sure they have the tools. It can be just as simple as is your documentation in the same place in every code repo? You'd be surprised how often it's not.

In today's world on LinkedIn, you you can't go a day on LinkedIn and not see some post saying, "Here's how I have 37 people that are agents not humans working for me today." Mhm. Mhm. And frankly, I know there's a few companies out there doing it, but I just I I just want to call on all of that. In my mind, AI is really meant to augment the human experience and and the human impact. So, to me, my math with AI looks like looking at humans and saying, "You're now 150% more effective today with AI than you were without it." Yeah, I I couldn't agree more, especially in the LinkedIn comment there that you see like, "Oh, I'm running a team of 50 agents." I'm like, "Oh, okay." How's that going for you?

Yeah, I mean, if if you had 50 direct reports, you wouldn't be able to efficiently keep an eye on what they were doing, so I don't know why you think you can do that with 50 autonomous agents and I it you know, there there's the the concept of the context window with one of these agents and when they when they lose like the context of what they're working on. Like with a human being, you know when you've forgotten. Right. But an agent doesn't know that they've forgotten.

Just And they fake it and they just make it up. Yep, exactly. Like I can look at something and go, "I don't remember what I was doing here. I'm going to go get a drink of water. I'm going to go for a walk, clear my head and come back and try to hit this problem again because I know that something has slipped out of my brain." Right. But anyhow, MK, it's been wonderful being with you today. Thank you so much. Thank you, Terry. This is This has been great. Thank you so I look forward to learning and continuing to hang out with you in this data world because I know for one thing the agentic space is going to create more data, more complications, more exposure for healthcare information and for healthcare providers are going to need good solutions moving forward.

Absolutely. All righty, well, thank you very much. Thank you. Have a great weekend. Yep, you too. Bye-bye. That's a wrap on Zero Friction, the show built around one simple idea. Remove the barriers and the revenue will follow. If today's conversation was valuable, please subscribe and share it with somebody who needs to hear it. That's how we will grow this community. I'm Terry Coutsolioutsos, a revenue architect powered by AI. Come find me at my website, myrevx.com, and let's talk about what friction is costing you and your organization. Until next time, keep removing the barriers and keep the revenue flowing.