Cleo Health

Founded by clinical AI researchers and built outward from an ambient scribe into charge capture, CDI, coding, census management and patient assignments, all on the same model stack. No legacy platform or services business underneath.

Several surfaces act during care rather than after it, and none is bounded in public. Real time CDI queries prompt the clinician mid encounter, clinical decision score reminders surface during care, real time risk analysis produces recommendations, and patient assignments are automated. No confidence threshold, accuracy rate, abstention behaviour or review gate was located for any of them.

Prompting during the encounter is the design choice that makes this platform valuable and also the one that most needs disclosure, because a prompt shapes what the clinician says and documents rather than correcting it afterwards.

The problem is described with genuine precision, naming layered context, re evaluations and care team handoffs as the specific ways acute care breaks a general purpose scribe, and criticising competitors for missing context and dropping critical details in noisy dynamic settings. That is a real technical position.

What is entirely absent is measurement: no accuracy figure, model card, named models, error rate or evaluation methodology was located, which is a notable gap for a platform deployed across a claimed 400 or more facilities.

Nothing identifies the model layer: no model or model family, no foundation model provider, no hosting arrangement and no sub processor list was located in two passes. One party is identifiable from published material and it introduces a category of the chain this index has not been checking systematically. The vendor describes using a commercial observability platform across its systems.

Telemetry and error monitoring tooling routinely ingests application logs, and application logs in clinical systems frequently contain patient identifiers, request payloads or fragments of clinical text unless deliberately scrubbed. So an observability vendor can be a processor of protected health information without appearing in anyone's mental model of the chain, and it is the kind of party that rarely reaches a security questionnaire.

Treat this as a standing check for every vendor in the index: ask which monitoring, logging and error tracking services are in use and whether protected health information reaches them. What that chain holds here is unusually broad.

The platform spans an entire inpatient stay, holding captured conversation alongside census and patient movement data drawn continuously from a hospital feed, patient assignments, charges, codes, documentation integrity queries and responses, handoff summaries, and length of stay and payment group estimates. That is a longitudinal record of an admission and of a hospital's operations, not a note. Ask for a sub processor list including observability tooling, and for the position at contract termination.

Deployment scale is substantial and specific at more than 400 facilities, with a named strategic partnership with Core Clinical Partners, a practice management company in emergency and hospital medicine, and named executives throughout. But no study, controlled evaluation, accuracy benchmark, third party rating or published outcome figure was located. Graded C on the standing precedent that scale of deployment does not substitute for evidence of benefit; a vendor at this footprint has the data to publish an outcome and has not.

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

The earlier assessment noted the gap is wider than usual because the platform spans an entire inpatient stay rather than a single encounter, and the second pass confirms how much wider. Alongside captured conversation it holds census and patient movement data drawn continuously from a hospital feed, patient assignments, charges, codes, documentation integrity queries and their responses, handoff summaries, and length of stay and payment group estimates. That is a longitudinal record of an admission rather than a note, and it is retained across a stay by design.

So the retention question is not how quickly audio is discarded. It is what persists about a hospitalisation after discharge, and what persists about a hospital's operations after a contract ends.

The scale sharpens it. The vendor states it will serve over seven million patients across more than four hundred hospitals, and that its customers represent a substantial share of United States emergency medicine and hospital medicine clinicians. A retention or training position that is immaterial at pilot scale is a national dataset at this one.

The training question is unanswered in either direction. Peers now state a position plainly, some committing never to train on clinical content and at least two operating an explicit permission gate.

One subprocessor is now identifiable from published material: the vendor describes using a commercial observability platform across its systems. Telemetry tooling routinely ingests application logs, so establish whether any protected health information reaches it.

Ask for the retention schedule per data type, the position at contract termination, and the training commitment in contract language.

No published health privacy statement or business associate agreement posture was located, which the earlier assessment rightly called surprising for an enterprise product deployed across hospital systems.

Agreements exist in large numbers, since the platform is live across more than four hundred facilities and receives a live patient movement feed from each. What is absent is any published statement a prospective buyer can read before entering a procurement process.

Two features of the deployment model make scope the substantive question rather than a formality.

The first is the customer structure. The vendor describes deep partnerships with large clinician staffing organisations representing a substantial share of emergency medicine physicians nationally. Where a staffing group contracts on behalf of clinicians working inside hospitals it does not own, the chain has three parties: the hospital holds the records and the custodial obligation, the staffing group contracts the vendor, and the clinician sits between them. Establish which entity is the covered entity for your purposes, whether the hospital is party to the agreement or merely the source of the data, and who is notified in a breach.

The second is the breadth of what flows. This is not encounter audio. A hospital feed supplies continuous patient movement data covering every admission, including patients no clinician using the product ever documented. Establish what the agreement permits the vendor to do with data about patients outside its documented encounters.

Ask for the agreement, which entity is party to it, and its scope over feed derived data.

No named or dated attestation and no trust centre were located.

The caution from the earlier assessment stands and is worth keeping visible, because it is the kind of thing a reader can easily miscount. Published engineering material describes commercial observability tooling used across the vendor's systems. That is evidence of operational maturity and monitoring discipline, and it is not a security attestation. Knowing when your systems misbehave is a different question from an independent examination of whether your controls operate.

The absence is more consequential here than for most of this lane because of what the vendor itself says about its customers. Its material states that operating in healthcare means trust is foundational and that its customers expect security, compliance, reliability and auditability from day one. That is the right description of the market, and enterprise hospital deployment at the stated scale, more than four hundred facilities and several million patients a year, will have involved security assessments by many individual institutions. So evidence exists in customers' hands and none of it is published.

Scope would be the substantive question when a report is produced. This is not a scribe. The platform ingests a live hospital feed, holds census and assignment data, produces charges and codes, and can trigger workflows in the record system. An attestation covering documentation alone would leave most of that outside the boundary.

Ask which report is held, its type, period and scope, and specifically whether the charge capture, assignment and workflow triggering components are inside it.

No clearance claimed and none required for documentation. The regulatory exposure is payment integrity, and this record is the most advanced instance of it in the category because of when the influence occurs.

Every other coding vendor in this lane operates after the fact: a note is written, then codes are suggested against it. This product operates during care. It delivers real time documentation integrity queries, specificity nudges and clinical decision score reminders while the clinician is still working, and the vendor's own comparison material presents retrospective review as the inferior alternative it displaces. So the record is being shaped as it is created rather than examined once complete, and the stated purpose of that shaping is optimised reimbursement and accurate diagnosis related group assignment.

One feature goes further and needs stating plainly. The vendor describes estimated diagnosis related group and geometric mean length of stay updating in real time as charges are created, and says this helps clinicians track length of stay and prioritise discharge planning.

That places an estimate of what the case pays, and how long comparable cases are expected to run, in front of a clinician at the moment they are deciding when a patient goes home. Both metrics are legitimate. Hospitals track length of stay against benchmarks for sound reasons, unnecessary inpatient days carry their own harms, and discharge planning genuinely benefits from knowing expected trajectory.

The question is whether an individual clinician making an individual discharge decision should see the payment estimate attached to it. A hospital monitoring length of stay in aggregate is doing operations. A number on the screen at the point of decision is something else.

Ask what is shown, to whom, and at what moment.

The most consequential position on the coding gradient found in this wave, and it deserves both halves of the argument.

The mechanism: real time clinical documentation improvement queries and granular medical decision making prompts are explicitly designed to encourage specificity at the point of care, supporting DRG assignment and, in the vendor's words, optimised reimbursement and revenue integrity, with competitors criticised for leaving revenue on the table. DRG assignment determines what an entire admission pays, so this is a larger financial lever than the E&M level of an office visit, and the prompt arrives before the documentation exists rather than auditing it afterwards, which is the same concern this index raised about Solventum at greater scale.

The counterweight is real and should be stated. Clinical documentation improvement is an established and legitimate hospital function, retrospective queries genuinely do interrupt clinicians days later, and doing it at the point of care is a defensible clinical argument rather than only a commercial one.

Separately, guidance on clinician performance against quality and patient experience scores is workforce monitoring and belongs in that conversation too. 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, across a platform the vendor states will serve over seven million patients across more than four hundred hospitals, with customers representing a substantial share of United States emergency and hospital medicine clinicians.

A position that is immaterial at pilot scale is a national one at this size, and the absence of any published measurement at that footprint is the finding rather than an ordinary gap. The output range compounds it because much of it is not documentation. Alongside captured conversation the platform produces documentation integrity queries, codes and charges, handoff summaries, and length of stay and payment group estimates. Two of those deserve separate treatment from a buyer.

A handoff summary is the artefact through which one clinician tells another what matters about a patient, and an omission there is a clinical event rather than a record keeping one. A length of stay or payment group estimate is a prediction about an individual admission that can influence discharge planning and resourcing, and nothing published describes its error characteristics or what a clinician is told about its confidence. Ask for accuracy and error characteristics per output type, particularly for handoff summaries and stay estimates, and for what the vendor commits to when either is wrong.

The earlier assessment found no named integration at all and called the absence conspicuous. The second pass answers half of it, and the half that is answered is the less important half.

The vendor states that it connects directly to a hospital's admission, discharge and transfer feed using standard interface protocols, and that no custom build or heavy technology involvement is required. That is a named mechanism against a named standard, which is more than most of this lane offers, and it is the right way to obtain census and patient movement data.

What it does not describe is the write path, and that is where the risk sits. This platform produces charges, diagnosis and procedure codes, patient assignments and handoff summaries, and separately describes translating conversations into actions such as triggering workflows in the record system. A movement feed is a read only channel. None of those outputs travels back over it.

So the questions remain open on the side that matters. By what mechanism do charges and codes reach the billing or record system. What identity do those writes carry in the audit log, and can they be distinguished from a human entry. What permissions does the platform hold to trigger a workflow, and what can an institution restrict. Triggering workflows is a materially deeper privilege than depositing a note, because it causes the receiving system to act.

A buyer should therefore treat the integration story as answered for ingest and unanswered for output, and press specifically on the second.

Ask what connects to what in each direction, for charges, codes, assignments and triggered actions separately.

No hosting region, residency option or full subprocessor list was located. Delivery is cloud with mobile clients on both major platforms.

One subprocessor is now identifiable from the vendor's own published material rather than by inference: it describes running a commercial observability platform across its systems to monitor reliability. That is a genuine disclosure and it is worth recording, because it is the kind of supplier that rarely appears on a vendor list and routinely handles more than buyers assume. Telemetry platforms ingest application logs, traces and error payloads, and clinical applications frequently include patient identifiers in those unless deliberately scrubbed. Establish whether any protected health information reaches it, whether log scrubbing is in place, and whether that supplier is covered by an agreement.

That is not a criticism of using such tooling. Monitoring is how a platform serving several million patients a year detects failure, and the vendor is right to invest in it. It is a subprocessor question that most vendors leave a buyer to discover.

The rest of the axis is unanswered. Nothing establishes the hosting region, whether residency can be pinned by contract, or which model service generates documentation and coding output.

The continuous feed changes the shape of the residency question. Where a platform receives a live hospital movement feed, data flows constantly rather than per encounter, so the connection itself is a persistent path out of the institution and its endpoint location matters more than for a product a clinician invokes.

Ask for the region, the full subprocessor list, the model provider, and the log handling position.

No published rate card, tier structure or pricing model located. Enterprise sold to health systems and provider groups through demo and partnership. The vendor's own argument for the platform is vendor consolidation return on investment, replacing multiple point solutions, so a buyer should expect to be quoted against the combined cost of the tools it displaces rather than against a per clinician scribe rate.

Deliberately narrow and, within that boundary, the broadest acute care coverage in this index. Emergency medicine and hospital medicine only, but spanning the whole inpatient stay from admission through discharge rather than one encounter: layered context, re evaluations, care team handoffs, census management and patient assignments. QuickStart lets a clinician defer patient registration during an emergency and complete it afterwards, which reflects how acute care actually sequences. This is the third emergency medicine specialist in the index after Sayvant and QiiQ Scribe, and the only one extending into inpatient. No language coverage published.