CancerLinQ: Cutting the Gordian Knot of ...

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.