Episode 19: mCODE, CodeX and Accelerating Healthcare Innovation – Part 2

This two-part episode of the Informonster Podcast features Steve Bratt and Carmela Couderc from MITRE, along with Charlie Harp, Carol Macumber, and Shaun Shakib.  The group discusses why a community-based approach, while foreign, is so beneficial to the industry, busting the myth that organizations can contribute to the standard without exposing their own secrets.  They also talk about the future of mCode. 

Contact Clinical Architecture

• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com

Thanks for listening!

Transcript

Intro: 0:12

[inaudible]

Charlie Harp: 0:12

I'm Charlie Harp, and this is the Informonster Podcast. This episode of the Informonster Podcast is Part Two of our discussion with the folks from MITRE about the mCODE and CodeX initiatives. Joining me in this second part of that interview is Steven Bratt, Carmela Couderc, Shaun Shakib, and Carol Macumber. In this part, we're talking about some of the complexities, challenges, and benefits of sharing data across the silos in healthcare. I think there's a couple of interesting forces at work, and we struggle against these in healthcare all the time. And one of them is exactly what you said: We we've evolved out of these silos, and so the idea of trying to do something collaboratively is still relatively new in healthcare. The second thing is the idea that as a provider, you know, they want the benefit of having computable data so that I can get real-time artificial experience or knowledge from other places incorporated into my workflow to enlighten me, or make me aware of something I didn't know before. But to make that happen, I have to be part of a system where I'm putting in data that can be shared across the silos. And usually, at least with the way we deal with terminologies today, there's a certain amount of lift that's involved. There's energy needs to be put in to capture the data in a structured way in the first place or in a way that I can easily structure so that I can share it. So, so that we can work collaboratively. And I think the other moving part that I know we struggle with sometimes as a terminology catalyst, if you will, is that a lot of the traditional terminologies and codes and things that we use, at least a handful of them are coming out of a very traditional publisher mindset going from people that are used to writing books, reference books that people would use to practice and turning that into something that you can integrate into a structured, computable environment is another challenge. And also, you know, how that's dealt with from a, from a licensing perspective, there's a lot of confusion about that. And, you know, where somebody is using it, where they're reusing it, how things are being transported. There's a lot of complexity. It's why, when people who sit outside of healthcare, kind of look at healthcare and roll their eyes and say,"Well, how hard could it be?" We all know firsthand how hard it can be because we're dealing with all these competing forces. And it's really almost like pushing that big Boulder up the hill to try to get to the point where we can take take advantage. So I have a great deal of respect for all the things that you guys are working to pull it all together.

Carmela Couderc: 3:08

You know, we've had, um, you know, Steve brought up body site for radiation. Some of the, one of the code systems that's in use, in common use, today is, uh, maintained by the American Association of Physicists in Medicine that Steve brought up before, and it's called TG263. What's interesting. It's so it's available- You can download the spreadsheet for that. And so then I guess people are copying it into their implementations, so that brings up maintenance issues. But when you look at the codes in there, and the names, it turns out that the names or the descriptions for the concepts that you might display, they're really short. And it turns out it's because the vendors that were using them had length limitations on their name. So this gets into the whole thing about reference terminologies versus, say, an interface terminology, and can the clinicians in their workflow use terminology that's familiar to them, but you know, potentially behind the scenes, it's mapped to a standard that's being communicated around that everyone understands?

Charlie Harp: 4:21

Absolutely, its the difference between, kind of the local terminology and the normative terminology can make a big difference. The other thing that is a challenge for us is, and you talked about, you touched on it earlier: We want everybody to take advantage of things. We want to show them the benefit of things. But when we have code systems that are updated on an annual basis or a semi-annual basis, if there's a code you need, and it's not there, and there's not an easy mechanism that allows you to create an extension or create something that you can incorporate into your processes, you can't wait for six months necessarily. And so, you know, we have a lot of those challenges also that, you know, how do we reduce the latency so that we can take advantage of it? Because the problem we have, at least the problem I've seen, you know, I've been doing this as an engineer for 30 years, is the consumers, the providers, the patients, the people in healthcare, you only have so many chances to prove that you're credible and to prove that you can do something useful before they get kind of, they start to stop believing that you can actually do the things you're trying to sell them on because you're saying,"Hey, I'm going to be able to help you in all these crazy ways and be able to shorten, you know, improve patient care and reduce the amount of time and effort." And that's what makes it worthwhile for them to do the additional work that they're going to have to do on their end to make it all happen. And so we've just got to be careful that, you know, we have systems in place where we can actually deliver on, you know, what we're saying, and, you know, that's where, you know, seeing you guys accomplish these things and seeing these things happen, it's good for the entire industry because it kind of shows that if we collaborate, if we have good normative terminologies, if we have good standard ways of communicating with each other, we can actually do some really cool things. And we're not just thinking that we can, we can actually demonstrate that we can, which, you know, the proof of the pudding's in the tasting, they say.

Carmela Couderc: 6:13

Right. And some of that demonstration might be years down the road. You know, when you think about registries and things like that, you know, being able to populate cancer registries in a standard way, it might take a while before we see tremendous benefit from that.

Charlie Harp: 6:31

Of the, one of the questions I was going to ask, Carmela, is, you know, when you look at the different domains that you guys are dealing with an mCODE, I know that there are some domains, you know, and I would've thought body location would be pretty straight forward. And actually, I think I underestimated the complexity of it, but I know there are some domains, when we worked with clients, that we've kind of struggled looking for kind of an authoritative source of information because a lot of these, like genomics, for example, genomic reporting is an area where, you know, I think there's still some, uh, some ambiguity, but are there any areas, domains that you find, you know, more troublesome than others in terms of trying to determine a good authoritative source of terminology?

Carmela Couderc: 7:19

Uh, I think we've been able to find good sources, uh, like the human genome variation society, you know, snowman of course, for the, for the clinical code systems. I think we've been able to find sources. I, it seems to me that the major issue is when a source doesn't cover a hundred percent of your needs. And, you know, I'll go back to SNOMED. SNOMED started, a few years ago, adding a pre coordinating laterality into some of their body sites, but they haven't finished that. And so it's not all of them. And what happens sometimes as people look at them, they say,"Well, gee, they have left leg, but they don't have left, um, pinky fingers, you know, something like that. So we can't use it." So I think that we can find sources, but sometimes we can't find comprehensive sources that, um, fit a hundred percent of the needs. And it's that maybe people just don't know, well, gee, you can contact the steward or the owner of that code system and you can start a dialogue with them, about adding something. Or sometimes you might need to use more than one code system to get what you need, like SNOMED and the NCI's thesaurus. And sometimes people are hesitant to do that, or they're operating under a misconception that you can't define value set where the concepts are drawn from more than one code system. Well, I mean, we had that happen in one of the CodeX use cases and we said,"Well, sure, you can define a value set that way."

Steve Bratt: 9:09

I wonder how much people sometimes don't want to lose ownership of that as well, because when you start taking something, maybe they've been doing in radiology radiation therapy for a long time, and then they say,"Well, we want to entrust this to SNOMED," maybe there's some reluctance to do that. Um, I don't know.

Carol Macumber: 9:30

That mindset, I mean, and part of it is just, you know, um, those of us who are entrenched in the HL7 world, I mean often make, you know, try to make the assumption that the stuff that we're creating is going to be used by someone else. Should be used by someone else. Should be reusable, be defined in a way that people understand what we meant by this, you know, by these codes, and this code system, or this value set. But, uh, you know, as you guys have been talking about, that's not, you know, a native thing for a lot of people. Maybe the answer is, you know, finding a way to make resources within HL7, you know, more available to take some of that work on instead of, you know, kind of relying upon people to have that in-depth understanding because it, it takes a lot of time and experience to get it right sometimes. And the researchers out there, the genomic experts, the, um, you know, the clinicians, you know, they're not, they're not as interested in the gory guts of terminology authoring and maintenance as we are.

Steve Bratt: 10:36

From my perspective, it's the community, you know? It's getting the thought leaders together, the b ig organizations(thought leaders could come from any size organization) because they're key to scaling this up. You know, so I've no doubt we c ould produce a beautiful implementation guide, and it's really critical that we do, and we hopefully the one we have is pretty good. But, it has to be used and adopted, and for that to happen, i t has to provide value, and as it w as mentioned before, it can't induce undue burden, or at least without increasing s ome substantial value for the people who have to collect the data. So, so I t hink t hat to me, it's the community, getting the people together who are going to- are committed to, to run with it. If it was just a MITRE research project, which it started off as, u m, it would be unlikely to succeed. I f we can continue to get more cancer centers saying they w ant i t a nd to contribute their oncology expertise, i f we can get more vendors saying,"Yeah, we want to help you collect this stuff and share it," more recipients of the data, whether it's places like CDC or other registries or pharmaceutical companies, and so on, payers, the more we can get a community around these, what sounds like a wide range of use cases, the bigger the community will be, the more important mCODE will be as a core that will lead to a real value down the road a nd success. So I think that's the key, is c ontinue to build our community. We're doing pretty well after a year, a little over a year of CodeX, and mCODE itself being a little older, but, u m, i t s ets, u h, that's the biggest challenge, I think, honestly.

Shaun Shakib: 12:16

This is kind of a h igh-level question. I mean, what do you guys view has been sort of the single biggest challenge now to either further adoption or, you know, additional work, y ou k now, to fully specify what's in mCODE? What do you view as your single biggest challenge today?

Carmela Couderc: 12:34

Yeah, I guess I've seen a challenge to explain to folks who are new to the space to define a value statement, and also explain the standards process that you can participate as a community member. And you, you don't have to, um, you know, give up any of the special sauce for your company or anything like that. You're contributing to the standard, but you're, you don't have to, um, describe or expose anything that you do that's specific that makes your particular implementation special and valuable to the community. So what we've seen a couple of times when we have meetings with potential community members, and Steve can chime in, is that sometimes the whole idea of participating in a standards organization is foreign to them. And we ha we have to get over that hump.

Steve Bratt: 13:35

One of the things we're trying to do in CodeX, at least as well as is that we don't require everyone in CodeX to be immersed in the HL7 process, because I think part of the value we can provide is, okay, you, you're an oncologist. You're good at oncology. You understand how patients are treated, and what the potential outcomes are from those treatments, and so on. Let's leverage that expertise. We don't need to make you an HL7 process expert. If you want to, that's fine, and we'll give you opportunity to do that. Same with even building implementation guides. We've got some wonderful tools that we've developed, including FHIR shorthand, which is now being used by like a hundred different projects in the HL7 space. But, um, I don't necessarily want every registry to become an expert on building implementation guides, but if they want to, or have some people they want to, they want to get smart on how to do those things, that's also good. And same with terminology or any area. So I think it's another part of the community, I guess, really is bringing together the complimentary expertise- expertises that are needed to succeed as well. Most of the people in CodeX, I would say. Carmela, it is fair to say, are not at all HL7 insiders, but they're getting exposed to HL7, and want it to be a good, you know, a good experience. Part of that will be kind of abstracting the... Making sure they don't have to go through every step of the process themselves, but that we were working together and leveraging their expertise on the right, in the right places.

Charlie Harp: 15:01

So, are there any other questions before we, uh, we look at wrapping things up today? Anything else you guys want to put out there?

Shaun Shakib: 15:10

I guess I'd ask what's the future of mCODE? I mean, what's next, I guess?

Steve Bratt: 15:15

Well, we're hoping to, um... I mentioned the STU 2 b alloting coming up and we'll certainly get some more comments, and hopefully if we're successful, we can freeze that as a STU 2; not just draft, but STU 2, by sometime in the third quarter of the year. We'll see how the comments look. And we have a lot of comments from internally coming in from our CodeX community, even. So t hat's, that's good though. If, I would hope, that at some point we can g o become normative, whether it's o n the next following STU 2 or STU 3, because we want to make something that's relatively stable for the community, especially for v endors t hat count on things to check and changed out from underneath vendors, or providers, or on a monthly basis, some stability. So I'm hoping we have enough experience and good input that we can kind of freeze that, and then it becomes a core that's relatively stable. Then we can build out these other implementation guides for t hese specific use cases. They may include additional data elements and additional profiles, maybe extensions that are not in mCODE. U m, it may turn out there's parts of mCODE that aren't right, but we're not g onna change them because t hey're normative. We'll create some kind of a supplement. So that's all to be seen, how these use cases play out these projects that a re people are working on, a nd real experience. A dream would be that w e got a critical mass of customers asking for mCODE and vendors that are delivering it and that we can help them, a nd we can help them, as a community, go faster. Uh, if that's what they want. I'm really hoping even this year, we'll start, we're starting to touch patients already t oo. And this is where it gets... We t alk a lot about standards and technologies, but already in our, on our r eal-world data project"iCare Data" it's called. We're hoping to have over 1 50 patient encounters for which mCODE data will be collected this year, as part of three trials, or three to six trials, depending i f we get some more at 20 different health systems. We already enrolled six patients in our clinical trials matching pilot for what's called p hase one of the pilot. So they'll start hopefully experimenting with, are they able to find trials that match their needs quicker and faster? Looking at even the user interface, making sure that t hat makes sense, can they get their data out of their EHR into these systems and send off to different matching services and get back some coherent set of matches with goodness o f f it that they can make choices w ith, on their own or with their o ncologist. So that's a really important part of the future is where we're really, we're not just testing and piloting, but we're really improving the care and research for cancer patients.

Carmela Couderc: 18:00

Steve, there's another item that we have started to touch on in mCODE and CodeX, but is the, the fact that right now mCODE is a US realm implementation guide. And there's a lot of interest outside of the US and mCODE. And the fact that the mCODE profiles say for procedure, or cancer patient, some of the observation profiles they're based on a US Core profiles. You know, it's probably something that, um, you know, I don't know if it would be a separate project or whatever, but I can see in mCODE's future, um, moving it more towards the universal realm or having a version of it that is the universal realm versus the US realm. Would you agree with that?

Steve Bratt: 18:50

I would agree with that. I think that's really important. Given all your experience, do you have any idea what kind of effort would be required to do that? To go to the universal realm?

Carmela Couderc: 18:59

Well, I think we'd probably have to do an examination of what restrictions, um, having the US Core profiles as our base be. And one that I can think of in other... It's only in the United States that say race and ethnicity are required for a patient. So, I know at least one of those US Core requires. So, you know, folks, say, in Switzerland would say,"Well, gee, we don't require that for a patient," but since that's one of the mCODE profiles, you know, and technically in FHIR, you can't relax a constraint, you can only add constraints when you build a profile. So, you know, that's one very simple example, but even the staging systems, you know, there's AJCC is that used outside of the US? I don't know, because there's also UICC, which is another staging system, so...[people talk over eachother] Oops, sorry.

Charlie Harp: 20:07

No, that's ok, Carmela. I was gonna say there's also, even if you look at someplace like the NHS in the UK, I mean, they have a different terminology for imaging and radiology procedures over there as well that's pretty actuall pretty robust compared to what we have here in the US. I would imagine that when you go from region to region, there's going to be some, you know, code system variability, and then there's the obvious language situation. When you go outside of SNOMED, or even within SNOMED, there can be some language challenges, but you're right. I mean, cancer is a universal problem. It's not just something we struggle with here in the US.

Steve Bratt: 20:41

As Carmela said, we've had interest in discussions with groups in Brazil, and we have active participation from people in Switzerland, and France, and Germany. Um, so yeah, it could be a really great, great observation though, Carmela. We do need to put that on our agenda for the next year to consider internationalization

Speaker 3: 21:05

Alright. Well, hey, uh, one of the things I wanted to make sure I said is when we first found out about mCODE, I know a lot of folks on my team were really excited to see it. Obviously cancer is a non-trivial issue. And it's the kind of thing where you would think that if we could get good data from across all the silos that we could see patterns that could help us make a meaningful impact on, you know, where we route patients, how we treat patients, and what we can learn about the disease. So, uh, we're really excited to see mCODE. We're really excited to be a part of mCODE, and to support you guys. And we'll have some more information in the links, any last words before we call it?

Steve Bratt: 21:46

Well, thanks for giving us t he opportunity to share what the community is doing, and certainly welcome any of your listeners to contact us. Love to have a conversation about where you might engage. Thanks.

Carmela Couderc: 21:57

Ditto.

Charlie Harp: 21:59

Absolutely. Well, I want to say thank you to Steve, Carmela, and thanks to Carol and Shaun for joining me today on the Informonster Podcast. I really appreciate all the information and, uh, look forward to the next one. Thanks you guys.

Outro: 22:22

[inaudible].