I’m Charlie Harp, and this is the Informonster Podcast. Today on the Informonster Podcast, I’m going to be talking to folks from MITRE who are working with the mCODE Initiative. And with me today, I have Steve Bratt, Carmela Couderc, Carol McCumber from Clinical Architecture, and Shaun Shakib from Clinical Architecture. So why don’t we start with some introductions? Uh, Carol?

Hi! Carol Macumber. I am the EVP of Client Services, in my role I lead Client Success and Professional Services. I also wear a hat at HL7 officially as a Vocab Co-chair and the Vice Chair of the HL7 Terminology Authority.

Shaun?

Hi, I’m Shaun Shakib. I’m the Chief Informatics Officer with Clinical Architecture.

And now our honored guests. Steve?

Hi, it’s a pleasure to be here. My name is Steve Bratt. I lead MITRE’s Health Standards and Interoperability Group, and also my HL7 hat is Program Manager for the FHIR Accelerator called CodeX, which we’ll be talking about a little bit later today.

And Carmella?

Hi, my name is Carmela Couderc, and I’m an informaticist working with Steve in the Health Standards and Interoperability Group at MITRE. I have a long career working with EHR vendors and terminology vendors, and I also have an HL7 hat. I’m a Co-chair of the Vocab Work Group along with Carol.

Well, I really appreciate everybody taking the time today. And as I mentioned before, the objective of the Informonster Podcast is to inform the healthcare IT community about things that are happening, and I thought one of the things that’d be really great is to kinda do a quick overview of how CodeX and mCODE came about, what’s the objective, and kind of the history behind it.

First, I should tell you a little bit about MITRE because not everyone knows us, I think the people at HL7 probably do, but MITRE is a not-for-profit. We work only in the public interest, and we run seven federally funded research and development centers, and these are governed actually by federal regulations. There are certain things we can do and can’t do: We can’t compete with other organizations, we can only work in the public interests, we don’t sell products, we’re not consultants. But we do do advanced research for the government, advanced prototyping, we work on things like standards, which we’ll talk about today, and also we help with government policy, including in the health space and procurements and things like that. But our department that Carmela and I are in focuses on, it’s called Open Health Services. And we really do focus on prototyping advanced ideas, and that’s a lead up to where mCODE came from. It’s, for everyone’s information, mCODE is the minimal common oncology data elements. So we’ll talk more about that. But it all started five years ago when there was an idea of creating or prototyping a standard health record for patients, and this would cut across all of health. It’d be longitudinal, from birth to death, including family history as well. And some of that work has started on that back about five years ago. And at some point, probably in 2017, 2018, I said, “This is just too, too big a problem to bite off”. So we decided to focus in the cancer space, originally on breast cancer staging, but then we decided, “Let’s look at cancer, and can we get… Is our interest in the community on a minimal, say less than a hundred data element standard, um, that’s FHIR based, that would be where the, those data elements were useful for patient care and research across a wide range of envisaged use cases.” So that’s where mCODE kind of came out, and another thing that MITRE likes to do is convene and bring together the right parties to make sure we’re successful. We were quite fortunate early on to partner with the American Society of Clinical Oncology, or ASCO, and their president at the time, Monica Bertagnolli, who’s also an oncologist at Brigham and Women and Dana-Farber in the Boston area, was good friends with our CTO at MITRE, who’s Jay Schnitzer. And he’s also a medical doctor, which is quite interesting for an organization like ours. So, they got together to start talking a little bit about what we might be able to do together, and so ASCO was one of our first proponents, and they have a huge community of 50,000 oncologists, and they were able to muster a lot of interest in this idea of a minimal common oncology data element set early on. And so that’s where that kind of started, and going back, of course, “Why cancer?” Also, in addition to this fortuitous connection with between Monica Bertagnolli and Jay Schnitzer, cancer is a very serious disease. And research has made a lot of progress on prevention of cancer and also remedies afforded as well, but still it’s the number two killer in the world. Probably 40% of all of us are going to get cancer at some point in our life. It’s also, of course, very expensive, it’s painful, can stay with a person for a long time. And we also know that everyone probably listening to this podcast knows of all the problems of collecting data for anything including cancer. I mean, figure 15, 20 million cancer patients today have their data in some electronic health record system, but almost little of it is structured. What’s structured isn’t standardized even within a health system, and certainly for a patient who may span different providers and health systems, their data can’t be longitudinally analyzed or used for research very easily without a lot of work, a lot of expense, and a lot of time. And we also think that this lack of standardized data for cancer care has other implications. (There’s) A lot of focus now on health equity, and we know in places in the United States, for example, the level of breast cancer mortality, for example, Mississippi river area is about three times the mortality rate in places like Boston or California. So care and the costs of care can vary a lot, so we believe also that by having more standardized patient data, not only can patients be cared for better on average, but also especially in areas where health equity is lacking. So feel free to stop me if you’d like, just a couple other things about mCODE. So we, of course, are focusing on FHIR, FHIR implementation guides. That’s why we will talk about the CodeX FHIR accelerator, I guess, later. That’s also been something MITRE has been involved with for a long time. And we even developed a predecessor standard called HData, which was the first, I guess, restful implementation for sharing health data, and FHIR, I think, drew from that quite a bit. I think we’re working on 20+ implementation guides now, within HL7, where mCODE is certainly one of them. And FHIR is also… We’re fortunate to have chosen that path because of course, federal regulations also leading to the requirement for health systems and payers to have open FHIR APIs for patient data and claims data, that puts us right in the sweet spot of what is being required of health systems as well. So that’s, we’re finding a lot of interest in mCODE. In addition, sort of a side interest, it’s because boy, we can learn more about FHIR implementation too, working with this community. So mCODE is a HL7 FHIR implementation guide, and it set the Standard for Trial Use Level 1, or STU 1. We’re going to be balloting a STU 2. That will be balloted in the may timeframe. It will be sort of freezing the draft work on STU 2, I think, in April 11th, so very exciting. The differences between STU 2 and STU 1 we could talk about if there’s interest, but a lot of it was based on learnings. With this HL7 FHIR accelerator called CodeX, we were able to start using mCODE for real use cases. For example, radiation therapy summaries is something that we have a lot of interest in from some of the [inaudible], radiation oncology societies, and health systems and vendors. And by pulling those experts together in that specific area, radiation treatment, we were able to see some areas where mCODE could use improvement. So those are the kinds of things that we really want to focus on. It is not just theoretical discussions of the standards, but implementing them, learning what works and what doesn’t work, and fixing it with all the parties involved. Before I stop, just, we have a large group of supporters now: Besides ASCO, we also have ASTRO, American Society of Radiation Oncology, CancerLinQ, NIH, FDA. We have about 20+ health systems that we’re working with on one or more of the use cases. We have probably on the order of 10 vendors we’re working with as well. And Epic has already been delivering code that supports the collection of a subset of the mCODE elements; we meet with them weekly. We really invite all, I think, leading vendors to come work with us and be part of this, uh, the work that we’re doing because I think it’s important to have an increasing number of people at the table who feel that there’s a value in mCODE, who are leveraging it to do provide better care and research, lower costs and lower burden. So that’s kind of where mCODE is, and I would like to tell you a little more about the CodeX accelerator too, but I’ll stop there, if there’s any questions.

I really appreciate the overview. It sounds like it’s pretty fascinating. It sounds like you guys have gotten a lot of traction with it. So, if I’m somebody who to date is not really familiar with mCODE, and I’m one of those health systems, one of those EHR vendors, how could they get more involved in what you guys are doing? What’s the best way for them to get more involved in what you’re doing?

Yeah, that’s a good question. It’s hard to put URLs into podcasts, but we certainly have… I think that the best way to learn is through our monthly Community of Practice Call. This is a call where everyone’s invited, there’s no cost to it, there’s no membership, you don’t have to be a CodeX member to be part of it. We meet the last Friday of every month, except for November and December because of the holidays then, and at noon Eastern Time. And if you go to HL7.org/codex, you’ll see a link to our confluence pages and you’ll see Community of Practice featured there as well, and you can click “register” for the call. You’ll get all the call information. The next one is the 26th of March, and then there’ll be one at the end of April. We always have really great speakers. Quite often, almost always they’re speakers from the community who are saying, “Here’s what I’m doing with mCODE, and here’s the challenges I’m having, or here’s the successes we’re having. And here’s what we’d like to work with,” inviting other people to work with them. It’s really exciting to see this uptake in interest in what we’re doing. The Community of Practice is a good way… If you go to the confluence page again, there’s a whole bunch of information about all the use cases we’re working on in CodeX, there’s a link to the mCODE implementation guide itself. You’ll also be able to see from the implementation guide that draft that’s coming out for STU 2, so you can get a lot of information there. You can also always contact Carmela or contact me for more information.

That’s absolutely true. I spent some time the last couple of days on your confluence pages. There’s a lot of great information out there, and we’ll, I believe we can publish URLs when we publish the podcast. So if you’re listening to this and you want to find the URLs, we’ll make sure we have good ones there that are available to you. I don’t know if Shaun, Carol, or Carmela have anything else to say about mCODE before we move on to CodeX?

No, I guess maybe it’s a softball question that will lead to CodeX. You know, Steve, you’ve been, you know, helping lead within the HL7 community for quite a long time. (Um, you know, Carmela and I have been around, you know, a decade here even.) What do you think it was, you know, about FHIR that made it possible for the accelerator program to really emerge as a powerful asset within the HL7 community to really accelerate things like CodeX and CARIN and Gravity and Da Vinci, and I’m sure I’m forgetting some of them? But it’s something that stands out as being unique to FHIR as a standard in comparison to some of the other HL7 standards of the past.

Yeah, it’s a good question. And it’s not a softball question because I don’t think it’s that simple. I’ve been in the standards world for a long time. I’ve only been in health standards for a short part of my career. I was the first CEO of the World Wide Web Consortium. I’ve been involved in arms control standards, logistical standards. I’ve seen kind of how these things work, and you all know that’s not always the best technical or clinical solution that’s adopted; it’s the one that the community gets around. And I think FHIR had, for all the challenges that this poses, I think that the concept of being able to make something that’s very implementable, that’s very developer friendly is important. Them also focusing on core things, their 80/20 principle and so on, which for people in this terminology world, it probably creates a lot of challenges as well, but it lowers the bar for entry. And that’s where the accelerators come in too because we can we can work together with the other accelerators who are working on social determinants of health, or who are working on research, or prior authorization, or other other areas. And we can work together to try to ensure that our different focuses are interoperable with each other because when it comes down to it, it’s one patient. They have cancer, they’re part of a research trial, their social determinants are having a huge impact on their health, (but) it’s still a person. And so we want to make sure these things are interoperable, and I think that FHIR accelerator community is one place where that happens on the ground. You know, when you’re really implementing stuff, you’re building software, you’re building reference implementations, you’re testing and piloting. In addition, it sort of supplements the traditional work of HL7, working on at the standards level allows you to really kick the tires and test it out as well in the accelerator world. It’s interesting how I think this has all come together. The focus on FHIR, I think also the increased appreciation of health systems and researchers on standards and how that could really help facilitate their work, reduce the friction in the system of sharing data and leveraging data. I think as a result, the vendors are responding, too, to their customers, whether the customers are health systems, or registries, or other kinds of pharmaceutical companies for the need of appreciation for standards, and FHIR’s kind of in the right place at the right time as a framework for sharing that’s got a low, low burden for implementation, relatively. That’s my opinion though. I know it’s not softball question. It’s a really good question. It’s a tough question. I’m sure others on the call have other opinions about that.

Thanks, Steve. Do you want to talk a little bit more about CodeX?

Yeah, I could. We mentioned it so many times up until now. So CodeX is an HL7 FHIR accelerator. I believe there’s six of them now, and we were the third, or second or third one in, and we focus on creating a community that’s really interested in implementation of mCODE and extensions to mCODE to help address and improve cancer care and research. And CodeX stands for the Common Oncology Data Elements Extensions, where extensions doesn’t mean the traditional FHIR extensions. That really just means supplements, I’d say it’d be a better word for it. Supplemental data elements that may not be, maybe, very specific to some element of the cancer space because we want to keep mCODE small. We want to keep mCODE stable and relatively small. I’m hoping, um, if we can get through publishing a STU 2, the Standard for Trial Use 2, this year, maybe we can be normative sometime next year, then vendors have trusted it. They can count on it and then we could have additional implementation guides that leverage CodeX, leverage other standards as well, and create new data elements that are necessary to work on new use cases. So CodeX is a place where we focus on use cases, we focus on development of implementation guides, and implementation of those guides into products, commercial products, open source project products, whatever. We want to help the community, leverage this, to support their customers better. We want the customers to be there at the table too, whether it’s a health system, a registry, or other places. So we do focus on implementation, not just on delivering implementation guides, and on execution. So we have pilots, agile development and short cycles of maybe three or four month phases, could be up to six month phases, and testing, go back and make the fixes that we need to mCODE or other things. And we’ve kind of already seen that with the work that’s going on now to move mCODE into the Standard for Trial Use 2 level. So that’s what we’re doing. The use cases I’ll read off really quickly, that that are active on now: We have one around real-world data trials, this is the most mature one. We’re now in phase two of that one, working with the Alliance for Clinical Trials in Oncology. We’re actually executing three trials now, collecting data in Epic, in mCODE elements and sharing them, collect, aggregating them in a central place to ensure that the data collected out of the HR are complete and of high quality as those that were collected in the case report forms that are traditionally the locus of information collected during trials. Related to that, we have another use case: Integrated trials matching for cancer patients and providers. This tries to help speed the enrollment of patients in trials, and speed the ability for patients to find trials. Again, I can answer questions about any of these things, if there’s interest. Our champion, we call it, there is the American Cancer Society. On cancer registry reporting, the CDC and another private registry called the Center for International Blood and Marrow Transplant Research are our champions there. We’re trying to demonstrate the capability, again, of collecting the data in one place in an EHR, and then sending it to different registries for sometimes very different purposes. Probably should’ve said that from the beginning, that is kind of our common focus is being able to collect the data once in the EHR, any EHR, and share it in a standard way for different use cases. So those use cases are all what we call an execution. That means we’re into phases, we’re building stuff, we’re testing stuff. And we have a couple of others that are in planning stages. So radiation therapy treatment, we’ve got the biggest radiation therapy delivery system vendors, like Varian, and Elekta, and Raysearch, working together to send a standardized report based on mCODE and other elements from their systems into the EHR in a structured way. Right now that’s almost exclusively done with PDFs. So getting this key structure data into the HR, right from these radiation oncology systems. So that’s probably getting close to being an execution, now. We got all the right partners there, including the American Society for Radiation Oncology, ASTRO, the American Association of Physicists in Medicine, who are kind of the brains behind a lot of the radiation work that’s done, AAPM, and all the vendors. That’s great. And then we’re also working on a couple of others: Prior authorization, can we leverage the work that the DaVinci HL7 FHIR accelerator has done, but focus on a very specific cancer use case? Carmela has been very active in that. And also looking at clinical pathways or guidelines and how can we automate that using mCODE and other data? So these are the use cases that are pretty well documented on our website and anyone who’s interested, I’m happy to share more on that.

I mean, it sounds like the things you guys are doing are pretty exciting, and I think that, you know, you said the comment earlier, “Why cancer?” I don’t know that I know anybody who hasn’t been touched by or had somebody near them that’s been affected by cancer. So I think it’s obviously a big issue in healthcare. And I also think that, just like everything else in healthcare, you know, being able to get the data, to organize the data in a consumable, computable way is half the battle. If you can do that, then you can start to do some of the things that we’ve been trying to do in healthcare IT forever. One of the big challenges that I think people struggle with with standards, and it sounds like you guys are doing a really good job to mitigate that, is that, you know, healthcare evolves from the edges. It’s kind of hard to create something, you know, authoritatively, centrally, and say, “This is how everything’s gonna work,” because healthcare is a very living, dynamic, evolving space. And it sounds like, with what you’re doing with codex, you’re involving people to kind of help evolve what you’re doing based upon those things that are happening at the edges. So it sounds like it’s really well situated to have a meaningful impact on where we’re going in addressing this issue in healthcare. So it’s very cool stuff. At the center of anything like this, so, you know, whenever you talk about FHIR, you talk about standards, you’ve kind of got this canonical, you know, standard and the patterns that you establish, and then you have the semantic standards. And so what I would like to do is kind of pivot from, you know, talking about some of the canonical things that are happening and the use case things, and talk about some of the terminological ontological things that you guys are doing and you’re putting together as semantic targets for mCODE. And, uh, I don’t, I don’t know if Carmela, if you’d like to talk a little bit about that?

Hmm. Trying to think where to start there.

Can I ask a leading question to maybe help with that?

Sure.

What is the scope of mCODE? So, you know, as Charlie mentioned, you know, there’s sort of the defining data elements, so there’s sort of some tactical level. These are all the things we care about. And then there’s the, you know, your trials, your [inaudible], the semantic level. So, you know, how do you effectively encode all that data so that it’s interoperable? Um, what is the full scope of mCODE’s efforts there? Is it syntactic and semantic, or are you actually building out terminology, you know, to address the semantic level of interoperability, leveraging existing content? Help us understand that a little better.

mCODE at the beginning was, you know, was trying to define their scope. So that’s a really good question. What they ended up settling on was, um, solid tumor cancers. So the common data elements around cancers that involve tumors. And so, say some elements that might be common for, say, blood cancers are not included in mCODE right now, but that might be considered, say, an extension. If that were a use case that, uh, CodeX prioritized, we would maybe work on what’s required, what kind of data is required to collect for leukemia, versus solid tumor cancers. So that’s one of the scoping issues that they took on. Also, from the get-go they’re trying to use existing code systems where they could, and as you might imagine, there’s some very specific code systems out there that address some of the cancer elements, like staging systems. So there’s different staging systems that exist that are used in different situations. A lot of implementations in this country use the AJCC, so the American Joint Committee on Cancer TNM staging system, which breaks down staging into a characterization of the tumor, whether nodes are involved, and whether, um, there’s mestast… I can’t say that word…. Whether the cancer has metastasized. So they did approach the terminology requirements by trying to find existing code systems out there that were being used by different, maybe professional societies, or registries or, um, cancer applications. Like sometimes there’s specialty EHRs that, are oncology EHRs. So sometimes there was code systems used in those implementations.

So what does, what do you do, as, you know, as mCODE, when you find a gap?

That’s a very good question. I think Steve mentioned that one of our very active use cases is radiation therapy. And we’re looking at SNOMED to record radiation procedure, which is pretty complex when you start breaking it down, in that you might have a general procedure, but then it’s really qualified by two other procedures, which are the modality and the technique. And what we found is that SNOMED, which is the recommended in US Core, now. So mCODE is built with US Core as a base, but SNOMED and CPT are the code systems for (oh and ICD 10 PCS) that are recommended in US Core for procedures. So when we started looking at modality and technique, we realized that SNOMED did not have full coverage, say, for the modality and technique procedures that the subject matter experts felt were really necessary to have. So there was some back and forth in the team and some folks were advocating for, “Well, let’s define a separate code system, all new codes, so that we can just have a complete code system and that’s what we’ll use.” Others did not agree with that approach, and we had some back and forth and really good communication among the team about what approach to take. And we really did a 360 and decided to use SNOMED, and to submit the missing concepts to SNOMED, you know, first you have to submit them to the US Release Center, then they’re considered, and they may go into the international release. And, you know, some of the issues there that some vendors aren’t using SNOMED and they start bringing up licensing issues and, you know, what would it cost to use SNOMED if they operate in countries that are not SNOMED member countries? So this is all these kinds of discussions we had, and you take it into consideration when you’re trying to figure out is the mCODE specification or one of the CodeX specifications going to roll their own and create a code system, or are we going to try to work with the code system stewards and supplement what’s already there?

Yeah, which kind of leads to, you know, I think questions or issues that a lot of people are facing now, you know, with the rapid, with the acceleration of the ability to create things like FHIR IGs and so on, you know, comes along with it, the need to be able to make these decisions about terminology and vocabulary usage within those IGs. You and I have talked about how standards are in some ways having its glory moment. We’ve emerged as some of you who’ve been to the HL7 meetings know that the Vocab Work Group is often off in a corner someplace, in the sub-basement as the trolls that are necessary to, you know, kind of keep the building standing up right, but often troublesome. And we’ve kind of emerged from that position to being the, as Julie James has referred to the HTA sometimes, as Cinderella, you know? As kind of cleaning up and keeping things going, but not ever kind of getting to be in the forefront. Right? But, with that in mind, I mean, you know, a tremendous amount of progress has been made, um, via things like the Unified Terminology Governance Project within HL7 to try to put some structure and process around the maintenance of internal HL7 vocabulary, the Gender Harmony Project that’s looking at finally capturing the difference between sex and gender identity and sex for clinical use in a meaningful way, where HL7 has been able to bring together not only standards development organizations, but international participants, EHR vendors, the radiology folks all together to talk about terminology and how it has a direct impact on the quality of the data and the outcomes for patients. Um, you know, we are seeing a emergence of tools that help within the HL7 community to do validation of things like code system identifiers, make sure people are referencing the versions correctly, and so on. And as you guys have talked about, you know, the FHIR IGs, and in FHIR in general, being referenced in federal mandates. But with that comes comes a different sense of urgency, “A need for speed,” as you’ve coined in other conversations, and that doesn’t necessarily align with the traditional terminology authoring and maintenance process that we’ve been used to, right, as you described. So you identify a concept, if you’re using SNOMED you enter it into, if you’re a member country, you enter it into your national release center process, it has to get reviewed, you get an answer, there’s mitigation about, you know, the definition of things. Then it maybe ends up in your addition, and perhaps it ends up in the core. All of that takes time, and we don’t always have it. I, you know, in my role at the HTA, you know, worked with the CARIN folks to ensure that their code systems were being identified and referenced accurately under a very tight timeline, right? That IG is being referenced in CMS regs. And so they had to get, we had to get it done, and that isn’t always easy. So, you know, I’d be interested to hear from you, and or Steve, you know, kind of, how do you find that sweet spot? Um, you know, what is the sweet spot between being able to efficiently do this and making sure that the right terminology best practices are followed in terms of the creation of that content? How do we get there from here?

I think some of it is to somehow change the mindset, or enhance the mindset of folks who are developing these IGs, uh, to start thinking about terminology and your terminology requirements at the beginning, rather than having it be an afterthought, which it sometimes is, as we’ve seen many times. So, somehow educate the community, and when I say the community, I guess I’m thinking of the HL7 community, the folks outside of HL7 that are developing implementation guides, and have the material prepared to help them understand why it’s important to think about your terminology artifacts at the beginning of your cycle and what’s available there to help you. You know, it’s not a mountain that you have to climb by yourself. There are these groups out there, like HTA, which is the HL7 Terminology Authority, that helps you discover, or URLs code system identifiers for those code systems that are managed by an organization other than HL7, like SNOMED, or LOINC, or some of the new ones we’re coming across in the mCODE code space that we just haven’t… HL7 hasn’t identified yet. And, um, well, not identify. That didn’t sound quite right, but maybe they don’t have a known identifier, an endorsed, or sometimes we use the word “authoritative” identifier provided by the code system owner, like AJCC for the staging system. You know, up to this point, we did not have a communication open with that organization to say, “Well, what would you like to use as your code system identifier? What would you like the community to use?” So I think it’s a kind of a culture change to try, and that’s going to be difficult, especially when a lot of IGs, FHIR IGs, are developed by consulting companies who maybe aren’t, uh, HL7 members, they might not be steeped in the culture of how things are done. Our documentation sometimes isn’t as easy to use as we might like. It’s getting better, Jess Bota created some great YouTube videos on how to use UTG, the Unified Terminology Governance, and their targeted towards whether you’re submitting or you’re doing some other tasks. Soit’s getting there, but I think it’s, um, sometimes it feels a little disjoint how HL7 is approaching it because it’s a big problem space. And it’s, it’s a lot to, it’s a lot to cover.

Uh, Carmela, really good thoughts too. [inaudible] Something they add when you’re done, if you don’t mind?

No, go ahead.

I’m not as steeped in HL7 or in health standards as most of the rest of the people on call are, shouldn’t have been surprising, but it is surprising even within oncology, certain kinds of disciplines have been working in their own silo for a long time. They didn’t have to be interoperable because all you needed is for some care coordinator or oncologist to be able to read a report, and they kind of know how radiologists talk, and how radiation oncologists talk, and how surgical oncologists talk, and they know how pathologists talk. And so we’re putting a new stress on the system that necessary for us all to talk the same language, you know? In the UN, they have six official languages, and they have interpreters that are working really hard to translate it. Even it chain translate from one language to another, to another, and to make that work. And healthcare is a lot more complicated than language, I think in most cases. So even body site was one that came up last week. Radiation oncology, they’ve talked about, “Where are you putting instrument?” And, “From outside of the body, what’s the organ or part of the inside of the body, the mass inside the body that you’re trying to target?” Um, and you need to have a terminology for those locations and some kind of a code system. And they’ve had things like those, too. They’ve developed things like this on their own, but surgery, you also need to know where’s the incision, and where’s the, you know, what are you trying to get at? And I guess every single subdiscipline of health has something about body site as part of it’s vocabulary. So just how do you get people who have spoken their own language for a long time to agree we need a common one? That’s not easy, and we’ll probably end up having to compromise in some short term with mappings and things, but, um, the benefit of working with different disciplines within an accelerator, at least, is you have those people, at least in the same community and there’s an opportunity to see if we can align. And we may find that this case is where we can, but we have to do we have to do our best.

Well, that wraps up Part One of our interview with Carmela Couderc and Steven Bratt from MITRE on mCODE and CodeX. I invite you all to listen in to Part Two, where we’ll get more into some of the complexities and challenges around sharing data across silos in healthcare. I want to say once again, thank you very much for the folks that participated today and thanks to all of you for listening. I am Charlie Harp, and this has been the Informonster Podcast.