API 101 – FHIR: A Standard API for Healthcare

We continue our API 101 Series with this 4x4 Health episode featuring Wayne Kubick, the Chief Technology Officer of Health Level Seven (HL7) International. Like the World Wide Web Consortium, HL7 International is a standards development organization devoted to an interoperable world. For over 30 years the foundational HL7 standard has helped healthcare organizations communicate and, today, Wayne is leading HL7 International’s development of FHIR (Fast Healthcare Interoperability Resources): a new standard for the future of healthcare. Dr. Dave and Wayne dive deep on both the potential and challenges of APIs disrupting Health It. FHIR is unquestionably going to play a major role in the future of healthcare interoperability and, in this episode, we start to define what that will look like. For a chuckle, check out the FHIR puns website referenced in the episode.

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 are now poised to do the same in Health IT but what’s all these 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 am talking with Wayne Kubick, Chief Technology Officer for Health Level-7, usually refer to this HL7 and answer your credited Standards Development Organization or SDO. HL7 is dedicated to the vision of a world in which everyone can securely access and use the right health data when and where they need it. Wayne has held a variety of senior executive roles over the course of his career. Prior to joining HL7 in 2016, he served as Chief Technology Officer for CDISC, the leading SDO for pharmaceutical clinical research. If there’s anyone who’s at ground zero when it comes to interoperability in healthcare, it’s Wayne Kubick. Welcome to 4 x 4 Health Wayne.

Wayne Kubick: Well, thank you Dave and it’s great to be here and happy to be chatting about APIs.

Dave: Well, that’s great! Before we get into the API discussion, let’s start with our usual opening question. Take a minute and tell us about yourself and your organization.

Wayne: Yeah, sure. So, myself, I’ve been in the Information Technology  space for something like thirty years, originally did some work in the Defense Industry but most of that time was spent in the space of pharmaceutical political research and drug safety. I was a CIO for a major service provider Parexcel International that conducts clinical trials. I did a start-up with data analytics which was later purchased by Oracle and from there I went into working in the standards space with a SDO CDISC that focused on, actually created the first standards use for representing clinical research data from clinical studies and submitting them to the FDA. I’ve been with HL7 now for just over three years. HL7, actually I was planning to semi-retire from CDISC but HL7 called me at the time, that old friend who was there and he said, you know, I said, yeah, I’m not really sure I wanna keep working full-time, he says, now come on down and talk to us, there’s something here I want you to see and he was referring to FHIR and yeah. To the first, my first FHIR connectathon and there was such a buzz of energy that it completely just captivated me and so, I’m back working again and it’s…

Dave: Well, that’s a great story and you know, obviously you bring decades of experience to this. We’re gonna get deeper into the discussion about FHIR in a few minutes and so I expect we’ll hear then what it was you saw that so animated you. You know, there’s a parallel to my own story here. I was first exposed to the idea of API based integration while serving as Chief Medical Information Officer at Cleveland Clinic and like you it sounds like in some ways not just a career-changing but a life-changing experience. I’ve been in this mad pursuit now for almost five years as well. So, let’s start talking abut APIs and I’m gonna ask you a series of four question and we’ll take about four minutes for each but let’s start with really the basics Wayne. In your own words, what is an API?

Wayne: Yeah so, you’ve been talking to a lot of people about this and so I’m sure people have a good impression but it stands for Application Programming Interface and it’s kind of a way that allows systems to talk to each other without having to actually get into the details or with you getting in within the system. It’s sort of like opens a portal or a way to communicate between one system and another. APIs are ubiquitous in the internet world that we are all comfortable with today. One analogy I often use is when you wanna book a plane ticket online, you go to your favorite site, maybe it’s an airline site, maybe it’s Expedia or one of Kayak or one of the group sites and when you go into that site and is looking for a flight between two places at a certain time, you’re gonna get a listing of all kinds of different airlines and flight options and that’s not being done by building direct, not everyone moves all their data between one database and another. Essentially, what you are doing is tapping into the API for each of the airline providers and they are telling you here’s what we got and putting it all together and presenting that to the end user who just wants to book a ticket. So, that’s what APIs are able to do. We access them on pretty much everything we are doing it with our pad and phone apps, with browsers when we go to Twitter or we go to a content site that might be having links to a Twitter tweet somewhere, that’s being done through the Twitter API and you know, you don’t actually invoking Twitter and log into Twitter and doing those things, it’s just pulling in the relevant information. When we are on Yelp and looking on restaurants, if we want to have some food shipped to us, you know, you’re tapping into the Uber, Uber Eats function which is basically just connecting through an API and saying, hey, is there somebody around to pick up my food and deliver it. So, APIs really are a way to capture the capabilities of the internet, putting information where you need it to be in a very easy way that just integrates with the user interfaces that we’re very comfortable with, that we’re working using with Computer these days.

Dave: Well, that’s a really terrific description and I appreciate that you avoided a lot of technical jargon. I’m sure you could probably give us this very formal definition but what you’ve described is something I summarized as it’s a technology that lets applications connect, exchange data and collaborate.

Wayne: Yeah.

Dave: And, the other thing that’s come out in these discussions that I think is very interesting is inside application design, this migration from monolithic designs to more of a service-oriented architecture. So, it actually mirrors kind of internally what APIs exposed by web services led us to over the internet as well.

Wayne: Right and I have you know, a long history as a CIO and in the old technology world, the only way to do this was to buy an expensive application that sat on a database, that stall at, support that darn thing and then you build interfaces between each thing that talk to each other and you’d build these sort of point-to-point communication bridges and it was enormously awful time-consuming horrible thing that had to be done in order to bring information together but the beauty of an API is that once it’s supported by each technology, you can have lots of way of different things can interconnect and to talk to each other and so that’s why they are so important in today’s world.

Dave: Well, I want you to elaborate further on that because as we’ve clearly heard during this series, APIs are not new, they’ve transformed the rest of the digital economy, they are just new to healthcare. So, could you elaborate further on both the benefits and the challenges that you see when it comes to using APIs in healthcare?

Wayne: Yeah, I think with healthcare because of its complexity and because of some of the challenges of just being able to ensure privacy and security and the rules against that for violations of that, people tend to be very, very you know, uncomfortable about making healthcare data accessible and so it needs significant controls in place and so APIs actually helped in a number of ways. Here’s where the standards picture comes in. There are a lot of different, for example, let’s start with the electronic health record which are you know, the systems that we have in all of our healthcare providers for the most part and EHR systems there if we were just at him. So, it just a week or so ago and you know, there were hundreds and hundreds of providers all of which had developed their own systems and all of their systems had their proprietary technologies and proprietary databases and it is absolutely possible for them to establish an API as here’s how you can talk to my database by putting together, by having an application calling but the problem is that each one is going to be individualized for that particular technology. Now coming from the HL7 world, a lot of people think of HL7 as our original flagship standard version two and version two exists all throughout the world of healthcare. It’s kind of like the plumbing. It’s like you know, when you’re at the physician, he ordered some labs, he’s sending a v2 message downs in the laboratory and he’s gonna get his results back in another v2 message and these things are flowing back and forth. Billions of these message transactions happen a year, each day within the healthcare industry but these messages were all sort of put together and sort of again, point-to-point communications that were set up within environments for the most part. What they did not really deal with was interoperability being that a message that had was sent in one particular doctor’s office to one particular hospital or lab would be exactly the same message that went to everybody else and so they always had to be tweaked and customized which was a significant burden but once things got them just right, they leave them alone [Laughing] and we keep them going, you know. We don’t wanna break what works because there is such a tremendous volume. Now when we talk about APIs, you know, Epic, Cerner, all the major EHRs had their own APIs they put in place in their own app stores but where standards come in is having a single API that any app would be able to access for any EHR, no matter what their internal technology and database is. What the API does is opens up a view of the information of the data that’s available an gives you the mechanisms, the rules, the procedures that allow you to reach in, get what you want and put something back without having to directly install that application and without having to modify it when you’re talking between two different systems. The benefits to the world of healthcare are so significant because it’s rare that people basically have the same provider who use the same system throughout their entire life, much less their parents that they may be responsible for caring for, their children and so what is important is to be able to get all that information you need in a fairly simple way so that you have it when you really need it. In terms of the HL7 vision which you articulated earlier, which I love you know, the world where you could securely access the right health information when and where you need it. Think about the possibility if you’re travelling in your, you know, in an automobile accident and you know, you want it to be delivered to care, you want your doctors to know everything about you know, they need to do. When you have an elderly parent who may need to have emergency care, you want those physicians to know what medications around without having to be there and watch it. In our healthcare system, we have a severe problem that people die due to medical errors often because of the lack of access of the right information. That’s a really serious problem that we really have to solve in today’s world and APIs I view are really the key technology to make this possible. It’s really starting to become tangible now and it’s really exciting.

Dave: Boy, that was a tour de force both of the history of traditional point-to-point interfaces which I agree. They’ve bought great value but they’re difficult to build and maintain they tend to be brittle. I think of them as almost artisanal work. You need highly skilled craftspeople to build and maintain them and those folks are tremendous but it does limit capacity. I grew up in a construction home and to me it’s a little bit like the difference between stick construction where you all the two-by-fours are delivered and you build that, you stick the plumbing and everything else versus prefab where they just show up and they drop the foundation in the ground and you’re off and running. There’s something of an analogy there. Your comment about the role of standards and all of that, I think it’s all just really spot-on. I want to go deeper into this for a minute but for our listeners if you just joined us, you’re listening to 4 x 4 Health. We’re talking about APIs for healthcare with Wayne Kubick, Chief Technology Officer for HL7. So, the way you’ve started to talk about FHIR a little bit, I want to go really deep here with you and let’s start with the basics. What does FHIR stand for and then tell us why this is important and we’ll work our way into current status and what the future looks like. So, take us on a little tour of FHIR and explain it like we were five years old.

Wayne: [Laugh], alright. Well, let’s start with the name. FHIR stands for fast healthcare, interoperability, resources. So, it’s a wonderful name which had the benefit of being a homonym with the source of all kinds of crazy puns which I contributed to some of its…

Dave: By the way Wayne, we do have a rule on 4 x 4 Health, we don’t make FHIR puns.

Wayne: I’ll talk you later and send you a link to a website, it’s good for a long laugh.

Dave: I’ll put that up on the episode website by the way.

Wayne: So, let’s start with the second layer which is healthcare and so what FHIR is, essentially was a means of being able to build APIs that are all around the world of healthcare. So, fast means that you know, it was designed using a technology, restful technologies that allow apps applications to be built very quickly, things that would take months or years to do in a traditional database client-server environment. People can put together very, very quickly in days, weeks and put them out there and this is one of the thigs about APIs that’s different from the old world. They basically unleash innovation, they basically energize startups that go out there and look for little gaps and niches which have been ignored  by the big players but which are really important to particular end-users, it’s that long-tail analogy of being able to have this hive of activity with that’s making so many different creative ideas and so that’s part of the fast piece. Around the world of healthcare interoperability what we are trying to achieve with the APIs make it possible for any two systems to communicate and understand the information that they are sending between each other and receiving. So, that it’s not just moving, you know, bits back and forth, it’s actually moving information that can be understood and used and resources are the fundamental building blocks that are basically used by FHIR. A resource is when you type a web address, you’re basically pointing it to an address for an URI, a resource. In the web world, we think of that as a web page, page full of information. In the FHIR world, we can think of a resource as being a set of related information. There is a resource description for a patient, there is a resource description provider, there is a resource description for a medication statement, that’s taken, I am taking this medication and there are about a hundred, over a hundred resources uniquely defined within the FHIR technology platform. We’re referring to FHIR as a technology platform being that it’s more than just a way to represent information and actually tells you how to apply different technologies to actually build applications and we also think of it as a data model. There are resource descriptions for each of these unique building blocks I mentioned that sort of you know, a patient description will tell you basic things like, what’s the gender of the patient and what’s their date of birth and you know, where can they be found and the contact information and thigs like that. So, let’s get these, it’s a data model that tells you not just what these resources are but how to represent them in a standard way. It gives you the capabilities to connect with controlled terminologies or external vocabularies. In the world of healthcare we use SNOMED a great deal, we use RxNorm to represent the names of drugs for prescriptions and so it tells you how to bring these pieces in and it tells you how to apply the standard for specific business problems that occur within the world of healthcare. What data do I need to give a patient after a visit, what data do I need to exchange between a lab and a hospital. So, the first piece of FHIR is the technology platform based on rest. The second piece is the information model and the third big pillar of FHIR is really in Graham Grieve who’s the father of FHIR and the one who came up with all this would say, this is probably the most important piece, it’s community and what we talk abut FHIR, we talk about an active community of people who all buy into this vision and this goal and are freely transparently sharing information to help everyone succeed. It’s a very non-competitive environment where you have people who on the, on one side might be working for competing organizations for the same patients, for the same as sales. Within the world of FHIR they are basically on the same level of being hey, you know, we’re on a crusade here, we need to do what we can and we help each other out to make the specification better because ultimately people are always thinking about how does this apply to our own lives, you know, we are all patients or we will be patients. We have elderly parents and we have children and we want to make this life better for then and so that community piece is so very important adapting what the power of FHIR is for specific business areas. Let me mention a couple of communities since I’m on that topic.

Dave: Before you do, let me just comment on that piece because this is a topic I think of great interest and some listeners may be confused by this and say, well, wait a minute, you started by talking about competition and innovation and then about this kind of kumbaya thing and people sitting in a room together.

Wayne: Yeah.

Dave: And, the reality is they fit together beautifully. The term would be coopetition and what I see this as is this group is essentially creating the playing field for sensible and productive competition and we’ve seen this pattern in other industries whether it’s figuring out how cellphones can communicate across different providers or your ATM information can follow you, so it actually makes perfect sense. So, we’re creating a better playing field through this standard application of API technology and then let’s let everybody compete, that’s gonna drive the kind of innovation you’ve talked about and create a kind of technical and strategic agility and forgive me, I know I’m on the soapbox but this is what animates me Wayne, this is why I was drawn to this technology and I share your vision that it’s not only fixing some existing problems, this is creating a platform for innovation that could be just transformational for healthcare once we get the major pieces in place. So now, this is your moment to reel me back yet, let me know if I’m going through flaw but…

Wayne: I love what you said, yeah. We’re definitely out there. This is exactly why we’re doing this stuff and you know, this is what captivated me that first time I went to my first FHIR connectathon…, it should be.

Dave: So, let me press you a little bit on a couple of the details here. So, first of all, my understanding of this is you know, and I know I’m oversimplifying a little bit but essentially it’s taking API technology, restful APIs and applying that to healthcare in a way that’s gonna promote adoption of standards and remove unnecessary variation and if you’ll accept my day of definition fair, one of the challenges that immediately comes to mind in a situation like this is well, how do you reach consensus about what the standards should be and once you’ve reached consensus how do you enforce that, how do you get people to actually adopt and use it as defy.

Wayne: Yeah, of course and really good questions and that’s where we get into Standards Development Organizations. So, Standards Development Organizations explicitly exist in order to address this problem. We wouldn’t have the World Wide Web without the World Wide Web Consortium which basically determined that you’re gonna use HTTP over TCP/IP and you know, you’re gonna use XML within that. They’re the ones that these technical standards that basically allow all the information towards who transfer over the internet making the World Wide Web possible. So, within a Standards Development Organization what you have is you have people coming together who crate a specification and the part of the collaboration is getting the right people involved in creating the specification and the second part of the process is having a formal vetting process that allows the broader community to simplistically put their two cents in and so, you create a standard within the HL7 world, we provide a ballot that’s out there, that allows the rest of the world to comment on it, we respond to that ballot and we publish another version. Now, historically, this was done pretty much from a top-down approach which was how V2 was created and later our Version 3 standard which has gone somewhat unless you’re used these days but the idea was figuring out what you want to do presenting it and then turning it over to the developers. One of the things that FHIR did that was truly innovative was flipped the entire model around. Let’s sketch something out, then let’s get the developers together to try it out and make it work and this is where you get the competing partners together, the various different stakeholders together, you get people from hospitals, you get people for EHR vendors, you get clinicians and users looking at the data, you put the all together in a room and you try stuff out and you refine it and you go through a series of step wise improvements until you get something that’s pretty solid and stable, that’s been widely tested in multiple environments. In fact, FHIR requires it to be tested and applied in production on a global scale before we will actually submit that content to the American National Standards Institute in order to be recognized as a normative controlled standard which means we don’t plan the changes and so this whole process is what SDOs do but what FHIR did was with innovatively was let’s make sure it works and can be used and solves a problem before we make it a standard rather than historically let’s make it a standard and then see what people can do with it.

Dave: There’s an interesting philosophical mirroring here too that this approach of sort of agile development evolution of the standards, to me is sort of a pleasing symmetry with and when the finished product is done, it creates the circumstances for agile development of applications as well.

Wayne: There you go, absolutely.

Dave: So now, let’s talk about enforcement and adoption because as I understand it one of the challenges with standards is, we can publish the standard and the specifications but then if folks follow it, it’s great but if they don’t then that can create a whole new set of challenges. So, what’s your view on that and how do you see that playing out with FHIR specifically?

Wayne: Sure. So, there are multiple different paths to achieving that. Part of it happens in the, well, let’s take the project Argonaut is a very visible collaboration that was put in place to define what are the core components of the API that will be used to make data accessible to patients on apps and this is the actual API that the proposed rule from the Office of National Coordinator is dealing with and back around 2015, during these meaningful use too, one of the ONC had already dictated that you know, all providers need to provide a CCDA, a clinical document that basically told patients kind of what the record of their visit is or the record of all the information, some of the information they have in their EHR and they dictated this and it was implemented at various different, all the EHRs had to do it to conform with the meaningful use guidelines but there were lot of variations in that. When FHIR came out and the potential for APIs was first understood, the industry actually asked ONC, don’t regulate and tell us what to do, let us figure out how to do it ourselves first in a consistent way and then regulate it. This led to the creation of project Argonaut which has close to a hundred participants. Many EHRs, many large hospitals and manty other organizations that got involved and basically said, let’s try to agree on how we’re going to apply FHIR for this specific use and that we will all commit to doing it the same way. So, this is kind of a soft compliance being that they said they are gonna do it, they’re gonna try to do it but you know, it may not be totally exacting, neither some of the challenges we had with the different EHR vendors was making sure that they mapped from their internal database correctly to the specification of variables that the FHIR was presenting. So, that takes to the next stage which is where you do get Government involved and where Government involved this tells you, you must do this and then secondly, put in place controls that will certify to make sure you’re doing it at least at some common level and so we’re seeing that again with the proposed rule, the plans from ONC and CMS as well, moving forward saying that we want everyone to use not just an API but the FHIR APIs according to specific specifications and we’re gonna put in place certification tests basically measure whether or not you’re actually using it correctly. So, it’s a tough thing, it takes a while to get there. We haven’t put the certification pieces in place yet for these FHIR APIs, there’s a little time as the rule goes through it’s, it’s changing us but you know, this is gonna happen very, very soon because it’s so important and so that’s how you basically get there but it starts with the standard, it secondly gets the consensus that is buy-in from the communities involved and then thirdly, there is the stick which is to make sure that you get Government involved.

Dave: Yeah, I think that’s a really good description and I would add a forth which is, it works. So, if it solves a real problem, people will adapt it and use it, you know.

Wayne: That’s a really key point and that’s also another one of the reasons for FHIR’s success is that once people tried it and saw what it could do and people coming out of college, they don’t want to be writing mumps code or VT, [Laughing]. Even if they say, no I mean, they want to be you know, they’re developing apps you know, and this is part of that innovation but it’s what people want to do and when they found how much easier is work with these newer technologies that the rest of the world’s been using for a while, the get really excited. You know, really…

Dave: Yeah.

Wayne: It’s the thought process of what can be done.

Dave: Actually this is the tip of a much bigger iceberg, so let’s go there for just a second. What I saw and really animated my interest in this was ginormous integration teams at health systems and these backlogs of projects because of the difficulty on cost of traditional integration. I saw really innovative digital health companies with cool ideas run into the brick wall of integration, particularly clinical integration for EHRs and they would subsequently have these integration teams as big as the core product team and these to me are all symptoms of the kind of innovation constipation that you and I have been talking about and the way you describe it, I think is perfectly which is the API model allows us to kind of coordinate off, isolate it, standardize it and let these companies and these health systems get back to focusing on the cool and important stuff they set out to do in the first place. Like, yeah, please real me back yet if I’m over the top, that’s how I see it.

Wayne: You’re directly on target and again, that’s where the competition should occur you know, not in terms of how they represent data but basically how they produce products that solve business problems and how they are able to support them and distribute them you know, and let’s take that information out of that. We want the same information to be coming, no matter who’s doing what.

Dave: That’s exactly right and as you said earlier, this is about patient lives which is a top most concern. I would add it’s also about provider productivity and satisfaction and overall efficiency of the health system.

Wayne: Oh yeah!

Dave: So, let me take you to one more area related to FHIR and you know, as we’ve talked about there’s some obvious benefits to having standards that there are some challenges what we can manage through those. What is your view of the role of custom and proprietary APIs in the world of healthcare?

Wayne: Right, well, I think they were necessary to basically give people an idea of what you can do by getting third party apps access to information but I think they don’t make a lot of sense moving forward. Certainly as FHIR when it was a news standard and was you know, under the trial use banner where it was being first tried out, there were a lot of skeptics out there who said, well, we’ll wait to see when it’s, you know, stabilizes and studies out but the point is, is once you have an API that is so broadly accepted and understood and works, why would you do anything else. You have access to all the knowledge in an open source transparent way, there are so many resources in the small our sense out there that people can you know, access without any charge. They can learn, it’s intuitive, it’s something that reaches you, why would you do that. There’s really no advantage and really some companies might say, oh, we’re holding on to our customers but that’s a sureFHIR way to lose your customers. If you can access any information from any source related to healthcare except this one, what do you think that’s gonna do to that business?

Dave: Right. Well, this is a place where you and I might gently disagree a little bit. Where I would agree with you completely is that where there’s a proven standard and it works, you should use it. I mean, there’s, it’s hard to come up with an argument against that. I actually take a both end view to this and I see it as part of the way of advancing the technology as well as medical science and so what I would argue is that, there’s a place for both and I actually think of it as a kind of yin and yang. So, bear with me for a minute. I think creating the space for customer proprietary solutions is a way of working at the bleeding edge of advancing in areas where we need to advance more rapidly while we wait for the consensus to emerge and I think it maybe useful information that feeds in to the selection of topics for standard development and the actual details of those. In other words, it could be data that’s useful to groups that are working on standards. The corollary to that is as I said, I think when a standard like a FHIR resource emerges and it’s hardened and it’s you know, proven to work then those who work in the proprietary accustomed areas should look hard at how they can adopt and migrate to that because as you say, that’s gonna be more widely acceptable and it becomes harder to justify an one-off or a custom approach. So, I don’t know if I’ve persuaded you at all but it’s a good debate to have and again, what my argument would be, this is such an important problem, we need to move as fast as we can to knock down interoperability barriers and I think there’s a place for those who wanna get out on the bleeding edge and do experiments and do things that are not contrary to the standard but just in areas where the standard hasn’t emerged yet and that hopefully those two processes can benefit each other. I’m not asking you to enforce it Wayne, I’m just asking if it makes any sense at all.

Wayne: It makes perfect sense and I don’t really think we’re disagreeing here at all because when you talk in terms of proprietary solutions, first of all I think historically, that was your only choice and secondly, I think that’s exactly how the bounds and the capabilities of FHIR can expand. I think what we encourage people to do is use the FHIR technology stack to build those proprietary solutions. In fact, as FHIR is evolving, it’s happening precisely through different organizations that solve particular problems in special ways and then they bring it into the community and then the community looks ahead saying, well, how can we add this to the core specification over time. So, this is how the things like, they are really fascinating CDS Hooks technology came about. CDS Hooks is a FHIR based technology that can sit within an EHR and sort of be an event monitor and when it sees something happen at some triggering event, it can invoke a message such as, don’t prescribe this expensive drug, there’s a cheaper generic that’s available. It can invoke an external app, it can invoke Uber to take the patient home, t can alert someone that you know, a medical error, it could be happening if you proceed with the next step doing here and this is something that came from the outside but was absorbed within the community. Another great example is the smart on FHIR technology in the Boston Children’s Hospital originally invented which is the fundamental way for connecting to APIs using Facebook or Google. You Google ID, you can gain a quick access without having to have a separate set of credentials for every system and so you know we absolutely feel people should be trying things out where possible use the FHIR platform and help make that stronger but then you know, to bring ideas back in that can expand you know, to improve the health offerings we can make to the world.

Dave: Those are really terrific ideas and Wayne, I would add, I think it’s a nice window into your own thinking and leadership style, so good on you man.  We’re gonna round out this conversation and I wanna wrap up by have it you offer us your most sage advice when it comes to APIs.

Wayne: Yeah so, I did actually write some things down on this one. [Laughing]. Then we go through this a little bit. The first things is like, people need to open up their minds. I think FHIR is the best opportunity we’ve ever had in healthcare really to do something and make really move the needle quickly and so you know, to be creative, be innovative but you know, take a look at it. Secondly, be sociable, join the community. The way that we’re going to make this actually lick those greater problems is really to get everyone involved back to Metcalfe’s law. You know, the value of a network is you know, directly proportional to the square of the number of users. That’s the story of FHIR. It has grown from a handful of people to hundreds to thousands around the world and really everyone who’s working with healthcare technology and healthcare information really ought to be becoming part of the FHIR community, plug in, listen, talk or at least look. You know, get involved there and we do weed people to participate within the HL7 community and the FHIR community as well and the last piece of sage advice is that I get excited and when I talk about this stuff and patience is the last piece because you know, I mean, FHIR has moved so much quicker than anything else but guess what, it takes time, it takes time. Things do come up, not everything has been solved by any means. There’s a massive amount of capabilities that are described within the FHIR resource definitions. Some of them are very raw and immature and haven’t really been tried out very hard. Many things we haven’t thought of yet within the FHIR community and people are bringing things in. Not everything is solid and stable yet. We’ve got that stable core, which is mostly the infrastructure components, we have the patient resource, we have the observation resource. Our next release of FHIR, we want to be able to get you know, pretty, all the rest of the basic data elements defined and ONCs, US core data for interoperability. We want to get more and more data, we want to bring imaging data, we want to bring genomics data, these things are being explored and worked on within FHIR but it could take a while to get there and so the apps will take a while to stabilize, the APIs will take a while to stabilize, the consistency will be there but the good news is we are really on a great path here and we’re gonna get there, really all we lack is the support and commitment, you know, for others to help us get there faster.

Dave: I share your enthusiasm about the stage there that we’re at and I’m excited about the potential. I gotta say, your advice about be an open minded, collaborative and patient is not just good advice for APIs, it’s good advice for working in healthcare in general. There I say, it’s a good advice for navigating life in general. So, definitely very sage and I think with broad applicability. So, thank you for that.

Wayne: No, thank you. It’s been a lot of fun. I really enjoyed it.

Dave: Thanks Wayne. We’ve been talking APIs with Wayne Kubick, Chief Technology Officer, HL7. Wayne again, thanks so much for joining us today. 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.