CareBeam

The company was founded as ScribeAI and the models remain the product across every capability it has added: note generation, chart auditing, coding recommendation and the order drafting now in development. There is no services layer or platform business underneath.

Reach across documentation, auditing and coding with no published limits, and expanding further. The platform generates notes in real time, audits charts automatically, and surfaces E/M level recommendations and ICD-10 mappings, with AI assisted order drafting described as in development. No confidence threshold, accuracy rate, review gate, abstention behaviour or escalation path was located for any of it.

Automated chart auditing is worth singling out: a system that reviews documentation and recommends a different billing level is performing a judgement that would normally involve a coder or compliance reviewer, and no description of what a human does with that recommendation was found.

No accuracy figure, model card, named models or evaluation methodology located. The capability set is described clearly enough, specialty aware note generation, automated chart audit, E/M level recommendation and ICD-10 mapping, but nothing is measured. For a product whose central claim is coding accuracy, the absence of any published accuracy result for the coding recommendations is the specific gap.

Nothing identifies any party in the chain: no model or model family, no foundation model provider, no hosting arrangement and no sub processor list was located in two passes. What the chain holds is wider than a scribe's and the distinction is one buyers rarely draw. A scribe holds what it recorded.

An auditing platform holds what it was pointed at, so this product ingests historical clinical content for patients whose encounters it never documented, and the population is potentially a whole panel rather than the visits since adoption. A patient can therefore be represented inside an unnamed chain without ever having attended a visit while the product was running.

One published figure makes the question current rather than academic: the vendor reports transcription volume rising more than thirty five fold year on year. Retention and sharing practices that were immaterial at one volume become the central question at another, and a policy written when a company was small should be re examined rather than assumed to have scaled with it. Ask for a sub processor list, and for retention stated separately for recorded encounters and for ingested chart data.

One named physician testimonial from a nephrologist and ACO medical director, describing reduced chart time and better reflection of care delivered. No study, controlled evaluation, accuracy benchmark, third party rating, deployment count or named institutional customer was located.

No statement on audio or transcript retention, de identification or training use was located.

The platform's stated scope makes those omissions wider than they would be for a scribe. It generates notes, audits existing charts for coding accuracy, produces coding recommendations, and delivers clinical guidance, all inside the record system. Chart auditing in particular means the product reads records it did not create, so the vendor holds historical clinical content for patients whose encounters it never documented.

That distinction is worth drawing because buyers rarely make it. A scribe holds what it recorded. An auditing platform holds what it was pointed at, and the population is potentially the whole panel rather than the visits since adoption. Establish what is ingested for audit, whether it is retained after the audit completes, and whether a patient who never had an encounter documented by this vendor nonetheless has records inside it.

The growth figure the vendor publishes, transcription volume rising more than thirty five fold year on year, is relevant here rather than as marketing. Retention practices that were immaterial at one volume become the central question at another, and a policy written when the company was small should be re examined rather than assumed to have scaled.

The training question is unanswered in either direction. Peers now state a position plainly, some committing that clinical content is never used to train or fine tune models and at least two operating an explicit permission gate over any training use. Both formulations are available and neither appears here.

Ask for the retention schedule separately for recorded encounters and for ingested chart data, and for the training position in contract language.

No product specific business associate agreement posture, template or scope statement was located.

Agreements exist, since the platform operates inside record systems at a growing provider base and no such deployment proceeds without one. What the grade records is that nothing is published, so a prospective buyer cannot establish terms, scope or subprocessor position before entering a sales process.

One scope question is specific to this platform rather than generic, and it follows from what the product does beyond documenting. Chart auditing means the vendor processes protected health information for patients whose encounters it did not record, potentially across a provider's existing panel. An agreement drafted around ambient capture describes the vendor receiving what it was invited to hear. It may not describe the vendor reading records created before it arrived, by other clinicians, about patients who have never been seen since adoption.

Establish which population the agreement covers, what the permitted uses are for ingested historical records as distinct from recorded encounters, and what happens to that ingested content at termination.

A second question follows from the stated direction. Order drafting is described as in development. Where a system prepares orders, protected health information moves onward to pharmacies, laboratories and imaging providers, which is a different transmission profile from producing a note. Ask whether the current agreement anticipates it, since capability is arriving faster than contracts are typically revisited.

One practical note: anything the company published on this before its rebrand sits under its former name.

Ask for the agreement, its scope across documentation and auditing, and the subprocessor list.

No named or dated attestation, no report of either type and no trust centre were located.

Two features of this vendor's position make the absence more consequential than a young company's usually is.

The first is the access model implied by the product. The platform is described as operating natively inside the record systems providers already use, and it audits existing charts rather than only writing new notes. Reading across a provider's existing records requires broad access to that record system, considerably broader than depositing a note. An examination would need to cover what that access permits, how it is scoped and whether an organisation can constrain it, and none of that is published.

The second is trajectory. Transcription volume is stated to have grown more than thirty five fold year on year, and the platform is expanding into order drafting. A control environment adequate for a small documentation product is not automatically adequate for a system reading a provider's whole record and preparing orders, and rapid growth is precisely when control maturity tends to lag capability. That is the argument for an examination rather than against one.

The rebrand is relevant only in one narrow way: a buyer searching for the company's security history should search the former name as well, since anything published before the change sits under it.

Fairness is due to a company at this stage and this grade reflects what a counterparty can verify before contracting rather than a judgement that controls are absent.

Ask which report is held or scheduled, what its scope covers, and specifically what record system permissions the platform requires to perform chart auditing.

No clearance claimed and none required. The regulatory exposure is payment integrity rather than device oversight, and this record states that more plainly than any other in the category, because the vendor has said it itself.

The company rebranded from a name describing a scribe to one that does not, and explained the move directly. Documentation was always the entry point, the fastest way into the workflow. The real problems were downstream: inaccurate coding, missed revenue, and documentation that did not reflect the actual acuity of care delivered.

That is the pattern this index has tracked across dozens of vendors, stated as corporate strategy by the company pursuing it. The scribe is the wedge and coding is the business. It is candid, it is a legitimate commercial strategy, and it is worth recording precisely because vendors usually leave a reader to infer it from a feature list. It also matters that documentation not reflecting actual acuity is exactly the ambiguity a published policy analysis identified as unresolved for this category: whether increased coding intensity represents care being described more accurately or described more profitably. The vendor has named the problem without answering which side of it the product lands on.

Two capabilities extend past documentation. Providers are given on demand access to clinical guidance, which is clinical reference operating alongside the note. And order drafting is stated as in development, which is the step from recording a decision to preparing an action.

One structural point to press: the same platform generates the note and then audits charts for coding accuracy. An audit performed by the system that produced the artefact cannot function as an independent check on it.

Formerly traded under a different name, which a buyer researching history should know.

Graded on the company's own stated strategy, which is unusually explicit. CareBeam describes documentation as the entry point and says the real problems were downstream: inaccurate coding, missed revenue, and documentation that did not reflect the actual acuity of care delivered. Acuity capture is the mechanism at the centre of coding intensity, so this sits on the gradient this index tracks from MarianaAI and Steer Health through Sayvant, Solventum and RevMaxx.

Two things place it mid gradient rather than at the aggressive end. The framing is corrective rather than maximising, and the word actual is doing real work: the claim is that documentation should match care delivered, which is also the legitimate argument against under documentation. And no revenue lift percentage is marketed and no contingent pricing was located.

Even so, a system that audits a chart and recommends a higher E/M level is making a judgement a buyer's compliance function should be auditing independently. No fairness statement, subgroup analysis or accent disclosure was located.

Two passes located no accuracy or error figure, no published limitations and no warranty, indemnity or remediation commitment, and the gap falls precisely where the product's central claim sits. The platform generates notes, audits existing charts for coding accuracy, produces evaluation and management level recommendations and maps diagnosis codes, so coding correctness is the thing being sold, and no coding accuracy result of any kind is published.

That is a different position from a scribe with no accuracy figure, because a coding recommendation is not merely documentation: it determines what is billed, and a wrong one creates false claims exposure for the practice submitting it rather than for the vendor recommending it. The audit function extends the exposure backwards in time as well.

Auditing charts means the product renders judgements about documentation it did not create, so an incorrect audit conclusion can prompt a practice to change coding on historical encounters, and nothing published describes what a user sees about why the system reached a conclusion or what happens when it is wrong. Ask for a coding accuracy result with a defined denominator, for what the audit output shows about its own reasoning, and for what the vendor commits to when a recommendation is wrong.

Positioned as EHR native, with the vendor stating the platform works across documentation and revenue cycle without requiring providers to learn new tools or change existing workflows, and that output is delivered inside the record systems they already use. Held at B because no named integrations, integration architecture, certification programme membership or write back mechanism was documented or verified in this pass, so native is asserted rather than demonstrated.

No hosting region, residency option or subprocessor detail was located, and nothing establishes which model service processes the encounter or what it retains.

One architectural claim is made repeatedly and needs unpacking rather than accepting, because it is doing more work than it appears to. The vendor describes its capabilities as delivered natively inside the record systems providers already use. Native is a marketing word rather than a technical one, and in this category it has covered everything from a certified interface to a browser extension overlaying a rendered page. Those have very different security and audit properties, and six vendors in this lane reach the chart by the second route while describing it in language that sounds like the first.

So the question is not whether it is native but what makes it so. Ask whether the platform connects through a permissioned interface, an approved marketplace application, an extension, or automation driving the user interface, and ask which of those applies for each record system supported.

The answer determines several things at once: whose identity the platform's reads and writes carry, whether an institution can constrain its access, and how its actions appear in the audit log. It matters more here than for a documentation only product because this platform reads across existing charts to audit them, so the access being described is broad rather than confined to encounters it captured.

Residency itself is unstated, and the growth trajectory the vendor publishes makes it worth pinning by contract rather than accepting as configured today.

Ask for the hosting region, the subprocessor list, the model provider, and the integration mechanism per record system.

No published rate card, tier structure or pricing model. Access is by demo request only. Given the platform spans documentation, auditing and coding support, a buyer cannot currently tell whether those are licensed together or separately.

Notes are described as specialty aware and the product is sold to independent practices, multi specialty groups and value based care organisations, with nephrology evidenced through a named user. Beyond that nothing is enumerated: no specialty count, specialty tuning detail, note format list, care setting range or language coverage was located, so breadth cannot be compared against vendors in this category that publish it.