Attend Health

Scribing, compliance auditing and coding intelligence all run on the same model engine, and the company exists to build them. Physician founded, with no services or platform business underneath, though note that ongoing configuration by the vendor is part of the offer rather than a self serve product.

Two mechanisms rather than one. Coding suggestions carry clear explanations, so a clinician sees the reasoning rather than a bare code, which is the reasoned coding control this index now credits in Lime Health, Marvix and CareCortex. And providers can run quality checks themselves on the same engine, positioned as preventing compliance issues and coding errors before they happen rather than detecting them later. Held at B because no confidence threshold, acceptance rate or explicit sign off gate is described.

No accuracy figure, model card, named models or evaluation methodology located, and the claim that the numbers show it works is made without any numbers. One design detail is disclosed usefully: coding suggestions and quality checks are said to run on the same engine as the scribe and to arrive with clear explanations, which describes an architecture rather than a benefit.

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. The boundary side is better than the enumeration side and is genuinely good for this tier, with audio deleted immediately after transcription, notes retained only as long as the customer's own policies require or erased immediately after transfer to the record system, and protected health information stated never to be used for anything other than healthcare, a use limitation that reaches training by construction since training a model is a use other than healthcare delivery.

None of that says who holds the content while it is being processed. One scope question the published commitments do not address belongs here. The audit function ingests records the product did not create, potentially across a whole practice, and the retention statements are written about recorded encounters and generated notes rather than about ingested chart data, which may persist to support trend reporting over time. Ask whether ingested records follow the same schedule, and for a sub processor list covering both the capture and the audit paths.

Named clinician testimonials, including one physician who reports having tried three other AI documentation tools before this one, which is more useful than a generic endorsement because it implies comparison. Beyond that, no study, controlled evaluation, accuracy benchmark, third party rating, named institutional customer or deployment count was located.

The earlier assessment found nothing. That is overturned, and the disclosures now present are among the better sets in this category.

Three commitments are published. Audio is deleted immediately after transcription. Clinical notes and summaries are retained only as long as the customer's own policies require, or erased immediately after transfer to the record system. And protected health information is never used for anything other than healthcare.

Each answers a different part of this axis, which is why the set is stronger than any one of them. Immediate audio deletion removes the largest and most sensitive artefact. Customer defined retention is unusual and better than a vendor default, because it lets an organisation apply its own schedule rather than discover what the vendor chose. And the use limitation reaches training by construction, since training a model is a use other than healthcare delivery.

Two things hold this short of the top grade. The use limitation is not an explicit training statement, and the plainer formulation some peers now use, saying directly that clinical content is never used to train or fine tune models, leaves less room for interpretation. Ask for it in that form in the contract rather than the marketing.

And the audit function complicates the retention picture in a way the published commitments do not address. Auditing existing encounters means ingesting records the product did not create, potentially across a whole practice. Establish whether ingested chart data follows the same schedule as generated notes, or persists to support trend reporting over time.

Ask for the schedule for ingested records specifically, and the training position in contract language.

No business associate agreement posture, template or scope statement was located, and the vendor's published privacy material addresses safeguards rather than the contractual relationship.

That distinction is the whole of this axis and it matters more here than for a vendor with weaker disclosures, because this one has published real commitments on the other side. Immediate audio deletion, customer defined retention and a use limitation are meaningful undertakings. They are stated on a website, where a vendor can revise them without notice. The agreement is where such commitments become enforceable, and nothing establishes that these appear in it.

So the practical instruction is unusually concrete: take the published commitments to the vendor and ask for each to be reflected in contract language. Audio deletion immediately after transcription, retention governed by the customer's schedule, and no use of protected health information other than for healthcare are all clean contractual terms. A vendor that means them will agree to them.

One scope question follows from the product's breadth. The audit component processes existing clinical encounters, which means protected health information for patients whose visits this vendor never documented, potentially across an entire practice. An agreement drafted around ambient capture describes the vendor receiving what it was invited to hear. It may not describe it reading records created before it arrived, by other clinicians. Establish which population is covered and what the permitted uses are for ingested historical records.

Ask for the agreement, its scope over audited records, and the subprocessor list.

The earlier assessment located no attestation. That is overturned. The vendor states it holds a SOC 2 certification from the recognised accounting standards body, that all data is encrypted, and that independent third parties continuously assess and audit its systems.

Continuous third party assessment named separately from the attestation is worth crediting. A point in time report and an ongoing testing programme answer different questions, and a vendor distinguishing them has understood that.

One omission should be pressed rather than assumed away, because this index has now seen it repeatedly. The report type is not stated. A Type I report assesses whether controls were suitably designed at a single moment; a Type II tests whether they operated effectively across a period, usually several months. The difference is substantial and the gap between them is where most real control failures live. A peer in this lane states plainly that it holds Type I, which is the honest version; several others say only SOC 2 and leave a reader to assume the stronger one. Ask which applies here.

Scope is the second question and it matters more than usual. This is not a scribe alone. The platform also audits a practice's existing clinical encounters, which requires read access across records the product did not create. An attestation covering documentation would leave the audit function outside the boundary.

Ask for the report, its type, period and scope, and specifically whether the audit component's access to existing records is inside the assessed boundary.

No clearance claimed and none required. The exposure is payment integrity, and this record has a structural feature worth setting out because it is designed rather than incidental.

The platform pairs a scribe with an audit product that reviews every clinical encounter for incorrectly coded visits and documentation integrity gaps, positioned as catching errors before billing rather than after. That positioning is sound and the pre bill placement is genuinely better for a practice than a retrospective payer audit.

The structural point is what happens next. The vendor states the audit works in tandem with the scribe, feeding insights back into documentation workflows, and that issues identified by the audit are fixed by updating the scribe's configuration. So the same vendor's audit examines the same vendor's generated documentation, and its findings retune the generator.

As a quality improvement mechanism that is elegant and it genuinely will raise consistency. It also has no external reference point. An audit that feeds its own generator will converge on output the audit approves, and the standard being converged on is the vendor's model of correct coding rather than a payer's determination or a regulator's. Consistency with an internal standard is not the same as correctness, and a closed loop cannot tell the difference.

This index has recorded two related cases: a vendor generating the justification alongside the code it selects, and a vendor auditing charts it produced. This is the most systematic version, because the feedback path is the product design.

Ask what the audit's standard of correctness is derived from, whether it has been validated against actual payer determinations or denial outcomes, and whether any external benchmark constrains the loop.

On the coding gradient, framed in both directions at once, which is unusual and worth describing precisely. The revenue language is present: Attend is sold partly on helping organisations recover lost revenue their documentation has been hiding. Set against that, the same sentence names managing audit risk, the audit product exists to find compliance problems rather than only missed charges, and coding suggestions come with explanations a reviewer can evaluate.

That combination puts it closer to ScribeEMR's downside protection framing than to the revenue optimisation end occupied by MarianaAI and Steer Health. What is absent is conventional governance disclosure: no fairness statement, subgroup analysis or accent and dialect performance data, and no language coverage claimed.

One published claim on this record is worth naming as a rhetorical move rather than a measurement, because it is more evasive than silence. The vendor states that the numbers show it works, and publishes no numbers. Asserting that evidence exists while withholding it invites a reader to credit a body of proof they cannot examine, and it is a step further than simply not publishing an accuracy figure, which at least leaves the reader knowing where they stand.

What keeps this in the middle band is a real mechanism. Coding suggestions and quality checks are stated to run on the same engine as the scribe and to arrive with clear explanations, so a user receives the basis for a suggestion rather than a bare recommendation, and can decline it on its reasoning. The explanations are not described in enough detail to assess their depth, which is the limit of the credit here.

The data commitments are among the better sets in this category and belong on the stewardship axis rather than this one, since immediate audio deletion and customer defined retention govern how long content is held rather than whether the output is correct. No accuracy figure, no published limitations and no warranty, indemnity or remediation commitment was located. Ask to see the numbers the vendor says exist, with a definition and a sample.

The vendor now describes the shape of its integration, though not the mechanism. It states that it configures the product to work with whichever record system a practice already uses, importing patient data as context, building documentation, and sending it back automatically in the format the team expects.

That establishes the flow is bidirectional and that the product reads chart context in as well as writing documentation out, which the earlier assessment inferred from the audit function and is now stated. Reading patient data as context is a deeper privilege than depositing a note, and it is the access the audit component necessarily requires.

What is not described is how any of it happens. No record system is named, no interface standard is referenced, and no distinction is drawn between a permissioned connection and automation driving the user interface. Six vendors in this lane reach the chart the second way while describing it in language that sounds like the first, so the phrasing does not settle it.

The per customer configuration model is the second thing to press. Configured to work with the record system you already use suggests bespoke work per deployment rather than a standard connector, which means integration depth, maintenance responsibility and upgrade fragility differ by customer. What a demonstration shows may not be what a given practice receives.

So the questions are specific. Which systems are supported today. By what mechanism, per system. What identity do reads and writes carry in the audit log. Who maintains the integration when the record system is upgraded. And what scope of read access does the audit function require across existing records.

No hosting region, residency option, subprocessor list or model provider was located.

One phrase in the vendor's privacy material points at something useful and stops short of stating it. Data is described as configured to match the organisation's compliance requirements. Configurability of that kind normally implies residency or retention options exist, since compliance requirements differ largely by jurisdiction and sector. The retention half of that is confirmed elsewhere, with customer defined schedules. The residency half is not stated at all.

So the question is whether the configurability extends to where data sits, or only to how long it is kept. A practice under a state or sector requirement to hold health information in a particular location needs the first, and cannot infer it from the second.

The model provider question is unanswered and matters here because the platform does more than transcribe. It generates documentation, produces coding suggestions with explanations, and audits existing encounters for integrity issues. Those are distinct workloads and may not run on the same service. Establish whether an external model provider processes clinical content, whether the same provider handles all three functions, and what it retains.

The audit component sharpens the residency question in the way it sharpens the others. Auditing existing encounters means ingested chart data crosses whatever boundary the platform sits behind, in volume and continuously, rather than only encounters the product captured.

Ask whether residency is configurable, for the hosting region, the subprocessor list, and the model provider for each function.

No published rate card, tier structure or pricing model located. Because ongoing configuration by the vendor is part of the offer rather than a one time setup, a buyer should establish whether that service is included indefinitely or billed separately once the initial tuning is done.

Specialty fit is achieved through per clinician configuration rather than a template library, on the stated premise that no two clinicians document the same way, and the vendor commits to refining output until it matches and updating it as protocols change. Output includes patient instructions alongside SOAP notes, which several testimonials single out. Held at C because no specialty count, care setting range or language coverage was located, so breadth cannot be compared with vendors that publish it.