Latest / Zero Friction / The Intersection of AI and Healthcare Security with MK Barton || Zero Friction Podcast
Transcript
- Terry Coutsolioutsos: Welcome Zero Friction Podcast. Terry Coutsolioutsos here today, and once again we have another guest who is 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 telling us a little bit about root work and what you guys do and how you do it and who you do it for? MK: Great. 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 DevX 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 am working with some ed tech companies and a pet care company. Terry Coutsolioutsos: how did you get all this expertise to design and develop your own company to go take this forward? MK: 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 success 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 Health Vana made me paranoid, but paranoid in the best way possible. Terry Coutsolioutsos: How do you handle like a new framework or a new network language or a new programming language? you know, like Is it does it take l as long to read and understand that language as it does a normal foreign language? MK: You know, programming languages tend, at least in my experience, are a bit easier than learning than than human languages. 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 ins, 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 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 a specific question, the better output you get. As Terry Coutsolioutsos: Yeah. MK: 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 to dig in and understand the parallels between a language I'm familiar with and one that I'm not. Terry Coutsolioutsos: when 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? MK: 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 ninety six and it's been revised a few times. But the key parts of that for 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. 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 gonna put any kind of fake data on any kind of advertising again because Terry Coutsolioutsos: wow, that's crazy. So how did how did that end up finishing up for you? MK: 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 when 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 Health Vana 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. Terry Coutsolioutsos: 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 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 MK: 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. Terry Coutsolioutsos: Yeah. MK: it's 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. And 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. and also, I mean, one of the things in the healthcare space that I get 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 or autonomous workflow. you know, if we if we put a clawed 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. Terry Coutsolioutsos: there's a lot of agents in practices today too. MK: 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 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 like appropriateness, like was the tone correct, but also to make sure they're not actually giving health insurance or health information to patient, like that they're not diagnosing them. And it it was a fairly laborous process for a while. And eventually we took those learnings and built them into evals to to kind of keep our AI on or 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. Terry Coutsolioutsos: here's the other thing is that we can talk about protecting data, but now I have all these agents creating data. So MK: Mm-hmm. Terry Coutsolioutsos: 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? MK: That is a great question. But for us, the current client I'm at 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, it can't grab a API token or an AWS token. Terry Coutsolioutsos: Right. MK: And you know, if you lose that laptop or someone gets access to it, like everyone knows where those keys are located. And Terry Coutsolioutsos: Right. MK: as I've been working with this team, we've been eliminating using those keys at all and using some of 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 Terry Coutsolioutsos: Yeah. MK: doesn't mean that someone has the keys to the kingdom. Terry Coutsolioutsos: 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 gonna have to deal with? MK: 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. Terry Coutsolioutsos: Right. MK: You know, my mentor Terry Coutsolioutsos: Okay. MK: at Health Vana 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. Terry Coutsolioutsos: Right. Okay. MK: 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 devs' fault, that's the framework's fault. Terry Coutsolioutsos: Right. MK: And I haven't seen this any place 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 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 Helvana 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. 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. And 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 Terry Coutsolioutsos: Huh. So you knew who the problems were gonna be before the problems were even there, huh? MK: Where we could, yeah. And tried to highlight those so that, you know, if you if you can only make fifty phone calls in a day, make the fifty that count the most. Terry Coutsolioutsos: 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, MK: Okay. Terry Coutsolioutsos: is cybersecurity becoming a bigger issue? MK: I think it it it is becoming a bigger issue. I mean, I would say, you know, the the rise of agents i 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 Terry Coutsolioutsos: Yeah. MK: 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, a you you can craft a Terry Coutsolioutsos: Yeah. MK: 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 prints. 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 in hoping that one might hit. Well now you can turn an agent loose that says, 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. And you Terry Coutsolioutsos: Sure. MK: can you can craft something very compelling and it looks legit. Terry Coutsolioutsos: the industry's gotta figure out how to train and create awareness what are some of the things that our companies can do today? MK: Yeah, we we worked with a really great company And this company would send like heavily personalized emails to our employees to quite frankly attempt to trick them to click on something they weren't supposed to. I personally thought it was a a tremendous tool. z some people felt that it was they were I that that it was like we were 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. 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, I think this might be a test. It was fortunately. but it 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 in attack people with urgency. Like something bad has just happened. You need to react Terry Coutsolioutsos: Yeah. MK: right now. And I think the im 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. Terry Coutsolioutsos: Sure. MK: You know, the object is to We all can be we e 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 gonna 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. Terry Coutsolioutsos: So where in the future is DevOps and infrastructure heading, like where do you think like the next frontier is what you're gonna be doing in the future for your customers? MK: Sure. I have a kind of a thought on this. 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 of years ago are amazing. You know, for me personally, I learned more about Rust in a few weeks than 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. It's one thing if you have one service, but if you have 50 services, it's a very different thing altogether. Terry Coutsolioutsos: Right. MK: 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 gonna become the bottleneck if it isn't already. Terry Coutsolioutsos: Okay. MK: And the the friction of, you know, for example, we're 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 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 devx, I 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 ChatGPT to go deploy this code faster. There has to be a system that allows the engineer to deploy that code faster. Terry Coutsolioutsos: And how do you create that? MK: A couple things, I think. One is first of it, there's a there's a culture of continuous integration and continuous deployment that people need to embrace that we're gonna be releasing code a lot. Terry Coutsolioutsos: Okay. MK: sometimes that can scare people, like, well, you know, I don't know if my changes are gonna work. And if I push it out there, maybe I just wanna 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, because 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 Health Vana, again, the fella I worked with was a very big believer in this and we might deliver code, fifteen, twenty times a day. I didn't know. yeah, yep. And Terry Coutsolioutsos: You're talking updates, right? Like updates to that's a lot. that's sort of a disruptive on the on the operational side I just remember MK: Absolutely. Terry Coutsolioutsos: 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. MK: I agree. And and there are I don't wanna give the impression that I didn't have to be up at two in the morning doing things fairly often as well. Like that that's still a reality. Terry Coutsolioutsos: what else would you like to leave us with, MK, MK: You know, I think a couple things. I 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. That's Terry Coutsolioutsos: Mm. MK: 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 problems. 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. Terry Coutsolioutsos: in today's world and LinkedIn that you you can't go a day on LinkedIn and not see some post saying, Here's how I have thirty seven people that are agents, not humans, working for me today. Right? MK: Mm-hmm, mm-hmm. Terry Coutsolioutsos: And frankly, I know there's a few companies out there doing it, but I just I I just want to call bullshit on all 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 MK: Right. Terry Coutsolioutsos: it. MK: Yeah, I I couldn't agree more, especially on the LinkedIn comment there that you'd see like, I'm running a team of fifty agents. I'm like, well, okay. Yeah, I mean Terry Coutsolioutsos: How's that going for you? MK: if if you had fifty 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 fifty 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 l lose like the context of what they're working on. Like with a human being, you know when you've forgotten, Terry Coutsolioutsos: Right. MK: but an agent doesn't know that they've forgotten. Yeah. Yep, exactly. Terry Coutsolioutsos: And they just and they fake it and they just make it up, you know. MK: Like I can look at something and go, I don't remember what I was doing here. I'm gonna go get a drink of water, I'm gonna 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. Terry Coutsolioutsos: Right. So, but anyhow, MK, MK: Yep. Terry Coutsolioutsos: it's been wonderful being with you today. thank you so much. MK: thank you, Terry. This is this has been great. Thank you Terry Coutsolioutsos: 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 gonna need good solutions MK: Yep. Terry Coutsolioutsos: moving forward. MK: Absolutely. Alrighty. Well, thank you very much. Okay. Terry Coutsolioutsos: Thank you. Have a great weekend. MK: Yep, you too. Bye bye.