Episode 19 - with Aaron Neiderhiser and Phil Ballentine

what's up guys? What's up? Glad we got together to do this. Finally, only took like three months or I don't know when we first started chatting about scheduling this. Yeah, I asked what I wanted to bring out the really great conversation we could have about fire in analytics and how that meets the world of relational to va is trying to democratize healthcare analytics. Why don't we start? Yeah, I think I think most people know me and fell air Neeterizer co founder to fill lead state engineering for atropos health. Yep. What are you up to these days, Gene? Lots of stuff, you know, just having fun. I am building with club like everybody else. Yeah, and I to follow on what you, I mean, the reason we were excited about that we haven't really done a podcast yet where we've talked, I think we've talked about fire here and there, but I think this is like, this is like the all fire podcast, right? And I'm probably in terms of the three of us, I'm probably the least qualified to talk about, I know a little bit about what's going on. Gene, you probably know the most failure, probably somewhere in the middle. And so I think it's going to be, you know, we're going to get into fire. And probably with a little bit of an analytics bet because to your point, Gene, that's like, I just, that's how I look at the world, right? It's like what questions are we actually answering with the data? So, but they are maybe just to kick it off. Gene, you, I think gave a talk today, or you're going to give a talk about some work that you did around fire and see and making it easier to convert CQL to SQL. So I thought that was really interesting. I posted it in the Tuva Slack, kind of late because I just saw, I think last night or this morning, but maybe some people were able to see it and join, but yeah, I just, I thought it was really interesting. So maybe we could start, you could like, give an overview like what that was. And yeah. So the SQL on fire conference, actually, it's the second year. I didn't have, they've been having it then. I joined earlier this year. I started attending the SQL on fire working group. So it's kind of just a bunch of guys that meet every week pretty much. You're one of them is Arjun. He's a really great guy and we have this conference that they put on every year. And so I'm giving the talk actually tomorrow in the morning. So obviously this box is probably not be out at that point. It will probably already would have happened. So go check it out. What I'm going to be talking about tomorrow. But basically the gist of it is that in the fire world, the analytics are not easy to do because it's Jason's crappy to run the analytics on, you know, rest APIs were not made for data aggregation and doing all kinds of things with it. So there's all kinds of interesting things that SQL on fire working group is working on. We're coming up with a standard way to kind of flatten fire and there's were actually really cool presentations today, which was the first day of the conference. And you could go check those out like Josh Kelly did a presentation on why it actually is very recommended to use for LLMs and tokenizing your fire data because as you know, it's the more data you have to process, the more expensive it's going to be. So he actually had like a really cool use case. But honestly all the presentations are really awesome. And so my whole topic and agenda for tomorrow would have happened already. Who I was watching this is CQL, which is designed as a clinical quality language for fire. To standardize and make interoperable the clinical logic component. So for a long, long time, the problem in healthcare analytics has been, you know, heat is particularly heat is measures. They were published as a just a narrative specification. There's hundreds of organizations out there. They either have to pay a vendor to build those measures and maintain those data warehouses right. And then everybody kind of interprets the specs differently. So when SQL wants to do is get away from that and have one single set of code that kind of interprets using standard data representation like a fire model. And then be able to just give that code to everybody and then you can run it. Well, the problem is it's really hard to run CQL. The standard is kind of like trying to reinvent a new thing and it's not easy and not very performant. And so there's been lots of people putting a lot of effort into it over the last couple of years. There's a whole community of kind of people that are working on it currently. There's been a lot of work to done. I don't want to say anything bad about it because I think there's still a need for that. But ultimately, if you want people to use CQL, let's do the easy or maybe not the easy thing, but the common sense thing, which is converted to SQL. And within running heat is measures on SQL for years, years and years. So we have a lot of people that know how to build SQL measures and how to make them performant, how to troubleshoot them. And really what we can do is we can use CQL as that really standards-based specification logic component. So essentially your requirements document for your CQL measure. And so my demo tomorrow at this conference is doing that with the help of LLAMS converting using a standardized set of prompts and inputs. And then running that in Databricks and basically being able to utilize that immediately without needing a SQL engine or anything else. So will all these talks be available online afterwards? I'm guessing like on the conference website or somewhere. Yeah, there's a YouTube channel, I believe. And the conference is actually sponsored and put on by the health summary guys and the reason health is the other company. So and they have a YouTube for it. Yeah, that's awesome. I'm definitely going to check out a bunch of those. So one thing I like really agree strongly with and what and what you're saying and one of the reasons I was attracted to this, basically the idea of your talk is like the that CQL, the the the the big difficulty of it is the execution. And and I agree with that pretty strongly. And I think the reason I agree with that most strongly is for better or for worse, the lingua franca franca of like data analytics is SQL, right? And so you have all these data people that it's like, hey, if it's in a database, I know what to do with that. And then if you give them really any sort of technology that like is like could be like a Java program or like anything other than that, it's kind of like, wait, what do I do with this? Right. And so yeah, I think I think that's why you see that's why you've seen, you know, measures be written in SQL. One question I had for you is why why don't we just use SQL as the way like why do we need CQL? Is there a benefit to have a I know that's the direction, like maybe the train is kind of left the station, right? And it's going to be CQL for better for worse. But in a different universe, would it be a better alternative just to have like, you know, English language documentation of how the measures are intended to work. And then the code representation of that is just SQL. Yeah, that means that's a that's a great question. And I think that it's potentially is more difficult to write the requirements in SQL. The only reason I say that is that because you can do things like define which value set this particular measure is using. You can list out the values. You can have store procedures. You can have various lists, right? So there's like in CQL, there's really like one way that it's done. And the way it's represented is very easy like use this. It's almost like the whole CTE thing where use this CTE for this. And it automatically knows where to go and look. And so behind the scenes, it's actually writing this ELM representation, which is what CQL uses right behind behind it as the code, but it's much more wordy, but it the the layer that you can use to define those requirements is actually, I think it is actually simpler than writing the same thing in SQL, for example, because you would have to like write out either you have to create a whole bunch of store procedures. You have to like list out all the values in this list of value set. So there's elegant ways that it's been designed to like define a value set or which value set. Then it has the whole structure of fire, which allows it to basically say it's a condition. And then here's the code in the condition that you compare, right? So it's you don't have to have this whole kind of additional structure to say many people probably say conditions can be defined differently between different healthcare organizations. But fire really gives us one if you're using something like US core. And then with CQL, you can say it's using that condition. Everybody knows what that means. So I say that's the biggest that's the biggest like pros of it. And so like conceptually CQL, like when you're defining a measure in CQL, it's almost like a conceptually, it's almost like writing it in English with kind of a specific syntax, but like a layperson could could kind of read the measure and understand what it's trying to do. And then that gets compiled down to the executable version of it, which that's like the the ELM that you were talking about. And that is that executable, the data model on using quotes, if you're just air quotes, if you're just listening to us, the data model that that expects ELM executable version is programmed again. So that's fire. Is that correct? Yeah. Okay. Yeah. Just to jump in. So it sounds like, you know, my jumping off point with fire was a long time ago. I got very excited about it because I was like, this is great. Never going to have to do another source of target mapping doc again. We can all just agree on this model. Never again. And yeah, that I've never done one since since 2019, never not even one time. But I think we all saw that with analytics in particular, I've been on the analytics side the whole time. So I know that there's a lot of use of fire on the operational side in terms of like exchanging patient records and all the stuff that be well and other things like it. But from the analytics side, it felt like it was lagging for a long time, both because of the mechanism in terms of how you would even obtain the data. But then also, you know, this issue of like working with the data as as an object as opposed to flat relational data. So like what it seems like maybe and from our convert from I read some of the stuff that you were writing and also just for my general sense of what's going on in the industry, seems like maybe the the dam is kind of breaking now on the analytic side. And maybe we're kind of coming up out of the trough of a disillusion or whatever part of the curve that is specifically with respect to analytics and fire. And so I'm just curious like I haven't done frankly that much with fire in the analytics space because it was kind of lagging for so long kept my eye on it did some stuff in my grad program, etc. But from your perspective, like, do you feel that's true? And then also like what is causing now, you know, at long last, maybe what's different now that is causing fire in the analytics based to maybe become more viable and really break through those barriers. Yeah. So like first and foremost, I want to give a try to a sequel on fire folks. They have been meeting basically every year every week for for now, over a year, two years to try to come up with this specification. And what that specification does is it really just it gives you a computable representation of the fire resources in a flat and format, right? So it kind of takes that deeply nested structure. It takes all those things and creates something called a view definition. And the view definition is something with a help of a view runner, which is basically like a execution engine, right, that you just have in a sequel. You can basically create views in fire. So you take that structure and you flatten it. And then this is something that then you can standardize and share. And then people, we've talked about various implementation guides that are published, for example, by ONC for US core, right? US CDF, which is supposed to be the standards for interoperability for the United States. Well, what we can do is we can actually publish these view definitions, which gives you a really simple way to take this fire resource. And now you can flatten that to a database very easily with a sequel around. So basically, from like my experience, every organization has done that themselves anyway. I've talked to maybe like 10 different companies over the last year that have built their own flapping pipelines, right? They say, okay, what do you mean? We can just use and it's really complex. We built one in that we built one in the two front, yeah, yeah, exactly. So if but it's really complex and it doesn't like cover all the use cases, and then you end up with what, you know, I had in our, you know, data marks, which every fire resource basically becomes a data mark, which like 30 or 40 tables, which is like, oh, wait a second, this is really crappy and hard to work with. So instead, you can create these view definitions, and then you can create the views on basically, hey, this is the data that actually need. I don't need these like 10,000 different nested elements of the base resource that nobody ever uses anyway, right? US core, like it's how many, you know, elements, data elements, I'm actually even getting when they're connecting to these EMRs, not a lot, right? Like we're getting like maybe we'll lucky if we get the codes and all the associated data, right? So so the point is I think it's like the whole market has matured to your point, Phil, and like there's a lot of people that have been working on this problem, and now actually I think with AI and the alarms and we're able to iterate a lot quicker too. So like what I'm presenting and what I'm trying to show as a path forward is, first of what we can have agents built the CQL that basically defines certain logical elements in fire format, we can take that, run it through to convert to SQL, use view definitions to flatten that data, and then we can have really like runable analytics, almost like immediately downstream, right? And then you could even integrate all of that into your existing system, your existing analytics, schemas, and without having to reinvent the wheel for the 10,000 time, like every organization has done, they have these pipelines that run and flatten all the data, like hopefully you won't need to do that as much in your because you're you're taking the analytics issues, you want the need, having agents write all of that code for you. With the view definition, sorry, I'm sorry, no, go ahead quickly, because so because I'm better at thinking about this just in terms of concrete example. So you get a bunch of fire from somewhere, you keeping it in your object storage, I would imagine that, you know, hope, do you see most people getting like whole bundles of patient bundles or are we to the point where we can do like bulk fire, like give me all the procedures at once, give me all the observations at once, give me all of the, et cetera, like at once, like has that kind of landscape changed because I feel like that was the biggest initial hurdle for a long time is like even just getting getting a ton of fire out for analytics. Yeah, and that's that's absolutely the other side of it as well, is that it's not just like it's not just getting the definitions of how you translate fire to this relational structure, it's also actually pulling it out in a performance, scalable like way, which honestly, there's a lot of work that's has been happening with bulk fire and that there's a spec that is out there, but like if you try to connect to a particular instant of epic to a particular health system, it's not going to work great and it's not going to work the same way from one to another, depending on what they've enabled, what their support, and what they don't support, right? So that's where it's it's a hard problem to solve. It just some, each of them, there's a better at it than others and have enabled it. Others have not. So we're kind of like in this situation where we're prisoners of still, and I think that's that's the large problem that we still have, each of them, there's controlling access to data, right? Is CMS BCDA the way you can get Medicare claims, you're familiar with this, Jane, the BCDA? Yeah, is that for ACOs, is that an instance of is that a bulk fire API? I believe so, but it must it must be because the intent of it is like basically CMS is saying you can get a bulk fire or you can get all of the Medicare claims that patients in your ACO through the BCDA endpoint. And so it's intended to be my understanding or maybe tell me if this is true. A traditional fire server is designed to transact information about a single patient or maybe a small number of patients, right? So I want the information on Aaron and I want these resources about Aaron, like upcoming appointments, conditions, medications, stuff like that. A bulk fire server is going to transact the same JSON objects, the same resources, but for a very large population, a sense of it. Yeah, exactly. And you're supposed to be able to like define that population. So you're like instead of like, give me everything, you're like, okay, there's a thing called group and like you define that group. So you can say group of ACO number 126, so whatever. And that defines all the patients that are in that group. So that group resource, it's kind of like a long list of it's basically a roster. And for the long for the longest time, you had or when this like EHRs and other organizations first started setting up fire servers back in like the late, I don't know when it was probably like mid teens or something like 2015 and 2016 is right. Maybe when you started to see it a little more, I don't know. They were really setting up just like kind of the end of one fire, you know, the one patient at a time fire server. And then you didn't even really have the way to extract. You couldn't use a group or something to extract the larger or even if you did have some way where you're trying to get all the data out, it could crash the server because it just wasn't designed for that sort of scale. But now you're starting to see things like CMS's beneficiary claims data API that allow for that larger scale extraction. And so you are like within users of two of a, there's a bunch of people using that endpoint to get claims data from CMS. And you can get it faster than the old CCLF flat files. But I don't, do you know of any other like who else would you point to is having like a bulk file, like being kind of a leader and transacting population scale data with fire? So all the pretty much all the EHR vendors support it. So like you have Epic and you have Athena and you have Meditaq. But you need to obviously work with a particular health system to make sure that they can enable that, right? So it's the same problem that we've had that you just described where you know, you have a CSV file, right? That's been generated. You drop it on an FTP site and people pick it up, right? So 90% of the data is transacted that way. I just had a podcast episode with Michael West over the other month and he literally like brought up the same use case like that's the way that we just interoperate data in healthcare right now. So to get away from that, but you need to have willing participants to say, hey, wait a second. Do you even have the expertise on the health system side to enable the things that do they even know that those things exist that you can even bulk, you know, you can bulk fire the data instead of creating another CSV extract that your analyst has to write a custom Epic query, right? To pull out. So there's a lot of like education, but then there's also like resources and constraints. Like they don't have anybody that knows that. And Epic is like, well, here's documentation and you guys are on the right version of fire. Or so it really is, you know, dependent on that. Like I'm sure as you guys run into that all the time, especially with tour, right? If you have the right resources, you can probably stand up things very quickly. And maybe to jump back to SQL and fire. So if I just just trying to make sense of it. So if I wanted to like after this call, let's say I have a bunch of synthetic fire data on my desktop, could I load it into snowflake just as JSON and use SQL on fire from there? Or how would I get started with SQL and fire? So you can use I think health somewhere actually has a view definition builder. So you can go in there and define what you want. To essentially, how do you want to flatten that recent fire resource? So let's say you want the patients, but in your snowflake, you only want to store their demographic data. And you don't care about like the whole all the nested elements, everything else. So you go and you build that view definition. And then does the the health samurai, but it's not actually flattening the data into CSVs. And I load those CSVs into snowflake or it is. You want to have this, you need the runner so that we'll take and do that for you, essentially. So what I've done with Databricks is I've just kind of passed through views that I've created. And I said, like, hey, just load these these data elements that I need into Databricks. And essentially, that's what that's what about. So then I can write, you know, SQL statements that use use those. But is it, I guess, or maybe just try and ask it a little more clearly? Are you actually creating CSVs or flat files that get loaded in the database? Or is it just a view that is then passing instructions back to some runner that is then going back to the JSON and converting it more in real time? Does that make sense? I believe it's just like again, you're retrieving, you know, SQL, you check the syntax, and then you produce a table like output that you can do whatever you want with. So it's like basically, yeah. But what health samurai's tool lets you do, it sounds like you can specify the data elements are important so that you don't have these views that are like, you know, more columns than the number of atoms in the known universe or something. That's the benefit of it. Right. And it's also making you like critically think about what you're actually using or not, right? And it's like the way that people have done flattening for fires that, oh, we need everything fire because we don't know when we're going to need something right. And then they realize they spend more time flattening data than they do anything else or actually running analytics, right? So you're just like flipping that on its head and you're saying, I'm going to define the view, which is basically going to be the contract of what I want to run my analytics on instead of just saying, give me everything that could possibly ever come through whatever this. This is the important stuff I actually need. And then like what I was actually, yeah. Sorry, I was just like on that point, I guess I can go against my informatics background for a second here and play Delos advocate. What if I just want everything? Like, what if I don't know what I want? And what if I just you know, I have access and I'm not sure what I really want in the future. I just want to get all the data out. I want it somewhere where my analysts can easily access it. And my problem right now is that I have to go through that process and a traditional method of like talking to analysts. Here's giving them a spec, getting setting up. That's like the old tool. Yeah, like what if I, what if I just I'm trying to solve the access problem? Is there, it sounds like and I've used Health Samurai before and it seems like a great tool. It's been a while. I'm sure they have even more features now, but like how, how does this solve that particular problem? Like I just want all the data out and I want it with SQL. So you can absolutely create those view definitions that like just take everything and the resource and be like, but do you need to have that definition first of what it is? Right? So you're like, fire is really just like giant spec. That's like this huge base line foundation, right? So it's like building a house. You want to first figure out what it is, what kind of house you want to build. Right? So then let's say you want to use the US quarterfinition of the patient. You can absolutely go in and create a view definition based on that profile, US core patient profile. And that's actually something that I think like I want to partner with people to do because I think that would help a lot of people is if we just have those available for everybody. So then to your point, you don't have to like create your own. You can just download the view definitions for US core for all the resources and boom, you've got the latest definition of all these resources and then you can just run them and you have everything available on a flattened table. So yeah, absolutely. I wonder how similar the view definitions for US like US core would be to the clinical data tables and in the two of a core data model. Because we took we like the way we designed those clinical tables is we started by just looking at the fire resources and looking at US CDI and being like, well, this stuff seems important, right? So the like, I mean, we added, we obviously we added stuff here and there, but they're basically like that. They're largely inspired by that. I wonder how similar it is. Yeah, probably. It's just like, I've looked at two, and I've played with two for a while, and it's a really good representation. So I don't think there's going to be probably a large disconnect between unless it's something that has literally changed where they updated it for the new year, you know, like something as complex as labs where there's like 10 different profiles in the observation resource. And it might have changed in the last two years where they added something. So then you would have like 10 different tables that you would have to like reconcile differently, but ultimately the structure and finally doesn't change that often. So that actually, that kind of brings me maybe to a slightly like wider conversation, which, you know, I hesitate to call it a bone to pick or anything, but like somebody that I've struggled with thinking about fire, being kind of like the solution for a lot of these problems is that for me, at least all of this business around the profiles and the core and the R5, R6, it's the use or non use of extensions. Like I, I like to imagine myself as a fairly, you know, capable person. And, and I like to imagine that I know a fair amount about health data, you know, yeah, opinions certainly can differ. I probably varies from day to day quite a bit, but whenever I've gone into this space with fire, and I have gone into it to some degree, I feel like my brain is too small for this. And I'm curious like from your perspective, have we now gotten past that degree of confusion? Is everyone actually using whatever core or whatever that somebody told them to? Like it's like, for my perspective, as a very small brain integration, you know, a focused person, I just want everything to be the same and I want to be able to go out and get it easily. So like, are we there yet? Are we at the Amazon level? Can I put it in the cart? Can I get two day shipping on my fire resources? Yeah, I mean, I would love to say yes, but I say like, we're getting there. And like, um, I were, where are the differences come from? Where are all the differences come from? The fact that this is the thing. This is the things like people that create a fire, which is, you know, grand grieve. I had a chance to meet him in person at the fire camp in the Portugal, just recently in September. And he actually talks and talked about this as one of the original kind of sins of fire is that, you know, you could either make things very specific or you could make them like really open, right? And they specifically made those things like really open because they were trying to, I think, have it be flexible enough and ability to serve many different use cases. So I think, again, I am, I am not been in the fire community as long as some people have, like you have people like Geno, Kinesa there with Microsoft, Josh Mandel, those are like originators, fire and that's their full-time job. And they can tell you from like 2018, 2019, I mean, the fire has been around since 2011, but really the normative version came out, like probably 2019. And there's a lot of progress that has been made to standardizing. So basically what they announced at the fire camp conference was that for R6, which is the current version that's being worked on. So basically we're skipping a version. It's like Windows 95, 98, 2000 where everybody went directly to like Windows 2000 or something whatever. So the same thing with fire because everybody's on R4, which is basically like the Windows 95. And nobody's adopting R5, which is like whatever it is, Windows 97 or whatever. And then we're going directly to R6, which is now being finalized. And they're putting a lot of effort into making sure that like the resources that are in R6 are all going to be normative. And there's not going to be all of these things that are trial, you still and things that because really they've realized that like what's the point of doing that because people are not going to want to use those because they could change in the future. So let's just like make everything normative and put everything else in these implementation guides for people if they want to go and use the bunch of these experimental features or maybe something that's not embedded. So I think you'll see a lot of hopefully people adopting now are six that are on R4 because it is going to make life easier for a lot of people where you want to use some of those advanced features also like subscriptions is something that like is not in really R4 that is a very much needed feature. So that people don't have to keep pulling those APIs every seven days to get new data. You'll just get a notification, hey, this patient has new data just go get all right. So like that kind of stuff is going to be a lot easier. But the things you guys brought up are exactly like some of the things that everybody has very like deep discussions and a lot of like why do we do it? Did we now we have this proliferation of implementation guides as well. So like 10 different profiles on something that really should just be one way of interpreting certain type of data, right? Well, just as an aside, my first computer had Windows ME on it, which I think is the best operating system we've yet seen and I would trade every Windows since then to go finally. So that yeah, that sounds it almost sounds like there's a sort of Uber style thing happening where you start your standard really open to get people onto the platform. The price is really low. And then after everybody's on, you jack the price up or you know, like in this case, maybe kick everybody off if they won't standardize things. But in this case, what's actually going to make people, I mean, you're saying like people aren't going from R, they're not really going to five. What's going to make people actually go to six, especially if they're giving up all this like had a regenerating that they've built in for themselves. Yeah. So that's an interesting question. I honestly, I don't know because like, honestly, a lot of people don't date invested a lot of effort into just rolling out R4. Yeah. Could it be just the EHR certification process? Could that be the version? Yeah, I mean, I think the regulations drive a lot of it. So like if a US core now stops man dating, and they really, I think they released a statement that they will not be, they will not allow the Windows XP and Windows 95. They're like Windows 95's going to have to go away at some point, not going to be supported anymore. So like they're going to say like we're going to have that be based on R6 like feature versions, let's say 2027, 2028 or whatever. Yeah, are going to be, and if US core is saying that that means that all the EHRs are going to be compliant with that. So all the APIs that you're going to have an Epic are going to comply with that. So you're going to have to have a system that can't, at the very minimum, you know, store that data in R6. Right, format. So but there's different ways now also that that is a little easier to do than it has been in the past. Like there's this whole fire facade concept, which is basically like you're not physically storing that data. I mean, the sale in fire, but you have like a layer on top that's almost like a facade that you're in, you know, virtualizing it or whatever you want to call it as a, as fire resources. So there could be solutions that do that for the versions and stuff, et cetera. But with all the improvements that have been happening to SQL on fire, should healthcare data teams think about using fire as their common data model? That's a really good question. What do you guys think? I think for me, it would depend on how normative like, so if I'm thinking about getting data from a bunch of different people, I need there to be commonality. Like if I'm just going to, if I'm going to switch from getting my CSVs and different shapes from everyone and then doing my own item model. And if I want to just destroy all that and go out and get something, I want there to be as much standardization of whatever that is as possible. And then also I want it to be easy to get, right? Like that's kind of the, actually, that's kind of the table stakes. It could be the most standard thing in the world if I can't get it, then it doesn't matter. But if I can get it, I want it to be really standard. And, you know, if that did exist and then it was easy to flatten so that I can not have to convince a bunch of people to think about nested data structures that haven't before and that I can plug it into R or whatever. Then yeah, that sounds great. But what I'd be concerned about is, you know, A, there's always the heterogeneity of the data underneath. And B, there's the heterogeneity of what version of fire and stuff people are using and then how they're like piping that in. My understanding of how you actually get from like the data in clarity or, you know, whatever the equivalent for certain is, my understanding of how that even becomes a fire object is very limited. And so I'm curious, like, from your perspective, you know, how is that kind of happening or like, is there, is there a ton of hidden heterogeneity there? Yeah, I mean, absolutely. And like your answer is like, well, I think right in the money, though, in terms of like, how do you decide that is you really have to understand like what type of data you're talking about, right? If you're talking about data that is you do want to exchange it. And then you also want to like go to all of the data providers on the market. So let's say we start talking about Tef code and the queue hands and we talk about these networks and other players that are, you know, supposed to be making their data available and the single format release fire, right? So if you're looking to get lab values or you're looking at conditions, I would highly support you. Like try to at least use that as a baseline. And then you can customize like you can add things that you have that nobody else might have. And you can like extend, right? You can extend that definition. But at least like try to align it so that there's certain commonality to it from the way that it's represented. But then there are certain things that are not even in fire. And then your other question is in terms of how does that data even get into fires like you're absolutely right? Like clarity, what is it? Has like 50,000, 60,000 tables in epic. And it's like we're pulling out maybe, I don't know, one 10 from that into these fire resources. We're probably not not even that much. And then there's first of all, yeah, like what's required to be shared? It's probably like just the portion of the patient's medical record in the first place. So right? So that doesn't answer every different use case. And then whatever is pulled out goes through a certain level of mapping and transformation that somebody that has decided based on the things that they know about, right? And does that like neatly all compile? Absolutely not. And that's why you still need to like worry about data quality and your semantic, you know, normalization, your terminology, organization. So there's all that enrichment that nobody's doing, right? So like you, you, unfortunately, as the consumer have to be aware of all that stuff. So here's the tough thing for me. And thing about fusing fire as the common data model. So ultimately, we want to get the data in a relational format because analytics is relational thinking. Like at the end of the day, somebody's doing a data analysis, somebody's building the dashboard, somebody's training machine learning model, we're talking a data frame or maybe a couple of data tables to power a dashboard or something like that. And all the data people like we talked about earlier, their language of choice is SQL. So we got to get the data in a relational format. And this SQL on fire, the improvements to SQL on fire, right? Sounds like that has come a long way. Maybe it, maybe it mostly solves the problem of getting fire into the relational format. But here's the tough thing for me is the majority of data that data teams are accessing today. If you look across all the EHR feeds that data teams get access to all the claims data sets, the ancillary lab data, it's already coming in relational format. And so we want to get it in a relational format. It's tough for me to go to the data team and be like, Hey, you know how we're getting a couple things in fire. Fire is a standard, obviously. We want to get it to a relational format. These other, you know how we're getting 80% of the other data is coming in a relational format. Let's convert that back to fire before we pull it back into the and the JSON objects, the fire objects. Yeah, there's going to be people on the team that are skilled enough to do with that. But not the lowest come denominator of from a skill standpoint on the team again is like relational tables or relational files and SQL. And so I think that's that's the tough thing for me. I think where that starts to flip for me is if over time data sharing moves more and more toward fire. And if it starts to go from less less than 20% of the data sources are coming in as fire and 80% as flat. If that inverts, then I think the, you know, maybe the calculus starts to change their a little bit. Just to go off of that like, I think, yeah, maybe the maybe it's the acquisition that it kind of soft because like, yes, we are getting 80% now more, more just flat files. But the process by which you have to go through to set that up is so bad that if you could just get rid of that, that's the commercial for fire. Yeah. Yeah. It's like, Hey, do you just, I just want a giant dump truck of data to show up to my house without going through 19 weeks of like kick off and back and forth and all that stuff. But in order to do that, I need to know that the dump truck will actually have in it the mulch that I ordered and not like a bunch of broken glass or like be empty or have like nuclear waste inside it, right? So like, how do we get that assurance and then maybe, you know, but that we could build something on top of it that that we need, you know, we don't have to use fire as the the back end of our application or something. I think I don't even know that date you were bringing up like a bunch of data quality points there with your nuclear waste. I don't even know that data quality is the real problem there because like oftentimes you get a claims data feed from somebody as a bunch of CSVs and the claims data quality is not good, right? So I wouldn't necessarily quiver about the data quality. I literally think it's just the administrative mechanism like most, you know, that like if you get if you're getting data from a health plan or a TPA or just really talking about claims data here, right? If you're getting claims data from a plan or a payer or a TPA on behalf of employer or maybe a employer directly like 9,999 times out of 10,000, it's coming as a set of CSVs over an SFTP. And I think if administratively, what is the will to like shift that? If all of a sudden you snap your fingers overnight and then that's fire and there's like a solution for off and access and off, right? That is like a techno, you know, so you're not just like emailing the IT team for, you know, and not having your emails responded to. And they could just give you access to a bulk fire server and your permissions are, you know, you have only access to the data line. You can ping it and you can set up a pipeline to pull on some frequencies. But wow, right? Like that's a big that solves what internally we've come to call the Larry problem, which is like, you know, the Larry at every, every company that has claims data, Larry is responsible for managing the claims data and sending out claims data feeds. And Larry smokes two packs of cigarettes a day and takes three launches and he's just never out of his desk, right? And so it's, you know, these data requests go unfulfilled for it can take weeks to do something that should take five minutes, right? And I think I like to have more sympathy for Larry because I use, maybe because I used to work in a health system IT. I like the thing that Larry has seven hundred tickets. Yeah, and he had 700 tickets assigned to him and, you know, three hours of meetings a day, the mandatory attendance, a bunch of tickets in the Q ad. Just to go back to the like flight path forward, because I agree with you that I think that I was what you wrote that I reviewed earlier about how AI kind of can impact this. I definitely agree with that like perhaps a really useful thing about fire is that it does, you know, a fire feed from one health system versus another from Epic versus Surinur from Meditech different versions, all these things. Those things look much more different from one another than fire does. Even though fire has differences, like fire does kind of bring you to like a shelling point on the map of like, hey, we kind of know what this is. And LLM's know about that, even without adding a bunch of docs, which you can totally do, right? Like, you could just download the entire spec for R6 and put it in the context window every single time you're asking a question. So can you elaborate on how you see that kind of impacts things? Because I have some ideas, but I think you being much closer to fire may have much more insight there. But yeah, I mean, in a sense, a great question. By the way, we were all Larry, I think at some point, but it's not Larry. So no, oh, Aaron is the unsympathetic customer. Anyway, so I think that yes, I think it's going to be a while until we see that like future of like the Amazon or the example that I like to bring up is like the plan of health care. So like how you could help plan is out there as a service that connects all of these endpoints with different banks and different financials. And we're on our way to trying to get to that point. And right now, there are some like really cool organizations like we got Flexball, we got a fast in health, and if you guys know of them, but like we have health gorilla, we have all of these people that are trying or aggregate data, right? But there's really not one plan. That's the problem. Like you still have to go, if you want data from all these different areas, you still have to go and like you have to contract with like a whole bunch of different orgs, right? And then like if you go to individual health systems, like God help you, it's going to take you years to get every single health system. And then you ask, right? There's like a few people that have been doing that for years and it's and they still don't have everybody. So so I think yeah, that future is possible, but like just because we have APIs and we have bulk fire and we have like off solved. It doesn't still doesn't solve because you still have to go. There's manual, you know, Larry problems because Larry has now got the promotion and he's now approving the API API requests for Epic, right? So he's not no longer sending you the CSV, but he's still the guy that appears and he usually takes a couple of weeks to get back to you. So on the question about AI, I think it's definitely like a big force multiplier, like just like with this project that I've been working on using MCP and basically have agents that are already aware of all of these MCP endpoints that, you know, you need to do this. You need to get this. Here's where you go. Here's the information I need to get it. I think that opens up like a huge amount of use cases that I really think is the way everything's going to be done in the future. Just because like everybody's going to want to interact with an AI, you know, whether you're a developer or you're an analyst or in your it consumer at the end of the day of the some analytics product, you're going to have you're going to have an AI that you're interacting with, right? And so the fact that everything's kind of like enabled out of the box with MCP and there's obviously like agent to agent and other frameworks out there that a lot of these use cases can be operationalized with a lot less like just grot work that you, you know, for years and years, you've seen like how long does it take to create a dashboard in a large organization that actually has all the data that's needed probably months because they first have to build you the tables to get all the data together, right? Then you have to have somebody build you the dashboard, then they have to build you whatever like access to. So all of that stuff can be automated with agents in my my hope. I don't know if, you know, how soon that's going to happen, but and I think there's a role for people to play. I don't think it's like replacing everyone's job, but it's going to make everybody focus on like what the value of your job is as opposed to just hitting schedule on the CSV extract or building a chart on a dashboard that like an LLM that can really do a better probably better job with that than I can if I just give it the right context window and the right prompt and MCPM points that it has to go to get the data. Yeah, it makes sense. I'm guessing we probably get a wrap here in a minute or so. Curious gene and fill any major predictions for what, you know, where where things are going with fire and in the next year, anything that's anything that you they're excited about. I'll let you start Gene. Obviously, I'll say the zero zero five seven staff that everybody's been talking about. I don't know if you guys would listen too much into that that's like the prior off stuff that there's a requirement one one twenty twenty seven. So there's a lot of work happening to so we'll see what happens with that. If organizations are still going to be ready or not, there are a bunch of solutions on the market for that, but basically that enables that communication between providers and payers for the approval and the data that they need to make the approval and then the the medical guidelines that they need. So there's a lot of things that have to go right for that, but that's like probably the biggest thing, but there's there's there's the whole thing within CQA and the quality measures and all of that. We'll see how how that kind of matures and where we go. Will they actually make that acceptable for or he just submissions. We'll see things are definitely moving, but not. I don't think the time lives are as solid. Feel what do you think? I'm not sure that I have a prediction, but I think my sentiment, you know, have a I got really cited about fire back in like 2019 and it followed it for a long time, and it does feel like something is changing, but to to recapitulate some of my family lineage from Missouri, I really want someone to show me in in 2026, like I want to see it. I want to see the button that I hit and it gives me all the fire and then I want to see the other button that I hit that makes it a tables show me the data. Yeah, show me like I want and I believe, you know, it's we as we know this is not a technical problem really. This is it has a lot to do with like the technology exists, you know, we have the technology, it's about actually making it making it real. But you are, you're not getting off the hook. Oh, no, no, no, no, no predictions. No predictions for me. I asked the question. I don't have to answer it. Well, two was compatible. Two was compatible with fire, right? Like you have to be compatible. Yeah, you guys will take it. You guys will take it and then you get show me and I want to see the connector into the the fire to two of a connector. It's called fire inferno. You can go check it out. I should check it out. I need data to put into it though. That's that's easy. Yeah, that's it. I need to fire data. Hey, let's let's create the MCP and the agent stuff. Let's have that all be automated. And I think it's possible to do and really cool. And then we can come back on this podcast, like in a couple of months and like show it off and be like, hey, it's really working. Phil, we'll do a two of a community meetup on that. Yeah, I'm down. Yeah, let's do it. Let's do it. I'll fly up. Well, this is great. This was great, guys. Awesome. Glad we got this finally done. Let's do it again. Yeah, this was a lot of fun. Guys, thanks a lot. Thanks a lot.