API 101 – Lessons From Outside of Healthcare

In this episode of 4x4 Health, we continue our exploration of APIs with Sam Pierson, the VP of Engineering here at Sansoro Health and a recent addition to our team. Sam has extensive experience working with APIs outside of healthcare and we were excited to explore his unique perspective in this episode. Throughout the conversation, Sam touches on several important developments that have already revolutionized e-commerce, such as cloud computing, and explains how APIs can unlock these innovations for healthcare. We often say that healthcare is a decade behind the rest of the internet economy and talking to Sam is a great reminder of Health IT’s incredible potential to decrease costs and improve outcomes for health systems of all sizes.

Dr. Dave Levin: Application programming Interfaces or APIs have transformed the digital economy and they are now poised to do the same in Health IT, but what’s all this API stuff really about, how do they work, why are they better than traditional healthcare interfaces, what should you know before you dive in? In this special series of 4 x 4 Health, our guest take on these and other questions. They help us demystify APIs and show us how we can use them to transform healthcare. Today I’m talking with Sam Pierson, Vice President of Engineering for Sansoro Health. Sam spent his career building software and software organizations as well as developing technology and product strategies. Prior to joining Sansoro, Sam was the Head of Engineering at SPS Commerce, a high-growth SAS company that serves retailers and vendors in the e-commerce space and has one of the most successful retail cloud services platforms available. At SPS, Sam focused on their API product and platform. He’s also held technology leadership positions and led various product incubation functions that companies like, Veritas Technologies and Symantec Corporation. Sam is relatively new to healthcare and brings an important and fresh perspective based on his years of experience in other industries. Perspective that’s invaluable as we reinvent healthcare and Health IT. It’s why we hired him at Sansoro and it’s why I asked him to join us today to share his perspective on APIs in general, how they’ve transformed other industries and how they could do the same in healthcare. Welcome to 4 x 4 Health, Sam.

Sam Pierson: Hey, thanks for having me Dave.

Dave: Before we get into the API discussion, let’s start with our usual opening question Sam. Take a minute and just tell us a little bit about yourself and about Sansoro.

Sam: Yeah, as you mentioned, I am relatively new to Sansoro. I think this is the end of week three for me and as you said before, you know, I am new to healthcare as well. You know, I’ve spent my career in the software industry building software, building teams and so that’s really you know, what, that’s really how I ended up here at Sansoro. We have folks in the team that spend their time building out the integration layer into the various EMR systems and exposing the common data model and then we also have some folks that are most focused on continuing the build-out of the cloud-based solution. I’m based here in Minneapolis and I started as an engineer before moving into different leadership roles in the software companies.

Dave: Sam, I’m always curious about people that come into healthcare, particularly when they’ve already had a successful career elsewhere. What drew you to healthcare at this point in your life?

Sam: Yeah, well, I think there’s, healthcare is a really interesting space. I think it’s really big. Here in Minneapolis there’s lots of companies that are involved in it and so, you know, it’s been something that I’ve wanted to get into and being able to build products that help people get better care and you know, improve the outcomes. I think it’s something that you know, just on a personal level is something that I’ve wanted to be able to do.

Dave: Well, that’s terrific and regular listeners of the podcast have heard some interesting answers to that question as well as discussions around how folks inside healthcare and folks outside healthcare really need to come together to sort out which one’s a big and challenging and important set of opportunities in our country right now. So, welcome to the fight, we’re glad to have you.

Sam: Yeah, thanks.

Dave: Let’s turn to APIs now and I am gonna ask you a series of four questions. We’ll take about four minutes to delve into each one. I like to start by asking each one of my guests in this series, in your own words, what is an API?

Sam: Yeah, well, you know, APIs are things that have been around for a really long time, you know, basically as old as computing itself. So, it stands for Application Programming Interface but it’s really just a neatly packaged piece of functionality, more of a, you know, a standardized adapter that you can count on to do something and to do it well. You know, there’s a million different analogies for this stuff but I, you know, the one that I kind of looked to is you know, if you are building a house in the basement, you know, you’re gonna get a hook up to the gas line, you’re gonna get a hook up to water, you’re gonna get a hook up to electricity and so, you know, when you go and build a new house, you don’t have to, you know, figure out how to make electricity, you don’t have to put your own water system, right. You’ve got a standard hook up where, you know, that stuff just comes into your house and it’s just something that you can rely on to be, you know, this fundamental building block as you’re building something bigger.

Dave: That’s a really interesting analogy and it’s a new one in this series. I’m gonna take the liberty of building on it a little bit. So, I love this idea of you know, let’s take electricity as an example that it’s a service that’s provided, it’s easy to hook up to and consume. It’s important to note, there’s some underlying standards there. So, it’s 60 Cycles, you know, 60 Hertz, and 110 or 220 and the plugs are designed and the sockets are designed to be compatible and so there are these interesting analogies I think in the physical world if you will to, so the world of software and design as well, so that’s really good. You know, at the end of the day what I usually say is APIs make it possible for applications to connect, exchange data and collaborate and they really are forming I think an important part of the infrastructure for the modern digital economy and for the emerging app ecosystem in healthcare as well.

Sam: Yeah, yeah, absolutely.

Dave: So Sam, as I mentioned at the top of the show, part of why we asked you on the podcast was to get a view on APIs from outside of healthcare. I mean, like you said, they’re not new, they’re just relatively new to healthcare. So, what I’d like you to do is take a few minutes and tell us about you know, on your, based on your experience, how APIs have been used in other industries and some examples of real transformation that was enabled by APIs.

Sam: Sure. So, I think, you know, I think it’s useful to, I think it’s useful to look at the history of this, of the use of APIs and how software is evolving and I think that’s been the thing that has really opened up innovation in these avenues for doing new things, right. So, you know, originally, you know, an API might be something that’s provided by an operating system, right or a programming framework and as software companies, you know, build bigger and bigger packages of software, there’s a, there’s been a pattern that’s emerged where those things get broken up into little services and so as those services are used across the rest of the product, the API is a really good, is a really good tool to use because it just completely abstracts and hides all the details underneath that API if the side and now as those APIs have proliferated, I think you see more and more companies that are actually offering APIs as a product, as opposed to something that’s just internal and I think the big idea there is that you don’t have to do everything yourself now. So, you know, I think that, you know, one, just one quick example is a you know, is around the consumer space. So, you know, all these different companies have websites and historically everyone has needed to track their own users and create their own user databases and once Facebook came around, you know, everybody was on the Facebook and so Facebook offered a set of APIs that would allow people outside of Facebook to let their users sign in with their Facebook credentials and so if you look at like this is just, it’s just a small example but I think it’s appropriate for APIs is that, you know, for the website that’s using Facebook’s APIs, you know, it reduces friction, it you know, increases user signups, it enables more tracking, it eliminates the need to manage any of those users yourself and then from Facebook’s perspective, right, it’s kind of a strategically compatible approach for them because now they become an even stronger network of, you know, of users and identity. So, that’s you know, that’s just one example where, you know, where APIs have started to, you know, basically replace whole buckets of functionality that software vendors would historically need to do.

Dave: Sam, I think that was terrific and you’ve just compressed about 30 years of programming history. It’s about a two minute summary and it’s been really interesting to me to talk to people like you and like John Orosco, Chief Technology Officer at Sansoro and others about the sort of underlying change in software architecture and how this gradually evolved into something that’s external facing as well. So, let me recount this the way I understand this and you know, I did some programing back in the stone age and in those days we built modules if we were really sophisticated but, and those modules did certain things but the modules were very tightly linked to each other and to connect one to the other, you really had to understand a lot about what module B was doing so that module A could connect to it and vice-versa. So, they were separate but very tightly intertwined and linked. You’ve had to understand the data structures, you often had to understand some of the business logic and the rest and the first transformation then was really in the internal architecture when we went from this modular design to a services design and essentially, we took those modules and we made them much more self-contained. As you said, we hid the complexity and the business rules and the others and increasingly it was more about how one module can provide services to another and it allows you to connect them in a much easier way and much less dependency and that was the services oriented architecture approach and then eventually it was realized, hey, you know what, you can expose these same services to the outside world to other applications and then the sort of idea of API was really and particularly public API was off and running and that’s how today Facebook and Google and others collaborate and share data, it’s how Amazon can tell that UPS has the package and where it is and all the like and for those who are interested in a deeper dive on this, we’ve put a series of blog posts up that kind of walk people through this and illustrate it. So, this and, this is the point where you get to correct me publicly if I’ve said things that aren’t exactly spot-on or…

Sam: No.

Dave: Please correct or elaborate…

Sam: No. I think, you know, I think all of that is right, you know, and I think one of the other things that’s driven this is you know, [Unclear] now, you know, it’s not just all software running in a data center, you know, these big monoliths, right. You’ve got, you know, this predominant model now of you know, being sent me being a SAS company, having a, you know, of this cloud-based offering and when things are running in the cloud and they’re publicly accessible, that you know, that has really opened up the door for you know, this reduced friction for consuming other people’s APIs and I think the, you know, the biggest you know, one of the biggest things that is driving that is you know, you have, you know, if you’re gonna start a software company and you have to, you’re gonna build, you know, build a new system, you, you know, you want to be focused on what you’re good at. You know, should you have your engineering teams and building out tools for logging or for observability, you know, these are areas where you can rely on the APIs and the infrastructure that are provided by you know, these other, you know, these other companies and they have opted now, you know, instead of making a product that is, that has an user interface per say, right. They are leading with an API first approach and because that’s the, that is the most expedient way to market, it’s the most expedient way to provide value to your customers.

Dave: So, there were two I think really important things in there and I want to go a little deeper on that. So, one is this idea of, you know, as people think about their business, they make decisions about, what am I gonna own and do internally and what do I essentially wanna outsource if you will and APIs bring an incredible flexibility there in terms of the technical planning. I can either build it myself or I can look for someone that does it today and offers that service through an API. I think most people can follow that but there’s something else you said that I think some important subtlety that personally I have just really started to grasp in the last year which is the connection between API technology and mobile computing, cloud-based computing and I certainly can’t get at all the subtleties but what I’ve been learning or at least I think I’ve been learning from folks like you and others is, you can’t do it without API technology, you can’t deliver the modern experience of you know, computing delivered in your device, in your hands and it’s mobile and it’s everywhere. If I’m correct in that statement, can you elaborate a little bit about that and why it’s so important?

Sam: Yeah, no, I think you’re absolutely correct. You know, there’s been a lot of different models for, you know, for building and delivering software. I think the APIs as a, you know, again, as that standardized interface allow, you know, allow consumers and consumers of those APIs to, it just, it unlocks a whole bunch of different innovation that wouldn’t be there without those building blocks. You know, and I think it’s almost, you know, this proof by just all of the different combinations that are out there, right. So if you’ve got, I’ll give you an example, so Amazon offers a set of APIs that are, that enable anyone really to have machine learning capabilities or to do these really advanced things like image recognition, right. So, you could build a business around, you know, taking pictures of a receipt and then analyzing the text in that and importing that into a, you know, importing that into an expense product, right and so the company that’s gonna go do that doesn’t have to build their own machine learning models, right. They can go directly to Amazon and just use this thing that has been provided by them and by the way, which is getting, you know, better and better and better every day.

Dave: Right and in fact that company probably could never build that text extraction tool better than the one Amazon can deliver.

Sam: Right.

Dave: One more at the price point that Amazon can deliver at.

Sam: For sure, for sure and I think there’s others that are, you know, potentially even more important, right. So, you think about security, things around authentication and authorization, you know, if you’re a, you know, if you’re a bank or if you’re a hospital, you’re gonna want to make sure that those things are rock-solid and, you know, I think way, you know, early on a lot of people would, you know, they look at well, how do I, maybe I need to build my own, I’m gonna create my own cryptography to protect things inside of my products. Well, you know, the best way to do that today is to go, look at the standard, cryptography libraries and use those, you know, that’s gonna be the best, you know, that’s gonna be the best. Not only is it gonna be the best security solution but you’re not gonna spend your own time doing something that isn’t gonna make a, isn’t necessarily gonna make a big difference for, you know, for your own business.

Dave: Yeah. I’ll give you an example from healthcare. We have a chronic problem with patient identity. Is Mrs. Jones in this record, at this practice the same as Mrs. Jones in this record, in this other practice? And, there are now available some essentially services like you described that allow me over the internet through a consumable API to leverage that service to see if these two records are the same service and it’s very rapid, it’s far more robust than anything I can build myself. Presumably it’s highly cost effective as well. So, essentially what we’re are talking at is you can begin to take these sort of key challenges, problems, services whatever and encapsulate them in a way that they are become building blocks and you can stack them and use them in different ways and then lastly I just, I wanna beat this horse completely to death. It’s combining that with cloud computing is allows you to deliver this essentially anywhere, anytime on demand and it’s that combination that, that’s just been incredibly powerful and transforming a lot of other industries.

Sam: Right.

Dave: I’ve got that more or less, right. I mean, I’m sure there are many other factors too but…

Sam: Yeah, no, that’s totally, that is, that’s totally right.

Dave: If you’ve just joined us, you’re listening to 4 x 4 Health and we’re talking about APIs for healthcare and experience from outside of healthcare with Sam Pierson, Vice President of Engineering for Sansoro Health. Sam, we’ve talked a little bit about the benefits of using APIs and my guess is you can probably name a few more. I’m also interested in some of the challenges. So, what have you seen in terms of challenges from outside of healthcare and what kind of window has that given you into some of those, either similar or different challenges in healthcare.

Sam: Yeah, yeah. Well, I think, you know, I think, you know, we talked a little bit about architecture and software design, you know, these patterns that they have emerged around micro-services. You know, I think it’s Epic, like building the system becomes more simple, it enables you to be intentional about your design. One of the things that does get challenging though is now you have this just, you’ve got a distributed system and you have these pockets of functionality that can potentially be, you know, littered all over the place and so, you know, having a strategy for being able to quickly refactor your software or you know, being able to change a pattern is, you know, is really important because there’s just an increased complexity now of you know, having these APIs get plugged into different parts of your software.

Dave: It’s that old challenge of you can deconstruct things and there’s value at deconstructing them into smaller units but they’re also that creates more challenge when you try to construct them into a functional whole. Is that…, yeah.

Sam: Yeah, yeah and just to, I mean, to build on the analogy that we were using before, right. So, we talked about electricity, right. Well, you know, I don’t, you know, my house, we, you know, we bought this house, you know, the electricity is, the electrical wiring is run through the house. If I want to make any changes or add line, you know, add additional outlets, right, like I’m gonna have to do some pretty significant work to either tap into the existing lines or to, you know, refactor the way that the electricity is run throughout the house. The same thing with, you know, with the ductwork, you know, if I’ve got a room, if I’ve got a room that gets cold in the winter, you know, it’s gonna be a pretty heavy lift for me to run another duct all the way from the basement where the furnace is up to, you know, the second floor when, you know, when everything is finished and I think that, that’s a, you know, it’s just another, another analogy for, you know, for software where, you know, if you’re not careful about how you build things, you know, you can end up in a situation where you have to, you expend a lot of resources just, you know, making things more flexible and not necessarily adding as much business value for your customers.

Dave: It’s a good caution and of course, the flip side of that and I’ll just, I’ll continue, or analogy is that you’re essentially talking about re-engineering an existing building or doing some rehab. The plus side of course is, if you decide to do an addition then you already know well, these are the components that are available, this is the type of wiring, these are the sockets you should use. Here’s the switches and the outlets and all the rest and it’s, and at that point the design challenge really becomes more about well, where do I put these things, how do I could form to code and those others but all of those other issues have been worked out for you in advance. I wanna go a little deeper on this too because I’ve seen some interesting things in terms of forward and backward compatibility in the API world and at least it seems to me as an ancient and at this point inexperience programmer that there are some inherent advantages here in terms of being able to make passive changes, extending data models, extending services to enhance what you’re doing while still preserving backwards-compatibility so that people that use it today aren’t completely disrupted and of course, that’s something people strive for in general and in software design but, are there some particular advantages in the API world in terms of the keeping everybody whole while you continue to move forward and then, and advance the capability?

Sam: Yeah, I think with APIs, it is a challenge, but I think it’s probably more so a challenge if you, you know, if you don’t have APIs, right. I mean, so, APIs are gonna allow you to decouple, you know, responsibility and, you know, in that business context between different services. I think there’s, you know, there’s two different things. One is, you know, at Sansoro, right, we take a lot of time to think through impacts to the existing data model, right and, you know, I think from a vendor perspective, you know, you are always trying to make the developer’s life easier, right and so that means as much as you can do without needing to issue breaking changes in the API, you know, it’s almost, you know, it’s your responsibility as a, you know, as a product developer to, you know, to make sure that you minimize those as much as you can and then, you know, that encapsulation layer does help you do that and I think, you know, in vice-versa when you are in the market looking for a product that solves a problem that you’ve got, understanding how that vendor chooses to version APIs and, you know, how robust their you know, their backwards compatibility is, is an important thing to consider.

Dave: Yeah, and it’s very interesting to me to watch this in terms of the ability to say, I’m gonna add some things to enhance what I’m offering today but that’s gonna be transparent and invisible to someone who consumes the current API. It’s an addition to, it’s not a disruption of and so, we’ll continue the electricity analogy I think until we’ve completely destroyed it, but the analogy here would be, I started out with a two-prong plug and then I added some sockets that are three prongs. They have a ground pin as well but those old two-prong plugs, they still can plug in there. They can’t take advantage of the grounding, but they still work. So, you know, kind of a simple physical analogy to the sort of evolution. Doesn’t happen automatically in the API world, you have to think and plan, but my impression is that some of the basic constructs of how API sort of designed and operate, make it easier and more possible to do that if you are intentional about it.

Sam: Yeah, that’s right.

Dave: Great! Any other challenges that you think folks should be aware of, particularly the people that are kind of new to this or diving in?

Sam: Yeah. I mean, I think as you build out your own systems just, you know, having a strategy for identifying issues with, you know, whether it’s your own services or whether it’s with services you depend upon. You know, there’s tools that will monitor APIs for you, they will alert you and they’ll call you if those APIs are down or things are having a problem. I mean, I think those are just some of the things that you got to have in place, otherwise, you know, when things go poorly and they will go poorly, you’re gonna be, you know, you’re gonna be kind of grasping at straws.

Dave: Well, the last question I usually ask my guests is to offer us some sage advice. I’m gonna give you the option of offering us just sage advice about life in general or if you have something specific about the world of APIs or both, it’s really your call.

Sam: Okay, yeah. Well, I think I’ll stick to the APIs, but I think like, you know, like anything else, I think you got to have an explicit strategy, you know, and that strategy has to map to, you know, what you do well, what your company does well, you know, the strengths that you, you know, that you bring to the table and, you know, be, you know, be very clear about what do you want teams to be focused on and what do you want to completely outsource to somebody else and then making sure that those values are aligned at the company and at, you know, at the team level and, you know, that’s probably, you know, the biggest thing is, you know, coming at it from a, you know, from a tops down kind of strategy level. I think that, that you know, just approaching those decisions with a framework around, is this something that we wanna be in the business of, is a really powerful question and then it’ll, you know, that’ll subsequently open up the door for, you know, evaluating partners that, you know, I think that at the end of the day will help you go much faster as a business than you would on your own.

Dave: Well Sam, I think that’s, that is actually sage advice about life and about work in general and as you’ve pointed out I think very clearly today, part of the beauty of API technology is it just gives you a lot more flexibility and granularity as you think about the thing that you wanna accomplish and, you know, what do you do yourself and where can you essentially find a partner that’s just got a better mousetrap and then leverage that through API services. So, to me this all comes together very, very nicely. The last thing I would ask you today is as you think about experiences from outside of healthcare, was there a moment when this all just crystalized for you? You know, when you looked at the landscape and said, this is the future, and this is where we’re going.

Sam: It’s a, you know, it’s a really good question. I don’t think that there’s, I don’t think that there’s, there was ever a, you know, a moment where that really hit me but I think, you know, in, you know, in other companies we, you know, we would always talk about, you know, hey, there’s gotta be a way for us to scale teams, you know, and that was sort of the first, you know, that was one of the first ones where, you know, APIs became the way that teams would, you know, essentially co, you know, coexist and it helps the organization to scale, you know, and then that’s kind of at the organizational level and then from a product strategy level, you know, at SPS we realized that, you know, there’s a lot of value that we can bring to the market through, you know, this web-based products but at the same time, you know, we started to hear more and more from customers that wanted to, you know, they wanted to integrate our functionality into their own offerings and, you know, the most clear way for us to do that was through this API first strategy and then, you know, when I, you know, when I started talking with, you know, Jeremy and the folks at Sansoro, you know, it was just, it was very obvious that this is, you know, this is something that solves a major problem, you know, and ultimately will, you know, will help others, you know, innovates in the healthcare space.

Dave: Well, I love the connection you drew to how you organize your teams as well because just like API allows you to sort of containerize if you will, to sort of say look, we’re gonna put these functions over here and this is what they’ll look like to the outside world. It allows you to organize your teams that way as well. They can focus on their segment of this if you will. I can tell you from my perspective, I’ve had two moments at least in the healthcare world where I was convinced that APIs were coming and they’re gonna change healthcare. One was several years ago when I saw some just early demonstration projects of using APIs as an alternative for integrating applications into an EHR and what those teams were able to do just blew me away and I was absolutely convinced at that moment, this is where we’re headed in healthcare, I don’t know how [Unclear] or how far but that’s where we’re going and when we started out at Sansoro five years ago quite frankly, we’d go to a lot of health systems and we get puzzled looks when we talked about APIs. Well, we’ve come a long way because as most people know in the past month or so, the Federal Government has dropped proposed rules that mandate, the adoption and use of APIs as part of the modern infrastructure for healthcare. So, we’ve gone in five years from, what are these APIs you speak of to, we’re all gonna adopt and use APIs and I think that’s a real powerful moment and I’m personally very excited about it because of the many things we’ve talked about today. It unlocks creativity, it’s more efficient, it allows us to collaborate, it allows us to evolve and innovate much more quickly. All things that we desperately need to do in healthcare. So, Sam, I’m grateful to you for you joining the fight but for it’s a good cause, it’s a, it has a lot of meaning and I’m also grateful for you sharing your wisdom with us here today.

Sam: For sure. Thanks for having me Dave. You know, I couldn’t be more excited to join the team and get to work on this stuff.

Dave: We’ve been talking APIs with Sam Pierson, Vice President of Engineering, Sansoro Health. Sam, thanks again for joining us today.

Sam: Thanks Dave.

Dave: You’ve been listening to 4 x 4 Health, sponsored by Sansoro Health. Sansoro Health, integration at the speed of innovation. Check them out at www.sansorohealth.com. I hope you’ll join us next time for another 4 x 4 discussion with healthcare innovators. Until then, I’m your host Dr. Dave Levin, thanks for listening.