← Back to Intel

Billing Automation That Matched The Experts First

Mar 8, 2026Omar Trejo7 min read

The Medicare improper payment rate ran at roughly 7% in 2025 — close to $29 billion — according to the Fiscal Year 2025 Improper Payments Fact Sheet (CMS, 2025). What that number hides is more useful than the number. The bulk of it is not fraud. It is documentation and coding rules, applied inconsistently, by people, at volume — which is to say it is a determinism problem wearing a compliance costume, and determinism is something software is unusually good at.

That is the problem ML LABS was asked to solve for HeartSciences, and it is worth saying plainly where the work came from: the billing automation described here was delivered under the ongoing ML LABS engineering retainer — the same practice that built their AI-ECG platform's cloud backend still owns engineering for them, and this system is one of the things that ownership produced. A retainer that never ships anything is a subscription. This is what the other kind looks like.

Between Medicare eligibility rules, CPT code requirements, payer-specific formatting, and CMS compliance mandates, clinical billing is one of the least forgiving operational domains in any industry. It is also one of the least automated: a study on healthcare revenue cycle management (PRS Global Open, 2024) still finds manual billing workflows to be the leading source of revenue leakage and administrative inefficiency across the sector — spreadsheets, manual data entry, and ad hoc validation, in a domain where one missed condition is an unpaid claim. A review of AI-driven medical billing (Cureus, 2025) finds the gap between automated and manual accuracy widening as rule complexity increases, which is the mathematically unsurprising result: humans do not get better at rule interaction as the rules multiply. The question was never whether people can do this work. It is whether they should be the control point in a workflow that turns on deterministic rules, traceability, and speed.

When Manual Processing Is Done

  • Rule density is rising. Eligibility, coding, and payer logic interact too tightly for reliable spreadsheet execution. The more a workflow depends on interacting rules, the worse a human queue performs against it.
  • Turnaround time is material. Delay affects cash flow, patient operations, and downstream service quality — and human queueing adds latency that no amount of headcount removes cleanly.
  • Auditability matters. Program integrity guidance (CMS) is explicit: if a workflow affects payment or compliance, the reasoning path must be recoverable. A spreadsheet records an answer. It does not record why.

The moment a workflow needs deterministic rule application and durable auditability at once, manual processing stops being cheap even when the labor rate still looks low.

The Rule Engine Is The System

The instinctive move is to automate the existing process, and it is the wrong one. RPA bots replicate human keystrokes faster, which means they replicate process defects at machine speed. Screen-scraping breaks the day the EMR ships a UI change. Lift-and-shift preserves every piece of hidden logic and exception-handling folklore that made the manual process fragile in the first place — and then runs it unsupervised.

What replaces manual processing is not a faster clerk. It is process re-architecture: define the rules, the exception paths, and the validation layers explicitly, then automate what is left.

graph LR
    A["Data Extraction<br/>(FHIR/HL7/adapters)"] --> B["Eligibility<br/>Rule Engine"]
    B --> C["CPT Code<br/>Generation"]
    C --> D["Validation &<br/>Submission"]
    D --> E["Audit Trail &<br/>Exception Queue"]

    style A fill:#1a1a2e,stroke:#0f3460,color:#fff
    style B fill:#1a1a2e,stroke:#ffd700,color:#fff
    style C fill:#1a1a2e,stroke:#16c79a,color:#fff
    style D fill:#1a1a2e,stroke:#16c79a,color:#fff
    style E fill:#1a1a2e,stroke:#e94560,color:#fff

Data extraction normalizes records from heterogeneous EMR systems into one canonical patient billing record — FHIR R4 APIs (HL7) where they exist, adapter layers for legacy interfaces (HL7 v2, flat files) where they do not, and validation at the point of extraction rather than three stages downstream. A scoping review of FHIR implementations (JMIR Medical Informatics, 2024) found practical variability across EMR deployments to be the primary integration challenge, which is the same finding the ECG platform's HL7 layer produced from the other direction: the standard tells you which fields exist, and the site tells you what is in them.

The eligibility rule engine is the core. It encodes business logic as explicit, testable, version-controlled rules that produce identical output for identical input. Medicare eligibility for chronic care management alone means checking Part B enrollment, hospice status, institutional stays, patient presence, and service time thresholds — conditions that interact across billing periods, and whose requirements the Medicare Claims Processing Manual (CMS) defines in detail. The engine produces a complete audit trail, correct rule interaction, and atomic updates when CMS changes a rule. That last property is the one that pays: a rule change becomes one deployment rather than a retraining exercise across every person who touches a claim.

CPT code generation aggregates clinical staff time across the billing period and maps it to the correct billing code, with modifier application and correct-coding validation (CMS) running before submission rather than after denial. Validation then runs in tiers, and each failure is classified by severity and routed rather than dumped in a queue:

  • Schema validation — required fields and data types
  • Referential validation — active NPIs, valid facility codes
  • Temporal validation — service dates inside the billing period
  • Business rule validation — diagnosis codes that support medical necessity

Shadow Mode Earns The Cutover

Replacing a live billing process is a migration, not a launch. The automated system ran in shadow mode first: processing live data, submitting nothing, and having its outputs compared against the manual team's every day, with every discrepancy investigated. That phase finds errors in both systems, which is the point — the manual process is not a gold standard, it is the incumbent.

The gate to supervised automation was 98%+ agreement with expert-adjudicated determinations. Not a target, not an aspiration: the threshold that had to be met before the automated system became the primary processor and human reviewers moved from processing every claim to reviewing exceptions. A number like that is only meaningful because the comparison set was expert adjudication rather than the manual team's own output — agreeing with the incumbent's mistakes is not accuracy, it is mimicry.

After the gate comes full automation, where human involvement narrows to exception-queue management and periodic accuracy audits, and each new facility onboards through a compressed shadow cycle rather than a fresh build. Throughout, three things are non-negotiable: audit-trail continuity across every phase, no regression in accuracy (a site showing elevated rejections goes back a phase, not forward), and documentation of the validation results and the rationale for each phase transition. The rules that make this survivable across many sites at once are the subject of the multi-site clinical operations architecture — the second system delivered under the same retainer.

When Source Data Is The Blocker

This entire approach assumes upstream data — EMR records, eligibility feeds, clinical encounter logs — exists in a form a program can extract. Where it does not, the pipeline produces more exceptions than throughput, and automation makes the mess faster rather than smaller.

The signal appears in Phase 1, and it is measurable before anyone commits to the build: if extraction turns up more than 15–20% of records with missing critical fields, or if the same clinical event is coded differently across sites, source-data instability is the constraint and no rule engine will out-argue it. Normalize first, then automate. The failure mode is not exotic — data scattered across systems that never agreed with each other, arriving in a pipeline that will now apply rules to it faster and produce disagreements at a rate no exception queue was staffed for. Automation inherits a data problem. It does not fix one.

First Steps

  1. Audit one facility's workflow end to end. Every data source, decision point, and handoff, with the hidden costs measured — rework, delay, audit exposure — not only the labor line.
  2. Validate the rules against history before touching live claims. Run the engine's determinations against expert-adjudicated outcomes and hold the 98%+ agreement bar before anything is allowed to submit.
  3. Shadow, then cut over. Connect to live feeds, submit nothing, and investigate every discrepancy. The discrepancies are the specification you did not know you were missing.

Automate Rules, Not Keystrokes

If billing is still being run by people applying interacting rules from a spreadsheet, the constraint is not effort and it is not talent — it is that the workflow has outgrown the control point. The path out is a deterministic rule engine with explicit validation tiers, a shadow-mode migration that earns its cutover against expert adjudication, and an exception queue that is treated as a feature rather than a failure. Once the engine is proven, each additional facility is a new data adapter rather than a new system, which is the entire economic argument for building it properly the first time.

That is one contained workflow, made into production software, held to written targets — a production AI workflow build, and it ships with its first 30 days of Operate run by whoever built it, because a rule engine only meets the payers' real behavior once it starts submitting, and that is precisely when it needs an owner rather than a handover document. If several billing and clinical workflows are moving at once and each new one lands on the same person, that is the state where a standing engineering owner beats a sequence of projects — which is what the compounding case for ownership is about, and what this system is evidence of.

References

  1. CMS. Fiscal Year 2025 Improper Payments Fact Sheet. Centers for Medicare & Medicaid Services, 2025.
  2. Nasser, L. K. The Evolution of Automated Medical Billing With Artificial Intelligence. Cureus, 2025.
  3. Tabari, P., et al. State-of-the-Art FHIR-Based Data Model and Structure Implementations. JMIR Medical Informatics, 2024.
  4. CMS. Medicare Claims Processing Manual, Chapter 12. Centers for Medicare & Medicaid Services.
  5. Chandawarkar, A., et al. Healthcare Revenue Cycle Management. Plastic and Reconstructive Surgery Global Open, 2024.
  6. CMS. National Correct Coding Initiative (NCCI). Centers for Medicare & Medicaid Services.
  7. CMS. Center for Program Integrity. Centers for Medicare & Medicaid Services.
NEXTTO PRODUCTION

Could this work for you?

Two minutes. Find out where you stand.

Fixed scope · written plan · Design and Build: full refund until you accept