IABtalks Keynote Speaker – Russ Leftwich, MD 

Innovations in Achieving Interoperability

May 4, 2018

I’m going to talk about innovations in achieving interoperability, and I think we don’t usually think of data standards as innovative.  But I’m going to change your mind, I think.  FHIR, which is HL7’s newest clinical data standard, is in itself an innovation, and it enables innovation for people using healthcare data. 

Now, one thing that’s happened that makes FHIR a necessary innovation, if you will, is that the meaning of interoperability has really changed.  In the 1980s, interoperability was about connecting two systems together.  And that’s where the data standards we use today came from.  They were built to connect one system to another system, and then we’ve leveraged those standards to connect one system to multiple systems.  But those standards really weren’t designed to do that, and in the current decade, there was an estimate a few years ago that the average US hospital has over 80 systems, IT systems, within its walls.  So their first interoperability challenge is just to connect their own systems to one another.  But now, in the 21st century, as we get into the second decade, interoperability is starting to mean something very different.  Interoperability now means being able to be in one place and see the data of an individual or a population of individuals from that one place in real time.  And that data is no longer in a hospital system alone.  It’s in many different systems.  It’s in pharmacies.  It’s in payer systems.  It’s in devices that people have at home and in wearables.  It’s in their family’s mobile devices.  It’s in social service agencies.  It’s in gen
omic sequencing labs.  So we have to be able to get that data to one place, to see it and to use it for clinical care, for other uses of that data, quality improvement and care coordination. And we can’t do it with the standards that were developed in the 1980s.  So that’s what HL7 FHIR is all about.  FHIR was built to answer this challenge.  The other part of the challenge is, not only is data in more places, but there’s a lot more data than there was 30 or 40 years ago.  So this is a graph that you can see is an exponential curve.  It’s from a publication by Dr. William Stead at Vanderbilt.  It’s an estimate of how many facts there are for a complicated decision in medicine.  And in 1980, there were about ten facts per decision.  In 2018, if you extrapolate on this graph, there are maybe 700 facts per complicated decision.  So it has grown incredibly just in our lifetimes, our careers.  And the other number that you should know is the number of facts a human mind can handle in making a decision.  That’s five.  I like to think I’m may be six or seven, but even in 1980, I was way behind, and now like everyone else, I’m hopelessly behind.  Yet, in clinical care, we still use the same workflows as we did 40 and 50 years ago.  We still act as if our physicians can come up with a conclusion in their head, and that hasn’t changed.  It needs to change. And the way that we can enable that change is with technologies like FHIR. 

So, it was with this need in mind that the organization, Health Level 7, about 2011 created a task force that was asked the question, what if we created a new standard from scratch?  What would it look like?  And after a time, a gentleman from Australia, Grahame Grieve, came forward with a concept that we now call FHIR.  FHIR was something new, because HL7 Version 2, HL7 CDA, were getting old, and they were the standards that were built to connect two systems, not to go out and get data from many different systems.  The reality today is, people are connecting with their own devices.  We are moving from offline data access and storage to online data access.  We have data transparency efforts in countries all around the world, things that have been inspired by the need to share patients’ data across organizations and to give individuals access to their own data.  And the data is different.  It’s many different types of data.  It’s a mixture of narratives and coded data.  It’s high resolution images and genomic sequences.

So FHIR, to explain a bit about what it is, is what’s called a representational state API, application program interface, or a RESTful API.  REST doesn’t refer to sleep or relaxation.  It’s an acronym; it’s an acronym for REpresentational STate, which means that you represent the data on one server in its current state on another server.  It’s the basis of Facebook and Google and all the ecommerce and social media applications we use daily.  But probably the easiest way to explain it is the airline booking sites that we all use.  And if you go to your favorite airline booking site, they all work much the same, and you say you want to go from Boston to London on May the 5th, in a few seconds you see several flights on different airlines, and that doesn’t work because your favorite travel site has downloaded all the airline schedules.  It works because the airline industry has agreed on how they’re going to represent the data in an airline flight.  The departure time, the arrival time, the price. 

And that is what FHIR is in healthcare.  It’s both the same technology as those Internet sites use, and it’s also the meaning of the data in healthcare.  And that’s where it gets a lot more complicated.  The number of data elements in an airline reservation is probably less than a dozen.  In healthcare, one coding system alone, the SNOMED code system has 380,000 codes, and 1.2 million relationships between those codes. Healthcare is not rocket science.  It’s a lot more complicated. 

Let me explain a bit the concept of what FHIR is. FHIR starts with basic building blocks called resources.  Resources are data concepts, not a data element, but something larger.  They have a known location, which looks like a URL, a URI.  It points to a location on a server somewhere, where that data is located.  And they are logically discrete data concepts, like a patient, a medication, a family history, a list. Resources in FHIR get reused for different things, so the list resource is used, whether it’s a list of medications that an individuals is on, or a list of patients that a provider has in the hospital.  Part of the concept of FHIR is to make it lean and efficient to use, so resources get reused to represent different data.  There is also the concept of a document in FHIR, where the data in a typical clinical document, like a history and physical, would be encoded as FHIR resources.  A care plan resource, which is not a document, but rather the data that you need for a care plan, an individual’s conditions, their care team, and the activities that are directed at reaching goals for each of those conditions.

The other important concept in FHIR is profiles.  And this is where it starts to get a bit more complicated, but profiles are the collection of FHIR resources, the code system binding the vocabulary specifications that you need for a particular use case in implementation, and extensions, FHIR encoding that’s not part of the standard, but is needed for your particular use case.  Those things make up a profile.  And shared FHIR profiles are the basis of interoperability.  Just using FHIR doesn’t make something interoperable.  Using the same FHIR profile, which specifies exactly what the data means, is what makes interoperability.  So if two ends of an interoperability transaction aren’t using the same profile, there is no interoperability. 

One thing that this means which is a complete paradigm shift from existing standards is that when you represent data as FHIR resources, you can move that data to a different interoperability paradigm, and it doesn’t change.  You can use that FHIR data in a message sending from one system to another, like an HL7 v2 message would be sent.  You can put that data in a document that would be analogous to a CDA document.  You can represent that data as a REST API.  And you can use that data just as it is in services -- in a decision service or alert service, for example.  That’s not true of any of the existing standards.  IF you have a lab test result, for example, in an HL7 v2 message, you cannot simply drop it into a CDA document.  There’s some transformation required.  But in FHIR, you can literally cut and paste the data into a different interoperability paradigm. 

That means that we can achieve this concept of true interoperability: we exchange data, and it means the same thing to both ends of that data exchange. 

One thing that makes FHIR innovative and suited to this idea of seeing data in different places in real time from where you are or where the patient is, is the ability to query for specific pieces of data.  You cannot do that with other standards.  In FHIR, you can query for an individual’s medication list or a laboratory or set of laboratories from a server or multiple servers.  In existing standards, you would not be able to do this. You might be able to query for a document that has all that data, plus a lot of other data, but then you’ve got to sort through and find that data. 

I have said FHIR profiles are essential to true interoperability. So let me explain a bit about what this challenge of creating FHIR profiles really represents.  Suppose there were two individuals who had never seen a zebra before, and one of them says, it’s a white horse with black stripes.  And the other one says, it’s a black horse with white strips.  Well, as humans, we’re very good at pattern recognitions.  Even a kid could figure out these two folks are talking about the same animal.  But computers are not good at that.  Computers, you remember, can handle 700 facts at once, but they can’t distinguish between these two descriptions of a zebra, nor of the tens of thousands of descriptions of data in healthcare. 

So that formal description of what a piece of data is, is called a clinical information model.  It’s the rules, the relationships and the vocabulary constraints that are needed to define a particular data concept.  So the description of the zebra that the computers are going to share is a formal clinical information model.  And as I said, i
n healthcare, there are tens of thousands of those, tens of thousands of data concepts that could reasonably be described in two or more ways, but if we do that, we don’t have interoperability.  So one preferred description gets translated into a FHIR profile, and it’s using the same shared FHIR profile that creates interoperability. 

Do we have models now?  Well, in a way.  Take a typical clinical document, like a history and physical.  If you printed it out on paper, you know what the data represents, because it’s in a certain place in the document.  But if you took a pair of scissors and cut that document into data elements, then you don’t know what the meaning of that data is.  Say it’s diabetes Type II.  But now you don’t know whether that’s a condition the patient has. Whether it’s a condition they had before they had surgery and lost 200 pounds, and they no longer have it. Or whether it’s a condition their mother had and it’s listed in the family history. 

o in FHIR, part of the challenge is to represent those relationships that we have typically gotten as a human from a document that structures the data in a certain way.  In FHIR, we have to represent the relationships between the resources that are part of that FHIR data concept as a profile.  If we took a high-level view of a FHIR procedure profile – it might be a lab procedure, an imaging procedure, a surgical procedure. Well, there’s a patient upon whom the procedure was performed.  There is the specific procedure that was done.  There is a provider who was the performer of the procedure.  And there’s a condition that was the reason the procedure was done.  And then there is a diagnostic report that comes out of that procedure.  So putting all those together, encoded and pointing to each other is a FHIR profile for a procedure.  Now, in this diagram, you can’t see the details that are there, if you were able to zoom in, and all of those things have particular data elements.  Who was the patient?  Who was the provider?  What was the procedure?  But the idea is that all of those are connected in an encoded way, not as a document, but as a FHIR profile.

So a lot of people are thinking, well, isn’t FHIR just a draft standard?  It hasn’t been 
around long.  But I think we have to have a different concept of what a draft standard is in this new interoperability era.  FHIR is new, but I would compare it more to an iPhone in terms of maturity.  Well, the iPhone 2, we now know, wasn’t very mature.  It didn’t have nearly the functions that the iPhone X has.  It didn’t have the functions that the next iPhone had.  But people bought it, used it, because you could do thing
s with it that you couldn’t do before.  And that’s what FHIR has become.  As we’re now on the third release of FHIR, we are seeing that subsequent releases are going to have more functionality, more capability.  But people are actually using FHIR.  There are hundreds of organizations around the world that have implemented the second release of FHIR and are using that for mobile apps, not for exchanging data across organizations so much, but for being able to access the data in their own systems that they couldn’t get to efficiently before, and have that data useful in clinical care, because you’re able to have it on an app that’s customized for the provider or clinician or patient to see that data on an app that’s based on FHIR.  And it’s going to get better.  Like the iPhone or any other brand of smartphone.  Each subsequent is going to have more function.  But people are using it, because it does things that you couldn’t do before.  It is innovation in a data standard.  


Popular posts from this blog

IABtalks: February 23rd Industry Presentation & Networking Event | University of Utah School of Medicine | Department of Biomedical Informatics