AlethianAI

The agents are the engine of the clinical modules, and a practice management platform sits underneath them that would survive their removal.

What the models do is real and central to the pitch. A live scribe transcribes encounters and generates structured notes. A physician assistant agent runs patient interviews and builds history narratives. A receptionist agent handles calls, scheduling, confirmations and cancellations. A coding agent maps clinical language to diagnosis and procedure codes. None of those exists without a model, and the company's commercial claim, a halving of clinical support staff cost, is a claim about what the agents replace.

But the published feature list is wider than the agent roster and much of it is ordinary software. Online booking on the practice's own website. A healthcare marketplace that raises clinic and provider visibility to attract patients. Insurance eligibility checking and benefits explanation. Payment collection for copays before the visit and balances after it. Digitized express check in forms that sync to the record system. Reputation management, collecting and monitoring patient reviews and ratings. An automated waitlist that fills canceled slots.

Strip every model out and that remains: a booking, intake, eligibility, payments, reviews and directory platform for small practices. Those are the components of a conventional practice management product and practices buy them without any artificial intelligence at all.

So the model is the engine of core modules while the platform carries other value. How good the agents are is a separate question; remove them and a practice would still hold a product.

Nothing published says which half a given contract is priced on.

No escalation criteria, confidence thresholds or human review gates are published, and the platform is sold on autonomy: an intelligent virtual assistant handling calls in real time, agents automating patient interviews, and a halving of clinical support staff cost as the stated commercial benefit.

Several agents take consequential action rather than drafting for review. The inbox manager works refills, lab results and follow ups. The coding agent assigns diagnosis and procedure codes and the product is marketed on audit defense and clean claim rates. The receptionist speaks to patients unsupervised, handles booking, confirmation, rescheduling and cancellation, and sends outbound voice, message and email reminders. The physician assistant agent conducts patient interviews and produces clinician ready history narratives. Each needs a defined boundary and none is published: what a refill agent may action without a clinician, what happens to an abnormal laboratory result, whether a suggested code is submitted or held for a coder, and when a call reaches a person.

The traceability feature is real: documentation carries evidence links back to the codes it supports, so an auditor can follow a code to the language that justified it. Traceability after the fact is not a control before it, and a code that has already gone out on a claim has already created exposure.

The commercial framing is what makes the gap matter. A product whose value proposition is replacing clinical support staff removes the people who would otherwise catch an agent's mistake, so the oversight model has to be stronger than at a product that merely assists them, not weaker. Nothing published describes one.

For a platform at this stage this is the single most important thing to establish before deployment.

No foundation model is named, no architecture is described, no evaluation methodology is published and no accuracy figure exists for any of the agents.

Two things count in its favor. The company states it holds licensed procedure code content from the professional body that maintains it, used for scribe training and code suggestion, which is a specific and externally checkable licensing fact rather than a general assurance and the correct basis for a product suggesting those codes. And the scribe produces documentation with evidence links back to the codes it supports, giving a coder or auditor a traceable path from a code to the language that justified it.

That traceability is the right design and nothing measures whether it is correct. For a platform generating documentation, assigning codes and marketing audit defense, the useful numbers are the rate at which suggested codes are accepted unchanged and how often a code survives payer review. Neither is published, and the site instead carries a 99.9 percent clean claim submission rate with no denominator, period or source, which is a different measurement and not a substitute.

The version question goes unanswered too. Nothing names what produces the output, nothing states how it is updated, and nothing tells a practice how it would learn the behavior had changed between one week's notes and the next.

A magic edit feature is described, allowing complex edits to a note by voice or writing, which is a second model surface with no description behind it.

One input is named and externally checkable.

The company states it holds licensed procedure code content from the professional body that maintains it, used for scribe training and code suggestion. That is a specific licensing fact rather than a general assurance, it is verifiable in principle, and it is the correct basis for a product suggesting those codes, since using that content without a license is itself a problem.

Everything else is absent. No foundation model provider, model class or version is named, no hosting arrangement is published, and no sub processor register exists. The content flowing through that unnamed chain is broad for an early stage company: call audio from the reception agent, symptom and history detail captured at intake, encounter recordings and generated notes, laboratory results and messages handled by the inbox agent, and now payment details and a public provider directory.

The onward direction is disclosed. The privacy policy states the company creates de identified data sets often derived from patient data received from healthcare providers and may share them with third parties for its lawful business purposes. That is a chain with an open end: the set of recipients is defined by a purpose rather than by a list, so even a complete register supplied on request would describe today's position and commit to nothing about tomorrow's.

The training question is only half answered. The licensed content statement covers one input and says nothing about the others.

Eleven quantified outcome claims are published and not one of them carries a source.

The figures span the whole platform: over 50 percent reduction in clinical support staff costs, 80 percent reduction in patient wait times, a 99.9 percent clean claim submission rate, over 90 percent less manual registration work, over 90 percent faster medical record review, 90 percent less time spent on documentation, 50 percent more time in diagnosis, 30 percent fewer cancellations and no shows, 40 percent lower operational cost, up to 80 percent faster patient service, and multi fold return on investment within the first year. A stated timeframe accompanies one of them, wait time reduction within 60 to 90 days.

The framing around them is the part to weigh. They are described as proven results from real healthcare practice implementations, as achieved in verified deployments, and as maintained across verified implementations. Verified is a strong word and nothing published says who verified anything.

No customer is named, no site, no practice count, no denominator, no baseline, no measurement period and no method. No case study, reference or third party evaluation is published.

The breadth compounds it. This is a company that emerged from stealth in late 2025 on a seed round, claiming measured results across reception, intake, documentation, coding, billing, eligibility, payments and the clinical inbox simultaneously. Nothing published says which agents are in production at a real practice today rather than on the feature list.

This is an absence of checkable evidence rather than evidence of poor performance.

The published terms answer part of this and what they permit is the finding rather than any silence.

A privacy policy is published with a data security and retention section, a dedicated section on protected health information, state privacy rights and messaging terms. It states that the company creates de identified data sets derived from the personal data it holds, that this de identified data often comes from the patient data it receives from healthcare providers, and that it may share aggregated, de identified or anonymized data with third parties for its lawful business purposes. No de identification standard is named, so a buyer cannot tell whether the method meets the rule's safe harbor or expert determination route.

What remains unstated is the question this product raises most sharply. Nothing anywhere says whether customer content is used to train or improve models. The company states it holds licensed procedure code content used for scribe training, which tells a buyer about one input and nothing about the others, and the others are the sensitive ones: call audio from the reception agent, symptom and history detail captured at intake, encounter recordings and generated notes, and laboratory results and messages handled by the inbox agent.

So establish whether encounter audio, generated notes or intake responses from one practice improve models serving another, and what survives after a note is filed. Those answers are cheap to give while a company is small and much harder to unwind once a corpus exists.

No retention period in days or months is stated, no deletion path is described, and no position is published on what happens to recordings and derived data at contract end.

Business associate status is stated in terms, in a published document.

The privacy policy carries a dedicated section on the health privacy rule and protected health information. It states that demographic, health and health related information the company collects about users on behalf of healthcare providers may be protected health information; that this applies when the company provides administrative, operational or other services to a provider that is a covered entity and receives identifiable information on that provider's behalf; and that in doing so the company is acting as a business associate as the rule defines it. Naming the status, the condition that triggers it and the counterparty is the substantive form of this disclosure.

The policy then narrows its own reach. It states that it does not apply to protected health information, which is instead regulated by the rule itself, and directs the reader to their provider's own notice of privacy practices.

Set against that, a second passage in the same document says the company creates deidentified data sets derived from personal data it holds, that this deidentified data often comes from the patient data it receives from healthcare providers, and that it may share such data with third parties for its lawful business purposes. Those two statements are not the same statement. One says the document does not govern clinical data; the other describes deriving and sharing data sets from exactly that clinical data. The exposed parties are the practice that signed the agreement, which may not have negotiated the onward sharing, and the patient, who is directed to a notice that says nothing about it.

No agreement terms, template, execution path, subcontractor flow down position or deidentification standard is published, and no attestation supports the platform's own compliance assertion.

A trust center exists, and it is the only security surface published beyond marketing claims.

The company links a hosted trust portal at a named compliance platform from its own site, and the portal may hold attestations.

Nothing else published names an attestation against a recognized framework: no report of any type, no healthcare specific certification, no international standard, no penetration testing statement on a stated cadence and no vulnerability disclosure policy. What the site itself asserts is that the platform is compliant with the health privacy rule and meets healthcare security requirements, which is a self assertion rather than an independent examination.

Stage context matters. The company emerged from stealth in late 2025 with a seed round, and a completed attestation would be unusual that early. The absence of a published one is not a judgment on the team, and a hosted trust portal at this stage suggests a company putting the apparatus in place rather than avoiding the question.

The gap weighs more for two reasons. The stated buyers are small clinics and practices in rural and underserved areas, the organizations least equipped to run their own vendor security assessment and most reliant on published assurance. And the data surface is wide for a young company, spanning call audio, intake responses, clinical documentation, coding and the clinical inbox.

No clearance, device authorization or published decision support exemption analysis exists, and the question is live here rather than academic.

The physician assistant agent is described as automating patient interviews, gathering and organizing symptom detail and medical history, and producing clinician ready history narratives. Software that takes a patient's account of their symptoms and structures it into a clinical narrative sits close to the device boundary, and whether it stays outside depends on whether a clinician can independently review the basis of its output. Most agents on this platform are plainly administrative. That one is not, and no analysis of where it falls is published.

The product naming is easy to over read. The coding product is branded as a diagnosis and billing assistant, and what it actually does is map clinical language to diagnosis and procedure codes. Diagnosis coding is not clinical diagnosis, and the branding invites the confusion in a category where the distinction is regulatory rather than cosmetic.

Two further regimes apply and are unaddressed. The coding and billing agents shape what is submitted for payment, and liability under the false claims framework sits with the practice submitting rather than the vendor suggesting, which makes the advertised clean claim rate a claim about the practice's exposure. And the receptionist agent places outbound voice reminders, which reaches the consumer telephone consent framework, where the regulator has held that artificial voices require prior express consent.

No governance framework, model monitoring disclosure or bias evaluation is published.

The company's own positioning raises the bar rather than lowering it. It markets on preserving access in rural and underserved communities facing reductions in state health funding, and that is a claim about equity rather than only efficiency. A vendor making an access claim carries a stronger duty to publish evidence for it than one selling time savings.

The mechanism is direct. Conversational agents handle reception and patient intake, and speech recognition and language understanding vary with accent, dialect, speech rate and language. In a rural or underserved practice that variation determines who can book an appointment, complete an intake, or get a refill handled without reaching a human. Where the product's stated purpose is to halve clinical support staff cost, a patient the system cannot understand has fewer fallbacks than before rather than more, and the failure is invisible: a caller who gives up leaves no record and no complaint.

Nothing reports performance by language or population, nothing states which languages the voice agents operate in, and nothing describes what happens when an agent fails to understand a patient.

The outbound side carries the same question. Voice, message and email reminders reach a patient population that is not uniformly English speaking or uniformly comfortable with an automated caller, and no accommodation is described.

The traceability design is the right one, and it is the strongest point on liability.

The scribe produces documentation with evidence links back to the codes it supports, so a coder or auditor can follow a code to the language that justified it rather than accepting an assignment on trust. That principle matters more in coding than in note text, because a code determines what is billed and the exposure for a wrong one sits with the practice submitting rather than with the vendor suggesting. It also underpins the product's own audit defense positioning, since an audit defense is only as good as the evidence path it can produce.

What is missing is any measure of whether the links point at the right things. No accuracy figure, error rate or evaluation methodology exists for any agent, and for a platform generating documentation, assigning codes and marketing audit defense the useful numbers are the rate at which suggested codes are accepted unchanged and how often a code survives payer review. Neither is published. The site carries a 99.9 percent clean claim submission rate instead, with no denominator, period or source, and a clean submission is a claim that passed format and eligibility checks rather than one that survived review.

No warranty, indemnity or remediation commitment exists.

The allocation of risk runs one way. The vendor suggests the code, the practice signs and submits it, and liability under the false claims framework attaches to the submitter. A product marketed on audit defense is selling reassurance about an exposure it does not carry.

Bidirectional integration with Epic, Cerner, and Allscripts is stated, with real time note completion during encounters and paperless intake syncing to the EHR. Graded conservatively because the claim is vendor asserted with no marketplace listing, certification, or customer reference retrieved to corroborate it, and bidirectional write access to three major EHRs is a substantial claim for a company selling for under a year.

No hosting provider, region, tenancy model or data residency commitment is published, and no sub processor register exists.

Two sub processor layers are near certain given what the product does, and neither is disclosed. The reception agent implies telephony carriage and speech processing, usually operated by third parties rather than built in house. And a platform generating documentation and suggesting codes implies a language model provider.

On that second point, nothing published says where inference executes, which model providers are involved, whether encounter content leaves the practice boundary on every note, or what those providers retain of prompt and completion data. A young company assembling a stack quickly will add sub processors as it grows, and no commitment to notify customers when the list changes is published.

The wider feature list adds a third layer. Payment collection for copays and balances brings a payments processor into the chain, and a healthcare marketplace raising provider visibility implies a public directory surface holding provider and possibly patient facing data outside the clinical system. Neither is described.

Deployment shape is stated only as phased, starting with administrative functions, with implementation and record system integration included in the engagement. No uptime commitment, support model or customer count is published.

No public pricing. Direct sales to clinics, MSOs, and hospitals with implementation and EHR integration included, marketed on reduced clinical support staff cost.

Scope is stated clearly by function and by buyer. The agent roster covers reception and scheduling, intake and history capture, documentation, coding, billing and clinical inbox management, sold to clinics, management services organizations and hospitals, with an initial geographic focus on Washington State and stated attention to rural and underserved providers.

Naming a starting market rather than claiming national coverage fits a company at this stage.

No specialty scoping is stated at all, and specialty is where this kind of platform usually breaks. Documentation, coding and intake differ substantially between primary care, behavioral health, orthopedics and oncology, and a roster this broad from a company selling for under a year is unlikely to be equally mature across them. Nothing says which specialties are in production today rather than supported in principle.