RAAPID

The architecture is the pitch. The company describes neuro symbolic AI combining machine learning with an explicit clinical knowledge structure, positioned specifically against systems that rely on pattern matching alone, and reports 92 percent out of the box accuracy rising above 98 percent after coder validation.

Whether the neuro symbolic characterization is technically distinctive or a naming choice cannot be verified from public materials, but the product does not function without models reading clinical documentation.

Coder validation is built into the workflow and the company is unusually precise about what it contributes, reporting accuracy of 92 percent before human review and above 98 percent after. Publishing both numbers rather than only the post review figure tells a buyer exactly how much work the human is doing, which is a more honest framing than most vendors offer. The company markets an autonomous platform while describing coder validation as the step that produces final accuracy, and a buyer should read the autonomy language against that.

The central claim is explainability and it is described concretely: every suggested hierarchical condition category code links to specific MEAT based clinical evidence, producing what the company calls a Glass Box transparent and explainable audit trail, explicitly contrasted with systems that cannot articulate the clinical reasoning behind a suggestion. MEAT is the documentation standard CMS auditors apply, so tying output to it is substantive rather than decorative. Model architecture and independent validation of the accuracy figures are not published.

One deployment option answers this axis structurally and the others do not, so the first question is which one a buyer is being sold. The platform can run inside the customer's own cloud environment, which means a health plan can put the whole pipeline behind a perimeter it already controls and the vendor never holds the documentation at all. That is a stronger answer than any retention policy and it is available rather than theoretical.

A fully managed service and an interface based option also exist, and under those the vendor does hold clinical data, with nothing published about retention, de identification, or what is returned and deleted at contract end. The knowledge structure raises the training question in a specific form worth asking directly rather than generally.

A platform built on an explicit clinical knowledge graph improves as that structure is refined, so whether refinement draws on customer documentation, and whether anything learned from one customer reaches another, is the material term, and it is not addressed. Nothing else is named: no model or provider, no hosting arrangement for the managed options, no sub processor list. The content is unstructured clinical narrative at population scale across health plan and health system populations. Ask which deployment applies to you, and under the hosted options what is retained and whether it informs the knowledge graph.

Claims are specific and quantified but entirely vendor reported with no independent validation located. Published figures include 92 percent out of the box accuracy rising above 98 percent with coder validation, 60 to 80 percent reduction in manual review burden, and 3 to 10 times return on investment. The company also asserts industry accuracy of 20 to 30 percent as its comparison baseline, which is a striking claim about competitors that no cited source supports. Backing from a major corporate venture arm is a diligence signal of a limited kind. Founded in 2022, so there is no longitudinal track record.

Converted from Not Rated. The surface is broad, the architecture offers a genuine mitigation, and the handling terms are unpublished.

The platform processes complete clinical documentation across health plan and health system populations, spanning retrospective chart review, prospective pre visit analysis and audit response. That is unstructured clinical narrative at population scale.

The mitigation is real and belongs here rather than only on the deployment axis. Because the platform can run inside the customer's own cloud environment, a health plan can put the entire pipeline behind a perimeter it already controls, in which case the vendor never holds the documentation at all. That is a structurally stronger answer than any retention policy, and it is available rather than theoretical.

It is not the only configuration on offer, though. A fully managed service and an interface based option also exist, and under those the vendor does hold clinical data. Nothing published describes retention periods, de identification, whether customer documentation contributes to model or knowledge graph development, or what is returned and deleted at contract end.

The knowledge graph raises the training question in a specific form worth asking directly. A platform built on an explicit clinical knowledge structure improves as that structure is refined, and whether refinement draws on customer documentation, and whether anything learned from one customer reaches another, is not addressed.

Ask which deployment applies, and under the hosted options what is retained and whether it informs the models.

Converted from Not Rated. Compliance is asserted and the instrument is not published.

No business associate agreement, addendum, role statement, subcontractor flow down, breach notification timetable or review cadence was retrieved. What exists is a statement that the platform is HIPAA compliant, which is a claim rather than a posture.

The role is clear on the standard configuration. Health plans, accountable care organisations and health systems are covered entities, and a vendor reading their clinical documentation to identify and validate diagnosis codes is a business associate with direct liability under the rule.

One configuration changes the analysis and a buyer should be explicit about which applies. Where the platform is deployed inside the customer's own environment and the vendor does not receive or maintain the documentation, the business associate relationship may be narrower than the standard case, covering software and support access rather than data custody. That is a materially different agreement, and it is the kind of distinction that gets lost when a single template is used for every deployment model.

Support access is the residual question under any model. Even in a customer hosted deployment, vendor personnel typically need access for implementation, tuning and troubleshooting, and that access is what the agreement must actually govern.

Ask which agreement applies to your deployment model, what standing vendor access exists in the customer hosted option, and how it is logged and revoked.

Corrected from Not Rated. Both credentials are held, and the level is stated nowhere by the company while third party sources contradict each other about it.

What is claimed by the company: HITRUST certification, maintained for two consecutive years, alongside SOC 2 Type 2. Two consecutive years is a useful detail because it evidences renewal rather than a single point achievement. A separate partner designation for healthcare artificial intelligence software adds a further external review, though of product rather than security.

The level problem is the reason this is a B. One third party account describes HITRUST i1 certification. Another describes r2. Those are materially different: i1 is a fixed control set certified for one year, r2 is the tailored risk based two year certification assessed across substantially more controls. The company's own material says only HITRUST certified. A buyer reading that would reasonably assume the higher tier, and the sources that name a tier do not agree, so neither can be relied on.

This index has an established rule that fits exactly. An audit partner's own account is creditable for certification facts, with attribution. Third party directories and comparison sites are not. Here every source naming a level falls in the second category.

One terminology note: the phrase SOC 2 Type 2 verified appears in company material. A SOC 2 engagement produces an attestation report, not a verification.

Ask for the certificate, the level, and the assessment date.

No FDA pathway applies, but this vendor is built around a specific regulatory regime and that is the point of the product. CMS risk adjustment rules govern here, particularly Risk Adjustment Data Validation audits, where a plan must produce clinical documentation meeting MEAT criteria to support every submitted diagnosis code. The company positions its evidence linking explicitly as defense against RADV clawbacks and covers RADV audit workflows as a first class use case. Building the product around the audit standard rather than treating compliance as an afterthought is the right orientation for this category.

No formal governance program or bias evaluation was located, but the explainability architecture functions as a governance control in practice, since a code that must be traced to specific documented clinical evidence cannot be generated from statistical association alone. That structurally constrains one failure mode this category is prone to. No analysis addresses whether performance varies by documentation quality, specialty, or population, which is the live equity question when documentation density differs across patient groups.

The traceability here is tied to the right reference and that is what distinguishes it from generic citation. Every suggested condition code links to specific clinical evidence assessed against the documentation standard that federal auditors themselves apply, producing an audit trail built to the test the output will actually face rather than to a standard the vendor invented.

Tying explainability to the auditor's own criteria is substantive rather than decorative, because it means a reviewer is checking the same thing an auditor would check, and a suggestion that cannot be supported against that standard is visible before submission rather than after a recovery demand. The company contrasts this explicitly with systems that cannot articulate the clinical reasoning behind a suggestion, which is a fair characterisation of much of this category.

Held at C because nothing external verifies the performance. The accuracy figures the company publishes carry no independent validation, no evaluation methodology is described, and no model architecture is disclosed, so a buyer can see the reasoning behind an individual suggestion without knowing how often the system suggests things it should not.

In risk adjustment that distribution matters, because the cost of over suggestion falls on a coder's time and eventually on an audit finding against the plan. No warranty, indemnity or remediation commitment was located. Ask for precision on suggested codes, the coder acceptance rate, and independent validation of the published figures.

Converted from Not Rated. An interface exists and no integration is named.

The platform is described as cloud based with interface availability for connecting to existing systems, and as integrating with existing systems and workflows. The prospective product implies deeper reach than retrospective review does, since pre visit summaries and in workflow prompts have to reach a clinician inside the system they are already using at the point of care.

That is the part a buyer should probe, because prospective risk adjustment lives or dies on it. A retrospective tool can operate on exported documentation. A prospective one that prompts during an encounter must render inside the record system, respect its workflow and write back what was addressed. The company sells the prospective capability without describing how any of that is achieved in any named system.

Nothing was retrieved naming an electronic health record, a supported version, a standards based interface, interface documentation or a data export path.

One deployment consequence cuts in the buyer's favour and is worth noting. Where the platform runs inside the customer's own cloud environment, integration is a problem the customer's own team can solve directly against its own systems, rather than depending on a vendor's connector roadmap. That is a different and often better position than a long list of prebuilt integrations.

Ask which record systems are live today for the prospective workflow specifically, whether prompts render natively or in a separate application, and what writes back.

Corrected from Not Rated, and this is the strongest deployment disclosure encountered in this pass.

Three distinct models are published rather than one. The platform can be run inside the customer's own cloud environment, with the company describing data sovereignty as remaining intact. It can be consumed as a fully managed service. Or it can be reached by interface from existing systems. Naming three options and letting the buyer choose where the data sits is the answer this axis exists to find, and almost no vendor in this index offers it.

The cloud provider is named, and one commercial consequence of that is unusually concrete. Organisations holding a consumption commitment with that provider can apply existing committed spend to the platform. The company notes this also removes the need for additional security approvals, which is accurate: software running inside a tenancy already assessed does not re open the infrastructure review.

Customer environment deployment is the material point for a health plan. It means complete clinical documentation for a member population need not leave a perimeter the plan already controls, which is a structurally better answer than any assurance about how a vendor protects data it holds.

What is still unpublished: region, tenancy separation in the managed option, subprocessor list, backup posture and retention terms.

Ask which model applies to your contract, and whether feature parity holds across all three.

Corrected from Not Rated. No price is published, and two disclosures here are commercial terms rather than outcome claims, which is more than most records in this pass offer.

The first is a guarantee. The company states a guaranteed ten to one return on investment. A guarantee is contractually different from a projection, because it places some risk on the vendor rather than all of it on the buyer. What it actually pays out on failure is unpublished and is the question to ask, but the existence of a guarantee is a real term.

The second is a procurement route. Organisations holding a cloud consumption commitment with the platform's underlying provider can apply existing committed spend against it. That materially changes effective cost for a plan already carrying such a commitment, and it is a specific, checkable mechanism rather than a value claim.

One further disclosure is relevant here rather than only to accuracy, because it speaks to incentive alignment. The company describes a two way architecture that both identifies unclaimed diagnoses with grounded evidence and flags codes lacking sufficient documentation for removal, and its post visit review is described as checking for upcoding as well as omissions. Publishing that the system removes codes as well as adding them is the direct answer to the question this index asks of every risk adjustment vendor, and it is the first record in this pass to answer it.

Still absent: rate, unit, term, minimum and whether any component is contingent on conditions captured.

Ask what the guarantee pays, and what the pricing unit is.

Coverage spans the full risk adjustment workflow rather than one phase, including prospective documentation improvement, retrospective coding recovery, and RADV audit defense, which is broader than competitors specializing at one end. Buyer types span health plans, health systems, at risk provider organizations, medical coding companies, and health technology companies. Program coverage centers on Medicare Advantage, ACA, and at risk arrangements. Not a clinical product and should not be evaluated as one.