Legacies | APIs And The Modernization Dilemma

  |  Compiler Team  
APIs
Weiterbildung
Technologiegeschichte

Compiler • • APIs And The Modernization Dilemma | Compiler: Legacies

APIs And The Modernization Dilemma | Compiler: Legacies

About the episode

Governments, companies, and organizations around the world are coming together to make healthcare IT infrastructure faster and more intuitive, matching the pace of modern living. 

APIs are a large part of those efforts. But their use in IT modernization can present both unique challenges and unanswered questions. Sometimes, the challenge isn’t the tech itself-it’s the people who build, manage, and use it.

Compiler team Red Hat original show

Abonnieren

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Transkript

There's a lot of innovation around healthcare, but the way we move around medical data? Let's face it—it's tedious, it's manual, it's outdated. But that's changing. The technology at the center of that change, both in the U.S. and abroad, is the API, application programming interface. (00:23): On the outside, API integration seems like an easy way to add new functionality to older systems, to allow different services and platforms to talk to each other, but the truth is a little more complex, and that complexity is causing many to come out in opposition to healthcare IT modernization. But why? Upgrades, more agility, more features—those are all good things, right? This is Compiler, an original podcast from Red Hat. I'm Brent Simoneaux. And I'm Angela Andrews. We go beyond the buzzwords and jargon and simplify tech topics. Today, we're taking a closer look at APIs. This is one episode of our series on legacy technology. To listen from the beginning, start from the episode, "In Defense of Legacy." Let's see what producer Kim Huang has for us. The way I think about it is that APIs allow systems or applications to talk to each other, to communicate amongst themselves. That's Jamie Beckland. He's the President of Contxt, a company that specializes in API security. And really, I think the elaboration of APIs has created whole new categories of what software can do, how it can work together, and how it can be componentized into microservices, and also expanded to do much more across functionality. APIs allow different applications or services to integrate and share information under specific conditions without the different teams involved having to know how these services are implemented. They're kind of like an agreement or a bridge between different pieces of software. (02:18): Most people don't think of APIs as legacy software, but they have been around for quite a while, around 3 decades. At that time, they would pass information between mainframes and be local to the systems they were operating on. Today, they are how most people encounter older systems and older programming languages. The interface might be different and modern, but it's still that older software underneath the window dressing, and since old systems are still pretty common, APIs are common too. People interact with APIs probably most of the time without realizing it. Today, API calls represent over 75% of all internet traffic. It's the majority of the internet, right? If you think about any service or any system that you're using through a browser, it's going to be built on top of a bunch of APIs. Every app that you have in your phone is built up of a bunch of API components. So really, almost every experience that humans use on the internet is built and managed through APIs. What? Did they say 75% of all internet traffic? Yes. That's huge. I thought it was Beyonce, but you're telling me it's APIs? What? Software eats the world, APIs eat the internet, I guess. Sheesh! Yes. I want to talk a little bit more about the proliferation of APIs over time. This is something that has been this fast development, this rapid development. I mean, APIs have been around for a while, but the use cases for them, specifically in tech-heavy areas like social media and banking, think about whenever you go on Facebook Marketplace to buy something or whether you have integrations on your social media platforms to make a purchase or to have it integrate with a personal calendar or another app that you use, those are all made possible with APIs. Okay. So APIs are the GOAT [greatest of all time]. They're what's out there. They're making the internet run. We wouldn't be able to do a lot of things without APIs. Right, that's true. And this is starting to become really essential in different industries, like I said before. But for this episode, I want to focus just on healthcare—how API integration is being used to update the infrastructure in healthcare systems—especially when it comes to the matter of sharing patient information between providers. (04:55): How healthcare IT is structured now, how it's always been, and how most of our listeners will understand it is that when you go to your doctor, and say you want to go to your doctor and then go to a specialist. Well, that specialist has to have the same information that your primary doctor has. How do they get that information? Traditionally speaking, they would get a fax. [laughs] You would have to fill out a form using these devices called pen and paper, and you would have to use a fax machine to send this information back and forth between your primary doctor saying that this other healthcare provider has your consent to have the same information or the same patient data as your primary doctor in order for them to treat you or do their job. I think it's funny that you said, "Used to." Still do. That's true. They still do. Still do. 100%. I'll do you one better. I very recently hand-carried paper medical records from one medical office to another one, and a CD, a CD-ROM with images on it. Those images, yep. Oh, wow. We've come far, but we haven't all come far. This was not that long ago. This was not long ago. No. And those situations are extremely common, right? Yes. But where are we going now? So in the last few, I would say the last decade or so, governments have kind of stepped in and said (surprise, surprise), "This is not very efficient, and we want healthcare to reflect the different changes that are happening in technology in other industries like banking"—where you don't have to carry a shoebox full of your receipts from one bank to the other, for context. (06:51): But what we have in place currently, and this is the product of many years of work, is something called Health Information Exchanges, and that's at the state level. This is mostly pertaining to the United States. These exist at the state or regional level to handle the movement of patient data back and forth in the form of EHRs (electronic health records). So Brent, you're hand-carrying the files—this is kind of the equivalent of that. (07:18): But for a variety of reasons, some we'll talk about today, it's still very difficult to move patient data between doctors, hospitals, and other healthcare providers. This is called interoperability, so we'll use that word moving forward. (07:34): Now, the 21st Century Cures Act, a U.S. law that was passed in 2016, requires the ease of movement of these records by the end of 2022. Well, it's 2023 while we're recording this. How is that working out for us? It sure is, Brent. How we doing? Let's just say things are in flux. Okay. Well, I assume this is a very— Complicated! ... challenging and complicated technical problem, in addition to legal and privacy and all that. There you have it. Yes. And I want to bring it back to APIs because there's so many different parts of this, like you say. But why are APIs such a huge component of this type of modernization? (08:23): I spoke to Bobur Umurzokov, he likes to be called Tiger. He's a developer advocate who works with the Apache Foundation, and he's written extensively about APIs. APIs can be modernized in such a way that different people can work on one API, another team can work on another API. That gives more flexibility. Instead of completely replacing the old system, as a developer, I can use APIs to bridge this sort of gap, and then I can step-by-step move the big legacy systems by migrating to the APIs, not immediately, so that I can allow new models that can talk to other new models through the APIs easily. That makes the transition to modern technologies smoother. You have people who are very, very eager for this to be a new normal where people can just move their electronic health records, their patient data, from one place to another very easily. So it seems like it's the cure-all, right? Yeah. It does. It's the cure-all for legacy systems with the ability to change the user interface, add new functionality for the user themselves. It all seems very ideal, picturesque. Mm-hmm. I feel like there's a "but" coming. You know it is. I'm just waiting for it. But it's more complicated— There it is. There it is. ... than that, yes. What we found is that there's a huge business imperative to add APIs into our existing services and applications. And oftentimes, that push has caused teams to move really, really quickly. And when you move fast, the risk is that you break things. We'll find out more about what Jamie's talking about when we come back. (10:21): Where we left off, Jamie was telling us about the complexities of using APIs for the exchange of health data. Where a more open understanding that there's a value exchange going on between the user and the social media platform or between the media company and the advertiser, there is an implicit understanding from the consumer that part of the opportunity to get something is that they're sharing some part of themselves. But that's not the case in healthcare. So we're thinking APIs are very useful for, let's say, buying something off of a social media platform or having all of your different applications integrated with each other. If you want to share photos, if you want to have things integrated with your personal calendar. But this isn't the same thing. This isn't apples to apples. This isn't the same thing as buying a t-shirt. This is a person's medical history. It's very deeply personal information that they probably don't want to share with anyone else. Exactly. So these are two different ends of the spectrum where we put information out there easily, freely, no one cares. But when it comes to something so personal and so intimate—your medical information—that has to be handled with a higher level of scrutiny, in my opinion. (11:50): I guess the question is, are APIs the actual solution for said thing? If we're so used to using it in this really open way, when we're talking about something very closed and secure, this does not seem like the same thing. Yeah, you and I are on the same wavelength about this, but here's Jamie again because he goes a little bit more in depth. When we're talking about PII (personally identifiable information), citizen data, patient data. When we're talking about the data of individuals, there is already an expectation of privacy. And we've seen, I think, in the last 5 years, a huge explosion in awareness from consumers about how at-risk their online information is. So when you take a step back and you look at where this landscape has led us, if you're a bad actor, you sort of go where the easiest target is, and APIs are the easiest target today. Wow. I can see that. I can totally see that. Yeah? Yeah. And it's almost if—if we're talking about such private data and protecting, there are laws in place to protect people's medical information and PII. So I always go back to the old adage, it's not if you're going to get hacked, it's when. That's right. And how do you mitigate against putting your business in the street like that? How? Yeah. And again, I think it has to do with where we are as a technologically advanced society and where we are with our relationship with technology. There's so much risk that we're okay with taking on, but this does not apply to that situation. Yes. This crosses the line. None of us are willing to take that risk. And APIs, unfortunately, have already become a huge target for cyber crime because they've become so ubiquitous. They've proliferated to the point where they're everywhere. (13:45): According to a 2021 survey covered in VentureBeat, 94% of the respondents that they talked to—cybersecurity professionals—experienced security issues related to APIs that year. Wow. Wow. Thank you. That is a lot more than I was expecting there. Are APIs such a big target for cybercrime, is that because of just the nature of APIs, that they allow you into systems? Well, I think it's because they're integrated with these systems. Think of them as like a go-between. They're allowing two applications to talk to each other. Think of it as like a bridge between two islands. What's the most vulnerable point of that relationship? It's the bridge itself. Good analogy. And then you add patient data into the mix. That's— That's a gold mine! It's a recipe for something very disastrous that a lot of people really wouldn't be able to understand the consequences or ramifications of right away. (14:54): Bobur points out the compliance issues—which is what Angela, you were talking about a little bit—the compliance issues with APIs and the scenario of one system failing while the other system is trying to access the data through the API. The API is still one of the best approach to go to some modernization, but you need to consider this modernization comes with responsibilities. Responsibilities—which means another API, let's say, with health systems or with government systems, that both APIs should be communicable enough. Otherwise, if one system is not reliable, if the system fails, you cannot get the response on time. When Bobur said that to me, I immediately started going through life-or-death scenarios in my head because that's really what a lot of healthcare is. It is, a lot of times, emergency situations are life and death. If the person that you're working on or the person that you're responding to in an emergency, the person that you're trying to administer care for has a pacemaker, but you don't know that. Or the person has a certain type of allergy but the information, the health data that has that information, that EHR is not readily accessible because one system's failing. The API is there, the API is working, but one system fails while the other system is up. (16:26): For me, and maybe I am just sensationalizing it a bit too much, but I can't stress enough that this information that we're talking about, these EHRs, they contain information that is very sensitive to our very lives. And you bring up an interesting point here, Kim, because it's like we obviously want to be concerned about privacy and security. And at the same time, we do want people to be able to access it when they need to access it—the right people. The right people. Bingo. The right people. Who are the right people though? Who decides that? Does the government decide that? Does the hospital decide that? Does your primary doctor decide? It's a lot of very big questions around health data and who needs to know and who doesn't need to know? Exactly. Just because you're in a hospital and you have a log on to this system, are there role-based access controls in place that say you can or cannot access this data? How are we segmenting it off? And that's just another level of security, but it's also another level of complexity because maybe you can or should have access to Patient X but not Patient Y or whatever. I don't know. (17:49): I'm just saying, knowing who should have access. And taking it a step further, if you're a patient not in a particular hospital, but your information is a part of this health system or it's trying to be accessed, should you be allowed to access it? Where are the guardrails? Where are the rules that say who can access what, when, and why? Yes. Jamie talks about this a bit too. When we think about data transmission, we think about several core concepts. What is the data itself? So is it mailing address or is it personal health information? Test results? Has the subject of the data appended any constraints? Are there any legal constraints? What are the constraints around this data sharing? And then what can that data actually be used for? Just what is the data itself? Who's requesting it? Where is it going and who can read it? Yes, and something as dynamic as someone's doctor visits, something that can be very... It's not static. It's very dynamic. If you have children, you have a pediatrician, you have all these different specialists and things, you have dental care, you have vision, you have... Our healthcare, I guess I would call it a healthcare data portfolio, the ecosystem and the portfolio is very complex, so the simple kind of who needs to know is actually quite a big question and quite difficult to decide when it's constantly changing. And, I imagine, leads to a lot of fights. Exactly. Yes. This is at the center of many a fight in the United States where healthcare providers, and patients too, are protesting modernization efforts because those particular guardrails are not expressed or they're not clear. And those guardrails, those standards are vital, especially when you're talking about people's personal information. It's also part of the reason that having open standards around healthcare portability, around other regulated industries, financial API access—it's part of the reason that these communities have come together to say, "Look, this is how we're going to interact with each other to make sure that we're all operating from the same rule book, and therefore, we're not going to have any sort of unintended consequences." Really? Yeah. Technology is interesting. There's always unintended consequences. You cannot successfully run through every use case. With all the Q&A in the world, there may very well be some unintended consequences. It's not a feature, it's a bug, or it's a bug, not a feature. It depends on how you look at it, right? (20:46): So I'm interested in seeing that. It's good that you do have standards. There should be a framework around how our data is shared. But we do have to be very careful about the ability to access it, how, and where, and why. Those are the big questions. And if we're relying on Company A or Health Provider A to be responsible for their end of the deal, and then Health Provider B is using this system, software as a service, whatever you want to call it, and how are we testing it? (21:27): Nothing makes me nervous. We're on social media all the time. We're posting photos, we're doing all the things we probably shouldn't be doing, but we're doing them. But this is the one thing that is going to continue to give me pause because this is something I don't think we should rush into for the sake of, "Well, we have to get this data out here. There's the Cures Act. And there, we have to do this by a certain time or date." And I'm really interested in seeing where this goes because this is all the marbles, really. Well, this is reminding me of something that we've talked about on this show before, which is that technology doesn't exist in a vacuum. That's right. Correct. The technology that we're building as technologists intersects with the law, it intersects with social issues. It intersects with historical issues. It's all embedded and knotted up within all that. It exists within all of these different contexts and... I just lost my train of thought. Catch the next one. Well, you know what? That was actually a really good segue because Bobur, who's done, like I said, a lot of writing on APIs, he identifies 3 important factors when building an API: problem, people, and context. Those factors are important, but they're not the only things we need to understand. When you are, let's say, dividing this [inaudible 00:23:03][a] application or a legacy system, think about what will be the outcome for the future when you are migrating the system to another newer, better system? Because the factors also depend on not only on the problem, consumer, context, but in the future, how you would like to support. This is the reason that I want to talk about APIs within the context of legacy technology because sometimes the challenge with migrating to a newer platform or a newer system isn't a technical problem—it's a human problem. Wait, explain that a little bit. I don't... Yeah. So we have a situation here where we have the solution, right? APIs are a great way to have 2 different systems talk to each other. There are problems with API security that obviously need to be addressed, if you have leaky APIs, if the people who are building it—there's a lot of episodes we have in our back catalog that you can listen to that have the same kind of refrain. If the people who are building it are not building with security in mind, then obviously you're going to have people who take advantage of that—bad actors. (24:18): But in this situation, it's intriguing that the people who are affected—the patients, the healthcare providers—they are fighting back against modernization for reasons that are, on paper and at face value, quite valid because they're not sure about the guardrails. They're not sure about who's going to have access to data. And even though there are governments and organizations that are trying to work out what these modernization efforts look like, they don't have all the answers upfront. And when you don't have all the answers upfront with something as sensitive as heart surgery, that's kind of concerning. That is concerning. But think about technology usually. Technology usually progresses, everybody jumps on it, and they don't think about these things. This is one of those scenarios where, yes, the technology has taken off. It's been around for a while. It's prolific, but we're trying to use it in this new and different use case where the rules are different. (25:29): This is really, like you said, it's a human problem. You're dealing with such critical information, how do you reframe the way you build and interact when something is such high-value? And I wonder if that's a different thought process. I wonder if that makes you think about it differently. Just a question. I think when we started this episode, I was thinking maybe uncritically about this because I was like, "Oh, modernization. That's good." Of course! Yeah, of course, of course. Yeah, of course. Of course we should use APIs to solve this really important problem. Of course, yeah. Modernization equals good. Again, I was thinking very uncritically. (26:22): I think what I'm having trouble making sense of in my mind is I want to keep the optimism that I had at the beginning of this episode. I want to be optimistic about solving important problems with technology, and at the same time, I want to be critical about the way I'm doing it, and sometimes I don't know how to hold those two things together because it's so easy to slide into pessimism and paralysis. How do you think critically while also remaining optimistic? Good question. Angela, what do you think? Okay, so I'm going to be perfectly honest with you. Yeah, go ahead. Go ahead. I am hopeful, but I am very terrified. This is one of those things where rushing to modernize can definitely have its downside. And for those folks who are rallying against this type of modernization, it's because their lives are at risk. And there's very few things that we do on the internet where our lives are at risk, and this really does just change my perspective in how technology is being used. (27:44): I know that there are amazing companies out there working to solve this very problem. But again, I'm one of those wait-and-see type of people because we cannot, and we should not, want to rush into this without having done a lot of due diligence, and there is no totally impenetrable system. It doesn't exist. That's why there are bugs. That's why things happen, vulnerabilities happen. So can we promise? Never. Right? There's always some risk, right? I think that in the situation or situations like this, fear is healthy because it means you care. Okay, I can live with that. Yeah, fear is healthy. If you're a technologist and you have fear or you have hesitation, that's good because it means that you care about the end goal. You care about the people who are involved and impacted by the things that you make. As long as you don't let it paralyze you. No, no. No, of course. No, of course. You do move forward. You still have to move forward. With caution. With caution. With extreme caution. Kim, I'm really curious, so we've been talking about APIs in the context of healthcare, and we have been talking about how maybe sometimes modernization, we might want to be cautious about it, but what can this teach us about other contexts, specifically with modernization? For me, working on this episode taught me a lot about expectations and the kind of expectations we have with technology when we are just consuming the technology, when we create the technology, and I feel like there's certain expectations on all sides that are manageable, and then there are ones that may not reflect the reality. (29:44): Jamie said something about pushing things fast and breaking things, and pushing and breaking things fast are a part of—whether we like it or not—modern-day tech culture, but that doesn't translate very well into something like healthcare. And I feel like the most important thing for people to take away from all of this because these are questions that they don't have answers, things are still being debated and still going through discussion, going through legislative bodies, through governments. I think the biggest takeaway from all of this is keeping in mind that sometimes humanity has to catch up with what we can do technically. I'll say that again. Oh, there it is. Sometimes humanity has to catch up with what's technically possible, and as long as we keep that in mind and are empathetic to the people who are most impacted on the apps that we build, on the APIs that we are working on, on the systems that we maintain, we'll all be better off for it. What do you think about our API issue in the context of legacy technologies? Is it really the panacea for modernization for older technologies that we think it is? I would love to hear your thoughts about this and on all the other cool things we talked about today. Please hit us up on social media @RedHat using the hashtag #CompilerPodcast. We would love to hear from you. That does it for this episode of Compiler. Today's episode was produced by Kim Huang and Caroline Creaghead. A big thank you to our guests, Jamie Beckland and Bobur Umurzokov. Victoria Lawton is a natural-born communicator, just don't ask her to send you a fax. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Devin Pope, Matias Faundez, Mike Compton, Ocean Matthews, Paige Johnson, and Alex Traboulsi. If you liked today's episode, please follow the show, rate us, leave a review, share it with someone you know. It really does help us out. Take care, everybody. Until next time. All right, see you next time. We'll fax you.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Blog

Friday Five — August 15, 2025 | Red Hat

15. August 2025  |  Red Hat Corporate Communications

...

Blog

Developing a standard AI OS: Unlocking production-grade AI at enterprise scale

14. August 2025  |  Brian Stevens

...

AI inference

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.