Sara SLMs for Revenue Cycle: Reading Notes So Coders Don't Have To

This is the fourth and final post in a four-part series on Sara SLMs: 12 purpose-built small language models for clinical extraction, care documentation, and revenue cycle.

Part one: Introducing Sara SLMs | Part two: Sara SLMs for Clinical Extraction | Part three: Sara SLMs for Care Documentation and Planning

Revenue cycle teams don't lose money because they don't understand billing rules. They lose it because clinical notes are long, physician shorthand is dense, and the evidence that makes a coded diagnosis defensible is buried somewhere in a document that was written for a clinician, not a compliance audit.

A mid-sized health system processes around 30,000 encounters a month. In each of those notes, there may be a condition documented but never coded, a diagnosis coded without a sentence of supporting evidence, or a CPT code pair that will come back flagged by CMS thereby requiring someone to locate the clinical justification for billing both procedures in the actual note and not a template. The industry loses more than $20B annually to avoidable denials and $6B to coding errors, not because teams aren't doing their jobs but because reading clinical notes carefully, at that volume, is a task that consistently outpaces the people assigned to it. Hiring more coders extends capacity at the margin. It doesn't change the underlying reading problem.

Sara-RCM addresses three specific versions of that problem, with one fine-tuned model for each.

Ask a frontier model to find a missed diagnosis in a clinical note and it will usually return an ICD code. The response is confident, the format is clean, and the clinical reading that should sit between the note and that code where a model works through the medications, lab values, and physical exam findings and reasons about what they collectively imply often gets compressed into something that can't be audited or handed to a coder for independent review.

That compression matters because coding isn't just identifying what's in a note. It's documenting why it's there, traceable to specific language in the encounter. A coder who acts on an AI-generated code without being able to trace it to a specific sentence has introduced audit liability even when the code happens to be correct.

The failure mode here is different from what we described for Sara-Extract in our second post; that was a variance problem where the same note came back with different concepts on each run. Sara-RCM's challenge is a reasoning problem. General-purpose models are optimized to produce well-formatted outputs at speed; they're not optimized to locate the sentence in a 1,200-word note that distinguishes evidence of Monitoring from evidence of Evaluation for a specific diagnosis, because that distinction requires reading the note as a clinician would, not pattern-matching on medical vocabulary.

For a coded diagnosis to hold up in an audit, the encounter note needs to show the condition was Monitored, Evaluated, Assessed, or Treated during that visit. Any one of the four categories is sufficient. The challenge isn't knowing the rules. Every experienced coder knows the rule. It's applying it to every coded condition across every encounter, at production volume, while catching the cases that look compliant on the surface but aren't.

The MEAT Evidence Checker was built for exactly this. Given a segment-numbered encounter note and a list of diagnoses, it reads the note and returns per-diagnosis evidence across all four MEAT categories, with each finding mapped to a specific note segment and a confidence score attached.

The straightforward cases like "Type 2 Diabetes, on Metformin, HbA1c reviewed this visit" laid out cleanly in the Assessment and Plan aren't where audits originate. The hard cases are the carryforward diagnoses: chronic conditions coded because they're part of the patient's problem list but received no clinical attention in this particular encounter. Conditions that appear once in a long A&P paragraph without distinct documentation for any MEAT category. Findings that contradict a coded diagnosis, which a human auditor would flag and which most AI systems miss because they stop at the word match. The model was specifically built to surface those before they leave the system.

F1 score for diagnosis match was 99.6% across 178 records spanning 18 conditions. Segment accuracy, which is identifying which part of the note supports each diagnosis, rather than confirming that support exists somewhere in the document, was 91.2%. Pass/Fail accuracy measures acceptance of a MEAT criteria by a trained clinical coder. 

Comparable frontier models can locate diagnoses in a note. They don't map them to supporting segments with the specificity an audit requires, because that isn't what they were trained to do.

Under-coding is quieter than denials. The condition is in the note, it is implied by a medication, confirmed by a lab value, described in the physical exam but it never made it into the Assessment and Plan, so no code was assigned. The encounter closes, the revenue goes uncaptured, and nothing in the workflow signals that anything went wrong, because technically nothing did.

The Missed Coding Detector reads clinical evidence across the full note: active medications, lab values, vital signs, past medical history, review of systems, physical exam findings. It looks for conditions present in that evidence but absent from what was billed. When it finds one, it surfaces the condition name and the supporting clinical evidence, not an ICD code.

That design choice matters for anyone evaluating this category of AI. Translating "three consecutive blood pressure readings above 140/90 and an active lisinopril prescription" into a specific ICD-10-CM code involves clinical judgment, payer-specific coverage rules, and professional liability that belongs to a coder, not a model. Sara-RCM tells the coder what the note says. The coder decides what to bill. Any system that skips that step assumes it can absorb the liability, and most of the time, it can't.

Confidence is stratified: High when multiple independent clinical signals converge on the same condition, Medium when there's one strong signal, Low when the evidence is indirect or contextual. A model with a high false positive rate becomes something coders stop trusting and route around. The 3.3% false positive rate on our holdout set reflects deliberate calibration toward that concern. Condition F1 score was 94.7%.

NCCI edits like Procedure-to-Procedure (PTP) and Medically Unlikely Edits (MUE) represent a smaller share of claims volume, but they're disproportionately costly when they go wrong in either direction. Failing to defend a legitimate bill leaves revenue uncollected; unbundling procedures when the documentation doesn't support it creates compliance exposure. The question is not limited to whether two CPT codes appear in the note. It's whether the clinical documentation specifically justifies billing them as separate procedures which are different anatomical sites, independent clinical intent, sufficient documentation for each and that determination requires enough clinical context to understand what the procedures actually were, not just that they were performed.

The NCCI Edit Resolver takes the encounter note and the flagged CPT pair and produces a structured decision: approve, deny, or flag, with a modifier recommendation, a clinical rationale grounded in the actual documentation, and a confidence score. For PTP edits, it classifies the procedural relationship and recommends the appropriate modifier where one applies. For MUE, it determines the maximum units billable per CPT per encounter.

One instructive side finding in this model's development came from a training experiment that had nothing to do with the final evaluation. We trained the same NCCI classifier with identical LoRA configuration, identical training data, identical hyperparameters on two different base models. On Gemma 3 27B, the outputs looked structurally correct but were clinically hollow. Cosine similarity, which measures how closely the model's reasoning matched expert clinical rationale, came in at 0.183. The same training process on MedGemma 27B produced 0.818. The only variable was whether the base model had been pre-trained on clinical language, which turned out to be the difference between a model that mirrors the format of clinical reasoning and one that actually does it. MedGemma already understood what anatomical separation means in the context of surgical billing. Gemma produced language that described the concept without grasping it.

Justified accuracy which is correctly determining whether co-billing is clinically supported is 75%, with clinical grounding and reasoning quality scores of 3.85 and 3.84 on a 5-point scale. Clinical grounding measures whether the rationale is anchored in the note's actual documentation rather than generic or invented justification; reasoning quality measures whether the clinical logic connecting that evidence to the decision holds up the way an expert reviewer would reason through it. 

Against every comparable self-hosted model in the evaluation, Sara-RCM wins 68% of head-to-head matchups. Claude Haiku 3.5 and Sonnet 4 score higher on clinical grounding and reasoning, they're significantly larger models, and that gap is real but both require routing PHI to an external API, which rules them out for most production healthcare deployments regardless of benchmark performance.

Some  revenue cycle AI systems try to make the billing decision for you. We consciously did not build that, and the reason has less to do with legal caution than with what it would mean for how a coder actually works.

The coder owns the claim. They carry the professional liability, they know the payer, they understand the documentation habits of the physicians they work with, and they've accumulated years of judgment about which signals in a note matter and which don't. A model that produces an ICD code and instructs a coder to bill it has automated the one step in the process that benefits most from human judgment, and handed back a conclusion the coder would need to re-derive from the note anyway before feeling confident using it.

Sara-RCM is built around a different premise: the model does the reading and surfaces what it found, with the evidence intact. The MEAT checker maps supporting documentation back to the note. The missed coding detector surfaces conditions alongside the clinical signals that suggest them. The NCCI resolver recommends a modifier and writes the rationale in enough detail that a coder can evaluate it against the actual documentation. Then the coder makes the call which is both the right workflow and the thing that makes the output auditable in a way a bare code recommendation isn't.

Most revenue cycle AI gets evaluated on output: whether the code looks right, whether denial rates improved, whether recommendations matched what a coder would have done. Those are reasonable questions, but they sit downstream of a more useful one: when the model flags something, what did it actually do with the clinical note to get there?

When it surfaces a missed condition, did it find clinical evidence like a medication, a lab result, an exam finding that supports the flag, or did it pattern-match on a diagnosis list and return a probable code? When a claim comes back denied for insufficient documentation, does the system know which note segments would have supported the diagnosis, so an appeal can be grounded in the actual record rather than a generic template?

Systems that can't answer those questions clearly are doing pattern recognition on clinical vocabulary, not clinical reading. The distinction tends to surface quietly in denial rates that don't improve the way the pilot suggested, in coders who start ignoring flags because too many of them don't trace to anything concrete in the note, in audits where AI-generated recommendations are defensible in format but not in substance.

Sara-RCM runs on your infrastructure, with no PHI leaving your environment, and every flag it surfaces points back to a specific segment of the documentation, something a coder can open the note and verify before making a billing decision.

This is the fourth and final post in a four-part series on Sara SLMs: 12 purpose-built small language models for clinical extraction, care documentation, and revenue cycle.