Nov 26, 2019
CancerLinQ Medical Director Dr. Robert Miller discusses how ASCO’s new initative, mCODE (Minimal Common Oncology Data Elements), will help take the oncology community one step further to achieving interoperability in electronic health record systems.
In the latest AiA podcast with host ASCO CEO Dr. Clifford Hudis, Dr. Miller says that doctors are expected by their patients to have all their relevant medical information to ensure they receive the highest quality cancer care. mCODE is working to encourage vendors to adopt a consistent set of data elements in their EHR platforms to achieve that goal.
If you like what you hear from the ASCO podcast, please let us know. Take our listener survey and help shape the future of the ASCO Podcast Network. Visit podcast.asco.org and click on the survey link. Once again, that's podcast.asco.org. The survey will just take a few minutes to complete and will help us get to know you better. Thank you so much for listening.
The purpose of this podcast is to educate and to inform. This is not a substitute for professional medical care and is not intended for use in the diagnosis or treatment of individual conditions. Guests on this podcast express their own opinions, experience, and conclusions. The mention of any product, service, organization, activity, or therapy should not be construed as an ASCO endorsement.
Welcome to this ASCO in Action Podcast, brought to you by the ASCO Podcast Network. This is a collection of nine programs covering a wide range of educational and scientific content and offering enriching insights into the world of cancer care. You can find all of ASCO podcasts, including this one, at podcast.asco.org. The ASCO in Action Podcast is ASCO's podcast series that explores policy and practice issues that impact oncologists, the entire cancer care delivery team, and the individuals we care for-- people with cancer.
My name is Clifford Hudis, and I am the CEO of ASCO, as well as the host of the ASCO in Action Podcast series. For today's podcast, I am delighted to have as my guest Dr. Robert Miller. Dr. Miller is the medical director of ASCO's CancerLinQ initiative. And as many of our listeners know, CancerLinQ is a big data technology initiative that collects and analyzes real world cancer care data from multiple health care IT systems seeking to deliver insights to physicians, improve quality of patient care, and support new research.
What our listeners may be less familiar with is that, earlier this year, ASCO and CancerLinQ announced a very exciting collaboration that has the potential of bringing the oncology community one step closer to our goal of achieving interoperability amongst electronic health record systems. The project is called mCODE. That's a lowercase m and then capital C-O-D-E. It stands for Minimal Common Oncology Data Elements, or mCODE.
Dr. Miller is going to tell us a whole lot more about this important initiative. And I welcome you. Thanks for joining us, Dr. Miller.
Thanks for having me.
So, we've all heard about the inability of electronic health record systems to share information with each other. And I always, at the beginning of this, used to talk about my favorite proverbial story. A patient is discharged from a big-city emergency room after a month in the hospital. That hospital uses a single electronic record system, all the details are there. The person is on their way home and developed chest pain, ends up in a neighboring emergency room a mile away. And in most cases, how much of their record from the hospital where they spent a month, to the hospital where they're finding themselves in the emergency room, is transmittable at that moment?
Yeah, I think that's an important question. And that's an example that I think we all have had experience with ourselves personally in health care, or their families. And it's easy to say, well, that's because the systems don't talk to each other. To answer your question specifically, it's probably a small percentage, a minority. There are certain laboratory values and other things that may make it across, but a lot of the important information is missing. And it's just not easy to get.
Well, if they're in different health care systems, and even sometimes if they have the same health record system installed, sometimes there's essentially no real transmission possible. And I mention that only because I think outside of medicine, people who are less familiar with this expect this to work like banking or airline reservations. They expect transmittal of the entire package of relevant information at that moment's notice. And unfortunately, sadly, in modern medicine, and indeed in oncology, we don't yet have this. And I'll just close this little editorial soliloquy by pointing out that Congress thought they were supporting the development of this when they passed HARP legislation more than a decade ago. But in fact, the reality isn't that. And that is the setup for what we're really going to talk about now, isn't it? Which is how mCODE can help fix this problem.
So, tell us a little more now that we've set up the problem. How is mCODE able to begin to address this issue?
So, I think it's important to realize that while all medical care is complex, there's a certain level of complexity in oncology given the explosive growth in knowledge and a lot of the new therapies even in the last five to 10 years. But I think what is really underlying the source of the problem is the fact that so many of the important parts of the cancer patient journey are just not entered into electronic records in a way that they can be easily retrieved.
So what I mean by that is things like measuring the cancer stage, or the basic biomarkers, or in the pathology report, or in the blood, and certainly more abstract concepts like, is the cancer growing or not, is the patient getting worse, or are they getting better, and so forth. The outcomes, the adverse events, are put in the electronic record in a variety of incompatible ways.
And that's not really through, necessarily, anyone's fault or the way things were designed. It's because the electronic record today looks very much like the paper record of yore. And largely, this type of information is captured in what we call an unstructured note, or a document, so that the clinician either dictates, or types, or just puts in text that tells a story. And that's important to tell the story, but it's not easy for a computer to retrieve that information.
And the real point is, at scale, you can't take 1,000 patients and consolidate some of the basics into a single file that you could then interpret, right?
That's right. The problem is that you can try. You can take human beings--we call this abstraction, or curation--and you can pull out the data elements from the notes and from the stories, but that doesn't scale. It's incredibly expensive, and it's also very inaccurate.
Obviously, there's a very big problem here. Tell us a little bit about how this actually came to be.
The mCODE project started last year in 2018, and there was the alignment of a number of individual work streams. So, let me just say that, as background, ASCO had already been active in the area of data standards going back a number of years. They worked with the standards organization called HL7.
If you look at the QOPI program, that's a quality registry that has to capture data, at least in certain fields. And one of the volunteer work groups at ASCO, the Informatics Task Force, was looking at the idea of a minimal data element. And of course, CancerLinQ--which you mentioned earlier--is a big data initiative that has to bring in cancer data in a certain way.
I think this really didn't align until the middle of 2018, and that was--I will give credit to the leadership of Dr. Monica Bertagnolli, who was ASCO President at the time. She also continues to hold the position of Chair of the Alliance for Clinical Trials. And her theme at the ASCO annual meeting, as we all remember, was caring for every patient, learning from every patient.
So that really, in a way, is a data problem. It basically says that if you really want to learn from every patient, from their information, from the data that's in the electronic record, you have to be able to retrieve it. ASCO, under Dr. Bertagnolli's leadership, together with the organization MITRE-- MITRE is a not-for-profit. It's what's called an FFRDC, or a Federally Funded Research and Development Center.
They were already working on something they called the Standard Health Record, or SHR, and they were trying to use modern data standards to improve the quality and the capture of electronic data. They weren't necessarily focusing on cancer, but there was this alignment in 2018. This was all built on a standard called FHIR, which is an acronym for F-H-I-R, which stands for Fast Health Interoperability Resources, or FHIR.
ASCO convened a group of experts in the summer of 2018 to try to create a minimal data standard to provide structured oncology data for electronic health records. So, this was ASCO volunteers and all the clinical oncology specialties, it was other scientists. It involved experts in standards, and quality, and policy, and so forth. The group met over a series of face-to-face meetings, and phone calls, and WebExes. We brought in experts from industry, as well, from electronic health records for their advice.
And the group created a data standard, or a data specification, saying these were the important data elements. They were open to public comments in January of 2019, and ultimately were approved by the mCODE executive committee, and announced publicly on June 1, 2019.
So, when you describe mCODE right now, it's clearly centering on some core set of data, not all data elements. Can you talk a little bit about which elements are actually being captured with mCODE? And maybe for listeners, describe in a very practical way how a clinician experiences mCODE. How does it get into their workflow, for example?
Sure. So, the mCODE data specification is designed around six different domains that describe the cancer patient journey. The first is the patient, which is the demographic and other clinical characteristics--the disease, which are our specific details around the cancer.
The third is genomics, because we knew that molecular characteristics of the cancer are so important for determining certain types of therapy. And largely, this is an area of real need.
The fourth was the labs and the vital signs, the fifth was the treatment. And that could be surgery, radiation, and other drug treatments--chemotherapy, immunotherapy, and so forth.
And finally, the outcomes. Again, this would be the cancer status of the patient--is the cancer better, worse, in remission or not--and ultimately, what the patient's survival is.
The way the user experiences mCODE, if you will, is it's really within their normal workflow of capturing the patient record in the EHR. So, we're not totally there yet, but the anticipation is that the electronic systems of today, the EHRs that are being used, will embed these data elements within their core systems that are exposed to oncologists. And basically, the oncologists will--they may have to enter some information manually at the time of the visit, but our hope is, really, that that's minimal, because I think that there are plenty of things that are already in other electronic systems like pathology and laboratory that simply don't need to be repeated by a human being.
How specifically will mCODE get that patient's age, or that patient's stage, or the biomarkers, or the disease status, into the more structured format that you describe?
So, I think there's going to be a few ways that we're going to see this. And I'll be honest and say some of this is still being worked out. Some of these details, we're working with the HR vendors to understand exactly where the needs are.
I will say that, of the various companies that we've talked to, most of them already have somewhere in their systems all of the data that we need--those six data elements and those domains that I described. That already exists, it's just not organized very well.
So, I think it's going to be a combination of these elements that are going to be carried forth from somewhere else in the system that may be entered, like an age, that you don't need to enter a birth date more than once. In fact, a human being probably doesn't need to enter a birth date. That's already captured some way. And then that populates the clinician note, but then the clinician is probably going to have to enter certain key things.
For example, the current disease status--is the patient alive with disease, do they have no evidence of disease, and so forth. There's going to be some, if you will, burden of entry on the doctor, but that's the part we're trying to minimize so that it, at the end of the day, doesn't add to the workload at the time of the visit.
I remember Dr. Bertagnolli demonstrating at some point what looked to me, as an outsider, like macros. They were essentially dropdowns, where if you put a certain phrase in, you would get the right terminology inserted, maybe with hashtags so that then it could be picked out and structured. Is that a key part of this or is that unrelated?
No, that actually-- that's correct. That is part of what we anticipate some of the implementations will be for mCODE, depending on the EHR type.
One of the things that our colleagues at MITRE-- one of things they're testing is that type of capability. And it is actually a hashtag symbol that you just have to, if you will, know the code. And you enter that into your note, and then the computer finds that. And at the back end, there is going to be a dictionary, or what we might call a lookup table, that pulls that into the mCODE data structure.
The other thing that I want to emphasize is that while it's certainly not revolutionary to think that you need to capture a patient age or a basic biomarker status of their cancer, one thing that mCODE is bringing to the table is the fact that we are strictly defining and requiring specific vocabularies and terminologies. So the computer can only understand things if it's coded in a certain way.
So, within mCODE, and really within the entire electronic record, if we constrain the use of certain lists of variables in defined terminologies, that's going to make the computers able to talk to each other. And that really goes back to your initial scenario of the one-month hospitalization and only being able to find a certain amount. If you used a terminology that one computer could understand from another, then you're not going to have that problem.
I got it. So we've come, in a way, full circle from talking about the big problem qualitatively--talking about what we need, which is structured data--and then describing a specific pathway to make it easy for clinicians to record data in a way that a computer can then read, in a sense, and restructure.
And then that delivers both interoperability on the one hand, but that has critical downstream consequences for our community. It means, ultimately, that quality measures might be more easily fired, and tested, and reported. And it might, of course, mean that that research of various types is much more easy to assemble. Is that right?
That's exactly right, and I think that that was one of the main motivations of trying to do this in the first place, was to be able to reuse the data in other ways. So, if you think about it, the electronic record is primarily a transactional tool. It's what treating clinicians used to document their care. Of course, it's used for billing purposes, and for compliance documentation, and so forth, but it could be used for so much more, right.
It could be used to aggregate. The data could be aggregated, and then those data could be used to run queries on large populations. You can't do this unless you know you're looking at--you're comparing apples to apples, basically. And that's why this basic data standard--again, as simplistic as the opening gambit is--I think, will make a big difference for secondary research, for quality improvement, public health reporting, all those things. Yes.
Yeah, I have to say when electronic record systems first rolled out in my career, one of the promises was it would automate the billing, because after all, over or under coding are issues that concern clinicians. And one would think that an accurate medical record system would essentially be able to automate the generation of a bill that was accurate because it reflected what was in the chart. So that seems, to me, to be at least eventually one of the deliverables in all of this.
And I don't think it's that hard to do. It really isn't rocket science, that part of it. But I think we're focusing now on the clinical and quality improvement aspects. I think that's going to come with it, and that'll be a big advance.
So, lots of people have lots of great ideas for things we should do in medicine, but I think the critical step for all of us is converting these ideas and even these theoretical advances into practical ones. And to do that, we have to begin to pilot and to test them.
I understand--I know Monica Bertagnolli has spoken a good bit about this--that there are clinical trials within, I think, the Alliance and beyond, and practices that are piloting mCODE. Can you tell us a little bit about the status of those pilots, where we are?
Yes. There are two main programs that are piloting mCODE right now. The first one that Dr. Bertagnolli is, in part, running and participating in is something called the ICAREdata study. This is through the Alliance for Clinical Trials, and the first part of this is actually already complete.
This was some work done at the Dana-Farber Cancer Institute, a few other centers. I believe it was St. Joseph's in Michigan, ThedaCare in Wisconsin, a few others. And they looked at, specifically, two breast cancer trials. They basically looked to see if you could capture critical data elements from the EHR that you needed as part of that trial. That was basically the proof of principle.
The more interesting part with ICAREdata is opening soon. Again, it's some of those same institutions, and they're looking to see if mCODE could look for two very specific questions. The first is, what is the patient's current cancer disease status? Now again, that sounds very obvious, but it's not an element that is typically captured in discrete fashion in the EHR. It's sort of put into clinical notes with a lot of flowery prose and so forth. So, the question is, if you define it in mCODE using a specific terminology, can you pull it out of the EHR and make it work in a clinical trial setting?
The second is another very important thing. Again, I'm sure you'll recognize that it doesn't always get written down right--is what is the reason for a change in the cancer treatment? The idea of testing in the ICAREdata study is to look to see if you can answer that question using mCODE. That's the first program.
The second is something that ASCO has been quite involved with--Intermountain Healthcare. This is an institution that participates in the CancerLinQ initiative. They have been great collaborators, and they're actually piloting mCODE, looking at building something called a SMART on FHIR application. So that is something that our colleagues at MITRE have built.
And basically, all that really is a small piece of software that gets plugged into the electronic health record at Intermountain. And really, this could be done anywhere once the prototype's fully done. And it basically queries the Intermountain electronic health record for a specific set of patient characteristics.
And then we've actually built an application programming interface with CancerLinQ, so you can go back to the CancerLinQ database and pull out a cohort of de-identified patients to find something that's called Patient Like This, or Cohort Builder. But this is the Compass app, and this is undergoing beta testing at Intermountain right now. The beta part is actually done, and we're looking for the next steps.
So that's a start. And that means that--I wouldn't say if mCODE's quite in the wild yet, but maybe it's near release, right?
And so, what do you think happens next? Can anybody decide they want to participate in mCODE, support its development, and contribute to it? Is it ultimately envisioned as a free add-on for any electronic record system, or would you have to pay to use it? What's going to happen here?
So right now, the mCODE data specification is freely available on the mCODE website--which I'll say this a few times, but it's www.mcodeinitiative--one word--.org. This can be downloaded. There is no cost for mCODE. All of the terminologies and all the components of mCODE are non-proprietary. It's released in what's called a Creative Commons Zero license, and it really is open to all. ASCO, MITRE, and others are looking to build a coalition of cancer centers, of interested electronic health record vendor companies, and other technology companies, frankly, to support this.
We're kind of in the coalition building phase right now, in the sense that we recognize we also have to bring the oncology clinical community, and ultimately the research community, around to say that this is important, to say that we can't continue our current use of the electronic records and documentation tools. We have to standardize it more. There will be a part for treating clinicians to play. There will be a bigger part, I believe, for vendors to play.
And speaking of vendors, I have to say there are a lot of vendors in the US. In fact, some people think that's part of the problem that we're facing. They have different platforms. They capture, I guess, largely overlapping data, but not always identically coded. And you and I will remember--I can't remember precisely the number--but two plus years ago, we found that there were more than 60 different ways that the term white blood cell was recorded, right?
Right, right. Or smoking status, white blood cell--many ways to say it.
It seems very obvious, I think, to the outside world, that recording data in a single standard way would lower the cost of interoperability and potentially improve quality of care. So that leads to the question, what do you think is the prospect of the vendors adopting these standards, and what can we do in ASCO to encourage that adoption?
So, the electronic health record vendor community has been very supportive of this initiative. They have been part of some of our early conversations. As I mentioned, they were part of some of our early discussions when we built the specification. Most of them provided very robust comments. The MITRE organization had a cancer data summit which was held in the DC area last month.
So bottom line is they are interested in this. They have told us in our one-on-one conversations they want to contribute, they want to see this specification used. They seem willing to set aside competitive interests to do this because they recognize that this is the right thing to do. Fingers crossed; I think we may be at a moment in time where there will be some alignment around this standard. But again, I'm actually pretty optimistic that the EHR vendors are going to come along with this.
Well, I think that's really great. It's nice to hear. To the outsider, it reminds me a little bit of what I understand to be the way that other standards in IT have evolved, like USB sticks. You can stick a USB thumb drive into any computer. It doesn't matter in the operating system at this point, or hardware. It will be read. And the reason, of course, is that the manufacturers came together and agreed upon universal standards. Is this analogous, do you think?
I think to some extent. I guess one of the things that was most eye-opening for me when I first started in informatics about 10, 12 years ago, was that a lot of these standards are voluntary. It's not like the government says, for things like health IT, that you have to use certain things.
Now let me just clarify, that is perhaps changing with some recent regulations from CMS. But I think when it comes to electronic health records, these standards are voluntary. That's why voluntary organizations like HL7 exist.
So yes, they're voluntary, but that also gives you flexibility for a group of vendors under, hopefully, the pressure in the leadership of ASCO and the rest of the mCODE group to agree to adopt these standards.
So, I have a couple questions that I think will build very nicely on the last point that you made. First is about the data set. How do you envision it evolving over time? Obviously, we're not suggesting that we'll just launch this and that's it--it's one-and-done. Quite the opposite, right? So, is there a system to expand it, a formal way to decide where to put our priorities going forward?
Yes, so that is built into the mCODE governance structure. First of all, the priorities can come from anywhere. There is an advisory council that we are forming of interested parties across the ecosystem. There is a technical group that's part of the mCODE governance that's called the TRG--or Technical Review Group--that will receive these proposed use cases from the community. And we fully expect that we will be building out extensions or supplements to the primary mCODE specification as it exists today.
Right now, mCODE is the six domains that I mentioned earlier. It's a total of 73 data elements, but that's going to grow. Now whether we add data elements to the core or whether there are always supplements remains to be seen, but we recognize that the minimal core set is not going to support the complete nuance and complexities of multidisciplinary cancer care. S,o it has to grow, but the governance has built that in. And we are actively looking for input from the community for that.
So, thinking about where we are today, we're about two years really into this project. And admitting that others and ASCO have tried to establish informatics standards in the past, what do you think at this juncture not just makes mCODE different, but makes it more likely than prior efforts at standardization to succeed?
So, I think there's several things. Let me just go through those quickly. I think in the past, exchange standards were purposefully left very flexible so that each vendor could--they would have to follow a very high-level broad standard, but they could customize any way that they wanted. And that led to some of the Tower of Babel that we have today, OK.
So, mCODE really is--we're specifically trying to standardize the health data itself. It's not just about how the two systems talk to each other--to the earlier example--it's that these are the ways to describe the patient journey, the genomics, the labs, and so forth. So that's different.
I think the other thing that's different, I mentioned earlier, is the use of the standard called FHIR, that this is probably the most important data standard in the world today in health care. It's very flexible. It's built on the modern structure of the world wide web, and it can be complemented with what are called APIs--Application Programming Interfaces. So, in a way, exchanging data may be as simple as the way it works when you go to a website now, and that's different than the way it was done maybe 10 years ago.
The two other things quickly: one is that--we've already kind of alluded to this--there's a lot of stakeholders involved. We have the vendor community involved early. This isn't just an ASCO initiative, it's not just a project of a professional medical society. We have MITRE as an FFRDC and others on board. And I think that's different.
And finally--and this may be the most important, I'll just say--is that we're actually bringing this mCODE standard through the HL7 formal recognition process--something called balloting. So the mCODE standard has now been tentatively approved by HL7 as what's called an STU--Standard for Trial Use--which means that it just gives it a little more gravity in terms of the EHR vendors, that it's not something that's not going to be supported going forward. We've built this out, and then others can use it. So, I think that's an enormous difference from what we did previously.
I have to say, it's been really interesting to me to watch this bubble up from the volunteer leadership of ASCO, because Dr. Bertagnolli had a clear vision for this. She brought it to ASCO, she leveraged in a very productive way, I think, the inherent skills and talents of the group that you're leading, and the rest of CancerLinQ for that matter. And I think it's a fascinating--and, I would say, beyond clearly needed--it's desperately needed. And I think it's critically important for all of us that this succeed.
I'm very, very proud that ASCO has been able to play such a critical role in developing this, in supporting Dr. Bertagnolli's vision, which I think was absolutely critical to this being launched. I want to thank you for all--not just for this great interview and clarifying all this for our listeners, but also for the long hours you've put into this project already, leading this from internally. And I think it's going to be exciting to see where it goes.
I think you said this before, there's a special website. But if listeners want to learn more, what is that address again?
It's www.mcodeinitiative.org. You can download the data specification there. There's some background material and links to other things.
And just at the risk of opening up another thread in this conversation, is there anything that we should have mentioned that I've neglected to ask about here?
I think the only thing I'd say is that this isn't just a dry topic of data standards, and computers, and EHRs, etc. This is really about what our patients expect from us. They--when we go in to see the physician, certainly when someone is in the stress of an oncology visit--they expect their doctor to have all the information. They expect their physician to be able to query what was in the EHR from across the street, or even what the last 10 cases like them would be. And it's not something that is over and above. This is fundamental to what medicine is.
And the other thing we've seen, certainly, is that our patients are--and many of them are altruistically motivated to share their own data. And this gives them another way to do this. If we can define their cancer journey in a standard way so that we can group like with like, then there are new insights that can be gained that we just can't do right now. And I think the mCODE initiative will help enable this.
And Bob, I really want to thank you, again, both for all the work on this, and for joining me for today for this ASCO in Action Podcast. We look forward to continuing to hear more and more about the progress of mCODE as it’s refined and deployed more broadly.
For everybody listening, I want to remind you that if you enjoyed what you've heard here today, don't forget to give us a rating or a review on Apple Podcasts or wherever you listen. And while you're there, be sure to subscribe so you never miss an episode.
The ASCO in Action Podcast is just one of ASCO's many podcasts, and you can find all of the shows at podcast.asco.org. Until next time, thank you very much for listening to this ASCO in Action Podcast.