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. Not one of them has a published confidence threshold, accuracy rate, abstention behavior or review gate.

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 once written.

The problem is described with precision, naming layered context, reevaluations and care team handoffs as the specific ways acute care breaks a general purpose scribe, and criticizing 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 is published, 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 subprocessor list is published.

One party is identifiable from published material, and it is a kind of party buyers rarely account for. 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.

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.

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 outcome figure is published.

No statement on audio or transcript retention, deidentification or training use is published.

The gap is wider here because the platform spans an entire inpatient stay rather than a single encounter. 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 hospitalization 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. The company makes no commitment never to train on clinical content and describes no 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, and whether any protected health information reaches it is not stated.

Business associate status is stated by the company in its own privacy policy, published under its operating entity Cleo Technologies. The policy commits that Cleo will enter a business associate agreement with each provider who uses the services, and that it agrees to maintain and protect all protected health information uploaded to the services according to the standards required of a business associate under HIPAA. That is an unconditional commitment stated as a term of the relationship rather than an offer made on request, and no tier condition attaches to it. It sits in the privacy policy rather than on the security page.

The same policy places a broad obligation on providers. Providers who upload patient data represent that they have obtained written consent from the applicable patients to use and disclose their data for that purpose. Written patient consent is a heavier requirement than verbal or notice based approaches, and in an acute care setting, where the platform draws continuously from an admission, discharge and transfer feed rather than from a single recorded encounter, it is not obvious how a provider would obtain it for every patient whose data reaches the system. Nothing published says what the company expects here in practice.

The agreement itself is not published for inspection before contracting, and nothing establishes whether it extends its obligations to subcontractors. The company does maintain a published trust center and states that vendor reports are collected and reviewed annually, which is adjacent evidence rather than the term itself.

The certification is named with its type and the company says the examination is complete. Its security page states that Cleo Health is HIPAA compliant and SOC 2 certified, and specifically that it has completed a SOC 2 examination and received a SOC 2 Type 2 report.

A trust center is published under the operating entity Cleo Technologies and can be opened without asking. It lists SOC 2 Type 1, SOC 2 Type 2 and HIPAA, states that the environment is continuously monitored through a compliance automation platform, and enumerates controls including formal risk assessments covering security, availability, confidentiality and fraud, a maintained risk register with mitigation strategies, a risk assessment and treatment policy, and annual collection and review of vendor SOC 2 reports or equivalent.

The gap is the clock rather than the substance. No audit date or reporting period is stated, and the reports themselves sit behind a request. Gating the reports behind a request is the normal trust center pattern, and existence and type are established without it, but a SOC 2 Type 2 report covers a defined window and nothing published says whether the window is current.

A trust center at trustcenter.cleo.com, carrying ISO 27001 and a full SSAE-18 suite, belongs to an unrelated business integration software company of a similar name, and none of it applies to this vendor, whose estate is published under Cleo Technologies.

No clearance claimed and none required for documentation. The regulatory exposure here is payment integrity, and what distinguishes this product is when the influence occurs.

Coding tools typically operate 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 company'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 optimized reimbursement and accurate diagnosis related group assignment.

One feature goes further and needs stating plainly. The company describes an 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 prioritize 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 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, and nothing published describes who sees it, in what form, or whether it can be turned off for clinical users while remaining available to administrators.

This is a consequential stance on coding and reimbursement, and the argument has two halves.

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, optimized reimbursement and revenue integrity, with competitors criticized 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 in retrospect.

The counterweight is real. Clinical documentation improvement is an established and legitimate hospital function, retrospective queries 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 is published.

No accuracy or error figure, no published limitations and no warranty, indemnity or remediation commitment is published, 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. 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 artifact through which one clinician tells another what matters about a patient. An omission there is a clinical event rather than a record keeping one, and the person receiving it was not present for the encounter it summarizes, so they have no independent basis to notice what is missing.

A length of stay or payment group estimate is a prediction about an individual admission that can influence discharge planning and resourcing. Nothing published describes its error characteristics or what a clinician is told about its confidence.

Half of the integration question is answered, and it 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, 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.

Nothing published says by what mechanism charges and codes reach the billing or record system, what identity those writes carry in the audit log, whether they can be distinguished from a human entry, what permissions the platform holds to trigger a workflow, or what an institution can restrict. Triggering workflows is a materially deeper privilege than depositing a note, because it causes the receiving system to act.

The integration story is answered for ingest and unanswered for output.

The vendor publishes no hosting region, residency option or full subprocessor list. 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 disclosure matters, 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. Nothing published says whether any protected health information reaches it, whether log scrubbing is in place, or 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 the published material does not settle.

Beyond that one supplier, the questions stay open. 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.

No rate card, tier structure or pricing model is published. 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 pricing is very likely set against the combined cost of the tools it displaces rather than against a per clinician scribe rate.

Deliberately narrow and, within that boundary, broad in acute care. Emergency medicine and hospital medicine only, but spanning the whole inpatient stay from admission through discharge rather than one encounter: layered context, reevaluations, care team handoffs, census management and patient assignments. QuickStart lets a clinician defer patient registration during an emergency and complete it afterward, which reflects how acute care actually sequences. No language coverage is published.