Jan 31, 2019
With the care of patients with cancer strewn across numerous settings, are electronic health records (EHRs) meeting the definition of interoperability according to the 21st Century Cures Act? Dr. Pennell speaks with author Wendy Rubinstein.
Read the related article "CancerLinQ: Cutting the Gordian Knot of Interoperability" on JCO OP.
Hello and welcome to the ASCO Journal of Oncology Practice
podcast. This is Dr. Nate Pennell, medical oncologist at the
Cleveland Clinic and consultant editor for the JOP. Most
oncologists in America today use an electronic medical record, or
EMR. But for a number of reasons, few of us are able to access
records for patients outside of our own practice, a concept that's
known as interoperability.
Today we're going to be talking about a new editorial published as
part of a series called "The State of Cancer Care in America." This
editorial is titled "CancerLinQ-- Cutting the Gordian Knot of
Interoperability," published in the January 2019 issue of the JOP.
Joining me on this podcast is the author Dr. Wendy Rubinstein
medical geneticist and Deputy Medical Director at CancerLinQ, LLC.
Dr. Rubinstein, thank you for joining me today.
Thanks for having me.
So I know that this is not going to be a surprise to any of our
listeners, but would you mind just kind of giving us a little
background on the issue of EHR interoperability, and how did we end
up with the scenario that we have today?
Well, sure. Of course, electronic health records systems weren't
built with interoperability in mind. The overarching goal for
hospitals was documentation to support billing, and it hasn't been
a priority for hospitals to make it easy for their patients to
interact with other health systems. But to be fair, people didn't
talk much about interoperability 10 to 15 years ago. And I'm not
even sure an official definition existed.
So now the 21st Century Cures Act provides a definition. So
basically, electronic health information should be able to be
securely exchanged with other health information technology. And
there should be no special effort required by the user, especially
and including patients. And the data exchange for the authorized
use, it needs to be completely enabled under applicable laws, and
any information blocking is prohibited.
So what this comes down to, basically, is that a patient should be
able to have care at one medical office, and then go to a separate
system across town, without having to fill out another paper form
with their complete medical history, medication list, and review of
systems all over again. So part of the article talks about, and you
mentioned, the ASCO Oncology Practice Census. And in 2017, the
practice census found that 40% of practices were unable to accept
any patient information from other practices.
And you might think that the problem is getting better with
attention to it, but actually, it's getting worse. In the 2016
practice census, 34% of oncology practices said that their EHR was
interoperable with hospitals in their region. But in 2017, only 10%
were interoperable with regional hospitals. So in oncology, this is
especially important because cancer patients typically have their
care strewn across multiple specialists, surgery, radiation
oncology, medical oncology, and more. So with their care being
decentralized and being complex, how can we really subject our
patients to recounting their entire history every time they come to
a new specialist?
And we're relying on them to be savvy about their cancer history
and to be accurate about it. And this is often the worst time of
their life. So without quite saying it to them, we're basically
letting them know that we don't communicate with our other doctors.
And I have to say, sometimes my own medical profession embarrasses
me.
Yeah, it's interesting. I mean, it's a couple of different issues,
the first being of just simple interoperability and having access
to your patients' records when they're not within your system. The
traditional way of doing this is you've typed up a letter or a note
from what you've done, and then you mail it to the other physicians
who are either the primary care doctor or the person who referred
to you the patient. And strangely enough, that's still mostly how
this happens.
I have a sophisticated electronic medical record that puts together
a sophisticated note filled with all kinds of important
information, which gets printed out and put it in an envelope and
mailed to someone, rather than sending that electronically and
having it available whenever they need it. They have to somehow
come up with a way to scan that into their system so that they can
read it. So it's really remarkable that we're still in that system.
And I now have limited interoperability with other people through
my own EMR, and it's just astonishing how much easier it is to keep
track of people with that. Once you start to get a taste of the
potential of that, it's really hard to go back and not be able to
access patient's records anymore.
Everyone I think is a little bit aware of this issue and becoming
increasingly aware of this issue. What are the barriers out there
to making EHRs interoperable? It just seems like such an obvious
thing to do, and yet it somehow is a difficult process.
To attempt to maybe take something complex and bring it to some
basic issues, I can call out a couple of issues. One is extreme
customization, and the other is that we need a common language that
can speak across different implementations of electronic health
records. So with extreme customization, and this is how I would
characterize it. So customization is very effective at locking up
health information and preventing it from being exchanged. And for
any EHR vendor, offering a way for clinicians to customize their
reports, their documentation, it really is a great way to satisfy
them.
And in fact in my own experience, my cancer genetics practice
became very efficient by creating templates for notes and letters
about genetic testing and managing patients at high risk of cancer.
But if you think about it, when I recorded a diagnosis of colon
cancer in a letter to the patient or the clinician, it wasn't
mapped to any standard vocabulary or code. It can't be shared other
than as a TXT file.
When you talked about bringing in scanned documents, yes, you can
look at them, but they're not machine computable. In fact, if you
like to know how many ways you can say total neutrophil count in an
electronic health record, CancerLinQ was in the unfortunate
position of figuring this out. So in the first 30 oncology
practices that CancerLinQ received data from, there were 76
distinct ways to say total neutrophil count, like white blood cell
count or WBC. And that means that there were more than two names
per organization on average, even within an organization. There's
no agreement on what to call this.
So it's certainly true. We, as human beings, we can all
semantically process different terms for total neutrophil count,
but a computer can't. It can't do that, unless we provide a mapping
or we create it. So this basically locks up the data and reduces
its value. So to extract the value, we apply natural language
processing and human observation using interfaces. But that's
expensive, and the problem is it doesn't help at the source. You
still have the EHR, it's not really aggregated together yet, and in
the day to day workings, you're not really doing anything to solve
the problem.
So the other problem which is very much related is we need a lingua
franca. We need a common language to make the proper use of the
data that we have in EHRs. And so on a higher level, ASCO and
CancerLinQ have convened a volunteer stakeholder group, and this
represents diverse perspectives in oncology, different specialties
coming to the table. And the purpose is to create a core set of
data elements from oncology called mCODE.
So mCODE stands for Minimal Common Oncology Data Elements. And ASCO
is aligned with other medical organizations, as well, and the Biden
Cancer Initiative, so that together we can inform oncology EHR
vendor design. We can inform their decisions and, hopefully, prompt
interoperability to improve cancer care.
One of the things that's-- of course, you now work with CancerLinQ.
Can you tell us just a little bit about CancerLinQ and how
CancerLinQ can work to overcome some of these issues?
Sure, I'd love to. So CancerLinQ is a major initiative at ASCO. And
the goal was to create a learning health system for oncology. So
first and foremost, CancerLinQ is a quality measurement and
reporting system. We have over 100 health care organizations. These
are large and small, they're community and academic, that are
participating in CancerLinQ.
And so far, we've established data flows with 47 organizations, and
we've integrated data for over a million patients with cancer. And
that reflects their comprehensive longitudinal record of health. So
by doing this, the reason to do this is we're enabling practicing
oncologists to measure, and report, and improve the quality in
patient care.
So when you look at, for example, the 2017 ASCO Oncology Practice
Census, about 25% to 30% of practices, they called out quality
measurement and reporting activities as a top burden for them. In
order for them to do this, they have to actually do manual
extraction from electronic health records, if you can wrap your
mind around that. You have to pay to do that. So the CancerLinQ
platform reduces the reporting burden by displaying the quality
measures for MIPS, MACRA reporting and also supports ASCO's QOPI
certification.
And what this means is that clinicians can actually see the time
window they have left to take specific actions to meet the quality
benchmarks. The other part of CancerLinQ is that we provide
statistically de-identified data sets from the cohort to
researchers and to FDA. And in that way, we're trying to accelerate
discovery and scientific improvements to cancer care.
Yeah, it's a fantastic initiative, and I'm glad to see that it
seems to be growing and doing well. The next question would be, how
can CancerLinQ, aside from individual practices being able to use
the data for quality metrics and, of course, the anonymized pool
data for research, how is this working to overcome problems of
interoperability?
So CancerLinQ is somewhat unique in that we've integrated data from
practices, so far using seven different electronic health records.
So we don't limit, we feel we can't limit the data aggregation to a
single EHR type because the overall goal is to learn from all
patients. But there are some common problems that we share with
other big data providers. So any entity that's performing data
aggregation, they're also coming up against the same problem we
have, as needing a common language for oncology, such as mCODE.
And as I mentioned, ASCO is looking to engage everyone who has this
common problem to solve it together. One barrier I can't resist
talking about as a geneticist is the way genomic data is handled.
The one disturbing practice is that really the way DNA sequencing
data exists is it's completely structured in machine computable
when it comes off the sequencer. I mean, almost by definition.
And then the results get reported by paper, and even if there is an
electronic file sent to the practitioner with the report, there's
nowhere in the electronic health record to store the genetic test
data in its rich detail. So the report might get scanned or copied
someplace, and it'll get attended somewhere where you can go
visualize it. If it's scanned in, it loses all of its structure,
and then it requires optical character recognition and very messed
up tables to try to make sense.
So if you think about it, like what we want to do with that data,
how can we automatically run clinical quality measures for colon
cancer without having a place for KRAS gene test results? That's
already in all the quality measures. If an oncology practice is
running Molecular Tumor Board, how can they do that with reading
off of this piece of paper? They need the files to really run that
activity. And the same thing is true for identifying patients who
are eligible for a clinical trial, increasingly based on a
molecular variant result.
So we can do that to some extent. We can do all these things, but
we really can't scale precision oncology with these kinds of
limitations. So I think a common theme across CancerLinQ and other
entities that are trying to aggregate data and especially to
combine it with the rich phenotypic data in electronic health
records, the molecular diagnostics laboratory should routinely make
these results available to the ordering clinicians as structured
data files. It may be difficult for them to maintain it themselves.
The electronic health record really should have a place for this,
which with mCODE, that will definitely be a part of mCODE.
Where do we go from here? How do we get from where we are today to
the world where all this information is easily shareable across
EHRs?
The technical challenges there, but really it's about collaboration
and having a will to solve this across the entire ecosystem. So we
have created an organization called the Oncology Leadership
Council. So CancerLinQ's Oncology Leadership Council includes
corporate nonprofit and government collaborators and, for example,
the American Society for Radiation Oncology, National Cancer
Institute, FDA, the Cancer Informatics for Cancer Centers, Ci4CC,
AstraZeneca, College American Pathologists, American College of
Medical Genetics and Genomics, and many others.
Now ASCO doesn't think that this is something that we could or
should solve alone. This really means helping the entire oncology
community to improve care by solving the problem at the source. And
that means capture all of the important oncology data as
structured, computable information. And we have to do this without
imposing any more documentation burdens on physicians. And frankly,
we shouldn't really be hiring an army of data entry clerks to do
this either.
I like to think about call to action. What can people do, given the
situation? So I would like the listeners to know that the Office
for the National Coordinator for Health IT is right now soliciting
comments on what they call the strategy on reducing regulatory and
administrative burden relating to the use of health IT and EHRs. So
ASCO is currently preparing comments, and you'll have a chance to
review and provide feedback. And I also wanted to let listeners
know that you can also participate in the writing of comments,
which is going on by the American Medical Informatics Association,
AMIA. The comments are due soon, on January 28, 2019, but input
would be very valuable.
I'd also like to mention that CancerLinQ is concerned about
information blocking. And as I mentioned before, information
blocking is prohibited by ONC. And lastly, I can't resist inviting
people, that if you're interested in joining CancerLinQ, please
contact us.
Excellent. I think that was a good idea to put that message out
there. And I will also put the plug in that joining CancerLinQ is
actually free of cost to get this wonderful resource.
You bet.
Dr. Rubinstein, thank you so much for talking with me today.
Thank you, it's a great opportunity and a real pleasure.
And I also want to thank our listeners out there who joined us for
this podcast. The full text of Dr. Rubinstein's paper,
"CancerLinQ-- Cutting the Gordian Knot of Interoperability," is
available online now at ASCOpubs.org, backslash journal, backslash
JOP in the January 2019 issue. This is Dr. Nate Pennell for the
Journal of Oncology Practice signing off.