Good afternoon, everyone. We're just gonna give it a little bit of time to let some more folks trickle in. Okay. I think we can go ahead and get started. Good afternoon, everyone. Thank you all for joining today's NCQA webinar on preparing for digital HEDIS, learning how one health system integrated CGM data at scale. My name is Nico Gutierrez, a senior health care analyst here at NCQA serving as your moderator. As a quick intro, my work at NCQA focuses on supporting the development and implementation of digital measures and resources, bridging technical standards, quality measurement, and practical implementation to support improvements in health care quality. The speakers for today's webinar are Ria Rustowski and doctor Michelle Knop. Ria is a product manager at Tidepool, a nonprofit advancing diabetes care through open source technology. Ria leads product initiatives for Tidepool, helping integrate diabetes device data into clinical workflows and electronic health records. Her work focuses on bridging clinical needs and health IT to improve efficiency, quality, and capacity in diabetes care. Doctor. Knop is an assistant professor at the University of Cincinnati and a physician at Cincinnati Children's Hospital. Board certified in internal medicine and clinical informatics, she works at the intersection of clinical care and health IT, including efforts to integrate diabetes device data into clinical workflows. Our research focuses on using technology and data to improve chronic disease management and health care delivery. Before we dive into the presentation, I just wanna quickly go through a couple of housekeeping items. First, the recording and slides will be recorded and accessible on our website by the end of the week. Second, if you have any questions, please feel free to use the q and a portal. There will be points during the presentation where the speakers will stop for discussion and questions. Questions. And now I will pass it on to Ria to kick off the presentation. Thank you so much, Nico. And so, yes, I had the pleasure of working with Michelle Knop on some of the EHR integration that she's gonna talk about in a minute. As far as agenda today, we have many folks from the health plan side as well as health systems and device makers as well. So we're gonna follow data the whole way from the device to the EHR and then to the quality measure. Along the way, I'm gonna point out which decisions belong to the providers and which ones belong to the plans. So I'm gonna start with why quality measures need CGM data in EHR. Next, Michelle will share what Cincinnati Children's has built in order to make CGM data available for their providers and patients, and then we'll walk through some of the technical and clinical decisions that affect quality reporting. Finally, we'll close with questions. And please, again, feel free to post questions along the way, and we'll pause and try to answer those. So, yeah, let's go to the next slide. Thank you. So CGM data and quality measures. Not knowing everyone's background, so just gonna give thirty seconds here, because just what is CGM if you're new to diabetes? So it's a small wearable sensor, reads glucose every few minutes. So instead of having to take multiple finger sticks a day, you get a continuous view of glycemic control. Time and range, that is the share of someone's day where the glucose is in a healthy range. It's usually the first thing that clinicians are looking at. And GMI, that stands for glucose management indicator. That is gonna come up a lot in this presentation. It's an estimate of a one c, and it's calculated from the CGM data. Next slide, please. So GSD, this is the main diabetes control measure in HEDIS. It's used for adults between 18 and 75 who have diabetes, and it looks at the most recent a one c for the year. For HEDIS, you wanna be below eight percent in order to be controlled. Trick is not every patient gets a lab a one c every year. Most of them do. It kinda depends on your system on your system. But when they don't, a GMI from their CGM can count instead. This matters now more than ever because chart review or the hybrid method is gonna be retired by measurement year 2029. And after that, a GMI and a PDF is not gonna be counted while a GMI that's stored in discrete data can be used. So getting CGM data into the HR, again, goes from a nice to have to a need to have. The next measure is CGDE. So this is new for measurement year 2027. It measures CGM use among adults eighteen to seventy five with diabetes on insulin. It's a utilization measure, so there's no target right now. It's just describing how many eligible members use a CGM. And what's great about this measure is that a pharmacy or DME claim, device record, or, again, CGM data in the EHR can all be counted as evidence of use. The last point matters, of course, because we're talking about CGM data because claims can sometimes miss patients that pay out of pocket or otherwise, yeah, there are patients that otherwise would not show up. So CGM data can close that gap. So EHR data. Yes. So let's talk about, you know, to kinda summarize those two measures. So, CGM data is very important, but, unfortunately, today, it rarely reaches the HR structured data. So when NCQA developed the CGDE measure, its own feasibility assessment found that the CGM data is accurate, but rarely available to plans. And that also matches what I've heard from clinics. They say patients use all kinds of different devices and manufacturers, which is amazing for patient choice, but obviously creates a real challenge when they have to bounce between multiple portals, each with their own report and login in order to get the data. Then there's the challenge of getting the data to the HR, which for most clinics, it's not practical to build separate integrations for each portal. So they're left having to print or download PDFs and scan into the chart by... And type in measures by hand. One clinician told me her clinic had 12 different third party softwares, and they still print PDF reports from each one. We would love to, you know, save some of our clinic staff time and also make this data available for quality reporting. And I think Cincinnati Children's is an excellent case study on how to bring these CGMetrics from several device manufacturers actually into discrete fields in Epic. I will make a note before Michelle starts. Cincinnati Children's is a pediatric clinic. So GSD and CGDE don't apply directly to them, but they do report for other quality bodies. And everything we're gonna talk about about how the data flows and how it's filed and how it's coded still applies. So, Michelle, I will let you take it from here. Michelle, you're muted. Thank you. So a little bit about us. We are an urban tertiary academic pediatric hospital, and I say that to remind that we are a very high resource facility serving about half a million children in the Southwest Tri State area. Southwest Ohio Tri State area, we provide care for just over two thousand patient... Diabetes patients per year with about two hundred new onset cases. We have a pretty good insurance mix with fifty eight percent on private, about thirty percent on public, and thirteen percent self pay or uninsured. And we have a highly multidisciplinary team with physicians, APRN, certified diabetes care educators, specialists, social workers, psychiatrists, community health workers, community partners, and also our families often representing, their voices in our different interventions. And so why did we initially start along this work? There's really a twofold why. Our first why was our patients and recognizing that so much of chronic disease care happens outside the fifteen to thirty minute clinic visit that happens, every quarter at best. But our other why was as clinicians, and the entire clinic staff really felt the... We don't need more portals. We need the right data in the right place at the right time to connect the rest of the patient's story. And so this work that I'm presenting here and sharing was funded by the Helmsley Charitable Trust and was a major effort over several years. So I don't wanna give anybody the impression that this is something that should... Can just be turned on tomorrow for health systems. And so what was our state before integration? We really had a significant manual workflow with lots and lots of different steps. We initially had a pretty significant pre visit planning process where a assigned MA or nurse for that provider would kinda go through the patient's chart before their upcoming visit, figure out which platform that patient is on based on which pump or CGM they use, which is in their prescriptions, log in to one of those four platforms with individual credentials that are not their health system credentials, often with two factor authentication for those four different platforms. If there was no data visible, or they weren't connected, they would contact the family if it was a digital connection to troubleshoot, and then they would go ahead and print the 10 to 20 page report, associated with with that. After the visit, providers manually transcribe the 10 CGM metrics into flow sheets, also known as observations in some e... EHRs, to get that discrete data that we've been collecting for several years now. But this is obviously tons of paper, tons of logins, lots of people handling the data in ways and not really streamlining that process in a way to truly add value to their day to day diabetes care of our patients. And so what we went ahead and do... Did was build an order based workflow. We wanted to really start our process and improve this process with a pull mechanism. And so we start with a clinician placing an order in the EHR that gets sent to one of our vendors or aggregator platforms. We use h l seven two, for that message to get formatted once the vendor is able to match our order from our patient to a patient that they know about. That gets sent through a middleware integration platform, which is something like Mirth and then goes to Redox, an enterprise interface engine, ultimately gets transferred back to our EHR where it's decoded, and ultimately, we made the decision to display this in results review. We also be... Knew that we have many patients with a large variety of choices of pumps and CGMs as Ray alluded to. And so we knew early on that integrating with just one one vendor or even one aggregator would not suffice for our clinical purposes in trying to reduce the barriers we were trying to solve. And so we have actually, at this point, integrated with three vendors and aggregators, including Tidepool and have a fourth one fourth one coming up. And so even with all of these steps, there's all sort... Understanding this process is helpful for understanding how it can fail, but also understanding the opportunities. And so what we did, we were very intentional in thinking about where to store our results, and you will potentially see this different... Done differently in other places around the around around the country. We intentionally chose to put it next to our lab results in results review and not into flow sheets or observation, which are discreetly documented by our clinicians. And the biggest win here... While there's many wins, the biggest win here is that it's right next to the patient's other lab values. This provides visibility across the health system. We actually just got contacted by some of our psych... Our behavioral health and genetics specialists who are trying to get insight into their patients with diabetes or elevated blood glucoses, and they will be able to use the same data stream and be able to see the results from our endoclinic, which is very exciting. As well as... Because we were integrating from three different vendors and aggregators, we are able to actually map the results from those three different places into a single place within our EHR. So instead of going to three different places based on where that result is coming from, it's a seamless experience on the clinician side, and it doesn't matter where those results come from. It's the same experience, which has been a huge win. We also know that we can't normally put PDFs within flow sheets. And so at the bottom of this, list of variables in the results review on the left, you see a little icon, that actually links you out to the PDF that gets resulted as well. And so all of this being in one place, is a really, really nice. We've also... With this entire process, I mentioned the 10 to 20 page PDF, reports that used to get printed out. We've actually also redesigned our entire clinic environment and then have installed larger shared screens in all of our clinic rooms that these PDFs are now actually shared live in the clinic, with the providers and patients looking at them together and going through the data rather than just the provider looking at that information and reporting out to the patient what they're seeing, which has been a huge win for for patients. As I mentioned previously, we did standardize all the vendors metrics so that a single, like, time and range from our diff... Three different integrations all go the same place. We've been lucky in that with the work of the iCode group that we'll refer to throughout this presentation as well. We have increased national standards around these metrics as well as now more recently have actual LOINC codes that we can map this to, that allows us, allows us to, when we send this, to map this to other health systems as well. And so while we actually have not, done the LOINC code mapping, that would be a simple update in our results in our results to actually create this linkage, if we were to share this data out more broadly for t one d data, for, world news and reporting data, and all the other various things we currently do report a number of this data to, while not using it for HIE does at this point in time. And the other big win here as well is that because we chose to use results review, families can actually see what the providers are seeing after we pull it in in their patient portals next to their lab results and all their other diabetes care. And patients have really enjoyed this aspect, and I'll share some quotes here in a minute. Additionally, we found out as we as we did this integration, our initial purpose and goal was to get 80% of the data for eighty percent of our patients. And so we knew that some people would still need to go to the different vendor platforms to get all the information they were seeking for an individual patient. And so as we work through that processes, we realize there is still significant benefit in actually being able to go to the different vendor platforms. And so with two of our vendors, we actually now have direct direct connect, within our EHR, like this button that's in this slide, that allows the provider to launch directly into that platform linked to that patient. This again removes the sign on credentials, and we are able to use the... Our internal sign on system that's validated through our EHR, once those providers have been linked to our clinic, which makes this much more seamless. This is all, enabled by smart on FHIR technology and allows that deep dive into data again while sharing it with families on those bigger screens in those clinics, which has been really helpful. I see a question from online. How often is the data updated? Currently, what we are doing with the order is that anytime that order is released, that that data pulls in. So it pulls in... We've made the choice to consistently pull in fourteen days worth of data anytime we choose to pull that data currently. We'll talk a little bit about in terms of what other options are here a little bit later. And so I showed a really complicated diagram and alluded to all the different ways that these processes could potentially fail. And so I don't like to say that this process is perfect, and we do still occasionally result to flow sheets in manual transcription, unfortunately. Our biggest reasons for failures are that the patient's data doesn't reach our charts, is that whatever device platform or device they're using is currently not one of our selected that we're integrated with. So one of the struggles of our current state is that we still have some manual processes based on the ones we aren't integrated with while having this advanced capability with some of the other ones. So we still have to kind of manage the expectations and make sure we account for both workflows in our day to day clinic processing. If, patients aren't connected to our clinic or aren't uploading data for whatever reason, whether that is, because their device is not connected or their account is not properly set up, that can be an ongoing struggle. Some of our vendors and platforms, depending on the device, don't have digital connections and require manual drivers and plug ins to get some of that data, into the platforms. And so if that's the case and there... The patients don't have the capability or are not doing that process, we might, be, missing some of that. In terms of data not flowing in when the patient, is actually with us, it's possible that they do have an account, their device is connected, and it's a device that we would expect to see. But each patient has to consent to join our clinic environment. And so without joining into that clinic environment, we can't pull that data through our integration streams. And finally, as silly as this sounds, the process of actually matching patients from their chart, in the clinical environment to the different vendor platforms continues to be an ongoing struggle. You'd be... Think this this manifests itself particularly in the pediatric space where we frequently see parents' emails, parents', date of birth, inversions of date of birth between US and metric systems, nicknames, as well as some of the matching, scores use MRNs, that families often do not readily have access to, and don't include when they go to sign up for their accounts. And so actually matching the patients to their different vendor profiles is an ongoing struggle. We do have an ongoing failure rate of upwards of between four and nine percent per month, currently with our biggest vendor. The other piece here is we can also only match one to one, in terms of the different, accounts and certain processes of pump initiation create additional accounts for patients. So when a patient switches from one type of pump or one diabetes technology to another, there's a manual reconciliation process that needs to happen with their accounts. So that's requires an ongoing process for your clinic... For the clinics and the clinical environment to be aware of. So now that we've built all this, what are clinicians saying, in terms of where where did we... What wins did we have? Integrating the diabetes device data into the EHR has significantly improved access and the use of the data in the daily clinical environment It has reduced the number of steps required to access data, especially in busy clinics or when clinicians are managing phone calls and different insulin adjustments via different workflows, such as remote patient monitoring or evisits during the same time. And really being able to share this data with families and have that engagement with families has been a huge win for our clinicians. Additionally, from our families, they really like this being able to see the results in their health system patient portal. They know... One patient family notes that it's really hard to see multiple patients' data, multiple children's data through the vendor system, and so that this has been much easier. They love the idea of the CGM metrics, the PDF, and the labs all being in the same place. And they're really excited about the possibility of using this to collaborate and really change that relationship with providers going forward to really shift the paradigm of diabetes care into a more collaborative, interactive process. Great. Thank you, Michelle. So in this next section, we're gonna talk about some of the decisions behind, EHR integrations because some of them do affect who gets counted for quality reporting. Alright. First of all, there are many different integration paths to get CGM data into the EHR. Some of these, you may have heard of. There's Redox, Zelph, the app launch. That's what Michelle was talking about for viewing interactive data. There's direct integration, which vendors could do with FHIR APIs. And there's even Epic Aura, which is one of the newer options available. Deciding which path to choose depends on what sort of data the whole system... Health system wants. So all of these, except for the app launch, do support discrete data write back. They also vary based on which sort of EHRs are supported. So if a health system is using one of the less popular ones, they may be more limited on what option they can choose. Additionally, the price for these differs, the time to integrate, and just the overall technology differs. One of the other factors to consider beyond just CGM data is, and Michelle's alluded to this, you know, what other data does the team need in the chart? If they want insulin metrics, if they want... If they have a lot of patients on AID, they're gonna need to choose which vendors are gonna support that. Next slide, please. For title specifically, our integrations take about three to four months, and that's pretty typical across vendors. So these integrations do take time. A lot of it is wall time and back and forth, but something to be aware of as you're planning this out with your IT teams if you're a health sis... Health system. Next slide, please. So quick word on standards. There's h l seven. There's FHIR, and then we talked about SMART and FHIR a bit. So h l seven is what most health systems run today. It's very reliable, but each interface is mapped site by site. So how data gets coded and file... And filed can vary. FHIR is a bit newer. Data has the same structure everywhere, which is a big advantage, and that makes it easier to share downstream such as with health plans. NCQA's digital HEDIS measures are built on FHIR, and iCode and iCode two both recommend FHIR as the primary means of data exchange. Smart on FHIR is a secure way to open up those vendor apps from the patient's chart. It's very helpful for data review, but by itself, it's not gonna move data. You still need a direct integration with FHIR APIs in order to write data back as I touched on before. Next slide. Thank you. There was a question about this, how often data is written back. The answer is it depends on the clinic. So, the type of order, first of all, can vary. The... Sometimes our health systems want the clinician to create the order and sign it every time. Obviously, that means the order cannot be delivered very often unless the provider is available to submit it. Some other systems use what's called a standing order, which means that any MA or front... Frontline staff can release the order similar to how you would handle a point of care a one c. This makes ordering much simpler, and this is what Cincinnati Children's utilizes. The other aspect of this is what signals trigger a CGM data write back. At Cincinnati Children's, the data is sent when the staff release the order. But, in my experience, other sites send the data when new device data is uploaded or on a timed cadence such as every couple weeks. And the data can also be written back when a patient checks in for the appointment. So all of these automate the ordering process even further and potentially result in more data being written back to the HR, which means you'll maybe have more recent GMI available. Okay. Next slide. Thanks, Michelle. This gets into decisions for GMI reporting. So, again, how you configure that CGM feed is gonna determine which readings ultimately count for HEDIS. Some questions to think about on the clinic side is how much data is enough. NCQA requires a GMI to document its date range, but it doesn't set a minimum wear time. So that's up to the clinical team. A GMI from three days of wear, obviously, is not gonna be as meaningful as from twelve days. We do have, you know, some standards, recommending 70%, for example, of that fourteen day period. Second question, what is the reporting window? So fourteen days, thirty days, ninety days, those are all gonna give different GMIs because they include different amounts of CGM data. And as you know, patients, their glycemic control can vary quite a bit over time. The third question is which GMI ultimately gets filed? As I touched on before, automated feeds can file dozens of GMIs a year. And the measure ultimately is gonna use the one that's the most recent, which might be the one that lands in December. And it may be one that a clinician has not looked at personally. So those are things to also consider. One other slide on this, Michelle. So, yeah, there is also potential for several values to share the same date. So if you file both a fourteen day and a ninety day GMI on the same day and the patient also came in and took a lab a one c, NCQA has the lowest value count towards that patient's GSD measure. So just worth agreeing on a role within the quality team if there's multiple data sources providing that same metric, if if that's what you want to do. Lastly, rounding. So GMI, you know, if if you have a GMI of 7.96 and that rounds up to eight, that patient may now not count as being controlled. So those are additional considerations just to talk about. Are you going to do rounding? Is your vendor doing rounding before it even reaches your EHR even? Maria, I'm not... I'm just gonna share a really funny story. I remember when we were doing integration, and one of our results had, like, three decimal points. I was like, I clinically don't wanna look at three decimal points. This is horrendous. And it's now dawning on me of, like, for some reason Maybe it is. Yeah. Purpose, we... There's a reason for it. But, like, from the frontline staff, that's additional noise that they need to process. Yeah. Great. We do have a question in chat that I'm just reading. So earlier, I heard Cincinnati Children's received a grant to support this effort. But considering time costs and any technical slash licensing costs, would you say that this project has significant financial cost? I'll let you answer that, Michelle. Yeah. So I think we have... There... There's a couple different aspects of the cost. One piece is which team is gonna do the integration work and the build. And if you're set up, with an operational team kind of running this project, that would be similar to any other work you do with your information services colleagues within a health system, then often it's just a, just a process of prioritizing resources. So for us in the health system, the grant really allowed us to prioritize the resources to have the integration team, the lab team, the ambulatory information services team to get all the clinical, clinical colleagues together to make the decisions around, are we gonna use fourteen day values? Are we gonna push? Are we gonna pull? And then, the biggest piece is really the ongoing licensing costs of these products, and trying to figure out what's... Where where is that worth it for you, how do you transition patients appropriately if that becomes more reasonable for you? And so working through the where are your patients now, where do they need to go, has been a big big piece of this process, where we've tried really hard to enable all of our patients to stay with whatever platform that they're currently on. But that obviously, results in significant costs for us with, having multiple different vendor platforms. Hopefully, that answered that question. So to brag a little bit about where we are now. So we have about 300 patients per month now getting CGM results directly into our EHR through this order release process. This is 40% of our encounters. This means 3,000 digital data entries per month that were previously manually transcribed by by our provider team are now no longer being transcribed, and we are saving $10,000 of printer and toner, costs per year, which feels like a crazy number, but it's the number that was actually provided to us by by the division. In our in our overall results per month, we see significant increases as we've added different vendors, onboard, as well as when we initially made that significant shift of every patient needing a new order for the results to come in and being able to allow anybody in the clinical practice to release the order to pull the results in. That was the other big, jump in our data here. As we've alluded to previously, the CGM data is only one piece of all the data we need to make these clinical decisions. And my leading theory of that delta of only forty percent of patients still getting this integration results versus those that are still being manually transcribed into our flow sheets, is that we're still not getting insulin delivery, pump settings, etcetera into our results. And so providers are still transcribing a whole host of other metrics, into our into our flow sheets. And so, doing the education and the process of optimizing these workflows, continues to be ongoing work for us. And so for the provider teams, as I mentioned in terms of the in terms of the kind of some of the decisions we made. So first is trying to figure out which patients you will be actually able to capture. And so patients that might be unmatched, might not be able to be connected digitally, or that have devices that are not supported by whichever vendor or aggregator platform you decide to choose will ultimately not be visible in your integration. You will also need to figure out where your health system is in terms of h l seven versus FHIR. We started this process back in 2024, so our system was overall much more comfortable using HL seven. Since that time, we have now mapped to the ONC standards for FHIR three, version three, as well as are talking about the new requirements for version five coming as soon. And so we are progressively gaining more and more experience with FHIR integrations. In terms of lab, security and compliance, we talked a little bit about patients opting in, to the clinic in order for us to receive that data. Additionally, because we put the results within our laboratory results window, there's certain lab accreditation rules we had to follow and had several meetings with our lab folks, since there are certain credentialing processes and all of our results are explicitly marked as external results since our lab cannot verify any of the CGM results. We also alluded to the financial feasibility in terms of what does the actual install look like, which vendor and... Which middleware and platforms do you already have licensing with and have experience with, as well as where are the ongoing costs in terms of the integration and licensing with your different vendor platforms. Operational capacity, we mentioned this ongoing need to manage account linkages, and we do have specific clinical staff that has FTE per month, whose job it is and clinical job it is to kind of work through certain work queues that we've set up, to manage the duplicate accounts. Obviously, we... We're here as part of NCQA and HIE does measures trying to figure out what kind of contracts are you using, both currently with your CGM vendors and aggregators, but also in terms of, more population health management and shifting away from the classic fee for service model and population health, are there are there different incentives that could change this equation for you? As I mentioned, with only 40% of our patients currently being in, being part of the integration. Part of that is ongoing clinician education about the integrations, but also making sure that our patients get a sense of what they can can do with the data and understanding. One thing we initially did is patients were getting all sorts, of notifications of the results, in their in their patient portal, and we actually suppressed some of those notifications because they didn't feel like that was relevant. So both training on the clinic... Clinical teams, but bringing that pay... The voice of the customer and the patients into this. And then ultimately monitoring, what's your data completion look like? What is this looking like? Are your failure rates? The fact that I am able to kinda show you what our results numbers look like, what our failure rates to look like are partially enabled by some of those work being grant supported. And this is all work that has been previously highlighted by Doctor Espinosa on thinking through integrations like this in the diabetes space. And I will turn it back over to Raya to think about from the health system... Or health plans perspective. Yeah. So, again, modeling that same framework for you all on the plan side, just create a mirror image of Michelle's questions. So for you all, as you're working to make sure that this data is available to you to report, the format and the codes are very important. So GMI and a PDF is gonna be very hard to count, and a discrete LOINC coded GMI will count. Again, Cincinnati Children's, their data is discrete and standardized, but without being LOINC mapped, it's not gonna be usable for your purposes. As Michelle mentioned, because at least in their case, each vendor's data is landing in the same place, it's not a huge lift for them to add those link codes, but that may not be true for every vendor in every health system. Additionally, ask about date ranges because NCQA does require those GMIs to document one and really get detailed about which GMI is getting filed and which ones are gonna be utilized. What is the CGM wear time over that period where that was being recorded? And then think about who is getting missed in all these integrations. As Michelle mentioned, even now with several, you know, vendor integrations, we're not able to cover everyone. And that's for a number of reasons. That could be a whole other discussion. But every unmatched or uncoated... Unconnected patient is gonna be a gap that this data is not gonna close. I... I'll just go to the next slide here. So, yeah, four takeaways. We just have two more slides left, because I know we wanna leave time for q and a. So first, structure data is what counts. Touched on this quite a lot. Second, expect gaps and plan for them. So not every patient say it's gonna reach the chart. Third, agree on those GMI rules before go live. And fourth, the EHR is only half the path. So health systems and plans have to agree early on how this data will reach plans, whether that's supplemental data, health information exchange, or FHIR. And in closing, if you go to the next slide, stepping back, let's look at the big picture. So how all of this data connects, to better care and outcomes for people living with diabetes. So this all starts at the bottom with a connected data foundation. Patients use CGM from many manufacturers, as we talked about, and nothing else is gonna work until the data is brought together into one consistent, reliable dataset. The next layer, which was today's focus, is getting the standardized CGM metrics into the EHR. That is what is gonna make quality reporting possible, and this reporting is really just the beginning. The real value comes when we use that data to manage populations, close gaps in care, and make care pathways more consistent. And what's very exciting in the future is that with continuous CGM data, it does become possible to risk stratify your population as often as every day, not just once a quarter or once a year. So that means care teams can reach out between visits instead of after an ED visit, which is better for patients and avoids cost for everyone. So, again, not standard of care yet, but I think it is a future that many of us envision, and that we're all building towards. So we all have the goal of improving diabetes care. And so my, question for you all then is to go back to your organizations and ask how can you better use CGM data to improve quality. So thanks. That concludes our talk, and we can go to questions. Great. Thank you both, for such a wonderful presentation. We do have some questions in the queue. So the first question is, is the data able to be shared with health plans? Yeah. Thank you, Nico. So right now, we are in the process of of navigating our first, value based contract. We have an ACO down here in Cincinnati, and so we're trying to figure out the best way to do that. Because our... Because of the way we've integrated the different vendors in the same field, once we add those LOINC codes, they will also be sent to our state health information exchange, and so have pathways there. So based on everything we've set up, we feel relatively confident, that we have much better pathways to do that than previously. Even though we're not quite doing it yet, we're already using that data for world, news reporting, as well as t one d exchange reporting. Great. Thanks. And then, Ria, would you like to also expand on that from the Tidepool perspective? Yeah. So I I think Tiepool's role is really making sure that we are providing those link codes, which are relatively new for CGM data. I think there's been a lot of standardization in the last couple of years and doing what we can to to, again, educate our health sis... Our health systems on providing that and doing that mapping on their end. But, yeah, out of the box, our data is gonna be mostly sent to the HR, utilized for the clinical workflows that need it. Great. Thank you. Alright. Next question. Would you advocate for additional data standardization to further reduce complexity? I love this question. Yes. Yes. Yes. Please. Yes. Anybody who's on board, let's do it. The fact that we now have the LOINCodes are helpful. Even with iCode standards. We spent a lot of time reconciling the date ranges, the time ranges between our different vendors and aggregators, the decimal points between different places. If we have an extreme value, for example, a mean, blood glucose value, some vendors will report simply high, which obviously is a text number that a fee... For a field that wants a numeric value. So trying to sort through all of those little little data standardization things that ultimately, make or break how we manage this data nationally and at large scale. I think we are finally at a place where we have enough... We have more and more people at the table with iCode with trying to really do this work at the frontline, that we're starting to understand to... Is understand to both see the opportunities, but also the the challenges that we continue to face. So I'm hoping we can come... Continue to come together and, work more towards increased standardization so that, our lessons learned from our integration can hopefully guide and make the path a little easier for others. I'll also add that, the rising tide the rising tide alliance is another great organization. They just released a white paper that Tidepool as well as several other manufacturers contributed to that goes in-depth about how each of us report our CGM metrics today. And it's mostly aligned, but there's definitely still some ambiguity, in what is considered the standard today. Great. Thank you both. I have another fun question. I imagine a lot of providers would love to integrate this, but maybe limited in capability to do so. Outside of the publications and some of the information from this presentation, are there any specific ideas you can recommend to make the argument at a system level to invest and prioritize this work? Yeah. So I think this has been a really evolving area, especially as we continue to advance asynchronous care through evisits and remote patient monitoring. I think there's huge opportunities in remote patient monitoring, in value based contracts, and thinking through how do we manage patients outside of that fifteen to thirty minute quarterly appointment that can truly drive value both for the health system as well as the patients if we do it the right way. And so I think that would be that would be the biggest win. If you're in a position where you have the majority of patients on one platform, then I think you have a easier early win than a highly specialized type one diabetes clinic, that basically wants to enable patients choice the maximum capability. So I'm thinking especially in the primary care setting, if the vast majority of patients are on Dexcom or Abbott's CGM devices, the equation becomes a little bit less complicated than in a hyper specialized type one setting. Thank you. Okay. We have this question from LinkedIn Live, actually. As CGM data becomes integrated into digital HEDIS reporting, how will health systems ensure that the information triggers timely clinical intervention when patients demonstrate poor glucose control rather than simply becoming just another data point in the EHR? Yeah. No. It's a great question. Thank you for for bringing that one up. So, this is actually exactly the the the opportunity but concern that we originally weighed and why we originally went with a pull mechanism enabled by h l seven two, rather than a prospective push mechanism is that we... When we first started this in 2024, we weren't ready to proactively act on that data. With with Raya's mention of Rising Tide Alliance, we are now much further along in our RPM development in proactive outreach programs within our diabetes population as well as also using evisits. And so now have a much different concept of how we can manage patients outside of the clinic that will ultimately allow us to think about how do we drive clinical decision support, elevate those patients that have acute changes in their glycemic control, or that we know are chronically, uncontrolled, and we need to have different intervention pathways for them to try to get them on a better path. And so, being intentional of what that data looks like, I think is really important. And it's something that we've been really intentional about, and we're slowly now ready to make transition over to more population perspective data. Great. Thanks, Doctor. Haupt. One more question to you. What is the patient consent model? Is additional consent required for data integration into EHR? Yeah. So this has been an interesting, piece of it. The consent model seems to be slightly different from the different vendors and aggregators and also dependent on how the data is moved. So the FHIR integrations, the FHIR integrations are often done via either a... Either via patient consent that gets pushed through the patient portal, or, is is really the most common way. They... We can also push some of them via an email or a text message and then have them open that link on the on the device that has the app of that vendor installed to create those linkages, and do that consent. While some are the... Since every patient is already consented to sharing that data in that clinic environment with the aggregator or the vendor. Some of it flows directly if we're able to successfully make that match. So in a lot of ways, it's been an interesting hodgepodge. But ultimately, if a patient doesn't consent to the clinic seeing that data in the first place, there's no way for us to get it. And then depending on the level of integration, there are often additional consents that the patient does. We've not had any pushback on patients in terms of doing those consents. And in fact, from the patient wins and being able to see that alongside their lab results and really aggregating all that information together, patients have actually been more than happy to consent, with that. I imagine the... How we think about this going back to health plans, outside of when we... As we transition from fee if, makes more set in a fee for service model predominantly, I think is then slightly different again than as we transition to value based contracts, if that makes sense. Yeah. Thank you. Okay, Rhea. Got some questions for you. Could you expand a little more on Tidepool, your role as a data aggregator? What CGM manufacturers do you work with? And how do you interact and process this data that you receive before exchanging it with another entity such as a health system? Thanks for the question. So Typool works with all major CGMs. That includes Dexcom and Abbott Libre. We also receive data from pumps and other AID system... Systems through our cloud integrations. So that includes Typo Loop and Twist. And so any CGMs that are supported by those AIDs such as Eversense, we also receive that data. Our data is deduplicated because as you can imagine, some patients may be uploading data from their Apple Health, as well as from their Dexcom app and other sources. So we we deduplicate that data and process it in accordance to the iCode recommendations, and that is ultimately what gets sent to the EHR through Redox or Zelp, whatever intermediary we're using there. Thank you. Another question back to you. Could you talk about Tidepool's involvement with health plans or other entities beyond health systems? For example, do you work with health plans now or intend to in the future? Yeah. Right now, our interaction with health plans is not as high as I think it should be. I think as clinics are moving towards value based care contracts and doing more proactive care such as through, yeah, RPM monitoring and, like, you know, risk stratified dashboards, it does become more important that our systems are reporting on those outcomes and ultimately improving those. I think some of our clinics are already doing great work there, and, it does make sense now that we start working with plans. Absolutely. Thank you. And then, doctor Na, for you, could you talk about the state of FHIR readiness at your health system? You talked about h l seven v two. Is there any intent on transitioning to FHIR or any data being exchanged by a FHIR API now or in the near future? Yeah. So we originally made the decision to go with h l seven initially because of the comfort of our technical team and where we were at at that time in 2024. We are currently in the process of exploring a new integration with FHIR, hopefully, for early next calendar year, which will use the patient portal linkage. And so we're excited to explore that for more of the prospective pulling of data that we would get every two... Or every seven to fourteen days and then try to manage more of the population health side of things of trying to triage patients outside of the clinic visits. We are at this point mapped to the FHIR version three from the ONC. That's the national standard, and we are in the process of mapping to version five, which will be the upcoming standard. We are continuing to explore and use this predominantly in the research setting right now, but are continuing to build the expertise to do this, more in the actual clinical environment for use cases such as this. Great. Thanks. That's really exciting to hear, actually. Yeah. Definitely keep keep folks updated on that. It looks like there are no more questions, and it looks like we're close to, time. So I think I'm just gonna wrap it up here. I'd like to say thank you again to our presenters, and thank you to you for attending today's webinar. The materials will be available on our NCQA website at the end of the week, and I hope you all have a wonderful rest of your day. Thank you.