Okay, hello everybody, welcome back. Hope you had a good lunch and had a chance to visit with our industry sponsors. We're really excited about this program and thanks to Heidi Bosley for helping to pull it together for us. This has been, I have to say that the title of this is really stolen from Jimmy Chang who's on the, who'll join us virtually shortly. Of this concept of clinical data standards, how do we build our lexicon? And it came up this morning as well in terms of how do we define what the most important elements are in terms of what our specialty societies bring to the table? We own that clinical content. We have a pretty good sense of the outcomes that are important. How do you then think about what data you then need? So logically pull this together. Randy, thank you for submitting this as a proposal. So Randy is the Assistant Director of Quality Improvement at Astra, the American Society for Radiation Oncology. So she's the one living in the space of a specialty society trying to do this work. Sue Chen in the middle here is the Digital Health Clinical Principal. I love the titles at MITRE, at MITRE Corporation. Sounds a little bit like lawyers, but delighted to have Sue. And Sue's gonna give an overview of what MITRE's been doing with M-Code and the new emerging work that we'll hear more about from Jimmy and then Kyle Cobb who is with the Office of the National Coordinator for Health IT. Have had the pleasure of working with her for years when we were together at NQF and she brings this unique sort of ability to be bilingual in data and quality, which I think is kind of a cool thing that ONC got to do that. And last but not least, somewhere in the stratosphere here is Jimmy Cheng who is a Professor of Medicine, Division of Cardiology and Family Medicine Informatics at Duke and he's the one leading Cardex, which is the new cardiology MITRE approach. So we're super excited to hear this and what I've been encouraging our society is regardless of whether you have a registry, you still need to own your lexicon. You wanna make sure that you're the ones defining your specialty, what's most important to your field and make sure we have the ability to capture those data. So I think first person we decided is Kyle. Welcome, please. Hi everyone and I get to, I think set up this whole conversation around building a lexicon with sharing some of the work that ONC has done around data standardization. And I think it's exciting. I think, well, mainly for me, but maybe others, that we have now a data standard for electronic health records that I'll dig into a little more. So, and then we'll hand it over to the rest. So let's go on to the first side. Oh, I have the clicker. Oh, somebody, I thought there was somebody like in the, either, okay, here we go. So, thinking about even before building a lexicon, thinking about standards and why they're important, there's so many good reasons, but what I think one of the most simplest things to think about around data standardization is that it simply allows systems to communicate information in a consistent and reliable way. And since ONC's formation in 2009, we've been charged with creating nationwide health IT infrastructure to facilitate interoperability. And I think that's, it's a simple but difficult mission. And over the years, we've built on that through the health IT certification program. And through that program, we're able to measure health IT conformance to a set of certification criteria. And for the most part, these certification criteria, they include references to standards and capabilities that EHRs should be capable of doing, but it also provides us with a benchmark to test conformance. So, and conformance measurement, and don't worry, I'm not gonna go into conformance measurement too much today, but I think it sets up everything. But the way that we're able to do conformance measurement, for the most part, we do it through testing or inspection or attestation. But we need standards, we need something that's consistent to benchmark with. And that's the only way that we can actually see if EHR can conform to a standard. And to make sure that it's capable of sending and receiving information in a consistent manner, which is, for the most part, what I do most days. So, sort of moving forward and getting into standards, to date, we've had a bunch of exchange standards that the ONC certification program reference, but they haven't included a common set of data elements or a common standard of data elements. So, in effect, we have all of these different exchange standards that are referencing different things, and maybe not the same language. So, enter 2020 USCDI and the introduction of the ONC 21st Century Cures Act, which updated the health certification IT program to include this data standard called USCDI, or United States Core Data Set for Interoperability. So, I'm gonna talk a little bit more about how to maintain that and what we do with it, but I think the main thing about the goal for this data standard is to support these other exchange standards in a way that we can use a common set of data elements and provide a consistent baseline for data elements to exchange across standards like HL7, CCDA, or FHIR. So, USCDI, as I said, it's a core set of standardized health data for health exchange, and it's not specific to a content exchange standard. So, I mentioned HL7, CCDA, and FHIR. It can, those exchange standards can use USCDI, which makes it, which makes the exchange standards consistent as well. And I think the other important thing, I have a couple more notes to say about USCDI that sort of, that makes it important or unique, is that it's updated on an annual basis, and we go through a clear and open, transparent process for annual updates. And we also, you know, this process allows for any member of the health IT community to recommend issues. So, it is absolutely open, and I think, you know, there's certainly people at CMSS and others who have submitted, you know, proposed data elements for future versions of USCDI. The other thing that, you know, I think, you know, beyond the annual updates that are, you know, predictable and, you know, and each new version, we really make sure is like, it's, they're incremental updates. We think a lot about burden and think about, you know, making sure that we're not, you know, tripling size of the data set. So, we have a selection criteria that goes into annual updates. And, you know, I think, you know, in large part to, you know, minimize the development implementation burden for developers, providers, and health systems. So, we increment on an annual basis. And I think another really important point here, and I've mentioned FHIR and HL7, but the other thing that USCDI did when we introduced it was that it, you know, we also, as part of the Cures Act introduced a new certification criterion for EHRs, which was for a standardized API for patient and population services. And so, with this API, we're able to now transmit consistent, EHRs can transmit consistently through, you know, FHIR implementation guides, data that will be the same from an EHR to a HIE to a registry to a, but it really gets us to that point of having some type of data liquidity, so. And then I think, you know, that, okay. And then, you know, so let's go on to the next slide. So, here is just a snapshot of, you know, what USCDI looks like. And that's the, those are the data classes and with their associated data elements. This version is in regulation. It's, and the regulation deadline is actually at the end of this year. So, as of December 31st, 2020, you know, all EHRs are expected to be able to transmit, exchange within their own systems and with other systems, these data elements. And they can do it through a variety of implementation guides or transport protocols, including FHIR or CCDA. So, those are sort of like, you know, and, you know, we are the, you know, since this initial version, we actually have two more versions. We have version two and three, and we're currently working on a version four, which will be published at the beginning of next year in draft. So, let's look at, so this is an example of our latest version that was just published this past summer. And I think, you know, what's in my mind really important about these annual updates is that we are able to add additional fields or classes and elements to reflect health priorities. So, this past annual update, the focus was on health equity, for which we included a variety, and they're all circled here in yellow, of new data elements specific to some of HHS priorities in terms of sexual orientation and gender identity and sex. We also included tribal affiliation. We also included ones around functional status, disability status, mental cognitive status, and pregnancy status within our health status and assessment, which also speaks to, you know, again, health equity and social determinants of health. And then finally, we were able to slip some health insurance status information in as well. So. Okay, so I think, you know, again, you know, U.S. CDI matters because it's a standard, it's a standard data for EHR exchange, and it increments, and I think in my mind, you know, from a policy perspective, we're able to add new elements on an annual basis that, you know, extends the regulatory floor, and it also signals to, you know, the industry, you know, where we may go in future rulemaking. So, you know, again, I'll just remind people that U.S. CDI one, version one is what is in regulation, and the other subsequent versions are not, but they still have corresponding FHIR and CCDA implementation guides. So. That is everything on U.S. CDI. I'm gonna move on to, and just run through a couple slides on U.S. CDI Plus. There's been, I think, a good amount of sort of confusion and not really understanding what U.S. CDI Plus is, but when you're building a lexicon, I think you wanna think about, you know, how to make everybody happy, right, and how to meet all the needs. So what we discovered last year around U.S. CDI was that it really didn't, it did not support all the domains that, you know, people wanted it to, that it needed to, that it could, and so we started this initiative called U.S. CDI Plus, and it's really designed to support specific use cases, whether they're in public health or quality, and I'm actually gonna go into a couple examples with those, but our vision is that, you know, this is an extension of what's in the regulatory requirements for EHRs, but it provides standardization that can be used in exchange, so. And here, as I mentioned, is a example of public health, which is being, you know, we, ONC, CDC, and other public health stakeholders have established this over the last year, and really, the goal, again, is to expand the capabilities of public health data exchange, and it's designed on a similar model as what we have for certification, where we have the U.S. Core Fire Implementation Guide with our API certification criterion, but for public health, we're looking at, you know, other types of use cases, so, for example, case-based surveillance, you know, it's, you know, we would look at, you know, something in there like electronic case reporting that would require standardized data, where we would have those as part of the public health U.S. CDI Plus domain, but that would then be incorporated into fire implementation guides for exchange, and then there's some other use cases that I've listed here, and then finally, you know, near and dear to everybody's heart is around quality measurement. We are also, and I think, you know, in large part, a lot of the U.S. CDI Plus work that was started because of quality. ONC will be, is working closely with CMS on a new fire-based quality reporting model for which we will use fire implementation guides, but there's a need for standardized data, and even more so for standardized data across not just the CMS programs, but other federal programs, so we're working with HRSA as well, and we've even engaged folks like CMSS in listening sessions to really understand what those data needs are for the quality domain. So with that, I am going to hand it over to Sue. Hi, everyone. As Helen mentioned, I'm Sue. I'm from MITRE, but I also am an emergency medicine physician. I have a distinct pleasure of being the clinical director of the HL7 Codex Fire Accelerator. So for those of you new to Codex, this is the accelerator that promotes development, the adoption of clinical specialty standards, and 2022 has been this banner year for us. We started in cancer, and then this year, we've doubled our membership, doubled our use cases, and we've expanded, as you will hear, into new clinical domains beyond cancer, beyond radiation oncology, into genomics, and into heart and vascular health. And I just wanna say that this is really a testament to our community. We've done this by our community's collective voice, striving collective action to gain that real-world traction and success. Now we're looking to see how we can demonstrate that even further in the next coming year. Next slide, please. Oh, sorry. But who are we, right? Codex. So when we're talking about data standards, better lexicon, we're here at Codex, we're a member-driven community. We are surrounded by and really driven by the vision that better data means better health. And what that means is we are really looking to leverage data standards in healthcare in such a way that patients can have the care and research journey that they deserve and expect. And what this means is how do we push data standards into the real world in a real way so that folks, not only patients, but the folks taking care of them across the healthcare ecosystem have the right data that they need when they need it, wherever they need it, and how they need it. Next slide. Oh, I'm sorry. Okay. And so to reflect back on what Kyle was saying, there's so many exciting things happening in the federal space right now in support of this. At the start of 2022, Mickey Tripathi, head of the ONC, he said, 2022, it is going to be this jump all year for digital health innovation and transformation. Why? Because of all this federal onus mandates really supporting core US healthcare data. And then as Kyle noted, at the end of this year, at the end of December 2022, the mandate that there is FHIR API capability live in healthcare, ONC, health IT accredited platforms, so that includes EHRs, patient portals, et cetera, to be required to transmit this core health data by EHRs. So that's exciting, and that opens up huge new potential, huge new opportunities, right, for the coming year. But when we're talking about clinical specialties, when we're talking about cancer, like complex disease processes, that's not necessarily covered by that. So in Codex, what our community has to ask is, how do we leverage this momentum, this foundational development in FHIR, in core health data, and now what do we do to leverage that potential on behalf of our communities further? USCDI Plus offers a lot of potential for that, but it's also by that collective community voice, traction, moving the needle forward to encourage de facto industry adoption, de facto real-world traction that has been really come to fruition this year, and that's been really exciting. Next slide, please. Oh, okay. It's gonna be a metric. Of pros and cons of how I've done on this presentation. So in terms of like a lexicon, in Codex, we foster FHIR clinical specialty standards. We started in cancer. MCODE is the cancer specialty standard developed to represent how do we speak about cancer with the granularity needed so that we can maintain that value as we converse about cancer across varied perspectives for various needs across the healthcare ecosystem. We talk about standards, and standards, they're only valuable, right, if they are used, used widely, used effectively, and used across healthcare settings in actual practice. So at Codex, our goal here is not that we are developing standards, it's how are we getting this real-world traction and usability out of these in the real world. And I don't have the answer, so with my full disclosure, I'm emergency medicine, right? So not cancer, not genomics, not radiation oncology, not heart and vascular health, but it is by the voices of our community. We leverage our community to bring them together from across healthcare, it's their thought expertise, their frontline expertise, their in-kind resourcing, the alignment at their shared pain point, and this is how we guide and prioritize design-based use case pilots to really develop and hone that real-world robustness, maturity, based on true requirements needed in practice, true complexities, so that these standards can fly in real-world settings. And so in Codex, it's not just about our member community, it's also about the public at large. Look, the work that we're doing in our community, it's great and it's in pilot, right? What we're hoping for impact is that that radiates across the healthcare ecosystem even further. And so in Codex, we have this community of practice. These are public monthly calls, it's where we share, learn about what is going on in the community, about developments using these clinical specialty standards. But it's not just about the work that our community has done, increasingly it's about the work that other folks are doing, externally, independently, and the best part is, especially this year, it hasn't just been nationally, and I'm not saying locally, it's been national, it's also been global. We're talking about like Oncoclinicus, the largest cancer clinical network in Latin America, UK has been involved, Germany, we're hearing from Taiwan. So this has been a really exciting year, and I'm really encouraged to see what will happen in the future. So that being said, our secret sauce to success is right here, these are our vibrant community members in Codex, and they have grown and doubled in size. And when you look at here, and actually, I didn't get a chance, because this is late in coming, but Epic is officially joining too, so that's been exciting, yay for that. But when you look at here, these are varied perspectives all across healthcare, and this is how we get it done. When we're looking at quality, research, trial matching, these are the different perspectives at the table, contributing hard work, sweat, equity, and actual true resourcing to make this happen, and so this is how these are the vibrant members steering our course and making it happen for us. And so it's that work that we've done in cancer, that success, that other clinical specialty domains have seen, and it's these clinical informatics leaders in genomics, in cardiovascular health that Dr. Jimmy Chang will now speak to, that have, you know, said, let's collaborate now and take the shared learnings, these shared best practices, and now leverage this to new domain development in other clinical specialty areas. How can we push the needle even further? And the conversation here, too, is as a shared collaborative effort, as we're doing this, let's continue to collate these lessons learned, collate these best practices, and let's start developing the community playbook, the community toolkit, so that anybody else wanting to follow in this path can also have an easier, to be honest, glide path. And as I mentioned, our use cases this year, we've doubled, so it's been pretty exciting. In these use cases, they cover research, trial matching, public health reporting, how do we develop clinical specialty processes for N10 workflow, such as radiation therapy, prior authorization, in cardiacs, cardiovascular health, we're looking at hypertension, genomics has been exciting, we're looking at and have committed folks at the table, looking at how do we structure genomics lab data and make it easily ingestible by EHR's patient portal platforms. When that happens, you all hear, oh me, many gold stars. For genomics operations, how do you access, no matter where and how genomics data is stored in data repositories, how do you access that easily, in bulk, so you can do the broad analysis needed to get to where we wanna go? The FDA has been excited by the work we've done. They've come and joined Clodex, sponsored, they're championing a use case around a FDA drug safety program called REMS, risk evaluation and mitigation strategies, and now we're exploring quality measures for cancer. So this has been huge, it's been exciting. This is real, like in EHR endpoints for cancer clinical trials, we are at multiple health sites now, capturing data in routine EHR workflows for NCCN clinical trials, so this is not just me spouting, and it's been really exciting. In the world of cancer registry reporting, because I know registry is a hot topic, registries are hard, there are so many requirements, so many perspectives, so many challenges, but it's still important to push the needle, see where we learn and get to where we all wanna go. So how do we approach registry reporting, leveraging data standards to get that low burden, less resource, more feasible way of standardizing this, and how do we do it so that it's more timely? Currently, just to report, for cancer registries, for bone marrow transplant, it takes huge teams, and not only does it take those huge teams, from the time for when the patient is seen to when it gets into central CDC registry repositories can take 24 months or more. So we just completed phase zero this year of a synthetic pilot with UCSF, MITRE, CIBMTR, the Center for International Bone Marrow Transplant and Research, California State Registry, Cancer Registry, CDC, and so that's been exciting, we confirmed sharing the data. This is in collaboration, right? The whole world of FHIR is just about promoting community development in this area. And so as such, it's not just about the work we're doing, it's also about leveraging and collaborating with CDC, leveraging the work they're doing for FHIR and public health reporting, and then collaborating them in kind. And as such, when CDC developed their central cancer reporting IG, the cancer data elements, they all point to the work we've done in codex, so M code. And so this is about puzzle pieces fitting together nicely, not shoved together in an awkward overlap, and together we are getting this done. We're now looking at phase one, how to expand this work, maybe to other sites too, other states too, and so stay tuned. And so I hope you like what you've heard, it's just really truly about building data unity for patients, clinicians, and research, and it's all done with a collective voice, driving collective action. And clinical specialty voices, the voices in the community, it really matters. So we are so thrilled Epic joined, but Epic has been party to this for a lot longer than even this initial membership, and it is the voices of our community and some of our use cases banding together health sites that are Epic saying, hello Epic, we need this, hello industry, we need this, start doing this. And so as such, increasingly in Epic, and now in increasing other vendors as well, we are hearing about adoption of this in production or in production roadmaps, so this is happening. And so this is the lexicon coming to life so that it can be accessed not just for patients, but for patient populations at large, so that we can all do what we need to do to care for patients, learn from each patient, and then be able to transform care for all. So just a plug, because I have to represent my community, is that if you like what you've heard, we'd love for you to build and innovate on our work, get engaged, join us on our public events or calls. If you want to dive in, learn more, reach out, share our website, check it out, but we'd love to hear from you. And now I'll turn it over to Randy. Great, thank you Sue and Kyle for such a great, I guess, platform, a great foundation. And so as a staff person at a specialty society, I can put myself in your place for a minute and say, yeah, yeah, we've all heard this before. We've heard the FHIR solution, we've heard it'll solve everything, but what does it mean for you with your specialty, with your organization? So I'll give you a little origin story. ASTRO, the American Society of Radiation Oncology, has, like probably many other specialty societies, a slew of failed and lukewarm informatics initiatives over the years. The front row here is having some PTSD, but we've had siloed projects for a decade that just haven't gotten off the ground for one reason or another, but mostly because they were siloed and the lack of data standards. And so in 2018, we actually heard about M-Code, which was being driven by MITRE and ASCO at the time, and ASTRO joined the M-Code, so Minimal Common Oncology Data Elements initiative. And it's a multidisciplinary group focused on this oncology-specific data standard. But we joined, and then we joined Codex. At the same time, our sister society, one of our sister societies, the American Association of Physicists in Medicine, also joined Codex, and so that we could work together instead of in these siloed situations and work under the same umbrella, work under the same language, and work in the same direction. And I'll say that the perfect storm that Kyle and Sue have both mentioned of the requirements for the vendor community, it has created this perfect storm for specialty societies to engage in building the standards that only their members will be able to provide that subject matter expertise for. It provides the stick that we've been looking for all along to get the standards in place, to get the data to a much more meaningful place. And so the outcome of that synergy that we've had and moving in the same direction has been vendor adoption of what I'm gonna talk about and successful pilots of data transfer in a meaningful way. And so in 2018, ASTRO developed what was meant to be a list of data elements. We had been asked by a million different domain groups, pharma, registries, state, bodies, everybody, saying we know what to collect for medical oncology. We know what to collect for surgical oncology. We have no idea what to collect for radiation oncology. What do you even do? And so we created a list of what should be collected in all cases, the minimum data elements. And we thought at that point, because ASTRO does not have technical expertise, we don't have expertise in building standards, this was gonna be a list that we put into the universe to see what happened. And so at that point is when we joined the MCODE Executive Committee. As you can see here, it's driven by the Alliance for Clinical Trials, ASCO, MITRE, ASTRO, and the Society for Surgical Oncology. So this was MCODE, the standard in 2019. What had been done was really scraping through SNOMED or any other standard that existed to see, okay, what fills in the gaps for oncology if we're looking at this holistic picture, not just treatment, but the full patient? What can we get? So this was 2019, and it was very limited at that point of what existed. We looked at the national thesaurus, we looked at every single source that existed. So keep this picture in your mind. As Sue mentioned, the use cases are very practical within Codex, which is the group that's actually rolling up their sleeves to grow the MCODE standard. These are very real-world, practical, clinical things that are not academic exercises. They are not conceptual. These things are actually being tested for real-world implementation. And so ASTRO is involved directly in these three. So the treatment data use case, prior authorization, and quality measures. So I'll start with the radiation therapy treatment data use case, not to talk to you about radiation therapy, but to talk about the success of all of these groups represented here, and this isn't even all of them, working together using the same language, the same platform, moving together. The goal, we took the minimum data elements paper that ASTRO had created in 2018 and said, okay, what's a practical use for all of these disparate things? And it was an end-of-treatment summary, the bane of clinicians' experiences, as Holland nods her head. It's painful, it's manual. What does it mean in the end? What's it being used for? If it's being transferred from physician to physician, it's in a PDF that nobody actually ever looks at. So how do we change that? So we took that core set from the minimum data elements, plus a couple others, that we only had ever believed would be a list and a pipe dream. We were able to engage the technical experts at MITRE and HL7 to make it a reality. And so huge things have come from this, but this is just the foundation. So again, our subject matter experts, our clinical experts in ASTRO and AAPM, the physicists in medicine, created this clinical conceptual map. You don't have to know anything about radiation oncology to understand all of these connect. And what we were trying to solve for in our use case was that gold box on top. We had vendors at the table, which was so key, because we were able to say, look, we need to aggregate the dose at that gold level, but we can only do it if we start at this tiny unit. Can your systems do that? And because we had vendors at the table, we weren't creating something that would never exist. We had the vendors saying, yes, we can do this. And the clinical experts saying, but what if you did this? This would be more meaningful. And so all of this collaboration, working together with the technical expertise of MITRE and HL7, turned this conceptual map into this. This is the fire profile. The red box will be the fire profile that went into the new M code standard, the V2, because the M in M code is minimal. And so there's not gonna be everything flooding into it or it's just code. It's not M code anymore. The outside blue box is everything that's standing in an adjacent fire implementation guide that's specific to radiation oncology. And so these are all the building blocks that lead to the data being transferred in that red box. All of this foundation had to be set. And this could have never been created at all by just ASTRO alone. We needed the partnership of different medical specialties. We needed the partnership of the vendor community, the technical expertise, again, of MITRE and HL7 to get here. So the outcomes of this have been broad. But we have had, before I move on to that, we have had successful pilots. So Varian and Research, which you see at the bottom, are radiation oncology-specific vendors. But you'll see Epic there as well as a participant in these Connectathons. Vendors will go through these Connectathons as a test before they implement it or before they even put it on their roadmap. And so this was in May, actually. And Research has already implemented the solution into their vendor system, into their live commercial system. And Varian and Epic have it on their roadmap, which is huge. Because you think of, in the world of specialty societies, radiation oncology is a pretty small player. And the fact that we've been able to say, Epic, pay attention. We need this. And they have shown up, is big. And so think of that first map that you saw. This is V2, this is where we are now. And you can see the biggest growth, actually, in the M-Code standard has been in the radiation therapy space because of all of the players that we had at the table. And so, again, this has gone on. Oh, it went away. Wrong button. There we go. So I wanna back up for a minute and say how we got to that point. We all have our committees in our organizations. We all manage our groups, whether it's your registry group, measures, informatics, whatever it is. Our sister society, which I spoke about earlier, AAPM, has a big data subcommittee. And this isn't just one group talking to themselves in a silo. It's meant to be broad. It's meant to get the full scope. And so, again, everyone's moving in the same direction. And so as members of this one society's committee, you'll see ASTRO's there. ASTRO is the European Radiation Society. IHE, basically everybody has an IGE. NRG, which is a research trials group. And then the top three organizations are all our Canadian counterparts. And so, like Sue said, even at this level, we're thinking internationally. So this group has been creating an operational ontology specific to radiation oncology. Sue and I were talking earlier, and there's a Venn diagram probably of all the specialties in this room. And oh, we don't really need to think about our data because this specialty will kind of fix it for us. This specialty will do it for us. In radiation therapy, nobody's gonna do it for us. We have to do it. And so that ontology then has been feeding the work we've been doing in Codex. And so there's this built-in, this feedback loop. And we're, you know, anything that comes up in Codex, we immediately take it back to this multidisciplinary international committee. And we're like, this question came up. What do you think about that? And we form consensus so that it can go back in. And then ontology is picking up all the decisions. And so it's a living ontology. So much so that with CMMI's proposal, that's now dead, of the radiation oncology alternative payment model, we wanted to incorporate a health equity element to it. And so ASRA developed the HEART score, which looked at different social drivers of health and all of that information that we identified. And looking at actually what was in US CDI, we then fed it into the ontology, which then feeds to Codex. And so again, it's all connected. And then we were able to take some of the ontology and submit it for the V4 US CDI. Look out for it. So like I said, the radiation therapy data has been fed other initiatives. Prior authorization is a big thorny problem. We are not trying to look at the political moral compass of it. We are trying to look at the data transfer piece. And so it's just a small sliver of what's happening in prior authorization. But Evernorth, who is a payer group, Evacor, came forward and said, we want to try to fix this. We're part of the problem. We're a payer. But can we fix this? Can we make the data transfer less painful? And so we jumped in. And then Varian, a radiation oncology information system, jumped in. And then you see US Oncology, MEDL, Telligen. We have big players that said, yes, let's fix this. And the information, because we were so robust with our treatment data use case, these players said, well, radiation oncology is out ahead. So let's start with radiation oncology treatment data. And so they're starting with lung and breast cancer for radiation therapy instead of going to the usually more popular medical oncology solution. And so it was exciting. Lastly, we are then taking that same platform, that same foundation that we've created, and said, OK, the other big pain in everybody's rear end is quality measures. The quality PPG group yesterday was talking for a very long time about the problems related to quality measures. And then to take all of that moving threshold of what's expected of us as measure stewards, and then to create digital measures on top of that. Who even knows where to start? And so we came to MITRE at the same time as actually Telligen came to MITRE and said, can we fix quality measures? And MITRE said, well, if both of you think this, then let's do it. And so we're looking at, this is the most nascent of the Codex use cases that we're involved with. But can we take M Code and the FHIR standards and create digital measures in a less painful way, where we still get to the same goal? And then using US CDI, using the APIs, using that perfect storm again, can we make it all work? So TBD, I'll report back later. But we have people at the table that are keen to fix this. And we're specifically looking at cancer. But not to preview what Dr. Chen will say, but they're also looking at this space. So if you have any questions about how to set this up at your own societies, what you do, how you can do it, please feel free to reach out. I'm happy to spread the love and the solutions that we've found with other societies. I am. Can you hear me? I'll drive for you if you'd like. I can just, just, oh. Actually, I think I have control. Yeah. So thank you, everybody, for allowing me the opportunity to present by a hybrid format. I'm going, it looks like I have only about 10 minutes. So I will try to bring this discussion home. Riffing off of what Helen actually introduced the discussion this afternoon is I'd like to provide you some perspectives on what it will really take for you to own your lexicon. What's that pathway forward? As the newest member, by the way, of the Codex Fire Accelerator, you will see some of the themes built on there. But it actually, the work that we're doing with fire and the fire accelerator is the culmination of work that really needs to start at a much more foundational or much more fundamental level. So here's a diagram from Stan Huff that describes the entirety of the health care ecosystem. And what we are really talking today about is this upper left-hand corner where you as either a representative of a society or a registry or perhaps an academic consortium are responsible for identifying what lexicon are you going to need in order for you to be able to describe performance measurement, quality outcomes, conduct research, any of the use cases that you can think of for that data. I'd like to say that that's really kind of where your responsibility ends. But I think what we're trying to do is stretch your mind a little bit to say, no, that means that we need to get into the terminology side of things, the development of common data elements. And then think about how to translate those via fire, using the word resources inappropriately, but using expertise, subject matter expertise, like, for example, has been provided by MITRE. And then bringing together the community including proprietary community that's represented on the bottom of this diagram in a way that allows for the data to be captured once and then really used many times. I think everybody in the room understands that whatever you're trying to accomplish, whether it's quality improvement, device surveillance, evidence generation, performance measurement, it really does need to start with good data. And so the key question is, how do you get to good data? Well, I would suggest that most everybody or perhaps everybody in the room today solves the data capture problem by creating your own set of data elements, your own set of processes, your own dictionaries, et cetera, and working with registry vendors, if you will, the registry vendors to create ways for humans to abstract that data and to move it into the registry's environment. You've heard a lot about FHIR. And the question you might be having, and hopefully this will provide you some perspective, is what does FHIR do? But perhaps more importantly, what does FHIR not do relative to this idea that can't we just pull it out of the electronic health record and get it into our registries? So this is a list of things that FHIR does. But what is missing from here, what is really missing from here is identification of the concepts that need to be captured, information, if you will, that needs to be captured as data, and representation of that data in a physical format. That is, how should that data be structured? So that's really what I'm talking about, what Helen introduced as owning your lexicon. Now, you might say, well, isn't FHIR supposed to do that via bindings, for example, to things like SNOMED? And I will give you a hopefully quick demonstration of why that's actually not the right way to be thinking about this. So being a cardiologist, I'm interested in myocardial infarction. If you search on the term myocardial infarction in the SNOMED CT browser, you'll find that there are 308 matches that are returned in a very quick time. But there is none, there is no clinical definition. So when you hear about the word ontology, you have to understand ontologies are just simply relationships of one concept to the next. They are not definitions that can be applied in ways that then say, yes, did this patient, or did this enterprise, or did this process meet a performance measure? Or what was the clinical outcome? So yes, FHIR is a great transport mechanism. No, it actually doesn't do the job to get to native data interoperability, which is really what you need to grasp as a concept. That is, the identification and the definition of the core clinical concepts that you need for your construct, performance measurement, or even resource use, whatever it might be, is really the starting point. And that is the responsibility, I think, of many, if not everybody, that is here at this presentation. So where does this take us? Well, the journey in cardiology actually dates back, very honestly, now some 20, 25 years. We've been at this quite a while, and the first foray into this was the cath PCI registry, which was started in 1994, so yet 25 years ago. From a standpoint of trying to identify a lexicon, and Randy talked about this and how the radiation oncology community has come together, there actually is an entity within the cardiovascular domain. It's the Joint Committee for Clinical Data Standards, sponsored by the American College of Cardiology and American Heart Association, where we're trying to bring together the subject matter experts that ought to be responsible for identifying these concepts. And so, point number one, that's kind of the starting point. This has resulted in publication. So you see on the left-hand side there, actual key data elements and definitions of a base cardiovascular vocabulary for electronic health records. The dilemma, though, is that we wrote this back in 2011, and a decade plus later, we really haven't made a whole lot of progress of getting this adopted across the clinical domain. So where are we today? Well, we have a lot of maturity around epidemiology, science, pharmacology, devices, guidelines, and policies, but what we find is incomplete, and this is really the plea, is around data standards, and that is how to express clinical concepts as universal common data elements. And the parallel to that, by the way, is device standards that would allow for, if you will, plug and play. The last couple of comments that I wanna make is that the pathway forward, we do believe, in the cardiovascular community, does involve fire. But it involves more than just expecting fire to, if you will, do it all, that you have to start off with a foundation of a core interoperable lexicon that's defined by the subject matter experts, and that anticipates use cases, application, if you will, of that lexicon with extensions specific to the use case. So hopefully this list here resonates with you, but this is the ask that we're suggesting. It does start off with, again, this standardized, excuse me, set, validated set of data elements. This is not just, if you will, text entries into electronic health records. This is actually converting those concepts into discrete computable data that's agreed to, if you will, by the community. What this means from a standpoint of then expression or extension is the magic of what we have been working on with MITRE. Sue Chen already represented some of this, but for example, we've said, let's go where we find that there's still problems. So again, we've got good drugs, good guidelines, but what's missing, for example, from the standpoint of hypertension management is a conversion, number one, from a clinic-based approach, which is on the left side of your screen, to more of a self-managed approach, where the patient is really managing their blood pressure at home, number one, and number two, the question we ask is, well, what's missing in order to enable that? Well, it's actually pretty simple, and that's the exchange of the data in ways that it really doesn't matter if you're a Cerner site, an Epic site, a Meditech site. In terms of the EHR, it doesn't matter what personal health record management system you're using. That data does need to be able to move freely, which are the red arrows towards the bottom with the bit of a fire emblem. Now, it's actually very hard work, because the technical side, and I know this is an eye chart, I apologize about this, but the technical side is, you actually have to figure out what needs to be moved, when it needs to be moved, what context it needs to be moved in, who's going to be responsible, what are the triggers, et cetera, et cetera. And so, as you think about the technical approach to what we're asking, number one, you have to understand what your destination is. What are you going to be using that information for? Randy showed the gold box at the very top of her diagram. That's very similar to what the ACC and AHA have done in terms of thinking about the guidelines and performance measures as the terminology set that needs to support that. Then again, you need to think about, okay, now, if that information is expressed as text, where can we find it as data in the context of processes and workflows? And only until you've done all that, can you then start thinking about building FHIR profiles and implementation guides, testing it, et cetera. So my last slide, a little bit, again, more of a eye chart, but I think everybody understands that we really do need to get to the point of capturing information as data, as computable data in real time, in ways that make that data liquid, in ways that make that data liberated in order for us to capitalize on the opportunities for all of the stakeholders in healthcare, which is not just registries, not just registry owners, but it's clinicians, patients, health systems, vendors, government, and payers, and really everybody who's involved in this domain. So I'm going to end my talk there. I do appreciate the opportunity to present to you virtually and I don't know if we have any time for questions, but thank you very much for your attention. Great, thank you so much, Jimmy. Let me actually thank the whole panel, if we could, and we'll see if we can have a little bit of time for questions. I was supposed to warn you, it's just a test. Sorry about that. Sorry, Jimmy. It was just a test. Oh, now there's this new one. A test, only a test. Thank you. May I have your attention, please? May I have your attention, please? This is only a test. Are we good? We appreciate your assistance. You know, we try to build excitement into a data standards talk. Oh my goodness. I suppose it'll end in like two minutes. I'm sorry. You think so? I feel like as soon as I start talking, it's going to go again. What do you think, guys, good? Okay, so that was fun. I really, that's for sure. Any questions for the panel? All right, I'll start with one then, as long as we have all of you here. I loved how these really built on each other, really the ideas like this is really what's coming down the pike in terms of the clinical data standards, the work that ONC and CMS will do. Sue's work around how Codex really brings these new ideas around data standards to the table. Randy building, I love the idea that Codex, but then specific use cases. And I think what Jimmy was really doing is more of a roadmap, right? How do you start from specialties that maybe aren't as far down the path? How do you do that? So I guess my question for any of you, maybe just starting with you, Jimmy, thinking about some societies who might be in the room who aren't as far along, haven't even done the paper from 10 years ago that says here are our core data elements. Where do we start? How do we get societies to start moving down this path, regardless of whether you have a registry or not? Why don't we start with Jimmy and see if anybody else wants to weigh in. Yeah, so I'll add one quick comment, hopefully quick comment here. If you think about NSA and the card, the records. I can't hear you, it's back again, one second. We thought we were done. Oh my Lord. Still a test? Okay, still a test. I'm sorry, Jimmy, I think we lost that. And I'm afraid they're- Okay. Julie said it would be done, it's really quick. Oh my goodness. Stop! Hope we're not recording this. We'll cut this out, right? Okay. No, it should be the after bloopers. It's... See if it has bloopers. All right, Jimmy, I'm afraid to say, ask you to repeat that. All right, can you hear me? For now. If it starts going again, we're sorry. Yeah, I know we're short on time, but I do want to emphasize the initial M is an M code and M card. The initiative to put together, for example, the cardiovascular based lexicon, we've code named M card. It stands for minimum. So the starting point really is to identify a very limited number of terms using what I would say, use the Pareto rule. What list of terms can you accomplish 80% of what you need to? Don't go for 100%, don't go on a fishing expedition, but the process is really gather together subject matter experts, understand that information captured as computable data is really the goal. That's perfect. Anyone, Kyle, I was gonna say, I assume you would want to answer that. Yeah, is this on? Yes. I would just add, take a look at US CDI. And I think Randy had and Sue had mentioned looking at it to see where it didn't meet. And so if you're trying to establish your own lexicon, take a look at that and see what's missing. Yeah, especially US CDI plus I would think in particular. Yes. I'm just gonna add one more because I wanna put the pressure on everyone. Okay, please go for it. Yeah, this is a time in fire where things are developing. There's maturation, there's development. Folks are doing things now, right? So this is not a couple of years ago where we came in and fired for oncology. It was kind of like an empty slate. Folks are developing fire. fire. But that also means that folks were developing. Having a sense of what is being represented and how it's being represented, that I think that challenge and gauntlet is here. It is a good time right now to jump in and there's industry support for this. So this is a great time to decide, are you gonna ride this wave or let it kind of roll over you? And it's not that I think, I do think that this is a great opportunity, I just also wanna lay that challenge down that the clock is ticking. All right, I like that. We like urgency. Anything you wanna add, Randy? Don't have to. So we followed exactly the same path as Jimmy said, but I will add in addition to USCDI, looking at the other fire accelerators, the prior auth work that we're doing is in conjunction with the DaVinci fire accelerator. Every use case we have is looking at the output of the gravity fire accelerator. So it's beyond specialty, it can go to payer relations or health equity or there's a fire accelerator for everyone. So get involved. Yeah, this feels like something I think for a lot of us, building lexicon, I think we need to build a glossary of some terms here too. I think there's just a lot of, so a lot of, as a good friend of mine, Carolyn Clancy has referred to dog whistle range for some things people are listening to probably. So try to explain that and we will understand. So let me, just I think we're gonna run into the next session. So thank you all, what a wonderful session. Sorry for the fire drill, literally. Thank you, Jimmy, it was great to see you and we'll see you, we have a little bit of a break to pass periods and move on. Thank you. Other than that, that was a great session.

clinical data standards

interoperability

data exchange

specialty societies

core data elements

fire profiles

subject matter experts

USCDI

Fire Accelerators

implementation