Maverick Medical AI

The model is the product. Clinical notes and radiology reports arrive, deep learning and large language models assign the codes, and the output goes to billing. Remove the model and nothing remains that a customer would pay for, because there is no workflow layer, network or platform underneath it.

The point of care variant sharpens rather than dilutes this. CodePilot runs against the report while the radiologist is still in it, which places the model earlier in the process than the rest of this lane rather than making it more peripheral. The company sells to providers, payers and revenue cycle management companies, and in all three the sold unit is the code assignment itself.

Both numbers a buyer needs are published, which is more than the better funded Arintra manages. Direct to bill is stated at 85 percent and accuracy at 97 percent, and the company frames the direct to bill figure as the barrier it broke rather than burying it. That pairing is the honest one: direct to bill measures charts reaching billing untouched, accuracy measures whether the engine was right, and quoting either alone lets a vendor look better than it is.

What holds it below the A grade in this lane is the absence of any commitment behind the figures. No contractual service level agreement on automation rate, accuracy or turnaround was located, no confidence threshold governing which charts the engine hands off is disclosed, and no validation trial before go live is offered in the way Fathom offers one. The numbers are published and unenforceable.

The real time architecture also changes what oversight means here. Where a batch coder produces output a reviewer can inspect before submission, CodePilot acts inside the reporting session, and nothing published describes what a radiologist sees, can override, or is required to confirm at that moment.

The mechanism is named and one element of it is genuinely uncommon. Deep learning and large language models are identified, and the company additionally discloses synthetic data generation as part of how models are built, which is a statement about training data provenance that almost nobody in this category makes. Proprietary deep learning design models are cited as the differentiator.

Below that the disclosure thins out quickly. Output scope is given as ICD-10 and CPT codes and stops there, so a buyer cannot tell whether evaluation and management levels, modifiers, units or hierarchical condition categories are in scope, and the peers in this lane all enumerate those. No architecture, model class, version or training scale is described, and no accuracy breakdown by coding element is offered against the single aggregate figure.

One published claim should not be relied on. The company states it holds the largest database of any solution on the market, which is unfalsifiable as written, carries no unit and no comparator, and is the kind of superlative this index records rather than credits.

Sits at the top of the C band rather than the bottom, on the strength of one disclosure. Synthetic data generation is named as part of how the models are trained, which is a partial answer to the training data provenance question that Fathom, Arintra and most of this lane leave entirely blank. It does not say whether synthetic data supplements or replaces customer encounters, and that distinction is the whole value of the disclosure.

Everything else in the chain is unnamed. No foundation model provider, model class or version is identified despite large language models being cited, no hosting arrangement is described, no sub processor list was located, and no position on whether customer documentation contributes to model development was found.

The delivery route adds parties the company does not enumerate. The product reaches customers embedded inside third party platforms including a cloud radiology information system running on a named public cloud, and through a revenue cycle vendor that is also an investor. Each of those is a link in the chain between the health system and the model, and none is described as such. Ask for the base model, the sub processor list, and whether synthetic data is a supplement or a substitute.

Named deployments exist and carry weight. Maverick completed an implementation at RadNet in December 2024, which is the largest outpatient imaging operator in the United States and a demanding reference, and published a customer case study with Steinberg Diagnostic Medical Imaging in November 2025 on coding delays and costs.

What is missing is anyone outside the company assessing it. No third party research organisation has published on Maverick, in contrast to the KLAS work covering Fathom and Arintra, and no peer reviewed publication, prospective study or independently audited accuracy measurement exists. The 85 percent direct to bill and 97 percent accuracy figures are vendor stated and have not been validated externally.

Deployment scale is the specific gap. No chart volume, facility count or customer count is published anywhere, so a buyer cannot distinguish a handful of imaging references from a business operating at scale. For a company of this funding level that distinction matters, and it is the first thing to ask for.

The stewardship questions are unanswered across the board. There is no retention schedule, no statement on whether customer reports and notes contribute to model development, no de identification position, no access control description, and no breach or incident history disclosure. The only adjacent material is an assertion of operating in a compliant and certified environment, which speaks to controls in general rather than to how this product handles the data it ingests.

Synthetic data generation is disclosed elsewhere as a performance capability, and the company never connects it to data protection. It could mean models are trained on generated rather than real patient records, which would be a materially better stewardship position than peers hold, or it could mean synthetic data augments customer encounters. The company does not say, and the index does not infer.

The exposure is concrete. The product ingests complete radiology reports and clinical notes, operates in real time inside the reporting session, and reaches customers through embedded third party platforms, so patient data crosses more boundaries here than in a batch coding architecture. Held at D rather than C because no external assessment of any kind substantiates the compliance claim and no stewardship specific statement exists to grade.

Compliance is asserted rather than evidenced. The company's home page carries a compact badge line pairing privacy compliance with SOC 2 certification, and a partner announcement describes operations inside a compliant and certified environment. Both are statements, neither carries a verb, a scope boundary, a date or an assessing party.

There is no health specific external certification. Fathom holds HITRUST i1 and Arintra holds e1, both independently assessed and both dated; nothing equivalent was located here, and the framework that maps a certifiable control set onto health privacy requirements is exactly what would move this grade.

No business associate agreement posture, template, negotiation stance or execution requirement was located. Given the company processes complete reports and notes for United States providers, agreements necessarily exist; none of it is public.

One credential is claimed and it fails the credential test. SOC 2 appears as a home page badge and, in a partner announcement, as a description of a certified environment. No report type, no audit period, no auditor, no scope statement and no date accompanies it in any source located. A certification counts on this index when it carries a verb and a scope boundary; a badge carries neither.

A dedicated retrieval pass on security and compliance material found nothing further. There is no trust center, no report availability or request process, no penetration testing disclosure, no vulnerability disclosure policy, no subprocessor page and no uptime or incident history. The absence is recorded after looking rather than assumed.

This is the lowest security disclosure in the autonomous coding lane and the gap between it and the rest is wide: two competitors hold dated external health specific certifications with the tier named. Producing a SOC 2 report type and period would move this grade immediately, which is worth stating because the underlying posture may well be sound and simply unpublished.

No device pathway applies and none is claimed. Assigning billing codes from a finalised report is an administrative determination rather than a clinical one, so the absence of a clearance is correct and is not a gap.

The exposure sits in claims submission. Codes on a claim are representations to a payer, and where they are wrong the framework is federal false claims enforcement, which lands on the billing provider rather than the vendor. The company states its models ensure codes meet payer criteria for reimbursement, which is a claim about payment likelihood rather than about coding correctness, and those are not the same thing.

One feature warrants a regulatory note the batch coders do not need. CodePilot suggests text for a physician to embed in the report before it is finalised. Software that shapes the documentation and then codes from it sits closer to the documentation integrity rules than a system that only reads a finished note, and nothing published addresses that posture.

A monitoring mechanism is named. The company lists audits alongside real time analytics as a product feature, which is the same shape as Fathom's audit programmes and carries the same limitation: the mechanism is stated and no result from it is published. No distribution of assigned codes against an expected benchmark, no breakdown by specialty, payer or physician, and no bias testing or model validation methodology was located.

The governance question specific to this vendor is one no other record in the lane raises, and it deserves to be on the record. CodePilot suggests text that is missing from a physician's report so it can be embedded before the report is finalised, and the same vendor's models then derive the billing codes from that report. That closes a loop between the party influencing the documentation and the party coding from it, in a domain where documentation is what justifies the code on audit.

That design may be entirely benign and is a reasonable way to fix genuine documentation gaps at the point they occur. Nothing published establishes which it is: there is no disclosure of what the suggestions optimise for, whether suggested text is flagged in the record as machine originated, whether physicians must affirmatively accept it, or whether the reimbursement effect of accepted suggestions is measured. Ask all four.

Better positioned than Arintra and short of Fathom, for a specific reason. A stated performance level exists against which a shortfall could be measured: 85 percent direct to bill and 97 percent accuracy, published together rather than one standing in for the other. Without a published accuracy figure there is nothing to hold a vendor to, and this vendor publishes one.

Nothing converts it into recourse. No service level agreement, warranty, indemnity or remediation commitment was located, no confidence threshold governing autonomous handling is disclosed, no accuracy breakdown by coding element exists, and no denial or reversal rate for assigned codes is published. Fathom's contractual guarantees on automation rate, accuracy and turnaround are the benchmark this falls short of.

The allocation question is sharper for a real time product. Where a suggestion is embedded in a physician's report and a code is later derived from it, responsibility for an incorrect code is genuinely harder to trace than in a batch architecture, and the provider carries the false claims exposure in either case. Ask how liability is apportioned when a code derived from a suggested documentation edit is found wrong on audit.

Integration is real, named and specific, and it is not with record systems. The product is embedded inside a cloud radiology information system across two named platforms, integrated with two radiology reporting products, and paired with a radiology billing vendor. Those are concrete partnerships with a described mechanism rather than adjectives about integration quality, and the primary platform partner reports use across more than 750 sites, so the distribution reach is genuine.

What is absent is the thing this axis measures. No integration with Epic, Oracle Health, Athenahealth or any general record system was located, no interface standard is described, and no vendor program listing or certification equivalent to Epic Toolbox exists. A health system evaluating this alongside Arintra or Fathom would find no path into its own record system documented.

The strategic route appears to be distribution through platform partners and through the revenue cycle vendor that invested in 2025, rather than direct record system integration. That is a coherent strategy and it leaves the depth on this axis dependent on whichever partner the buyer already runs.

The hosting position is undescribed. No cloud provider, region, residency commitment, tenancy model or customer controlled option was located for the product itself. The one public cloud named anywhere in the material belongs to a platform partner and describes that partner's infrastructure rather than where Maverick processes data.

Geography makes this more pointed here than for the domestic vendors in this lane. The company is headquartered in Tel Aviv while its customers, deployments and coding regime are all United States, so clinical documentation is plausibly crossing a border for processing, storage or engineering support. Nothing published confirms or denies it, and for a health system carrying residency obligations that is a threshold question rather than a detail.

The real time architecture compounds it, since latency sensitive processing constrains where compute can sit and therefore says something about the deployment that the company has not stated. Ask for the processing and storage regions, the tenancy model, and whether personnel outside the United States hold access to production data.

Neither a price nor a proxy for one is published. There is no pricing page, no unit of charge, no range, and no percentage cost reduction against the buyer's existing coding spend, which is the disclosure that earns peers in this lane a grade above D when absolute pricing is withheld. Cost benefit appears only as adjectives: decreased operational expenses, reduced denials, backlogs eliminated.

The single concrete commercial disclosure is an implementation timeline, stated as go live in roughly three months. That is genuinely useful for planning and it is not economics.

A published customer case study addresses coding delays and costs, so a cost figure exists in at least one documented deployment and has not been surfaced in a form a prospective buyer can use. Ask for the pricing mechanism, whether the fee is per report, per chart or a volume band, and what the case study cost reduction actually was.

The claimed coverage and the demonstrated coverage are not the same shape, and the gap is the finding on this axis.

The claim is broad. The company positions the platform as navigating diverse medical domains, serving providers, payers and revenue cycle management companies, with models trained across specialty specific charts.

The evidence is radiology, almost entirely. The completed implementation is an imaging operator, the published case study is a diagnostic imaging group, and every named integration partner is an imaging platform or an imaging billing vendor: a cloud radiology information system, two radiology reporting products, and a radiology billing company. The real time point of care design is built around a report being finalised by a radiologist, which is a workflow specific to reporting specialties rather than to office visits.

Graded on demonstrated coverage. A buyer in radiology, pathology or another reporting specialty should read this as depth; a buyer coding office visits or inpatient encounters should ask for a reference in their own setting before treating the broad claim as coverage. Nothing addresses coding regimes outside the United States.