Welcome, everybody. Really excited to get this discussion about standards development for wearables going. I think all of us have spoken in advance, and hopefully we'll have some audience participation. Those of you who have been working in the space know that HRS has been in the standards development space for implantable devices for a long time, 15 years. And so now with the advent of wearables moving in, the question came up of whether or not a similar effort might be appropriate, either through HRS or more broadly for the wearables. So I want to start by just going around the table and letting people introduce him or herselves. We have an interesting group, I think, representing all the different groups that have a stake in this game. Why don't we start? We'll start with you, Megan. Sure. Thanks, David. Happy to be here. So my name is Megan Turchio. I'm an assistant professor at Columbia School of Nursing. My background is in nursing, but I have cross-training in informatics, and most of my work is applied in cardiology with a specific focus on atrial fibrillation. Hi, I'm Andy Everson. I'm a software architect at Medtronic, focused on our information systems. My background's in data science, and after working on different data science problems for a while, kind of realized that the biggest barrier to making AI models or even understanding the safety or efficacy of our devices or software as a device is really lack of data quality. So about six years ago, I kind of started working on interoperability and standards development, and I've been participating on the HRS working group for the last three years. Hi, my name is Mintu Dharakia. I am chief medical officer and chief scientific officer and head of product at iRhythm Technologies, which is a cardiovascular diagnostics and digital health company. I'm also a professor of medicine and an electrophysiologist at Stanford. My interest here is related to both the large data set kind of observational analysis we've done where we've integrated device work as well as clinical trials in the space. Hi, my name's Uday Kumar. I'm the founder and president and CEO of a company called Element Science. We're building a wearable defibrillator, patch-based. I was also the founder of iRhythm Technologies. I teach at Stanford BioSign. I'm on faculty there since the last 17 years. So since I've been in the intersection of wearables, AI, ML for quite some time, I've had to raise a lot of money and battling uncertainty. It's an important topic. Hey, my name is Chris Irving. I'm the chief experience officer and co-founder of Merge. I've also been on the IDCO work group panel for probably about 10 years now. Sit on a few other panels as well. I'm a data guy, also a design guy for the past 30 years. My interest here is around data, getting data. We ingest data from a lot of different devices and a lot of different modalities. I'm still very interested in getting the data however I can get it. Hello, I'm Craig Reister with Boston Scientific. I'm a system engineer and my day job is working on our latitude remote management system, kind of specifying that, helping design that for the future. The other hat I wear is our EMR integration and data integration, primarily for the remote management, but for also our in-clinic platform to some degree. And lastly, but not least, I work on the IDCO nomenclature group and we've worked in implantable standards for more years than I can even count at this point. I'm George Schroep-Mendenhall. I'm a cardiac electrophysiologist over at Scripps Memorial Hospital in La Jolla. I was a graduate of the Harvard HST Health Science and Technology MD program and then did a lot of computer science basically in undergraduate and was thinking of going into that field but continued with electrophysiology. I'm also the chief medical officer of EverBeat, which makes a wearable arrhythmic detector, and the chair of the interoperability committee at HRS, which brokers between all of the other interested parties. Terrific. Thanks. So we have the groups. We have the constituents. We have representatives on the table represent, I think, the entire spectrum of stakeholders. We have the clinicians. We have representatives from the implantable space who have experience doing this for implantables. We have middleware vendors who help manage the space and then med tech. So I think it's a great group. Hey, David, quick question. Since we have an audience here, does it make sense for us to kind of turn this way so we're speaking to them a bit? That's a great... I was going to say, I am going to follow the... I'm going to try to check the Q&A, but if I miss a question, I really do want to make sure we get you guys involved. So feel free to raise your hand. And that's... Thank you, Mintu, for suggesting that. I really want to make this interactive. Just to outline, we sort of will try to follow to give you the arc of our discussion. We're going to start with some basics, including what do we mean by wearables and what do we mean by standards, then move on to why we might want to consider standards. Is there... Are there other ways to do this? There are some regulatory considerations that might affect this space, so we'll touch on those. If time permits, we'll talk about the different pathways that we could consider for developing standards and then we'll close with some final thoughts from the panel about whether standards are the right way to move forward. So let's start just by talking about what we mean by wearables. And I thought I'd start with our clinician representatives. There are a lot of people who have been clinical, but the clinicians at the table... Our clinicians right now are primarily Megan and George. So Megan, what do you think we mean by wearables? Sure. So when I think about wearables, I kind of think of two different categories. I think about the consumer-grade wearables that we're all able to purchase on our own, things like smartwatches or the AliveCore device, and then there's the sort of medical-grade devices that could be prescribed or implantables and sort of cardiac implantable electronic devices. Those are the main buckets that I think about. Stuart? Yeah. I think that as time goes on, there's going to be increasing non-standard wearables, right? So right now, we have people that wear something on their wrist, and you can touch the opposite side. That's almost a lead-in-one EKG, but we're going to have people that watch their chest or touch a ring to their chest, and that gives you approximately a standard EKG, but it's not really quite a standard EKG. So I would say wearables is just anything that we can get physiologic data from that we're wearing, and we can possibly take it off, and it may or may not be standard, and that's part of the issue that we have today, to define all those standards. So those are all heart rhythm examples. Should we limit this to heart rhythm? No, of course not. I think that we have wearables for physiologic data. We'll have ballistocardiograms, and soon we'll have SpO2 meters and PPG wearables. I think if you wanted to broadly define wearables, you could even say things that are looking at gait instability and things like that, right? So in the future, you can have plugins for your watch that detects if you're walking with an unstable gait, or whether you're having frailty detectors or fall detectors, and all of these things could be binned in that wearable category, too. I think it's important we clarify what we mean, though, because, so is a CGM device a wearable? Is it not? What about the next sensor, right? And so are we the ones to opine standards across that industry? Because that industry has already created its set of interoperability with personal health records, you know, without HealthKit and others, right? So I think it's, you know, there is a risk of overreach here, as well, that we have to be careful about. Yeah, great point. Yeah, Udi? Yeah, I would just add the other axis I might think about are really, one, is it, what's the purpose of a wearable as part of this? Is it for screening? Is it for clinical diagnostic? Is it therapeutic? And then, is it regulated or not regulated? Obviously, in our world, that's a big deal in terms of differences. And then, to Mintu's point, who makes that determination, particularly not on the whether it's screening diagnostic, but really on the regulated, because that changes a lot of what has to happen. Right, right. Great point. Chris, you have to consume all this data. Any thoughts? Yeah, we see data from all these wearables and everything under the sun, you know, that was mentioned, from Apple Watches to halter monitors to MCOTs, even glucose meters. So the data comes in, some of it's more structured than other data, some of it comes in in more dependable formats than other data, but I think it's all worthy for this discussion. It's going to be a very broad topic if we think of wearables as anything you can literally wear on your body. I do think there is a distinction between those that are just measuring and those that are providing therapy. Do you think we could structure this framework in considering what the physiologic data is rather than the device? Would that be a potentially effective way to frame this? I think it's easy for an ECG, because it's a common signal, it might be easy for glucose, but can you conflate an irregular pulse notification from one vendor who has one algorithm and has a specific positive predictive value with another vendor's irregular pulse detection? Can you conflate the wearable tech of a heart failure diagnostic that's AI-based of one company versus another? And so that's where it gets challenging, because I would argue that data is not interchangeable. I would just add also that I think to Mintu's point, if you get down to each particular thing, it's a never-ending rabbit hole. So I do think it might be a little bit more important to think about, if you think about consensus standards or other things, what's the purpose, what's the outcome? So if it's decision-making or clinically relevant versus is it just for personal use, there might be ways of cutting that that gets, again, at why is it here? As opposed to focusing, again, wearing my Stanford bio-designer, we're thinking about needs, really think at that level versus getting down into the technology itself, because it's never going to end otherwise. Yeah, and to that point, the need for the implantable side was a whole care paradigm of remote monitoring, where the data was never intended initially as conceived to go direct to patient. So you needed a better way for doctors and nurses to look at it, to program and guide therapy. Now we're taking that and exploring whether that is applicable to data that maybe wasn't intended for the clinician. Yeah, right, excellent point. I think we should just directly state, yes, that's the central problem for all of this. As you said, there's a massive heterogeneity in signal quality coming in. There's a massive heterogeneity in the types of recording. When you step back at this, how hard could this be? I mean, this is a series of numbers, a series of little measurements that's coming in. We just label them and put them in a chart, right? I mean, it's very easy. But when you go down this kaleidoscope, there's different ways of acquisition of the signal and different qualities, and then people add on specific algorithms, right? Something as simple as pacing minimization or even detection of the QRS on PPG or something that you're talking about. There's so many ways of doing that. To label that accurately and to have it so that it's trustable by somebody that's not a domain expert is very difficult. And last thing is intended use, right? So I'm not a regulator, but a pre-diagnostic, a 510-CAD clear, if you start getting interoperability to pipeline that in, has the intended use changed? Does that have any regulatory implication? Excellent points. Thank you. Well, why don't we turn to what do we mean by standards, which I think is not a simple question. And why don't I start, Stuart, with you since you've been involved in this space for implantables and give us your thoughts. Yeah, that's partly what I was saying before. The standards have to describe the data in a canonical way that everybody can understand what the... I would say intended use is kind of after the standard maybe, but you're right. You could make standards that kind of imply intended use, and that could be very, very, very difficult. I tend to view this in two kind of distinct ways. One is a proscriptive standard, right? We're as a regulator or as a body trying to say, okay, everybody, this is what you use. And then others is somewhat descriptive, where industry gets together or through whatever reason people are starting to communicate, and that becomes a coalesced standard, and then we just formalize that standard. And the latter is usually what happens. If you look at the arc of history, people don't go out and define a computer standard. And if you do that, you run the risk of being wrong and people need other needs and then your standard is obsolete. If you're too late on the descriptive standard, people have already used it and you're a little bit of a laggard and it might not be as useful, but that's generally how things go. If you look at interoperability for any sort of, let's say POSIX or something like that, or some sort of computer standard, people start making the system calls and then you go and formalize the system calls, what everybody's starting to use, and that aggression on whether you're trying to be too forward thinking or too late with the description of the standard is something that we always have to balance as somebody that's in a standards-making organization now. I think even at a higher level, though, it really starts with the clinical needs. Why should patients be sending this data? What's the purpose for it? How frequently should they be collecting this data and then which devices are valid in this use case? So I think that's what we need to be thinking about, too, and getting to the technical standard that supports that. I would also add that if you think about how every technology is developed, it's really based on risk. So if you think about a fundamental premise of all technology development, of risk management and your risk matrix, we all do, as everyone here, that might be a way of thinking about it at a much higher level. What are the risks of whatever data you're collecting and for whichever user? And that might allow us to categorize without, again, getting into the actual technology because it's useless to have a standard. It has to be able to outlive itself a little bit, not just for the technology of the day. And I think oftentimes in a very technologically driven field like EP, we oftentimes focus on what we know today as opposed to things that are coming down the pike that we don't even know about. And the one risk of interoperability is actually loss of information, not because of mapping, but the contextual information is lost. So we're doing a lot of patches a year, a couple million, and the thing that most health systems and doctors want is EHR integration. That is like the common denominator of interoperability. They want to be able to see it in their systems so they're not logging into a hundred different things, right? We all know that as clinicians. So they want to see the whole report. If we were to take out our AF burden through some standard, the risk there is someone looks only at the digital readout of an AF burden trend and doesn't look at the report that is much, much richer with contextual information, right? I think a company like Merge that sucks in all the data parameters has done it right where you get all that information, but sometimes that report, so to speak, is priceless. And if they don't have standards for every little data element, then you could start creating risk. Yeah, that's a great point, but I want to jump out of order just and talk about why standards. I think I'll ask Craig to describe how we could have a standard but still include the more detailed proprietary. There are ways to do that, but why don't we just first answer, I think, the really important question. What's the clinical need we're trying to address with standards? And I don't know who to start with. Anyone who wants to jump in first? Okay. Well, the clinical need is that right now we go to too many data silos, right? I mean, when somebody comes to me with a new login portal that I have to go in and check to get some sort of value, I shudder, I cringe. I mean, I don't need another password. I don't need to open up another browser tab and find something, download it, then upload it in a PDF to Epic, right? So we're at this kind of patchy medium space where we do have some quasi-integrated portals, right? So usually you click on your PAX portal and you get taken to a radiology page and you can view images nice in a pretty smooth environment. You go to, you want to see an echo, you click on the echo, it takes you to another application, but that application is somewhat seamless. It's integrated with the medical record. When you want to go to a wearable tab, even with the merges and the Geneva's and all the other aggregators, it's usually going to a separate portal or saving to a PDF. So is that something that we could streamline without data loss, without contextual loss and have it integrated for clinician workflow? So I would say both for the clinician and for the data aggregation and the scientists and the data wranglers afterward. And maybe also clinical interpretation, right? Because then you can sort of have a little bit more confidence in what you're seeing and knowing that it's sort of meets certain data standards and quality standards. So you understand how that data was collected in an ideal world, apples to apples, but we're not there yet. But I think the clinical interpretation is what we're probably trying to support ultimately. Cross-referencing in the clinical interpretation is, it would be very much facilitated by that. For instance, if you see an EKG, you see the peaky T-waves and you can go and see what the potassium was right at that same time. Right now, that's a very, very difficult task relatively to what we need. Yeah, I think it's great to hear from clinicians what they want and how they want it. Because every clinician has, I think, a different ask in this space. We're talking about like broadly, what data should we consider? In my experience, the clinicians want all that data, even if it's like steps or BPA. Anything we can send them that might be ancillary data to make a better decision on a patient, they welcome. But that data ranges from, like we covered, rings to implantables. And I think that standards, as they exist today, it is, as Stuart mentioned, it's kind of the way things are today. But I think that needs to change going forward because standards are not moving as fast as the technology is moving. And we're seeing a lot of, even at this event here today at HRX, there's a lot of vendors that have come up. They have new hardware. They want to get the data out. They want to work with other companies and they're wondering, okay, what does this data look like? What's the structure? How should I get this out to you all? Do you want it as a HL7 message? Do you want it as an API? And these are questions that everybody's asking. We lack some sort of kind of base nomenclature, at least how to structure this data. Should it be outputted as a standard? Should it just be outputted as data? I think that's a valid question. In my experience, standards move too slow, but from the clinician perspective, absolutely. Clinicians do not want to log in to each one of these hardware manufacturers to see their data. If there is data loss, it's usually because the data is not available to be exported discreetly from the vendor. So that's what we work with, with all manufacturers, Medtronic, Boston, iRhythm, everybody to kind of increase that data set so that there isn't data loss, but we're very careful always to show what's most important. What do you guys show in your summary sheets? What do you show on page one? So let's start there. I think we may be an enriched sample of people who want data, but I don't know if every clinician wants the steps. I don't. I really don't think they do, actually. We hear this a lot as we think of our product portfolio and future. What can you add in terms of the sensor stack? There isn't even a group of VPs who's like, I don't care. I just want AFib. I want to know who I need to ablate, and I could care less what their steps are, right? And then you go back to primary care. What are they supposed to do to that? What liability is encumbered for them? So that, I think, goes back to, is it even possible to generalize a single clinical need? Because as you pointed out, Chris, you ask 10 doctors, you get 11 answers. Rudy? Yeah. I would just maybe make a couple comments. In terms of building on Mintu's point about asking what physicians want, I can tell you when I founded iRhythm, nobody thought there was a need for another cardiac monitor type clicker. We have holters. We have vent monitors. We have MCOT. Why would we need something different? But you really understand the workflow and the business of where people get seen and all that, it's, they're right in front of you, these needs. And so I do think, again, taking a step back to a higher level, how do we really make sure that we're not catering to the practice needs of everybody today versus what are kind of economic and clinical needs to solve a problem? So that's one thing, just first, you know, how do we not get it out of the weeds of a technology or individual doctor? I think the second thing is on data, there's two, we're talking a lot about data from sensors, but I build a wearable defibrillator now, so it's a pure hardware therapeutic wearable. And so as people who build hardware, as many of the implantable folks here know, there are tons of standards we have to live by. Like every time, one of, I'm an EP as well, but every time you see an EKG, there's a lot of standards of just how that is characterized, is that really an EKG? We would all say so clinically, but to actually have a company make a hardware, piece of hardware to draw or create that ECG has a lot of IEC standards behind it. So there's a rich history of standards, good and bad, that actually exist for hardware. I think, you know, even in the early days of iRhythm, we had, we would go to vendors and say, we could put metadata in an HL7 message, where do you want us to send it? They're like, what? And the fact that we're 17 years later and still the same questions is kind of maybe why there's still a unmet need in this area. Right, right, great point, Craig. Yeah, I wanted to, so I'm a little bit of a, in this space, outsider looking in kind of from a parallel universe. So from the implantable standards perspective, our IDCO standard, the nomenclature, you can represent a good set of information from the device, kind of to follow on to your point is we can't represent everything. And various manufacturers have done different ways of representing that additional, very important information that we can't represent all the important information in individual data elements today. So going forward, if the standards are being considered, that the ability to represent, and that's in some way other than just simply PDFs, I mean, PDFs can sort of work, that's what we're using for the most part for the implantable side, but at least some sort of structure of how do you represent this additional information, will be very important. Yeah, and even on the PDF report, we can't forget that that's a standard and just being able to write that to the EHR with specific metadata is relevant. And then just kind of getting at how wearables might evolve if it kind of follows the cardiac devices trend is as the manufacturers have created more sensors, we create more and more algorithms and kind of the, before IDCO, the belief was let's get all the data clinicians, then it kind of reached a point where it was like, this is too much data, all the manufacturers are doing it and it's completely overwhelming. So IDCO is a really nice, simplified data set because nobody actually wants kind of the raw interrogated data and even when you normalize it internally, you might get 150,000 lines of XML, you'd see one patient a week if we sent that over. You can easily draw parallels between the PDF and the DICOM too, I mean, they're both kind of containers that if you have a searchable PDF, I mean, you can do a lot with that. Yeah, and then the other point I'd make is just like the benefit of standards is just from a patient perspective, if you have standardized data, it can go into your health record, now you have a transportable record, so if you get referred to electrophysiology, it comes in, it can be mapped to the field, so if you get steps, it maps to where you have steps in the HR and it's just gonna make it easier to kind of get a comprehensive view of this patient's health and give them the best care. Although I would say that sometimes giving data and like we're talking about data overload and a whole bunch of generative AI tools to be scribes in clinical summarization and now we're talking about full data operability, so does somebody really want 14 days of uninterrupted raw signal from an ambulatory cardiac monitor? No, the entire need that Uday mentioned was actually to distill that and not give it and have high confidence, right? So you're having sort of competing, needs competing with each other and it's gonna be very hard to distill this down to a single need that works. What about the paradigm of thinking about the data standards as providing one level of access to the data, maybe in the EHR, but the availability then to dive deeper, linking it to the original data, which I think what we've achieved with IDCO, any thoughts on that? Is that sort of possibly addressable? I think we have to strongly deconvolute the transmission of the data versus display of data, right? So obviously clinicians don't care about a data soup of activity and steps coming into the EHR, but if it comes into the EHR through a standard, then you can filter it through the epic and see, okay, wearable steps, oh, steps over time, oh, activity strength percent per day. So I think that is the idea. So we shouldn't hobble or stymie the transmission of the data and the creation of a standard because it will overload the clinician. The clinician can be filtered through appropriate display and appropriate interactions, and that's something we also have to think about. I think standards help kind of the software become a meaningful gatekeeper to prevent it from the EHR. So there needs to be valid reason for the patient to collect the data. The standard should help, you know, whichever information system, the patient facing system is being sure they collect it at the right frequency, maybe normalizing it and packaging in a way that kind of clinicians are able to read at the right time and then hopefully even get reimbursed for it. Or presented at the right frequency. Even if it's collected at a higher frequency, it can be displayed at a lower frequency or even selected, right? So we have to be practical with the clinician's need, which reflects also the clinical need. The clinicians and the clinical are hopefully aligned. We're doing, you know, the work patient interfacing, but then the underlying standards should not be necessarily hobbled. And I think this disconnect and formally thinking about these in separate ways will really help us develop these standards. Over. No, and standards as an underlying base, I think, is good. But if we use the example right now of Epic, Epic can map all of that IDCO data coming in. They use all the IDCO field value pairs. It doesn't take into consideration some of the logic you have to apply on top of that IDCO sometimes. And as we've seen, there's a lot of devices there. Every single manufacturer makes their own IDCO data set, if you will. They export their own data. And when new devices come out, they use those fields to support that data. Epic does not support those extensions. It doesn't support it when it kind of expands beyond that original data set. So I think that's something to consider too, is that this data is going to grow beyond what the standard supports. And how do we accommodate that? I was just going to also say that some of this discussion is kind of interesting because if you'd actually think about, you know, the practice of medicine and particularly not increasing reimbursements, more workload, you know, it's great to have all this data, but ultimately what I've found and what we see a lot at Stanford in terms of what unmet needs is, you just have to get physicians that can get to a point of trust. Someone asked about, you know, do you really want 14 days? And the first days of iRhythm when we had a report, people didn't believe that our EKGs were that good. So they asked like, we want to see the whole thing. They thought we were drawing it. Seriously. And so once we then gave them this huge packet, they're like, okay, fine. But then it moved past that. And so nobody asked for that now. Same thing with like everything in that. And actually the original zero report was supposed to be interactive. I have the whiteboard pictures, you know, where you're supposed to be able to click it to get to the next level. But again, that was interesting, but not necessary. So I do think there's a minimal viable product approach that actually might be more consistent with a economically consistent paradigm of how medicines practice versus the ability to look at all this data. It's going to move a lot more to exception reporting and just where do you get past the threshold where someone cares? Like in our defibrillator, we stored 90, 180 days of straight data, but the only thing a doctor wants, did you get shocked? What happened when you got shocked? That's it. Otherwise, I'm sure it's fine. I just want to summarize. So the question, you know, was what was the clinical need? And so what I'm hearing from the clinicians is a little very different from what I'm, and you guys are clinicians of course too, but you're entrepreneurs. And so what I'm hearing from the clinicians is the organizational need just to get it into the EHR. So I can manage the patient, but what I'm hearing from you guys is that most clinicians are not like these clinicians and they don't want or need that. And from a practical standpoint, that's probably not economically viable. So what is an alternative way that you could meet these clinicians' needs? And we're only dealing with a tiny bit of medically relevant stuff. Of course, wearables is going to be 99% non-clinically based but occasionally people are going to want to bring that into the medical system. So how would you, what's an alternative way to deal with the clinical questions that these guys are posing and that Chris is trying to deal with as opposed to standards? It's a great question. And that problem is being tackled in different ways. So first of all, you know, at iRhythm, we are very kind of friendly to all of the integrators and portals and we will work with them. Our customers want different things. Some of them love, you know, the sort of freestanding software for remote monitoring of implantables and they view the non-invasive solutions and extensions of their practice. Other hospitals say, I don't really care what that EP group uses, they're in a corner, I want this in Epic. And that's from the CMIO or the CIO down of the health system. And so you have to navigate all that. Epic has created new kind of integration standards with something called Epic Aura. So they've inverted the business model so that the implementation IT costs basically go, you know, are kind of offset by the device company, so to speak, via Epic. We're, I think, the first cardiac device company to be part of that. There's strong health system interest. And then in Silicon Valley, there's a number of companies that aren't just looking at wearables, but they're looking at machine reading of all the data. So show me a trend of the left atrial size. Show me a trend of the MR severity. Let me track that over time. Let me grab every single data point on AFib I can find and generate a timeline. So the solution there isn't a standards-based approach, but actually a software overlay of the EHR that can parse, right? Now, of course, you get into proprietary platformization, and that goes against a grain of standards. And so that's something we all have to contend with, is like, which side do we want to be on? Very interesting. Yeah, I would say that I think one of the biggest pieces building on my last comment is the economic. I mean, we're approaching 18, 19% of GDP on healthcare, and especially in wearables, the vast majority are diagnostic. We really have to ask ourselves, does this information change the natural history of the course of that patient in a way that's not only meaningfully clinically equivalent or better, but does it economically change the equation for the healthcare system and society? Even though we're many years past ACA, and we clearly haven't get to a value-driven system yet, we are getting further and further along those lines and think that way. So beyond all the hardware, and I'm the person who builds all these technologies or comes up with them, the biggest challenge is, can you get paid for it? Can you prove that you can get paid for it? And does it actually change what doctors do? If you start with that lens, many of the things we do just add cost to the healthcare system and actually don't fundamentally change the outcome. There's a ton of lead time bias for a lot of these things, so we really need to think, go back to first principles. Otherwise, we're going to spend a lot of money, and then there's a minefield of companies out there that didn't go anywhere because they couldn't prove that to payers. Right, right. Chris? Yeah, I think it's tough because we're trying to boil the ocean here. I think that there's a lot of different instances. There's a lot of different scenarios. This should probably be like a 10-part series on standards addressing each vertical. But nobody wants the state of deluge that's thrown around. I think I read that it's the luxury of applying AI, and you guys have services on that data. So absolutely, every clinic clinician wants to manage the exceptions. Show me what's wrong with this patient. Show me when they're out of normal. And I think with AI and with services, you're able to do that. But there are a lot of clinicians out there that don't have that luxury outside of like Holter monitors or MCOTs. I love what you guys are doing with Aura, by the way. I think that's gonna provide even more of this interim data in between those endpoints. But I think ultimately, when I say we want a lot of data, we want to provide it to the clinicians in a way that they can manage it. Because there are less clinicians today, there is a lot more data that they need to look at, and it's just gonna kind of increasing in that ratio. So ultimately, we can get data supports AI, it supports better AI, the more discreet that data is, and it kind of opens up doors for different ways to handle that data burden in the future. The non-proprietary parser, unfortunately runs into the same issue, the same central issue. I mean, it is another way of going about it, but then when you parse it, do you have a data integrity of what you're parsing? I mean, if you're parsing for regurgitation, what echoes do you use? Do you use outside hospital echoes that are in through Community Connect, or do you only use the in-house echo? So that all has to be programmed. It's a great concept, but I think it's almost the same. So we're trying to say, should we filter, should we parse, should we make a standard that you have? And that trending is one in the same, in my opinion. But you're still gonna need parsers, because not everything is gonna get sort of into a standardized pipeline. Well, that's what we're talking about. So if we do have it in a standardized, then we can put it into the standardized and that's the parsing, right? So whether you have a soup and you parse it later versus you have a standard, and that parsed into the standard is essentially equivalent. I think what we don't know is our willingness to lose unstructured data in the chart. Like, are you still gonna do a, let's say we create the standard for this. Are we still gonna do a comprehensive chart review in the way that we had previously? Is that a measurable outcome that we should aspire to? Is that chart review time go down? It may or may not. And that's part of, again, forming the standard. I think that when we interface with the proprietary, we're probably always going to lose data and we're always going to lose context, right? So we can't know what you guys are thinking. If you're making a new sensor, if you're making an accelerometer on Xeo, or if you're making a step detector or a fall detector, then that doesn't have to go in a monolithic standard. I think the fear that a standard is going to impose on developers is largely unfounded. I wouldn't say that IDCO has slowed down feature development in the cardiac device world. And I think clinicians still have the opportunity to go into the manufacturer system for deeper dives of data. The standard is really the first set of information, I'm sure. You can speak to it better than I can, but sometimes there's a deeper dive where you need to access certain data that's not standardized. So I think that workflow is always enabled. A very good analogy is if you use Expedia versus you go to delta.com, are you losing data? Well, of course you are. I mean, you go to Delta, you can see the seat map and their load factors. If you go to Expedia, you're just seeing the ticket and the price. But people use Expedia because it's an aggregator and you're able to see the data in a way. Now, there is a standard, right? There's an API that Expedia is going to the Delta flight, but you don't necessarily need to know the load factor. And for Delta to say, we're going to have our own standard because we don't want to interface with Expedia. As you said with iRhythm, you are interfacing very, very well with these aggregators. And I think that's the philosophy we need to maintain. I agree, but I don't think you can extend the analogy from flights to devices with different intended uses and different AI PPG algorithms. I mean, I think the aspiration is in the right place. I think that the details are ones that really have to be thought through in ensuring we're not creating risk by trying to solve a problem. And I think that's, oh, sorry. Sorry. Oh, David. I was going to say, yeah, I think maybe the discussion's going, where's the right threshold for a standard? At least for all of industry, standards actually reduce uncertainty because you know what you have to kind of meet. Even if it's relevant or not, at least you have a pathway which helps think about how much money you need to raise, how long it's going to take. But you don't want it so detailed that it's irrelevant. I mean, so much of what we have to do today is comply to how an EKG was thought to have been captured by an ambulatory EKG with wires and other things which doesn't apply to new technology. So that standard back then, which might have seemed very forward-facing, at least on the development of hardware side, is different. So I would say maybe the question is, what's the right level that's not too detailed, but detailed enough to provide certainty for both clinical needs as well as people making these products? That's what we're doing. Great, great point. We're almost out of time as I anticipated, and I want to go around the table quickly, but there are some regulatory considerations that might influence this. So I just wanted to turn briefly to Megan and Andy just to mention those briefly. Sure, so I think one thing that's actually currently available for all of us to sort of think about and maybe even comment on because it's in an open commenting period is the ONC's HTI-2 proposed rule. So the ONC is a federal entity that's charged with coordinating nationwide efforts to implement health IT and EHRs. And one of the things that they're doing right now is building on their prior work of expanding standards and capabilities for FHIR APIs. So for example, this includes like bulk data standards. So being able to get large data sets, increasing patient access, which has been another major focus of theirs. So that's also in this space. I'd be curious to hear from others sort of how they see that as intersecting with their work, but just wanted to mention that because that's also currently in the public commenting period till I believe early October. Yeah, the one thing I would add to that is right now those are all kind of read standards from the EHR. There's no write standards and kind of you can't have a mandate for write standards to the EHR until the standard exists. So that's kind of, I think where we're at right now where there's a couple of groups looking at creating a FHIR standard for CGM to be able to for patients to write that data. There's another group working on self-measured blood pressure because that's the standard of care. If we want to be able to kind of improve access of patients to be able to get their data to the system of their choice, we really need a standardized way to do that. I don't have any questions from the audience yet. So if I'm missing it, please raise your hand, but we're just about out of time, but let's just go around the table. I think it's an oversimplified question, but Udo, let's start with you. Standards or no standards for this complicated space? Yeah, the complicated space is a complicated question. So I would say just in one area, I think this particular field should think about is standards for AI and ML, because this is a big issue where FDA is on a learning curve at the moment, and it really needs industry participation and help to understand what's relevant, what's not relevant, where those lines are drawn, because obviously from a risk perspective and regulators may take a one view, but there might be other things to kind of bring to the table, because we're seeing it in companies across the board in this new frontier that's moving so fast. So standards, at least from my perspective on this new frontier will be important to be part of that discussion. Okay, great. Very interesting. Hard question to answer. I'm still at the point where I want to clarify the clinical need and the outcome to measure to know that the implementation was successful. Thanks, Mintu. Yeah, I kind of echo Mintu's comment. It really starts with the clinical need, making sure we have a valid reason to continue down the standards path. So I think that's really a good place to start. Great, thanks. I'm gonna agree. And also say, I think as we think about the clinical need, I think you brought up an important point, Mintu, which is that patients are increasingly also getting this and that may not have been the intended use initially, but now patients are seeing this. So as we think about the clinical use, I think thinking about patients as an end user will be an important consideration too. Terrific, thanks. Chris. Can I say both? I think standards have a place in this industry and I think not having a standard has a place in this industry. Standards are only as good as they're enforced. There are some standards that aren't in place today that aren't being currently prescribed to, but I think what I like about it is it brings awareness to a lot of this data and it gets people to have a discussion about it. Terrific, thanks. Stuart. I would say don't fear the standards and they will coalesce and will open up your APIs, clarify your APIs, canonicize your APIs. We will see what is coalesced and what is common between them, what the clinical need is, and merge it together and it's going to be an organic process. So I'd echo a lot of what everybody else is saying, that it's based on the clinical need. I heard in one of the talks yesterday that patients will come in and say, here's my EKG and they've got their device of choice and that varies wildly. And how do you get that in your record when you're documenting that the patient has AFib or whatever it is, right? That seems untenable, right? That's not something that's workable. So at least basic standards could help in that space. For example, there are other spaces where it's not that big a blood pressure, they show you a blood pressure. Well, you could just remeasure it or whatever. You don't necessarily have to have something like that. Although Andy's got a standard for that. We're actually at exactly nine o'clock. I really enjoyed this discussion, terrific points. I hope we can continue it. Thank you everybody.

wearable technologies

medical applications

standards development

data integration

electronic health records

regulatory considerations

interoperability

clinical decision-making