Talk by Vasant Kearney (Onlay) on using X12 healthcare EDI transactions as an execution harness for AI agents in the claim lifecycle. He argues that payer phone systems, web portals, and X12 feeds are not ground truth and can contradict each other, so agents should treat X12 as a constraint harness encoding the provider-payer contract. Topics include mapping each claim stage to an X12 transaction (e.g., 270 eligibility, 999 acknowledgment, 835 payment), normalizing everything to an internal representation held only until downstream evidence contradicts it, storing enterprise memory in a database rather than local disk, and why a stronger benchmark model is not automatically better inside a system built around a replaced model. Framed as a posture of being simultaneously "AI pilled and AI skeptical." # Video Identity Observations ## Video Context - **Title:** Healthcare's Agent Bytecode: X12 as the Harness for AI Agents — Vasant Kearney, Onlay - **Format:** Conference talk (speaker addresses a live audience: "How's everyone doing today?" and conducts repeated show-of-hands polls). - **Speaker:** Vasant Kearney, affiliated with **Onlay** (per title only; the transcript references "our system internally" without naming it). ## Intended Audience - **Dual technical/healthcare professional audience**, confirmed by speaker's own audience probing: > "Let's get a quick show hands to see who... Who here is on the healthcare side?... Who here is on the technical does the genetic workflows?" - Audience is assumed to be **AI practitioners with deployed systems**: > "Who here has models running right now somewhere doing some work?... It's like the whole audience. Okay. All right. So, I know who I'm talking to." - Speaker also acknowledges a segment still doing manual work: > "maybe half the companies I spoke with here still program today just everything by hand." ## Claimed Scope (Self-Description Evidence) - The talk's stated scope: **agentic AI execution in healthcare insurance workflows**, framed around cost and patient experience: > "this talk will be about insurance cost specifically, the cost of interacting with insurance. Um, but also to improve the patient experience." - Speaker claims domain expertise via a shared-practitioner framing ("I think it's always really good to learn what the audience background is") and refers to internal system experience ("our system internally," "in our system or other systems"). ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Technical depth in healthcare interoperability:** detailed walkthrough of X12 transaction types (270 eligibility, 275 imaging, 835 EOB, 999 acknowledgement) tied to the claim lifecycle. - **Engineering rigor framing:** repeated emphasis on evals, validation, and model replacement risk: > "you can't just replace the model and assume it's going to be better... you really have to redo everything from scratch." - **Balanced AI skepticism** as a rhetorical stance: > "I'm fully AI pilled, right? But... you should also be very AI skeptical. Like these things, they make mistakes." - **Practical production concerns:** cost-effectiveness, memory-induced bias, and hardcoding vs. free agentic reasoning tradeoffs — presentation oriented toward builders, not general audiences. ## Creator Claims vs. Demonstrated Content - **Explicit self-description:** minimal — the speaker claims a goal (reduce insurance cost, improve patient experience) and positions the talk as being for the "right crowd" of technical healthcare AI practitioners. - **Demonstrated:** deep working knowledge of payer systems, X12 standards, claims workflows, and agentic system design; no explicit channel-level mission statement appears in the transcript. # Delivery Observations — Vasant Kearney, "Healthcare's Agent Bytecode" ## Tone & Overall Style - **Conversational, informal conference talk**: opens casually — "Hey everybody. How's everyone doing today? Good." — and maintains a colloquial register throughout ("So, have fun," "AI pilled," "cool"). - **Self-aware framing**: repeatedly checks audience fit — "Let's get a quick show hands to see who... Who here is on the healthcare side?" followed by "Okay. All right. So, I know who I'm talking to. Wonderful. This is the right crowd." - **Wry humor and understatement**: e.g., "Um, so, now we're ready to um deposit this check into this person's account and transfer money. Well, not quite" and "Um, 'Attention is all you need,' one of my favorite titles for a paper." ## Audience Interaction Habit (Opening Pattern) - A **rapid series of three show-of-hands polls** at the start (healthcare side, agentic workflows, models running now), each with surprised reactions: "Ooh, wow. That's a lot of you. There's more than I expected. Wow. Okay." This is an observable opening habit, though it occurs only once, so it may be a one-time adaptation to the audience. ## Vocabulary & Recurring Concepts - **Repeated key terms**: "harness," "X12," "agentic execution layer," "grounded/grounding," "transaction," "steps," "evals." - "So this concept of harness different groups have different definitions of this so I'm going to use a super broad definition here..." - "we really thrive they work well and when they're confined... and x12 is exactly this so it provides this underlying structure this contract" - **Concrete X12 vocabulary woven in**: "270," "275," "999," "835," "EOB," "ACH," "COBOL," "Claude codes, the Codexes," "open claw, Hermes agent." - **Healthcare-domain terms**: "eligibility," "claim status," "payer," "PMS," "EHR," "CBCT." ## Teaching Habits ### 1. Analogies to familiar AI history - Walks through a timeline: "this evolution from the neuron convolutional neural networks large-scale unsupervised learning back in 2011 2012. Then, the introduction of attention is all you need." - Uses a **check-depositing analogy** to illustrate hidden complexity: "So, like you have a check and you want to cash it... 'Oh, we have solved the handwritten digit problem.'... Well, not quite." ### 2. "Setting the stage" / walk-through structure - Explicitly signals sections: "So, another thing that comes up, just sort of setting the stage, is that um multimodal context..." and "All right. What is the agentic execution layer?" - Walks through the **patient journey step by step**: "Starting with the schedule, when let's say you're showing up to the doctor's office... Submitting the claim. And then finally getting the payment in the provider's bank." ### 3. Repetition for emphasis on caution - A recurring theme is **skepticism toward AI**, restated multiple times near the end: "I'm fully AI pilled, right? But we want to make sure that we introduce la- language models... in a very skeptical conservative way... you should also be very AI skeptical." - Similarly repeats the "no ground truth" point: "And we have to understand that there's no ground truth... they can all actually agree on the wrong information as well." ### 4. Balance framing ("strike a balance") - Repeated rhetorical pattern of positioning choices between two extremes: - "we want to do is strike this balance between what we should be completely free... and what is hardcoded." - "you also introduce bias... So, you want to strike a balance somewhere in there." ## Communication Patterns & Disfluencies - **Frequent filler and restarts**, especially mid-explanation: "you have to make sure that it is um that it is um going to the target account"; "in these tight con- these strict confinements"; "la- language models." - **Doubled words and self-corrections**: "it it boils down," "your your objective," "or or, you know." - **Short asides to the audience**, including hedging on interest level: "Maybe you find it's it's interesting or not but..." - **Minor technical mishap acknowledged verbally**: "the different treatments that you have in that clinic can oop." followed by a restart of the sentence. - **Pace of enumeration**: lists tools/transactions in rapid runs without conjunctions: "You might be making a phone call. You might be looking at a web portal. You might be interfacing with an EHR." ## Uncertainty Notes - The show-of-hands opening, the "oop" technical stumble, and the audience snort ("[snorts]") are isolated moments, not patterns. - Personality traits or motivations are not assessed here; only observable delivery features are reported. # Position Record: "Healthcare's Agent Bytecode: X12 as the Harness for AI Agents" — Vasant Kearney (Onlay) ## Speaker - Single identified speaker: **Vasant Kearney**, founder/engineer at Onlay (per video title metadata). No other speakers appear in the transcript. ## Stated Goals of Healthcare AI Work - Kearney frames the goal of healthcare technical work as twofold: - **Drive overall cost down**, specifically the cost of interacting with insurance. - **Improve the patient experience**, since insurance processes directly shape patient experience. - He cautions the technical audience against getting "really experimental" for technology's sake; work must be "grounded in one of these two concepts." ## Historical Framing of AI Evolution - Kearney traces a progression: neurons → CNNs and large-scale unsupervised learning (2011–2012) → the transformer ("Attention Is All You Need" — which he calls one of his favorite paper titles) → modern chat interfaces/LLMs → **agentic execution layers** (citing Claude Code, Codex, OpenClaw, Hermes agent, and Onlay's internal system). - His stated focus: how to do this execution layer "safely and reliably in health care." ## The "Check Deposit" Cautionary Analogy - Claim: early enthusiasm for AI capabilities often overlooks system complexity. Example — recognizing handwritten digits does not mean you can safely deposit checks, because: - You must identify many character types on the check. - You must match against other infrastructure pieces. - You must ensure funds go to the correct target account. - He labels parts of this surrounding structure **the harness** and says claims processing presents "a similar challenge" with many small AI steps spanning from eligibility to insurer payment into the provider's bank account. ## Multimodal Context in Claims - Kearney argues that reducing images (e.g., medical imaging) down to extracted findings and geometries for cost reasons can **lose context** — the upstream model may omit information relevant to a downstream procedure it "wasn't aware of." - He extends multimodality to **desktop use**: some UI features (buttons, shapes) are only visible through multimodal perception. ## Components of the Agentic Execution Layer - **Actions**: database queries, code queries, insurance transactions, phone calls, web portal interaction, EHR interfacing. Some actions carry audit/right implications (e.g., user logs when interfacing with PMSs via desktop). - **Memory**: unlike Claude Code/Codex which use local desktop memory, "in enterprise healthcare, we can't really do this, so we do memory in a database" for logical separation. - **Model replacement caution**: new, "better" models cannot simply be swapped in — they are better "on certain evals" but not necessarily for your system's situations; all evals, testing, and validation "have to be redone from scratch." ## The Harness Concept (Broad Definition) - Kearney explicitly notes "different groups have different definitions" and offers his own broad one: everything surrounding agentic reasoning — **memory, tools, checks, permissions, handoffs, evals**, and, in healthcare claims, **X12**. - Claim: LLMs thrive when confined to strict formats with clear, limited prediction values — analogous to COBOL or strict languages like TypeScript. **X12 provides this: "a contract between what you're trying to communicate and the insurance company."** ## The Core Argument: X12 as Grounding/Harness - Claim life cycles involve many steps (~50 possible), and errors **propagate downstream**; a strict structure lets incorrect outputs be **rejected**. - Trade-off he identifies: - Pure agentic reasoning over many multimodal steps is **expensive, slow**, and each step is an error opportunity. - Full hardcoding produces "crazy bloat" and unmanageable code requiring a giant engineering team. - Solution: **strike a balance** between free agentic reasoning and hardcoded structure. - **Every step of the claim lifecycle has an X12 correspondence**: scheduling → treatment → documents (e.g., the x-ray itself as a 275 attachment) → claim submission → payment (835 EOB), with 999 for syntax acknowledgment. - Claim: even calling an insurance company "boils down to a transaction" — eligibility (270), claim status, etc. all have X12 groundings. Bank ACH is "not X12 but it's still that structured transaction." - Practical benefit: X12 transactions are **public standards**, not a proprietary schema. Agents generating their own schemas produce "all sorts of stuff"; grounding in X12 means new engineers (and agents) can look up the standard immediately. ## X12 Reliability — Qualifications and Contradictions Kearney is explicit that X12 grounding is **not** a guarantee of truth: - Insurance companies may contract out their web portal, phone system, and X12 layer to different companies/teams; "there's no ground truth." - Multiple payer systems can **agree on wrong information** — his example: eligibility checks via phone, browser, and X12 all say "covered," yet the claim is later denied because the patient wasn't covered at treatment time. - Practitioners learn **payer idiosyncrasies** — some systems are more reliable than others. - Resolution he proposes: regardless of source, boil all transactions down to your **"own internal semi-correct X12. Correct until downstream evidence proves it otherwise."** - Further qualification: any X12 information from an insurer "any time can be wrong. It can be updated later. So, have fun." ## Memory Design and Bias (Internal Onlay Practice) - Onlay uses **partner-level, organizational, and user-level memory**. - Rationale: users in multi-site health organizations tend to do the same things daily; a few words plus context can predict intent. - Stated tension/qualification: persistent memory introduces **bias** — the system may steer a user to repeat yesterday's behavior when they don't want to. Balance is required, and **any user must be able to break out** of memory-driven behavior. ## Closing Position: AI-Pilled but AI-Skeptical - Kearney states: "I'm fully AI pilled" — but language models, including small ones, must be introduced "in a very skeptical conservative way." - Dual attribution of error: models make mistakes, *and* "we make mistakes designing them. We might set them up to fail." - **Cost-effectiveness constraint**: using an overpowered, expensive model for routine tasks performed "a thousand times a day" contradicts the goal of reducing costs. ## Unresolved Tensions (Preserved) - Agentic flexibility vs. hardcoded reliability (explicitly framed as a balance to strike, not solved). - Memory-driven efficiency vs. memory-driven bias (explicitly acknowledged, no final resolution offered). - X12 as grounding/contract vs. X12 data being unreliable and mutable ("semi-correct," correct only until disproven). # Speaker Attribution & Provenance Record ## Video - **Title:** Healthcare's Agent Bytecode: X12 as the Harness for AI Agents — Vasant Kearney, Onlay - **Video ID:** `01a15ca7-ce98-7ea5-927e-96c9089330f1` ## Speakers ### Vasant Kearney — **Presenter / Creator-side speaker** - Identified via title attribution ("Vasant Kearney, Onlay"); speaks throughout the transcript. - Self-references an internal company system ("our system internally") and internal practices ("we do that internally"), consistent with a company-affiliated presenter at a healthcare/technical conference. - Engages in live audience polling (show of hands on healthcare vs. technical background, models currently running), indicating an in-person conference talk. ### Audience — **Unidentified participants (background)** - Presence indicated by presenter's interactive questions and implied responses ("Ooh, wow. That's a lot of you."); no individual audience members speak in the transcript. ### Narrator - None present; no narrator voice segments. ## Non-Speech Audio - Audience snort (marked `>> [snorts] >>`) - Music at the close (`>> [music]`) ## Referenced Sources & Claims (as cited by the presenter) - **"Attention Is All You Need"** paper / transformer architecture — cited in an AI history overview (described by presenter as "one of my favorite titles for a paper"). - **X12 EDI transaction standards** — central topic; presenter states these are **public specifications** ("If you look up any of these transactions they're all public... this is not my schema"). - Named X12 transactions: **270** (eligibility request), **275** (imaging/document), **999** (syntax acknowledgement), **835** (EOB/receipt of payment). - Named systems/tools: **Claude Code / "cloud code"**, **Codex / "code X"**, **OpenClaw** (transcribed as "open claw"), **Hermes agent**, **COBOL**, **TypeScript**, EHR, PMS, CBCT imaging, ACH banking. - **Unverified anecdotes:** presenter's bank-check-digit example, payer reliability idiosyncrasies, denied-claim scenario — presented from personal experience, no cited external source. ## Third-Party Claims - Claims about insurance companies outsourcing systems (web portals, phone systems, X12 layers) to different companies — asserted by presenter, no cited source. - Claim that "half the companies I spoke with here still program today just everything by hand" — informal conference-floor survey by presenter, unverified. ## Promotional Segments - **None explicitly flagged.** Presenter references his own company's system ("our system internally," "at Onlay" implied by title) but contains no distinct promotional call-to-action segment in the transcript. ## Availability & Metadata Limits - **No curated metadata supplied** beyond title and transcript; speaker identity derived solely from title attribution. - **No timestamps** present in transcript. - **Comment availability:** not indicated. - Transcript contains transcription artifacts ("cloud code," "code X," "open claw," "AI pilled/filled") — exact product names uncertain from source. \>\> Hey everybody. How's everyone doing today? Good. So, this is a bit about my background, but I think it's always really good to learn what the audience background is if it's more on the technical side, which I know this conference is, healthcare side. Let's get a quick show hands to see who Who here is on the healthcare side? Ooh, wow. That's a lot of you. There's more than I expected. Wow. Okay. Who here is on the technical does the genetic workflows? Wow, okay. Overlap. All right. As should be expected at this conference. Who here has models running right now somewhere doing some work? Wow. It's like the whole audience. Okay. All right. So, I know who I'm talking to. Wonderful. This is the right crowd. So, what is the goal of this? Like if we're working in healthcare and we're doing some genetic workflows, we have to keep in mind the goal. And that goal, at least from my perspective, is to drive the overall cost down. So, in this talk will be about insurance cost specifically, the cost of of interacting with insurance. Um, but also to improve the patient experience because insurance relates back to the patient and how they experience the whole process. So, let's keep that in mind when we're solving problems. I know that if we're on the technical side, we like to get really experimental with things and get excited about just this the technology itself, but has to be grounded in one of these two concepts. So, a little trip down memory lane just starting from this long journey of AI machine learning and where we are today. And we're obviously going to talk about the last point, this agentic execution layer. But, we can see this evolution from the neuron convolutional neural networks large-scale unsupervised learning back in 2011 2012. Then, the introduction of attention is all you need, one of my favorite titles for a paper, the introduction of the the transformer. Then, we go into this modern chat interface with these large language models. And then, finally with the Claude codes, the Codexes, and our system internally, and a lot of systems you have open claw, Hermes agent, all all that kind of stuff. Which really brings into the into the picture this execution layer. So, we're going to be talking about how to do this execution layer safely and reliably in health care. So, let's think back to some of the earlier examples of like getting really excited about some AI technology and then realizing it has all these little bits and pieces which make it a lot more trickier than maybe it is is obvious at first. So, like you have a check and you want to cash it. You want to deposit it into your bank account. Um you might say, "Oh, we have solved the handwritten digit problem. We can recognize digits from zero to nine." Right? Wow, oh oh, so now we're ready to um deposit this check into this person's account and transfer money. Well, not quite because as you dig in a little bit deeper you see that you have to identify all sorts of characters in the check. You have to make sure it matches up with all these other pieces of the infrastructure. You have to make sure that it is um that it is um going to the target account that you're interested in. So, parts of this can be thought of as as the harness. Um in claims, we have a similar challenge that there's a lot of these little AI steps involved in fulfilling that whole patient journey of eligibility to getting the insurance company to deposit money in the provider's bank account. A whole bunch of little steps. And we have to make sure that we're safely doing this, that we're operating like in these tight con these strict confinements. So, another thing that comes up, just sort of setting the stage, is that um multimodal context in comes up very frequently with claims. So, you might have an image and it might seem like at at first for cost reasons or something else that you'd want to take that image and reduce it down to the findings, like here's the anatomy in the image, and maybe even extract some geometries from that anatomy. Here's pathologies. And then you would take that and then combine it with some other machine learning with some other data in a different downstream machine learning model. Like um EHR. And that might make sense from a cost perspective and also just like model capabilities. Um but in a lot of situations, it you lose context. So, it might be that you're extracting all this information and missing something that relates to some downstream procedure that you didn't that wasn't the upstream model wasn't aware of it. So, that introduces this concept of just multimodal processing. So, uh uh another place this comes up in healthcare, but not related to anatomy or anything like that, is desktop use. You can see that sometimes, you know, things are buttons or or or, you know, it might have some shapes that are only obvious when you do this multimodal. All right. What is the agentic execution layer? So, this can this can take on a lot of different forms. It is the ability of this model to take actions. So, it might be you're starting out with um database queries. And let's say it's just completely open. You're querying the database, you're finding your schema, you're figuring out what this what the data looks like, and then you might even have access to your code. So, then you're querying your code with the respect to your data. Uh and you might actually, in our system or other systems, you might be making insurance transactions. You might be making a phone call. You might be looking at a web portal. You might be interfacing with an EHR. These are all actions you can take. And some of these actions have right implications. If you're interfacing with different PMSs, you're going to the desktop, you can have at least user logs at the minimum. Uh and then the next concept is memory. So, cloud code or codex, they use local memory, they write to your desktop. In enterprise healthcare, we can't really do this, so we do memory in a database, just so we have that logical separation. Uh important concept here is that when you're introducing new and improved better models more sophisticated more parameters you can't you can't just replace the model and assume it's going to be better it's different right it's a it's a on certain evals it's a better model as measured by these different metrics but it doesn't necessarily mean it's better right for all the situations that you want it to be better at because of the way you've designed your system so you really have to redo everything from scratch just make sure your evals your testing your validation is all set up so that you can introduce these new models and not break your system. So this concept of harness different groups have different definitions of this so I'm going to use a super broad definition here which is like all the different nuts and bolts that that surround this agentic reasoning and that is the concept of memory that we discussed the different tools the checks the permissions the handoffs the evals but also in the context of health care and claims it's x12. So just like we have these old school languages or formats like COBOL or other stricter maybe strict languages typescript llms really thrive they work well and when they're confined they have clear limited values that they can predict and x12 is exactly this so it provides this underlying structure this contract between what you're trying to communicate and the insurance company. So, when you're reasoning in this in this healthcare, your your objective is to do something with handle a claim or research your EHR with respect to claims. It might be that you have like 50 steps or something like that. There's a lot of different steps. And so, you can um you at at each of those steps as you make mistakes, those mistakes can propagate down your system. Um and so, it's very good to have something grounded that can be rejected to. So, if you have a really strict got guardrails, you can reject something that happens that's incorrect. So, if you're reasoning over, let's say, the previous example, 50 steps, that and they're multimodal. You're considering and everything like that. That can get really expensive. It can also take a really long time. And folks might not want to wait. You know, it could be too expensive and people don't want to wait that long. And each time it each step is an opportunity to introduce an error and you can have problems. Um but, if you hardcode your whole system, you say we're you're going to throw out this whole agentic process, you limit yourself or your code can explode to be just unmanageable. So, now all of a sudden, you just have this crazy bloat and you have to have this giant engineering team, which poses its own problems. Um so, what we want to do is strike this balance between what we should be completely free, like um with just pure agentic reasoning and execution, and what is hardcoded. So, we do that internally with introducing memory, just this uh partner level memory, organizational organized memory and user memory. So, we say if a user, we find people in in multi-site health organizations, they tend to do the same thing day after day. And it might be if they mention a few words, "Oh, they usually do eligibility and they usually do it within this context, they probably mean this." Right? Where another user, they probably mean that. So, we want to be really careful here because as you introduce memory, you also persistent memory across chats, across days, you also introduce bias. So, maybe that person doesn't want to do the exact same thing that they did yesterday and now you steer them to do the exact same thing they did yesterday. That's a problem. So, you want to strike a balance somewhere in there and you want to make sure that the use any user can break out of this. So, for folks that are unfamiliar with the whole claim life cycle, it's many steps. So, each step does have an X12 correspondence with it. Starting with the schedule, when let's say you're showing up to the doctor's office before you even show up. That's insurance starts then. Um when you're getting treated, that also relates to insurance, what you you know, the different procedures that you are candidate for depending on your insurance. Um your documents, sometimes the x-ray itself is the document and you would send proof of that in. Submitting the claim. And then finally getting the payment in the provider's bank. So, this I think this concept is a little bit I I found it to be obvious in retrospect but let me talk you through it. Maybe you find it's it's interesting or not but if you're calling an insurance company that it that boils down to a transaction an X12 transaction. You'd say hey this is the patient I'm talking about. Great. That's a like an eligibility request a 270. Oh I need to do you're requesting a claim status or whatever it is you're doing that has an X12 grounding. And that is the whole concept here this this X12 harness. So you call the insurance company you have an agent interact with a desktop you have an agent interact with the browser your imaging system that's a 275 and and and your insurance your bank your ACH so that's not X12 but it's still that structured transaction. \>\> \[snorts\] \>\> So this is just a reiteration of these different transactions. And the other beautiful thing about it it's not you know it can you ask an agent to do something let's say you're genetically programming or let's say you're just you're you're programming how you know maybe half the companies I spoke with here still program today just everything by hand and they use these clock code or code X4 research. If you look up any of these transactions they're all public. Like this is not the beautiful thing about this is like this is not my schema. If you ask agents to make a schema for you you're going to get like all sorts of stuff. But now if we ground it in something standard you can look up all of these and you would know just right off the bat my schema. Let's say you're a new engineer coming in, like, you know. So, X12 is a is a system of rules and it doesn't mean that when an insurance company gives you an X12, it's true. So, that concept is when insurance company tells you something, it's coming from different teams potentially. They can have an engineering team that's It could be even a different company. A different company that the insurance company contracts out designed their web browser, their phone system, or their X12 layer, or their fire. And we have to understand that there's no ground truth. They also within all of these systems, they can they can all actually agree on the wrong information as well. Like, let's say they all say this patient is covered. All three You call them. You look in the browser and the X12 and they all say, "Yes, this patient is covered." And then you treat the patient, they say claim is denied due to the patient wasn't covered during that time. Um so, they can all disagree, but sometimes you'll learn some idiosyncrasies of these different payers that some of these systems are more reliable than others. But, regardless of if it originates as an X12 or not, you can boil all those transactions down to your own internal semi-correct X12. Correct until downstream evidence proves it otherwise uh to be incorrect. So, just a little bit more on that. So, and any of the X12, any of the information coming from the insurance company, any time can be wrong. It can be updated later. So, have fun. This is just an example of what it would look like if you're um in that patient journey. You're you're trying to figure out how much you would pay as a patient up front, and it's very important for your experience going to the doctor. And then the different treatments that you have in that clinic can oop. Yeah. The different treatments that you have in that clinic can be the evidence that you need. Like you might get a CBCT. Well, that those images and slices of those images might be the evidence that they're asking for. So, ultimately, if you're delivering that treatment, you're sending that claim, that claim is like a receipt of what you did. I did this, like here's the invoice. Right? Like you send it to the insurance company this invoice, and they would pay you back. So, that is your ultimate like contract of you're saying you did this work, it's sealed um and now the ball is in insurance company's court. And just a little bit about this progression of the claim from you're sending it, you're getting some acknowledgement, has like the syntax is right with that 999. The status has been updated. Hey, cool, we received it. Um maybe you call them and you verify the status didn't come in. Then you have this EOBs 835 receipt of payment. And then we're getting to the end of this uh this talk here, but I think that, you know, LLMs, I'm fully AI pilled, right? But we want to make sure that we introduce la- language models, small tiny models in a very skeptical conservative way. So, being AI filled is great, but you should also be very AI skeptical. Like these things, they make mistakes and it's not even you can't even say they make mistakes. Like we make mistakes designing them. We might set them up to fail. So, we have to be very skeptical of them and we have to use them in a way that's also cost-effective. You can't throw I mean you don't you don't want to use an overpowered over expensive model cuz then if you're going back to if you're reducing costs or not. Let's say it's ends up being super super expensive to deliver one of these routine things that need to be done a thousand times a day. You definitely don't want that. All right. Thank you very much. \>\> \[music\]