API 101 – The Role of Standards and Coalitions

In this episode of 4x4 Health, we return to our API 101 Series for a conversation with Micky Tripathi, PhD. As the President and CEO of the Massachusetts eHealth Collaborative and the project leader of the Argonaut Project, Micky is truly a leader in healthcare interoperability. Throughout the discussion, Micky talks about the critical need for innovation in how healthcare applications talk to one another and, through his position at the Argonaut Project, why he sees APIs as the solution Health IT has been looking for. Micky is one of the most important voices in healthcare interoperability and we hope you learn as much from this conversation as we did!

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 Programming 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 the to transform healthcare. Today I’m talking with Micky Tripathi, President and CEO of the Massachusetts eHealth Collaborative. Micky has acquired rich experience in EHRs and Health Information Exchange during his nearly fifteen years of leadership at the Massachusetts eHealth Collaborative. This is a non-profit collaboration of thirty four leading Massachusetts organizations. Among other things, this collaborative provides strategic direction and overall project management to the Argonaut Project which was formed to create a first generation FHIR-based API and core data services specification to enable expanded information sharing for electronic health records. These topics will be part of our focus today and expect we’ll hear more about them later in the discussion. Welcome to 4 x 4 Health, Micky.

Micky Tripathi, PhD: Hi Dave, thank you, delighted to be here.

Dave: Micky, before we get into the API discussion, let’s start with our usual opening question. Take a minute or two and tell us about yourself and your organization.

Micky: Okay, sure. Yeah, as you know that I, I’m the CEO of the Massachusetts eHealth Collaborative, basically a non-profit professional services and technology services company. We provide consulting support to healthcare stakeholders related to any issues on Health IT, whether it’s electronic health record systems, health information exchange, data analytics and we also have a technology services platform which is a clinical quality data warehouse where we provide clinical quality measures, data extracts, data normalization to a wide variety of customers both in Massachusetts as well as across the country.

Dave: Well Micky, it’s pretty obvious form that and from your fifteen plus years in this area. You’ve got deep knowledge about healthcare data and about the exchange and sharing of data for clinical care and other purposes. So, let’s get right into this and what I wanna do now is ask you a series of four questions about APIs and we’ll take about four minutes to discuss each one. So, let’s start with the basics. In your own words, what is an API?

Micky: Okay, sure, yeah. I’m not a Computer scientist, so definitely on my own words.

Dave: Good, that’s good.

Micky: I mean, an API is basically a method for web-based software systems to interact with each other and you know, I sort of think of it as by you know, both the combination of kind of programming instructions and standards that allow multiple types of interactions whether it’s being able to write or read or update or delete, it enables those systems to interact with each other without knowing the basics of how each of those systems operates that more of a basic level in terms of their own functions, so it allows you to do that kind of interaction.

Dave: And, this is sort of the theme we’ve heard as different folks volunteer their definition. I heard really two things in there. One is this idea of hiding complexity. So, applications can collaborate without having to know our master, if you will the dirty details under the hood and then the second is this idea of collaboration that it makes it easier for applications to connect and collaborate to provide solutions.

Micky: Absolutely, it’s almost like an introduction in a contract about a set of things you’re gonna do together.

Dave: Yeah, and I mean this is obviously an area that’s been of great interest to you personally and to the work of the eHealth Collaborative. Why is that, what was it that sent you in this direction?

Micky: I think it started with the pain that we’ve experienced over the years in doing it, you know, doing it every other way, right. So, our organization, we were founded in 2005 and with an initial funding from Blue Cross Blue Shields of Massachusetts who funded us with 50 Million Dollars to do a large scale Health IT experiment, community based Health IT experiment here in Massachusetts. So, we chose three markets, Brockton, Newberry Port and North Adams with six hundred physicians and we outfitted the physicians with electronic health record systems and stood up three health information exchanges and then created a data warehouse on top of all of that and the experience back then, you’ll remember what it was like in you know, 2005 and you were, you know, hand building, you know, non-standard HL7 V2 interfaces to get whatever we could out of these systems and it was incredibly painful experience and it was across disparate EHR systems. So, anything that would standardize that as much as possible, abstract us away from the complexity of the underlying systems as you kind of described before and that would enable a richer set of interactions to be able to do more than just pushing data one way, you know, where all things that we were interested in from the beginning. So, that’s what got us interested in APIs in general as the market started to move that way and it certainly you know, in healthcare is that we’ve experienced, you know, we’re kind of the last sector to fully embrace the internet as it were, as it were so, you know, all of us have this experience when you sort of see what you can do at home depot and you know, in other places and ask yourselves, why am I, you know, I have all these HL7 V2 Engineers, you know, doing it this way here in my office, that certainly was a pressure point as well.

Dave: Well, you make a really good point which is APIs are not new, they have been a key component of transforming the rest of the digital economy and dare I say the way we live our lives day-to-day, they’re just new to healthcare and the other you said that thing is important is we’ve had integration technology for decades now. I think of it as this artisanal work. It’s, it requires, you know, highly skilled craftspeople to build and maintain them and that’s proven to be a challenge in terms of cost and scalability and other issues, and we’ve heard these themes in some of the other episodes. You have a unique view because you’ve worked in industry, but you also work closely with health systems, other vendors, HIEs and the like. So, I’m particularly interested in what you’ve seen in terms of the benefits and challenges of using APIs in healthcare. What’s the good and the bad here Micky?

Micky: Yeah, I don’t think there are many bads. I mean, we can come back to that, we’ll come back to that in a second except that they’re new and new means that it’s going to be change required and in an industry as fragmented as healthcare both in the supply side and the demand side that just means that it’s gonna take time for us to be able to, you know, sort of do that kind of full you know, tide that lifts everyone that we’d love an API based world to be able to do but in terms of the benefits, in general just allowing systems to do more than just pushing data back and forth in you know, one way kinds of transactions, that to me is at the heart of what’s a benefit there. In the ability to do that in a scalable way where I don’t have to be figuring out every piece of it you know, security, transport, format, semantics, you know, all of that which is what we are literally having to do figuring out every single layer and it was unique in every single case and I think allowing that iterative back-and-forth for more complex transactions opens up new avenues and new possibilities that didn’t exist before with you know, with the kind of one way interaction patterns that we had and I think going forward in the case if we’re gonna be specifically now about Restful APIs, so sort of narrow down the API in general to talk about Restful APIs, you know, that just aligns us with the rest of the internet economy and I think that just has a number of benefits. One is, you start to get richer experiences examples from other places that give you the opportunities for thinking about richer experiences because you have more functionality that you can work with, right. So, you can start to say, gee, I’d love you know, the way OpenTable works, I can now start to think about that in healthcare, right and the way that other kinds of patters work, the way the Canoe or Hayek works, Canoe, [Laugh], that’s kind of awkward or the way that other, you know, that other kinds of businesses that are formed in other areas, you’re able to take that as an example and say, there is a direct analogy in here that we haven’t been able to use before or implement before because we didn’t have that foundational way of interacting. Also it brings in people from other industries which is huge, right and if we’ve learned nothing else from being able to you know, what technology has allowed us to open up in a way of information systems, it’s the crowdsourcing always as a tremendous amount of benefit that’s always hard to anticipate what type of benefit, how far reaching that can be when you just start to have more people focusing on the problem and at least but you know, our experience as a company that has always been hiring people over a decade is that when you put on the table and implementation guide based on you know, sort on an IHE stock, no disrespect there but the standard that was developed in the late 1980s and it’s a thousand pages and expect you know, a new grad from Stanford or MIT to dig into that, there’s not a huge a lot of appeal for that but you know, but when you give them an implementation guide that’s based on basic Restful API internet conventions that they can understand right away and have something up and running in a week that starts to get a lot of appeal from other vertices and other parts of the internet economy and I think we are starting to see that, right. Now we’re starting to see that you’re getting more eyeballs on this which is just huge benefit I think, you know, we’re gonna see the benefits of that three, four, five years from now in ways that we probably can’t appreciate right now.

Dave: This is a theme here that I personally am fascinated by and very excited by. I want to do a quick head nod to some technical jargon you threw out which is Restful API and for our listeners I would simply say, this is a set of specifications about designing a particular type of API, how it should behave, how it should interact with the rest of the world. We don’t really need to go deeper on that. The more important point that you’re making here I think goes to agility, diversity and the role that these can play in enhancing innovation in healthcare, both the breadth of innovation but also the pace of it and you hit on some things that I think are really important. So, the technical approach which itself is more agile. It makes the development of the API and the development of applications that used on simpler or more agile, it’s easier to iterate and learn from experiments and improve more quickly. That to me also translates into a kind of strategic agility because so much of what we are trying to fix in healthcare is enabled by Health IT. I wanna be clear Health IT is not the whole answer but it’s often a critical piece of the puzzle, often a rate limiting step and so things that allow me to push the tech faster to evolve it to experiment, to bring in people from outside healthcare, to leverage other services, to me this is all kind of brewing up, this perfect storm, a much more agile and responsive Health IT infrastructure. As I often ask my guest Micky, reel me in if I’m over the tip here but that’s why I get so excited about this.

Micky: Yeah, no, I think you are absolutely right because on the one hand it’s juts a standard, right and we’ve seen, oh, here’s the new standard, it’s gonna be the magic bullet that solves everything, right and we know that that’s not the case. On the other hand to the extent that it starts to open things up to different ways that one can interact and that organizations can interact and it opens the thigs up in a way that brings more people in to start being innovative or at the edges. I think that there is just a world of possibility here that then opened up that again, it doesn’t mean that all the other problems that we’ve had with respect to interoperability and the challenges on other dimensions go away but it opens up more opportunities and it makes some of those a little bit easier to deal with.

Dave: Yeah, and I think that last point is important. I mean, pretty much everything comes down to people process and technology and in the case of interoperability and data sharing it’s certainly true. I feel like the API technology goes a long way towards reducing the technical barriers, it also tends to throw up a pretty harsh light on some of the other challenges that we are wrestling with. We’ll save those for another podcast though. If you’ve just joined us, you’re listening to 4 x 4 Health and we’re talking about APIs for healthcare with Micky Tripathi, President and CEO of the Massachusetts eHealth Collaborative. Micky, I want to take us deeper now into this subject of standards and the roles that organizations like Massey Health Collaborative or projects like, The Argonaut Project can play and so if you would, take a minute and share with us your views on standards in general and about specifically around FHIR, the API standard and the core data services. Why are these things important Micky?

Micky: Sure. So, standards in general are you know, just hugely important to all of us. It actually a great opportunity, I don’t know if you saw it, just last week it was in New York Times, it was called the joy of standards or something which is not usually something that people think of as being joyful and certainly when I was younger I never would have thought that I would be embracing standards or even thinking about standards but you know, and I’m sure you have this experience. I mean, once you get involved in it you start to see it all over the place. I mean, I was pumping gas into my car the other day and thinking, wow, there’s a really useful standard here, I never really appreciated that. I can pull up to any gas station and this nozzle actually fits right into my car…

Dave: That’s right. Hopefully it keeps you from putting Kerosene or Diesel where you shouldn’t also.

Micky: Right and I’ve had that experience too where I’d you know, accidentally pulled off the diesel thing and it was pretty clear right away that, oh, that’s actually, it won’t let me do that. There’s some amazing things that happened with standards. So, I mean, seems usually and I would say that in an industry like healthcare where again, as I noted before you’ve got incredible fragmentation on the supply side and the demand side, being able to have standards developed across the industry by Standards Development Organizations ends up becoming that much more important and the reason that is, is I think because as opposed to other industries where you tend to have concentration, industry concentration either on the supply side or the demand side, sometimes both, you know, you can have large companies, large organizations that make up a majority of the market that end up driving and creating a de facto standard that might even be a proprietary standard and there are lots of things that can be bad about that, it’s you know, monopoly, all of that but on the other hand you can get rapid standardization around something and that can help to, you know, give you the benefits of standardization. In a way that’s very difficult to achieve in healthcare on it’s own, right. There’s so much fragmentation on the provider side, on the vendor side, on the payer side across the country that there isn’t the Walmarts or the American Airlines with the Sabre system or whatever it is that can sort of say, we’re gonna make this sweeping change and the rest of the market is gonna follow in you know, certain keyways or if you think about you know, how Amazon and eBay and you know, PayPal have standardized a lot of payment processes. So, when we think about standards in healthcare, I think that’s where you start to see that you know, the collaboratively developed standards with SDOs like, HL7 end up becoming critically important because there’s no other way for us to you know, get agreement and then we can talk about some of the levers like the Federal Government’s and the new rules coming out start to play because again, with so much fragmentation who are the big guerillas who can drive the market in ways that a whole bunch of small players have a hard time getting together and agreeing on something that can help to drive the market.

Dave: Well, it’s true and probably like me you’re digesting the literally hundreds of pages of…

Micky: 749 pages, I think.

Dave: That’s a 724 for ONC and I can’t remember what it is for CMS, its comparable. My takeaway from this as a theme is leveling the playing field and creating the circumstances for more competition. The way we were talking about earlier and promoting the adoption and appropriate use of things like FHIR to as you said, address some of the fragmentation. We’ve spent a fair amount of time on this series talking about FHIR and APIs. Could you take a minute and enlighten us on core data services because I know that’s another critical piece of this but what is that and why is that important?

Micky: Yeah, you know, I think the notion of core data services which was in you know, sort of the Argonaut Project original charter, which is now you know, four or five years old. So, I’m not sure that we would specifically use that term today but the notion, but the idea behind that was the anticipation that there was going to be a requirement from the Federal Government related to an API specification for what was then called the common clinical data set. So, basically the idea that you know, whether it’s common clinical data set or you know, whatever else it is, the idea of core data services are as you know, in electronic health record system, there are literally thousands and thousands in any particular electronic health record instance that you could look at. There are literally thousands of types of data in there, right, in all different forms, formats, structures, everything under the Sun and particularly if you get into a large enterprise system at a you know, large Academic Medical Center. I mean, there’s just tens of thousands of data types in there and the idea was that if we’re just starting off with this Argonaut Project which was a collaboration of key vendors and provider organizations. If we’re just starting off, let’s try to focus on at least a core data set that all of us would agree that you know, so to follow a little bit of the 80-20 rule that for you know, most of the things that happened day-to-day in a clinician’s office that the set of data would satisfy that use case for most cases and if we can just come to an agreement on that, then we can build from that, right but we have to start someplace and if we say that we wanted to cover all ten thousand data types from day one, then of course we would never get anywhere. So, that was that notion and then we quickly sort of tied that immediately to the clinical data set which is defined by the Office of National Coordinator for the purposes of EHR certification related to the high-tech incentives, the meaningful use program but going back to one of the things that at least has occurred to me since I’ve been in healthcare is that every single pathology we have in healthcare, you can relate back to the fragmentation on spy side and the demand side. So, come back to that again and say, because we are so fragmented on the supply side and the demand side that the Federal Government role ends up becoming incredibly important because it’s the only entity that cuts across every market, smaller or large, rural or urban in a way that no other actor in the market can cut across. So, that’s how we said, alright, the common clinical data set is out there. We can see that the National Coordinators Office is gonna embrace this concept of APIs and so before they go out and do that, what we wanna do with the Argonaut Project is collaboratively develop from a market perspective and an implementer’s perspective and approach that is going to meet that need for a common clinical data set oriented API but that does it with as much market input as possible, as early as possible. So, that they are not requiring something that hasn’t at least had a little bit of market and implementer experience because you know, we had that experience with the direct standard which for all the good intentions people had is still something that people are having a hard time implementing because it really didn’t come from the market, it came from you know, a group of implementations who got together and tried as hard as they could to make it work but you know, but if you don’t have enough of that feedback from the market, it becomes hard to adopt.

Dave: Right, it’s when theory meets reality and practical barriers. So, when there was a lot in there, I wanna see if I can parse this all. So, a couple of things. The first idea was eventually the Federal Government was gonna have to help us solve this because of fragmentation. The idea behind collaboratives and projects like Argonaut was well, let’s get out in front of that, let’s establish what we think the basic data set should be and an API approach like FHIR. Let’s do that with multiple stakeholders so that we get the appropriate mix of theory and practice and the need for something that’s commercially viable with something that will also promote competition. All of that eventually was informing the proposed rules that we’ve now seen and the last piece I would add is I look at CMS and ONC moving clearly in lockstep here is on the one side you’ve ONC say look, these are you know, the ways that you need to behave and the technologies you need to adopt and CMS is saying, do this if you want to get paid. That’s a pretty powerful combination, yeah, it’s in my experience. So, let me pause there. I mean, then I, at least do a reasonable job of summarizing all of this history and how it kind of fits together from where we stand now.

Micky: Yeah, no, that’s great. I was looking forward to hearing you, tell me what I said, oh, you did it much better. [Laughing]

Dave: But I don’t know about that.

Micky: No, I think that, I think you are absolutely right and you know, and I think one of the interesting things when you look at the history of FHIR was, it was a really short history, you know, as we know, it hasn’t been around that long. I actually did this for a project that we’re working on. One of the core concepts from the very beginning when Graham Grieve, you know, the George Washington, James Madison and Thomas Jefferson, all wrapped into one, of FHIR. Then I guess we should add a famous programmer or [unclear] or something. So, when Graham was first thinking of this idea, it was partly about a technical specification but he also you know, articulated very early on that we need to have an approach to standards and healthcare where the implementers have a larger voice earlier in the process. You can go back to his blog and see that in 2012, 2013 that he was you know, kind of saying that back then. It’s interesting now that we think of the Argonaut project for example and there have been successors now, you know, the DaVinci Project and work that the Karen Alliance is doing. There have been you know, sort of successor and I think we’re gonna see more of those with the newly inaugurated FHIR Accelerator Program that HL7 has launched but in a way when I think of the Argonaut Project, I reflect back on and think, well this is exactly what Graham Grieve was talking about. We’ve actually just instantiated it in a particular thing that’s now got a name but it was a part of vision early on was that implementers need to have a larger voice early on if adoption at the end of the day is our goal, not the creation of a pristine set of standards that are there for reference but that no one really uses in the way that we want them to.

Dave: Well, as a guy that believes culture pretty much rules the day in any situation, this resonates really deeply with me and it’s interesting you make this point because as part of the series, we talked with Wayne Kubick, the Chief Technology Officer of HL7 and he very explicitly made the same point. He talked about this idea of community that it’s not just about solving the technical problem, it’s the way you bring people together to do that. That’s vital both to getting a better solution but also in getting people to adopt and use it. So, I think we’re all aligned on this particular aspect of it. It always comes down to people process and technology. Micky, doesn’t, you just keep skip on.

Micky: Yeah, absolutely.

Dave: So…

Micky: The culture eats strategy every day of the week.

Dave: So, you reference Argonaut and some successors. Take a minute or two and tell us about that pedigree and what are you involved in right now or what do you see as some of the more interesting coalitions that you’re optimistic about right now?

Micky: Sure, absolutely. So, the Argonaut Project and what’s interesting about it is, I know many things interesting about it, I think but I’m biased obviously is it really has its origins back in the Jason Advisory Group, if you know remember that, that’s a scientific advisory panel that advises Federal Government. They issued a report that was given to the Office of National Coordinator that made strong recommendations about moving healthcare interoperability to an API based approach and that report Dr. Karen DeSalvo was the National Coordinator at the time. She set up a task force that drew from the HIT Policy Committee and the Standards Committee to standing federal advisory committees that I co-chaired from the policy committee side along with Dr. David McCauley from the Cerner on the Standards Committee side and it was not hot task force that was asked to look at the Jason report and provide recommendations and we delivered that report in the fall of 2014 and it basically was a recommendation to move forward with an API based approach and to use meaningful use stage-three as a lever to move the industry forward to an API based approach. So, that report that we presented got such a great reception at the Policy committee and the Standards Committee but the Argonaut Project was born literally like a week after that meeting. So, there’s a group of people who came out of that meeting and got together at a restraint. It was a Greek restraint in Washington and got together and said, this looks like it’s gonna happen and so we as an industry, as the private sector need to stand up and take responsibility at this point that we need to do things in the way that only the private sector can which is in a very agile nimble way, put some money on the table, hire a project manager, hire some you know, some developers and let’s just get going and lets you know, there’s a bunch of things we agree on here and let’s you know, let’s take some responsibility now as the private sector, move forward with interoperability. So, that’s how the Argonaut grew out, out of you know, multiple threads. One was you know, the Jason, there was a follow on with the Jason fast forward to and then the Argonauts…

Dave: Oh no!

Micky: And then also because they met in a Greek restraint that they thought, oh, this is all coming together and somehow the name Argonaut Project came out of that and they reached out to me, asked if I’d be willing to be the project manager. So, we’re off and running but it was that idea of saying you know, we just need a critical mass, we don’t need everyone, we don’t need every stakeholder represented, not that all the other stakeholders aren’t important but if we wait for that and if we wait for you know, sort of too much governance, we’re never gonna get started on this thing and we need desperately to have more private sector input into this conversation as we quickly as possible. So, that’s how we sort of said well, how about a coalition of the willing? We’ve got this group here, we’ll reach out to the others and you know, with the immediate yes or no question, are you in or out, just because you’re out now doesn’t mean you’re not in tomorrow, that’s okay. We’re just gonna go ahead and start doing this. Everything we do is gonna be available to the industry, everything that we do will be under an HL7 approach which means consensus, it means open standards, it means no one claiming intellectual property rights over our outputs and it means trying to push everything that we do in a way that’s going to strengthen the FHIR standard that HL7 is working on but try to accelerate it and give the process a little bit of a kick in the pants, so actually more than a little bit of kick in the pants. So, a good solid kick in the pants to say you got to move faster but you’re gonna be in our industry needs. So, that was really with the origins of the Argonaut Project in terms of what was really driving the folks who got together and said we need to take a different approach and so we started off with thinking about a specification of profile and a specification for the common clinical data set as we talked about before anticipating that you know, ONC was going to you know, have an API requirement and then after a year we even got that done and I think it was roughly 18 months and we published that and once we had done that we had a conversation about well, you know, we’re done now, right. This was really a code and implementation guide sprint, mission accomplished. We’ve turned that over to the industry, a lot of people are using that for their certification. You know, this is all great but we’re done and then you know, a number of the stakeholders around the table said, well, wait a minute, you know, we actually like the platform. This as a forum for us to take things that are at the point of maturity from a process perspective that they’re ready for technology enablement and what they really need is implementer feedback to iron out those wrinkles, to make them something that developers can pick up and run with, the platform is what’s valuable now. It’s not about that particular output that motivated us at beginning. So, that’s how we ended up being something that was an ongoing initiative rather than just sort of an one-off focused on that you know, first deliverable. So, at that point what we decided is that we would have a funding model where you know, where each of the sponsoring organizations puts in a certain amount of money every year and we have what we call you know, basically our core projects that we work on every year and so those can be anywhere in the range from two to four projects. At the beginning of every calendar year we decide, we’re going to work on and we have a couple of you know, a couple of criteria that we use to decide on projects. One is that it’s gotta be of importance to the industry and that can take a variety of forms of what importance to industry means but it’s gotta be something that is solving a problem that people want solved today and second is, it’s gotta be something that’s pretty much tractable within a roughly twelve month period. So, you know, there are lots of problems out there that we’re solving but as we know they might take two, three, four years in part because they are complex, maybe they’re not mature enough from a business process and process alignment perspective and a workflow level or an organization level like if it’s paid between payers and providers, if it’s you know, a part of a problem as well. There’s to much fragmentation on the payer side, so things like tire off aren’t even standardized across payers. So, how can you know, we are not gonna be able to solve tha problem. We can only solve the problem once we have some workflow alignment and agree on you know, sort of goals and the parameters of how the exchange and the business exchange is gonna work, then we can think about technology enablement. So, we basically said, you know, we’re only gonna take things that are mature enough from a modeling and workflow perspective that we think that we can actually get a technology enablement based on FHIR done in a year, so that an organization at the end of the 12 months can pick up an implementation guide and implement it and can implement it you know, when sure, there’ll be some you know, some wrinkles, additional wrinkles that will be discovered but they can have some confidence that it is ready for production. So, really those are kind of the two criteria that we use to you know, decide on which projects we’re gonna work on. So, we started that first year with the data query implementation guide which is a FHIR API that allows data level queries. So, item by item or data type by data type or it allows you to request the entire continuity of care document as a document. Today is that the core of the Apple implementation in iOS VSS 11.3 that enables you to upload your medical records onto your iPhone. That’s that implementation guide, the data query implementation guide and then since then we’ve done a number of implementation guides that are you know, available on our, on the website, everything from provider directories which is now the provider directory that’s used by Kara Quality, a FHIR based provider directory to a scheduling implementation guide for organizations involved in care management for example to be able to have the uniform way to be able to make scheduling requests to check for appoints, things like that and then this year we just decided on the projects that we’re going to be working on for this year and a number of them are a lot very much aligned with the ONC and CMS rules are looking at. So, the first is we’re going to be doing an update of the original data query implementation guide to the latest version of FHIR. So, that was based on SDU2 R2 not to get to round down in the Arcana of the FHIR versions but it was based on the version of FHIR that was available two years ago. Now, we’re at R4 and there’s an industry consensus I think that we need to move to that. So, we’re gonna upgrade that implementation guide to be aligned with that version of the standard. We’re going to work on a project on data provenance. So, data provenance is now a part of the USCDI as it’s called the core data set as a word, that’s defined by these, by these new rules and provenance for those who are familiar with that, it’s really important where we have more interoperability. So, what provenance means is, do I know where that piece of data came from originally, who actually know that and you think about the problem of more and more types of data hopping from record to record. At the end of the day for whatever reason, I may wanna know, well I know that lab result wasn’t one that I ordered, how did it get into my EHR, I may need to understand that at some point for whatever reason. So, provenance would allow the ability to tag those data elements or those records in a way that would allow me to know where it came from.

Dave: We’re on the cusp of the internet if things for healthcare. So, devices that are gonna be streaming more and more data, patients and their loved ones directly contributing. So, this issue of provenance and the metadata if you will is probably gonna be increasingly important overtime.

Micky: Yep, hugely important, I agree. The two others quickly that we’re gonna work on this year, one is again, not to get too much into the technical weeds of FHIR, but it’s called a subscription resource and the notion of subscriptions is a very easy to understand once you strip away that name. It’s basically enabling a push type of transaction versus a query. So, right now the way that we’ve, you know, the FHIR implementation guides and all of the requirements are basically to for a query for information. I am a primary care physician, I would like to query that specialist medical record for a medication or for an allergy or whatever it is and so as I request that information, I get it back, I do that be at my FHIR API. What about the other type of interaction pattern though, where you actually wanna push something, where we see that today with lab results or with ADT alerts, event notification systems where I’m not querying it, I’m actually pushing it. I’m at organization wants to push it someone else so the notion of a subscription resource is that I, let’s say as a primary care physician could subscribe to the discharge information that’s right now encapsulated in an HL7 admission discharge transfer message, I could subscribe to a hospital for a particular patient and say, here’s my list of patients who I care about, I wanna subscribe to get it having you pushed to me that information on that patient when that patient is discharged and when that patient has an event. So, that’s a you know, particular use case that obviously in the CMS rules, they make as a conditional participation that hospitals are required to provide event notifications to other providers involved in the care of the patient. They didn’t specify exactly how that happens, so this would be one way using a FHIR API  that one could create an ecosystem or an infrastructure that would allow that to happen.

Dave: Let me interject just for a second, this maybe a subtle but it’s an important point. It brings two important issues to the surface. The first is that and again, I’m not a technical guy but and my understanding is Restful API is typically the model is, it’s a query model. If I wanna know something, I have to go ask and so if I’m wondering about an event occurring in that model, basically I’m asking the question repeatedly overtime until the answer changes and that I know something has happened. This ability to subscribe and have an event pushed to you, it really complements that and the other reason I want it to drill it on this is it goes to this whole issue of cycle times in healthcare and you tied it directly to change the level and care. Well, we know from decades of experience that these are critical junctures in patient care. When you move from level of care, you get at middle of the hospital, discharge in the hospital, you’ve had an encounter, these are often critical moments and care and yet it can be really difficult to know that these things have happened and so it’s a nice illustration of something going on at the technical level in terms of you know, please message me when something happens and how that scales all the way up to actually interacting with patients.

Micky: Yeah, no I completely agree and I think it is, as you said, we think of these as query but the FHIR API is agnostic. It can do a push, it can do a pull, it really, you know, it doesn’t care. It says that we’ve only used it primarily in one particular way. Some other very intuitive examples I think, where the subscription resource that I think you know, your listeners will immediately sort of recognize and understand as important is it’s not only you know, changing where you are in the healthcare system for example but if your condition changes and let’s say, I’m relying on a clinical decision support or intelligent type of system that’s external, that’s connected to my EHR via FHIR API and it gives me important information on how to treat complex diabetics for example or how to treat patients who are on this particular type of drug that isn’t very common for example and it’ll take information on my EHR system and then provide guidance back to me on what to do in this particular case, what you want to be able to do is if that patient’s condition has changed in some way, you’d like that to be able to push, be pushed out to that system and have that pushed back updated guidance based on the patient’s new condition, right and right now that other system would always have to be asking you, has something changed, has something changed, has something’s changed, that’s not a very good pattern. I think most people would recognize.

Dave: I think that’s exactly right and again, to tie it to the real world clinical outcomes, it’s a pretty solid general rule in healthcare that when you shorten the cycle time for clinical care, the quality goes up. So, all the examples you gave, our situations where the sooner we know about a change in condition and the appropriate response to that and the sooner we do it, the more likelihood that we’re gonna get a good outcome for the patient and financially another wise. You had one more item you wanted to bring to us here. So, let’s get that one on the table too.

Micky: Sure, yeah, I’ll do that one really fast and that is refining some work that we had already done on a project that’s called CDS Hooks which is also, we’ve got to work more on branding, I think in the standards, higher standards world. So, CDS Hooks, CDS stands for Clinical Decision Support and Hooks release to, you’re sort of a software term of like a software Hook but the idea of it again in very intuitive terms, I think is what, but you know, in some ways it’s the dream of what we’ve wanted electronic health records to be from a functional perspective which is to say the notion of a software hook is that as I use my software application whatever it is I would like that system to be intelligent to the extent that when I do a certain thing or come to a particular place in my software application, it will go out based on instructions that I’ve given to it in advance, it will go out and actually hook another software application or hook some other information from another place and bring it back to me right at the point where I am and that’s gonna be the most meaningful to me in terms of workflow and so the very specific example here would be I’m in my EHR, I open up my ordering screen and immediately it would go out to an external service that provides some clinical decision support that’s not resident in my EHR and it’ll pull back in, it’ll take some information out of my EHR that’s based on you know, the patient particular clinical information that’s relevant to that particular service that, that external service provides and then it’ll give me intelligent advice on the order, the particular type of order that I’m going to or at that point but the important thing is it does it in a passive way or it does it from, I don’t have to push a button to ask it to do that. It basically is triggered by my opening up that ordering screen. So, what we are gonna focus on particular is radiology ordering. As you may know there is a CMS rule and a requirement for radiology ordering that a physician have some type of external guidance or external information to support that ordering decision they are making because imaging as we know is so incredibly expensive. So, the owner will provide, make sure that the physician has some kind of guidance. So, what we wanna do is have a FHIR based implementation that when a clinician goes into their radiology ordering module of their EHR that it would enable their being able to go out in electronic way consult clinical decision service and have that present information right back into their workflow, so that they can act on it based on that external information that they’ve got.

Dave: This is real exciting work because it takes us closer to truly integrating into the workflow in a seamless way, presenting information in a way that’s actionable and kind of defragmenting the user experience as we bring ever more powerful services to bear. So, you’ve given us a nice peak around the corner at what’s coming next and I personally find it very exciting. We could probably go on for a long time on this topic based on the number of activities out there and different projects but I think we probably should wind down here and so Micky if you would, take us home and what I’d like you to do now is share your most sage advice when it comes to APIs.

Micky: Oh Lord! Okay, yeah and I guess a couple of things. One is use them as early and as often as possible to the extent you can and I think there’s a little bit of challenge and a little bit if balance there because if we wanna do things in a standards way, the standards process is somewhat laborious and what I mean by that is it doesn’t cover all of the possible use cases that people want to cover to the extent that you have things that you wanna do and be able to enable, it’s great if there is a FHIR based approach to doing that and there’s a standardized thing because that’s gonna be something that standardized with the industry that’s available in your EHR and you know, that you are able to do but I think that it’s really important for people to be pushing the edge as well because the only way we’re all gonna get better is pushing the edge and if that means you know, sort of embarking on the proprietary API approaches that are offered by vendors or that are offered by the EHR vendors themselves or combination with vendors, you know, I think exploring more and more of those to ultimately provide better functionality to the users, that’s really what we’re all after at the end of the day. The happier users are the more they are gonna be engaged with it and the better they are gonna make it. An API is offer a way to have better and more rich experience and allow them to be happier at the end of the day and that means, they are gonna use the systems more they’re gonna use the systems better. So, that would be the first thing is try to use them early and use them often as you can. I think the other thing though is to remember that APIs are just a technical approach and we talked about this before. They don’t solve any of the business, cultural, legal, policy hurdles that we have. Sometimes they can present pathways and you had noted Dave. Sometimes they expose those in a way they haven’t been exposed before which is good because you sort of identify it in a way that might help you get to a problem but it also doesn’t solve a lot of those things. So, just not forget that those things are still there and those still need to be tackled and let’s not pretend that you know, that, that’s gonna be a magic bullet that solves all of those, you know, and I think at the end of the day it’s really about trying to provide as much additional functionality and a richer user experience so that we get higher adoption of all of these systems and there were not confined to our individual platform and I think we’re seeing movement now among the EHR vendors to enable their EHRs to be more and more like platforms that may be my home but I’m not limited to the functionality that my EHR vendor provides to me. I can use it as a platform to get functionality that’s available in other places and the only way that gets better is by customers and users complaining bitterly to their EHR vendors about the functionality that’s not there, right and I think it’s only the market and more users who speak from the bottom up, they keep the industry moving and keep the vendors moving.

Dave: Boy, there was a ton of sage advice in there. I’ll just call out a couple of things quickly. Like you, I definitely believe in the both end approach when it comes to standards and so I think it’s great that FHIR is maturing and providing real value but also like you, I think there’s a lot to be learned that the journey of discovery is out on the bleeding edge and I actually think of these things as kind of a yin and a yang that as the standards mature people should adopt and use those but the work that’s done on the bleeding edge can inform the choice of things to work on to standardize and what those standards ultimately look like and I think that’s been a through and through this. I think the other thing that I find so exciting about all these is that you’re right, this diminishes the technical barriers. I think it does shine a light on some of these other barriers. That’s probably a good thing. I tend to refer to those as the geopolitical challenges if you will but we’ve got to address those as well. It’s good to be able to set the technical piece aside and not let that be a distraction as we work on some of these other challenging issues.

Micky: Yep, totally agree.

Dave: Well Micky, thank you. This has been a tour de force in terms of what’s going on out there in the world of developing, real world standards that can be adopted and used practically and I am grateful for your time today.

Micky: Great, thanks Dave. I enjoyed the conversation and look forward to the next one.

Dave: We’ve been talking APIs with Micky Tripathi, President and CEO of the Massachusetts eHealth Collaborative. Again Micky, thanks for taking time to speak with us today.

Micky: Thank you.