FHIR holds big promise for interoperability, but will need to coexist with other standards for the foreseeable future

Russell Leftwich, MD, senior clinical advisor of interoperability at InterSystems and member of the HL7 board of directors, says IT professionals need to have a strategy for integrating the spec with existing standards into a hybrid model.

Once again this year, HL7's FHIR specification was a hot topic at HIMSS17, a burning issue discussed ardently across the show floor. (Our apologies, but heat- and flame-related puns seem to be required when writing about FHIR. Thankfully, we've gotten them out of the way early.)

But while many vendors were touting their embrace of the interoperability spec, and while the promise it holds for enabling faster and easier exchange of data is very real, the open API isn't going to supplant existing HL7 standards such as Version 2 and CDA any time soon. That means the industry will be taking a hybrid approach to interoperability standards for the foreseeable future.

We recently spoke with HL7 board member Russell Leftwich, MD, senior clinical advisor of interoperability at InterSystems and co-chair of both HL7's Learning Health Systems Workgroup and its Clinical Interoperability Council, for his perspective on FHIRs place in healthcare now and prospects for the future.

Q. How do you see FHIR's place right now in the larger ecosystem of interoperability standards?
A. Number one, it will be the preferred technology for new development, particularly when it involves accessing data across many servers. That's one of the driving forces for developing FHIR – that the existing standard are based on technology of a previous era. Really, interoperability in the '80s, when those standards were first developed, meant connecting two systems together. And then we managed to extend those standards to connect one system to multiple systems. But the reality of today is that there's data across many systems, for an individual or a population – and that's happened steadily over the past decades. The amount of data has grown, and so has the number of places where it exists.

The inspiration for FHIR was to be able to see that data from one point in real time, the way we do in other industries: The way e-commerce works, the way Google and social media work, where you're connecting across the entire internet network from one place, and seeing the data that's out there. Not necessarily downloading it, because that's becoming harder and harder to do, based on the amount of data, but to see the data you're interested in. That's the technology that FHIR is based on.

Q. When a vendor touts FHIR capabilities what does that mean? Should it be taken with a grain of salt, or should we temper our enthusiasms? Or is FHIR as exciting as everyone says it is?
A. Well, it is exciting. And I think what you should take from that is they're excited about it. And they understand that. I don't know what "FHIR-compatible" means to any one vendor, there's not a good definition of that. But that said, there are a number of apps that have been developed around FHIR and are actually in use and production.

There was recently an event at Duke called the FHIR Applications Roundtable where something like 35 different FHIR apps were demonstrated by the developers. Now, most of those early apps are not about connecting across systems but about accessing the data in your own systems – or your own closely held systems – to more easily access it in the flow of particular user, of particular clinical domains, where they would like to see the data and see it in a way that they can easily use it, as opposed to having a huge pile of data they have to sort through. FHIR makes it easy to access just the data you need, which was not the case with previous standards.

Q. At HIMSS17, Micky Tripathi made a very compelling case about how beneficial FHIR can be, and how much progress has been made in a relatively short time. But in the near term, how do you see it coexisting with other standards in actual practice?
A. It definitely will coexist for the foreseeable future, there is no compelling economic argument to replace the uncounted billions of dollars worth of existing systems that use existing standards and do what they do perfectly well with them. The change in technology is such that you probably couldn't retrofit most of those systems with FHIR.

But what will happen, I think, is that FHIR will serve as a translation layer, as is the case with the InterSystems health informatics platform, which has now become enabled so data can come in in existing standards like V2 or CDA documents, and can be transformed into FHIR and take advantage of the technology FHIR is based on to do things with that data. And then can be exported from that platform as any one of those standards, including FHIR, back to systems that may only understand some of the existing standards.

Q. Practically speaking, what should IT teams at hospitals and other providers be thinking about in the years ahead, as FHIR continues to evolve?
A. Vendors, and the organizations that use health IT systems, need to think about a strategy to live in this hybrid environment. You're certainly not going to replace or abandon your existing system – the average hospital today has in excess of 80 systems within their walls – so many of those systems may operate very well with older standards, but you want to be able to get that data and aggregate it with data that comes in other forms and from other systems – some of it in FHIR, some of it in existing standards – and aggregate that data.

I think FHIR is the ideal standard to create a representation of that data as FHIR resources, and then you can operate on that data with the technology that FHIR represents and do a lot with it that you couldn't previously.

Q. Do you see a time where FHIR will win out as a standard and be the only game in town? And if so, how far off would that be and what would have to happen between now and then?
A. I think before that happens there would be something new after FHIR. Because of all the systems that exist, the economic argument just can't be made for replacing all of them. And many of them have quite a long lifecycle. So by the time they are replaced, there will be something better than FHIR. But I think that day is probably 20 years off. Some people think longer.

That said, I think FHIR will be essential in the next few years as it evolves. I would compare the way FHIR is now to an early version of a smartphone: We have the iPhone 3G, and it can do things phones could never do, and we're excited about it. But it doesn't do nearly what the iPhone 7 will do. But it's still useful even in its current form. And it sort of confounds the concept of a draft standard because people are actually using it. So I think it's more the concept I suggest: It's a new reality of maturity where standards evolve, and you use the current version because it's useful and the F in FHIR stands for fast, and it is fast to develop applications with FHIR, and implement them, and they operate in this technology world that the older standards can't take advantage of.

Q. What are some areas where FHIR is being deployed that you're particularly excited about?
A. I'm really excited in general that there are so many people who have developed something with FHIR. I heard there were more than 60 FHIR presentations at HIMSS17, where at the previous annual conference there were fewer than 10. That reflects how fast it's growing.

I think some of the most exciting aspects of FHIR are when it's used in areas that don't have existing standards, like genomics. There's no older genomics standard because genomics hasn't been around that long. So that was an ideal place for FHIR to become the standard from the beginning. And truthfully it's the only standard that could meet the needs of that domain, because when someone has their whole genome sequenced it creates terabytes of data, and you're not going to be able to move that data around easily. You need to be able to access it, get the important pieces of that data – genomic variant or the tumor mutation – that's reflected in that huge amount of data, and that's what FHIR is ideal for doing.

The other thing that's great about FHIR is it's ideal for mobile devices and mobile applications, because it's the type of technology that most of those apps were already built on. FHIR is just the healthcare version of that, so a lot of the uses of it we're seeing are those mobile applications, web apps that leverage the technology FHIR is made from along with its healthcare structure to do things you couldn't do before.

Q. In the meantime, as it runs alongside existing standards in clinical settings, what are some of the technical challenges of managing that?
A. You do need a strategy. Connecting to each of those many systems individually with some sort of FHIR translation interface probably isn't practical. Having a platform that can connect to those systems, or maybe is already connected to those systems and can take in data in different formats and standards and transform it into FHIR is, I think, the only workable strategy. Retrofitting systems with FHIR or connecting them with some sort of individual translator probably isn't a good long-term strategy. It's going to be exciting to see what happens with FHIR even within the next year. We're about a month away, probably from the publication of the next version of FHIR STU3 – it stands for standard for trial use three – which will be another quantum leap for FHIR, and will enable a broader range of applications to use it. Because of how fast the applications can develop – even recreating an app for the new version of FHIR shouldn't be much of an obstacle, so organizations can go along and take their existing applications and start to build new ones that leverage the increased capability of this next version of FHIR.