AKASA

Models read full clinical records and interpret context rather than matching rules, which is the stated difference from the robotic process automation vendors this product is usually compared against. The specific claim is architectural and checkable: instead of recording and replaying screen interactions that break when a payer portal changes, the company trains models on portal, EHR, and clearinghouse behaviour so they tolerate interface change. That is a real engineering distinction in a category where much of what is marketed as AI is scripted automation.

The design is stated in the right terms: an expert in the loop model that autonomously handles high confidence encounters and escalates edge cases to revenue cycle staff, with coding presented as an assistant to coders rather than a replacement. Held back from A because the confidence threshold governing what proceeds without review is not published, which is the same gap flagged for Elation and Waystar. In coding and prior authorization the threshold is the control, and a buyer cannot evaluate the oversight model without it.

More disclosed than most in this category, with one substantial gap left open.

The training approach is stated plainly: a tailored large language model per health system, trained on that organisation's own clinical and financial data, on the argument that billing practice and documentation style are institution specific. Recommendations carry confidence scores surfaced to the coder, which is a per suggestion quality signal rather than an aggregate claim.

What is missing is the model itself and the numbers. No architecture or base model is named, no accuracy or precision figures are published, and no confidence threshold is given for what the system handles autonomously versus what it escalates. The company describes an expert in the loop design that autonomously handles high confidence encounters, which makes the threshold the operative fact, and it is not stated.

One tension a buyer should resolve directly. The models are reported as trained on more than 43 million clinical documents, while the product is also described as trained on each health system's own data. Both can be true of a base model with per customer tuning, but nothing published says whose data formed the base corpus or whether one customer's documentation informs another's model.

A reported claim that the models outperform general purpose models by up to 40 percent on health system tasks is vendor generated with no published methodology.

The training architecture is described and one tension inside it is left for the buyer to resolve. The stated approach is a tailored model per health system, trained on that organisation's own clinical and financial data, on the argument that billing practice and documentation style are institution specific, and a per customer boundary of that kind is a genuine control because a model tuned on one organisation's data is not obviously reusable against another's.

Alongside it the models are reported as trained on more than 43 million clinical documents. Both statements can be true of a base model with per customer tuning, and nothing published says whose data formed the base corpus or whether one customer's documentation informs another customer's model. That is the material question and it is a stewardship question as much as a technical one.

The data concentration makes it weightier: the platform ingests complete clinical documentation across every encounter, with records reported to average around sixty documents and fifty thousand words, for entire health systems. On enumeration there is nothing: no base model or provider named, no hosting arrangement and no sub processor list, and no retention or deletion schedule for documentation that has no ongoing purpose once a claim is finalised. Ask whose data formed the base corpus, whether your documentation joins it, and for a retention schedule.

Scale is substantial and specific: more than 650 hospitals and 6,500 outpatient facilities across all 50 states, with models reported trained on over 43 million clinical documents. The Cleveland Clinic strategic collaboration is a strong named reference, and its framing of the problem is unusually concrete, describing staff reviewing more than 100 clinical documents per case and selecting from more than 140,000 codes, taking up to an hour per encounter. Held back from A because outcome figures, a 13 percent reduction in accounts receivable days and 300 plus monthly staff hours saved, are customer reported without stated baselines or methodology.

The data concentration here is at the high end of the revenue cycle category. AKASA ingests complete clinical documentation across every encounter, with patient records reported to average around 60 documents and 50,000 words, and it does so for entire health systems. This is unambiguously protected health information and the volume is the point of the product.

Supporting controls are substantive: security infrastructure aligned to HITRUST CSF, SOC 2, NIST 800-53 and CIS, continuous monitoring, and a documented incident response policy, all set out on a dedicated data handling page rather than inferred.

The per health system training boundary is the strongest single control, since a model tuned on one organisation's data is not obviously reusable against another's.

Three gaps. No retention or deletion schedule is published for the clinical documentation ingested, which for coding has no ongoing purpose once the claim is finalised. No subprocessor list. And the base corpus question noted on model transparency lands here too, because whether 43 million documents from other organisations sit underneath a customer's tuned model is a stewardship question as much as a technical one.

Business associate status is not in question. AKASA processes complete clinical documentation on behalf of hospitals and health systems, so it handles protected health information as the core of what it does, and it states HIPAA compliance directly.

The supporting evidence is better than a policy statement. HITRUST R2 certification maps onto the HIPAA Security Rule and is externally validated against hundreds of tested controls, which is a stronger signal than a compliance page. Infrastructure alignment to NIST 800-53 covers much of the same ground independently.

Held at B because the posture itself is unpublished. No business associate agreement or its terms appear publicly, the company does not state its role in those words, and no evaluation or review cadence is given. None of the three routes to a higher grade in this index is taken: publishing the instrument, publishing the role alongside an evaluation cadence, or publishing both roles and the switch between them.

For a vendor with a genuine trust page already built, this is a presentational gap rather than a substantive one.

Among the stronger positions in the revenue cycle category. HITRUST R2 certification, the tailored risk based tier rather than a fixed control set, stated explicitly as R2 rather than left ambiguous. A SOC 2 report. Infrastructure aligned to NIST 800-53 and CIS benchmarks. Continuous monitoring with a documented incident response policy. And a dedicated trust and security page a buyer can read without entering a sales process, which is a real trust surface and something several better known peers lack.

One avoidable imprecision keeps this from being exemplary, and it is the disclosure failure this index finds most often. The company describes itself as SOC 2 certified and SOC 2 compliant, and never states the type. Type 1 tests whether controls are designed appropriately at a point in time; Type 2 tests whether they operated effectively over a period, and only the second tells a buyer anything about sustained practice.

The word itself is also wrong in a way worth knowing. SOC 2 produces an attestation report from a CPA firm, not a certificate. There is no certification body and no registry to check, so SOC 2 certified is not a thing anyone can hold. Naming the type would cost one word and would move this record from strong to unambiguous.

The finding here is not that this vendor lacks a credential. It is that no regulator or accreditor governs vendors in this category at all, and a buyer should understand why that matters.

The FDA has no jurisdiction, since nothing diagnoses or treats. Unlike the credentialing lane, where NCQA and URAC certify verification organisations, and unlike payer side utilization management, where URAC and NCQA accredit the review itself, provider side revenue cycle has no vendor level accreditation to hold. Nobody examines this software from outside.

The regulatory weight instead falls entirely on the customer. Coding sits under the False Claims Act, OIG compliance programme guidance and CMS billing rules, and it is the health system that signs and submits the claim. If a recommended code is not supported by the documentation, the provider carries the liability and the vendor carries none.

So the questions that substitute for a clearance are these: what is the published coding accuracy and against what reference standard, what is the audit trail on every recommendation, and does a credentialed coder verify before submission. AKASA answers the third clearly, since coders accept or revise every suggestion, and provides justifications linked to source text. It publishes no accuracy figure.

Earns the B on evidence surfaced at the point of decision rather than on published testing. Every code recommendation arrives with a justification linked directly to the supporting medical text, alongside coding references and a confidence score, and a coder accepts or revises it. That gives the person accountable for the claim the means to check the reasoning rather than accept a suggestion.

One design point deserves credit because it is not the default in this category. The system is described as flagging unsupported codes and compliance risks as well as missed coding opportunities, so it is built to move recommendations in both directions rather than only upward.

That matters because of where the pressure sits. A tool whose value is measured in recovered revenue has a natural direction of travel, and the party that benefits from a higher code is the customer while the party exposed if it is unsupported is also the customer. Bidirectional flagging is the structural answer, and a buyer should verify it operates in practice by asking what proportion of recommendations reduce rather than increase reimbursement.

Held at B because nothing is published on bias evaluation, accuracy by document type or service line, or false positive rates.

A real mechanism sits on this record and the number that governs it does not. Recommendations carry confidence scores surfaced to the coder, so a per suggestion quality signal reaches the person deciding rather than an aggregate claim reaching the buyer, and that lets a coder weight a suggestion instead of accepting or rejecting it blind. What is missing is the threshold.

The company describes an expert in the loop design that autonomously handles high confidence encounters, which makes the threshold the operative fact of the entire product, and it is not stated anywhere located. That is the disclosure a direct competitor in this category does publish, so the omission is a choice rather than a limit of the category.

Without it a buyer cannot establish what share of encounters are finalised without a human, what confidence level the vendor considers sufficient to bill on, or who set that level. No accuracy or precision figure is published either, and a reported claim that the models outperform general purpose models by up to 40 percent on health system tasks is vendor generated with no methodology and uses the unfalsifiable construction. No warranty, indemnity or remediation commitment was located. Ask for the autonomy threshold, the accuracy at it, and the proportion of encounters finalised without human review.

Designed to layer on existing EHR systems without replacement, spanning payer portals, EHR interfaces, and clearinghouse connections, with results written back into the EHR. Third party review is usefully candid that depth is uneven: Epic integration is deepest, including Hyperspace, while Cerner and MEDITECH integrations vary by version and configuration, with a recommendation to obtain references from comparable environments before committing. Buyers not on Epic should treat that as a real diligence item rather than a footnote.

One architectural fact is disclosed and it is a real differentiator in this category. AKASA requires no on premise installation and states it offers multiple options for secure data exchange, which it positions explicitly against revenue cycle peers that do require local infrastructure. The platform sits on top of existing electronic health record systems rather than replacing them, and implementation is reported at around four months, including a period where the models observe workflow before making suggestions.

Beyond that the axis is unanswered. No hosting provider is named, no region or data residency statement is published, and there is no subprocessor list. For a cloud only architecture handling complete clinical documentation from entire health systems, where the data sits is the question the model most needs answered, and it is the one not addressed.

A buyer should also establish what the per health system model tuning means physically. If each customer gets its own tuned model, ask whether it runs in an isolated environment and what happens to it at contract end.

No published pricing and no published pricing mechanism. Contracts are negotiated privately with mid to large health systems.

There is a pointed contrast worth noting, because it is the company's own material. AKASA publishes buyer guidance advising health systems to establish exactly what is included in an automation contract, how the pricing structure is set up, and the methodology behind the pricing. The advice is sound. The company follows none of it about itself.

Third party analysis sites describe a structure combining subscription fees scaled to claims volume with a percentage of recovered revenue on denial modules, and some publish detailed revenue splits and return on investment ranges. None of this comes from AKASA, some of it asserts financial detail no outside party could know about a private company, and none of it should be carried into a budget as though the vendor had published it.

If the third party description is directionally right, the structure deserves the same scrutiny applied to any success fee arrangement in this index: a percentage of recovered revenue means vendor compensation rises with the volume and size of upward adjustments, while the party carrying False Claims Act exposure for an unsupported code is the health system. Establish which modules are priced this way and what the rate is.

Clearly bounded to provider side revenue cycle across coding, clinical documentation integrity, prior authorization, eligibility, and claims, sold to health system finance, revenue cycle, and health information management leadership. Scales from regional hospitals to multi state networks. No claims outside revenue cycle.