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.
S
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.
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. 
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.
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. 
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 
Comments
Post a Comment