This two-part episode of the Informonster Podcast features Steve Bratt and Carmela Couderc from MITRE, along with Charlie Harp, Carol Macumber (EVP – Client Services at Clinical Architecture), and Shaun Shakib (Chief Informatics Officer at Clinical Architecture). Steve, Health Technology Principle at MITRE, is the Program manager of the Common Oncology Data Elements Extensions (CodeX) HL7 FHIR Accelerator. Carmela, is a Clinical Informaticist at MITRE, working across CodeX use cases. Steve and Carmela take a deep dive into the history and accomplishments of the growing CodeX community that is working together to leverage standardized collection and exchange of oncology data via the minimal Common Oncology Data Elements (mCODE) HL7 FHIR Standard for Trial Use.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
This two-part episode of the Informonster Podcast features Steve Bratt and Carmela Couderc from MITRE, along with Charlie Harp, Carol Macumber (EVP – Client Services at Clinical Architecture), and Shaun Shakib (Chief Informatics Officer at Clinical Architecture). Steve, Health Technology Principle at MITRE, is the Program manager of the Common Oncology Data Elements Extensions (CodeX) HL7 FHIR Accelerator. Carmela, is a Clinical Informaticist at MITRE, working across CodeX use cases. Steve and Carmela take a deep dive into the history and accomplishments of the growing CodeX community that is working together to leverage standardized collection and exchange of oncology data via the minimal Common Oncology Data Elements (mCODE) HL7 FHIR Standard for Trial Use.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
[inaudible]
Speaker 2:I'm Charlie harp. And this is the info monster podcast today on the infer monster podcast. I'm going to be talking to folks from MITRE who are working with the a M code initiative. And with me today, I have Steve brought Carmella[inaudible] Carol McCumber from clinical architecture and Sean Shaquille from clinical architecture. So why don't we start with some introductions? Uh, Carol, hi
Speaker 1:McNamara. I am the EVP client services and my role I lead, um, client success and professional services. I also wear a hat NHL seven officially as a vocab co-chair and the vice chair of the April seven terminology authority. Sean. Hi, I'm Sean chief informatics officer with clinical architecture,
Speaker 2:And now our honored guests. Uh, Steve.
Speaker 1:Hi, it's a pleasure to be here. My name is Steve brought. I lead miters health standards and interoperability group, and also my HL seven hat is a program manager for the fire accelerator called codex, which we'll be talking about a little bit later today and Carmella. Hi, my name is Carmella and I'm an informaticist working with Steve and 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 HL seven hat. I'm a co-chair of the vocab work group along with Carol.
Speaker 2:Well, I really appreciate everybody taking the time today. And, um, as I, as I mentioned before, the objective of the infer monster podcast is to, to inform the healthcare it community about things that are happening. And I thought one of the things will be really great is to kinda do a quick overview of how, um, codex and M code came about. What's the objective and, and kind of the history behind it.
Speaker 1:First, I should tell you a little bit about MITRE because that everyone knows knows us. I think the people at HL seven probably do, but MITRE is a not-for-profit. Um, we, uh, work only in the public interest and we run seven federally funded research and development centers, and that these are governed actually by federal regulations and 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, uh, advanced prototyping. We work on things like standards, which we'll talk about today. Uh, and also we help with government policy, including in the health space and procurements and things like that. But our department that Carmella and I are in focuses on is called open health services. And we really do focus on prototyping, advanced ideas and, and that's, that's a lead up to where I'm code came from it for everyone's information. M code is the minimal common oncology data elements. So we'll talk more about that, but, um, it all started five years ago when there was an idea of creating a prototyping, a standard health record for patients, and this would cut across all of health. It'd be longitudinal from birth to death, uh, including family history as well. And, uh, 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, um, originally on breast cancer staging, but then we decided let's, let's look at cancer and can we get as our interest in the community at a minimum, say less than a hundred data element standard, um, that's fire based, uh, that would be where the, those data elements were useful to for patient care and research across a wide range of envisaged use cases. So that's where M code kind of came out. And, um, another thing that might or likes to do is convene and bring together the right parties to make sure we're successful. And we were quite fortunate early on to partner with the American society of clinical oncology or ASCO and their president at the time. Monica Bertolli is also oncologist at Braman women and Dana Farber in the Boston area was good friends with our CTO at MITRE, who's out Jason insur. And he's also a medical, a medical doctor, which is quite interesting for an organization like ours. So, um, 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, uh, and they were able to muster a lot of interest in this, this idea of a minimal common oncology data elements that are early on. And so that's, that's where that kind of started and, and going, going back, of course, why cancer also, in addition to this fortuitous connection with between Monica Burton Olian and Jason knits are cancerous as a very serious disease. And research has made a lot of progress on prevention of cancer and also, um, remedies afforded as well, but still it's the number two killer in the world. Probably 40% of all of us are going to go 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 I'm probably listening to this podcast knows of all the problems or collecting data for anything but 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 or data can't be longitudinally, analyze or used for research for 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 of a lot of focus now on health equity. And we know in places in the United States, for example, the level of cancer, breast cancer mortality, for example, um, Mississippi river area is about three times the mortality rate in places like Boston or California, uh, so care camp 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, uh, health equity is, is lacking. So stop me if you'd like, um, just a couple other things about M code. So we of course, are focusing on fire, fire implementation guides. That's why we will talk about the codex fire accelerator, I guess later. Uh, that's also been, uh, uh, something MITRE has been involved with in a long time, a long time. And we even developed a predecessor standard called H data, which was the first, I guess, restful, um, implementation for, for sharing health data and fire. I think drew drew from that quite a bit, I think we're working on 20 plus implementation guides now within HL seven, where M code is, is certainly one of them. And the fire is also, we're fortunate, chosen that, um, chosen that path because of course that would wreck federal regulations also leading to the requirement for health systems and payers to have open fire API APIs for patient data and claims data that's puts us right in the, in the sweet spot of what is being required of health systems as well. So that's, we're finding a lot of interest, uh, in M code in addition sort of a side interest is because of what we can learn more about fire implementation to working with this community. So there's a HL seven fire implementation guide, uh, and it set the standard for trial use level one or two, one, we're going to be balloting a stew too. That's, uh, we'll be bounded in the may timeframe. It will be sort of freezing no, the draft workout it's due to a, I think in April 11th. So we're exciting. The differences between Stu tunes do one. We could talk about if there's interest, but a lot of it was based on learnings with this HL seven fire accelerator called codex. We were able to start using them code for real use cases. For example, radiation therapy summaries is something that we have a lot of interest in from some of the big system, medical radiation, oncology societies, and health systems and vendors. And by pulling those experts together in that specific area, radiation treatment, um, we were able to, uh, see some areas where M code could use improvement. So those are the kinds of things that we really want to focus on is not just theoretical discussions of the, of the standards, but implementing them, learning what works and what doesn't work and fixing it with all the parties involved. So I stopped just, we have a large group of supporters. Now we tied to ASCO. We also have Astro American society of radiation, oncology, cancer link, NIH, FDA. We have about 20 plus 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 is already been delivering code that supports the collection of some, a subset of the M code elements. We meet with them weekly. We really invite all, I think, leader 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, uh, an increasing number of people at the table will feel a value that there's a value in M code who are leveraging it to do provide better care and research, lower costs and lower burden. So that's, uh, that's kind of where I'm code is. And I, I would like to tell you a little more about the codex accelerator too, but I'll stop there. And if there's any questions,
Speaker 2: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, if I'm somebody who to date is not, is not really familiar with, with M code. Um, and I'm one of those health systems is 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?
Speaker 1:Yeah, that's a good question. Um, 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. Paul, 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. Um, we meet the last Friday of every month except for November and December because of the holidays then, and, uh, at noon Eastern time. And if you go to HL seven.org/codex, you'll see, um, a link to our confluence pages and you'll see a community of practice feature 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. So you always have really great speakers. Um, quite often, almost always they're speakers from the community or saying, here's what I'm doing with them code. 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 a white, you know, inviting other people to work with them. So, so that's, it's really exciting to see this it's uptake and interest in what we're doing. The community practices 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, you can get a link, the link to the M code implementation guide itself. Um, you'll also be able to see from the implementation guide that draft that's coming out for Stu to, uh, so you can get a lot of information there. You can also always contact Carmella or contact me for more information.
Speaker 2:That's absolutely true. I spent some time in the last couple of days on your confluence pages. There's a lot of great information out there and will, 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, uh, we'll make sure we have good ones there that are available to you. I don't know if Sean Carroll or Carmel have anything else to say about Emco code before we move on to codex?
Speaker 1:No, I guess maybe it's a, it's a softball question. Imagine then a lead to Kodak. You know, Steve, you've been, you've been, you know, helping lead, you know, within the HL seven community for quite a long time. Um, you know, and I have been
Speaker 3:Around, you know, a decade here or even, um, what do you think it was, you know, about fire that made it possible for these, for the accelerator program to really emerge as a powerful, um, asset within the HL seven community to really accelerate things like codex and Karen and gravity and Divinci, and I'm sure I'm forgetting some of them, but it's something that's, that stands out as being unique to fire as a standard in comparison to some of the other HL seven standards of the past.
Speaker 1:Yeah, it's a good question. And it's not a softball question because I don't think it's that simple. Um, 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 getting, it's the one that the community gets around. And I think fire 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 or 80 20 principle and so on which, which for people in this world of a terminology world, it probably creates a lot of, uh, 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, or, uh, 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. If cancer, they they're, they're part of a research trial or their, their social determinants are having a huge impact on their health is still a person. And so we want to make sure these things that are interoperable, and I think that fire Felder 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, uh, in addition, and sort of supplements the traditional work of HL seven, working on at the standards level, uh, allows you to really kick the tires and test it out as well in the, in the accelerator world. So, um, yeah, it is, it is, uh, it's, it's interesting how I think this has all come together. The, the focus on fire, 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 to, to their customers, whether the customers are health systems or registries, or other kinds of pharmaceutical companies for the need of, uh, appreciation for standards and fires kind of in the right place at the right time is like as a framework for, for sharing. That's got a low, low burden for implementation relatively. So that's my opinion though. I don't know if 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.
Speaker 4:Do you want to talk a little bit more about codex?
Speaker 1:Did we mentioned it so many times up until now? Um, so Apotex is an HL seven fire accelerator. I believe there's six of them now. Um, and we were the third or second or third one in, and, um, we focus on creating a community that's really interested in implementation of M code and extension STEM code, uh, to help address improve cancer care and research. And Kodak stands for the common oncology data elements, extensions, um, what were extensions. It doesn't mean the traditional fire extensions. That really just means supplements. I'd say it'd be a better word for it. Um, supplemental data elements that may not be maybe very specific to some element of the cancer space, because we want to keep M code small. We want to keep them code stable and relatively small. I'm hoping, um, if we can get through publishing a stew to this standard for trial use to this year, maybe we can be normative sometime next year, then vendors have trusted it. They can count on it and that we could have additional, uh, 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, uh, open source project products, whatever you want to help the community, leverage this, to support their customers better. We want the customers to be there at the table to whether it's a health system or registry or other places. So we do focus on implementation, not just on delivering implementation guides and 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 encode or other things. And we kind of already seen that with the work that's going on now to move M code into the standard for Kroll use to level. So that's what we're doing. The use cases I'll read off really quickly, um, 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 are actually executing three trials. Now collecting data in, in Epic and in M code 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 and trials and speed the ability for patients to find trials. Again, I can questions about any of these things, if there's interest. Um, but working our champion, we call it, there is the American cancer society, eye 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 on 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 HR 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 in, into phases, we're building stuff, we're testing stuff. And we have a couple of others that are in planning stages, a radiation therapy treatment. We've got the biggest, um, the biggest radiation therapy delivery system vendors like Barry Varian and Elekta and research working together to send a standardized report based on M code and other elements from their systems into the EHR in a structured way. Right now that's almost exclusively done with PDs. 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 HL seven fire accelerator has done, but focus on a very specific cancer use case. Carmel has been very active in that and also looking at clinical pathways or guidelines and how can we automate that using M code and other data? So these are the use cases are pretty well documented on our website and anyone who's interested in, I'm happy to share more on that
Speaker 2:Sounds was like the things that you guys are doing are pretty exciting. And I think that, you know, you said that 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, 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, in a consumable computable way is half the battle. If you can do that, then you can start to do 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. Um, it's, it's kind of hard to create something, you know, authoritatively centrally and say, this is how everything's gonna work because healthcare is, 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, well situated to have a meaningful impact 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 fire, 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 like to do is kind of pivot from, you know, talking about the, 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 M code. And, uh, I don't, I don't know if Carmela, if you'd like to talk a little bit about that.
Speaker 5:Hmm. Trying to think where to start there.
Speaker 6:Can I ask a leading question to, to maybe help with that? Sure. What is the, what is the scope of M code? 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, trolls, your printers, 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 M codes, um, efforts there? Is it syntactic and semantic? Are you actually building out terminology and, you know, to address the mantic level, inter-operability leveraging existing content helps understand that a little better
Speaker 5:M code, uh, 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 they common data elements around cancers that are, that involve tumors. And so say some elements that might be common for say, blood cancers are not included in M code right now, but that might be considered say an extension if that were use case that, uh, codex, uh, prioritize, we would maybe work on what's required. What kind of data is required to collect for, uh, say leukemia versus solid tumor cancers. Um, so that's one of the scoping issues that they took on also, um, 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, uh, 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 missteps. And 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 a specialty EHR is that, are there oncology HRS? So sometimes there's, there was code systems used in those implementations.
Speaker 6:So what does, what do you do is, you know, as M code, when you find a gap,
Speaker 5:That's a very good question. And then Steve mentioned that we're one of our very active use cases is radiation therapy. And, uh, we're looking at snow med for, to record, uh, radiation procedure, which is pretty complex when you start breaking it down and that you might have a, a general procedure, but then it's really qualified for, by two other procedures, which are the modality and the technique. And what we found is that snowman, which is the recommended in U S Corps. Now. So M code is built with us core as a base, but snowman and CPT are the code systems for all an ICD 10 PCs that are recommended in U S Corp for procedures. So when we started looking at mud modality and technique, we realized that snowman did not have full coverage say for the, for the modality and technique procedures that the, uh, 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 a 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, um, really good communication among the team about what approach to take. And we did really did a three 60 and decided to, uh, use snowman and to submit the missing concepts to snomad, you know, you first, you have to submit them to the U S release center, then they're considered, and they may go into the international release. And, you know, some of the issues there that, um, some vendors aren't, aren't using snomad and, uh, they start bringing up licensing issues and, you know, what would it cost to use nomad if they operate in countries that are not snomad 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 M code 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?
Speaker 3:Yeah. Which, which kind of leads to, to, you know, I think questions that, or issues that a lot of people are facing now, you know, with the rapid, with the acceleration of, um, the ability to create things like fire 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 ideas. Um, you and I have talked about how standards are in some ways having, having its glory moment we've emerged. Um, as some of you who've been this, the HL seven meetings know that vocab, the work group is often, um, uh, often a corner someplace, um, uh, in the, in the sub-basement as, as the trolls that are necessary to, you know, kind of keep the, keep the building, uh, standing up right. But often, um, troublesome, um, and we've kind of emerged from that, that position to being the, uh, uh, as, as Julie James has, has, has referred to the HTA sometimes as Cinderella, you know, as, as a, as kind of cleaning up and keeping things going, um, uh, but not ever kind of getting to be in the forefront. Right. But would that, 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, um, within atrial seven, to try to put some structure and process around, um, the, the, the maintenance of internal HL seven, um, vocabulary, um, you know, the, the gender harmony project that's looking at, you know, finally capturing the difference between sex and gender identity and sex for clinical use in a meaningful way where atrial seven has been able to bring together, you know, not only standards development organizations, but international participants, EHR vendors, um, the radiology folks, um, all together to talk about terminology and, 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 HL seven community to do validation of things like code system identifiers, make sure people are referencing the versions correctly and so on. Um, and as you guys have talked about, you know, did the fire IGS there being an in fire in general being referenced in federal mandate. Um, but with that comes comes a different sense of urgency. A need for speed is as you've coined in other conversations, and that doesn't necessarily align with the traditional terminology offering and maintenance process that we've been used to, right, as you described for you identify a concept, if you're using snowman, you enter it into, if you're, if you remember 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, in the core, all of that takes time. Um, and we don't always have it, you know, I, you know, in my role at the HDA, you know, worked with the Karen folks to ensure that their code systems were being identified in reference accurately, um, under a very tight timeline, right? Th that, that is being referenced in a CMS Rex. And so they had to get, we had to get it done. Um, and that isn't always easy. So, you know, I I'd be interested to hear from you or Andrew 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, um, and making sure that the right terminology best practices are followed in terms of the creation of that content. Um, how do we get there from here?
Speaker 5:Some of it is to somehow change the mindset or enhance the mindset of folks who are in developing these ideas, uh, to start thinking about terminology and your terminology requirements at the beginning, rather than having it be an afterthought and, um, which it sometimes is as, as we've seen many times, uh, so somehow educate the community. And when I say the community, I guess I'm thinking of the, the HL seven community, the folks outside of HL seven, that are developing, um, implementation guides and have the material prepared to help them understand why it's important to, 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. Um, there are these groups out there like HTA, which is the HL seven terminology authority that helps you discover or URLs code system identifiers for those code systems that are managed by an organization other than HL seven, like snowman or LOINC, or some of the new ones were coming across in the encode code space that we just have an HL seven hasn't identified yet. And, um, well, not identify that didn't sound quite right, but maybe they don't have a, um, a known identifier, an ex, uh, endorsed, or sometimes we use the word authoritative identifier provided by the code system owner, like AJCC for, um, the staging system, you know, up to this point. Um, 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 to, and that's going to be difficult. Um, especially when a lot of IGS fire ideas are developed by, uh, consulting companies who maybe aren't, uh, HL seven members, they might not be steeped in the culture of how things, how things are done. Our documentation is sometimes isn't as easy to use as we might like. It's getting better, just Boda created some great, uh, YouTube videos on how to use UTG, the unified terminology governance and their car gutted towards whether you're submitting or you're doing some other tasks. So it's, it's getting there, but I think it's, um, sometimes it feels a little disjoint how HL seven is approaching it because it's a big problem space. And it's, it's a lot to, it's a lot to cover,
Speaker 1:Uh, CML, a really good girl. You good thoughts too? Aye. Aye. Aye. Aye, aye. Something they add when you're done. If you don't mind, I'm not as steeped in HL seven or in health standards. As most of the rest of the people, Paul are, shouldn't have been surprised, 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 what, how radiologists talk and how radio radiation, oncologists talk and how surgical oncologist talk. And they know that's all just 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 U S and they have six official languages, and they have interpreters that are working really hard to translate it. Even it changed, translate from one language to another, to another, and to make that work. And, and, uh, healthcare is a lot more complicated than language, I think in most cases. So even body state was one that came up last week of 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 and some kind of a code system. And they they've had things like this too. They've developed things like this on their own, but surgery, you also need to know where are you? 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, part that's part of it's a 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. Um, and we'll probably end up having the compromise in some short term with mappings and things, but, um, the benefit of working with different disciplines within an accelerator, at least as 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 Kadeer and Stephen brah from MITRE on M code and codex, and invite you all to listen into part two where we'll get more into some of the complexities and challenges around sharing data across silos and 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 Hart, and this has been the monster podcast.
Speaker 7:[inaudible].