Interoperability: Why is Healthcare Data So Complex? | Podcast

Welcome to Healthcare IT Talk, interviews and discussions on the topic of information technology in healthcare and life sciences.

This is Steve Chipman, and I’m your host for this episode. Today’s guest is Steve Heard, Vice President of Technology, at J2 Interactive. Steve has been involved with healthcare interoperability projects for almost two decades. He currently manages a staff of over 150 health care IT professionals. Today, I’ll be asking Steve a number of questions about interoperability in healthcare.

Hey Steve, let me just start by asking, what is your definition of interoperability in healthcare?

That’s a good one because the term interoperability gets thrown around a lot with integration and plumbing and all that sort of stuff. Really, what it comes down to is it’s just making all the systems talk with each other.

If you think about how many different types of systems that you have in a hospital ecosystem and then how many different systems you have in the broader health care ecosystem, once you’ve left that hospital and whether it be private practices, or ambulances, or laboratory, everybody’s got a computer and everybody’s got their data on that computer. And you would think and hope that all those computers just magically talk to each other. But they don’t. And there’s different standards. There’s different legacy things that are going on. And so interoperability is the idea of getting these systems to speak with each other, but also getting them to speak with each other in a meaningful way, respecting all of the different things that make healthcare data a little bit different than, say, financial data or logistics data.

So interoperability in our world is more than just that plumbing of getting data from one point to another. It’s following the rules that are pretty specific to what we do.

And for our listeners who come from a corporate IT environment and are new to healthcare IT, can you explain the difference between what they’ve come to know is integration and interoperability in healthcare?

The easy answer is that it’s harder. Integration and interoperability, again, I don’t want to get too bogged down in vocabulary. They do mean very specific things to certain people. Right. There are all those words out there: integration, interoperability, interfaces, electronic data transfer, information exchange. You know, it’s all some kind of plumbing one way or another.

When we talk about interoperability, though, and how it is relative to, say, finance or logistics, or whatever you’re used to, the reason why it is harder or more challenging on the healthcare side of things is: it starts with 30 years of standards that we’ve been using, and we have systems that have been going back to the ’70s, the ’80s. Many of the systems that we work with every day were built in the ’90s.

Healthcare, more than any other technology vertical, is probably the slowest to upgrade. Healthcare upgrades are really, really expensive. Legacy systems are everywhere for a reason. You very rarely get to greenfield a healthcare application. So they take time to do upgrades, they’re dangerous, they take a lot of money, they take buy-in from everybody more so than ever in healthcare. You really see the if it’s not broken, don’t fix it kind of stuff. So that’s one challenge is just the years and years and years of different systems that we’re talking to.

I think another thing that makes interoperability harder than your typical integration is that our space has traditionally been dominated by a few vendors. It hasn’t really been until recently that the vendors have opened up their systems to even want to talk with other systems. There’s a lot of incentives for the big electronic healthcare record manufacturers or software developers to kind of keep the data in their world. Through some nudges from our government, through overwhelming customer demand, and just kind of the nature of IT systems opening up more, we have started to see some of these walls come down. But typically it has been, just because you can talk to System A doesn’t mean you can talk to System B.

And then some of the other things that make us uniquely different are patient record matching is very, very challenging and very serious. This is the idea that when you present yourself at a hospital, they take down some basic information about you; maybe your name and address, possibly your birthday, your Social Security number, getting your data matched up with what’s already in the system, it’s a really big deal. It’s really challenging. Here in the United States, we don’t have a concept of a universal medical record number. Any time you go from one system to another, it’s sort of a game of, OK, how does their system identify you? How do you match it up with how another system identifies you?

And if you think about the implications of this, when you’re talking about matching up prescription drugs or matching up people’s laboratory results, every single integration sort of starts with a little bit of a conversation with the systems upfront about who is this person, are we sure it’s this person, let’s make sure we’ve got this person matched. And then you can start exchanging the data. And then kind of along the lines there.

I think the other thing that we have lurking over every one of our moments that we share data with one system to another is the idea of privacy and consent. Who is allowed to see your data? Who have you authorized to see your data? Even within the same healthcare system or network, there may be different tiers of authorization of who is allowed to see your data or what kind. You know, things like mental health data, sexually transmitted disease data; that’s really sensitive stuff that may be treated one way or another. Just because you necessarily have that type open from one system to another, it doesn’t mean that you’re allowed to move the data out of that one system.

Long answer, but we could go back to just like I said, it’s harder.

It sounds like it. But once you do have the connections made, there are obviously some benefits to patients and some very strong benefits to patients. Can you give us a couple of examples of interoperability in action?

Yeah, I think a great example is just a physical one, right? So if you get some blood work done at the hospital, and it goes to a laboratory that is on the other side of the city, we used to have to wait for couriers to bring those results back on a piece of paper.

Now, those just go from one system to another, electronically, of course. That lab system may work with 15, 20, a hundred different hospitals. And those different hospitals have their own EMRs. Some of them may be by the same vendor, but even the ones that are by the same vendor may be set up a little bit differently.

The IT responsibility that would be put on top of that lab system to be able to communicate with every one of those different EMRs, that would just be crushing for them right there. They’re not nerds. They’re lab people. So interoperability is sort of this magic middleware that makes it so they can do what they do best. Everybody agrees on the basics of how the communication should happen, and then we let that go in the middle.

I think another good example that’s particularly timely during the pandemic here has been the emergence of the health information exchange. And we work with a lot of these. And the idea is you take a geographic population of people with healthcare data, for example, the area surrounding New York City or the state of Montana, people who share kind of a physical area in common. Now, they may go to all sorts of different healthcare providers, even under competing systems, but the idea is to aggregate all of their data together and get that into one database or one central processing area. That is only possible because of interoperability.

Once again, you’re talking about hospital systems, lab systems, physical therapy systems, and nursing homes, everything that, at its core, is healthcare data. But it’s all very, very different data. And interoperability lets you pull that all together in this idea of a health information exchange, and then you can do some pretty cool stuff with that. You can, in real-time, be looking for people who are presenting with flu symptoms, or you can be looking for trends across certain populations that are presenting with the particular lab result that you’ve been looking for. And then once you’ve got all that data aggregated, you can view sort of analysis on it and start talking about predicting what might happen based off of seeing trends. We used to not be able to do that when my record was siloed at one hospital and your record was siloed at another hospital.

And then finally, I think that what we’re really, really starting to see, in fact, there’s even been timely things in the news today about what Apple is doing with their iPhone is the idea of interoperability, making it so that your record is portable and you can take your record with you when you go places.

So, again, it doesn’t matter the healthcare provider, what brand, or what vendor of system that they’re using. If we know that there is a standard that everybody speaks to or everybody can come close to speaking to, then you don’t have to worry about when you’re building your application or you’re solving your problem, the “how do I exchange this data from one system to another,” that’s something that interoperability is solving for you.

What are some of the main challenges of interoperability that you’ve personally experienced or that your team has seen?

I think one of the biggest challenges is that, because we are using standards and we are using systems that are so established and have been around for so long, the way that we exchange data isn’t exactly the same as how we’ll just call them, you know, very modern systems, are exchanging data.

We rely on some older standards now. Doesn’t say we don’t have an equivalent of the newer standards, but the real workhorse of our industry is, as a concept called HL7, and HL7 has been around for years. HL7 has sort of taken on its own kind of life in that it doesn’t matter what version you’re using, chances are somebody is probably using it a little differently than you expected. The oldest joke in our industry is if you’ve seen one HL7 integration, you’ve seen one HL7 integration. They really are that different.

And then, of course, if you have somebody who has been doing interoperability or integration for the last five years on a web platform or in some other industry, they come in and they take a look at how we’re doing things and they just scratch their heads. It’s not a full-blown time warp, but you do have to go back in time. But again, it’s because the systems in the hospitals, they’re working, they’re not broken, they’re just getting a little old. Just the nature of HL7, I think makes it challenging.

The other thing is, is that we spend a lot of time having to massage and transform data that you sort of expected it to be one way, but it comes in another way. A lot of time is spent on data quality and making sure your data is cleaned up. As we say: there is no margin of error in healthcare data. You just have to get it right. You have to be able to predict it. It’s not something that you want to find out after the fact that, oh, that was off by just a little bit. You can figure it out or you can intuit it from there. The data—it needs to be perfect.

I think another problem is that we’re firmly in the world of cloud computing now. There’s a lot of standards, API standards that if you were building a software application from scratch right now, you can assume, OK, this is going to be restful services over HTTPS. Right. Or there’s going to be OAuth authentication. We’ve done a good job over the years of sort of settling on ways of doing things.

In healthcare IT, we are still doing things older ways. We are still doing a lot of systems on-premise. The idea of VPN’ing in and out of buildings is still very much a part of what we do every day. Some data is starting to move to the cloud. Some data is staying behind all of the rules around where that data can be and can’t be. Every time you are thinking of talking to another system out there; before you can talk to that computer, you have to talk to a person. And so a lot of policy has to go through.

There’s a lot of administrative overhead that goes into the idea of, “can my system talk to your system” before we even get into, “how are our systems going to talk to each other?” And I think the last one would be testing. We test and test and test and test. Anyone who is familiar with software development knows that testing is always the last thing to be thought about, is the last thing to get the budget, and it’s the first budget to get slashed. But we just can’t avoid that. Testing is just too important in the work that we’re doing. The testing part is one of the parts that makes it expensive. There are very few shortcuts you can take around testing to do things well.

And can you tell us a little bit about how interoperability standards have evolved over the past several years, particularly with regard to FHIR?

Sure. So I mentioned HL7. You know, we’ve been using HL7 for two, three decades now. HL7 was a great little point-to-point protocol where you got to file. If you looked into it, you could kind of decipher what’s going on but not, not terribly. That evolved into using some more XML-based standards with SOAP services. When that was big, we were doing a lot of that.

FHIR is the same data model. We’ve done a pretty good job of perfecting the data model or at least getting close enough. The concepts are still the same in there. If you were to crack open these objects or these databases, you’d see, OK, that makes sense. That’s a medication. That’s a diagnosis. That’s a procedure. Even to non-healthcare IT people, that makes sense. What’s changed, though, is the format.

We are now, not to get too technical, but we’re now using JSON objects over RESTful Services. Anybody who’s been doing mobile or web development for the last decade is probably shrugging and going, “Oh, of course you are.” But that’s sort of a big deal for us. It means that more people can build applications. It means that your phone and your web browser are now ready-made for the healthcare world, or they weren’t necessarily before. Also, the thing about FHIR, is that it’s the first time that we’ve really introduced, in addition to a data format to follow, an API specification for how you implement that. How you go about adding data to people’s records, or searching people’s records, or looking things up in people’s records, or updating people’s records, that is all now, there is a by the book API that you have to follow.

So, for the first time, if I build a small application that’s very purpose-built, like, say, it’s a behavioral health application, I have a very, very high probability that it will be able to work with the big EMR systems out there, no matter who the vendor is. So it’s now worth it for me to take the chance on building this application.

That sort of entrepreneurship and try things, fail, try again, that we see coming from the sort of the Silicon Valley model of building software, it’s a lot easier to do that now because of FHIR. There are standards that you can build to that. You don’t have to be part of some sort of esoteric knowledge of healthcare IT to get your ideas out there.

So, I mean, yeah it is. It is a one-word answer. It’s FHIR, which, by the way, is F.H.I.R: Fast Healthcare Interoperability Resources. The downside is the extreme amount of fire puns that we’ve been exposed to as an industry. You know, playing with FHIR and FHIR is catching on. If you think you’ve got a new one, I’ve heard it.

I’m sure the developers had that in mind when they came up with the acronym.

Right. Well, we spent a decade dealing with Java puns. Now we get FHIR puns.

So that leads into my last question, which is how can a CRM system like Salesforce or Salesforce Health Cloud become part of the interoperability equation within a health system?

Yeah, I think about it as part of the equation. I’m visualizing some boxes and arrows now on a whiteboard.

Salesforce is certainly a data target, right? You want your healthcare data to end up in Salesforce. It’s also a data originator. Actions that happen inside the Salesforce system, you want to get sent back to sort of the definitive electronic health record or maybe you want them to go off to some of these systems on the outside that we’ve been talking about. Interoperability is what makes that happen in between.

Salesforce is, you’re not going to be able to just crack open a Salesforce system and, ta-da, talk to that EMR that is buried deep inside a hospital. As much as we would love that to happen, you can’t do that really with any technology. You do have to have interoperability in there, you know, some sort of bridge.

Where you find Health Cloud wanting to be on the end of that equation, what Salesforce and the CRM model are very well positioned to do, which just frankly, the existing EMR systems out there aren’t built to do, is as we start switching more to patient population management and doing more direct outreach to patients, and somebody’s job isn’t necessarily to sit in the hospital now and wait for the patients to come to them. It’s to be more proactive and talk to them, see how they’re doing, see if they’re taking their medications, see what procedures that they need to have scheduled in the future, that is CRM. And that that is where Health Cloud nails it.

But the challenge of Health Cloud is that the experience that the person who is navigating that system, it’s only going to be as good as the data that they have in there. And that comes back to interoperability and this idea that getting data out of systems and from other systems is still a very challenging thing to do in the healthcare space.

So, if you can solve it at an interoperability level, let Health Cloud stick with what it does best. Don’t try to turn a Health Cloud itself into the tool that is grabbing your data from all of these systems. Rely on interoperability to do that. And that’s been the case, I think, for a lot of years with a lot of the Salesforce implementations. I think it’s just more acutely obvious to people when they on day one of, “how do I make my Salesforce application talk to your electronic medical record,” you see very quickly that the game is a bit different.

And some of these EHR systems, which used to be fairly close to open themselves up such that they can be connected to a system like Salesforce Health Cloud.

Exactly, yeah. Because the, you know, at this point, people like Salesforce are innovating at a pace quicker than the internal healthcare vendor world can innovate. So it’s a very good thing. But they need that data, right, and so unlocking that data and building the systems around and making predictable systems around: How do you move that data into an application like Health Cloud? That’s where we come in.

Well, thank you very much for your time today, Steve. This has been very enlightening and I think anyone who’s listening to this that needed to know a little bit more than they already know about interoperability probably gained a lot. So we really appreciate it.

Thank you.