API 101 – An Introduction to APIs

For the first episode of our special API 101 series, we welcome back John Orosco, Co-Founder and CTO of Sansoro Health. John lives and breathes APIs – his expertise helps Sansoro Health connect applications across healthcare using the Emissary® API platform. Before co-founding Sansoro Health, John was an early pioneer in implementing APIs in Health IT. His incredible depth of knowledge shines throughout the episode, and will leave both the API novice and expert excited about the potential of APIs to disrupt health IT. If you would like to hear more from John, check out his previous discussion with Dr. Dave about being a startup CTO.

Dr. Dave Levin: Welcome 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’m your host Dr. Dave Levin. Application Program Interfaces or APIs have transformed the digital economy and now poised to do the same in Health IT but what’s all this API stuff is really about, how do they work, where 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 John Orosco, Co-founder and Chief Technology Officer for Sansoro Health. John’s been a guest on 4 x 4 Health several times and has a long history of healthcare IT experience with deep expertise in electronic health records in general and in Application Programming Interfaces or API Technology as well. It’s hard for me to think of a better person to have us kick off this new series we are doing where we’re gonna dive into APIs starting with a fairly high-level summary of what they are and then going much deeper with a series of gasps looking at some specific and important issues. This is also very timely subject because recently the Office of the National Coordinator and the Centers for Medicare and Medicaid released proposed rules on interoperability and information blocking. A substantial portion of those rules address the use and proper business practices related to APIs. So, as I like to think about it John, when you started Sansoro five years ago, APIs were a brand new thing for healthcare, barely talked about and now we see the Federal Government proposing to mandate their use. So, clearly something important is going on here and we are delighted to have you as a guest today.

John Orosco: Yeah, thanks for having me.

Dave: So John, let’s start with the basics. What is an API?

John: What is an API, that’s a really good question. So, I will give you the definition. API, technically stands for Application Programming Interface. So, what does that really mean and what that means is, it’s really an interface or a way for programmers to access functions or procedures in another system through a web call. A web call means that really there’s a request being made between two servers that have network connectivity to one another and usually when we talk about API calls, we’re talking about HTTP or HTTPS protocols. So really, they’re we calls and so that’s what that means.

Dave: Lot of technical jargon in there John. Let’s try to unpack this a little bit for a less technical user.

John: Yeah.

Dave: The way I think about it as a layperson and feel free to correct me is, this is technology that allows two different applications to connect with each other, exchange data and collaborate.

John: Great!

Dave: And that a lot of this today occurs essentially leveraging the backbone of the internet. So, those applications can be pretty much anywhere in time and space.

John: Right.

Dave: And, still connect in near-real-time for this kind of collaboration. Is that a fair summary or did I dumb this out too much?

John: That’s a perfect summary. In fact, I can give you an example. I think if we have an example that people can sort of hone in on, a great example would be the package tracking API service that’s available from the United States Postal Service, just as an example, right. This is something that happens in our everyday lives, this is outside of healthcare, it’s in a different digital economy but this notion that you can take the ability to enter a tracking number for a package and get returned the status of where that package is at and some other data around it, maybe even like the estimated delivery date, that in and of itself is an API. Now, before APIs existed, that sort of information was only known to folks that had logins to the United States Postal Service Systems. So, as they are tracking packages, they knew about it, they can see it, nobody else outside of their system can see it. So, if you go to their website today, you’ll go to a website, you can navigate around somewhere on their site, you’ll be able to enter a package number and get the status of where that package is at. That website is building that sort of user experience around an API. That same API is also used by Amazon. So, if you go to order a package up Amazon and you can be in the Amazon app, it’s not even the United States Postal Service app but you wanna know where that package is at. Amazon is actually is using that same API capability to also tell you where that package is at and when it’s going to be delivered and all those sorts of things and so those are very powerful things and that’s an one example of how APIs are used today and how it’s changed our lives and so it makes every day, things that we have to do like, ordering packages and then knowing where they are at, you can be in one app and it makes it very powerful for a group like Amazon and others to keep you in one experience and you don’t have to go bounce out, take a number or log into a different site, you’ll figure out where the package is at, you can get it all in one workflow and to the consumer, an end user, the don’t even now and they don’t care. For all they know, Amazon knows that information that’s got that database but that’s not what’s happening. They are leveraging APIs that care available.

Dave: Yeah, and this don’t know, don’t care idea also applies to the developers of the two different applications, right. So, amazon doesn’t really care how the UPS system functions, what’s going on in the guts of that system or the structure of its database or any of that, it just wants information about the status of the package and so the API exposes that information to the outside world with the varying degrees of control and makes it available in a way that’s kind of independent and the consuming application can use it in a variety of ways. Is that a fair summary?

John: Yeah.

Dave: Yeah, you know, the other analogy I often think of and again please correct me, is the apps that sit on your Smartphone and I like this analogy because I think it speaks to not just the exchange of data but the exchange of services if you will and so the analogy, I like is the messaging app and the camera app on your Smartphone. There are two separate applications but they work closely together. So, if I’m in the messaging app and I’m sending a message and I want to take a picture and send it, I can do it all from within the messaging app and it’s not that the messaging app has all the camera features and functions built into it, it’s just communicating through an API with the camera saying, hey, take a picture and send the picture back to me.

John: That’s right, yeah, that’s a great example and that’s exactly how you think about all the apps that are on your phone today. Inevitably most of the apps when you download them, they are gonna ask you, if it’s okay for them to access your folders and have access to your camera function and that sort of thing and that’s a lie because as part of the workflow for whatever app you are downloading, they’ve got inherent functionality built within them that gives them value but they take advantage of APIs either native to the phone in the operating system or APIs for are other applications that are on your phone, like the camera. So, that’s a perfect example and those are also APIs.

Dave: I guess again, part of why I harp on this kind of example is the power of APIs goes far beyond simply pushing data around as powerful as that function is. Again, this notion of collaboration between different applications, I think is powerful and important.

John: Yeah.

Dave: So, let’s pivot a little bit to talk about APIs for healthcare because as you and I have often said, APIs are not new but they are new to healthcare. Talk to us a little bit about the benefits and the challenges of bringing and using APIs in healthcare.

John: Well, the benefits are many, probably almost too many to even itemize out in a finite list here. There’s so many things that you could do. If you think about all of the data that’s captured in, let’s say a clinical system, either an electronic health record or a billing system or a scheduling system or radiology, whatever. There’s a lot of things that could be done, there’s a lot of powerful things that can happen if you take different you know, data sets or even functions around that data and expose that as APIs. I’ll give you an example in healthcare that’s actually been around for a little while, most of the EHR vendors today when we think about electronic prescribing, they take advantage of Surescripts as a network, right for being able to query for prescriptions that were sent to a pharmacy, mostly outpatient, that sort of thing. So, when you, if you are a patient, you present at a healthcare facility and they want to reconcile the meds that you have, there’s a Surescripts call that’s been made. That’s really an API. So, they’ve got a network in a system that most of the EHRs today have built in some sort of capability for making a Surescripts connectivity or a connection and getting a list and then helping the clinical user reconcile the meds list with that patient. That’s totally in use today and that’s actually been around for a while. So, that’s a call, that’s considered an API and if you look further than that, you start looking at the things that really aren’t exposed today and it’s really endless. I mean, the possibilities are endless. Think about all of the things that if APIs were exposed to get to all the clinical data that was in a health system, the kinds of things that artificial intelligence or machine learning could do if they had access to that kind of data and exposing that through APIs will give access to these systems that people are doing really cool and innovative things, we won’t even know. Some of it you can’t even think about or wrap your head around now because you can’t even figure out what that would look like but there’s other things that are more apparent just having access to like a patient’s current diagnosis list, their lab results and their current meds. All of those things can be available through APIs and they should be and so those are the benefits. The benefits will be there as people have access to the APIs, they will start to build really cool and innovative things in and around it.

Dave: I mean, what you describe is a series of powerful building blocks that could be stacked to make different solutions some of which we can’t even imagine today, some of which we are like desperately trying to solve as soon as possible.

John: Right.

Dave: You know, I think it’s always useful to think about these things you know, as a question of in comparison to what because we have been doing integration in healthcare for at least as long as I have been in healthcare. I mean, there are technologies out there, some have been around for a long time, is part of the issue that their advantages to APIs over the existing approaches because otherwise why would I go to the effort and cost of switching?

John: Yeah, no, I think that’s a really good point. So, one of the other benefits of APIs is you think about it and even the examples that we’ve given, APIs in and of themselves, if you take advantage of those as a third party, you make an API call, the notion is you don’t have to store that information that you want to utilize in a separate database and so what tends to happen and what has happened over the last several decades in healthcare especially is, if you want to ‘Integrate’, you’re really getting either flat-file extracts of data from a source system or you’re getting an outbound feed of transactional data from a system. That information is being stored and persisted in a different system that wants to take advantage of that data and make it look like it seamlessly integrated and in many ways, it is very innovative and it solved a lot of problems and we do integration today and we have. We’re not saying that integration hasn’t happened but, in that model, now you’ve got copies of the same data all over the place. If we go back to the UPS or the United States Postal Service example, the packaging information doesn’t get pushed out to Amazon or to all these other third parties and they store it just so that the users of their apps when they come to look at what the packages they’re getting it from a local repository, they are using APIs to effectively use other databases in other systems as their database for certain things and so by doing that, if you’d have APIs in healthcare, third parties can basically change their architecture model. You’ve got less data that’s being copied, less data being stored, there’s no need for trying to keep those data stores in sync anymore. That’s part of the problem with anytime you have a copy of a data in a different database, almost immediately you have synchronization issues. Here, you don’t have to worry about that and so, what this does in healthcare and in the conversations that I have with folks especially third parties that want to integrate is, we explain to them, rethink this whole model. You don’t have to store this data. In fact, if you’ve got access to APIs, I would challenge you to say, you really shouldn’t really store this data unless you have a very strong reason why you need to keep a copy of this data. You should be using that source system that you’re getting the data from through an API as the source. You’ve got your own data for you own purposes, that’s great, keep that but utilize these other data sources as an extra or an external data source but you don’t have to make a copy of it and it’s profoundly changed their architecture. It’s shrunk their codebase down, it’s shrunk the disk space own. So, operationally they’ve been able to refactor their applications and become a lot more efficient through the use of APIs.

Dave: And, as I understand it, there’s data and data types that you can’t get through legacy technology or get easily and the API approach tends to expose a lot more data as well.

John: Yeah, that’s totally true. There’s certain things that are either very, very hard to get, certain data types are very hard to get through traditional interface means or next to impossible just because there’s not trigger mechanisms to do that and so the APIs open up a world where you can be exposed to that because what people don’t realize and I think is important to understand, this probably maybe more technical than people care to know but all of the native applications that are out there in healthcare today, they’re all considered service-oriented architectures and really all that means is you’ve got a database, you’ve got a middle tier, like a communication layer and you’ve got an application. That application isn’t directly connected to the database just making calls directly from the app layer, it’s calling services, their proprietary, their services that only that application is aware of and understand how to use in order to get data to facilitate their own workflows. So, you take that same concept and you basically take the middle tier and now you expose that as APIs, it’s really not that hard. They are already set up to do this. That’s why we see things like, FHIR APIs coming out and now the vendors can expose that, it’s really not a major lift for them because they’re really, they are building these API layers and facades on top of on already services oriented architecture. That means, all of that data that traditionally was sort of hard to get to because you had to rely on database triggers or have an HL7 spec or you need a custom coding to develop those data sets to get. Now, you’ve basically got an architecture that all you have to do is put an API web façade on top of an already existing services oriented architecture and it’s way easier.

Dave: I think this is a really powerful idea and again, I’m gonna sort of translate it into my simple layman’s term. The typical application has a database where we store the data. The user interface where the human being is interacting with the system and then there’s a layer that connects those, a kind of communication layer that connects those.

John: Yeah.

Dave: Historically, that was all inside the application part of the beauty of APIs is you’re basically saying, well no, let’s expose parts of this to the world because those services can be used in different ways and be valuable, not just for my particular user interface and app but for others as well.

John: Right.

Dave: If you’ve just joined us, you’re listening to 4 x 4 Health. I’m your host Dr. Dave Levin. Today we are talking about API Technology with John Orosco, Co-founder and Chief Technology Officer for Sansoro Health. The other thing, I don’t wanna leave this legacy thing just yet because you said a lot in there that’s really important but again, the way I think about it you know, kind of simper terms is old-school is I show up and I say, well, what data stream do you already have and typically a whole system will have those data streams flowing but they vary quite a bit and they tend to be kind of brittle and they tend to break whenever you upgrade other parts of the system and by other alternatives to say, well, go run a report and basically you said, flat-file, basically send me an Excel Spreadsheet with the data.

John: Um hmm.

Dave: And, I’m gonna take that data stream that’s kind of limited and not real-time and I’m gonna take the files you send me and I’m gonna use those to create my own copy of your database so that I can then go do the thing I want it to do versus essentially real-time access almost directly to the database. So, why would I make a copy if I can get what I need in real time and always be assured it is the most current, most up-to-date, most accurate information.

John: Yeah, that’s right. That’s the beauty and the power of using an API approach because it is synchronous which means when you ask a question, you get an answer as quick as the machines can process that and so if you’re doing APIs in a way that expose what’s already natively there for a current system’s applications, it’s synchronous and it works really quick. You’re really not adding an extra layer there. Maybe a small one but it’s still small that it’s not noticeable to a human. You are talking milliseconds. So, in that way, you’ve got a lot of power, you have access to it, it’s the stuff that’s committed at that moment, you can trust it a lot more, you don’t have to have these questions about whether or not this is the most current information that you have, you know it because you can consider that a fact. That’s the power and beauty of being able to use APIs.

Dave: So, let’s pull up out of the technical weeds for a few minutes and I really want to go to the highest level of this to talk about why is this important, what is the high level problem or set of problems that we need to solve in healthcare and why are APIs important to that and you know, I’ll kind of give you again my layman’s view of this which is pretty simple. We gotta reinvent the US healthcare system.

John: Um hmm.

Dave: Technology is going to play a critical role in enabling that kind of transformation. It’s not the whole story but it’s an important part of it and a lot of the innovation in technology today comes from building an app ecosystem. It’s the app store model of the world that creates variety and choice and competition and bad ideas fail quickly and good ideas become better and more affordable. So, from my point of view, this is the central challenge in IT for healthcare. We have to become more agile, we have to be able to innovate more quickly and more broadly. One company can never do that. What we need to do is create an ecosystem with a fair and competitive landscape so that the people that are going to invent the next generation of Genomics Technology or the best patient engagement app or the best way to dictate a note or detect sepsis or any of a thousand other important clinical and business problems, it’s the old idea of you know, let a thousand lilies bloom and the key to that is you have to have robust interoperability, you’ve gotta have the kind of show up, connect, collaborate that we’ve talked about or you can’t build that kind of ecosystem. So, from Dave’s point of view, this is why this is an important issue and why APIs are such a welcomed and powerful solution to this problem. Do you see it that way and from a technical perspective it might be unrealistic or it might over-the-top here?

John: No, I think that’s spot-on. I mean, you think about you know, other digital economies and the reason why your phone and the app store is so great is because you have access to all these different applications and tools that people have created and it’s not one company that’s creating all of them, right. So, Apple isn’t the company that creates every app on the App Store. They couldn’t, I mean, they physically couldn’t and even if they tried to, they wouldn’t be that good at all of them, right. So, this notion that one group can be that great at understanding all these intricate workflows and being the greatest developer and designer of all these apps is absurd and I think they know that. So, what they did instead is create an ecosystem. There’s still the core, there’s still the system but you build an ecosystem around other people being able to integrate with it, those are the people that integrate with it in tern into promoting your own system. So, now it becomes even more sticky and you’ve got a lot of value because you’re bringing a lot of value through other developers that you don’t even have to pay, that’s the crazy thing, right. So, Apple doesn’t even pay these developers to develop all these apps. They have their own business model, you know, essentially, they have hundreds of thousands if not millions of developers coding against their platform and promoting their platform, they don’t even pay them a dime. So, that’s the beauty of what you are talking about is creating an ecosystem. The innovation will happen if folks have access to the data through APIs or whatever mechanism it is or figure it out and let the market dictate who’s winners, let the market police who’s bad actors. Bad actors aren’t gonna last like, they’ll get killed in the market. So, you let the market dictate who’s good and bad and that’s who wins and all the while, you still got this core system and all these folks that are developing against your system, they’re promoting your system for you.

Dave: It’s so true and I recently was doing some research on this question to write an article and I think you and our listeners will find this information interesting. So, in 2017, Apple’s App Store revenue grew 30 percent year-over-year, it generated 26 and a half billion in revenue for its development partners and it’s estimated about 11 and a half billion for Apple. So, like you said, this was one of those grow the pie, everybody wins kind of exercises and it’s about platforms for innovation and again, the key enabler here is API Technology. If your camera app and your messaging app can’t collaborate, you’re not gonna build much of an ecosystem and what you and I were imagining is what this looks like at scale in healthcare and I suspect you’d also agree with me, this is how we are gonna solve some of the usability problems too. We’ve not been particularly good in healthcare, at human factors and usability, at making things patient centric and all these other issues that are kind of, we were second order when we were just trying to get the basic infrastructure in place. Now, they are real important and I think the solution to those is the same thing. You know, innovation, competition, experiments in the marketplace will sort all that out and I suspect you’ll agree with me.

John: Yeah, no, I do agree. I think the other thing, the problem that we can solve here which is obvious and everybody talks about is the fact that we’ve got data today in silos and it’s super inefficient. The cost and the overhead of duplicate data or manual data entry and duplicate systems, all of that stuff starts to go away. We’ve become way more efficient than we are today. The cost of healthcare can come down as it relates to administrative and just operational things that have to happen every single day within a healthcare setting. That alone, outside of just having a better form factor and usability, if you can shrink cost and actually make people happier and give them a better experience, get them access to data when they need it, better patient outcomes, I mean, that’s why I said, the benefits are almost too many to even quantify because it’s hard to even fathom a world where if it was truly open, all the awesome things that could happen. So, I totally agree with you.

Dave: It’s kind of like if I said to you, hey John, we just invented the wheel, what are the advantages of the wheel, you’d probably go on at length. You know, the other thing I’ll add is this also has patient safety implications and I’m thinking specifically of the work we’ve done with a company like PipelineRX, so they do telepharmacy, under the old integration model, their pharmacists working remotely would be working in both their native application and up to seven different EHRs at the same time. So, setting aside what a nightmare of a job that must be and the workflow issues, that just makes me cringe when I think about it from a patient’s safety, it’s just so easy no matter how careful and attentive you are to make a mistake and now through the power of APIs, these pharmacists are largely able to work within one native system. They don’t have to flip screens, they don’t have to learn ten different EMRs, the patient safety and as you’ve already pointed out, the efficiency is pretty obvious.

John: Yeah, totally agree. Patient safety and think about just the time it takes, if you sat on with one of those folks all day and just counted the time than flipping between applications alone, that time saving is probably blow your mind. So, just the throughput alone and on top of that you make it streamlined for them so that you’re cutting down on mistakes, inadvertent mistakes and helping with patient safety, all of that and the business model is completely the same and now you make it way more efficient for a group like Pipeline, you make it better for the folks that they serve all the way around, it’s phenomenal.

Dave: So, the last thing I wanna comment on and then we will turn to your sage advice is I’m making my way through the proposed ONC rules and what I see is this theme about a level playing field and more competition. It’s interesting to me John because a lot of the specifics are I think designed to promote more openness, more sharing, the freer flow of data and access for innovators that want to create the new apps for the new ecosystem and I don’t often say this about the Federal Government but as I grow to understand what ONC and CMS are doing together, I think they are spot-on and they way they are going about it is very creative and dare I use the word Brilliant because they are not saying, do it this way, they propose to mandate adoption of APIs as a core technology but they also say or successor technologies. So, they recognize, maybe twenty years from now there might be something better but a lot of the rules are really more around frankly behaviors. You know, what can you charge for this, what kind of access control can you establish and it’s a delicate balance because people have a legitimate right to protect their IP and to make a decent revenue but it is a balance. So, forgive me, I know I’m up on the soapbox here but I do see that theme here, I think it’s very consistent with the points you’ve been making about how we get out of the place where we’re a little bit stuck right now and get to a more agile kind of innovation.

John: Yeah, I think that’s right. I’m making my way through that rule as well and I think that is the theme that I’m taking away and to say it a slightly different way, I think the Government realizes there’s not a good technical reason why this doesn’t exist today and hasn’t been around forever. So, this notion that this isn’t gonna happen or it’s too hard or it’s too complex, they are not buying that anymore. So, better have a really strong reason why things can’t be interoperable or you can’t exchange data easier than what we’ve been accustomed to. I think that’s the overarching theme and it’s really built based around, first of all patient access, right. So, patients should have ready access to their information whenever they want it and I think that’s a really good start and I think where you see it go from there is it starts to get into other areas that aren’t just related to like patients and their access but it’s how these systems can interact with one another to better promote you know, patient outcomes and all of that good stuff but it’s for the greater good. It’s for the better efficiency, it’s breaking down data silos, it’s all of those things and so I’m encouraged by what I’ve seen and I like the fact that ONC and CMS seem to be in lockstep in terms of being on the same page and sort of honing these rules together in a consistent manner. I think it’s gonna be great for everybody.

Dave: Yeah, I’ll pick up on that last point. It’s no accident that they release their rules simultaneously.

John: Right.

Dave: And, you can see how they fit together and very simply, ONC is defining the expected behaviors when it comes to technology and sharing a data and CMS is saying, if you wanna get paid, you’ll follow these rules. It’s a pretty effective set of carrots and sticks. I’ve seen it worked before in other settings. So, like you I’m pretty optimistic and then lastly and your point about the focus on empowering patients and making patients’ data available, I could not agree more with you. Very smart way to get this started. That’s mom and apple pie, the data belongs to them in large part, pretty hard to argue with that position. Most of the arguments against it are pretty layman in my judgement. So, let’s go to the last question today John and you are one of the most seasoned people in healthcare when it comes to APIs. So, if anyone is able to offer some sage advice whether it’s about how to get started or how to think about it or other challenges or opportunities, tell us John, what is your most sage advice when it comes to APIs?

John: Well, my most sage advice related to APIs, yeah, I can come at this from many different angles. One way to think about it is coming at it from as an API designer which is where I’d live, right. So, I’ve been doing this for a long time and as an API designer, my most sage advice would be to folks that are doing that, don’t over architect the API. Too often I see development teams become paralyzed by designing the ‘Perfect’ API or object model. We call this affectionally paralysis by analysis and what ends up happening especially if you have two or more architects or two or more strong engineer types in the room together, you literally, it’ll go nowhere and what gets designed out or what gets Specht out is this utopian world that is almost impossible to achieve and it’s pure in it’s design, it’s and that’s what designers do it. They want it to be pure and they want it to be perfect but you don’t have to do that. Don’t let the perfect be the enemy of good but don’t design a piece of crap either. I’m not saying you know, just punch something out that is garbage but at the end of the day what consumers of APIs care about it’s a few things. One, is the API well documented, right? So, if I’m a consumer of an API and I want to come and understand how I’m gonna be using an API, is the documentation good enough for me to be able to do this on my own, do I understand how to make the call, do I understand what’s required as input parameters, do I understand what I’m gonna get back and the data types in the definitions around those data elements, so that I can on my own figure out how to do this integration because I know my application, I know what I need. If the APIs are well documented, that’s a very important thing for people who are gonna consume it. The second thing would be and I already mentioned it, does the API return the data that they need? So, not only is it documented but is it robust enough that it’s going to give you everything that you need so you don’t have these major gaps. What we see oftentimes in integration projects is you get 90-95 percent of what you need through whatever’s out there for integration today but that last 5 or 10 percent is critical, it’s like a showstopper and so, are they getting what they need and then finally, is the API contract consistent from release to release and what I mean by that is and we’re very strong about it on our group, you can’t change. We talked about passivity, introducing non-passive changes, what that means is if you publish a contract in terms of an API to folks and people code against that and they depend on that and they’ve actually got it working and it’s live, every future release specifically for that API that’s already been released, you can’t change and break that contract. So, making sure that you remain passive in your approach, you can do versioning, there’s all kinds of strategies that let people make non-passive changes but you have to adhere to that contract that you created and if you do all those things, you win. Everything else is gravy and quite frankly or it’s you’re doing stuff to make yourself feel better like, over designing and trying to have a perfect bottle but that’s probably my most sage advice when it comes to API design.

Dave: You know John, I here and there a theme of agility too and agility at the design and tactical level and I like that because I think it also resonates with agility, it’s a strategic level. So, what do I mean by this, I heard you say, don’t overengineer, don’t make the perfect, the enemy of the good and the ideas of passive design and the rest. I think that’s all intended to say look, you know, make it good enough to get started because it’s always about evolution. These things will change and evolve and they are designed to be able to change and evolve in pleasing ways. That’s really powerful if you will at the design or the technical level. What I’ve also seen is the use of APIs creates a strategic agility as well, so that application developers can evolve their stuff more quickly because they don’t have to fret as much about, can I get this extra data element, how hard is it gonna be and likewise, I think at the organizational level, organizations can say look, we are gonna get this patient engagement app because we’re gonna make a bet on patient engagement but it integrates with our system through an API. So, if two years from now we don’t look like this one, pull it out and stick another one in and that’s you know, sort of bringing it all the way back to why does this matter, it’s the agility at that technical level that creates the agility at the strategic level which brings us back to, we need people to be out there experimenting, creating new things, failing, succeeding. Every time we make that cycle faster, everybody wins.

John: That’s right, that’s very well said.

Dave: Well John, we really appreciate you taking time to speak with us today. We’ve been talking with John Orosco, Co-founder and Chief Technology Officer for Sansoro Health and one of the most seasoned and experienced API developers in healthcare. John, thanks for helping us kick off this series on API 101. I think you really did a great job of answering the basic question of what’s an API and why should we even care about it in healthcare.

John: Thanks again for having me.

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.